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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

May 19, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

May 19, 2013

Re: [Pharo-dev] AsmJit-Core not in Pharo30 repository

by Marcus Denker

Ok, I think I have copied over all the missing packaged. On May 17, 2013, at 3:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > of course SmartSuggestions and NodeNavigation are dependent on this packages :-) > > On Fri, May 17, 2013 at 3:56 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Please, can you somehow place the packages there? I cannot test morphic reloading without it. > Some package is dependent on ConfigurationOfNodeNavigation. > > -- Pavel > > > On Fri, May 17, 2013 at 3:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 17, 2013, at 3:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> ...and some other AsmJit packages, ConfigurationOfNodeNavigation and ConfigurationOfSmartSuggestions >> > > Yes, we need to improve the setupâ¦ right now we commit to pharo and then merge later with upstream. > This is not good. > >> -- Pavel >> >> On Fri, May 17, 2013 at 3:30 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> the package AsmJit-Core has in Smalltalkhub Pharo30 repository no version. >> >> Cheers, >> -- Pavel >> > > >

May 19, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 2 regressions found. Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses

May 19, 2013

[update 3.0] #30145

by Marcus Denker

May 19, 2013

Fwd: NB primitives inheritance

by Igor Stasenko

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 19 May 2013 06:11 Subject: Re: NB primitives inheritance To: nativeboost(a)googlegroups.com, Pharo Development <Pharo-project(a)lists.gforge.inria.fr> On 19 May 2013 04:26, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > yep I agree with your arguments... what about selfInstance (because on the > class side 'self' means the current class, and Instance will make us think > that is an instance of it)? > i don't know.. maybe 'newInstance' then? i wish i could find a name which is short and precise enough to express what is behind it. (i cc to Pharo-dev list, asking for help). > > On Sun, May 19, 2013 at 3:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 18 May 2013 22:26, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: >> > >> > >> > On Thursday, March 21, 2013 12:54:23 PM UTC+1, Igor Stasenko wrote: >> >> >> >> On 21 March 2013 12:21, Ciprian Teodorov <ciprian....(a)gmail.com> wrote: >> >> > >> >> > On Mar 21, 2013 12:03 PM, "Igor Stasenko" <sigu...(a)gmail.com> wrote: >> >> >> >> >> >> On 5 March 2013 22:38, Ciprian Teodorov <ciprian....(a)gmail.com> >> >> >> wrote: >> >> >> > Yeah traits seem to work nicely... >> >> >> > >> >> >> does self works that way (as return type)? >> >> >> >> >> >> never tried nor intended it to work. >> >> >> But yeah, you found a nice use case :) >> >> >> >> >> > If i remember correctly, self as return type does not work >> >> > directly... >> >> > Though we can make it work easily(just a little patch on return type >> >> > parsing) however just doing that raises inheritance problems, since >> >> > in >> >> > the >> >> > generated code we will have a hard coded class. >> >> > So that explains my initial question? How can we get around this, and >> >> > have >> >> > diferrent classes instantiated depending on the receiver of the call >> >> > >> >> yeah.. >> >> you want a single method which serves to instantiate different >> >> subclass instances. >> >> >> >> 'self' as return type can do that.. At least for pointer-type objects >> >> (no variable objects) >> >> you can instantiate them based on receiver (since the method is on >> >> class side, the receiver is the class to instantiate). >> >> >> >> I would modify NBExternalObjectType to: >> >> 1. add a flag, to use receiver of method for instantiation >> >> 2. modify #coerceReturnValue: to generate different code when flag is >> >> true. >> >> >> >> 3. setting this flag to true in NBFFICallout>>returnType:, if: >> >> - type name is 'self' >> >> - method belongs to class side >> >> - method's class is a subclass of NBExternalObject >> >> >> > Hi all, >> > I've just commited an implementation of this receiver-based >> > instantiation in >> > NativeBoost-Core-CiprianTeodorov.123. >> >> >> >> (but im not sure that using 'self' to denote that type is good idea, >> >> maybe using different name will be better). >> >> >> > Igor since you were not sure about using 'self' as type I called it >> > 'receiver'... What do you think? >> > >> >> I think this having same problem as with 'self'. >> What prevents me (or someone else) to think that 'self' or 'receiver' >> special type >> means "disregard a function return value, and answer a receiver of >> message as a primitive result, e.g. >> equivalent to: >> >> someMethod: args >> >> ... do something. ... >> >> ^ self >> >> I think 'receiverClass' is better.. but still ambiguous: does it means >> "answer the class of receiver" >> or "create an new instance of same class as receiver?" >> >> What about, 'receiverClassInstance'? It is very precise, which i >> like.. but it looks too long , which i don't like. >> :) >> >> > for example: >> > if we have two classes NPointB as subclass of NPointA and: >> > >> > NPointA class>>x: x y: y >> > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: >> > errorCode> >> > ^self nbCallout >> > function: #(receiver PointCreate(int x, int y)) module: self >> > nbLibraryNameOrHandle >> > >> > NPointA x: 3 y: 4. "creates instance of NPointA" >> > NPointB x: 5 y: 6. "creates instance of NPointB" >> > >> > cheers, >> > >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.

