- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] [ANN] DTrace for Squeak/Pharo

by Adrian Lienhard

Hi John, DTrace on my unix VM thinks it does not know ioShowDisplayOnWindow (I guess because I use X11 display). With a Mac VM I it works. To trace ioShowDisplayOnWindow you don't need a dedicated probe (and hence no specialized VM). The DTrace "pid" provider allows you to trace any function entry (and return): pid$target::ioShowDisplayOnWindow:entry { printf("%s'%s\n", probemod, probefunc); } Cheers, Adrian On May 11, 2010, at 19:03 , John M McIntosh wrote: > Ah, nice, yes very nice. > > One interesting one to have a probe for would be ioShowDisplayOnWindow so one can understand how much screen drawing goes on. > > On 2010-05-11, at 12:13 AM, Adrian Lienhard wrote: > >> >> Now there's also a DTrace provider for the Squeak VM: >> >> http://www.adrian-lienhard.ch/blog?dialog=smalltak-meets-dtrace >> >> DTrace is a powerful, kernel-based dynamic tracing framework. With the new provider one can analyze the execution of Pharo/Squeak applications. >> >> My post is an introduction that should get you quickly started. I've attached a pre-compiled VM for OS X. >> >> Hope you like it :) >> >> Cheers, >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

May 12, 2010

Re: [Pharo-project] I would like to kill some tests

by Igor Stasenko

On 11 May 2010 23:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 11, 2010, at 9:34 PM, Alexandre Bergel wrote: > >>> testMetaclassSuperclass >>> Â Â Â "self run: #testMetaclassSuperclass" >>> >>> Â Â Â self assert: Dictionary class superclass == Set class. >>> Â Â Â self assert: OrderedCollection class superclass == SequenceableCollection class. >> >> What is the important is the metaclass relationship, and not really the fact that Dictionary is a subclass of Set. >> I think this is better: >> Â Â Â self assert: Dictionary class superclass == Dictionary superclass class. >> Â Â Â self assert: OrderedCollection class superclass == OrderedCollection superclass class. > > ok > but do you think that the system would work if such test would not work? > I dont quite understand, what this test testing. Yes, in ST-80, a class inheritance chain and metaclass inheritance chain must go in parallel. But there's nothing in VM (to my knowledge), which prevents you from sidestepping from this convention. This means, that a system may work even if such test will fail. I made my own experiments with it , by creating a prototype-based framework , and along with existing prototypes implementation, it serves as a proof, that its not critical for a system to organize your behaviors strictly only in such way(s). > >>> I would rewrite the test as: >> >> testSuperclass >> Â Â Â "self debug: #testSuperclass" >> >> Â Â Â | s b | >> >> Â Â Â s := OrderedCollection new. >> Â Â Â b := [:cls | cls ifNotNil: [s add: cls. b value: cls superclass] ]. >> Â Â Â b value: OrderedCollection. >> >> Â Â Â self assert: OrderedCollection allSuperclasses = s allButFirst. >> Â Â Â self assert: OrderedCollection withAllSuperclasses = s. >> >> You even test #withAllSuperclasses in that case. > > this one is more interesting > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 12, 2010

Re: [Pharo-project] [Metacello] Fwd: Metacello questions

by Dale Henrichs

----- "Andreas.Raab" <andreas.raab(a)gmail.com> wrote: | 5) Bootstrapping Metacello? | | I found that most of the ConfigurationsOfXXX include some code to | 'bootstrap' Metacello in some form. There appear to be variants on | the | code; is there a "canonical bootstrap method" that should be used? | There is a canonical bootstrap method that is documented here: http://code.google.com/p/metacello/wiki/EnsureMetacello But the best technique is to copy the class MetacelloConfigTemplate where all of the required methods are already implemented... For more information see my answer to Question #6 below. | 6) A standard Configuration template? | | The Metacello tutorial is very useful as far as the configuration | goes | but it falls short of getting into the details of what it means to | provide a 'working' configuration. Testing the configuration isn't | covered (is there a way to get back to a 'clean' state?); | bootstrapping | isn't covered; the meaning of #isMetacelloConfig, | #metacelloVesion:loads:, #lastMetacelloVersionLoad and several other | -seemingly random- methods that can be found on most -but not all- of | the configurations. There is no indication on what these do, if | they're | required, recommended, or optional. Is there some 'standard' | Configuration template that people can use to avoid guessing about | which | parts of the boilerplate to copy from some other configuration? There is a FAQ on creating a new Metacello configuration: http://code.google.com/p/metacello/wiki/FAQ#How_do_I_create_a_Metacello_Con… but unfortunately the instructions are buried within a series of workspaces in ProfStef ... a Pharo-only package:( I've just extracted the instructions and added the following link to the FAQ answer: http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration Hope this helps, Dale

