November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

by Henrik Nergaard

| dct arr | dct := IdentityDictionary new. arr := #( #valueOfProperty: #valueOfProperty:ifAbsent: #valueOfProperty:ifAbsentPut: #setProperty:toValue: #hasProperty: ). Morph withAllSubclasses do: [ :class | class methods do: [ :each | each ast allChildren select: [ :c | c isMessage and: [ arr includes: c selector ] ] thenDo: [ :c | dct at: c selector ifPresent: [ :col | col add: c ] ifAbsentPut: [ OrderedCollection with: c ] ] ] ]. dct ------------------ Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Thursday, November 3, 2016 8:48 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty: I would like to be able to compare the **arguments** passed to setProperty:toValue: and the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:, and hasProperty: I quite sure that we will discover more deadcode in morphic. Any ideas? PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns. There are plague and lead to shitty and crappy code. Stef

Nov. 3, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Thierry Goubier

Le 03/11/2016 Ã 19:25, Esteban Lorenzano a Ã©crit : > >> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto >> <casimiro.barreto(a)gmail.com <mailto:casimiro.barreto@gmail.com>> wrote: >> >> BTW, the threaded version requires to be run as super user because it >> tries to do a pthread_setschedparam(). I tried to fiddle with >> /etc/security/limits.conf... but it's not something fancy to doâ¦ > > no, is not hard. > you just need to add this file: > > pharo.conf > *hardrtprio2 > *soft rtprio2 > > to: > > /etc/security/limits.d And reboot for this to be applied. Thierry > > Esteban > >> >> Best regards, >> >> Casimiro Barreto >> >> Em 03-11-2016 13:53, Thierry Goubier escreveu: >>> Hi Esteban, >>> >>> Another question about Pharo 64 bits. >>> >>> Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 >>> provides them with the same version numbers, more or less. >>> (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, >>> SDL and ssh are the exact same versions). >>> >>> Collectively, those three libs are ~ 5M. >>> >>> Thierry >>> >>> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>>: >>> >>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ >>> <http://bintray.com/estebanlm/pharo-vm/build#files/> >>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip >>> <http://files.pharo.org/get-files/60/pharo-64.zip> >>> >>> this is still not official (thatâs why is not in official place) >>> so there are a couple of known problems: >>> >>> - version format is different, and that breaks some things in >>> image that depends on it to know what happens >>> - command line is different and probably youâll need to play a >>> bit with options (one or two dashes). >>> - UFFI has some failing tests (but most of it works). >>> >>> I would appreciate some help to report and/or fix the emerging >>> problems. >>> >>> cheers, >>> Esteban >>> >>>> On 28 Oct 2016, at 10:39, Thierry Goubier >>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> anybody knows how to get (and test) the 64bits version of the >>>> Pharo vm and image? >>>> >>>> Thanks, >>>> >>>> Thierry >>> >>> >> >> >> -- >> The information contained in this message is confidential and intended >> to the recipients specified in the headers. If you received this >> message by error, notify the sender immediately. The unauthorized use, >> disclosure, copy or alteration of this message are strictly forbidden >> and subjected to civil and criminal sanctions. >> >> == >> >> This email may be signed using PGP key *ID: 0x4134A417* >

Nov. 3, 2016

About setProperty:toValue: vs. valueOfProperty:

by stepharo

I would like to be able to compare the **arguments** passed to setProperty:toValue: and the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:, and hasProperty: I quite sure that we will discover more deadcode in morphic. Any ideas? PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns. There are plague and lead to shitty and crappy code. Stef

Nov. 3, 2016

Re: [Pharo-dev] why RBComment is not called RBCommentNode

by John Brant

> On Nov 3, 2016, at 11:46 AM, stepharo <stepharo(a)free.fr> wrote: > > >> A comment isnât code. The nodes are for code. A comment is more like a token â RBComment basically has the same two instance variables as RBToken. Should tokens also be nodes? For example, should a left paren token be represented as a node? >> >> If a comment is a node, how is it visited? >> For example, if you have (âcomment1â self âcomment2â foo: âcomment3â a bar: âcomment4â b âcomment5â), what is the traversal order for the nodes? > To reproduce the code as it was typed why the representation a message is not a sequence. because you need to encode that you > have comment1 and self and comment2 But how does this fit with a tree structure. For example, should âcomment5â be associated with the âbâ variable node, or the #foo:bar: message, or the sequence node that contains the #foo:bar: message, or the block or method node that contains the sequence node. You can choose, but only the writer of the comment can tell if you are right. > We do not have a structure that is responsible for that order. > We could have two entries in AST node; > one discrete where you can cherrypick what you want receiver arguments selector > and one that represent the node placement. > > Now when we emit bytecode comment would do nothing. > > How having them as token helps? You will visit the receiver and check if it has a token and place it. > I found that strange that comments are not part of the code tree as first class citizen. Tokens are essentially what they are now â although they arenât in the RBToken hierarchy. So far, the only advantages that Iâve heard you mention for nodes are visiting nodes and having a parent. The example above shows why neither of these are valid â you canât determine what is the correct parent for the comment. Anyway, I think comments should not be in code, but rather on code. When you add a comment, you would select a node or nodes that it applied to. When viewing a method, the comment could be displayed inline (like we have now), off to the side like reviewer comments in word processors, or a highlight that when you move the mouse over would show in a popup. Furthermore, there could be different comment types. For example, one could have design comments, todo/review comments, example code comments, bug fix comments, etc. The code view could be customized to show each one differently. Comments could have pictures and other non-string items. Having comments as objects outside the methodâs source string would allow them to be easily searched. For example, someone could search for a certain bug fix. Currently, if a bug fix id is in a comment, it requires a full text search of all method text. This is slow. Therefore, many companies start adding these bug fix ids to the code as symbols so that a senders search will work. Iâve seen companies that put symbols like #Fix12345 as statements inside of methods. However, this doesnât work for Smalltalkâs that remove unused literals, so in those cases they do something like adding a statement like #Fix12345 == #Fix12345 which generally isnât optimized away. In addition to comments, I believe that annotations (not primitives) should be on code instead of in code like they are now. With a good implementation one could unify the concepts of comments and annotations. >> Furthermore, if comments are nodes, how do they affect all of the code rewriting and validation that is part of the RB and its rewrite tools > With comments cannot act as nullobjects for such operation? Yes, someone could spend time making all of this work with the existing code. However, why not fix the real problem in that comments and methods should not be a single string, but rather objects. John Brant

