February 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11232

by Marcus Denker

11232 ----- Issue 2064: Tests for Cull: Issue 2044: fix cycles Issue 1797: Object>>initialExtent (again) Issue 2070: hierarchy button DNU in the Browser Issue 1972: clean ResourceCollector, ResourceManager and ResouceLocator -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 24, 2010

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by StÃ©phane Ducasse

Since this is obvious that in a tree you do not get twice the same node I was wondering why in the first place a set was returned. So apparently I'm not the only to not know and I was then curious about the impact of the changes. I was more interested in the impact of the changes that its justification :) http://code.google.com/p/pharo/issues/detail?id=2071 Stef On Feb 24, 2010, at 9:33 AM, Nicolas Cellier wrote: > 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> this was not really my question :) I know that a tree does not twice the same node >> do you know when it changed in squeak or pharo and the reason? >> >> Stef > > I return the question: so why answer a Set ? > For multiple inheritance experiments or for some tools conveniency ? > > Nicolas > >> >> On Feb 23, 2010, at 11:02 PM, Nicolas Cellier wrote: >> >>> The single inheritance hierarchy is a Tree... >>> I don't see any interest in answering a Set. >>> Some tools might expect a Set... >>> If so, they just have to use withAllSubclasses asSet. >>> >>> If my own tool expect a LinkedList, I ain't gonna change the Kernel >>> library for my conveniency, or am I ? >>> >>> Nicolas >>> >>> 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Nicolas I remember that we discussed this point or a related one a while ago >>>> >>>> Squeak >>>> >>>> Point withAllSubclasses >>>> an OrderedCollection(Point) >>>> >>>> >>>> Pharo >>>> >>>> Point withAllSubclasses >>>> a Set(Point) >>>> >>>> Do you remember? >>>> I forgot? >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

[Pharo-project] Issue 2070: hierarchy button DNU in the Browser

by Pavel Krivanek

see http://code.google.com/p/pharo/issues/detail?id=2070 fix included -- Pavel

Feb. 24, 2010

Re: [Pharo-project] HelpSystem & Class comments

by StÃ©phane Ducasse

On Feb 24, 2010, at 9:55 AM, Torsten Bergmann wrote: > Crosspost squeak-dev/pharo-dev > > Andreas Raab wrote: >> a) Currently a book depends on the presence of HelpSystem (i.e., via >> subclassing). > > No, you are not forced to be in the "CustomHelp" hierarchy. > You can define an own hierarchy, directly as subclass of Object, whatever > (athough I would recommond CustomHelp as common superclass similar to > TestCase in SUnit) > > The standard builder ("HelpBuilder") is able to use a different root. > See HelpBuilder class>>buildFromRoot: and HelpBuilder>>defaultRoot. > > With HelpSystem-Core-tbn.16 I even allow to provide own builders. > To get the latest you can just load the baseline: > > (ConfigurationOfHelpSystem project version: '1.0-baseline') load > > > b) Typing in '' quotes is pretty insane when you quote text. > > I know, but this is annoying since you currently write it manually > using the browser and by adding methods yourself. Storing the > contents in method is just the vehicle - additional authoring > capabilities would help here in the future (an additional HelpEditor > beside the HelpViewer). Again you judged too early. > > I would also like to see some reactivation of Scamper code for > a more capable viewer/editor - since with a basic support for > simple markup we could catch two flies by providing in-image and > web-help with the same contents/source. > >> I'm not saying that comments are the only way by which HelpBooks should >> be created but I think that this should be one of the ways that >> HelpSystem directly supports. > > That's already there - Danny already added this for the help classes. > Just open the book "Help on Help" -> "HelpSystem API Documentation" > and subnodes after loading the latest baseline. > If you click on a class node you will see the class comment displayed > in the help (currently as ASCII). > > We may add a book "Reference" where you open two subbooks: > "By categories" and "By hierarchy" - displaying the classes > using categories or in their usual class hierarchy for browsing. > > > However: the main question to me is the kind of format we should > use: > > a) Wiki Style or similar > + easy to write > + easy to transform > - mostly non-standard > > With Maven the APT format is often used [1], Eclipse for instance > provides even editors, see [2] for screenshots) > But we also have Tiny wiki syntax somewhere on SqueakSource which > may be similar. > > b) real markup like HTML > + easy to put onto the web without tranformation > - we need to have more markup support > -/+ embedding of Smalltalk has to be done the W3C way, similar > to javascript <a href="smalltalk:..." > > c) specific format like Squeaks Text representation with textDoits, ... > - very Squeak specific and may not work in Pharo > - hard to put on the web > > I would like to see b) with a cleaned up Scamper code since > a general markup editor/viewer would be helpfull anyway and it would > be easy to publish stuff on the web. But looks like more work. > > There is also another HTML browser with markup and CSS now available > open source as MIT (WithStyle), see [3] and [4] for more info. > Maybe someone has a minute ;) why not using the same seaside html canvas api? > > Bye > T. > > [1] http://maven.apache.org/doxia/references/apt-format.html > [2] http://sourceforge.net/project/screenshots.php?group_id=193560 > [3] http://n4.nabble.com/ANN-HelpSystem-was-ProfStef-td1554685.html > [4] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&… > > > > > > > > > > > -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] Issue 1972 clean ResourceCollector, ResourceManager and ResouceLocator reopened

