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

Re: [Pharo-project] Bug with RBParser

by Lukas Renggli

According to the ANSI standard integers do not support an exponent: integer ::= decimalInteger | radixInteger decimalInteger ::= digits digits ::= digit+ radixInteger ::= radixSpecifier 'r' radixDigits radixSpecifier := digits radixDigits ::= (digit | uppercaseAlphabetic)+ They even state explicitly that '10e10' is not a valid number token. Furthermore floating point numbers do not accept a different radix (or base) and thus are always written in decimal notation: float ::= mantissa [exponentLetter exponent] mantissa ::= digits '.' digits exponent ::= ['-']decimalInteger exponentLetter ::= 'e' | 'd' | 'q' Cheers, Lukas On Wed, Feb 11, 2009 at 11:34 AM, Gwenael Casaccio <mrgwen(a)gmail.com> wrote: > Hi, > > RBParser parseExpression: '2r100e2' > results : 400 should be : 16 > > Cheers, > Gwenael Casaccio > > _______________________________________________ > 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

Feb. 11, 2009

[Pharo-project] Bug with RBParser

by Gwenael Casaccio

Hi, RBParser parseExpression: '2r100e2' results : 400 should be : 16 Cheers, Gwenael Casaccio

Feb. 11, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

>>> Also, note, that you need only one instance of such tree in image . >>> You don't have to build this tree over and over again for each browser >>> window on screen :) >> In a way, yes. >> But then OB would basically do what the system itself should do, namely modeling >> packages. I would rather invest in a genuine package model in the system itself than >> let OB build its own persistent package model. A browser should by definition browse >> an existing model and not primarily create, maintain, and make persistently >> accessible a system's model. This would be like a shadow model to what the system >> otherwise uses, Sounds odd to me, although from a performance point of view it would >> make sense. >> > > Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to > model different data structures and they relations. Should we expect > from squeak/pharo to use same model? I think no. > So, even if some day we will have categories as first class objects in > system, you still will need to map them to own objects. yes, but that won't be problematic in terms of performance anymore when we can rely on an efficient package model. The traditional system browser not showing packages (no matter whether based on OB or the old Browser class) does not need to use caching or even provide its own persistent shadow system model. Instead it just provides a view on the system model, as it should be. Because what the browser does is really simple: It traverses a tree from packages (or class cats in case of the system browser) down to methods. There shouldn't be a huge overhead if the system model provides efficient access to the entities and its sub-entities (eg. transitions from packages to class cats, to classes, to extended classes, etc.). David

Feb. 11, 2009

Re: [Pharo-project] Problem with linux VM and Pharo

by Provoost, P (Paul)

