- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo and XML

by Serge Stinckwich

On Wed, May 27, 2009 at 9:35 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > Hi Torsten, > > The work done by Michael is excellent. The parser works pretty well, > even on big XML files. There is currently no support for XPath > unfortunately. Pastell by Giovanni is a first step, but most of the > test are red. I plan to put some work on Pastell in a few days. We > could do it together if you wish. > > XMLParserTest is a collection of simple and small tests that run out > of the box. No need of external files as the XML testing package > requires as far as I remember. Regarding XML, Julien Bourdon developped some support for RDF : http://www.squeaksource.com/Rikaiko.html -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

May 28, 2009

Re: [Pharo-project] Issue 832

by Schwab,Wilhelm K

Henry, I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Wednesday, May 27, 2009 5:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote: Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference... I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant> Cheers, Henry On 27.05.2009 19:44, StÃ©phane Ducasse wrote: Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote: Performance of UI seems poor after 832 integration. http://code.google.com/p/pharo/issues/detail?id=832 Regards, Gary _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 27, 2009

Re: [Pharo-project] ScriptLoader>>loadMetacello

by Dale Henrichs

What I would add is that there is a functional prototype (alpha version) available now that is being experimented with a bit. If you've got a particular set of package management/version/configuration problems that you're struggling with right now, I'd be interested in hearing about your particular problems, so I can see if there is a way of solving the problem with Metacello. I've gotten very useful feedback so far and plan on rewriting the system based on that feedback. So as it stands there is gap between what the prototype actually does today and what it will do after the rewrite... I am hopeful that the I will have a useful system a month from now and documentation would naturally follow. Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | No real documentation for now, only email exchanges. Metacello | currently works at top of MC1 and using MC2 should not be a problem. | It is still early work, but looks promising. Dale is putting a great | | energy into it. I am experimenting with few projects I am familiar | with. I will send a report to this mailing list in a few days time. | | Cheers, | Alexandre | | | On 27 May 2009, at 16:10, Mariano Martinez Peck wrote: | | > Ahh okok. Is this documented somewhere? For example, advantages it | | > has compared to standard MC ? or against MC 2. Features? is it | > stable or is still in development phase ? | > | > thanks! | > | > Mariano | > | > On Wed, May 27, 2009 at 7:06 PM, Alexandre Bergel | > <alexandre(a)bergel.eu> wrote: | > A version management system built at the top of Monticello by Dale | > Henrichs from Gemstone. It is a bit early to say whether it will | gain | > a large adoption in Pharo or not. But one single method does not | hurt | > much I think | > | > Dale, are you member of Pharo? | > | > Cheers, | > Alexandre | > | > | > On 27 May 2009, at 15:59, Mariano Martinez Peck wrote: | > | > > hey what's Metacello ? | > > | > > On Wed, May 27, 2009 at 6:55 PM, Alexandre Bergel | <Alexandre.Bergel(a)inria.fr | > > > wrote: | > > Name: ScriptLoader-Alexandre_Bergel.877 | > > Author: Alexandre.Bergel | > > Time: 27 May 2009, 3:43:22 pm | > > UUID: 84df91c2-2efc-4cfd-8f0a-d566e9e05f73 | > > Ancestors: ScriptLoader-stephane_ducasse.876, ScriptLoader- | > > Alexandre_Bergel.861 | > > | > > - minor refactoring | > > - added loadMetacello | > > | > > ISSUE 850 | > > | > > Waiting in PharoInbox | > > | > > 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 | > > | > > _______________________________________________ | > > Pharo-project mailing list | > > Pharo-project(a)lists.gforge.inria.fr | > > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > 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 | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 27, 2009

Re: [Pharo-project] Issue 832

