- Pharo-dev - lists.pharo.org

Re: [Pharo-project] thanks for pharoconf

by phil＠highoctane.be

Usman, Update done, including link to your Inria page. KR Phil 2012/5/27 Usman Bhatti <usman.bhatti(a)gmail.com> > > > On Sun, May 27, 2012 at 12:58 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> Yes, very interesting, motivating, and results producing! >> >> Thanks a ton for making it a reality. >> >> Two blog posts of mine just in case you are interested: >> >> http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/ >> http://philippeback.be/2012/05/second-day-at-pharoconf-in-lille/ >> > > Thanx for the post, Phil. It was nice talking to you and other people at > Pharo conf. Igor rightly mentioned that the conference was a moral booster > for all of us... > > Now back to work. > > Usman Bhatti > (I hope you dont forget my name anymore :-) > > >> >> Thanks again! >> >> Philippe Back >> >> 2012/5/27 Norbert Hartl <norbert(a)hartl.name> >> >>> Yes, >>> >>> was fun to see a lot of you. And I could add some new faces to my >>> inventory. Great! >>> >>> Norbert >>> >>> Am 27.05.2012 um 00:12 schrieb Tudor Girba: >>> >>> > Hi, >>> > >>> > I had a good time at PharoConf. >>> > >>> > Thanks for organizing it. >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > -- >>> > www.tudorgirba.com >>> > >>> > "Beauty is where we see it." >>> > >>> > >>> > >>> > >>> >>> >>> >> >> >> -- >> Philippe Back >> "Helping you hit the top 3 outcomes you really want to achieve" >> >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> >> > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

May 28, 2012

Re: [Pharo-project] [ANN] NativeBoost 1.2 version released (#development)

by Lawson English

On 5/28/12 12:14 AM, Igor Stasenko wrote: > Hi, there > > i prepared new Metacello configuration of NativeBoost. > > Here the list of changes: > > Sounds good. I will modify my test of gmp bindings to use it. BTW, for anyone interested, here is a way of creating "batch" bindings to the gmplib big integer add call: http://pastebin.com/naj05wEe makes two successive calls to the same (could be a different) function from within the same method. This avoids the overhead of the marshaling of parameters and making successive calls via the VM. With this technique, you could perform a reasonably complex task in an external lib with a single method. Extra assembler code can be placed in the same block, for extra speedy goodness. Now, in order to keep the Squeak Wayâ¢, we need a way of writing the code in slang instead of assembler. L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

May 28, 2012

[Pharo-project] [ANN] NativeBoost 1.2 version released (#development)

by Igor Stasenko

Hi, there i prepared new Metacello configuration of NativeBoost. Here the list of changes: Integer>>#| in AsmJit now - added a recursion detecting/handling via notifications - NBExternalHandle / NBExternalAddress is no longer subclasses of NBExternalStructure - more safer way to handle finalizing external objects survived from old session - avoid recursion when printing external struct fields - default alignment of external struct is machine word size - correct padding between struct fields (need to test) - ** fix ** conceptual bug when passing a struct by value. Now copying its contents on stack, instead of passing pointer - rewrote accessing struct fields, allowing nested structs - added #size_t type and NBSizeT marshaller - use stack pointer directly by getting it's address (via stackPointerAddress() available in Cog), so accessing ST stack is faster.. - added recursion guards in NBInterpreterProxy and in NBNativeCodeGen to prevent runaway train(s) - NBExternalType >> #typeSize answers the number of bytes which value of full type (including ptr arity) variable takes place in memory. NBExternalType >> valueSize is the number of bytes for base type (excluding pointers) takes in memory. NBExternalType >> stackSize taking into account stack argument alignment ------------------------- The main change is handling correctly passing structs by value. Before i was wrongly assuming that if function takes struct: int foo ( struct x a) you need to push the pointer to struct.. but in fact you need to copy struct contents on stack! This means that all function signatures which were written based on this wrong assumption should be changed to pass a pointer (if function takes a pointer to struct). So, don't be so haste to use it with Athens with new version of NB. It will definitely break (and i know where) because of this mistake. Fortunately, most of the libraries avoid passing structs by value, so most of the bindings should still keep working fine after update. But be warned about it! Thanks Luc for pointing out on this issue. Another improvement is because of more correct handling of structs, now NB allows nested structs. I blessed this version as #development. If no serious bugs will be found, after testing it with Athens and NBOpenGL (+ add your projects) i will change blessing to #release. -- Best regards, Igor Stasenko.

May 28, 2012

Re: [Pharo-project] building and installing a morph in the background

by Igor Stasenko

On 27 May 2012 23:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > "To utilize feedback, you first have to acquire it." :) -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] building and installing a morph in the background

by Tudor Girba