It happens on OpenSolaris too.Squeak runs fine but Pharo crashes almost immediately. When you look into the source code of sqUnixMemory.c you find a comment in the beginning stating that the memory management here is tricky. If you have plenty of memory a workaround is using the -memory commandline option. The maximum seems to be 2047 (MB)... Maybe someone with enough knowledge (Ian P. ?) can look into this problem? Damien Cassou wrote: > Every 5 minutes or so, my VM crashes and prints: > > squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: > uxGrowMemoryBy: Assertion `newDelta >= 0' failed. > Aborted > > > I'm using Squeak VM from SVN. Does that happen to anyone else? > _____________________________________________________________ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _____________________________________________________________

Feb. 11, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

Then I'm not in favor to load files in workspace or saving contents to file. Workspace snippets are against classes. If you have a nice and fast snippets then you put it in a class and work a bit and you get an little object. And you can even version it Stef On Feb 10, 2009, at 3:49 PM, Keith Hodges wrote: > http://bugs.squeak.org/view.php?id=5669 > > I requested then implemented a reasonable API for opening Workspaces > on > strings and files. I now find that pharo has implemented incompatible > versions of the same. > > Workspace openContents: 'blah'. > > or > > Workspace new > contents: 'blah'; > label: 'Title'; > open. > > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

Where? When? Keith in the long run it would be nice that yu do not bash us systematically. Yes we have a different way of working but normally this is often by pure lack of time or information that we do not check what exist. Stef On Feb 10, 2009, at 3:49 PM, Keith Hodges wrote: > http://bugs.squeak.org/view.php?id=5669 > > I requested then implemented a reasonable API for opening Workspaces > on > strings and files. I now find that pharo has implemented incompatible > versions of the same. > > Workspace openContents: 'blah'. > > or > > Workspace new > contents: 'blah'; > label: 'Title'; > open. > > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2009

Re: [Pharo-project] another slice for popups cleaning and some questions

by HernÃ¡n Morales Durand

2009/2/8 Alain Plantec <alain.plantec(a)free.fr> > Hi all, > I've uploaded another slice for popup and co cleaning > (SLICE-MorePopUpAndCustomMenuCleaning-alain_plantec.1) > - it Removes last PopUpMenu references. > - it Removes some of CustomMenu uses (wherever it is possible to replace > it with a simpler UIManager dialog). > > I've three questions: > - EmphasizedMenu is never used, can we remove it ? > - MorphicUIManager is subclassed by PSUIManager which is now the > default UIManager. Several MorphicUImanager methods are > redefined in PSUIManager. So I guess one can simply remove > MorphicUIManager versions. Is it ok to do so ? (as an example, > #chooseDirectory:from:, in MorphicUIManager, the code is using FileList > but now we have the PSUIManager version) > - last unrelated question, I've also seen that ListParagraph is never > used, can we remove it ? ListParagraph was historically used by ListView (Minimal Morphic images) and PluggableListView>>list: , and you could find initialize references in SystemDictionary, FontSet, TextStyle, Preferences and possibly others. Let me know if you need help with this issue. Cheers HernÃ¡n > > > now I am about to see how to kill MVCMenuMorph > > cheers > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2009

Re: [Pharo-project] Workspace API

by Damien Cassou

What do you suggest? On Tue, Feb 10, 2009 at 3:49 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > http://bugs.squeak.org/view.php?id=5669 > > I requested then implemented a reasonable API for opening Workspaces on > strings and files. I now find that pharo has implemented incompatible > versions of the same. > > Workspace openContents: 'blah'. > > or > > Workspace new > contents: 'blah'; > label: 'Title'; > open. > > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 11, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Igor Stasenko schrieb: >> 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >>> >>>> But again, there is no excuse in doing this each time you need a tree. >>>> Thanks to system notifier we have a ways to determine when category >>>> tree needs to be rebuilt, so it can be built once and stay cached >>>> until user add/remove/rename category. >>> yes, right. Packages are cached for a long time and also their classes and extended >>> classes. And now also the class cats per package, which is a small share though. >>> But it's good to cache iy anyway. >>> >> >> Also, note, that you need only one instance of such tree in image . >> You don't have to build this tree over and over again for each browser >> window on screen :) > > In a way, yes. > But then OB would basically do what the system itself should do, namely modeling > packages. I would rather invest in a genuine package model in the system itself than > let OB build its own persistent package model. A browser should by definition browse > an existing model and not primarily create, maintain, and make persistently > accessible a system's model. This would be like a shadow model to what the system > otherwise uses, Sounds odd to me, although from a performance point of view it would > make sense. > Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to model different data structures and they relations. Should we expect from squeak/pharo to use same model? I think no. So, even if some day we will have categories as first class objects in system, you still will need to map them to own objects. > David > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] {Spam?} Re: "Real" packages.

by Travis Kay

Bill Schwab wrote: > Stef, > > Re Dolphin, class categories have long been of marginal use; I'll speak for myself on that but suspect others would agree. I am a Dolphin Pro, Squeak and Pharo users, I agree. Travis > Packages are of course extremely useful. Method categories are also quite useful, and Dolphin allows multiple categories to be assigned to a given method. Dolphin mixes virtual categories (computed by rules) with static ones maintained by the user (and serialized as part of packages). > > I can easily see where OB would get quite a speed boost out of it. > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > >>>> stephane.ducasse(a)inria.fr 2/10/2009 4:41:10 PM >>> >>>> > Alexandre implemented long time ago an hybrid model where both kind of > packages could coexist > and we should probably revive it for 1.1 > > Stef > On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > >> On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch >> >>> wrote: >>> >> So if we had real packages in Pharo as first class entities, OB >> would be much faster >> and simpler to maintain. Right now, OB models packages and class >> cats itself, has to >> take the information from both the Monticello's working copy >> managers and the >> SystemOrganizer. This is a mess and a huge pain, but what can we do. >> We should really invest in bringing real packages to Pharo. >> >> >> If you want "real" packages, I've implemented them in Squeak: >> >> http://gulik.pbwiki.com/Namespaces >> http://gulik.pbwiki.com/Packages >> >> The places the code is held, including a video and a Squeak image is >> linked from here: >> http://gulik.pbwiki.com/SecureSqueak >> >> I'm not interested in Pharo, but the code is there and is released >> under the MIT license if anybody else wants it. >> >> Gulik. >> >> -- >> http://people.squeakfoundation.org/person/mikevdg >> http://gulik.pbwiki.com/ >> _______________________________________________ >> 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 > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.20/1943 - Release Date: 02/10/09 07:20:00 > >

Feb. 10, 2009