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

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 20, 2013

May 20, 2013

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

1 0

AsmJit-Core not in Pharo30 repository
by Pavel Krivanek May 19, 2013

May 19, 2013

Hi, the package AsmJit-Core has in Smalltalkhub Pharo30 repository no version. Cheers, -- Pavel

3 8

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 19, 2013

May 19, 2013

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

1 0

[update 3.0] #30146
by Marcus Denker May 19, 2013

May 19, 2013

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 19, 2013

May 19, 2013

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

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 19, 2013

May 19, 2013

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

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 19, 2013

May 19, 2013

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

1 0

[update 3.0] #30145
by Marcus Denker May 19, 2013

May 19, 2013

1 0

Fwd: NB primitives inheritance
by Igor Stasenko May 19, 2013

May 19, 2013

---------- 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.

1 0

Fwd: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition
by Ciprian Teodorov May 19, 2013

May 19, 2013

---------- 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

2 1