- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 10 Oct 2014, at 10:57, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > Hi All, > > Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? > I will try to fix it next week... > Or can you suggest me some other way/workaround, how to get/generate the source code of a block? > The old compiler used a hack to decompile blocks for getting a textual representationâ¦ one could port the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of using the byte code-offset-to-AST mapping more). Marcus > Thank you very much! > Cheers, > Jan > > BTW, the tests to execute: > self assert: [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] asString = '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' > self assert: [ :ctx | [ ctx atEnd ] whileTrue: [ ] ] asString = '[ :ctx | [ ctx atEnd ] whileTrue: [ ] ]' > > > > On 8 October 2014 18:43, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> On 08 Oct 2014, at 18:28, Camille Teruel <camille.teruel(a)gmail.com <mailto:camille.teruel@gmail.com>> wrote: >> >> >> On 8 oct. 2014, at 17:49, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >>>> >>>> On 08 Oct 2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch>> wrote: >>>> >>>> Hi, >>>> >>>> I need to extract a source code from a block closure and I found something strange: >>>> >>>> [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . >>>> [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. >>>> >>>> Print of the first line returns: >>>> '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' >>>> >>>> Print of the second line returns: >>>> '[ ctx atEnd ]' >>>> >>>> And honestly, I have no idea why. This behaviour was observed in Pharo3 and Pharo4. >>>> >>>> Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd ] whileTrue:[ ] ]' for a second line? >>> >>> >>> I think this is an example that exposes a bug that we still have in the source mappingâ¦ on Context, see >>> >>> sourceNode >>> "Return the source node of the method or the block corresponding to the receiver" >>> ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping) enclosingMethodOrBlockNode >>> "Uncomment the following once the pc->AST mapping is fixed" >>> "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ])) enclosingMethodOrBlockNode" >>> >>> #neighborPCWithCorrectMapping returns the inner send, which is wrongâ¦ this method needs to be rethought. >> >> Yes it should. But that's not easy with optimized loop messages like whileTrue: & co. >> Ideally, the source mapping needs to be fixed because that's the reason this method exists in the first place. > > The first step is to record a range for the byte code that an IRNode createsâ¦ > >> Or else we accepts that "1 to: 1 do: [ :i | ^ thisContext sourceNode ]" returns a method node instead of a block node and use a different implementation. >> >>> >>> Marcus > >

Oct. 10, 2014

Re: [Pharo-dev] Building diffs

by Marcus Denker

> On 10 Oct 2014, at 10:26, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > But also something is building this thing: > <5437978fac2a4954c1354f1f-5437978fac2a4954c1354f20.png> > > I need to figure that out. This is all in Polymorph-Tools-Diff It would be nice to merge the two diff packages... > Uko > > >> On 09 Oct 2014, at 19:24, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Yuriy, >> >> In that case, I'd be inclined to strip the leading whitespace off of the lines and do the diff ... TextDiffBuilder could probably be subclassed/extended to remove leading whitespace for diff and then restore the whitespace for diff ... >> >> Dale >> >> On Thu, Oct 9, 2014 at 10:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> Yes, Iâve tried to use pretty printed version, the problem is that if you wrap something in a block, then itâs indented anyway, and so it looks like youâve replaced a lot. >> >> Uko >> >>> On 09 Oct 2014, at 18:39, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >>> >>> Yuriy, >>> >>> For tODE is use TextDiffBuilder, but I format the source before doing the diff ... it's still line by line, but formatting differences are eliminated ... >>> >>> Dale >>> >>> On Thu, Oct 9, 2014 at 2:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> Hi, >>> >>> What is the best way to find a difference between methods? Iâve tried to use TextDiffBuilder, but itâs very inaccurate, as it reports dive by line, and then even indentation is rated as change of whole line. Is there anything better? >>> >>> Cheers! >>> Uko >>> >> >> >

Oct. 10, 2014

Re: [Pharo-dev] BlockClosure source code