May 11, 2010

Re: [Pharo-project] [Metacello] Fwd: Metacello questions

by Dale Henrichs

Andreas, Your 'self answers' all look good. | spec | package:'Foo' with:[spec requires: 'Bar']; | package:'Foo' with:[spec requires: 'Baz']; | | and | spec | package: 'Foo' with:[spec requires: #('Bar' 'Baz')]. are indeed equivalent. So the difference pieces of the spec can be included in different #for:do: blocks based on the platform. To take you a little bit into the internals...You will notice that all packages/projects/groups are named, so for each spec of a given name an ordered list of modifications are recorded while resolving the spec on a given platform. 1. all #version: pragmas (no import and therefore self-contained) are processed first 2. #version:import: pragmas are processed next (using the imported version as a starting point). 3. within a #version: or #version:import: method, the specs are processed in project attribute order (i.e., for Squeak -> #common, #squeakCommon, #squeak). 4. the individual statements in the #for:do: for a given attribute are processed in order. 5. there are 4 unique operations supported: - add - copy - merge - remove Once the initial processing is complete, the operations are collapsed to form the final named spec. The named specs are collected into the version .... The #add operation is used by the constructors with 'overrides' in their name. The #add operation replaces the named spec. The #copy operation is used the by the #project:copyFrom:with: constructor. Note that #copy requires that an #add/#merge operation proceeds it in it's list. The #merge operation merges it's items into the previous version of the named spec. Not that #merge is equivalent to #add if the name spec doesn't exist yet. Most of the constructors use the #merge operation. The #remove operation is used by the constructors with 'remove' in their name. The #remove operation removes it's from the previous version of the named spec. So you can imagine that as you traverse through an attribute list for a particular project, that each of the individual constructor statements for a named spec are processed in a very specific order with each of the #add, #copy, #merge, and #remove operations applied in order... Hope this helps, Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | On 5/6/2010 5:26 PM, Dale Henrichs wrote: | > I don't think I've completely answered your questions so we might | want to continue the dialog on this question.... | | We're getting close :-) Let me take my own questions and answer them | in | my own words to see if I understand the issues correctly: | | Q1: #includes: vs. #requires: | | If I understand correctly what you're saying then, in heavily | simplified | form, I'd say they're both dependencies, except that #requires: is | loaded before the package it relates to and #includes: afterwords. | Thus: | | spec package: 'B' with:[ | spec requires: 'A'. | spec includes: 'C'. | ]. | | will load A, B, and C in that order. One thing one can do with this is | | to have mutually dependent packages, for example if package Foo and | Bar | always must be loaded together (Foo before Bar) one would specify: | | spec package: 'Foo' with:[spec includes: 'Bar']. | spec package: 'Bar' with:[spec requires: 'Foo']. | | There is now no way by which Foo or Bar could be loaded without its | companion. Correct? | | Q2: Why is HelpSystem not loaded? | | A: That's a bug which I can work around by specifying either #version: | | or #versionString:. | | Q3: When exactly is HelpSystem loaded? | A: In the context of my configuration HelpSystem is loaded for two | reasons: a) because it's a dependency for WebClient-Help and b) | because | no 'default' group has been specified it would be loaded implicitly. | | Q4: How does one define dependencies that differ based on platform? | A: I'm not really sure about this. My understanding is that I could | use | #includes: to model the dependency in the "for: #pharo" branch, but | one | question that is still open is whether the following two expressions | are | equivalent: | | spec | package:'Foo' with:[spec requires: 'Bar']; | package:'Foo' with:[spec requires: 'Baz']; | | and | spec | package: 'Foo' with:[spec requires: #('Bar' 'Baz')]. | | Are these equivalent? | | Cheers, | - Andreas

May 11, 2010

Re: [Pharo-project] I would like to kill some tests

by Mariano Abel Coca

The fact is that in the case that this test fails, besides that most of the system won't work, at least you will have some hint on where could be the problem. Obviously it's only useful if you're playing with the vm. If we are going test this, (I don't know if we already have it) would be useful to test a basic message sending. And to have a testWellCompiledMethods (or something like that) that checks if all the methods are correctly compiled, e.g.: a method which instead of referencing the instance variable that says in it's source, references the next one. I think that something of that is actually implemented in SmallLint for VASmalltalk, but I may be wrong... This tests could be some sort of: "if this doesn't work, it's all FUBAR<http://en.wikipedia.org/wiki/FUBAR>" :) +1 to Alexandre's version. Cheers, Mariano. On Tue, May 11, 2010 at 5:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On May 11, 2010, at 9:34 PM, Alexandre Bergel wrote: > > >> testMetaclassSuperclass > >> "self run: #testMetaclassSuperclass" > >> > >> self assert: Dictionary class superclass == Set class. > >> self assert: OrderedCollection class superclass == > SequenceableCollection class. > > > > What is the important is the metaclass relationship, and not really the > fact that Dictionary is a subclass of Set. > > I think this is better: > > self assert: Dictionary class superclass == Dictionary superclass > class. > > self assert: OrderedCollection class superclass == > OrderedCollection superclass class. > > ok > but do you think that the system would work if such test would not work? > > > >> I would rewrite the test as: > > > > testSuperclass > > "self debug: #testSuperclass" > > > > | s b | > > > > s := OrderedCollection new. > > b := [:cls | cls ifNotNil: [s add: cls. b value: cls superclass] ]. > > b value: OrderedCollection. > > > > self assert: OrderedCollection allSuperclasses = s allButFirst. > > self assert: OrderedCollection withAllSuperclasses = s. > > > > You even test #withAllSuperclasses in that case. > > this one is more interesting > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2010

