stepTime and wantsSteps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

stepTime and wantsSteps

patrick.rein
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

Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

Nicolas Cellier
+1 go ahead!

Le ven. 14 déc. 2018 à 10:17, <[hidden email]> a écrit :
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



Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

Karl Ramberg
In reply to this post by patrick.rein
Isn't that 'testing' category for like querying the object/morph for properties? Like 'wantsSteps', isMorph etc.
So not for SUnit testing.

So maybe the category should be named something else to not confuse.

Cheers,
Karl


On Fri, Dec 14, 2018 at 10:17 AM <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

Bob Arning-2
In reply to this post by patrick.rein
fwiw in 3.2 they are in stepping and presenter:

('stepping and presenter' arrangeToStartStepping arrangeToStartSteppingIn: isStepping isSteppingSelector: start startStepping startStepping:at:arguments:stepTime: startSteppingIn: startSteppingSelector: step stepAt: stepTime stop stopStepping stopSteppingSelector: stopSteppingSelfAndSubmorphs wantsSteps)

On 12/14/18 4:11 AM, [hidden email] 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




Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

Bob Arning-2
In reply to this post by Karl Ramberg
I think the same and this is one of the issues with categories: they are slices along one axis. If you prefer a different axis, categories are often all wrong.

On 12/14/18 9:12 AM, karl ramberg wrote:
Isn't that 'testing' category for like querying the object/morph for properties? Like 'wantsSteps', isMorph etc.
So not for SUnit testing.

So maybe the category should be named something else to not confuse.

Cheers,
Karl


On Fri, Dec 14, 2018 at 10:17 AM <[hidden email]> 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



    



Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

patrick.rein
In reply to this post by Bob Arning-2
... welp ... and I felt smart looking back up to 3.3 :)

Thanks everyone for your feedback!
Patrick

>fwiw in 3.2 they are in stepping and presenter:
>
>('stepping and presenter' arrangeToStartStepping arrangeToStartSteppingIn: isStepping isSteppingSelector: start startStepping startStepping:at:arguments:stepTime: startSteppingIn: startSteppingSelector: step stepAt: stepTime stop stopStepping stopSteppingSelector: stopSteppingSelfAndSubmorphs wantsSteps)
>
>On 12/14/18 4:11 AM, [hidden email] 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
>
>
>--------------24109100560C657751E03E67--

Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

Chris Muller-3
In reply to this post by patrick.rein
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: stepTime and wantsSteps

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

FFI and macOS

Squeak - Dev mailing list
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

Reply | Threaded
Open this post in threaded view
|

Re: FFI and macOS

Eliot Miranda-2
Hi John!!

On Dec 15, 2018, at 8:10 AM, JOHN SARKELA via Squeak-dev <[hidden email]> 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:
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?

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.

2. 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.

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?

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

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.)

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%20OS/vm/sqMacUnixExternalPrims.c

I would be most appreciative if someone could shine some light on this topic.

So would I.

John Sarkela