by Jan KurÅ¡

Hi All, Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? Or can you suggest me some other way/workaround, how to get/generate the source code of a block? Thank you very much! Cheers, Jan BTW, the tests to execute: self assert: [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] asString = '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' self assert: [ :ctx | [ ctx atEnd ] whileTrue: [ ] ] asString = '[ :ctx | [ ctx atEnd ] whileTrue: [ ] ]' On 8 October 2014 18:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 08 Oct 2014, at 18:28, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 8 oct. 2014, at 17:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 08 Oct 2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > Hi, > > I need to extract a source code from a block closure and I found something > strange: > > [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . > [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. > > Print of the first line returns: > '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' > > Print of the second line returns: > '[ ctx atEnd ]' > > And honestly, I have no idea why. This behaviour was observed in Pharo3 > and Pharo4. > > Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd > ] whileTrue:[ ] ]' for a second line? > > > > I think this is an example that exposes a bug that we still have in the > source mappingâ¦ on Context, see > > sourceNode > "Return the source node of the method or the block corresponding to the > receiver" > ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping) > enclosingMethodOrBlockNode > "Uncomment the following once the pc->AST mapping is fixed" > "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ])) > enclosingMethodOrBlockNode" > > #neighborPCWithCorrectMapping returns the inner send, which is wrongâ¦ this > method needs to be rethought. > > > Yes it should. But that's not easy with optimized loop messages like > whileTrue: & co. > Ideally, the source mapping needs to be fixed because that's the reason > this method exists in the first place. > > > The first step is to record a range for the byte code that an IRNode > createsâ¦ > > Or else we accepts that "1 to: 1 do: [ :i | ^ thisContext sourceNode ]" > returns a method node instead of a block node and use a different > implementation. > > > Marcus > > >

Oct. 10, 2014

Re: [Pharo-dev] Building diffs

by Yuriy Tymchuk

But also something is building this thing: I need to figure that out. Uko > On 09 Oct 2014, at 19:24, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Yuriy, > > In that case, I'd be inclined to strip the leading whitespace off of the lines and do the diff ... TextDiffBuilder could probably be subclassed/extended to remove leading whitespace for diff and then restore the whitespace for diff ... > > Dale > > On Thu, Oct 9, 2014 at 10:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Yes, Iâve tried to use pretty printed version, the problem is that if you wrap something in a block, then itâs indented anyway, and so it looks like youâve replaced a lot. > > Uko > >> On 09 Oct 2014, at 18:39, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Yuriy, >> >> For tODE is use TextDiffBuilder, but I format the source before doing the diff ... it's still line by line, but formatting differences are eliminated ... >> >> Dale >> >> On Thu, Oct 9, 2014 at 2:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> Hi, >> >> What is the best way to find a difference between methods? Iâve tried to use TextDiffBuilder, but itâs very inaccurate, as it reports dive by line, and then even indentation is rated as change of whole line. Is there anything better? >> >> Cheers! >> Uko >> > >

Oct. 10, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 10, 2014

