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

Re: [Pharo-dev] About TextStyle and StrikeFonts

by Nicolai Hess

2015-05-17 19:01 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > I am about to fix some issues related to TextMorphs and fonts: > > 15402 <https://pharo.fogbugz.com/default.asp?15402> > wrong choose list from TextMorph editor halo > > 15552 <https://pharo.fogbugz.com/default.asp?15552> > chooseStyle halo from TextMorph lists only one StrikeFont > 15553 <https://pharo.fogbugz.com/default.asp?15553> > choose Font halo from TextMorph lists only one StrikeFont > > But I have some questions: > > TextStyle and fonts, this is bound to StrikeFonts for now, because only > StrikeFonts > register themself at "TextSharedInformation" and therefore: > > TextStyle actualTextStyles -> only lists the one Font "Bitmap DejaVu > Sans". > > There are other places that work with TextStyle default / TextStyle .... > > Should I add the FreeType fonts to TextStyles TextSharedInformation > or > should I use "LogicalFontManager allFamilies" instead of "TextStyle > actualTextStyles"`? > > I would like to remove/cleanup all places where we use some TextStyle > methods > that only work for StrikeFonts, but I don't know what was the idea behind > this > current state, that only works partly. Remove and Replace TextStyle with > LogicalFontManager > or use TextStyle for Strike and FreeType fonts? > Anyone? > > thanks in advance > > nicolai > > > > >

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Guillermo Polito

Well, we already have in-image a #once like solution based on memoization. block := [ :key | key factorial ] memoized. "first time" [1000 to: 1500 do: [:index |block value: index]] timeToRun. "0:00:00:01.598" "second time, cached" [1000 to: 1500 do: [:index |block value: index]] timeToRun. "0:00:00:00" And it requires no compiler nor syntax changes. In any case, changing the compiler would be good as: - an example of how to write opal extensions - an additional package for those who would like to play and do hacky stuff (why not huh?) So I would not discourage it (but it would be good to have it as an extra loadable package instead of an in-image one). Guille El lun., 15 de jun. de 2015 a la(s) 10:08 a. m., Ben Coman < btc(a)openinworld.com> escribiÃ³: > whoops. please excuse my previous clicktoofast. > > On Mon, Jun 15, 2015 at 3:51 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hey all, > > > > Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but > > that was definitely what I was trying to experiment with. > > > > As Thierry mentioned, these elements come from C/C++ where you have > macros > > that are very useful when writing high performance code so your code can > be > > both flexible and very efficient. > > > > Ben you're right, normal users should not be confused by those features > or > > new syntax elements. For CValue, I added class-side of the classes using > it: > > > > MyClass>>#compiler > > | comp | > > comp := super compiler. > > comp compilationContext semanticAnalyzerClass: NeoCompiler. > > ^ comp > > > > I think the solution for this problem is to do another Opal compilation > > options for precompilation. This way, if you want to use your compiler > > extension, you have either to: > > - override #compiler class side for a hierachy of classes granularity > > - add a pragma such as <compilationOptions: + optionPrecompilation> for a > > per method granularity > > To make it more explicit, possibly consider requiring the special > selector to be mentioned in the pragma. > <precompile: #once> or <precompile: #Cvalue> > > Now I wonder how this precompiled code might look or operate within a > debugger? > cheers -ben > > > > > > then in the methods affected by the compiler extension, you can either > use a > > different parser with new syntax elements such as ##() or use new special > > selectors such as #once or #Cvalue. > > > > > > 2015-06-15 7:13 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> > >> Hi Ben, > >> > >> > >> Le 15/06/2015 01:09, Ben Coman a Ã©crit : > >>> > >>> 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. > >> > >> > >> I don't know. It could even be at first run with a recompilation of the > >> method, to add another solution to the mix :) > >> > >>> 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 ]> > >> > >> > >> #define and friends it is :) In short, a dedicated syntax for compile > >> time... aka macros. > >> > >> Thierry > >> > >> > > > >

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Ben Coman

whoops. please excuse my previous clicktoofast. On Mon, Jun 15, 2015 at 3:51 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hey all, > > Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but > that was definitely what I was trying to experiment with. > > As Thierry mentioned, these elements come from C/C++ where you have macros > that are very useful when writing high performance code so your code can be > both flexible and very efficient. > > Ben you're right, normal users should not be confused by those features or > new syntax elements. For CValue, I added class-side of the classes using it: > > MyClass>>#compiler > | comp | > comp := super compiler. > comp compilationContext semanticAnalyzerClass: NeoCompiler. > ^ comp > > I think the solution for this problem is to do another Opal compilation > options for precompilation. This way, if you want to use your compiler > extension, you have either to: > - override #compiler class side for a hierachy of classes granularity > - add a pragma such as <compilationOptions: + optionPrecompilation> for a > per method granularity To make it more explicit, possibly consider requiring the special selector to be mentioned in the pragma. <precompile: #once> or <precompile: #Cvalue> Now I wonder how this precompiled code might look or operate within a debugger? cheers -ben > > then in the methods affected by the compiler extension, you can either use a > different parser with new syntax elements such as ##() or use new special > selectors such as #once or #Cvalue. > > > 2015-06-15 7:13 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> Hi Ben, >> >> >> Le 15/06/2015 01:09, Ben Coman a Ã©crit : >>> >>> 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. >> >> >> I don't know. It could even be at first run with a recompilation of the >> method, to add another solution to the mix :) >> >>> 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 ]> >> >> >> #define and friends it is :) In short, a dedicated syntax for compile >> time... aka macros. >> >> Thierry >> >> >

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Ben Coman

