June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Inexact draiwing in roassal?

by Alexandre Bergel

The class has been removed some times agoâ¦ There is not much I can do if people do not updateâ¦. Alexandre > On Jun 14, 2015, at 3:42 PM, stepharo <stepharo(a)free.fr> wrote: > > Alexandre > > why don't you communicate it well in the code. > This is really easy to deprecate the new method, put the class in a different package. > > We will not use Roassal anymore in our open-devs lectures just because we literally burnt a poor > student that was systematically bumping into deprecated code but non explicit. > It gives a really bad impression of Pharo after this kind of experience. > > Stef > > >> >> First of all, RTGrapherBuilder has been obsoleted. Use RTGrapher instead. >> I guess this is a problem with rounding with RTGrapherBuilder. With RTGrapher, I do not see this behavior. >> >> For example: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. >> 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. >> 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. >> 1.0 @ 10.0. 0.0 @ 11.0}. >> >> b := RTGrapher new. >> b extent: 400 @ 200. >> >> ds := RTDataSet new. >> ds dotShape circle color: Color red. >> ds interaction fixedPopupText: [ :e | e printString ]. >> >> ds points: events. >> ds connectColor: Color blue. >> ds x: [ :e | e y ]. >> ds y: [ :e | e x ]. >> b add: ds. >> b axisX noTick; noLabel. >> b axisY noTick; noLabel. >> b build. >> >> b view add: ((RTLine new width: 0.02; color: Color yellow) edgeFrom: b view elements fifth to: b view elements last). >> b view >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> A deep zoom-in shows everything is okay: >> <Mail Attachment.png> >> >> Cheers, >> Alexandre >> >> >>> On Jun 13, 2015, at 8:00 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >>> >>> Hi guys, I'm drawing a chart with roassal2 and just discovered that lines are not being drawn exactly as expected. Maybe this is a known problem? I'm running on a few months old pharo4beta image, in linux. Here I attach a screenshot corresponding to the code below. There are more evident examples but this one is easier to debug as it is a straight line made of many segments (zooming a bit you'll see the thin reference line and notice the blue line "bends"). Thanks for reading! >>> >>> Cheers, >>> Javier >>> >>> test >>> | b ds events | >>> >>> events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. >>> 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. >>> 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. >>> 1.0 @ 10.0. 0.0 @ 11.0}. >>> >>> b := RTGrapherBuilder new. >>> b extent: 400 @ 200. >>> >>> ds := RTDataSet new. >>> ds dotShape circle color: Color red. >>> ds interaction fixedPopupText: [ :e | e printString ]. >>> >>> ds points: events. >>> ds connectColor: Color blue. >>> ds x: [ :e | e y ]. >>> ds y: [ :e | e x ]. >>> b add: ds. >>> b axisXWithNumberOfTicks: events size. >>> ^b build >>> >>> <image.png> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Ben Coman

On Mon, Jun 15, 2015 at 2:34 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 14/06/2015 18:39, Holger Freyther a Ã©crit : >> >> >>> On 13 Jun 2015, at 14:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> Dear Clement, >> >>> This is an interesting problem. There is currently no simple way of >>> executing a message at compile-time instead of at runtime in Pharo, which is >>> useful to have settings but no runtime overhead. >>> >>> I did a simple extension for opal compiler for this purpose, adding the >>> message Cvalue, which is compiled by Opal either to its receiver's block >>> value or the result of its value depending on the result of >>> #allowPrecompilation sent to its class using AST manipulation before the >>> semantic analysis. >> >> >> are you aware of the compile time constants in GNU Smalltalk. The syntax >> that was >> picked is ##(EXPR). E.g. the below is an example for usage in GNU >> Smalltalk. >> >> >> someMethod >> ^##(Character value: 8) >> >> the compiler will create a CompiledMethod that holds a literal ($<8>) and >> will return >> it. In general I find that syntax quite nice. > > > When porting SmaCC from the Dolphin version, I found that optimisation in > many places, as well as methods returning once blocks: > ^ [ Dictionary new add: .... ] once. > > So, I'd say that Cvalue is the same as once :) > Does #once evaluate at compile time? Or the first pass at run-time? The latter would have a different runtime overhead to CValue. There are probably valid arguments for not introducing new syntax (including cross-dialect compatibility), but for something that occurs at compile-time rather than run-time, I think I'd prefer syntax to a keyword. To reuse existing elements that are not compiled, that is either comment quotes or pragma angle brackets. Maybe combine pragma with an executable block... <[ doThis at compileTime ]> Marcus said: > I am a bit sceptical to have meta links show up as syntaxâ¦ > I see two possibilities one could experiment with: btw, Are meta links planned to show up as highlighting in code views? btw2, I guess if debugging code is a meta link, it won't get filed out or saved by Monticello. This would have a benefit to minimise adhoc logging accidentally ending up in packages, but wouldn't suit a case where the logging is meant to permanently remain spread throughout the code ready for all to be enabled when needed. Otherwise you'd need code in a separate location that installs the debugging metalinks, which may be susceptible to getting out sync with the main code it references. cheers -ben