by Henrik Sperre Johansen

Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote: > Yes, rollbacking probably is the safest choice, > As I implied in the mail, this was really meant as a experimental > effort, to see if people on slower machines noticed the effects I was > (pre)anticipating. > I really don't see how an extra intersect: per Morph (containing > submorphs) can make such a big difference... > > I'll definately post another update sometime in the future, I don't > know when I'll have to look into it though. > <rant> > To me, the way it is right now seems unacceptable, there's really no > reason to write a "smart" drawOn: routine for morphs that are likely > to end up as a subMorph (saaaay, the TextMorph which I started > investigating in the first place), as they have to redraw the entire > area anyways. > This leads to a bad cycle in morph development; > "As long as at minimum the area we want to redraw is marked as, it's > fine. There's no performance gain from reporting a more accurate area > anyways". > So you end up with "sloppy" damage rects for new morphs, which leads > to more to fix if it IS changed, and slower performance for those whom > redrawing the entire area rather than a subsection IS expensive. > </rant> > > Cheers, > Henry > > > On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >> Thanks for reporting. >> Henrik? >> I could rollback the changes. >> >> Stef >> >> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >> >> >>> Performance of UI seems poor after 832 integration. >>> >>> http://code.google.com/p/pharo/issues/detail?id=832 >>> >>> Regards, Gary >>> >>> _______________________________________________ >>> 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

May 27, 2009

Re: [Pharo-project] Issue 832

by Henrik Sperre Johansen

Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference... I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant> Cheers, Henry On 27.05.2009 19:44, StÃ©phane Ducasse wrote: > Thanks for reporting. > Henrik? > I could rollback the changes. > > Stef > > On May 27, 2009, at 6:25 PM, Gary Chambers wrote: > > >> Performance of UI seems poor after 832 integration. >> >> http://code.google.com/p/pharo/issues/detail?id=832 >> >> Regards, Gary >> >> _______________________________________________ >> 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 > > >

May 27, 2009

Re: [Pharo-project] SLICE-RelicensingPart1

by Alexandre Bergel

I agree with what has been previously said. However, I think there is a fundamental difference between getting en error: 'Character code point ranges between 1 and 256 only' and 'subscript is out of bound'. Currently, CharacterTable has 256 slots. Maybe an initialization has to be done or something, but if you provide a value > 255, then you will get an error. Alexandre On 27 May 2009, at 17:26, Gabriel Cotelli wrote: > Yes, but if "value:" cannot lookup in the table uses some extended > character set... > > I think the negative check mut be done... about the > 255 I'm not > sure... > > On Wed, May 27, 2009 at 3:42 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > > Please remove the upper limit, I think this was a > > pre-internationalization method which should have been updated but > was > > not because not used. > > But CharacterTable is an array of 256 characters long. > > Alexandre > > > > > > > 2009/5/27 Alexandre Bergel <alexandre(a)bergel.eu>: > >> Yes, with a negative argument. > >> Adding the check: > >> (0 > integer or: [255 < integer]) > >> ifTrue: [self error: 'parameter out of range 0..255']. > >> is probably enough. > >> Alexandre > >> > >> > >> On 27 May 2009, at 08:27, Gabriel Cotelli wrote: > >> > >> The ANSI Specification doesn't mention anything about that the > >> integer must > >> be in some range... the only thing that expects is that (Character > >> codePoint: x) codePoint = x .... > >> > >> anyway... I can add the verification... but that's not specified in > >> the > >> ANSI... anybody knowns some senders of this? I checked Pharo-Dev > >> and found > >> none.. maybe in the Web Image? > >> > >> Alexandre, how you obtain an error using value: ? given a negative > >> argument? > >> I tried with values greater than 255 and works in my image... > >> > >> Tonight I check that > >> > >> 2009/5/27 Alexandre Bergel <Alexandre.Bergel(a)inria.fr> > >> I went through all the changes proposed by this slice. I am not > >> sure how > >> should I review the code, but here is my try: > >> - the new version of Character class>>codePoint: anInteger seems to > >> have a > >> different behavior: > >> The old (current) code is > >> codePoint: integer > >> "Return a character whose encoding value is integer." > >> #Fundmntl. > >> (0 > integer or: [255 < integer]) > >> ifTrue: [self error: 'parameter out of range 0..255']. > >> ^ CharacterTable at: integer + 1 > >> The new one is: > >> codePoint: anInteger > >> "Just for ANSI Compliance" > >> ^self value: anInteger > >> value: anInteger > >> "Answer the Character whose value is anInteger." > >> anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. > >> ^ CharacterTable at: anInteger + 1. > >> At the end an error is raised, but this is not the same. > >> Was this review useful? > >> 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 > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> 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 > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 27, 2009

Re: [Pharo-project] allObjectsDo: broken

by Lukas Renggli

