- Pharo-dev - lists.pharo.org

[Pharo-project] Confused about #isDirectory

by Sven Van Caekenberghe

Hi, I don't understand why '/tmp' asReference isDirectory. false '/private/tmp' asReference isDirectory. false '/Users/sven' asReference isDirectory. true '/Users/sven/Desktop' asReference isDirectory. true on Pharo 1.4 Mac OS X Cog VM. Anybody any idea ? Am I doing something wrong ? Thx, Sven

April 26, 2012

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

by Fernando Olivero

Thanks! I wasnt aware of that projec. Fernando On Thu, Apr 26, 2012 at 4:36 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Fernando olivero-2 wrote >> >> Seems it depends on XMLDOMParser? >> How can i install it? >> > > Â Â Â Â Gofer new > Â Â Â Â squeaksource: Â 'MetacelloRepository'; > Â Â Â Â package: Â 'ConfigurationOfXMLSupport'; load. > > Â Â Â Â (Smalltalk at: #ConfigurationOfXMLSupport) load. > > Sean > > -- > View this message in context: http://forum.world.st/Athens-SVG-was-Re-new-icon-set-tp4585623p4588733.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2012

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Frank Shearar

On 26 April 2012 03:35, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 25 Apr 2012, Levente Uzonyi wrote: > >> On Wed, 25 Apr 2012, Frank Shearar wrote: >> >>> On 20 April 2012 15:15, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>>> On 20 April 2012 03:51, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>> >>>>> On Thu, 19 Apr 2012, Frank Shearar wrote: >>>>> >>>>>> I found a serious bug in parsing numbers with negative exponents. It >>>>>> was completey broken, in fact, parsing 1e-1 as 10, not 1 / 10. Anyway. >>>>>> This version fixes that, and adds a bunch of tests demonstrating that >>>>>> number parsing will return rationals if it can. >>>>>> >>>>>> It's significantly slower than Squeak's SqNumberParser: >>>>>> >>>>>> Time millisecondsToRun: [100000 timesRepeat: [SqNumberParser parse: >>>>>> '1234567890']] => 466 >>>>>> >>>>>> Time millisecondsToRun: [100000 timesRepeat: [PPSmalltalkNumberParser >>>>>> parse: '1234567890']] => 32082 >>>>>> >>>>>> I've attached a MessageTally spying on the latter: I've not much skill >>>>>> in reading these, but nothing leaps out at me as being obviously >>>>>> awful. >>>>> >>>>> >>>>> >>>>> Didn't check the code, just the tally, and I think that >>>>> PPSmalltalkNumberParser(PPSmalltalkNumberGrammar)>>digitsBase: is >>>>> begging >>>>> for optimization. It's probably also the cause of the high amount of >>>>> garbage >>>>> which causes significant amount of time spent with garbage collection. >>>>> It's also interesting is that the finalization process does so much >>>>> work, >>>>> there may be something wrong with your image. >>>> >>>> >>>> Thanks for taking a look, Levente. >>>> >>>> I'd expect digitsBase: to dominate the running costs, given that we're >>>> parsing numbers. >>>> >>>> I do make a large number of throwaway "immutable" values with a >>>> Builder-like pattern... in PPSmalltalkNumberParser >> >>>> #makeNumberFrom:base:. That, I would imagine, could explain the >>>> garbage? >>>> >>>> If I may, what do you look for when reading the MessageTally? How do >>>> you tell, for instance, that there's excessive garbage production? >>>> That the incremental GCs take 7ms? (I'm reading Andreas' comments on >>>> http://wiki.squeak.org/squeak/4210 again.) >>> >>> >>> Levente, you're quite right: #digitsBase: has now been optimised even >>> more, reducing the time taken to run my benchmark >>> >>> MessageTally spyOn: [Time millisecondsToRun: [100000 timesRepeat: >>> [PPSmalltalkNumberParser parse: '1234567890']]] >>> >>> from ~32 seconds to ~16 seconds. (Memoising was the answer: >>> #digitsBase: is effectively a higher-order production and, like OMeta, >>> PPCompositeParser doesn't memoise those. A simple class var dictionary >>> solves that problem. >> >> >> Creating a new parser (PPSmalltalkNumberParser) takes quite a while, if >> you extract the parser creation, then you'll get closer to the performance >> limit of PetitParser: >> >> | p | >> p := PPSmalltalkNumberParser new. >> [ Time millisecondsToRun: [100000 timesRepeat: [p parse: '1234567890']] ] >> timeProfile. "==> 2594" >> >> There are still places where you create parsers on the fly, like >> PPSmalltalkNumberGrammar #>> number. These should be avoided. > > > I hacked the code a bit and got the following results: > > (1 to: 5) collect: [ :run | > > Â Â Â Â | p | > Â Â Â Â p := PPSmalltalkNumberParser new. > Â Â Â Â Smalltalk garbageCollect. > Â Â Â Â [ 1 to: 100000 do: [ :i | p parse: '1234567890' ] ] timeToRun ]. > > #(1198 1209 1225 1221 1204) > > It's ~6 times slower than SqNumberParser and I don't really think it can get > much closer to it. The mcz is available here: > http://leves.web.elte.hu/squeak/PetitSmalltalk-ul.62.mcz Ah excellent! Thanks! I see you eagerly initialise the number parsers where I'd gone the lazy/memoise route. Any performance implications I should be aware of, other than of course that eager initialisation means keeping 36 parsers around when maybe three or four of those will see regular use? (decimal, hex, binary, octal) For instance, I guess the running cost of Dictionary >> #at:ifAbsentPut: is greater than Array >> #at: because the latter just uses a primitive. Lastly, I added PetitSmalltalk-fbs.64 to http://ss3.gemstone.com/ss/Scratchpad-fbs/, based on your .62. It just normalises how signs work. Why I didn't write the exponent sign as a string from the beginning (like I do the number's sign), I don't know. At any rate, that normalises NumberMaker's API (it always takes Strings) and keeps the cheaper x = '-' rather than #($- '-') includes: x, and makes the tests all pass :) And now I'm going to add a feature request for SS3, asking for a RESTful interface to the repositories! frank > Levente > > >> >> >> Levente >> >> >>> >>> frank >>> >>>> frank >>>> >>>>> Levente >>>>> >>>>> >>>>>> >>>>>> frank >>>>>> >>>>>> On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 3 September 2011 19:35, Nicolas Cellier >>>>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think it is a good idea to have the number parser separate, >>>>>>>>>> after >>>>>>>>>> all it might also make sense to use it separately. >>>>>>>>>> >>>>>>>>>> It seems that the new Smalltalk grammar is significantly slower. >>>>>>>>>> The >>>>>>>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>>>>>>> source code of the collection hierarchy and does not especially >>>>>>>>>> target >>>>>>>>>> number literals runs 30% slower. >>>>>>>>>> >>>>>>>>>> Also I see that "Number readFrom: ..." is still used within the >>>>>>>>>> grammar. This seems to be a bit strange, no? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>>>>>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>>>>>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>>>>>>> particular, Squeak's Number doesn't get to see anything other than >>>>>>>>> a >>>>>>>>> well-formed token). >>>>>>>>> >>>>>>>>> It sounds like you're happy with the basic concept, so maybe I >>>>>>>>> should >>>>>>>>> remove the Number class >> #readFrom: stuff, see if I can't remove >>>>>>>>> the >>>>>>>>> performance issues, and resubmit the patch. >>>>>>>>> >>>>>>>>> frank >>>>>>>>> >>>>>>>> >>>>>>>> Yes, a NumberParser is essentially parsing, and this duplication >>>>>>>> sounds >>>>>>>> useless. >>>>>>>> The main feature of interest in NumberParser that I consider a >>>>>>>> requirement and should find its equivalence in a PetitNumberParser >>>>>>>> is: >>>>>>>> - round a decimal representation to nearest Float >>>>>>>> It's simple, just convert a Fraction asFloat in a single final step >>>>>>>> to >>>>>>>> avoid cumulating round off errors - see >>>>>>>> #makeFloatFromMantissa:exponent:base: >>>>>>>> >>>>>>>> The second feature of interest in NumberParser is the ability to >>>>>>>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>>>>>>> digitValue) loops, and replacing them with a log(n) cost. >>>>>>>> This would be a simple thing to implement in a functional language. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hopefully this won't offend your sensibilities too much :). It does, >>>>>>> in fact, use 10* loops - I wrote an experimental "front half * rear >>>>>>> half" recursion, which was slower in my benchmarks. >>>>>>> >>>>>>> This version has the grammar and parser doing no string->number >>>>>>> conversion at all. PPSmalltalkNumberMaker supplies a number of >>>>>>> utility >>>>>>> methods designed to stop one from making malformed numbers. It also >>>>>>> supplies a builder interface that the parser uses to construct >>>>>>> numbers. >>>>>>> >>>>>>> frank >>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>>>> Lukas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3 September 2011 16:51, Frank Shearar >>>>>>>>>>>> <frank.shearar(a)gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Lukas, >>>>>>>>>>>>> >>>>>>>>>>>>> I haven't :) mainly because I'm unsure where to put it - is >>>>>>>>>>>>> there >>>>>>>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or >>>>>>>>>>>>> what's >>>>>>>>>>>>> your preference? (How about an mcd between my merge and PP's >>>>>>>>>>>>> head?) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, >>>>>>>>>>>> ...) >>>>>>>>>>>> or >>>>>>>>>>>> attach it to a mail. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>>>>>>> separate class. That was really more to make what I'd done more >>>>>>>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but >>>>>>>>>>> perhaps >>>>>>>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>>>>>>> subgrammar. >>>>>>>>>>> >>>>>>>>>>> frank >>>>>>>>>>> >>>>>>>>>>>> Lukas >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Lukas Renggli >>>>>>>>>>>> www.lukas-renggli.ch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lukas Renggli >>>>>>>>>> www.lukas-renggli.ch >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >> >

April 26, 2012

[Pharo-project] ScriptLoader log

by Pavel Krivanek

Hi, as I see the ScriptLoader log was cleanded in 14432. Do we have full version somewhere? CI versions history is not so long. I found that keyboard input is not working in latest Reloaded Core image And I wanted to see when it happened. I saw it in results of latests Fuel tests but I expected it is somehow Fuel related, sorry Mariano ;-) Cheers, -- Pavel

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Sven Van Caekenberghe

+100 Thanks for putting it so clearly, Pavel. On 26 Apr 2012, at 10:19, Pavel Krivanek wrote: > Hi Chris, > > the planed changes in Pharo are not autotelic but in most cases they > are replacements of current buggy and unmaintainable subsytems. > We also use automatic or semiautomatic tools for shrinking and > modularization of the image. For example uMorphic is generated moslty > automatically with subsequent hand-made cleanup. The original Squeak > KernelImage was generated in the similar way. But we use the results > of this tools only as the supporting experimental sources of > information. > The goals of Cuis, Spoon and Pharo are very very similar. Everyone > wants to have the "small, clean, understandable Smalltalk system". But > Pharo development is more evolutional and modularity is more valuable > than small size. > In Smalltalk it is easy to dive into the system and create something > like Cuis, Spoon or KernelImage. But this projects were created by a > single person and the degree of adoption of this forks is low. You may > for example to take the current PharoKernel and withing few days to > create a perfect small and clean kernel. It is cool intelectual > adventure but to make it generally used stuff is another story. > > -- Pavel > > > On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> I see the "point" of Cuis as to have a small, clean, understandable >> Smalltalk system. It's a *general-purpose* system rather than one >> geared solely towards business. Pharo, at least to me, feels more >> like the Java ecosystem -- a platform aiming primarily toward business >> and generating plenty of marketing "buzz" with frameworks-of-the-month >> (such as the ones you listed). In Cuis, Smalltalk _is_ the framework >> and users are expected to build on that directly. >> >> In my view, Spoon is about letting the machine generate a small, >> vertical system from a larger, horizontal system. Pavel, Edgar and >> you all have been working on making a smaller system for years (good >> work); but I see the dream of Spoon as delegating that work to the >> machine, which will do it quickly and accurately. The question at the >> moment is whether that dream will be realized. Based on Craig's >> Squeak-Board candidacy announcement, I expect 2012 to be the year >> Spoon is born into mainstream-use at least in the Squeak community. >> >> >> >> On Tue, Apr 24, 2012 at 4:22 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> May I ask you why you talk about CUIS and Spoon/Pharo? >>> If you want to work with these systems we do not have any problems. >>> >>> We are working on Pharo since 2008. We deliver regularly, we are concerned with >>> making sure that you can do business with Pharo. And we will continue. >>> WE want to invent and build OUR future. >>> >>> We are spending a lot of time on making the system better. >>> - Fuel >>> - Athens >>> - OPAL >>> - Ghost >>> - Nautilus >>> - Ring >>> - NativeBoost >>> - Zinc >>> - HUGE amount of fixes >>> - Working on a core >>> - Writing a lot of documentation (yes guys) >>> to name a few. We are pushing like hell and getting there. >>> >>> We spent time building our vision and step by step building it. We are getting there. :) >>> Now I do not see the points related to spoon and cuis. I do not understand what is the point. >>> If people wants to collaborate with us this is ok now we do not count on that for our future. >>> >>> You do not have to reply. Just think about what you want to build and your future. Everybody >>> make choices and is free. >>> >>> Stef >>> >>> >>> >> >

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Norbert Hartl

