Variable parameter in transform scale() svg document - variables

In a SVG file, I want to define some global constants values in the defs section (or any other relevant node) to be reused as a scale parameter.
<svg:defs id="defs4">
xxxx value defined here
</svg:defs>
...
<svg:g id="id1" transform="scale(xxxx)">...</svg:g>
PS : there is no scripting involved here
I've tried the param() function without any success...
Is it even possible ?
Thanks.

There is an SVG parameters specification but it's still being written and not implemented by any UAs natively yet. There are some examples of how it would work in the primer but they are currently implemented using javascript. Future UAs that implemented the parameters specification once it is complete would not need scripting to be turned on for parameters to work.

Related

How to get the list of all the parameters for gurobi solver

I am trying to add gurobi solver interface to a modeling language (in c++) and I was wondering if there is a list of all the available parameters somewhere. I found this https://www.gurobi.com/documentation/9.1/refman/parameters.html page that describes some parameters but I am not sure if this is the exhaustive list or not.
All public parameters are listed in the header file include/gurobi_c++.h.

Vim - proper handling of multiple syntax in a single shell script

I write many scripts where there is complex awk logic incorporated into the script directly. I prefer the "one-stop-shop" approach and not have those logic segments as external files.
I have tried what I have seen in this reference about specifying the multiple syntaxes that are to be evaluated (and hopefully colorized per syntax colorscheme). I tried the suggested method as both a VIM command and as a setting in the .vimrc file. The use of "setfiletype sh.awk.sed" did not work in either case.
Is there a special way to make this work properly ?
Another reference seems to provide what looks like awk-related syntax declarations. However, those are presented out of context, and it is not clear if the info provided is complete and self-contained, or whether that is an extract from an unknown, unpublished larger syntax definition, and whether that is added to the sh.vim or the awk.vim syntax files ?
Can anyone shed light on this ?
This first image is a test file created to show my colorscheme use-cases for Bourne shell.
This second image is a sample of awk logic displayed by the same scheme.

How to add an underscore mixin library to WebStorm?

In my work, we have a file with utilities functions that are extended in _.mixin() function at runtime. No, I cannot change the framework, because the solution would be to separate those function from _.mixin() and make them and indepent module, that would be the best.
Either way, my problem is that I cannot link this file, with all the extended functions in WebStorm, so I always see Unresolved function or method warning
Yes I have tried to add the file in the Library tab under Libraries & Framework preferences. And it did nothing.
So my question is, It is possible to WebStorm (or other Atlassian software) to link a file with several functions that will be extended with Underscore.js _.mixin() function to show up in Autocomplete?
Thanks, in advance
Adding the file to JavaScript libraries won't help here. _.mixin() dynamically adds passed utility functions to _ object, it's not possible to resolve such dynamically generated stuff during static code analysis unless a special treatment for the certain functions is provided. And WebStorm doesn't provide any special support for _.mixin().
If you miss it, please feel free to create a feature request in youtrack, https://youtrack.jetbrains.com/issues/WEB

Dart - dart2js and further size-optimization

I already using the minify argument when building with dart2js.
I looked at the output and I see that the import 'dart:html causes problems in terms of the output file size (2kb .dart file becomes 182kb .js file). For example it imports SVG package though in my code I never touch any <svg> DOM Elements.
I understand that the compiler doesn't know if I'm going to use svg DOM Elements or not. And I understand that the using of var is one of the reasons of that behavior.
But if I will not use any var keywords, the compiler still doesn't have enough 'power' to strip all unused packages and functions.
Is there any directive I can use to forbid the import of certain packages. I mean built-in packages right now. I'm using IntelliJ IDEA and it doesn't allow me to change anything in the Dart default setup.
UPD: Tried to use
import 'dart:html' show querySelector, Element
to import only that method and class, but file size is still 182kb.
The only solution I see for now is to make a few stripped versions of the default 'dart:html' package. The one without WebGL, SVG and some other features.
Because maybe Dart compiler works good, but there is just some methods and classes that I don't use, but the code uses. Like.. the initial package methods checking if some elements are SVG or something like that.
There is a tool for analyzing the output of a dart2js build, especially for references and dependencies. Just tested and gave a better overview in my case.
https://github.com/dart-lang/dump-info-visualizer
hosted :
https://dart-lang.github.io/dump-info-visualizer/
Build with option --dump-info
https://webdev.dartlang.org/tools/dart2js#options
Even when you don't import anything you will get some minimal output size. Dart provides a lot of features like classes with inheritance and mixins (and a lot more) and dart2js output contains code that implements these features.
This is like adding a JS library like jQuery.
Therefore main() {} will already result in an output size of several dozen kb. Adding another line of code probably will only add a few additional bytes.
pub build by default does tree-shaking and minifications, therefore no additional options are required.

dojo js library + jsdoc -> how to document the code?

I'd love to ask you how do the guys developing dojo create the documentation?
From nightly builds you can get the uncompressed js files with all the comments, and I'm sure there is some kind documenting script that will generate some html or xml out of it.
I guess they use jsdoc as this can be found in their utils folder, but I have no idea on how to use it. jsDoc toolkit uses different /**commenting**/ notations than the original dojo files.
Thanks for all your help
It's all done with a custom PHP parser and Drupal. If you look in util/docscripts/README and util/jsdoc/INSTALL you can get all the gory details about how to generate the docs.
It's different than jsdoc-toolkit or JSDoc (as youv'e discovered).
FWIW, I'm using jsdoc-toolkit as it's much easier to generate static HTML and there's lots of documentation about the tags on the google code page.
Also, just to be clear, I don't develop dojo itself. I just use it a lot at work.
There are two parts to the "dojo jsdoc" process. There is a parser, written in PHP, which generates xml and/or json of the entirety of listed namespaces (defined in util/docscripts/modules, so you can add your own namespaces. There are basic usage instructions atop the file "generate.php") and a Drupal part called "jsdoc" which installs as a drupal module/plugin/whatever.
The Drupal aspect of it is just Dojo's basic view of this data. A well-crafted XSLT or something to iterate over the json and produce html would work just the same, though neither of these are provided by default (would love a contribution!). I shy away from the Drupal bit myself, though it has been running on api.dojotoolkit.org for some time now.
The doc parser is exposed so that you may use its inspection capabilities to write your own custom output as well. I use it to generate the Komodo .cix code completion in a [rather sloppy] PHP file util/docscripts/makeCix.php, which dumps information as found into an XML doc crafted to match the spec there. This could be modified to generate any kind of output you chose with a little finagling.
The doc syntax is all defined on the style guideline page:
http://dojotoolkit.org/reference-guide/developer/styleguide.html