September 2015 - Pharo-users

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by phil＠highoctane.be

Which is a pain as when I copy/paste a shell script full of those, I won't do that. Is this also doing the same thing in blocks like: [[[label=.bashrc|caption=Ajouts Ã .bashrc|language=bash ${SOMEVAR:-} ]]] I am not gonna escape those things as what happens is copy/pasting code. That there are no such directives in Markdiwn is what makes it nice to use and hassle free. I would escape your directives and leave the core of the text alone. Well, what do you think? Phil On Wed, Sep 30, 2015 at 10:38 PM, Ferlicot D. Cyril < cyril.ferlicot(a)gmail.com> wrote: > Le 30/09/2015 22:32, phil(a)highoctane.be a Ã©crit : > > Downloaded the book-skeleton, patched the download script so that it > > gets the centos things right and the Pharo4VM. > > > > Now, changes in Pillar made my books unsuable, namely the introduction > > of things like this: > > > > ${tag:parameter=value|parameter2=value2}$ > > > > > > made contents with bash shell scripts unparsable. > > > > > > Yeah, but there are often such things. > > > > > > Like in: > > > > > > Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui > > couvre une pÃ©riode plus courte > > > > > > How do I solve that with the new markup? > > > > > > Phil > > > > > > > > You can just escape like this: > > Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui > couvre une pÃ©riode plus courte > > :) > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

Sept. 30, 2015

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by Ferlicot D. Cyril

Le 30/09/2015 22:32, phil(a)highoctane.be a Ã©crit : > Downloaded the book-skeleton, patched the download script so that it > gets the centos things right and the Pharo4VM. > > Now, changes in Pillar made my books unsuable, namely the introduction > of things like this: > > ${tag:parameter=value|parameter2=value2}$ > > > made contents with bash shell scripts unparsable. > > > Yeah, but there are often such things. > > > Like in: > > > Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui > couvre une pÃ©riode plus courte > > > How do I solve that with the new markup? > > > Phil > > > You can just escape like this: Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une pÃ©riode plus courte :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Sept. 30, 2015

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by phil＠highoctane.be

Downloaded the book-skeleton, patched the download script so that it gets the centos things right and the Pharo4VM. Now, changes in Pillar made my books unsuable, namely the introduction of things like this: ${tag:parameter=value|parameter2=value2}$ made contents with bash shell scripts unparsable. Yeah, but there are often such things. Like in: Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une pÃ©riode plus courte How do I solve that with the new markup? Phil On Wed, Sep 30, 2015 at 7:57 PM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 30/09/2015 18:38, phil(a)highoctane.be a Ã©crit : > > Hello, > > > > It may have been a long time without it but still... > > > > I ran the doc job on my CI and got this that wasn't working: > > > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,V… > > > > Hum, yes, but ... why remove the doc tools as this is quite an important > > thing to keep around for all Pharo versions? > > > > I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. > > Not good as I need to migrate these things for my customer as well. > > > > Phil > > Hi Phil, > > We removed the Pillar job for Pharo 3 because we introduced an new > feature not backward compatible. > So we freezed the Pillar version for Pharo 3. So we do not need a job > for it anymore since it will not change and we do not want to keep a red > job for "Pillar - Pharo 3 - Development". > > You can still load the stable version of Pillar in Pharo 3, but this > version will not evolve anymore. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

Sept. 30, 2015

Re: [Pharo-users] Custom type inference and RoelTyper

by Alexandre Bergel

Type system is particularly complicated. I did a first implementation (called Type4Pharo on smalltalkhub), but it does not go in the right direction. I will redo it completely. So, nothing will be ready until a few months. Alexandre > On Sep 30, 2015, at 10:01 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Good to hear! > > Do you have any time estimation (days/weeks)? Also I don't mind looking at something incomplete (after all I learned roassal just from source code ;)) > > Thanks, > Peter > From: Tudor Girba > Sent: â9/â30/â2015 9:43 PM > To: Any question about pharo is welcome > Cc: Moose-related development > Subject: Re: [Pharo-users] Custom type inference and RoelTyper > > Great news :) > > Doru > > On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Peter! > > I am currently working on gradual typing for Pharo. > I hope to have something ready for public consumption soon... > > Alexandre > > > > On Sep 30, 2015, at 8:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be maintained (last version 2013), and for my purposes is lacking. > > > > So do we have something more advanced, even at the expense of speed? > > > > Other alternative would be to either extend RoelTyper or write something custom that would be ran alongside RoelTyper. > > > > Examples of such extensions would be extracting the type from meta-annotations and the actual argument names. (e.g. if an argument is named aString, I can safely assume that it will be String). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 30, 2015

Re: [Pharo-users] Accessors vs instance variables

by Sven Van Caekenberghe