May 19, 2013

Re: [Pharo-dev] 3.0 git tracker

by Igor Stasenko

On 18 May 2013 02:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Pharo 3.0 is now properly tracked on github > > - https://github.com/pharo-project/pharo-core > - the update messages are properly shown > - html output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - diff output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - patch output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… You are my hero! Now can we have same for VM sources? I would really love to simplify a process of changing VM by simply modifying file either on disk (in platform sources) or in image (VMMaker & friends) and then do git ci -m "new fix/feature integrated" :) -- Best regards, Igor Stasenko.

May 19, 2013

Re: [Pharo-dev] Fwd: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Igor Stasenko

On 19 May 2013 01:22, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > Date: Sat, May 18, 2013 at 10:11 PM > Subject: Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in > function definition > To: Pharo-project(a)lists.gforge.inria.fr > > > Hi guys, > > Here is another idea which I think is nice, without disabling the > typechecker or anything: > > I suppose the LGitObjectExternal is a subclass of NBExternalObject > in LGitObjectExternal implement the #git_object_lookup as follows: > > LGitObjectExternal>primitiveLookupIn: repo id: id type: type > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: > errorCode> > ^self call: #(git_return_t git_object_lookup(self, git_repository_ptr > repo, git_oid_ptr id, git_otype type)) > > then all the calls to #primitiveLookupIn:id:type: would succeed in all > subclassed of LGitObjectExternal without doing anything special. > You mean using "self" special argument. Yes. I like this construct a lot , it allow to avoid unnecessary type checks (since we know the class of receiver, we know it's layout and we can make much more assumption about it than an object passed as a method argument or from somewhere else). The marshaller of NBExternalObjectType actually checks for that case and do not generates code for type check, since type is known: the receiver will be either instance of class with this method or one of its subclasses. Since in our smalltalk implementation, slots reserved for instances in class is invariant for all of its subclasses, there is no danger in accessing instance variable (handle in our case) by its index, for any (sub)instance of the class. Unfortunately, you still need a check when you need to put method into other class which takes a (sub)instance of your external object as argument. For such cases, 'self' special argument in function signature apparently does not apply. > cheers, > ciprian > > > On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> I have a wish for NativeBoost (which is probably on your list anyway Igor, >> just wanted to put it out there): function definitions should be able to >> understand that I want to accept any object of a hierarchy. >> >> Here's my use case: >> >> self call: #(git_return_t git_object_lookup(LGitCommitExternal * >> object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> This function takes a pointer to any of LGitCommitExternal, >> LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was >> to create a superclass LGitObjectExternal and use that superclass in the >> function like so: >> >> self call: #(git_return_t git_object_lookup(LGitObjectExternal * >> object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> But that gives me an error. So for now I can either use a dummy object >> (like NBExternalObject) and then convert from that or I have to implement >> the same function thrice in the different object flavors. >> Being able to use a superclass would just be awesome! >> >> Cheers, >> Max > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

May 19, 2013

Fwd: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Ciprian Teodorov