On Mon, Jun 15, 2015 at 3:51 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hey all, > > Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but > that was definitely what I was trying to experiment with. > > As Thierry mentioned, these elements come from C/C++ where you have macros > that are very useful when writing high performance code so your code can be > both flexible and very efficient. > > Ben you're right, normal users should not be confused by those features or > new syntax elements. For CValue, I added class-side of the classes using it: > > MyClass>>#compiler > | comp | > comp := super compiler. > comp compilationContext semanticAnalyzerClass: NeoCompiler. > ^ comp > > I think the solution for this problem is to do another Opal compilation > options for precompilation. This way, if you want to use your compiler > extension, you have either to: > - override #compiler class side for a hierachy of classes granularity > - add a pragma such as <compilationOptions: + optionPrecompilation> for a > per method granularity > > then in the methods affected by the compiler extension, you can either use a > different parser with new syntax elements such as ##() or use new special > selectors such as #once or #Cvalue. > > > 2015-06-15 7:13 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> Hi Ben, >> >> >> Le 15/06/2015 01:09, Ben Coman a Ã©crit : >>> >>> 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. >> >> >> I don't know. It could even be at first run with a recompilation of the >> method, to add another solution to the mix :) >> >>> 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 ]> >> >> >> #define and friends it is :) In short, a dedicated syntax for compile >> time... aka macros. >> >> Thierry >> >> >

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by ClÃ©ment Bera

Hey all, Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but that was definitely what I was trying to experiment with. As Thierry mentioned, these elements come from C/C++ where you have macros that are very useful when writing high performance code so your code can be both flexible and very efficient. Ben you're right, normal users should not be confused by those features or new syntax elements. For CValue, I added class-side of the classes using it: MyClass>>#compiler | comp | comp := super compiler. comp compilationContext semanticAnalyzerClass: NeoCompiler. ^ comp I think the solution for this problem is to do another Opal compilation options for precompilation. This way, if you want to use your compiler extension, you have either to: - override #compiler class side for a hierachy of classes granularity - add a pragma such as <compilationOptions: + optionPrecompilation> for a per method granularity then in the methods affected by the compiler extension, you can either use a different parser with new syntax elements such as ##() or use new special selectors such as #once or #Cvalue. 2015-06-15 7:13 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Ben, > > > Le 15/06/2015 01:09, Ben Coman a Ã©crit : > >> 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. >> > > I don't know. It could even be at first run with a recompilation of the > method, to add another solution to the mix :) > > 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 ]> >> > > #define and friends it is :) In short, a dedicated syntax for compile > time... aka macros. > > Thierry > > >

June 15, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by stepharo

Hi Peter Definitively. Having stable API is key for us and for everybody. For us (synectique), we stop to change versions around 6 months ago. This is sad that we have to shield us from Roassal but this is what we are doing. We cannot fight to get clients and change all the time our code. As you see, I'm the only one to say it because usman already reported this problem one year ago and we discussed with alex but we faced the same problem and now he stopped even to report problems. So we will rediscuss in july when alex is visiting us and else we will stay with an old version. The problem is that the community around roassal will not benefit from this but we cannot do much. Stef > 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 > <mailto:yuriy.tymchuk@me.com>> wrote: > > > > On 08 Jun 2015, at 18:22, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@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 <mailto:yuriy.tymchuk@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 > <mailto:i.uhnak@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 <mailto:yuriy.tymchuk@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 > <mailto:i.uhnak@gmail.com>> wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk > <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@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 <mailto:alexandre.bergel@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 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Marcus Denker

> > btw, Are meta links planned to show up as highlighting in code views? > Yes, we will soon have the new editor everywhere which allows to do this. The most important is to visualize breakpoints. I want to have dedicated visuals for that. Then, later, I want to show meta links in general, but with a non-intrusive way. (maybe optional?). There should be a âmeta link editorâ, too. But all that needs experiments... > 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. > Yes, meta links and breakpoints are never saved with the code. Marcus

June 15, 2015

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

by stepharo

Le 15/6/15 02:30, Alexandre Bergel a Ã©crit : > The class has been removed some times agoâ¦ There is not much I can do if people do not updateâ¦. Indeed. In my case we used the latest version. > > 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 >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>>

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by Thierry Goubier

Hi Ben, Le 15/06/2015 01:09, Ben Coman a Ã©crit : > 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. I don't know. It could even be at first run with a recompilation of the method, to add another solution to the mix :) > 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 ]> #define and friends it is :) In short, a dedicated syntax for compile time... aka macros. Thierry

June 15, 2015

WhatsUp from: 2015-06-15 until: 2015-06-30

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-06-30 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

June 15, 2015