July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Project Catalog getting out slowly :)

by Camillo Bruni

nice! :) On 2013-07-13, at 15:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm building (I'm consolidating the code now) a Catalog builder that takes metadescribed > configurationOfâ¦. It uses Gutenberg. > > Have a look at the ConfigurationOfSoup to see what I need: > two methods + one class comment for now. > > I want better documented configuration. > > After if somebody wants to have a better system, I will have no problem to throw away my code. > Right now I want all the configurations to support these two methods and a jenkins build to generate the catalog for me. > > Stef > > >> How do you generate this? >> >> On 2013-07-13, at 14:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> I start to be able to generate such files for a Pharo project catalog >>> >>> <Soup.html><XMLWriter.html> >>> >>> I added some metadata to configuration files and it pays off. >>> >>> Stef >> >> > >

July 13, 2013

Re: [Pharo-dev] [update 3.0] #30267

by StÃ©phane Ducasse

I imagine that quite well :) but my love/hate relationship with trait always bugs me :) On Jul 13, 2013, at 2:44 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > If you put all methods from ClassDescriptions in traits and move them on > Class and Metaclass there is no need for ClassDescription. > > If previously you want something that inherited from ClassDescription you > can simply include the traits now. > > In the case of a Behavior subclass nothing changes. > > On 2013-07-13, at 14:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Why can't we keep ClassDescription. >> Then in addition Behavior is a nice class to have to build strange stuff. >> >> Stef >> >> On Jul 12, 2013, at 7:22 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> On Thu, Jul 11, 2013 at 6:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> 11151 More changes needed to trait/classes polymorphism >>>> https://pharo.fogbugz.com/f/cases/11151/ >>> >>> >>> That's huge. Soon, we will be able to remove thr ClassDescription and >>> Behavior classes. It makes sense because they are useless in the >>> presence of traits. But do people want it? >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >> >> > >

July 13, 2013

Re: [Pharo-dev] Project Catalog getting out slowly :)

by StÃ©phane Ducasse

I'm building (I'm consolidating the code now) a Catalog builder that takes metadescribed configurationOfâ¦. It uses Gutenberg. Have a look at the ConfigurationOfSoup to see what I need: two methods + one class comment for now. I want better documented configuration. After if somebody wants to have a better system, I will have no problem to throw away my code. Right now I want all the configurations to support these two methods and a jenkins build to generate the catalog for me. Stef > How do you generate this? > > On 2013-07-13, at 14:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> I start to be able to generate such files for a Pharo project catalog >> >> <Soup.html><XMLWriter.html> >> >> I added some metadata to configuration files and it pays off. >> >> Stef > >

July 13, 2013

Re: [Pharo-dev] [NB]: Review & fixes & ideas

by StÃ©phane Ducasse

what are the pros and cons? Stef > the only question, which remains , shall it use strict type checking > (so you have to change the signature), or allow to use such objects > with any signatures which takes a pointer to something, e.g. > extend generic NBExternalType>>pushAsPointer: to additionally check if > incoming argument is instance of NBObjectFieldAddress class.

July 13, 2013

Re: [Pharo-dev] [update 3.0] #30267

by Camillo Bruni

If you put all methods from ClassDescriptions in traits and move them on Class and Metaclass there is no need for ClassDescription. If previously you want something that inherited from ClassDescription you can simply include the traits now. In the case of a Behavior subclass nothing changes. On 2013-07-13, at 14:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Why can't we keep ClassDescription. > Then in addition Behavior is a nice class to have to build strange stuff. > > Stef > > On Jul 12, 2013, at 7:22 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> On Thu, Jul 11, 2013 at 6:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> 11151 More changes needed to trait/classes polymorphism >>> https://pharo.fogbugz.com/f/cases/11151/ >> >> >> That's huge. Soon, we will be able to remove thr ClassDescription and >> Behavior classes. It makes sense because they are useless in the >> presence of traits. But do people want it? >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> > >

July 13, 2013

Re: [Pharo-dev] [NB]: Review & fixes & ideas

by StÃ©phane Ducasse