Re: [Pharo-project] I would like to kill some tests

by StÃ©phane Ducasse

On May 11, 2010, at 9:34 PM, Alexandre Bergel wrote: >> testMetaclassSuperclass >> "self run: #testMetaclassSuperclass" >> >> self assert: Dictionary class superclass == Set class. >> self assert: OrderedCollection class superclass == SequenceableCollection class. > > What is the important is the metaclass relationship, and not really the fact that Dictionary is a subclass of Set. > I think this is better: > self assert: Dictionary class superclass == Dictionary superclass class. > self assert: OrderedCollection class superclass == OrderedCollection superclass class. ok but do you think that the system would work if such test would not work? >> I would rewrite the test as: > > testSuperclass > "self debug: #testSuperclass" > > | s b | > > s := OrderedCollection new. > b := [:cls | cls ifNotNil: [s add: cls. b value: cls superclass] ]. > b value: OrderedCollection. > > self assert: OrderedCollection allSuperclasses = s allButFirst. > self assert: OrderedCollection withAllSuperclasses = s. > > You even test #withAllSuperclasses in that case. this one is more interesting

May 11, 2010

Re: [Pharo-project] Incremental garbage collection

by Alexandre Bergel

Thanks John, your slides are really good. Alexandre On 10 May 2010, at 12:41, John M McIntosh wrote: > http://www.smalltalkconsulting.com/papers/GCPaper/GCTalk%202001.htm > > see slides 46 & 47 > > You need to have a tenure event, or a full GC to move the youngStart pointer > past all previously allocated objects, thus promoting a previously allocated > object from new space into old space. > > There is btw a primitive I added many years back > primitiveForceTenure > > SystemDictionary>>forceTenure > > Understanding when and why you would want to use it is another question... > > > On 2010-05-10, at 9:02 AM, Igor Stasenko wrote: > >> On 10 May 2010 18:33, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: >>> Hi! >>> >>> The garbage collection offered by the Pharo VM has two divisions. One for >>> young objects, and another for old objects. I was wondering when a young >>> object become old? I start to have a pretty good idea for human beings, but >>> I am not so sure for Pharo objects. >>> Is it when the object survives its first garbage collection? >>> >> I'd say, whenever VM decides to change a youngStart pointer. >> Its quite sophisticated, and having a lot of quirks & preconditions. >> But after compaction (either incremental or full), it usually picks a >> free memory region which will serve as a space >> for newly created objects. After that, obviously, all objects, which >> survived GC treated as old ones. >> >> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