June 14, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by Peter UhnÃ¡k

Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine ( https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). So, maybe this could be also addressed at the camp if there will be time? Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. Peter On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 08 Jun 2015, at 18:22, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > >> Well at least for me it is certainly not clear what release policy is > Roassal following; i.e. if I see a minor version change what to expect, if > any BC breaks were introduced, etc. Of course this is extra effort for the > person doing it, so it should be taken with care. But there are certainly > things to be discussed about this. > > > > Hi Peter, > > > > Indeed, we have not been good at producing a descent version numbering > schema. > > My position was always this one: the last version should always fit your > need. However, some product favored stability when Roassal is used in a > commercial setting. > > We will be more careful when updating the configuration with a proper > version number. > > Versioning is in fact a complex thing. Thatâs why I suggest to have a > brainstorming session during the camp. > > Uko > > > > > Cheers, > > Alexandre > > > > > >> > >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât > updated for a long time. Maybe I was wrong. > >> > >> Uko > >> > >> > >> > >>> On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>> > >>> There sure are, look at ConfigurationOfRoassal2>>version*: > >>> > >>> and in my baseline I have something like > >>> > >>> ~~~~~~~~~~~ > >>> spec > >>> project: 'Roassal2' with: [ > >>> spec > >>> className: > #ConfigurationOfRoassal2; > >>> versionString: '1.52'; > >>> repository: ' > http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; > >>> ~~~~~~~~~~~ > >>> > >>> Peter > >>> > >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >>> But are there numbered version to refer to? > >>> > >>> Uko > >>> > >>>> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >>>> Iâm interested in participating. Personally Iâd like to talk more > about design decisions behind roassal ecosystem, release strategy and so > on. Usually when I work with Roassal I have this issue that things are > breaking because of rapid changes, or because of the differences between > different parts of roassal. Maybe someone is also concerned about this, so > we can discuss and maybe improve somethingâ¦ > >>>> > >>>> Yes I am also interested in this, right now I am actually using quite > old version (month+) because I didn't have time to keep up. :) (Arguably > 90% of my problems were from infamous composite shapes. :)) > >>>> > >>>> Peter > >>>> > >>>> Uko > >>>> > >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>>>> > >>>>> Dear Colleagues and Friends, > >>>>> > >>>>> We are happy to announce we will organize a CampSmalltalk about the > Roassal visualization engine, on _Sunday 12 July_. > >>>>> > >>>>> As far as we have seen, the interests are multiple. Here is a list > of topics we will happy to work on: > >>>>> - Port of Roassal on VisualWorks > >>>>> - Using Roassal on Gemstone > >>>>> - HTML/JavaScript export > >>>>> - Improving Grapher, our charting library > >>>>> > >>>>> If you wish to participate, get in touch with us. Since we will > probably have a sponsoring of the event, it would be nice to know how many > will attend to ease the logistic and the pizza ordering :-) > >>>>> > >>>>> Cheers, > >>>>> Alexandre > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

June 14, 2015

Re: [Pharo-dev] Inexact draiwing in roassal?

by stepharo

Alexandre why don't you communicate it well in the code. This is really easy to deprecate the new method, put the class in a different package. We will not use Roassal anymore in our open-devs lectures just because we literally burnt a poor student that was systematically bumping into deprecated code but non explicit. It gives a really bad impression of Pharo after this kind of experience. Stef > > First of all, RTGrapherBuilder has been obsoleted. Use RTGrapher instead. > I guess this is a problem with rounding with RTGrapherBuilder. With > RTGrapher, I do not see this behavior. > > For example: > > -=-=-=-=-=-=-=-=-=-=-=-= > events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. > 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. > 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. > 1.0 @ 10.0. 0.0 @ 11.0}. > > b := RTGrapher new. > b extent: 400 @ 200. > > ds := RTDataSet new. > ds dotShape circle color: Color red. > ds interaction fixedPopupText: [ :e | e printString ]. > > ds points: events. > ds connectColor: Color blue. > ds x: [ :e | e y ]. > ds y: [ :e | e x ]. > b add: ds. > b axisX noTick; noLabel. > b axisY noTick; noLabel. > b build. > > b view add: ((RTLine new width: 0.02; color: Color yellow) edgeFrom: b > view elements fifth to: b view elements last). > b view > -=-=-=-=-=-=-=-=-=-=-=-= > > A deep zoom-in shows everything is okay: > > Cheers, > Alexandre > > >> On Jun 13, 2015, at 8:00 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com >> <mailto:elpochodelagente@gmail.com>> wrote: >> >> Hi guys, I'm drawing a chart with roassal2 and just discovered that >> lines are not being drawn exactly as expected. Maybe this is a known >> problem? I'm running on a few months old pharo4beta image, in linux. >> Here I attach a screenshot corresponding to the code below. There are >> more evident examples but this one is easier to debug as it is a >> straight line made of many segments (zooming a bit you'll see the >> thin reference line and notice the blue line "bends"). Thanks for >> reading! >> >> Cheers, >> Javier >> >> test >> | b ds events | >> >> events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. >> 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. >> 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. >> 1.0 @ 10.0. 0.0 @ 11.0}. >> >> b := RTGrapherBuilder new. >> b extent: 400 @ 200. >> >> ds := RTDataSet new. >> ds dotShape circle color: Color red. >> ds interaction fixedPopupText: [ :e | e printString ]. >> >> ds points: events. >> ds connectColor: Color blue. >> ds x: [ :e | e y ]. >> ds y: [ :e | e x ]. >> b add: ds. >> b axisXWithNumberOfTicks: events size. >> ^b build >> >> <image.png> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