Well said! Norbert Am 26.04.2012 um 10:19 schrieb Pavel Krivanek: > Hi Chris, > > the planed changes in Pharo are not autotelic but in most cases they > are replacements of current buggy and unmaintainable subsytems. > We also use automatic or semiautomatic tools for shrinking and > modularization of the image. For example uMorphic is generated moslty > automatically with subsequent hand-made cleanup. The original Squeak > KernelImage was generated in the similar way. But we use the results > of this tools only as the supporting experimental sources of > information. > The goals of Cuis, Spoon and Pharo are very very similar. Everyone > wants to have the "small, clean, understandable Smalltalk system". But > Pharo development is more evolutional and modularity is more valuable > than small size. > In Smalltalk it is easy to dive into the system and create something > like Cuis, Spoon or KernelImage. But this projects were created by a > single person and the degree of adoption of this forks is low. You may > for example to take the current PharoKernel and withing few days to > create a perfect small and clean kernel. It is cool intelectual > adventure but to make it generally used stuff is another story. > > -- Pavel > > > On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> I see the "point" of Cuis as to have a small, clean, understandable >> Smalltalk system. It's a *general-purpose* system rather than one >> geared solely towards business. Pharo, at least to me, feels more >> like the Java ecosystem -- a platform aiming primarily toward business >> and generating plenty of marketing "buzz" with frameworks-of-the-month >> (such as the ones you listed). In Cuis, Smalltalk _is_ the framework >> and users are expected to build on that directly. >> >> In my view, Spoon is about letting the machine generate a small, >> vertical system from a larger, horizontal system. Pavel, Edgar and >> you all have been working on making a smaller system for years (good >> work); but I see the dream of Spoon as delegating that work to the >> machine, which will do it quickly and accurately. The question at the >> moment is whether that dream will be realized. Based on Craig's >> Squeak-Board candidacy announcement, I expect 2012 to be the year >> Spoon is born into mainstream-use at least in the Squeak community. >> >> >> >> On Tue, Apr 24, 2012 at 4:22 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> May I ask you why you talk about CUIS and Spoon/Pharo? >>> If you want to work with these systems we do not have any problems. >>> >>> We are working on Pharo since 2008. We deliver regularly, we are concerned with >>> making sure that you can do business with Pharo. And we will continue. >>> WE want to invent and build OUR future. >>> >>> We are spending a lot of time on making the system better. >>> - Fuel >>> - Athens >>> - OPAL >>> - Ghost >>> - Nautilus >>> - Ring >>> - NativeBoost >>> - Zinc >>> - HUGE amount of fixes >>> - Working on a core >>> - Writing a lot of documentation (yes guys) >>> to name a few. We are pushing like hell and getting there. >>> >>> We spent time building our vision and step by step building it. We are getting there. :) >>> Now I do not see the points related to spoon and cuis. I do not understand what is the point. >>> If people wants to collaborate with us this is ok now we do not count on that for our future. >>> >>> You do not have to reply. Just think about what you want to build and your future. Everybody >>> make choices and is free. >>> >>> Stef >>> >>> >>> >> >

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Pavel Krivanek

