Smalltalk › Squeak › Squeak - Dev

stepTime and wantsSteps

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

patrick.rein

stepTime and wantsSteps

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

Nicolas Cellier

Re: stepTime and wantsSteps

+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

Karl Ramberg

Re: stepTime and wantsSteps

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

Bob Arning-2

Re: stepTime and wantsSteps

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

Bob Arning-2

Re: stepTime and wantsSteps

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

patrick.rein

Re: stepTime and wantsSteps

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

Chris Muller-3

Re: stepTime and wantsSteps

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
>

K K Subbu

Re: stepTime and wantsSteps

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

Squeak - Dev mailing list

FFI and macOS

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

Eliot Miranda-2

Re: FFI and macOS

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