[pharo-project/pharo-core] 51a875: 40295

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 51a875010b99e15c6711c391bdd973ac637edcd1 https://github.com/pharo-project/pharo-core/commit/51a875010b99e15c6711c391… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-10 (Fri, 10 Oct 2014) Changed paths: A AST-Core.package/RBFindBlockArgumentAssignment.class/instance/private/is_inScopeOf_.st M AST-Core.package/RBFindBlockArgumentAssignment.class/instance/visiting/visitAssignmentNode_.st M KernelTests.package/BehaviorTest.class/instance/tests/testBehaviorRespectsPolymorphismWithTraitBehavior.st R Refactoring-Core.package/RBRenameInstanceVariableRefactoringTest.class/README.md R Refactoring-Core.package/RBRenameInstanceVariableRefactoringTest.class/definition.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script295.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40295.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InvalidPackageName.class/README.md A Slot.package/InvalidPackageName.class/definition.st M Slot.package/SlotClassBuilder.class/instance/accessing/category_.st M Slot.package/SlotClassBuilder.class/instance/private validating/validateClassName.st A System-Support.package/SystemNavigation.class/instance/query/allImplementedMessages.st A System-Support.package/SystemNavigation.class/instance/query/allUnimplementedCalls.st Log Message: ----------- 40295 14201 RBAssignmentOnBlockArgumentRule does not catch all assignments to block args https://pharo.fogbugz.com/f/cases/14201 13174 Should warn against creating class #NameOfSubclass https://pharo.fogbugz.com/f/cases/13174 14207 failing test testBehaviorRespectsPolymorphismWithTraitBehavior https://pharo.fogbugz.com/f/cases/14207 14209 add back #allUnimplementedCalls https://pharo.fogbugz.com/f/cases/14209 14206 remove empty RBRenameInstanceVariableRefactoringTest https://pharo.fogbugz.com/f/cases/14206 7291 Creating a class with empty category should be an error https://pharo.fogbugz.com/f/cases/7291 http://files.pharo.org/image/40/40295.zip

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by phil＠highoctane.be

Le 9 oct. 2014 23:15, "David T. Lewis" <lewis(a)mail.msen.com> a Ã©crit : > > Darn, I think we must have both done our updates on the same day. The last > update I did was this (time stamp is GMT -4 hours) : > > CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm > CommandShell 4.6.9 > > Improve pipe closing for PipeableOSProcess class>>command: and related > methods to support use as stand alone command processor. An expression > such as the following will now close all open handles when command > processing is complete: > > "(PipeableOSProcess command: '/bin/echo this is a test') output" > No more need for the closePipes thing then? Also, I see that there is apparently no AioPlugin support in Pharo 3.0. Or so say the tests of OSProcess. What is the state of affairs there? Phil > If you could update the configuration to pick this up, that would be > great. I think it will be helpful for people who want to easily execute > commands directly from the image. > > I think the two sub-packages that you would update are > CommandShell-Base-dtl.38 and CommandShell-Piping-dtl.16 > > Thanks, > Dave > > > Hi Dave, > > > > thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; > > are those the latest? I did it last Sunday. > > > > Thierry > > > > Le 09/10/2014 22:42, David T. Lewis a Ã©crit : > >> Thierry, > >> > >> Thanks for doing those configuration updates, I hit "send" before I saw > >> your reply. > >> > >> Dave > >> > >>> Hi Noury, > >>> > >>> no, OSProcess on Squeaksource is not dead and is integrating all the > >>> changes needed for all the platforms it is running on. > >>> > >>> And as you can see, I very recently updated the configuration to make > >>> sure it was pointing to the very latest version. > >>> > >>> Regards, > >>> > >>> Thierry > >>> > >>> Le 09/10/2014 22:30, Noury Bouraqadi a Ã©crit : > >>>> Hi, > >>>> > >>>> Just tried to install the stable version of OSProcess using the > >>>> configuration browser on a 3.0. > >>>> I noticed it is still on http://www.squeaksource.com/OSProcess. > >>>> Does it mean it is dead? if yes, what is the alternative? > >>> > >>> > >>>> Thanx > >>>> Noury > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> > >> > > > > > > >

Oct. 10, 2014

Re: [Pharo-dev] Program visualisation

by Florin Mateoc