Hi Chris, the planed changes in Pharo are not autotelic but in most cases they are replacements of current buggy and unmaintainable subsytems. We also use automatic or semiautomatic tools for shrinking and modularization of the image. For example uMorphic is generated moslty automatically with subsequent hand-made cleanup. The original Squeak KernelImage was generated in the similar way. But we use the results of this tools only as the supporting experimental sources of information. The goals of Cuis, Spoon and Pharo are very very similar. Everyone wants to have the "small, clean, understandable Smalltalk system". But Pharo development is more evolutional and modularity is more valuable than small size. In Smalltalk it is easy to dive into the system and create something like Cuis, Spoon or KernelImage. But this projects were created by a single person and the degree of adoption of this forks is low. You may for example to take the current PharoKernel and withing few days to create a perfect small and clean kernel. It is cool intelectual adventure but to make it generally used stuff is another story. -- Pavel On Wed, Apr 25, 2012 at 6:17 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > I see the "point" of Cuis as to have a small, clean, understandable > Smalltalk system. Â It's a *general-purpose* system rather than one > geared solely towards business. Â Pharo, at least to me, feels more > like the Java ecosystem -- a platform aiming primarily toward business > and generating plenty of marketing "buzz" with frameworks-of-the-month > (such as the ones you listed). Â In Cuis, Smalltalk _is_ the framework > and users are expected to build on that directly. > > In my view, Spoon is about letting the machine generate a small, > vertical system from a larger, horizontal system. Â Pavel, Edgar and > you all have been working on making a smaller system for years (good > work); but I see the dream of Spoon as delegating that work to the > machine, which will do it quickly and accurately. Â The question at the > moment is whether that dream will be realized. Â Based on Craig's > Squeak-Board candidacy announcement, I expect 2012 to be the year > Spoon is born into mainstream-use at least in the Squeak community. > > > > On Tue, Apr 24, 2012 at 4:22 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> May I ask you why you talk about CUIS and Spoon/Pharo? >> If you want to work with these systems we do not have any problems. >> >> We are working on Pharo since 2008. We deliver regularly, we are concerned with >> making sure that you can do business with Pharo. And we will continue. >> WE want to invent and build OUR future. >> >> We are spending a lot of time on making the system better. >> Â Â Â Â - Fuel >> Â Â Â Â - Athens >> Â Â Â Â - OPAL >> Â Â Â Â - Ghost >> Â Â Â Â - Nautilus >> Â Â Â Â - Ring >> Â Â Â Â - NativeBoost >> Â Â Â Â - Zinc >> Â Â Â Â - HUGE amount of fixes >> Â Â Â Â - Working on a core >> Â Â Â Â - Writing a lot of documentation (yes guys) >> to name a few. We are pushing like hell and getting there. >> >> We spent time building our vision and step by step building it. We are getting there. Â :) >> Now I do not see the points related to spoon and cuis. I do not understand what is the point. >> If people wants to collaborate with us this is ok now we do not count on that for our future. >> >> You do not have to reply. Just think about what you want to build and your future. Everybody >> make choices and is free. >> >> Stef >> >> >> >

