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

Re: [Pharo-dev] Forgotten halt ?

by Marcus Denker

> On 15 Jun 2015, at 12:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 15 Jun 2015, at 12:36, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >> >>> On 15 Jun 2015, at 11:45, Franck Warlouzet <franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: >>> >>> Hi, >>> >>> I wanted to merge a package filed out, and I got a self halt in FileList>>#readOnlyStream. Is it an expected behavior (like instead of raise an exception, put a self halt, I do not know what) or is it just a forgotten self halt ? >> >> In Pharo 4 or Pharo 5? > > Pharo5, and yes, looks like an oversight when integrating the FileList fixes. > I added an issue: https://pharo.fogbugz.com/f/cases/15775/remove-some-halt-that-where-left-ov…

June 15, 2015

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

by Javier PimÃ¡s

Thanks for the quick answer, it now works as expected. I updated to a clean pharo 4 image and loaded roassal2 again (my previous image was just 2 months old). I had to change the ConfigurationOfGlamourCore to point from version 1.2.14 to version 1.2.10 of rubrick (don't know what rubrick is but changing the version allowed loading everything). Still some things don't work as expected: export to svg and png in inspector. pngs are exported with the wrong viewport, svg are distorted, like with the old version. As for the code, just copy-pasted from the docs in agilevisualization.com or examples in image can't remember exactly though. I took them 2 or 3 months ago, but these same examples seem to be up-to-date now in both places. Cheers On Sun, Jun 14, 2015 at 9:53 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

June 15, 2015

SHRBTextStyler is desynched

by stepharo

Hi SHRBTextStyler is using the wrong class when doing semantics analysis. So this is why the coloring does not work. A clear example is looking and the implementor of setText: and selecting one of the three methods. opening the transcript shows an error message that shows that the class used to analyse the method is not correct. Stef PS: trying to solve the problem right now

June 15, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50114 Home: https://github.com/pharo-project/pharo-core

June 15, 2015

[pharo-project/pharo-core] d4e81a: 50114

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d4e81a2c267b75815db347f8024946c3747dba0f https://github.com/pharo-project/pharo-core/commit/d4e81a2c267b75815db347f8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-15 (Mon, 15 Jun 2015) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st M Collections-Sequenceable.package/OrderedCollection.class/instance/accessing/at_.st M Collections-Sequenceable.package/OrderedCollection.class/instance/accessing/at_put_.st R Polymorph-Widgets.package/ThemeIcons.class/instance/accessing - icons/checkBoxPressedIconContents.st R Polymorph-Widgets.package/ThemeIcons.class/instance/accessing - icons/haloScaleIconContents.st A Polymorph-Widgets.package/ThemeIcons.class/instance/private - contents/checkBoxPressedIconContents.st A Polymorph-Widgets.package/ThemeIcons.class/instance/private - contents/haloScaleIconContents.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50113.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50114.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50113.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50114.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50114 15765 OrderedCollection>>#at: and #at:put is slow https://pharo.fogbugz.com/f/cases/15765 15753 wrong styling for comments https://pharo.fogbugz.com/f/cases/15753 15770 Methods are in wrong protocol on ThemeIcons https://pharo.fogbugz.com/f/cases/15770 15711 The File Browser has a Context Menu "Workspace with Contents". It opens an Edit Window (String Morph), but not a Workspace ... https://pharo.fogbugz.com/f/cases/15711 http://files.pharo.org/image/50/50114.zip

June 15, 2015

Re: [Pharo-dev] Forgotten halt ?

by Franck Warlouzet

Yes sorry I forgot ... Pharo 5 latest image From: marcus.denker(a)inria.fr Date: Mon, 15 Jun 2015 12:39:43 +0200 To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Forgotten halt ? On 15 Jun 2015, at 12:36, Max Leske <maxleske(a)gmail.com> wrote: On 15 Jun 2015, at 11:45, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote:Hi, I wanted to merge a package filed out, and I got a self halt in FileList>>#readOnlyStream. Is it an expected behavior (like instead of raise an exception, put a self halt, I do not know what) or is it just a forgotten self halt ? In Pharo 4 or Pharo 5? Pharo5, and yes, looks like an oversight when integrating the FileList fixes. Marcus

June 15, 2015

Re: [Pharo-dev] Forgotten halt ?

by Marcus Denker

> On 15 Jun 2015, at 12:36, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 15 Jun 2015, at 11:45, Franck Warlouzet <franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: >> >> Hi, >> >> I wanted to merge a package filed out, and I got a self halt in FileList>>#readOnlyStream. Is it an expected behavior (like instead of raise an exception, put a self halt, I do not know what) or is it just a forgotten self halt ? > > In Pharo 4 or Pharo 5? Pharo5, and yes, looks like an oversight when integrating the FileList fixes. Marcus

June 15, 2015

Re: [Pharo-dev] Forgotten halt ?

by Max Leske

> On 15 Jun 2015, at 11:45, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > Hi, > > I wanted to merge a package filed out, and I got a self halt in FileList>>#readOnlyStream. Is it an expected behavior (like instead of raise an exception, put a self halt, I do not know what) or is it just a forgotten self halt ? In Pharo 4 or Pharo 5? > > Cheers, > > Franck

June 15, 2015

Forgotten halt ?

by Franck Warlouzet

Hi, I wanted to merge a package filed out, and I got a self halt in FileList>>#readOnlyStream. Is it an expected behavior (like instead of raise an exception, put a self halt, I do not know what) or is it just a forgotten self halt ? Cheers, Franck

June 15, 2015

Re: [Pharo-dev] Debugging and optimizations

by ClÃ©ment Bera

2015-06-15 10:07 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > 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 > Debugger works fine don't worry. It either ignores the Cvalue block if precompiled or highlights the inner statements of the blocks if not precompiled while debugging the outer context. As my code edits the AST and that the AST is kept in a cache there might be some issues with the tools though, but nothing hard to solve. As Guille said, I think this is interesting experiment, and you can use it and hack it if you want, but I am not sure it should be part of the base image. > > > > > 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