- Pharo-dev - lists.pharo.org

[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

[Pharo-project] XPath issue ?
by Herve Verjus May 18, 2013

May 18, 2013

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

4 6

Small Methods dont need comments , true or myth ?
by dimitris chloupis May 18, 2013

May 18, 2013

I really enjoy smalltalk, every small thing that I discover every day. But there is one thing that really annoys me. The bold claim that small functions do not need comments. There is of course a level of truth that when a function/methods is well formated and follows the common logic rules of readable code a comment should not be needed for what it takes 10 lines or less of code to explain. But then that is also an illusion. The problem is that the code never explains the why. And why can be very important in understanding the code. Also a big issue I have with smalltalk in general. All this spaggeti mess I see unfold before my eyes in every library I see. One method calling another method which calls (excuse me, I should have said "sends a message") another and before you know you forget where you started and where is the end. Its the definition of Code Labyrinth. All this hectic browsing around could have been avoided so easily with a single comment. Its those moments you beg for a comment or some documentation. So my message to this list is to express my discomfort on this and ask Is it me or is this a really bad code practice afterall ? I am new to smalltalk so maybe I miss something or maybe things get easier in the future with more experience. But something it tells me inside that I will never get used to this , maybe I will learn to tolerate it , but its so far away from my way of thinking I dont think it has much chance into integrating in my brain. The thing is that I am quite the opposite , I am a comment and documentation freak. You may think I do it just to be awared the oscar of amazing readable coding but nothing can be further from the truth. I may be coding for 25 years now but it was never something serious , I am no pro and certainly not a serious coder. I just like to mess around with code, thats all. For me its a matter of survivability , if I dont comment or document I will quickly forget why I code these things anyway. Its so easy for me to forget and be confused and I find in this case smalltalk code is not as forging to coders like me. So I would like to hear you thoughts on this as much more experience smalltalk coders than me.Â I would like to note here that I am also a big fan of small methods and that my questionis not related to whether methods should be kept small and readable but whether comments are really needed for those methods.

7 11

[update 3.0] #30144
by Marcus Denker May 18, 2013

May 18, 2013

30144 ----- 10666 FileList should work on any FileSystem https://pharo.fogbugz.com/f/cases/10666 10664 Unify and clean a bit the CommandLine class comments https://pharo.fogbugz.com/f/cases/10664 10663 RPackageOrganizer out of sync https://pharo.fogbugz.com/f/cases/10663 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/UpdateStreamer-Core-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-MarcusDenker.denker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1124.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelCommandLineHandler-Marcus… http://smalltalkhub.com/mc/Pharo/Pharo30/main/ConfigurationCommandLineHandl… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AndreasProfiler-MarcusDenker.…

1 0

TxTextLayout
by Camillo Bruni May 18, 2013

May 18, 2013

I have a question concerning the new TxText layout. How hard is it support inline non-text nodes (aka inline morphs) in a text layout? My dream is still to be able to drag and drop an "instance" from an inspector to a workspace and do some operations on it using standard smalltalk. The only difference here would be instead of using a variable or expression to get an instance of something I would have a textual/visual node directly representing an instance! best regard, camillo

7 15