Hi, > On 30 Sep 2015, at 21:35, Lyn Headley <laheadle(a)gmail.com> wrote: > > Hello, > > As I understand it, in Smalltalk, the instance variables of a class C are "protected" - able to be referenced by methods of C or its subclasses, but not by other objects. This is a useful feature as it clearly points out which pieces of data are not available to other objects, and thereby simplifies code. > > However, I am often unsure of whether to use this feature or not, as it conflicts in my mind with the practice of using accessor methods. I like accessor methods because they make it easy to change behavior later -- If I have a dozen calls to an accessor method, then I only need to change it in one place. If these were instance variable references, I would have to do more work. The disadvantage of accessor methods is that they obscure the protected status of data -- it becomes unclear how protected an instance variable is meant to be. (Accessors also make it harder for me to find users of the data when browsing, when there are senders from totally unrelated classes, although I suspect I have just not figured out how to browse scoped in the right way for this). > > It occurs to me that a tool could be (easily?) developed that would solve this problem. It would take existing variable references and turn them into calls to accessor methods. That way, I could have protection when I want it, and easy ability to change code as well. Does something like this exist, or is it feasible to build? > > How do others think about this issue? > > -Lyn I think that with the current options in the tools (auto generation of accessors based on instance variables, checking references to instance variables, renaming either accessors or instance variables, syntax coloring) the difference between the two is becoming somewhat smaller. I used to consistently use accessors for the reasons you describe, but lately I find it more important to think as object oriented as possible, to maximise encapsulation and minimise the interface to the outside world. Now, I only add accessors if that really makes sense, the lack of accessors should then signal the private nature of the instance variable. Sven

Sept. 30, 2015

Re: [Pharo-users] Custom type inference and RoelTyper

by Peter Uhnak

Good to hear! Do you have any time estimation (days/weeks)? Also I don't mind looking at something incomplete (after all I learned roassal just from source code ;)) Thanks, Peter -----Original Message----- From: "Tudor Girba" <tudor(a)tudorgirba.com> Sent: â9/â30/â2015 9:43 PM To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch> Subject: Re: [Pharo-users] Custom type inference and RoelTyper Great news :) Doru On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: Hi Peter! I am currently working on gradual typing for Pharo. I hope to have something ready for public consumption soon... Alexandre > On Sep 30, 2015, at 8:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be maintained (last version 2013), and for my purposes is lacking. > > So do we have something more advanced, even at the expense of speed? > > Other alternative would be to either extend RoelTyper or write something custom that would be ran alongside RoelTyper. > > Examples of such extensions would be extracting the type from meta-annotations and the actual argument names. (e.g. if an argument is named aString, I can safely assume that it will be String). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2015

Code completion in comment pane and Pillar

by Peter Uhnak

Hi, Some time ago I ran into a problem with typing left brackets into comment pane. As you know, code blocks in Pillar are marked with [[[ However comment pane is subject to regular code completion of NECController, which means that every time I type '[' NEC converts it into '[ ]'. So if I type '[[[' then I get '[ [ [ ] ] ]'. Which is good in code, but not here. Now considering we are pushing for Pillar in comments I think this should be resolved. However I don't know how. a) disable code completion for comments (trivial, but loosing CC b) subclass NECController to disable this. This is probably lot more complex, because the current one is hard-wired via Smalltalk tools c) add configuration option to NECControler so it can run in different modes (still a lot of work) d) add setting to options to disable/enable CC in comments and let users decide. d) other better, faster, easier solution? >From future perspective b) could be used to provide more extensive code completion, specifically for Pillar. Thanks, Peter

Sept. 30, 2015

Re: [Pharo-users] Custom type inference and RoelTyper

by Tudor Girba

Great news :) Doru On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Peter! > > I am currently working on gradual typing for Pharo. > I hope to have something ready for public consumption soon... > > Alexandre > > > > On Sep 30, 2015, at 8:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to > be maintained (last version 2013), and for my purposes is lacking. > > > > So do we have something more advanced, even at the expense of speed? > > > > Other alternative would be to either extend RoelTyper or write something > custom that would be ran alongside RoelTyper. > > > > Examples of such extensions would be extracting the type from > meta-annotations and the actual argument names. (e.g. if an argument is > named aString, I can safely assume that it will be String). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2015

Accessors vs instance variables

by Lyn Headley

Hello, As I understand it, in Smalltalk, the instance variables of a class C are "protected" - able to be referenced by methods of C or its subclasses, but not by other objects. This is a useful feature as it clearly points out which pieces of data are not available to other objects, and thereby simplifies code. However, I am often unsure of whether to use this feature or not, as it conflicts in my mind with the practice of using accessor methods. I like accessor methods because they make it easy to change behavior later -- If I have a dozen calls to an accessor method, then I only need to change it in one place. If these were instance variable references, I would have to do more work. The disadvantage of accessor methods is that they obscure the protected status of data -- it becomes unclear how protected an instance variable is meant to be. (Accessors also make it harder for me to find users of the data when browsing, when there are senders from totally unrelated classes, although I suspect I have just not figured out how to browse scoped in the right way for this). It occurs to me that a tool could be (easily?) developed that would solve this problem. It would take existing variable references and turn them into calls to accessor methods. That way, I could have protection when I want it, and easy ability to change code as well. Does something like this exist, or is it feasible to build? How do others think about this issue? -Lyn

Sept. 30, 2015

Re: [Pharo-users] Custom type inference and RoelTyper

by Alexandre Bergel

Hi Peter! I am currently working on gradual typing for Pharo. I hope to have something ready for public consumption soon... Alexandre > On Sep 30, 2015, at 8:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be maintained (last version 2013), and for my purposes is lacking. > > So do we have something more advanced, even at the expense of speed? > > Other alternative would be to either extend RoelTyper or write something custom that would be ran alongside RoelTyper. > > Examples of such extensions would be extracting the type from meta-annotations and the actual argument names. (e.g. if an argument is named aString, I can safely assume that it will be String). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 30, 2015