[Pharo-project] Overlapped calls via NativeBoost [Was: Re: Single threaded Pharo IDE?]

by Igor Stasenko

On 11 May 2010 21:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > If you give us "overlapped calls," we'll make a statue of you. Â I'll bring the chissels :) > So, start preparing them. :) I need a feature request for it. How to make it convenient and what protocol/api you thinking of to make such calls. I can describe the things, which we need under the hood for implementation: - first, we need to create a common 'Native thread' class, which uses a native routine which it will run in it. So, you can create a donzens of native threads, each having own native function, and may serve for various purposes, not just for overlapped calls - second , we need to add a bindings for native semaphores and mutexes (so, we could generate a native code which can wait on them). - for overlapped calls, we need a special thread routine which runs a loop of following: - waits for 'action' native semapore - loads the arguments on stack and calls native function - stores the result on some 'results buffer' - signals 'result ready' interpreter's semaphore now, at language side , to do an overlapped call, we need - push arguments on some 'overlapped call' buffer - store the function pointer to call etc. - signal the 'action' native semaphore, so our overlapped call worker thread may proceed with call - wait for 'result ready' semaphore - fetch the result - return result. I would say, that its not hard to implement, but first, we requires some infrastructure before we can do it, namely: implement a NativeThread, and NativeSemaphore > On sockets, I'm not terribly worried about the blocking part: what I don't want is for the whole image to go under because of mis-typed URL or something. Â In short, I'm worried about too much blocking, not the absense of it. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Monday, May 10, 2010 6:21 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Single threaded Pharo IDE? > > 2010/5/11 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Andrei >> Having do-its block the UI is a feature, especially since you can >> explicitly fork a new (Smalltalk) process to do the work.Â What is >> **NOT** acceptable (and I fear I will discover is "easy" to cause to >> happen) is for DNS and socket operations that have been forked to block the main thread. >> > someone still has to do that for you, i.e. wait for a completion of blocking operation. > >> Dolphin has a feature called overlapped calls that allow external >> functions to be executed on a new OS thread specifically to avoid >> hanging the entire image.Â There are restrictions and disclaimers even >> then, and the default behavior is to block the UI. >> > Btw, its good that you mentioned this feature. > Given that i have a full control, what happens with NativeBoost, i could create a native thread to serve for handling such 'overlapped' calls, and at image side, it will just put a process, which made a call into a waitable state, while other processes could still continue to run. > > >> Bill >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Andrei Stebakov >> Sent: Monday, May 10, 2010 5:31 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Cc: Adrian Lienhard >> Subject: Re: [Pharo-project] Single threaded Pharo IDE? >> >> >> >> 2010/5/10 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> >>> 2010/5/10 Andrei Stebakov <lispercat(a)gmail.com> >>>> >>>> >>>> I just started to use Pharo 1.0. So please bear with me since I may >>>> not fully understand the full concept of the IDE. Sometimes the >>>> whole IDE freezes indefinitely. >>> >>> Welcome ! we hope you enjoy ;) >>> >>>> >>>> So questions: >>>> 1) Looks like evaluating anything from the Workspace freezes the >>>> whole UI for the time of execution. Is it a bug or a feature? >>> >>> More or less. Pharo has a green thread implementation. I will tell >>> you what I understand. Green threads means, there is only ONE OS >>> thread, and then, internally (in Smalltalk) there exists their own >>> threads, scheduler, priorities, etc. The UI is just a process that is >>> running, with a certain priority. Go to the world menu, then "Tools" >>> -> "Process Browser". There you will see all the current processes >>> with their priorities. You can notice the UI process. >>> >> But you must agree that it still looks fishy when your whole UI blocks >> when you execute something lengthy (like new package install)... >> Well, if the majority of Pharo users think that it's OK who am I to argue? >> ;) >> >> >>> Â So...whatever you do here, it will be done inside that process. If >>> you do normal things, then yes, I guess the UI freezes. However, you >>> way want to launch another thread to do what you want and with a >>> lower priority than the UI. >>> >>> Do this test: open a workspace and a transcript. In the workspace, >>> evaluate: >>> >>> [ 1000 timesRepeat: [Transcript show: 'mariano'; cr] ] forkAt: >>> Processor userBackgroundPriority >>> >>> there, you will see that you are able to use the ide, while the block >>> of writing to Transcript is working "at the same time". >>> >>> Here the most important message is forkAt:Â Â Â . fork just fork the >>> block with the standard priority ("Processor activePriority"). If you >>> want to specify the priority, you have to use forkAt: >> >> Yes, the [ HTTPSocket httpGet: 'http://www.pharo-project.org/home'] forkAt: >> Processor userBackgroundPriority doesn't block the UI anymore... >> If it's the way to go, shouldn't we have a "special non-blocking" >> Workspace which does exactly this (or have an option to run your >> Workspace command with a background priority)? >> >>> >>> >>>> >>>> 2) Sometimes executing something freezes the UI indefinitely. Is >>>> there a way to cancel the operation (other than restarting the image)? >>>> Strangely in my case the IDE froze on evaluating HTTPSocket httpGet: >>>> 'http://www.pharo-project.org/home' >>>> >>> >>> Yes, Sockets are an example where sometimes they block the whole image. >>> Are you behind a proxy ? do you have a timeout error after a while ? >>> I have just tested and it also freezes for me in Mac OS. I have no idea. >>> Maybe other can help. >> >> If I execute HTTPSocket httpGet: 'http://www.pharo-project.org/home'. >> in a Workspace having a Transcript window open, I got a never-ending >> messages in the Transcript window like: >> "redirecting to http://www.cmsbox.com/errors/hostnotfound.html". >> Yes, I am behind a firewall, but other urls work with the same command. >> >> >>> >>> But yes, usually (sometimes it doesn't work) there is a combination >>> of keys that send a system interruption. Check this links: >>> >>> http://wiki.squeak.org/squeak/899 >>> http://wiki.squeak.org/squeak/1542 >>> >> Great! Alt-. works. >>> >>> BTW Adrian, I think this deserves a FAQ entry as it has been asked >>> several times. >>> >>> Cheers >>> >>> Mariano >>> >>>> >>>> Thank you, >>>> Andrei >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 11, 2010