June 14, 2015

Re: [Pharo-dev] Debugging and optimizations

by Thierry Goubier

Le 14/06/2015 18:39, Holger Freyther a Ã©crit : > >> On 13 Jun 2015, at 14:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Dear Clement, > >> This is an interesting problem. There is currently no simple way of executing a message at compile-time instead of at runtime in Pharo, which is useful to have settings but no runtime overhead. >> >> I did a simple extension for opal compiler for this purpose, adding the message Cvalue, which is compiled by Opal either to its receiver's block value or the result of its value depending on the result of #allowPrecompilation sent to its class using AST manipulation before the semantic analysis. > > are you aware of the compile time constants in GNU Smalltalk. The syntax that was > picked is ##(EXPR). E.g. the below is an example for usage in GNU Smalltalk. > > > someMethod > ^##(Character value: 8) > > the compiler will create a CompiledMethod that holds a literal ($<8>) and will return > it. In general I find that syntax quite nice. When porting SmaCC from the Dolphin version, I found that optimisation in many places, as well as methods returning once blocks: ^ [ Dictionary new add: .... ] once. So, I'd say that Cvalue is the same as once :) Regards, Thierry

June 14, 2015

Re: [Pharo-dev] Debugging and optimizations

by Holger Freyther

> On 13 Jun 2015, at 14:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: Dear Clement, > This is an interesting problem. There is currently no simple way of executing a message at compile-time instead of at runtime in Pharo, which is useful to have settings but no runtime overhead. > > I did a simple extension for opal compiler for this purpose, adding the message Cvalue, which is compiled by Opal either to its receiver's block value or the result of its value depending on the result of #allowPrecompilation sent to its class using AST manipulation before the semantic analysis. are you aware of the compile time constants in GNU Smalltalk. The syntax that was picked is ##(EXPR). E.g. the below is an example for usage in GNU Smalltalk. someMethod ^##(Character value: 8) the compiler will create a CompiledMethod that holds a literal ($<8>) and will return it. In general I find that syntax quite nice. cheers holger

June 14, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Alexandre Bergel

+1 > On Jun 12, 2015, at 9:36 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > As a sidenote (and since Yuriy mentioned Roassal), we would like to address the versioning (and release management) of roassal at ESUG (Camp Roassal) since Roassal was being developed really fast and it was hard to keep up. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 14, 2015

