September 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Fraction>>asFloat needs review

by Nicolas Cellier

After Integer>>asFloat, Fraction>>asFloat needs a review too. It is not broken. But it has unreachable code, performs more arithmetic than necessary and we could put some light on obscure comments and reduce implicit knowledge. So if we can leave a better example of coding in the image, let's do it. It's better to write this in a Blog http://smallissimo.blogspot.com/2011/09/reviewing-fraction-asfloat.html because it would be too long for a single commit comment. Nicolas

Sept. 25, 2011

Re: [Pharo-project] Class creation notification

by Henrik Sperre Johansen

Of course, this is best handled by modifying the notifier to determine what is a "bulk". One way; - fork off notification in a lower priority thread, keeping a (threadsafe) reference to the collection of classes. - thread nils var when starting delivery - if new notification should be raised, and collection not nil, add it to current instead. Cheers, Henry -- View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841079.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 25, 2011

Re: [Pharo-project] Class creation notification

by Henrik Sperre Johansen

Mariano Martinez Peck wrote: > > grrr shorcuts.. then I found AutomaticMethodCategorizerApplier which I > don't > care. > And I don't care if I need to close and open again the TestRunner. > > So....what I mean is that class creation notification increases Fuel > classes > materialization like 50%. Do you think this is un-important enough to > provide a way to NOT notify? I mean, should I provide a way to avoid that > and avoid the 50% ? or it will be totally unsafe? > > Thanks! > Yes, it will be totally unsafe, if tools hold caches relying on the notifications for invalidation (which is entirely appropriate). A better solution would be to provide bulk notifications, so instead of sending a notification to subscribers once for each class added, you update them only once, after all classes are created. Same holds true for other kind of system changes. Cheers, Henry -- View this message in context: http://forum.world.st/Class-creation-notification-tp3837570p3841078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 25, 2011

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by Frank Shearar

On 25 September 2011 03:50, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 September 2011 01:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 24 September 2011 20:40, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Sat, Sep 24, 2011 at 9:34 PM, Frank Shearar <frank.shearar(a)gmail.com> >>> wrote: >>>> >>>> On 24 September 2011 20:01, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> wrote: >>>> > Well...Martin and I have been working a little bit this week and here is >>>> > a >>>> > post explaining it: >>>> > >>>> > http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… >>>> >>>> Cool! >>>> >>>> If I understand correctly, Fuel and Monticello (1; I don't know >>>> anything about 2 other than noone seems to use it but it's much >>>> better) accomplish two different things though: Fuel's a mechanism to >>>> quickly load a bunch of stuff, while Monticello's much more >>>> introspective: mainly, a bunch of definitions of things, with a >>>> history pointing to previous versions of the package. >>>> >>> >>> Yes. >>> >>>> >>>> I don't see how Fuel could replace Monticello, >>> >>> No, Fuel won't replace Monticello at all. They are different things. >>> >>>> >>>> then, except in the >>>> sense of "here's a chunk of stuff you can load into your image" - >>>> which makes me think that one could simply replace the snapshot.bin >>>> with a snapshot.fuel (or simply put it in the same directory, for a >>>> loss in space but a gain in compatibility) and you'd have a much >>>> faster loading mcz, right? >>> >>> Exactly. With Monticello right now you have to compile the sources.st, which >>> may be slow and even more you need the compiler. The idea is to experiment a >>> way of using Monticello to directly store binary/already compiled code. >>> This way, it may be faster for exporting/importing the code. >>> So....in summary, we will try to experiment to replace only a small part of >>> Monticello ;) >> >> I just did a bit of digging. It looks like source.st is there purely >> as a convenience. It looks like Monticello (i.e., MCPackageLoader) >> will look for snapshot.bin (or, failing that, the files snapshot/*). >> This file (or files) contains the list of definitions in the package. >> MCPackageLoader then walks over the definitions. >> > > ... and then compiles them :) > Fuel can load stuff directly, without compilation. Yes, I know Fuel can. Monticello does too, as it happens: it only compiles new methods. Take a look at MCPackageLoader >> #basicLoad, which invokes MethodAddition >> #installMethod. My comment was merely to say that Monticello doesn't actually use source.st in its loading process (from what I can see). Fuel looks to do more, faster! frank >> frank >> >>>> frank >>>> >>>> > Cheers >>>> > >>>> > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe <sven(a)beta9.be> >>>> > wrote: >>>> >> >>>> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >>>> >> >>>> >> > Cool Martin. Now I could do it as well. I have exported the groups >>>> >> > 'Core', 'Tests' and 'Zinc-Seaside'. >>>> >> > Then I materialize it a clean image and all tests (1567) are green. >>>> >> > And >>>> >> > it only takes 7 seconds :) >>>> >> >>>> >> Great ! >>>> >> >>>> >> I want to try this myself soon. >>>> >> >>>> >> Sven >>>> >> >>>> >> _______________________________________________ >>>> >> seaside mailing list >>>> >> seaside(a)lists.squeakfoundation.org >>>> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> > >>>> > >>>> > >>>> > -- >>>> > Mariano >>>> > http://marianopeck.wordpress.com >>>> > >>>> > >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Sept. 25, 2011

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by StÃ©phane Ducasse

