where is processing.py's modules that are imported? - processing

I was reading one of the examples in processing.py, Arctangent. It has an import statement:
from eye import Eye
I cannot figure out where this 'eye' library that I'm importing from is located. I don't see it in the processing.py reference. I searched the filesystem under the processing-3.5.4/ subdirectory and cannot find any module named eye either.
The program works. But I wonder where these modules are, and where can I find a reference for them. I'm wondering now what else is available that I cannot see.

I failed to notice that the example had a second tab with the code to be imported. These aren't standard library modules.

Related

Is there a standard practice for splitting packages into modular components?

I'm working on a library with multiple layers of functionality. I want developers to be able to import only the parts they need, ie mylib-core, mylib-feature1, mylib-feature2, etc. Each lives in its own git repo. I'd also like to provide a simple mylib package which exposes a default set of functionality which is useful for developers new to the library. See d3.js version 4+ for something very similar to what I'm trying to accomplish.
The problems I've run into are
Apparently you can't share a package name between packages. This is a problem because it would be nice to import all the desired repos and then simply have everything available under the mylib name.
I don't see an obvious way to re-export functionality, in order to build the default mylib package.
Are there good solutions or a more idomatic go way to accomplish what I'm shooting for?
Answering your question, there is no idiomatic way of doing what you want. It is common in JavaScript to import a library and export its members without interference. This is not the case in Golang.
I advise you to host your whole library under a single repo, and split the functionality to packages. The Go compiler will only compile and use the imported packages.
And a tip for the future, Go is very different than almost any other language you previously know 😅

Should functions/constants/variables be exported or not in `package main`?

I'm developing a tiny project that has a single package main. AFAIK, best-practice for small Golang binary projects is to have all code in a single (main) namespace, so that's what I've done.
Just curious, within a package main, is it best practice to keep functions/constants/variables exported (MyFunction) or unexported (myFunction)?
Really it doesn't matter. main packages can't be imported so whether you export them or not doesn't matter in that regard.
However if you do export them then tools like golint will encourage you to document them so maybe that's a good reason to go ahead an export them.
The most important thing is to be consistent. I prefer to name un-exported items in package main starting with lowercase even though they can't be exported. This is because it's an additional hint that these entities aren't used outside their containing package. You don't need to know that the declaration is in main to know that the thing being declared is not used externally.

The procedure entry point interlockedcompareexchange#12 could not be located in the dynamic link library SDL2_ttf.dll

I was studying SDL2 with LazyFoo's tutorial, everything was ok before I came to import the SDL2_ttf library, I import this library into my vs2015 the same way as I import SDL2_image library, but it seems not to work...
When I tried to run the problem I wrote that contains the SDL2_ttf, I got an error window that shows the mistake The procedure entry point interlockedcompareexchange#12 could not be located in the dynamic link library libfreetype-6.dll, how can I fix it ?
Finally I fixed it, I just put all the .dll file into the vs working directory, then it works. I don't why other .dll can work as long as I set the path into where they are, but SDL2_ttf.dll can not...

Import ReactiveCocoa, or PromiseKit, or BrightFutures as sources?

I have an OSX project (xcode plugin) and I want to use the ReactiveCocoa paradigms in it (PromiseKit andBrightFutures` are the other implementations of the same paradigms so I need to import at least one from these 3 frameworks/libraries).
The problem is it seems impossible to import them as compiled frameworks into my project because it is plugin. In my project I used dispatch_async and dispatch_after functions only but their nested blocks look awful.
The only solution I found is import one from these frameworks as sources but I don't know how to detach their code. So could anybody help with this trouble? Or maybe are there any other similar libraries which are already represented as source files only?
Short Answer:
Use a dependency manager like Cocoapods or Carthage.
Longer Answer: You can do it manually, but even if you don't want to use any of those, you can look at the .podspec file and see how it's supposed to be used. For example BrightFutures.podspec says:
s.source_files = 'BrightFutures/*.swift'
s.dependency 'Result', '0.6.0-beta.6'
That means that you need to import all the .swift files inside the BrightFutures folder, and that it won't work unless you also import the files from another project called Result.
But please, just let the tools do that for you. You'll be happier. :)

Tracing source to binary

I'm trying to understand the way a particular package fits into a project I'm working on. I believe only a portion of this package actually makes it into the binary of the project, and I need to find out exactly which parts. Library functions from this package are called from many other places (i.e. several other packages depend on it).
I plan to build the project and distribute it. Is the only way to determine which source->binary files I'll distribute by looking at all of the headers in my dependent packages? Or is there a more clever way to approach this?
Thanks in advance,
You haven't given us much information to go on, but here's a method that will work: remove parts of the package and see if the project will still compile.
Use nm to unpack a static lib. This will list all the files and methods included in the lib.
You could also try using strings.
This displays strings that are defined in the binary.
Look through your source and see if the strings you define are in the library.
Something like gprof could also be used to see which methods are called by your executable.

Resources