41 Matching Annotations
  1. Jul 2023
    1. "Data models for different systems are arbitrarily different. The result of this is that complex interfaces are required between systems that share data. These interfaces can account for between 25-70% of the cost of current systems".
  2. Jun 2023
    1. under the name “conversion functions.” These exist in Ruby’s standard library - for example Array() is one that you’re likely to see in real code.
  3. Feb 2023
    1. I observe that they take no care of the conversion of their Slaves.

      In New York in 1687, Thomas Dongan reports that people didn't convert their slaves to their own religions.

  4. Dec 2022
    1. Basically I wanted to merge every tiddler into one ORG file.

      All this detailed manipulation re/decomposing tiddlers in other formats or adding tiddlers content in a programmatic way is done via TiddlyWikiPharo and inside a single language. For external functionality not implemented or too slow in Pharo (for example YAML to JSON conversion) we try to program it in Nim and create a Pharo wrapper around the Nim binary output.

    2. Generate HTML and meta files

      For this, we use Pandoc's YAML metadata blocks or approaches inspired by it. Our data publishing package MiniDocs (which is a prerequisite of TiddlyWikiPharo), provides a YAML metadata importer/transformer to native Pharo dictionaries that can be added to tiddlers. An alternative route from tiddlers metadata to Markdown could be easily implemented (but, as told our focus has been Markdown to WikiText migrations so far)

    3. Now let’s generate the single HTML file:

      We do this in a semi-automatic way, as the manipulated tiddlers inside TiddlyWikiPharo powered data narratives are exported as a single JSON file that is dropped back into the single HTML file we they came from, before manipulation. Some automation could be implemented in the future, maybe with a simple Nim TW server (as we try to avoid JS incidental complexity as much as we can, including/particularly node).

    4. David Alfonso has done a great job and put together a repository that helps you with the export of tiddlers. All you need is to export all your tiddlers bundled as one single HTML and then follow the instructions in the README.

      TiddlyWikiPharo is capable of similar exportation and we start from the single HTML TW file that we can de/recompose almost at will, because we can manipulate the tiddlers inside a data narrative. As shown in the malleable systems wiki example, we're mostly focused in conversions from Markdown to WikiText (TW's format) as it is our most felt necessity, but migrations from WikiText to Markdown are in the radar, combining/extending TiddlyWikiPharo with Pandoc (future needs/funding will tell if/when is implemented).

  5. Nov 2022
    1. by using symbols as keys, you will be able to use the implicit conversion of a Mash via the #to_hash method to destructure (or splat) the contents of a Mash out to a block

      Eh? The example below:

      symbol_mash = SymbolizedMash.new(id: 123, name: 'Rey') symbol_mash.each do |key, value| # key is :id, then :name # value is 123, then 'Rey' end

      seems to imply that this is possible (and does an implicit conversion) because it defines to_hash. But that's simply not true, as these 2 examples below prove:

      ``` main > symbol_mash.class_eval { undef :to_hash } => nil

      main > symbol_mash.each {|k,v| p [k,v] } [:id, 123] [:name, "Rey"] => {:id=>123, :name=>Rey} ```

      ``` main > s = 'a' => a

      main > s.class_eval do def to_hash chars.zip(chars).to_h end end => :to_hash

      main > s.to_hash => {a=>a}

      main > s.each Traceback (most recent call last) (filtered by backtrace_cleaner; set Pry.config.clean_backtrace = false to see all frames): 1: (pry):85:in __pry__' NoMethodError: undefined methodeach' for "a":String ```

  6. Apr 2022
    1. First, there is a need at the institutional level to offer the students information about the learning models in general, and the online CSCL activities specifically, in order to allow them to adjust their expectations, preferences, and decision

  7. Mar 2022
  8. Feb 2022
  9. Nov 2021
  10. Mar 2021
    1. “There is very little incentive for Microsoft to make a significant change to features that are used extremely widely by the rest of the massive community of Excel users.”

      Microsoft did the right thing here. Most users are not geneticists and they rely on automatic date conversion.

  11. Oct 2020
  12. Sep 2020
    1. This package exposes an hyperscript compatible function: h(tag, properties, ...children) which returns a svelte component.
  13. Jul 2020
  14. Jun 2020
  15. Apr 2020
  16. Mar 2020
  17. Feb 2020
    1. Import from other open source toolsWe have built tools to convert your existing JMeter tests and Postman collections
  18. Dec 2019
    1. These Web pages presents a set of examples using ImageMagick ("IM," for short) from the command line. However, they also illustrate what can be done using the ImageMagick Application Programming Interface (API). As such, these pages should be the first stop for IM users after reading the terse Command Line (CLI) Option manuals.
    1. We see that ImageMagick is very good about preserving aspect ratios of images, to prevent distortion of your favorite photos and images. But you might really want the dimensions to be 100x200, thereby stretching the image. In this case just tell ImageMagick you really mean it (!) by appending an exclamation operator to the geometry. This will force the image size to exactly what you specify. So, for example, if you specify 100x200! the dimensions will become exactly 100x200 (giving a small, vertically elongated wizard)
    2. Image Geometry Many command-line options take a geometry argument to specify such things as the desired width and height of an image and other dimensional quantities. Because users want so many variations on the resulting dimensions, sizes, and positions of images (and because ImageMagick wants to provide them), the geometry argument can take many forms. We describe many of these in this section. The image options and settings that take some form of a geometry argument include the following. Keep in mind that some of these parse their arguments in slightly different ways. See the documentation for the individual option or setting for more specifics. ‑adaptive‑resize • ‑border • ‑borderwidth • ‑chop • ‑crop • ‑density • ‑extent • ‑extract • ‑frame • ‑geometry • ‑iconGeometry • ‑liquid‑rescale • ‑page • ‑region • ‑repage • ‑resize • ‑sample • ‑scale • ‑shave • ‑splice • ‑thumbnail • ‑window The geometry argument might take any of the forms listed in the table below. These will described in more detail in the subsections following the table. The usual form is size[offset], meaning size is required and offset is optional. Occasionally, [size]offset is possible. In no cases are spaces permitted within the geometry argument. size General description (actual behavior can vary for different options and settings) scale% Height and width both scaled by specified percentage. scale-x%xscale-y% Height and width individually scaled by specified percentages. (Only one % symbol needed.) width Width given, height automagically selected to preserve aspect ratio. xheight Height given, width automagically selected to preserve aspect ratio. widthxheight Maximum values of height and width given, aspect ratio preserved. widthxheight^ Minimum values of width and height given, aspect ratio preserved. widthxheight! Width and height emphatically given, original aspect ratio ignored. widthxheight> Shrinks an image with dimension(s) larger than the corresponding width and/or height argument(s). widthxheight< Enlarges an image with dimension(s) smaller than the corresponding width and/or height argument(s). area@ Resize image to have specified area in pixels. Aspect ratio is preserved. x:y Here x and y denotes an aspect ratio (e.g. 3:2 = 1.5). {size}{offset} Specifying the offset (default is +0+0). Below, {size} refers to any of the forms above. {size}{+-}x{+-}y Horizontal and vertical offsets x and y, specified in pixels. Signs are required for both. Offsets are affected by ‑gravity setting. Offsets are not affected by % or other size operators. Note that positive X and Y offsets are in the inward direction towards the center of the image for all ‑gravity options, except 'center'. For East, +X is left. For South, +Y is up. For SouthEast, +X is left and +Y is up. For center, the normal X and Y directional convention is used (+X is right and +Y is down). Basic adjustments to width and height; the operators %, ^, and ! Here, just below, are a few simple examples of geometry, showing how it might be used as an argument to the ‑resize option. We'll use the internal image logo: for our input image. This fine image is 640 pixels wide and 480 pixels high. We say its dimensions are 640x480. When we give dimensions of an image, the width (the horizontal dimension) always precedes the height (the vertical dimension). This will be true when we speak of coordinates or offsets into an image, which will always be x–value followed by y. Just think of your high school algebra classes and the xy–plane. (Well, almost: our y–axis will always go downward!) magick logo: -resize '200%' bigWiz.png magick logo: -resize '200x50%' longShortWiz.png magick logo: -resize '100x200' notThinWiz.png magick logo: -resize '100x200^' biggerNotThinWiz.png magick logo: -resize '100x200!' dochThinWiz.png The first of the four commands is simple—it stretches both the width and height of the input image by 200% in each direction; it magnifies the whole thing by a factor of two. The second command specifies different percentages for each direction, stretching the width to 200% and squashing the height to 50%. The resulting image (in this example) has dimensions 1280x240. Notice that the percent symbol needn't be repeated; the following are equivalent: 200x50%, 200%x50, 200%x50%. By default, the width and height given in a geometry argument are maximum values unless a percentage is specified. That is, the image is expanded or contracted to fit the specified width and height value while maintaining the aspect ratio (the ratio of its height to its width) of the image. For instance, the third command above "tries" to set the dimensions to 100x200. Imagine gradually shrinking the original image (which is 640x480), keeping is aspect ratio constant, until it just fits into a 100x200 rectangle. Since the image is longer than it is tall, it will fit when its width shrinks to 100 pixels. To preserve the aspect ratio, the height will therefore have to be (480/640)×100 pixels=75 pixels, so the final dimensions will be 100x75. Notice that in the previous example, at least one of the specified dimensions will be attained (in this case, the width, 100 pixels). The resulting image fits snugly within the original. One can do just the opposite of this by invoking the ^ operator, as in the fourth example above. In that case, when 100x200^ is given as the argument, again at least one of the dimensions will be attained, but in this case the resulting image can snugly contain the original. Here the geometry argument gives minimum values. In our example, the height will become 200 and the width will be scaled to preserve the aspect ratio, becoming (640/480)×200 pixels=267 pixels. With the ^ operator, one of those dimensions will match the requested size, but the image will likely overflow the dimensions requested to preserve its aspect ratio. (The ^ feature is new as of IM 6.3.8-2.) We see that ImageMagick is very good about preserving aspect ratios of images, to prevent distortion of your favorite photos and images. But you might really want the dimensions to be 100x200, thereby stretching the image. In this case just tell ImageMagick you really mean it (!) by appending an exclamation operator to the geometry. This will force the image size to exactly what you specify. So, for example, if you specify 100x200! the dimensions will become exactly 100x200 (giving a small, vertically elongated wizard). Bounding the width, height, and area; the operators >, <, and @ Here are a few more examples: magick logo: -resize '100' wiz1.png magick logo: -resize 'x200' wiz2.png magick logo: -resize '100x200>' wiz3.png magick logo: -resize '100x200<' wiz4.png If only one dimension is given it is taken to be the width. When only the width is specified, as in the first example above, the width is accepted as given and the height is chosen to maintain the aspect ratio of the input image. Similarly, if only the height is specified, as in the second example above, the height is accepted and the width is chosen to maintain the aspect ratio. Use > to shrink an image only if its dimension(s) are larger than the corresponding width and/or height arguments. Use < to enlarge an image only if its dimension(s) are smaller than the corresponding width and/or height arguments. In either case, if a change is made, the result is as if the > or < operator was not present. So, in the third example above, we specified 100x200> and the original image size is 640x480, so the image size is reduced as if we had specified 100x200. However, in the fourth example above, there will be no change to its size. Finally, use @ to specify the maximum area in pixels of an image, again while attempting to preserve aspect ratio. (Pixels take only integer values, so some approximation is always at work.) In the following example, an area of 10000 pixels is requested. The resulting file has dimensions 115x86, which has 9890 pixels. magick logo: -resize '10000@' wiz10000.png In all the examples above and below, we have enclosed the geometry arguments within quotation marks. Doing so is optional in many cases, but not always. We must enclose the geometry specifications in quotation marks when using < or > to prevent these characters from being interpreted by the shell as file redirection. On Windows systems, the carat ^ needs to be within quotes, else it is ignored. To be safe, one should probably maintain a habit of enclosing all geometry arguments in quotes, as we have here. Offsets in geometry Here are some examples to illustrate the use of offsets in geometry arguments. One typical use of offsets is in conjunction with the ‑region option. This option allows many other options to modify the pixels within a specified rectangular subregion of an image. As such, it needs to be given the width and height of that region, and also an offset into the image, which is a pair of coordinates that indicate the location of the region within the larger image. Below, in the first example, we specify a region of size 100x200 to be located at the xy–coordinates x=10, y=20. Let's use the usual algebraic notation (x,y)=(10,20), for convenience. magick logo: -region '100x200+10+20' -negate wizNeg1.png magick logo: -region '100x200-10+20' -negate wizNeg2.png magick logo: -gravity center -region '100x200-10+20' -negate wizNeg3.png Note that offsets always require +/− signs. The offset is not actually a true location within the image; its coordinates must be added to some other location. Let's refer to that as the current location. In the first two examples above, though, that location is the upper-left hand corner of the image, which has coordinates (0,0). (That is the default situation when there are no other directives given to change it.) The first example above puts the 100x200 rectangle's own upper-left corner at (10,20). A negative offset can make sense in many cases. In the second example above, the offset is (-10,20), specified by -10+20. In that case, only the portion of the (virtual) rectangle obtained that lies within the image can be negated; here it is equivalent to specifying the geometry as 90x200+0+20. In the third example above, the ‑gravity setting precedes the others and sets the current location within the image at the very center of the image. In this case that is at pixel (320,240), since the size of the image is 640x480. This means that the offsets apply to that location, which thereby gets moved, in this case, to (320-10,240+20)=(310,260). But the 100x200 region itself is affected by the ‑gravity setting, so instead of affecting its upper-left corner, the region's own center (at (+50,+100) within it) is determined. Therefore the center of the 100x200 rectangle is moved to (310,260). The negated rectangle's upper-left corner is now at (310-50,260-100)=(260,160).
  19. Nov 2019
    1. Use ImageMagick® to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 200) including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG. Use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.
  20. Oct 2018
  21. Aug 2015