>> > > I just did a bit of digging. It looks like source.st is there purely > as a convenience. It looks like Monticello (i.e., MCPackageLoader) > will look for snapshot.bin (or, failing that, the files snapshot/*). > This file (or files) contains the list of definitions in the package. > MCPackageLoader then walks over the definitions. yes and this is important that the bin does not get desync else you publish packages and 3 months later they are broken. This happens to us when we started to fix MethodReference and friends. So soon we will migrate MC model to Ring to reduce the over head because a MC meta model uses pseudo class (I guess) and MethodReference a real "mille-feuilles". Stef

Sept. 25, 2011

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by Igor Stasenko

On 25 September 2011 01:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 24 September 2011 20:40, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Sat, Sep 24, 2011 at 9:34 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >>> >>> On 24 September 2011 20:01, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> > Well...Martin and I have been working a little bit this week and here is >>> > a >>> > post explaining it: >>> > >>> > http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… >>> >>> Cool! >>> >>> If I understand correctly, Fuel and Monticello (1; I don't know >>> anything about 2 other than noone seems to use it but it's much >>> better) accomplish two different things though: Fuel's a mechanism to >>> quickly load a bunch of stuff, while Monticello's much more >>> introspective: mainly, a bunch of definitions of things, with a >>> history pointing to previous versions of the package. >>> >> >> Yes. >> >>> >>> I don't see how Fuel could replace Monticello, >> >> No, Fuel won't replace Monticello at all. They are different things. >> >>> >>> then, except in the >>> sense of "here's a chunk of stuff you can load into your image" - >>> which makes me think that one could simply replace the snapshot.bin >>> with a snapshot.fuel (or simply put it in the same directory, for a >>> loss in space but a gain in compatibility) and you'd have a much >>> faster loading mcz, right? >> >> Exactly. With Monticello right now you have to compile the sources.st, which >> may be slow and even more you need the compiler. The idea is to experiment a >> way of using Monticello to directly store binary/already compiled code. >> This way, it may be faster for exporting/importing the code. >> So....in summary, we will try to experiment to replace only a small part of >> Monticello ;) > > I just did a bit of digging. It looks like source.st is there purely > as a convenience. It looks like Monticello (i.e., MCPackageLoader) > will look for snapshot.bin (or, failing that, the files snapshot/*). > This file (or files) contains the list of definitions in the package. > MCPackageLoader then walks over the definitions. > ... and then compiles them :) Fuel can load stuff directly, without compilation. > frank > >>> frank >>> >>> > Cheers >>> > >>> > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe <sven(a)beta9.be> >>> > wrote: >>> >> >>> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >>> >> >>> >> > Cool Martin. Now I could do it as well. I have exported the groups >>> >> > 'Core', 'Tests' and 'Zinc-Seaside'. >>> >> > Then I materialize it a clean image and all tests (1567) are green. >>> >> > And >>> >> > it only takes 7 seconds :) >>> >> >>> >> Great ! >>> >> >>> >> I want to try this myself soon. >>> >> >>> >> Sven >>> >> >>> >> _______________________________________________ >>> >> seaside mailing list >>> >> seaside(a)lists.squeakfoundation.org >>> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > -- Best regards, Igor Stasenko.

Sept. 25, 2011

Re: [Pharo-project] looking for boring morphs

by Ricardo Moran

Hi, last year I made this very simple CalendarMorph for Etoys (find attached). I just tested it in Pharo 1.3 and it works (except for the text alignment) so maybe you can find it useful as a starting point or something. Cheers, Richo On Fri, Sep 23, 2011 at 5:55 PM, Edgar J. De Cleene <edgardec2005(a)gmail.com>wrote: > > > > On 9/23/11 9:47 AM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > Hi, > > I have a customer who are asking me for a very small app... but a desktop > app, > > not the usual web app I'm more used to do... > > and of course, I'm doing it with pharo! > > So far... this is working really well... much easier as I supposed it > would be > > :) > > I'm using glamour, magritte, keybindings, hpdf, mongodb... and small > tweaks by > > my self to make it work as expected, but not so much. > > > > (btw... I want to say that a couple of years ago, this wont be an option > at > > all... this is due to the great effort the pharo community is doing, and > I'm > > really proud of it. Thank you guys!) > > > > well... now... I need some morphs a regular management application > usually > > needs: > > > > 1) NumberInputFieldMorph (A child of TextMorph or PluggableTextMorph who > > allows different kind of numbers -> this is easy to do, but better if it > is > > already somewhere) > > http://wiki.squeak.org/squeak/5906 "How to do a Calculator using pure > Morphic" > > Hope this help > > > 2) DateInputFieldMorph (a morph with a "date picker" -> this is harder, > > because I have very limited knowledge about morphic) > > 3) I'm sure there are others I didn't needed yet, but there are needed in > this > > kind of applications > > > > so... does someone has this kind of morphs somewhere? I would really > > appreciate it, because you know... it is doable, but time is tyrant and > better > > if I can reuse someones work ;) > > > > cheers, > > Esteban > > And see > > > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/ > designer > > Sure some ideas was useful. > > Edgar > > > >

Sept. 24, 2011

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by Frank Shearar

On 24 September 2011 20:40, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, Sep 24, 2011 at 9:34 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 24 September 2011 20:01, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > Well...Martin and I have been working a little bit this week and here is >> > a >> > post explaining it: >> > >> > http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… >> >> Cool! >> >> If I understand correctly, Fuel and Monticello (1; I don't know >> anything about 2 other than noone seems to use it but it's much >> better) accomplish two different things though: Fuel's a mechanism to >> quickly load a bunch of stuff, while Monticello's much more >> introspective: mainly, a bunch of definitions of things, with a >> history pointing to previous versions of the package. >> > > Yes. > >> >> I don't see how Fuel could replace Monticello, > > No, Fuel won't replace Monticello at all. They are different things. > >> >> then, except in the >> sense of "here's a chunk of stuff you can load into your image" - >> which makes me think that one could simply replace the snapshot.bin >> with a snapshot.fuel (or simply put it in the same directory, for a >> loss in space but a gain in compatibility) and you'd have a much >> faster loading mcz, right? > > Exactly. With Monticello right now you have to compile the sources.st, which > may be slow and even more you need the compiler. The idea is to experiment a > way of using Monticello to directly store binary/already compiled code. > This way, it may be faster for exporting/importing the code. > So....in summary, we will try to experiment to replace only a small part of > Monticello ;) I just did a bit of digging. It looks like source.st is there purely as a convenience. It looks like Monticello (i.e., MCPackageLoader) will look for snapshot.bin (or, failing that, the files snapshot/*). This file (or files) contains the list of definitions in the package. MCPackageLoader then walks over the definitions. frank >> frank >> >> > Cheers >> > >> > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe <sven(a)beta9.be> >> > wrote: >> >> >> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >> >> >> >> > Cool Martin. Now I could do it as well. I have exported the groups >> >> > 'Core', 'Tests' and 'Zinc-Seaside'. >> >> > Then I materialize it a clean image and all tests (1567) are green. >> >> > And >> >> > it only takes 7 seconds :) >> >> >> >> Great ! >> >> >> >> I want to try this myself soon. >> >> >> >> Sven >> >> >> >> _______________________________________________ >> >> seaside mailing list >> >> seaside(a)lists.squeakfoundation.org >> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 24, 2011

[Pharo-project] [1.4] pre-build 14163

by Marcus Denker

... with jenkins dead here is a current updated image of 1.4: I will link it on http://www.pharo-project.org/pharo-download/unstable-1-4 https://gforge.inria.fr/frs/download.php/29095/Pharo-1.4-14163.zip -- Marcus Denker -- http://marcusdenker.de

Sept. 24, 2011

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by Mariano Martinez Peck

On Sat, Sep 24, 2011 at 10:53 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hmmm, I don't think that Fuel has to be related with Monticello. They have > different intentions :). > > But having binary packaging is great! :) > > What comes next is a way of organize the binary distributions :P. > > Well, in fact that was one of the ideas behind Fuel Package Loader. For those who knows Java, the idea is to provide a kind of Jar, that is, the code already compiled. With of course, the possibility to attach sources as well. Then for example you have your applicatio XXX that uses Seaside, then you can just build an image with seaside.fuel and that's all. No need of sources, no need of version history, etc... So...I think that for deploying purposes, it is also an interesting idea :) > Guille > > > On Sat, Sep 24, 2011 at 5:30 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sat, Sep 24, 2011 at 10:22 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: >> >>> On 24 September 2011 20:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> > >>> > >>> > On Sat, Sep 24, 2011 at 9:47 PM, Frank Shearar < >>> frank.shearar(a)gmail.com> >>> > wrote: >>> >> >>> >> On 24 September 2011 20:40, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> >>> >> wrote: >>> >> > >>> >> > >>> >> > On Sat, Sep 24, 2011 at 9:34 PM, Frank Shearar < >>> frank.shearar(a)gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> On 24 September 2011 20:01, Mariano Martinez Peck >>> >> >> <marianopeck(a)gmail.com> >>> >> >> wrote: >>> >> >> > Well...Martin and I have been working a little bit this week and >>> here >>> >> >> > is >>> >> >> > a >>> >> >> > post explaining it: >>> >> >> > >>> >> >> > >>> >> >> > >>> http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… >>> >> >> >>> >> >> Cool! >>> >> >> >>> >> >> If I understand correctly, Fuel and Monticello (1; I don't know >>> >> >> anything about 2 other than noone seems to use it but it's much >>> >> >> better) accomplish two different things though: Fuel's a mechanism >>> to >>> >> >> quickly load a bunch of stuff, while Monticello's much more >>> >> >> introspective: mainly, a bunch of definitions of things, with a >>> >> >> history pointing to previous versions of the package. >>> >> >> >>> >> > >>> >> > Yes. >>> >> > >>> >> >> >>> >> >> I don't see how Fuel could replace Monticello, >>> >> > >>> >> > No, Fuel won't replace Monticello at all. They are different things. >>> >> >>> >> Ah, OK. That means I misinterpreted "As you may imagine the idea is >>> >> that maybe in the future we can replace Monticelloâ mcz with Fuel >>> >> packages." You meant in the sense of an mcz being something you load >>> >> in your image, not somehow extending Fuel to a version control system >>> >> (which would ... not make sense :) ). >>> >> >>> > >>> > Exactly. Maybe the comment was not clear. What I mean is to change >>> > Monticello in the way that instead of serializing code into a mzc that >>> > contains the sources and the use the compiler, use Fuel to directly >>> > store/load the code in a binary way. >>> > Is that better explained? >>> >>> I think it's just my careless reading. The rest of the article's quite >>> clear - "As you may know, Fuel is a plain object graph serializer. No >>> more than that." - and so on. >>> >>> >> :) >> >> >>> I can't wait: a super fast package loader makes it cheap and easy to >>> build up images from recipes. Nice! >>> >>> >> Yes, me too. Problem is that neither Martin or I know very much about >> Monticello. Even more, we prefer to focus in Fuel itself. We consider Fuel >> Package Loader as a proof of concept for a real project. Hopefully, someone >> can join and take care of it. Otherwise, we will try to make progres, but >> slowly :( >> >> >> >> >>> frank >>> >>> >> >> then, except in the >>> >> >> sense of "here's a chunk of stuff you can load into your image" - >>> >> >> which makes me think that one could simply replace the snapshot.bin >>> >> >> with a snapshot.fuel (or simply put it in the same directory, for a >>> >> >> loss in space but a gain in compatibility) and you'd have a much >>> >> >> faster loading mcz, right? >>> >> > >>> >> > Exactly. With Monticello right now you have to compile the >>> sources.st, >>> >> > which >>> >> > may be slow and even more you need the compiler. The idea is to >>> >> > experiment a >>> >> > way of using Monticello to directly store binary/already compiled >>> code. >>> >> > This way, it may be faster for exporting/importing the code. >>> >> > So....in summary, we will try to experiment to replace only a small >>> part >>> >> > of >>> >> > Monticello ;) >>> >> >>> >> Ah, excellent! I can't wait! >>> >> >>> >> >> frank >>> >> >> >>> >> >> > Cheers >>> >> >> > >>> >> >> > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe >>> >> >> > <sven(a)beta9.be> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >>> >> >> >> >>> >> >> >> > Cool Martin. Now I could do it as well. I have exported the >>> groups >>> >> >> >> > 'Core', 'Tests' and 'Zinc-Seaside'. >>> >> >> >> > Then I materialize it a clean image and all tests (1567) are >>> >> >> >> > green. >>> >> >> >> > And >>> >> >> >> > it only takes 7 seconds :) >>> >> >> >> >>> >> >> >> Great ! >>> >> >> >> >>> >> >> >> I want to try this myself soon. >>> >> >> >> >>> >> >> >> Sven >>> >> >> >> >>> >> >> >> _______________________________________________ >>> >> >> >> seaside mailing list >>> >> >> >> seaside(a)lists.squeakfoundation.org >>> >> >> >> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Mariano >>> >> >> > http://marianopeck.wordpress.com >>> >> >> > >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Mariano >>> >> > http://marianopeck.wordpress.com >>> >> > >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2011