- Pharo-dev - lists.pharo.org

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

by stepharo

Thanks henrik this is cool and now I can do diffs and other. I started to get the list of sender of setProperty:toValue: and one by one analyse them. Le 3/11/16 Ã 21:25, Henrik Nergaard a Ã©crit : > | 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. 4, 2016

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

by Nicolas Cellier

2016-11-04 1:54 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > > On Nov 3, 2016, at 4:03 PM, stepharo <stepharo(a)free.fr> wrote: > > > >> 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. > > How tokens solves this problem? > > I think that we do not really care one objective is to be able to > recreate the code from the tree. I worked on a project in C > > where the guys want to know if the code is well commented and we built > heuristics to associate the comments to the closest node. > > The nodes have comments and the comments have their source and position so > you can recreate the code from the tree already. It may not be as easy as > you want, but all the information is there. > > > >>>> 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. > > > > Marcus did that during his phd and he blew up memory. So after we got > a guy that worked on tree compression but he never finished. > > Because this is the part that makes all these ideas flying or not. > > From what I remember, ASTs are roughly 10x the size of the code string. > Iâm not suggesting holding on to them in the image when they can be > loaded/built from a file like the method sources currently are. Instead, we > can associate a comment/annotation to a particular node in the AST without > having to keep the AST around. For example, we could say that some comment > is associated to the 4th node visited from the standard AST traversal. We > donât need to keep the AST around since we can recreate it and the 4th node > visited will be the same. > > > John Brant > But this vision is a bit static. Code is living. Shall these annotations be lost on next refactoring? Or are we going to diff the two AST and salvage as many annotations as we can? Or are we going to keep an history of these comments in the versioning system?

Nov. 4, 2016

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

by John Brant

> On Nov 3, 2016, at 4:03 PM, stepharo <stepharo(a)free.fr> wrote: > >> 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. > How tokens solves this problem? > I think that we do not really care one objective is to be able to recreate the code from the tree. I worked on a project in C > where the guys want to know if the code is well commented and we built heuristics to associate the comments to the closest node. The nodes have comments and the comments have their source and position so you can recreate the code from the tree already. It may not be as easy as you want, but all the information is there. >>>> 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. > > Marcus did that during his phd and he blew up memory. So after we got a guy that worked on tree compression but he never finished. > Because this is the part that makes all these ideas flying or not. >From what I remember, ASTs are roughly 10x the size of the code string. Iâm not suggesting holding on to them in the image when they can be loaded/built from a file like the method sources currently are. Instead, we can associate a comment/annotation to a particular node in the AST without having to keep the AST around. For example, we could say that some comment is associated to the 4th node visited from the standard AST traversal. We donât need to keep the AST around since we can recreate it and the 4th node visited will be the same. John Brant

Nov. 4, 2016

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

by John Brant

> On Nov 3, 2016, at 1:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> 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 Has anyone tried this in a docker container environment? Someone tried to setup a docker container with the VM for me, but the VM wouldnât start. After a few attempts, I decided that we could use the non-heartbeat thread VM. John Brant

Nov. 3, 2016

Re: [Pharo-dev] pillar highlight text in code

by Nicolai Hess

2016-11-03 23:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Can we highlight a piece of code? > In the updated PBE (Reflection chapter) there is the text: > "Change the definition of Integer>>>factorial by inserting the underlined > expression as shown below" > But I can not see the "underline" in the code example. Is it even possible > to add such text properties to a "code-style" formatted text ? > > BTW, the method name is wrong (in both places) > Integer>>#factorial > not > Integer>>>factorial > actually all code examples in that chapter uses >>> instead of >>#

Nov. 3, 2016

pillar highlight text in code

by Nicolai Hess

Can we highlight a piece of code? In the updated PBE (Reflection chapter) there is the text: "Change the definition of Integer>>>factorial by inserting the underlined expression as shown below" But I can not see the "underline" in the code example. Is it even possible to add such text properties to a "code-style" formatted text ? BTW, the method name is wrong (in both places) Integer>>#factorial not Integer>>>factorial

Nov. 3, 2016

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

by Yuriy Tymchuk

> On 3 Nov 2016, at 22:05, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Can we have rules about indentation? Yes, we can. I think that even easier heuristic would be to check if a unary is separated from the receiver by a line break.

Nov. 3, 2016

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

by Thierry Goubier

Le 03/11/2016 Ã 22:17, Casimiro de Almeida Barreto a Ã©crit : > 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. > > There are some troubles with ssl in Fedora (didn't test it in Ubuntu). > While loading Woden (for instance) there's a crash (exception) because > ZdcPluginSSLSession fails. Yes, this is the SSL plugin not being compiled in. Github-based projects may still be accessed by using gitfiletree (or a command-line wget + filetree). FFI-support isn't complete yet as well so this would probably make Woden non-working for the time being. Thierry

Nov. 3, 2016

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

by Thierry Goubier

Le 03/11/2016 Ã 22:16, Eliot Miranda a Ã©crit : > Hi Thierry, > > On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > 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> > <mailto:casimiro.barreto@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. > > > To be accurate, one only needs to login again. I'm too accustomed to a single user laptop :) But that 64bits version working is really great. Thierry

Nov. 3, 2016

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

by phil＠highoctane.be

Ha, I was busy with these yesterday. Worse bit is not the morphExtension or otherProperties stuffed into them, but rather the fact that when one puts a value into #paneColor for example, themes are not respecting that. The morphExtension rationale is to have lightweight and heavyweight morphs. It is not easy to balance what should be put into a method or kept into those extra places. Now try to make a SystemWindow use the selected window color in the little downarrow menu. You'll get into the morphs creating the sides and having a transparent fillstyle, and override the paneColor thing. I am glad to have the dark theme. I am sad to not be able to set colors on my system windows easily (Yeah, I like the Play-Doh UI). Maybe subclassing those Morphs making up SystemWindows would be a good idea so that we can start having a theming for the windows borders and title. I want put the TilingWindowManager icons in the SystemWindow title bar. So, I need something more focused than just an aligment morph etc. So we will be able to plugin a couple interesting features in it. Phil On Thu, Nov 3, 2016 at 8:47 PM, stepharo <stepharo(a)free.fr> wrote: > 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