April 26, 2012

Re: [Pharo-project] [update 2.0] #20011

by Sven Van Caekenberghe

On 26 Apr 2012, at 09:36, Marcus Denker wrote: > Yes, loaded on top of a seed image. > > For one, the Pharo image that we call "Pharo" needs to be what we use daily. Already in 1.4, most > people at RMoD use the Nautilus build, not 1.4 as is. And this is a problem, because getting the details right > is very hard if the artefact that we call Pharo is not used by anyone. > > So in some way, the "Pharo" of 2.0 is more like "Pharo Full" then the old 1.3 Core. And this is good, because > the Core will shrink until it is not usable in itself. Only this way it can be really core. +1 (And well said)

April 26, 2012

Re: [Pharo-project] pharo site is down

by Christoph Wysseier

Thx for reporting. We (Cmsbox) needed to replace our complete storage infrastructure which crashed randomly and without warning several times in the last weeks. During the restore and the replacement there were several service outages for a few minutes. Thank you for your understanding. Chris Am 25.04.12 21:44, schrieb StÃ©phane Ducasse: > tx. > this is strange may be there is power outage at bern > > Stef > > On Apr 25, 2012, at 9:24 PM, Francisco Garau wrote: > >> Apologies if somebody has already reported, but the Pharo site seems to be down >> >> http://www.pharo-project.org/ > >

