April 2012 - Pharo-dev - lists.pharo.org

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

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

by Marcus Denker

On Apr 25, 2012, at 7:49 PM, Tudor Girba wrote: > Hi, > > I am a bit puzzled by the current trend of 2.0. > > Are these additions part of the image, or will they be loaded continuously on top of a seed image? > 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. Marcus -- Marcus Denker -- http://marcusdenker.de

April 26, 2012

Re: [Pharo-project] pharo site is down

by Carlo

Hi It may be only me but it seems as if http://book.pharo-project.org/ is down. > Proxy Error > > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request GET /. > > Reason: Error reading from remote server > Cheers Carlo On 25 Apr 2012, at 9:44 PM, StÃ©phane Ducasse wrote: 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] Editor focus & hotkeys

by Chris Muller

> Yeah, it's really challenging to figure out where your key presses are gonna go. Not only that, but it requires the human to do a fine-motor click just to -gain focus-. Most of Pharo's focus problems can be solved by simply flipping two preferences: Keyboard focus on mouse down ::: set it false (instead of true) Lose keyboard focus when mouse leave ::: set it true (instead of false) This will bring "power of pointing" to the hand. By default, pointing means *nothing* in Pharo -- only a click will cause anything to happen in the UI. But wouldn't it be nice to have a "mid-gesture", simply a gross twitch of the mouse to be associated with focus? It solves the issues you and I raised. If you have a Lenovo laptop (with trackpoint) its absolutely fantastic. Otherwise, it is a bit harder to get accustomed to at first because it will feel like a lot of back-and-forth between keyboard and mouse -- but the mouse gestures are quick and rough. Once accustomed, going back to a "click-for-focus" reveals how much extra energy that configuration requires to operate.

April 26, 2012

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

by Sean P. DeNigris

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 Levente Uzonyi

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 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

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

by Fernando Olivero

Seems it depends on XMLDOMParser? How can i install it? On Thu, Apr 26, 2012 at 3:30 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > NICE!!! Great work Igor! > > Fernando > > On Wed, Apr 25, 2012 at 7:59 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> .. and , of course, some screenshots for thirsty people ;)

April 26, 2012