Igor you should add that to a class comment and into the wiki of NB. On Jul 12, 2013, at 5:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, there , > i've been working last two weeks on reviewing the code in NB, > and update configuration & making tests green etc.. > So, here the summary: > > 0. New stuff: > > external structures (NBExternalStructure) now is normal objects (not > var-byte ones), and using 'data' ivar indirection like in > NBExternalArray, so you can allocate external struct on both external > heap and object memory, e.g.: > > struct := MyStructClass externalNew. > or: > struct := MyStructClass new. > (so, it is similar to NBExternalArray). > > - a function with signature > > MyStruct * foo () > > which returns a pointer to struct, now will return an instance of > MyStruct with the address, so you can use it directly , e.g.: > > struct := self callFoo. > > value := struct field1. > struct field2: 10 > > etc.. > > Thanks to Ciprian for introducing the change. I just polished a bit > and fixed some mistakes. > > 1. NBExternalTypeValue>>address > should not exist. > You simply cannot use freely an address to object's internal field > because object can move in memory. > > (the tests in > NBFFIExternalValueTests > testOutIntArg > testOutValueArg > testOutVoidArg > > is changed accordingly) > > 2. In NBExternalEnumerationType: pushing a pointer to this type is not > allowed, since it makes no sense. > > But the mistake there was to generate a code which fails primitive > with an error message, > instead of failing much much sooner - at code generation stage, since > it is already known that user specified wrong type. > > 3. I reverting generic pushAsPointer: to accept varbyte objects > instead of just ByteArray object. > - removing #specialPush:asPointer:endLabel: > because it will be not used (btw, > in NBExternalStructureType>>specialPush:asPointer:endLabel: , there > was same mistake that > it generates code to checking a pointer arity at runtime, while it is > already known during code generation time: > > asm decorateWith: 'arity checking' during: [ |pointerArityOk| > pointerArityOk := asm uniqueLabelName: 'pointerArityOk'. > asm mov: pointerArity asImm32 to: asm EAX; > cmp: asm EAX with: 1 asImm32; > je: pointerArityOk. > gen failWithMessage: 'Arity ', pointerArity printString,' not > allowed for ', objectClass name, 'objects'. > asm label: pointerArityOk]. > > since pointerArity is known, the produced code will be something like: > > mov: 1 to: EAX; > cmp: EAX with: 1; > je: pointerArityOk > > and makes no sense, because again it can just throw the error at code > generation time. > > 4. Added code to capture argument names (CompiledMethod>>nbArgumentNames) > and 'NativeBoost prepareForProduction', to ensure NB can work without > source code accessible. > > > 5. But the general expression, like in (1): > > object address > > gave me an interesting idea: what if we introduce a special type, say > NBObjectFieldAddress. > Consider the following problem: > imagine that you have a big array in object memory (byte array), > and you want to pass a pointer to n-th element of that array to some function. > Right now, there is no way how you can do it, and you can pass only a > pointer to array itself (which means it will always point to its first > element). > > So, the idea is to introduce a special type, and special object which > represents the address-of-object's-field, so you can tell: > > array := ByteArray new: 1000. > > address := array nbAddressAt: 500. "create an address object which > points to 500th element of given array" > > (and expression 'array nbAddress' is synonym to 'array nbAddressAt: 1'). > > self callSomeFunctionWith: address. > > The signature of C function which takes a pointer like: > > void foo (void * ptr) > > then should be changed to: > > void foo (NBObjectFieldAddress ptr) > > the only question, which remains , shall it use strict type checking > (so you have to change the signature), or allow to use such objects > with any signatures which takes a pointer to something, e.g. > extend generic NBExternalType>>pushAsPointer: to additionally check if > incoming argument is instance of NBObjectFieldAddress class. > > P.S. to try new config , load it: > > Gofer new > smalltalkhubUser: 'Pharo' project: 'NativeBoost'; > configuration; > load. > > > ConfigurationOfNativeBoost loadDevelopment. "which should load 2.2 > version of it" > > > -- > Best regards, > Igor Stasenko. >

July 13, 2013

Re: [Pharo-dev] [update 3.0] #30267

by StÃ©phane Ducasse

Why can't we keep ClassDescription. Then in addition Behavior is a nice class to have to build strange stuff. Stef On Jul 12, 2013, at 7:22 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Jul 11, 2013 at 6:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 11151 More changes needed to trait/classes polymorphism >> https://pharo.fogbugz.com/f/cases/11151/ > > > That's huge. Soon, we will be able to remove thr ClassDescription and > Behavior classes. It makes sense because they are useless in the > presence of traits. But do people want it? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 13, 2013

Re: [Pharo-dev] [update 3.0] #30267

by StÃ©phane Ducasse

On Jul 12, 2013, at 7:22 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Jul 11, 2013 at 6:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 11151 More changes needed to trait/classes polymorphism >> https://pharo.fogbugz.com/f/cases/11151/ > > > That's huge. Soon, we will be able to remove thr ClassDescription and > Behavior classes. It makes sense because they are useless in the > presence of traits. But do people want it? I'm not sure :) Stef > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 13, 2013

Re: [Pharo-dev] Some updates to GLorp

by StÃ©phane Ducasse

On Jul 11, 2013, at 3:52 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I do agree. But notice that it took me like 2 days to adapt the pool to the native driver, find the problems, fix the bugs, commit fixed, update the confs, etc. > So that was already something :) Indeed :) Stef > > > On Thu, Jul 11, 2013 at 4:14 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 10, 2013, at 10:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys >> >> I did a couple of things related to Glorp. I commited 2 fixes related to the connection pool. >> Also, for the native postgres driver, I adapted the pool we have for OpenDBXDriver. It's quite ugly because we are duplicating quite a lot of code, but the hierarchy make things complicated here and I don't have more time to improve it (at least not right now). If someone wants to give it a shoot :) You can give it as an exercise to a student hahaha. >> >> So...to sum up, some fixes in GlorpOpenDBXDriver and the new connection pool to >> GlorpDriverPostgreSQL. >> > > Hi mariano > > I think that this is important that you allocate a certain percentage of your dev time to improve the tools > you use else there is no possibility of progress. I would not wait for a student to fix code that > nobody in our team (except esteban probably) ever used. > > Stef > >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

July 13, 2013

Re: [Pharo-dev] Project Catalog getting out slowly :)

by Camillo Bruni

How do you generate this? On 2013-07-13, at 14:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I start to be able to generate such files for a Pharo project catalog > > <Soup.html><XMLWriter.html> > > I added some metadata to configuration files and it pays off. > > Stef

July 13, 2013