I played a bit with it. I came up with the following quick fix, but probably Eliot has a better solution. I find that code quite fragile anyway, if you instantiate an object in your enumeration block your lost (that was already the case before) ... allObjectsDo: aBlock "Evaluate the argument, aBlock, for each object in the system excluding SmallIntegers." | object | object := self someObject. [0 == object] whileFalse: [ (object class == MethodContext and: [ object closure == aBlock ]) ifFalse: [ aBlock value: object ]. object := object nextObject] On Wed, May 27, 2009 at 10:53 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > SystemNavigation default allObjectsDo: [ :e Â ] > > ...never terminates. At least since this is broken since #10268cl. > Version #10263 was still working. > > The suspect are new closures (I guess, creating new context instances > while iterating over all objects)... > > http://code.google.com/p/pharo/issues/detail?id=851 > > Adrian > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

May 27, 2009

Re: [Pharo-project] How To build exupery?

by Marco Schmidt

Is it possible to build exupery + alienffi (under linux and win32)? I wrapped my head trying to build a new vm to make some progress using libcurl ... Marco Schmidt 2009/5/27 Bryce Kampjes <bryce(a)kampjes.demon.co.uk> > On Wed, 2009-05-27 at 20:39 +0200, Giuseppe Luigi Punzi Ruiz wrote: > > I downloaded but I suppose a make install or something like this is > > needed, to put all files and plugins in the rigth place. > > What are you trying to do? The VM's include a pre-built squeak > executable, just execute that. > > There's also some source tarballs but they aren't recommended because > most people should either build from VMMaker (real source) or use a > pre-compiled VM. I supply the source packages because they were asked > for and there are a few legitimate uses for them. > > Bryce > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 27, 2009

Re: [Pharo-project] SLICE-RelicensingPart1

by Gabriel Cotelli

Yes, but if "value:" cannot lookup in the table uses some extended character set... I think the negative check mut be done... about the > 255 I'm not sure... On Wed, May 27, 2009 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Please remove the upper limit, I think this was a > > pre-internationalization method which should have been updated but was > > not because not used. > > But CharacterTable is an array of 256 characters long. > > Alexandre > > > > > > > 2009/5/27 Alexandre Bergel <alexandre(a)bergel.eu>: > >> Yes, with a negative argument. > >> Adding the check: > >> (0 > integer or: [255 < integer]) > >> ifTrue: [self error: 'parameter out of range 0..255']. > >> is probably enough. > >> Alexandre > >> > >> > >> On 27 May 2009, at 08:27, Gabriel Cotelli wrote: > >> > >> The ANSI Specification doesn't mention anything about that the > >> integer must > >> be in some range... the only thing that expects is that (Character > >> codePoint: x) codePoint = x .... > >> > >> anyway... I can add the verification... but that's not specified in > >> the > >> ANSI... anybody knowns some senders of this? I checked Pharo-Dev > >> and found > >> none.. maybe in the Web Image? > >> > >> Alexandre, how you obtain an error using value: ? given a negative > >> argument? > >> I tried with values greater than 255 and works in my image... > >> > >> Tonight I check that > >> > >> 2009/5/27 Alexandre Bergel <Alexandre.Bergel(a)inria.fr> > >> I went through all the changes proposed by this slice. I am not > >> sure how > >> should I review the code, but here is my try: > >> - the new version of Character class>>codePoint: anInteger seems to > >> have a > >> different behavior: > >> The old (current) code is > >> codePoint: integer > >> "Return a character whose encoding value is integer." > >> #Fundmntl. > >> (0 > integer or: [255 < integer]) > >> ifTrue: [self error: 'parameter out of range 0..255']. > >> ^ CharacterTable at: integer + 1 > >> The new one is: > >> codePoint: anInteger > >> "Just for ANSI Compliance" > >> ^self value: anInteger > >> value: anInteger > >> "Answer the Character whose value is anInteger." > >> anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. > >> ^ CharacterTable at: anInteger + 1. > >> At the end an error is raised, but this is not the same. > >> Was this review useful? > >> 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 > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> 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 > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

May 27, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by StÃ©phane Ducasse

> Hi. > I recently download the new 10318 development image and it seems the > OBTextSelection>>isClassNode MNU is not fixed yet. > (See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html) > I just want to remind it for you to fix it because it would be a > really pity to release a version with such a silly error. > Thanks and excellent work Yes I used the dev version in a lecture and we could get the menu working :) Stef

May 27, 2009