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

Re: [Pharo-project] Confused about #isDirectory

by Alexis Parseghian

On Thu, Apr 26, 2012 at 12:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > '/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. For what it's worth, working as expected on Linux (using either deprecated asReference or asFileReference) : /tmp true /home/alexisp true /nosuchpath false Pharo 1.4-14438 'CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Jan 26 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Jan 26 2012, https://git.gitorious.org/cogvm/blessed.git Commit: e49a136ea9fe909dd5ba3cdeffac8f61cce27c9f Date: Thu Jan 26 17:38:06 2012 +0100 By: Camillo Bruni <camillobruni(a)gmail.com>'

April 26, 2012

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

by Torsten Bergmann

Fernando wrote >Thanks! I wasnt aware of that projec. Also look at Pastell which allows for easy XPath like access to XML. See http://astares.blogspot.de/2010/01/pharosqueak-and-xml.html for an example. Bye T. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

April 26, 2012

[Pharo-project] Pharo Kernel 1.4 Reload Tests-Unix - Build # 86 - Still unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

April 26, 2012

[Pharo-project] [ANN] ImageWriter, the SystemTracer's son

by Guillermo Polito

First public push of the first step of the hazelnut GSoC project :) *In a nutshell* For those who didn't know SystemTracer (the father): It is a tool that traces a graph of objects and writes an image from it. ImageWriter is a refactored, renamed and repackaged version of SystemTracer2 with the following changes: - The image format can be provided as a parameter. - You have to provide an SmalltalkImage object as root to write the image (so in the future we can write bootstrap with this). - The object format was reified in objects. So the code is easier to understand + change, and people can learn how are our objects in memory easily :D. Right now, only 32 bit image format is supported. *Structure* - ImageWriter-Core has the image formats and the image writer in itself - ImageWriter-ObjectFormats contains objects that represent the memory layout of the objects and it's headers. - ImageWriter-Tests has some tests. *Tests done* - Only tested in Pharo-1.4 - There are specific tests written for the size and headers of the objects - Also, I've written a Pharo-1.4 image and then run the tests in the copied image. Only one failure compared to the original :) *Known Bugs :)* - WeakRegistryTest>>#testFinalizationWithOnFork is failing, and when I run it manually it works :/. In the image I use to write, it does not happen, only in the clone. - When opening the new image, the window is too small. It is not respecting the original image size. Don't know yet what is the problem. *How To Download* Gofer it squeaksource3: 'ImageWriter'; package: 'ImageWriter-Core'; package: 'ImageWriter-ObjectFormats'; package: 'ImageWriter-Tests'; load *How to Use it* HzImageWriter new format: HzCogImageFormat new; "or HzInterpreterImageFormat new" imageFileName: 'someFile.image'; onInitializeDo: [ "Some initialization?" ]; "this is optional, probably the same as an startup script, probably nonsense" writeImage: Smalltalk "Yes, we provide the our lovely global Smalltak, but any SmalltalkImage instance could be" *Next steps on this direction* - support to write an isolated image different from the host one (I'll know what I need later, hehe) - class comments! - metacello configuration - better api :) *Links* http://ss3.gemstone.com/ss/ImageWriter.html Cheers, Guille

April 26, 2012

[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