Re: [Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)

by Alain Plantec

Le 11/05/2010 21:00, Mariano Martinez Peck a Ã©crit : > > > > Ok...but how can I do the following: there is a setting that in Core > has XXX value and I want to change it for the Dev image. yes, this is the case of #showUpdateOptionInWorldMenu, the values are different > Creating whole Style doesn't make sense as I only want to change one > setting. the advantage is that you have the UI to switch from one Style to another through the setting browser. The load method of your style class (as show in my previous mail) can contains few setting updates, only those that make sense for the dev. PharoDevSettingStyle>>load "set your default 1.1 preferences here" UITheme currentSettings fastDragging: true. WorldState showUpdateOptionInWorldMenu: false. > In addition, happens what you told me in this mail, and finally it is > difficult to manage I think: imagine today I create a Style and > tomorrow you create ore settings...do I need to update my style to > contemplate such setting ? if the desired value for the dev is the default one then no. Cheers Alain

May 11, 2010

Re: [Pharo-project] I would like to kill some tests

by Alexandre Bergel

> testMetaclassSuperclass > "self run: #testMetaclassSuperclass" > > self assert: Dictionary class superclass == Set class. > self assert: OrderedCollection class superclass == SequenceableCollection class. What is the important is the metaclass relationship, and not really the fact that Dictionary is a subclass of Set. I think this is better: self assert: Dictionary class superclass == Dictionary superclass class. self assert: OrderedCollection class superclass == OrderedCollection superclass class. > > testSuperclass > "self run: #testSuperclass" > > | s | > self assert: Dictionary superclass == Set. > self assert: OrderedCollection superclass == SequenceableCollection. > > s := OrderedCollection new. > s add: SequenceableCollection. > s add: Collection. > s add: Object. > s add: ProtoObject. > > self assert: OrderedCollection allSuperclasses = s. I would rewrite the test as: testSuperclass "self debug: #testSuperclass" | s b | s := OrderedCollection new. b := [:cls | cls ifNotNil: [s add: cls. b value: cls superclass] ]. b value: OrderedCollection. self assert: OrderedCollection allSuperclasses = s allButFirst. self assert: OrderedCollection withAllSuperclasses = s. You even test #withAllSuperclasses in that case. Cheers, Alexandre > > > let me know what you think. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010