by StÃ©phane Ducasse

Tx! On Feb 24, 2010, at 12:15 PM, Pavel Krivanek wrote: > Hi, > > I reopened the issue 1972 because it caused an obsolete class instance > in Project current instVarNamed: #resourceManager > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by StÃ©phane Ducasse

I was thinking that if the changes are not too big, I would prefer to change for a good solution. Stef >>>>> Authorize - at any position in binary selectors (like VW 7.7) >>>>> See http://bugs.squeak.org/view.php?id=3616 >>>>> Address the problem of compiling 1@-2 with following strategy: >>>>> >>>>> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >>>>> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >>>>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>>>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>>>> >>>>> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >>>>> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. >>>> >>>> >>>> I was wondering what do we do with that kind of changes. >>>> Is it useful? >>>> what is the end user case? >>>> what are the binary operators that we could invent with -~- -| -@ >>>> nicolas do you have a case in mind? >>>> what VW people use it for? >>>> >>>> Now do we want this in pharo? >>>> What is the cost? >>>> Impact / broken code? >>>> >>> >>> Huh? I am always assumed that binary selectors parsed in greedy >>> manner, which means that if parser found the start of >>> binary selector, it scans forward for following characters which can >>> be part of selector, without exceptions, like '-' char.. >>> >> >> This is precisely the reason I want to change this Behaviour for long. >> It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity. >> The fact that VW did it influenced my decision to act. >> >>> so, >>> 1--2 should ALWAYS mean: MessageSend receiver: 1 selector: #'--' argument: 2 >>> >>> and if you want an unary minus, you should put the white space or braces: >>> 1 -- -2 >>> 1 -- (-2) >>> >> >> And this is precisely how things work now in trunk. >> Beside, I forbid (- 2) which was authorized more accidentally than >> intentionnally IMO. >> >> Nicolas >> > > Oups, wrote to fast ! > 1--2 now compiles 1 - (-2) for obvious backward compatibility reasons > (1@-2) in batch mode (you import or recompile code). > But it request disambiguation in interactive mode. > > If I would adopt Igor strategy that I like better, then I would break code. > I want smooth transition. > > Nicolas

Feb. 24, 2010