April 26, 2012

Re: [Pharo-project] Concrete Type Inference

by Mariano Martinez Peck

On Thu, Apr 26, 2012 at 12:44 AM, Francisco Garau <francisco.garau(a)gmail.com > wrote: > The following code demonstrates the problem: > > EllipseMorph new > setBalloonText: 'hello world'; > openInWorld > > It's always the same behaviour regardless the text (even adding an extra > space at the end computes a box which is too big...) > > It happens in 1.4 and 2.0. I would like to try in previous Pharos, but > can't get hold of 1.3 or 1.2. Are those images available somewhere? > > http://www.pharo-project.org/pharo-download/release-1-3 http://www.pharo-project.org/pharo-download/release-1-2 > I am looking in BaloonMorph >> popUpForHand: > > - Francisco > > On 21 March 2012 14:44, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>wrote: > >> Thanks too, i spend two hours searching for it last night :P when i >> couldn't make work the image of Concrete Type in the latest vm. (i had to >> prove :P). >> >> >> 2012/3/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> >>> On Mar 21, 2012, at 10:34 AM, Francisco Garau wrote: >>> >>> > Hi - we are trying to port to Pharo some work I've done on Concrete >>> Type Inference back in 2001. >>> >>> Excellent! >>> We want that ;) >>> >>> > >>> > I've got a Squeak 2.8 image which is working, but having some minor >>> problems with the pluggins. >>> > >>> > Is there a public repository where old Squeak distributions are stored? >>> >>> normally on http://www.squeak.org/ >>> there is an ftp >>> http://ftp.squeak.org >>> >>> stef >>> >>> > >>> > Thanks, >>> > Francisco >>> >>> >>> >> > -- Mariano http://marianopeck.wordpress.com

April 26, 2012