Nov. 3, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Esteban Lorenzano

> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > > BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to doâ¦ no, is not hard. you just need to add this file: pharo.conf * hard rtprio 2 * soft rtprio 2 to: /etc/security/limits.d Esteban > > Best regards, > > Casimiro Barreto > > Em 03-11-2016 13:53, Thierry Goubier escreveu: >> Hi Esteban, >> >> Another question about Pharo 64 bits. >> >> Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. >> (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions). >> >> Collectively, those three libs are ~ 5M. >> >> Thierry >> >> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ <http://bintray.com/estebanlm/pharo-vm/build#files/> >> Image here: http://files.pharo.org/get-files/60/pharo-64.zip <http://files.pharo.org/get-files/60/pharo-64.zip> >> >> this is still not official (thatâs why is not in official place) so there are a couple of known problems: >> >> - version format is different, and that breaks some things in image that depends on it to know what happens >> - command line is different and probably youâll need to play a bit with options (one or two dashes). >> - UFFI has some failing tests (but most of it works). >> >> I would appreciate some help to report and/or fix the emerging problems. >> >> cheers, >> Esteban >> >>> On 28 Oct 2016, at 10:39, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> Hi all, >>> >>> anybody knows how to get (and test) the 64bits version of the Pharo vm and image? >>> >>> Thanks, >>> >>> Thierry >> >> > > > -- > The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. > > == > > This email may be signed using PGP key ID: 0x4134A417

Nov. 3, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Casimiro de Almeida Barreto

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do... Best regards, Casimiro Barreto Em 03-11-2016 13:53, Thierry Goubier escreveu: > Hi Esteban, > > Another question about Pharo 64 bits. > > Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides > them with the same version numbers, more or less. > (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, > SDL and ssh are the exact same versions). > > Collectively, those three libs are ~ 5M. > > Thierry > > 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > <http://bintray.com/estebanlm/pharo-vm/build#files/> > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > <http://files.pharo.org/get-files/60/pharo-64.zip> > > this is still not official (thatâs why is not in official place) > so there are a couple of known problems: > > - version format is different, and that breaks some things in > image that depends on it to know what happens > - command line is different and probably youâll need to play a bit > with options (one or two dashes). > - UFFI has some failing tests (but most of it works). > > I would appreciate some help to report and/or fix the emerging > problems. > > cheers, > Esteban > >> On 28 Oct 2016, at 10:39, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi all, >> >> anybody knows how to get (and test) the 64bits version of the >> Pharo vm and image? >> >> Thanks, >> >> Thierry > > -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

Nov. 3, 2016

TheManifestBuilder>>#packageNameOf:

by stepharo

Still a name around https://pharo.fogbugz.com/f/cases/19282/Still-name-used The method Object>>#name called from TheManifestBuilder>>#packageNameOf: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. Select Proceed to continue, or close this window to cancel the operation. Stef

Nov. 3, 2016

Re: [Pharo-dev] why RBComment is not called RBCommentNode

by stepharo

https://pharo.fogbugz.com/f/cases/19281/We-should-improve-the-class-comment… If we would have better comments.... a kind of a dream. Stef

Nov. 3, 2016

Re: [Pharo-dev] [Seaside-dev] Build failures

by Sven Van Caekenberghe

> On 3 Nov 2016, at 15:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I decided to shut down the slave for now. > > OK, Thanks. My builds are started to return to normal, so this seems to be working.

Nov. 3, 2016

Re: [Pharo-dev] some little static analysis with great impact

by stepharo

Le 3/11/16 Ã 15:52, Esteban Lorenzano a Ã©crit : > wouldnât this be better to solve this with QA? but QA needs the analysis first. > >> On 3 Nov 2016, at 15:17, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I often end up forgetting a period. >> >> printOn: aStream >> super printOn: aStream. >> aStream nextPutAll: ' "' >> aStream nextPutAll: contents. >> aStream nextPutAll: '" '. >> >> >> And statically the system could see it with a simple heuristics: >> >> if the message as the same name as self, super, a tmp or an argument >> >> May be there is a missing period. >> >> Could the compiler get this analysis? >> >> Stef >> >> > >

Nov. 3, 2016