Re: [Pharo-dev] Inexact draiwing in roassal?

by Alexandre Bergel

Hi Javier, First of all, RTGrapherBuilder has been obsoleted. Use RTGrapher instead. I guess this is a problem with rounding with RTGrapherBuilder. With RTGrapher, I do not see this behavior. For example: -=-=-=-=-=-=-=-=-=-=-=-= events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. 1.0 @ 10.0. 0.0 @ 11.0}. b := RTGrapher new. b extent: 400 @ 200. ds := RTDataSet new. ds dotShape circle color: Color red. ds interaction fixedPopupText: [ :e | e printString ]. ds points: events. ds connectColor: Color blue. ds x: [ :e | e y ]. ds y: [ :e | e x ]. b add: ds. b axisX noTick; noLabel. b axisY noTick; noLabel. b build. b view add: ((RTLine new width: 0.02; color: Color yellow) edgeFrom: b view elements fifth to: b view elements last). b view -=-=-=-=-=-=-=-=-=-=-=-= A deep zoom-in shows everything is okay: Cheers, Alexandre > On Jun 13, 2015, at 8:00 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > Hi guys, I'm drawing a chart with roassal2 and just discovered that lines are not being drawn exactly as expected. Maybe this is a known problem? I'm running on a few months old pharo4beta image, in linux. Here I attach a screenshot corresponding to the code below. There are more evident examples but this one is easier to debug as it is a straight line made of many segments (zooming a bit you'll see the thin reference line and notice the blue line "bends"). Thanks for reading! > > Cheers, > Javier > > test > | b ds events | > > events := { 10.0 @ 1.0. 9.0 @ 2.0. 8.0 @ 3.0. > 7.0 @ 4.0. 6.0 @ 5.0. 5.0 @ 6.0. > 4.0 @ 7.0. 3.0 @ 8.0. 2.0 @ 9.0. > 1.0 @ 10.0. 0.0 @ 11.0}. > > b := RTGrapherBuilder new. > b extent: 400 @ 200. > > ds := RTDataSet new. > ds dotShape circle color: Color red. > ds interaction fixedPopupText: [ :e | e printString ]. > > ds points: events. > ds connectColor: Color blue. > ds x: [ :e | e y ]. > ds y: [ :e | e x ]. > b add: ds. > b axisXWithNumberOfTicks: events size. > ^b build > > <image.png> > -- > Javier PimÃ¡s > Ciudad de Buenos Aires -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 14, 2015

Re: [Pharo-dev] what is the simple way to get an input?

by stepharo

Thanks mathieu. I do not know. May be the repl that guillermo is building is the solution. Stef Le 13/6/15 19:29, Matthieu Lacaton a Ã©crit : > Isn't it*userInput := UIManager default request: 'Enter whatever you > want'* ? > > 2015-06-13 19:00 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi > > I was reading a book that teaches programming in python and they > have input(x) that > requests inputs and stores it? > > What is our equivalent? > > Stef > >

June 14, 2015

Re: [Pharo-dev] Pharo on bitnami

by stepharo

Ok how do we proceed? The first one is a product disguised as an open-source software (yeh it is open-source like C# I guess). Do we want to spend energy to advertise bitnami? We could try just to see how many voters we could get? Stef Le 7/6/15 13:08, stepharo a Ã©crit : > Hi pharoers > > we got in contact with bitnami and I would love to see two bitnami > apps around Pharo: > - basic pharo > - pharo + seaside + magritte + voyage (mongo pharo layer) + > mongodb > > So who would like to help pushing this effort? > > Stef > > Begin forwarded message: > > From: Kevin Franklin <kevin(a)bitnami.com> > Subject: Introducing Bitnami... > Date: 5 Jun 2015 10:57:36 GMT+2 > To: <board(a)pharo.org> > > Hello Pharo Association > > I wondered if you knew about Bitnami. Please check us out at > www.bitnami.com. We provide over 120 apps and development stacks â > many of them open-source. > If you would like Pharo to be included in our marketplace, we have a > contest https://bitnami.com/contest were you can nominate it, and > encourage your community to vote for its inclusion. > > Also, I wondered if you could put me in touch with any commercial > companies within and around the Pharo ecosystem that might like to > work with us as a software partner https://bitnami.com/partners/software > > Kind regards > Kevin >

June 14, 2015