Hi, Thanks, Igor. Indeed, something is strange. And indeed, you were obviously right about not building the morph inside the addDeferredUIMessage block. It's published now. I built a test to show the behavior. It does not rely on a Glamour mechanism, but it does use the GLMWatcherWindow. Perhaps it is useful for other people: ----- GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance addContent: [ RectangleMorph new color: Color transparent ]. "just to make sure it's gray" (Delay forMilliseconds: 500) wait. "this is just to simulate an initial request for a blue rectangle. it has a slight delay." GLMWatcherWindow uniqueInstance addContent: [ (Delay forMilliseconds: 1000) wait. RectangleMorph new color: Color blue ]. "this is for simulating an override of the previous request. the delay is longer to ensure that blue can appear in case the process is not terminated properly" GLMWatcherWindow uniqueInstance addContent: [ (Delay forMilliseconds: 5000) wait. RectangleMorph new color: Color red ] ----- So, the basic question is now solved. Thanks. I will look into the Glamour-related problem. I might need some more help there :) Cheers, Doru p.s. I know you do not like suspendAllWhile:, but I think there are scenarios in which it is useful. I will get back to this in a separate thread a bit later On 27 May 2012, at 18:30, Igor Stasenko wrote: > i think there is some mistake in event wiring.. > i cannot tell much, because i don't understand the glamour models.. > > but what i found strange is that i get large pause before i got halt in > actOnMatchingPresentationsChanged: > > it looks like the same event goes twice (or there two kinds of events) > and you model tries to update the detal list bypassing (or in addition) to the > #actOnMatchingPresentationsChanged: > > To reproduce my observations try do following: > - evaluate the doit which you gave above , so you have two windows open. > Now click in a browser list, to set the initial selection. > > Now go to #actOnMatchingPresentationsChanged > and put halt there > > actOnMatchingPresentationsChanged: anAnnouncement > > +++ self halt. > GLMWatcherWindow uniqueInstance > addContent: [ self renderObject: anAnnouncement pane ] > > Now click on list again to change the selection. > You can observe a huge pause before you got halt. > So, apparently the logic in #addContent: has nothing to do with the > blocking you still observe. > (btw in image which you give in link the > morph generation is still inside of #addDeferredUIMessage, > i , of course moved it outside before trying things). > > > P.S. btw, did i told you that i don't like #suspendAllWhile: in announcer? :) > The point is: if you need things like that, then you doing something wrong. > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

May 27, 2012

Re: [Pharo-project] [Pharo-users] [ANN] Fuel Release Version 1.8

by Igor Stasenko