---------- Forwarded message ---------- From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> Date: Sat, May 18, 2013 at 10:11 PM Subject: Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition To: Pharo-project(a)lists.gforge.inria.fr Hi guys, Here is another idea which I think is nice, without disabling the typechecker or anything: I suppose the LGitObjectExternal is a subclass of NBExternalObject in LGitObjectExternal implement the #git_object_lookup as follows: LGitObjectExternal>primitiveLookupIn: repo id: id type: type <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: errorCode> ^self call: #(git_return_t git_object_lookup(self, git_repository_ptr repo, git_oid_ptr id, git_otype type)) then all the calls to #primitiveLookupIn:id:type: would succeed in all subclassed of LGitObjectExternal without doing anything special. cheers, ciprian On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske(a)gmail.com> wrote: > I have a wish for NativeBoost (which is probably on your list anyway Igor, > just wanted to put it out there): function definitions should be able to > understand that I want to accept any object of a hierarchy. > > Here's my use case: > > self call: #(git_return_t git_object_lookup(LGitCommitExternal * > object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > This function takes a pointer to any of LGitCommitExternal, > LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this > was to create a superclass LGitObjectExternal and use that superclass in > the function like so: > > self call: #(git_return_t git_object_lookup(LGitObjectExternal * > object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > But that gives me an error. So for now I can either use a dummy object > (like NBExternalObject) and then convert from that or I have to implement > the same function thrice in the different object flavors. > Being able to use a superclass would just be awesome! > > Cheers, > Max > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

May 18, 2013

Re: [Pharo-dev] Fwd: [Pharo-project] XPath issue ?

by StÃ©phane Ducasse

thanks hernan! Stef On May 18, 2013, at 10:04 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > I submitted a fix, please check with the latest version at > > http://ss3.gemstone.com/ss/XPath.html > > cheers, > > HernÃ¡n > > El 14/05/2013 4:46, Herve Verjus escribiÃ³: >> Hello, >> >> Erwan gave me a piece of code I will test in the next couple of days :-) >> >> Thanks >> >> Herve >> >> StÃ©phane Ducasse wrote: >>> HI guys may be this mail passed under the radar >>> >>> Stef >>> >>> Begin forwarded message: >>> >>>> *From: *Herve Verjus <herve.verjus(a)univ-savoie.fr >>>> <mailto:herve.verjus@univ-savoie.fr>> >>>> *Subject: **[Pharo-project] XPath issue ?* >>>> *Date: *May 8, 2013 11:23:01 PM GMT+02:00 >>>> *To: *Pharo-project(a)lists.gforge.inria.fr >>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>> *Reply-To: *Pharo-project(a)lists.gforge.inria.fr >>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>> >>>> Dear All, >>>> >>>> I try a very simple example: >>>> >>>> mydoc.xml document: >>>> >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> >>>> <first> >>>> <second> >>>> <item type="attvalue">nodevalue</item> >>>> </second> >>>> </first> >>>> >>>> >>>> And the Pharo code found in the book.pharo-project.org >>>> <http://book.pharo-project.org>: >>>> >>>> | doc results | >>>> doc := XMLDOMParser parseFileNamed: 'mydoc.xml'. >>>> results := ( XPath for: 'first' ) in: doc. >>>> results explore >>>> >>>> >>>> As a result, I obtain an empty OrderedCollection...It should contain >>>> an element. Then a make some changes using different XPath expressions >>>> (i.e. '/first/second/item/@type", etc.) but no way. >>>> >>>> Then I discover the first element of the XPath expression must not be >>>> the root of the XML doc. If I change the mydoc.xml, introducing a new >>>> root element: >>>> >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> >>>> <foo> >>>> <first> >>>> <second> >>>> <item type="attvalue">nodevalue</item> >>>> </second> >>>> </first> >>>> </foo> >>>> >>>> Everything is ok (the same code as above). Here, XPath assumes that >>>> the first tag we are looking for is not the root of the doc, otherwise >>>> it fails. I'm not so sure but it seems that such implementation >>>> doesn't follow the XPath specs. I tried another example from >>>> http://www.w3schools.com/xpath/xpath_syntax.asp and same results: I >>>> obtain an empty collection when using an XPath expression beginning >>>> with the 'bookstore' tag, the root element of the doc: >>>> >>>> | doc results | >>>> doc := XMLDOMParser parseFileNamed: 'books.xml'. >>>> results := ( XPath for: '/bookstore' ) in: doc. >>>> results explore >>>> >>>> Maybe, I missed something... >>>> >>>> Note: I have had to replace the isTag (deprecated) with isElement in >>>> some piece of XPath code. >>>> >>>> Cheers, >>>> >>>> Herve >>>> >>> >> >> > >

May 18, 2013