October 2015 - Pharo-users - lists.pharo.org

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

by stepharo

>>> We removed the Pillar job for Pharo 3 because we introduced an new >>> feature not backward compatible. >> >> Why is that a reason to remove the build? You have a configuration, >> don't you? > > I would suggest: move to a separate job that is run much less often > and doesn't keep so many old artifacts. That makes it easier to get > old stuff running again. + 10000

Oct. 3, 2015

Re: [Pharo-users] Some news from the growing pharo teacher front

by stepharo

+1 Stef Le 29/9/15 18:02, Johan Fabry a Ã©crit : >> On Sep 29, 2015, at 12:52, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: >> >> Hi, >> >> On 29/09/15 10:08, Stephan Eggermont wrote: >>> On 29-09-15 16:52, Offray Vladimir Luna CÃ¡rdenas wrote: >>>> Thanks for your interest. Please try this updated installation script [1]: >>> Is there a specific reason this is not a Metacello configuration? >>> >> Yep. I don't know how to do them ;-), a lot of stuff I need to learn to get a minimal interface working (now is Spec and GT, but in my list testing has high priority) and few time to hack on Pharo, so a script seemed like the easier approach to get the installation working. >> >> Now I have more time, so after finishing Spec-Glamour interface, I will try to learn more about Metacello and try a better way to install grafoscopio on pharo 4. > Try using Versionner (World->Tools->Versionner). I do not understand Metacello at all yet I was able to create a configuration in less than 30 minutes. There are also some tutorials on Youtube, but I donât have a link here, sorry. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > >

Oct. 3, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by stepharo

Why do you need that? Le 2/10/15 20:50, Peter UhnÃ¡k a Ã©crit : > Hi, > > What options do we have in terms of type annotations in Pharo? > > I stumbled upon TypePlug this > https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or > rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > which enabled type annotation for Squeak such as > ~~~~~~~~~~~~~~~~ > Fruit>>mixWith: aFruit <:type: Fruit :> > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > ~~~~~~~~~~~~~~~~ > Orange>>color > ^ (Color orange) <:type: Color :> > ~~~~~~~~~~~~~~~~ > (or even blocks) > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > ~~~~~~~~~~~~~~~~ > > obviously something like this wouldn't even compile in Pharo (does > Sqeak have different syntax for pragmas, or did the TypePlug change > the syntax?) > > And my question is... is there a port of this, or something similar? > > I've also found this > http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > Which is a framework for integrated testing that uses pragmas such as > ~~~~~~~~~~~~~~~~ > makeBatchWithdrawalOn: aDate note: aString > <fitTakes: #(#{Date} #{String})> > <fitReturns: #{Fixture}> > ^(BatchWithdrawalFixture date: aDate note: aString) > systemUnderTest: systemUnderTest > ~~~~~~~~~~~~~~~~ > > Right now I am exploring what options we have in Pharo in terms of > type annotations (before writing yet-another-library ;-)). > > Thanks, > Peter

Oct. 3, 2015

Re: [Pharo-users] Morph: event handler on wrong morph/submorph

by stepharo