On 27 May 2012 21:23, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > >> Fuel works out of the box in Pharo from 1.1 up to 2.0 (checked at >> #20094). Please check our documentation [2] for complete installation >> and use guides > > > > Martin told me something by private email that I think is worth to mention. > Not sure if you read it carefully, but Fuel is working from Pharo version > 1.1 up to 2.0!!! But he is mentioned that already in his announcement. :) This is nice, of course! > One of reasons is to help people migrate to new Pharo versions by using Fuel > as a way of moving data. > > Cheers > >> . >> >> Below, there are some remarkable changes. >> >> - Much more complete user guides. >> - Improved API for customizing how graph is traced. >> - FuelMetalevel: serialization of stuff like classes and compiled >> methods moved to an optional package. >> - Customize objects to be treated as globals. >> - Migrations: declare at materialization time class and variables renames. >> - Weak references properly managed. Thanks to Juan Vuletich and Levente. >> - Thanks Pavel for helping us improving FuelPackageLoader with >> wonderful ideas and bug reports. >> - Serialization speed up on large graphs by using specialized >> collections. Thanks Levente. >> - Encoder and Decoder: new reifications that clarify the design. >> Thanks Colin Putney. >> - Optimized serialization of "clean" BlockClosures, which don't need >> the whole stack of contexts. Thanks Juan Vuletich and Eliot Miranda. >> - Added a clear error hierarchy. >> - Debug facilities, including graph visualization using Roassal. >> Thanks Alexandre and Doru. >> - Many more new tests. Including those from extension packages, we >> have almost 600 tests. >> - Repository moved from 'http://www.squeaksource.com/Fuel' to >> 'http://ss3.gemstone.com/ss/Fuel'. >> >> If you are a Fuel user we are not aware of, please let us know! >> >> Best regards, >> Martin and Mariano >> >> [1]: http://rmod.lille.inria.fr/web/pier/software/Fuel >> [2]: >> http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation >> > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by Usman Bhatti

On Sun, May 27, 2012 at 12:58 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Yes, very interesting, motivating, and results producing! > > Thanks a ton for making it a reality. > > Two blog posts of mine just in case you are interested: > > http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/ > http://philippeback.be/2012/05/second-day-at-pharoconf-in-lille/ > Thanx for the post, Phil. It was nice talking to you and other people at Pharo conf. Igor rightly mentioned that the conference was a moral booster for all of us... Now back to work. Usman Bhatti (I hope you dont forget my name anymore :-) > > Thanks again! > > Philippe Back > > 2012/5/27 Norbert Hartl <norbert(a)hartl.name> > >> Yes, >> >> was fun to see a lot of you. And I could add some new faces to my >> inventory. Great! >> >> Norbert >> >> Am 27.05.2012 um 00:12 schrieb Tudor Girba: >> >> > Hi, >> > >> > I had a good time at PharoConf. >> > >> > Thanks for organizing it. >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Beauty is where we see it." >> > >> > >> > >> > >> >> >> > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > >

May 27, 2012

Re: [Pharo-project] class message

by Igor Stasenko

On 27 May 2012 21:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> So questions: >> >> >> Is ProtoObject should implement #class? >> >> >> Can we move #class method from Object to ProtoObject? >> >> >> >> >> > >> >> > ups....good catch! indeed, we should move it to ProtoObject. >> >> > >> >> mm.. why? >> > >> > >> > Because ALL objects do have a class. Right? if you want to change the >> > semantics of #class then just subclass and change it. >> >> mmm.. no. >> IMO, in pure sense, all objects having behavior. but behavior is not a >> class (and we can even have >> two classes to discriminate between them). >> yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to >> be compatible with Class protocol.. You should know pretty well, what >> requirements VM side puts >> for a valid behavior: - superclass, methoddict, format. >> which enables VM to do method lookup and creating an instances. >> >> now, if you make ProtoObject to answer message #class, one will assume >> that >> the object it answers should conform to a full-fledged Class protocol. >> But of course it should not. >> >> Maybe i nitpicking about terminology.. but i think at that level we >> should make it clear: >> - all objects having behavior! >> - some object's behaviors are Classes >> - some object's behaviors are Metaclasses >> - but there could be any other. >> > > I agree with all that. But as you said, I think you are going too low level > in details. > For example, I would call class to all your previous list. All objects have > a class, which can be Class, Metaclass, whatever. > In addition, if we don't add #class in ProtoObject, then there are some of > broken messages like #cannotInterpret: and #pointsTo since they send #class > to self. > okay i agree. i just don't like that in case of ProtoObject the name of a message is a bit misleading, while perfectly ok for Object. Maybe we should state that in method comment, that only instances of Object and its subclasses are guarantee that answer of #class message are Class.. for ProtoObject (or its direct descendant) is can be anything. > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] [Pharo-users] Zinc/Zodiac Documentation

by StÃ©phane Ducasse

thanks Sven. I have nearly finish to read the zinc chapter. Great contents. I would like to create diagram and others for the book version but no time right now. Stef On May 27, 2012, at 7:34 PM, Sven Van Caekenberghe wrote: > Hi, > > > Now that I have recovered from the intensive Pharo Conference, I found the time to publish the Zinc and Zodiac documentation. > > The two main websites have been updated: > > http://zn.stfx.eu > http://zdc.stfx.eu > > My slides are here > > http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf > http://zdc.stfx.eu/zdc-talk-pharo-conference.pdf > > The documentation (as Pharo Conference paper and draft chapter for Pharo By Example 2) are here > > http://zn.stfx.eu/zn/zinc-http-components-paper.html > http://zdc.stfx.eu/zodiac-paper.html > > For some inexplicable reason, Google Chrome is extremely slow doing the syntax highlighting on the long Zn paper/chapter, so here is an alternative version > > http://zn.stfx.eu/zn/zinc-http-components-paper.no-js.html > > > Enjoy! > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

May 27, 2012

Re: [Pharo-project] [Pharo-users] [ANN] Fuel Release Version 1.8

by Mariano Martinez Peck

Fuel works out of the box in Pharo from 1.1 up to 2.0 (checked at > #20094). Please check our documentation [2] for complete installation > and use guides Martin told me something by private email that I think is worth to mention. Not sure if you read it carefully, but Fuel is working from Pharo version 1.1 up to 2.0!!! One of reasons is to help people migrate to new Pharo versions by using Fuel as a way of moving data. Cheers . > > Below, there are some remarkable changes. > > - Much more complete user guides. > - Improved API for customizing how graph is traced. > - FuelMetalevel: serialization of stuff like classes and compiled > methods moved to an optional package. > - Customize objects to be treated as globals. > - Migrations: declare at materialization time class and variables renames. > - Weak references properly managed. Thanks to Juan Vuletich and Levente. > - Thanks Pavel for helping us improving FuelPackageLoader with > wonderful ideas and bug reports. > - Serialization speed up on large graphs by using specialized > collections. Thanks Levente. > - Encoder and Decoder: new reifications that clarify the design. > Thanks Colin Putney. > - Optimized serialization of "clean" BlockClosures, which don't need > the whole stack of contexts. Thanks Juan Vuletich and Eliot Miranda. > - Added a clear error hierarchy. > - Debug facilities, including graph visualization using Roassal. > Thanks Alexandre and Doru. > - Many more new tests. Including those from extension packages, we > have almost 600 tests. > - Repository moved from 'http://www.squeaksource.com/Fuel' to > 'http://ss3.gemstone.com/ss/Fuel'. > > If you are a Fuel user we are not aware of, please let us know! > > Best regards, > Martin and Mariano > > [1]: http://rmod.lille.inria.fr/web/pier/software/Fuel > [2]: > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation > > -- Mariano http://marianopeck.wordpress.com

May 27, 2012