I think they should both be in "updating".
But what is a "presenter"? I don't recognize that as a Morphic term at all... On Fri, Dec 14, 2018 at 3:17 AM patrick.rein@hpi.uni-potsdam.de wrote:
Hi everyone,
while going through the categorizes of Morphic I noticed (or re-discovered) the fact that stepTime and wantsSteps are both in the category 'testing'. While I figured out that this is the case at least since Squeak 3.3, I find this very odd. I would have expected both methods in the category 'stepping and presenter' to which they belong.
Are there any good reasons for keeping the methods in that category?
On that note: The 'testing' category of Morphic contains several other apparently misplaced methods such as #knownName, #renameTo, #renameInternal:. If no one feels strongly about the membership of these selectors in these categories, I will go ahead in a few days and recategorize them.
Bests Patrick
On 15/12/18 3:51 AM, Chris Muller wrote:
I think they should both be in "updating".
But what is a "presenter"? I don't recognize that as a Morphic term at all...
+1 for updating. I think Presenter comes from the Scratch/Etoys experiments - a PasteUpMorph like container that provides a scope for running Player scripts.
Regards .. Subbu
I’ve been fiddling about with FFI and have some macOS questions. Things on Linux work as expected. On macOS (Mojave) I am unable to resolve a dylib.
Questions: 1. Must the code be packaged as a bundle for FFI to find and load the code? If so, is there a standard method for wrapping the dylib? 2. Does the vm respect environment LD flags? 3. Must the library be in a location that is accessible to Squeak? If so, a simple sym link does not appear to work. Does the library have special requirements as to the location in the filesystem where it resides? 4. A simple c program can resolve and use the library via dl* calls. Does the vm use some other mechanism for finding and loading modules? (Yes, I have been lazy and not read the vm code.)
I would be most appreciative if someone could shine some light on this topic.
John Sarkela
Hi John!!
On Dec 15, 2018, at 8:10 AM, JOHN SARKELA via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I’ve been fiddling about with FFI and have some macOS questions. Things on Linux work as expected. On macOS (Mojave) I am unable to resolve a dylib.
Questions:
- Must the code be packaged as a bundle for FFI to find and load the code? If so, is there a standard method for wrapping the dylib?
No. Both bundles and dylibs work. I *think*, but am not sure, that bundles only work if they’re in .app/Contents/Resources but I’m not sure. The code is positively labyrinthine and not easy to read.
- Does the vm respect environment LD flags?
The VM uses dlopen and hence if dlopen respects the flags do does the VM, but otherwise there is no explicitly access to those environment variables. For example LD_LIBRARY_PATH is never fetched.
- Must the library be in a location that is accessible to Squeak? If so, a simple sym link does not appear to work. Does the library have special requirements as to the location in the filesystem where it resides?
I think the issue here is that the loading code does not check for or follow symlinks. I guess it should. There is a repository near you ;-). https://github.com/OpenSmalltalk/opensmalltalk-vm
- A simple c program can resolve and use the library via dl* calls. Does the vm use some other mechanism for finding and loading modules? (Yes, I have been lazy and not read the vm code.)
The dl* calls are wrapped in a labyrinthine enumeration over many directory paths. I’d love to see this code rewritten to be more comprehensible. See https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20O...
I would be most appreciative if someone could shine some light on this topic.
So would I.
John Sarkela
squeak-dev@lists.squeakfoundation.org