Re: [Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

by StÃ©phane Ducasse

Do you have an estimate of the code that you would break? Stef On Feb 24, 2010, at 9:14 AM, Nicolas Cellier wrote: > 2010/2/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/2/24 Igor Stasenko <siguctua(a)gmail.com>: >>> On 24 February 2010 09:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> After the lengthly discussion about the fact that Smalltalk implementation is a balkan region >>>> (cf "what Pharo/squeak do not parse 16rFF) >>>> >>>>> Authorize - at any position in binary selectors (like VW 7.7) >>>>> See http://bugs.squeak.org/view.php?id=3616 >>>>> Address the problem of compiling 1@-2 with following strategy: >>>>> >>>>> If compiler is non interactive, then compile with backward compatibility 1 @ (-2). >>>>> If compiler is interactive, propose a menu to disambiguate and insert a proper space. >>>>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>>>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>>>> >>>>> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >>>>> I didn't do anything to support this vicious Squeakism, and by now the semantics are change. >>>> >>>> >>>> I was wondering what do we do with that kind of changes. >>>> Is it useful? >>>> what is the end user case? >>>> what are the binary operators that we could invent with -~- -| -@ >>>> nicolas do you have a case in mind? >>>> what VW people use it for? >>>> >>>> Now do we want this in pharo? >>>> What is the cost? >>>> Impact / broken code? >>>> >>> >>> Huh? I am always assumed that binary selectors parsed in greedy >>> manner, which means that if parser found the start of >>> binary selector, it scans forward for following characters which can >>> be part of selector, without exceptions, like '-' char.. >>> >> >> This is precisely the reason I want to change this Behaviour for long. >> It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity. >> The fact that VW did it influenced my decision to act. >> >>> so, >>> 1--2 should ALWAYS mean: MessageSend receiver: 1 selector: #'--' argument: 2 >>> >>> and if you want an unary minus, you should put the white space or braces: >>> 1 -- -2 >>> 1 -- (-2) >>> >> >> And this is precisely how things work now in trunk. >> Beside, I forbid (- 2) which was authorized more accidentally than >> intentionnally IMO. >> >> Nicolas >> > > Oups, wrote to fast ! > 1--2 now compiles 1 - (-2) for obvious backward compatibility reasons > (1@-2) in batch mode (you import or recompile code). > But it request disambiguation in interactive mode. > > If I would adopt Igor strategy that I like better, then I would break code. > I want smooth transition. > > Nicolas > >>> >>>>> >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> 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

Feb. 24, 2010

[Pharo-project] Issue 1972 clean ResourceCollector, ResourceManager and ResouceLocator reopened

by Pavel Krivanek

Hi, I reopened the issue 1972 because it caused an obsolete class instance in Project current instVarNamed: #resourceManager Cheers, -- Pavel

Feb. 24, 2010

[Pharo-project] Issue 1797 Object>>initialExtent reopened

by Pavel Krivanek

Hi, I reopened the issue 1797 because it caused the deprecation warning while opening the FileBrowser. see: http://code.google.com/p/pharo/issues/detail?id=1797 -- Pavel

Feb. 24, 2010

Re: [Pharo-project] how to remove World?

by Mariano Martinez Peck

On Tue, Feb 23, 2010 at 6:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes this is a good idea. > May be the DummyUIManager should be by default in the system. > Can you open a ticket? > > Done: http://code.google.com/p/pharo/issues/detail?id=2069 > Stef > > > I think that maybe it is a good idea to use the DummyUIManager and the > MorphicUIManager from Pavel MinimalImage. > > > > We can put those classes in a repository called PharoMinimal or something > similar. Then, you will be able to load both classes, run your image > headless and before, evaluate something to set those classes as the current. > > > > Just an idea... > > > > On Tue, Feb 23, 2010 at 10:18 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > this is a really good experiment > > please continue > > and let us know the results. > > Stef > > On Feb 22, 2010, at 8:21 PM, Esteban Lorenzano wrote: > > > > > I tried by starting pharo with a script: > > > > > > Project uiProcess suspend. > > > Smalltalk > > > snapshot: true > > > andQuit: true. > > > > > > ...and the processing stop working after the #suspend (no > > > snapshot:andQuit: happens :( ) > > > > > > On 2010-02-22 13:43:05 -0300, Lukas Renggli > > > <renggli(a)gmail.com> said: > > > > > >>> Is that also necessary for a headless Pharo/Squeak? > > >> > > >> No, it is not necessary. It saves a few CPU cycles because the event > > >> polling stops, the #step methods on the visible morphs are not called > > >> anymore, and the display is not updated any longer. > > >> > > >> Programmatically you can still do everything (headless or > > >> non-headless). For example you can open morphs and move them around, > > >> you just won't see a change on the screen. Code that have some > > >> interaction with the GUI thread (like the debugger) might deadlock (or > > >> hang) the system. > > >> > > >> Lukas > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010