Hi federico could you - show it to damien when he will come to Laplata? - could you produce a small video because I would like to share it with other teachers? Stef Le 28/9/15 18:59, Federico.Balaguer a Ã©crit : > Hello, > > I found a problem with BotArena > (http://smalltalkhub.com/#!/~FedericoBalaguer/BotArena) on Pharo 4. > > BotArena is an interactive robot simulation environment that we use in my > university to teach OOP basics. BotArena was developed as an instantiation > of BOSS (http://smalltalkhub.com/#!/~CAR/BOSS/) > > BotArena (as well as BOSS) has a window (Morph) that has three buttons and a > grid view that is subclass of BorderedMorph. The GridView can handle > RedButtons, a click on the grid adds a new robot to the simulation. > > The problem that raised on Pharo4 is that, after a RedButton event, any > event (focus to another pharo window or clicking on one of the buttons of > BotArena) will be handled by the GridView. > > It seems like the GridView retains the focus after the (first) RedButton > event was handled. > > Could someone help me to sort this one out? > > Thanks! Federico > > > > -- > View this message in context: http://forum.world.st/Morph-event-handler-on-wrong-morph-submorph-tp4852370… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Oct. 3, 2015

Re: [Pharo-users] NeoCSV and special handling for some columns

by stepharo

sven do you think that we should add this to the chapter? Le 28/9/15 16:42, Sven Van Caekenberghe a Ã©crit : >> On 28 Sep 2015, at 15:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> Imagine something like this: >> >> neoCSVReader := (NeoCSVReader on: stream). >> neoCSVReader >> separator: $,; >> recordClass: PriceRecord; >> addIgnoredField; "<name>" >> addField: #securityUniqueId: ; "<ticker>" >> addField: #date: converter: [ :string | Date readFrom: string readStream pattern: 'yyyymmdd' ]; "<date>" >> addFloatField: #open: ; "<open>" >> addFloatField: #high: ; "<high>" >> addFloatField: #low: ; "<low>" >> addFloatField: #close: ; "<close>" >> addIntegerField: #volume: . "<vol>" >> neoCSVReader skipHeader. >> priceRecords := neoCSVReader upToEnd. >> >> >> The #recordClass: is optional. If not, you can get an array of arrays instead. >> You can add #addIgnoredField for all the ones you want to ignore, then add the #addNumber: etc for the number ones, etc. > Correct. > >> To write a default empty value, I would use my own converter. Something like: >> >> addField: #stringcolumn: converter: [ :string | string isEmptyOrNil ifTrue: [ '' ] ]; >> addField: #numbercolumn: converter: [ :string | string isEmptyOrNil ifTrue: [ 0 ] ifFalse: [ NeoNumberParser parse: string ] ]; > Actually there is NeoCSVReader>>#emptyFieldValue: which you can use the configure the reader (but it counts for all fields). > >> Hope this helps. >> >> Cheers, >> >> >> >> On Mon, Sep 28, 2015 at 9:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> Hi, >> >> I have two problems I could not solve: >> >> 1. I would like to read only some columns: I have a large file with >> ~30 colums, but I am only interested on ~5 columns >> (not that important, I could pre-process the file) but anyway it would be >> nice to do it in smalltalk. >> >> 2. some columns will contain only strings (quoted values) and some only numbers, >> but the field may be empty, is it possible to define the default "emptyValue" as an >> - empty string for empty fields in the "string column" >> - 0 for empty fields in the "number column"? >> >> >> thanks >> in advance >> >> nicolai >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > >

Oct. 3, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by Stephan Eggermont

On 02-10-15 20:50, Peter UhnÃ¡k wrote: > What options do we have in terms of type annotations in Pharo? The only type annotations I've actually used in Pharo is Magritte Stephan

Oct. 3, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by Alexandre Bergel

> Well my primary motivation is that I need annotated code to be able to do full model reverse-engineering (that of itself is very hard task, however if you work only on constrained models that you've forward-engineered or control, it's significantly simpler). > In fact types are not enough because they do not tell things like cardinality and other features of relations between objects, but I will be adding that too, probably in similar fashion to MSE pragmas, since I am already using FAMIX model. (In fact FAMIX already annotates the type of it's own properties with <MSEProperty>.) Oh, okay! This has a radically different purpose than static typing then. There is a bit of work on that. For example google this: "Typing in Model Managementâ However I am not sure how practical it is. > As for the type of the types... I am not looking for battle-hardened solution, just something good-enough. Yes, but even this is not easy to get. > The benefit of using pragmas over comments is that I don't need to parse them and currently they look better (unlike comment they are nicely colored, instead of a block of text). This would be also fairly easy (it seems) to implement. > > Now for what you are proposing My proposal is actually very close to the optional types of Dart https://www.dartlang.org/articles/optional-types/ I plan to use these types in Pharo to do some static checking, checked execution mode, and providing additional analysis such as code coverage, code completion. I believe this is a very good tradeoff, however it is not sound. Gradual typing is, but it is significantly more complicated to implement I have the impression. > This however would require change to the syntax, which I'm not very keen on (and I cannot imagine that anyone would welcome syntax change). Changing the syntax is a very bad idea. Google GradualTalk to have an idea of what i mean. I played with GradualTalk, it works well on toy examples. However I cannot use it for my projects :-) > > Now as I mentioned, right now I'm exploring options that are available; my requirements only overlap of what real solution (whether annotations or gradual types) offer. So maybe I will settle on some custom-hacked pragmas until/if a mature solution emerges. > (Pragma annotations are also what I would go for if nothing better comes up). If you feel like going toward the annotations, then go for it! I will purpose the type declaration in comments because it fits better my needs. However, it should be quite trivial to bridge our two approaches. Alexandre > > Peter > > The email youâve sent a couple of days ago motivated me for continuing my effort. > > The two important design points of my implementation are as follow: > (A) - Types are specified in the method comment. Consider the following two examples: > -=-=-=-=-=-=-=-=-=-=-=-= > RBParser class>>parseMethod: aString > " > :: String -> RBProgramNode > â > ... > -=-=-=-=-=-=-=-=-=-=-=-= > The method parseMethod: accepts a string as argument and return a program node > > -=-=-=-=-=-=-=-=-=-=-=-= > exampleLabelledIf > " > var b: RTPieBuilder > var c: Class > â > | b c | > â¦ > -=-=-=-=-=-=-=-=-=-=-=-= > The method exampleLabelledIf defines two temporary variables, b and c. The comment defines the types of these variables > > (B) - I am still unsure which types system to use. Probably I will use the one of Dart for now. It is easy to implement but it is unsound. I think having a Gradual Type checker for Pharo would be fantastic, but this is seriously more complicated to have. > > All in all, there is a fair amount of non-trivial theory behind. Does this make sense to you? > > Cheers, > Alexandre > > > > On Oct 2, 2015, at 3:50 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > What options do we have in terms of type annotations in Pharo? > > > > I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > > > which enabled type annotation for Squeak such as > > ~~~~~~~~~~~~~~~~ > > Fruit>>mixWith: aFruit <:type: Fruit :> > > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > > ~~~~~~~~~~~~~~~~ > > Orange>>color > > ^ (Color orange) <:type: Color :> > > ~~~~~~~~~~~~~~~~ > > (or even blocks) > > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > > ~~~~~~~~~~~~~~~~ > > > > obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) > > > > And my question is... is there a port of this, or something similar? > > > > I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > > Which is a framework for integrated testing that uses pragmas such as > > ~~~~~~~~~~~~~~~~ > > makeBatchWithdrawalOn: aDate note: aString > > <fitTakes: #(#{Date} #{String})> > > <fitReturns: #{Fixture}> > > ^(BatchWithdrawalFixture date: aDate note: aString) > > systemUnderTest: systemUnderTest > > ~~~~~~~~~~~~~~~~ > > > > Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 2, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by Peter UhnÃ¡k

On Fri, Oct 2, 2015 at 9:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Peter! > > I see you are really motivated for having types in Pharo. This is great. > Well my primary motivation is that I need annotated code to be able to do full model reverse-engineering (that of itself is very hard task, however if you work only on constrained models that you've forward-engineered or control, it's significantly simpler). In fact types are not enough because they do not tell things like cardinality and other features of relations between objects, but I will be adding that too, probably in similar fashion to MSE pragmas, since I am already using FAMIX model. (In fact FAMIX already annotates the type of it's own properties with <MSEProperty>.) As for the type of the types... I am not looking for battle-hardened solution, just something good-enough. The benefit of using pragmas over comments is that I don't need to parse them and currently they look better (unlike comment they are nicely colored, instead of a block of text). This would be also fairly easy (it seems) to implement. Now for what you are proposing (A) is basically JavaDoc for Smalltalk; this was already done in other languages such as JavaScript's JSDoc ( https://developers.google.com/closure/compiler/docs/js-for-compiler ) - Google Closure can do static analysis and js transpilation/optimization, php has PHPDoc ( https://en.wikipedia.org/wiki/PHPDoc ) and Ruby also has something similar (RDoc or something). So this is definitely something that is being used at large and is well integrated with today IDEs (so not using it is those languages is actually detrimental). Also this doesn't affect the syntax of the language. (B) I am not familiar with Dart, but it seems similar to what TypeScript does, where I can do either backward compatible with regular javascript ~~~~~~~~~~~~~~~~~~~ setName(name) { this.name = name; } ~~~~~~~~~~~~~~~~~~~ with specification of a type ~~~~~~~~~~~~~~~~~~~ setName(name: string) { this.name = name; } ~~~~~~~~~~~~~~~~~~~ (in fact PHP can do this too for non-primitives and I believe JavaScript/ECMAScript7 was also supposed to support something like that). This however would require change to the syntax, which I'm not very keen on (and I cannot imagine that anyone would welcome syntax change). Now as I mentioned, right now I'm exploring options that are available; my requirements only overlap of what real solution (whether annotations or gradual types) offer. So maybe I will settle on some custom-hacked pragmas until/if a mature solution emerges. (Pragma annotations are also what I would go for if nothing better comes up). Peter The email youâve sent a couple of days ago motivated me for continuing my > effort. > > The two important design points of my implementation are as follow: > (A) - Types are specified in the method comment. Consider the > following two examples: > -=-=-=-=-=-=-=-=-=-=-=-= > RBParser class>>parseMethod: aString > " > :: String -> RBProgramNode > â > ... > -=-=-=-=-=-=-=-=-=-=-=-= > The method parseMethod: accepts a string as argument and return a program > node > > -=-=-=-=-=-=-=-=-=-=-=-= > exampleLabelledIf > " > var b: RTPieBuilder > var c: Class > â > | b c | > â¦ > -=-=-=-=-=-=-=-=-=-=-=-= > The method exampleLabelledIf defines two temporary variables, b and c. The > comment defines the types of these variables > > (B) - I am still unsure which types system to use. Probably I will > use the one of Dart for now. It is easy to implement but it is unsound. I > think having a Gradual Type checker for Pharo would be fantastic, but this > is seriously more complicated to have. > > All in all, there is a fair amount of non-trivial theory behind. Does this > make sense to you? > > Cheers, > Alexandre > > > > On Oct 2, 2015, at 3:50 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > What options do we have in terms of type annotations in Pharo? > > > > I stumbled upon TypePlug this > https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather > this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > > > which enabled type annotation for Squeak such as > > ~~~~~~~~~~~~~~~~ > > Fruit>>mixWith: aFruit <:type: Fruit :> > > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > > ~~~~~~~~~~~~~~~~ > > Orange>>color > > ^ (Color orange) <:type: Color :> > > ~~~~~~~~~~~~~~~~ > > (or even blocks) > > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > > ~~~~~~~~~~~~~~~~ > > > > obviously something like this wouldn't even compile in Pharo (does Sqeak > have different syntax for pragmas, or did the TypePlug change the syntax?) > > > > And my question is... is there a port of this, or something similar? > > > > I've also found this > http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > > Which is a framework for integrated testing that uses pragmas such as > > ~~~~~~~~~~~~~~~~ > > makeBatchWithdrawalOn: aDate note: aString > > <fitTakes: #(#{Date} #{String})> > > <fitReturns: #{Fixture}> > > ^(BatchWithdrawalFixture date: aDate note: aString) > > systemUnderTest: systemUnderTest > > ~~~~~~~~~~~~~~~~ > > > > Right now I am exploring what options we have in Pharo in terms of type > annotations (before writing yet-another-library ;-)). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Oct. 2, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by Alexandre Bergel

Hi Peter! I see you are really motivated for having types in Pharo. This is great. The email youâve sent a couple of days ago motivated me for continuing my effort. The two important design points of my implementation are as follow: (A) - Types are specified in the method comment. Consider the following two examples: -=-=-=-=-=-=-=-=-=-=-=-= RBParser class>>parseMethod: aString " :: String -> RBProgramNode â ... -=-=-=-=-=-=-=-=-=-=-=-= The method parseMethod: accepts a string as argument and return a program node -=-=-=-=-=-=-=-=-=-=-=-= exampleLabelledIf " var b: RTPieBuilder var c: Class â | b c | â¦ -=-=-=-=-=-=-=-=-=-=-=-= The method exampleLabelledIf defines two temporary variables, b and c. The comment defines the types of these variables (B) - I am still unsure which types system to use. Probably I will use the one of Dart for now. It is easy to implement but it is unsound. I think having a Gradual Type checker for Pharo would be fantastic, but this is seriously more complicated to have. All in all, there is a fair amount of non-trivial theory behind. Does this make sense to you? Cheers, Alexandre > On Oct 2, 2015, at 3:50 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > What options do we have in terms of type annotations in Pharo? > > I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > which enabled type annotation for Squeak such as > ~~~~~~~~~~~~~~~~ > Fruit>>mixWith: aFruit <:type: Fruit :> > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > ~~~~~~~~~~~~~~~~ > Orange>>color > ^ (Color orange) <:type: Color :> > ~~~~~~~~~~~~~~~~ > (or even blocks) > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > ~~~~~~~~~~~~~~~~ > > obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) > > And my question is... is there a port of this, or something similar? > > I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > Which is a framework for integrated testing that uses pragmas such as > ~~~~~~~~~~~~~~~~ > makeBatchWithdrawalOn: aDate note: aString > <fitTakes: #(#{Date} #{String})> > <fitReturns: #{Fixture}> > ^(BatchWithdrawalFixture date: aDate note: aString) > systemUnderTest: systemUnderTest > ~~~~~~~~~~~~~~~~ > > Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 2, 2015

IS there TypePlug for Pharo or similar type annotation tool?

by Peter UhnÃ¡k

Hi, What options do we have in terms of type annotations in Pharo? I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) which enabled type annotation for Squeak such as ~~~~~~~~~~~~~~~~ Fruit>>mixWith: aFruit <:type: Fruit :> ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> ~~~~~~~~~~~~~~~~ Orange>>color ^ (Color orange) <:type: Color :> ~~~~~~~~~~~~~~~~ (or even blocks) [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] ~~~~~~~~~~~~~~~~ obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) And my question is... is there a port of this, or something similar? I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ Which is a framework for integrated testing that uses pragmas such as ~~~~~~~~~~~~~~~~ makeBatchWithdrawalOn: aDate note: aString <fitTakes: #(#{Date} #{String})> <fitReturns: #{Fixture}> ^(BatchWithdrawalFixture date: aDate note: aString) systemUnderTest: systemUnderTest ~~~~~~~~~~~~~~~~ Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). Thanks, Peter

Oct. 2, 2015