Hi Thierry, On 10/9/2014 4:52 PM, Thierry Goubier wrote: > > I'm currently on a medium to long term quest to learn in depth / maybe improve the AST automatic generation in SmaCC; > it should give me a core foundation (a common API for the ASTs for all langages that SmaCC can parse) to build upon > interactive visualisations IDEs for the programming languages I'm getting involved in: yesterday C, now R, tomorrow (I > hope) Fortran and Python. But this is more about static analysis than runtime behavior analysis, unless I turn to > VectorFabrics underlying tech... Hum, this one is ... interesting. It opens new ideas. Thanks a lot, this is really > great! > > Thierry By coincidence (or maybe not :) ), I have also fiddled with SmaCC (and, funny thing, I am also interested in static analysis :) ). I ported it to VisualAge, maybe we should exchange notes. I am still not happy with the result, for the previous version I had optimized it to use a VA-specific primitive (Character>>testBit: - very useful little primitive, the VA scanner also uses it (I suspect they implemented it specifically for that)) instead of is... methods, and I did not get to do it yet for the current version. This is actually not just an optimization, I consider it a bug-fix as well - one cannot rely on every method in Character that happens to start with "is" to be fast. Plus you don't know in which environment you are using SmaCC and what kind of extensions people have implemented there. I know that I hit some really bad such methods (now I don't remember if it was ours or some third-party extension). Plus, you are generating a parser that relies on methods that may not be there at runtime. Anyway, I also have some ideas for what I think would be some improvements for SmaCC. Too many ideas, too little time (: Florin

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

Darn, I think we must have both done our updates on the same day. The last update I did was this (time stamp is GMT -4 hours) : CommandShell-dtl.76 Dave Lewis, 5 October 2014 5:29:32 pm CommandShell 4.6.9 Improve pipe closing for PipeableOSProcess class>>command: and related methods to support use as stand alone command processor. An expression such as the following will now close all open handles when command processing is complete: "(PipeableOSProcess command: '/bin/echo this is a test') output" If you could update the configuration to pick this up, that would be great. I think it will be helpful for people who want to easily execute commands directly from the image. I think the two sub-packages that you would update are CommandShell-Base-dtl.38 and CommandShell-Piping-dtl.16 Thanks, Dave > Hi Dave, > > thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; > are those the latest? I did it last Sunday. > > Thierry > > Le 09/10/2014 22:42, David T. Lewis a Ã©crit : >> Thierry, >> >> Thanks for doing those configuration updates, I hit "send" before I saw >> your reply. >> >> Dave >> >>> Hi Noury, >>> >>> no, OSProcess on Squeaksource is not dead and is integrating all the >>> changes needed for all the platforms it is running on. >>> >>> And as you can see, I very recently updated the configuration to make >>> sure it was pointing to the very latest version. >>> >>> Regards, >>> >>> Thierry >>> >>> Le 09/10/2014 22:30, Noury Bouraqadi a Ã©crit : >>>> Hi, >>>> >>>> Just tried to install the stable version of OSProcess using the >>>> configuration browser on a 3.0. >>>> I noticed it is still on http://www.squeaksource.com/OSProcess. >>>> Does it mean it is dead? if yes, what is the alternative? >>> >>> >>>> Thanx >>>> Noury >>>> >>>> >>> >>> >> >> >> >> >> > >

Oct. 9, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

Hi Dave, thanks to you. I updated OSProcess to 4.5.11 and CommandShell to 4.6.8; are those the latest? I did it last Sunday. Thierry Le 09/10/2014 22:42, David T. Lewis a Ã©crit : > Thierry, > > Thanks for doing those configuration updates, I hit "send" before I saw > your reply. > > Dave > >> Hi Noury, >> >> no, OSProcess on Squeaksource is not dead and is integrating all the >> changes needed for all the platforms it is running on. >> >> And as you can see, I very recently updated the configuration to make >> sure it was pointing to the very latest version. >> >> Regards, >> >> Thierry >> >> Le 09/10/2014 22:30, Noury Bouraqadi a Ã©crit : >>> Hi, >>> >>> Just tried to install the stable version of OSProcess using the >>> configuration browser on a 3.0. >>> I noticed it is still on http://www.squeaksource.com/OSProcess. >>> Does it mean it is dead? if yes, what is the alternative? >> >> >>> Thanx >>> Noury >>> >>> >> >> > > > > >

Oct. 9, 2014