The reference page (use "toggle all") for Processing.js says the import command remains unimplemented. It references a page for the Java Processing language that describes a usage pattern like this: import processing.opengl.*;
I see at Github that some work on the import command was committed to the root in May. Does anyone know how this syntax works in a JavaScript environment? It's not clear what the path to the library file and its assets would be. Does this depend on the use of an environment variable similar to PYTHONPATH, or is there a directory naming convention?
Finally, would you care to discuss the relative merits of the import command (assuming it now works) versus the approach described here, and discussed briefly here on StackOverflow.
I was looking for a similar solution. Perusing the processing.js base code, I noticed that you can simply list multiple files in your datasrc declaration if you separate the file names with spaces. That kind of does what I want, although the result is multiple ajax calls to load the separate scripts.
<canvas id="test" datasrc="resources/pjs/Spot.class.pjs resources/pjs/cursor.pjs"></canvas>
I think a cleaner solution, given the current state of the processing.js code (as of July 2010) would be to simply build a server-side code concatenator a-la minify:
http://groups.google.com/group/minify
Related
I'm learning the Go language by following a tutorial. Not wanting to just blindly copying the examples, but understanding what's going on, I came accross the following puzzling case:
In the tutorial the import statement was written as:
import (
"fmt"
"example.com/greetings"
)
I first was surprised about the empty line between the two strings and thought that this is just following some style guide, and when creating my program, I wrote it simply as
import (
"fmt"
"example.com/greetings"
)
To my astonishment, when saving the code (I was using Visual Studio Code for editing at that time), the editor re-inserted the empty line, so I reckon that there must be a deeper reason for it.
I can't see any effect on my program, because when I later removed the line with a less presumptuous editor (nano), my program seemed to run the same as with empty line included ... but maybe I just missed something. So, my question, does this empty line have a deeper meaning, which I just don't grasp yet?
There is no significance to the empty lines in the import group.
Some editors (including VSCode) put standard library imports first, then add an empty line, and then other (3rd party imports). Also the 2 groups are sorted alphabetically.
Again, there is no significance to this other than being easier to read. It also comes handy if everyone formats imports like this, so there are no "meaningless" commits in a version system due to different import sorting / organizing.
Several organizations distribute variants of the same project, and we regularly pull changes from one another. It would be great if we could eventually merge code repositories and maybe, maybe have a common source tree managed by a consortium. However, each member would probably want the option of distributing their own variant without too much pain for customers in case there is trouble upstreaming changes required to work with newer products.
The project consists of three packages:
A library
A compiler executable that outputs go code that needs to import the library
A utility executable that uses code generated by #2 and links with #1
A big annoyance, when pulling changes back and forth, is gratuitous differences in import paths. We basically have to edit every version of import "github.com/companyA/whatever" to import "companyB.com/whatever". Of course these problems would go away with (gasp) relative import paths. If we resorted to such heresy, our compiler can just hard-code the absolute import path in generated code to isolate end users from the library's import path. It would also require only one gratuitous difference in the source trees (the line in the compiler that outputs import statements) rather than a bunch.
But anyway, I know relative import paths are bad - this is a tricky situation. I know this is similar to questions such as this or this, because the answer of just asking end users to create a directory called companyB.com and cloning something from companyA in there is just not going to fly for practical and political reasons.
I already know that go is not really good at accommodating this scenario, so I'm also not asking for a magic bullet to make go handle something it can't. Another thing that unfortunately won't fly is asking customers to curl whatever | sh, as this is viewed as too much of a liability (deemed "training customers to do dangerous things"). Maybe we could forego go get and have everyone clone to some neutral non-DNS-name under $GOPATH/src, but we would need to do this without a "flag day" in which code suddenly breaks if it's in the wrong place.
My question is whether anyone has successfully merged SDK-type projects with existing end users, and if so, how did you do it, what worked, and what didn't? Did you in fact avoid relative import paths or gnarly GOPATH hacking, and if so was it worth it? What mechanisms did you employ (environment variables, configuration files, .project-config files in the current working directory, abusing the vendor directory, code-generation packages that figure out their absolute import path at compliation time) to make this work smoothly? Did you just muddle through with a huge amount of sed or maybe gofmt -r? Are there tricks involving clever use of .gitattributes or go generate to rewrite import paths on checkout/checkin?
Merging them is pretty easy - cross-merge so that they all match, pick one (or create a new one) as the canonical source of truth, then migrate all references to the canonical import and make all future updates there.
The probablem arises here:
each member would probably want the option of distributing their own variant without too much pain for customers in case there is trouble upstreaming changes required to work with newer products
There's no particularly good way to do that without using any of the known solutions you've already ruled out, and no way to do that depending on your threshold for "too much pain".
Without knowing more about the situation it's hard to suggest options, but if there's any way that each company can abstract their portion out into a separate library they could maintain and update at their pace while using a smaller shared library with shared responsibility, that would likely be the best option - something like the model used by Terraform for its providers? Basically you'd have shared maintenance of a shared "core" and then independent maintenance of "vendor-specific" packages.
I am trying to add some support for D programming language to my vim config. For autocompletion I need to detect packages that are included. This is not exactly hard to do in simple case:
import std.stdio;
import std.conv;
My config:
set include=^\\s*import
set includeexpr=substitute(v:fname,'\\.','/','g')
Works great.
However, imports can have more complicated format, for example:
package import std.container, std.stdio = io, std.conv;
I was not able to find a simple way to parse this with include and includeexpr.
Also there is a second problem: import can have different access modifiers, like public and private. VIM scans included files recursively, import statements from included files are parsed too. But I need to distinguish between the file I am working with now and files which are scanned automatically: in current file all imports should be detected, but in other files only public import statements should add more files to the search.
Thanks for help.
Update
It's a shame if this can not be done without full parsers. Essentially, I only need two things:
ability to return an array from includeexpr instead of one file name
ability to distinguish between includes in current and other files
I think only way to do it reliably is to use complete parser and semantic analyzer. D Completion Daemon (https://github.com/Hackerpilot/DCD/tree/master/editors/vim ) has vim plugin and is not very resource-hungry.
Vim's include mechanism and 'includeexpr' are heavily influenced by the C programming language and only work for single files. You cannot return a list of filenames, so it won't be possible to support D's complex include mechanism with Vim. Use an IDE that is fully tailored to support the programming language, not a general-purpose text editor.
I just installed the scheme48 package from macports and have started experiencing. I was watching this youtube video, link here and was attempting to perform some of the examples. In the lecture the professor is running scheme on a Sun terminal. For example, I attempt to do '(first 473)' and get 'Error: undefined variable first'. Now, I'm assuming I haven't loaded the correct package / library or what ever it is called in scheme but am not sure what the syntax and library is. I believe that scheme48 and the scheme version on that sun terminal in the video are not the same and could be part of the problem.
So, what library do I need to use and how do I load it?
Those lecture notes are based on a book called Simply Scheme, and you can find the library code that is used in the book here. Specifically, you need simply.scm.
(But whether it is a good idea to have these kind of overloading functions is debatable. Specifically, note that first is used in a way that is different from many other languages.)
How can I include the procedures from one Netlogo file into another? Basically, I want to separate the code of a genetic algorithm from my (quite complicated) fitness function, but, obviously, I want the fitness reporter, which will reside in "fitness.nlogo", to be available in the genetic algorithm code, probably "genetic.nlogo".
If it can be done, how are the procedures imported, and the code executed? Is it like Python, where importing a module pretty much executes everything in the module, or like C/C++, where the file is blindly "joined"?
This may be a stupid question, but I couldn't find anything on Google. The Netlogo documentation says something about __includes, an experimental keyword that may do the trick, but there's not much explained there. No example either.
Any hints? Should I go with __includes? How does it work?
To include a file you use
__includes["libfile.nls"]
After adding this and pressing the “Check” button, a new button will appear next to the Procedures drop-down menu. There you can create and manage multiple source files.
The libfile.nls is just a text file that contains NetLogo code. It is not a netlogo model, which always end in .nlogo, as a NetLogo model contains a lot of other information besides the NetLogo code.
Including a file is the equivalent of just inserting all its contents at that point. In order to make it work in a way like reusable library files, one should create procedures which use agentsets and parameters as input variables to be independent of global definitions or interface settings.
The feature is documented in the NetLogo User Manual at http://ccl.northwestern.edu/netlogo/docs/programming.html#includes.
You can create a file libfile.nls and in the same folder create your main model model.nlogo.
After that, go to your model.nlogo and write:
__includes["libfile.nls"]
This file contains your reporters and procedures that you can call in your model.