- Pharo-dev - lists.pharo.org

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

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

by Fernando Olivero

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

Re: [Pharo-project] Downloading a file

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > Now, you are right that there should be some convenience method to make > that easier. I'll think about it for a bit and let you know if I can come > up with something. > What about: download: urlString to: anFSReference "anFSReference can be either: - a directory, where the file will be saved under its original name - otherwise, the file will be saved as the FSReference" | target entity | target := anFSReference isDirectory ifTrue: [ anFSReference / urlString asUrl path last ] ifFalse: [ anFSReference ]. entity := ZnClient new streaming: true; get: urlString; entity. target fileStreamDo: [ :stream | stream binary. entity writeOn: stream ]. This would allow really easy, flexible use like: "Save in this directory as same name" ZnClient download: 'http://www.pharo-project.org/images/pharo.png' to: '/Volumes/Fast/Squeak/Main Working Images/Pharo-1.3' asFile. "Save under new name in this exact place" ZnClient download: 'http://www.pharo-project.org/images/pharo.png' to: '/Volumes/Fast/Squeak/Main Working Images/Pharo-1.3/new_name.png' asFile. -- View this message in context: http://forum.world.st/Downloading-a-file-tp4586900p4588519.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

Re: [Pharo-project] Downloading a file

by Sean P. DeNigris

Sean P. DeNigris wrote > > > Sven Van Caekenberghe wrote >> >> entity := ZnClient new >> streaming: true; >> get: >> 'https://ci.lille.inria.fr/pharo/job/Cog%20Git%20Tracker/lastSuccessfulBuild…'; >> > > The above snippets successfully downloaded the files (I think), but there > is something wrong with them. The snippets were fine. The problem was me ;-) Sorry to cause you extra work... your original simpler examples (like the one above) work. I was calling #response instead of #entity, so the saved file included the http headers and made the files unreadable. Thanks for the help. Sean -- View this message in context: http://forum.world.st/Downloading-a-file-tp4586900p4588483.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

[Pharo-project] ConfigurationOfNautilus fix

by Francois Stephany

The latest ConfigurationOfNautilus was broken (Nautilus 4.3). I've uploaded a new version. However, this shows a bigger problem. The packages loaded in version 4.3 was modified over time. So doing "(ConfigurationOfNautilus project version: '4.3') load" right now loads different packages than 6 hours ago and breaks. It's alright but having this many times a day for countless packages hurts. We *should not* modify versions that have been tagged by the "stable" symbolic version. Francois

April 26, 2012