September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

> > OK, then I finally succeeded in decoding Marcus/Stef high level > instructions into low level specifications. > I translate here for those obscurantists speaking native gdb: you want > step/jump instead of stepi/jumpi. > But it would have been better to provide detailed explanations from > the beginning for slow brained like me ;). > > Nonetheless, you still need to map execution machiney to source code > because of initial program counter, and in case of AST-based stepping, > the map must be bi-directional in order to execute multiple bytecodes > sometimes required by a single instruction. > > Nicolas yes :) we were not clear. Do not worry. Stef

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

>> > > By the way, I would find it cool to have an optional byteCode view > parallel to source code view and see the execution of byte codes, and > why not, a view of Context stack frames. > Also, the debugger might step message by message (AST-based) rather > than byteCode by byteCode, is this what you mean by wrong abstraction > level ? yes :)

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

We were thinking with marcus that using byte code to go back to sources code is broken by essence and that using an AST is the way to go. Now we would need a good AST-based interpreter to start with. > 2011/9/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> BTW mike roberts is building a tool to be able to understand and fix the code range of the debugger hilighting. >> Probably your bug is also related to the closure introduction. >> >> Now the abstraction used is so low level that this is a pain and fragile. >> Ideally using an AST would be much better but this is for the future. >> >> Stef >> > > Stef, > If you are saying that implementation is not crystal clear, I can only > agree with you. > Eliot did avoid a full rewrite (I guess he took the shortest path to > make the available implementation work with closures), and this design > decision can be questioned indeed. > > But speaking of abstraction level by itself, I don't understand your sentence. > To me, the abstraction is at the correct level. > The Debugger has to map the low level execution machinery > (Context/program counter/CompiledMethod/byteCodes) to high level > specification visible to the user (source code). > The Debugger does so by mapping bytecodes to source ranges via AST, no > more, no less. > > In case of inlined blocks, there are more instructions on the bytecode > side than messages sent on the AST side, just to make the problem a > bit more complex, so maybe there are more intelligent way to address > the mapping problem (maybe you mean via an intermediate transformation > of AST), but you'll have to explain this a bit deeper. > > Nicolas > >> >> On Sep 5, 2011, at 9:07 AM, Andrea BrÃ¼hlmann wrote: >> >>> Hello Stef, >>> >>> I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that >>> we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 >>> (debugger) where we really need your help. Other issues like the buggy code completion can be >>> workarounded by me by disabling code completion ;-) >>> >>> So thanks for the welcome and I am looking forward to having 4694 fixed! >>> >>> Andrea >>> >>> >>> >>> >>> StÃ©phane Ducasse schrieb: >>>> Thanks andrea >>>> Welcome to the pharo mailing-list and community. Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) that you should also contribute. Bug reporting is already a contribution. Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). I also understand that people can get frustrated by changes but what can we do? >>>> May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. >>>> Imagine well that we have one engineer full time since 8 months. Stef >>>> On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: >>>>> Hello, >>>>> >>>>> I reported some bugs on the issue tracker and hope you can help me with them! >>>>> >>>>> >>>>> 4681: Accepting with the enter key does not work >>>>> http://code.google.com/p/pharo/issues/detail?id=4681 >>>>> >>>>> 4682: Code completion makes strange cursor placements and too many spaces >>>>> http://code.google.com/p/pharo/issues/detail?id=4682 >>>>> >>>>> 4683: Code completion breaks some search fields (errors during typing) >>>>> http://code.google.com/p/pharo/issues/detail?id=4683 >>>>> >>>>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>>>> http://code.google.com/p/pharo/issues/detail?id=4684 >>>>> >>>>> 4685: Merge dialog: cannot resolve conflict with removed method >>>>> http://code.google.com/p/pharo/issues/detail?id=4685 >>>>> >>>>> 4686: Method category change creates no new version >>>>> http://code.google.com/p/pharo/issues/detail?id=4686 >>>>> >>>>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >>>>> http://code.google.com/p/pharo/issues/detail?id=4687 >>>>> >>>>> 4688: Progress bar disappears on image save >>>>> http://code.google.com/p/pharo/issues/detail?id=4688 >>>>> >>>>> 4689: MessageTally bug >>>>> http://code.google.com/p/pharo/issues/detail?id=4689 >>>>> >>>>> 4690: Progress bar position >>>>> http://code.google.com/p/pharo/issues/detail?id=4690 >>>>> >>>>> 4691: Bad line breaks in code until window is resized (because of bold text?) >>>>> http://code.google.com/p/pharo/issues/detail?id=4691 >>>>> >>>>> 4692: Drop downs should select the default entry (topmost) instead of a middle one >>>>> http://code.google.com/p/pharo/issues/detail?id=4692 >>>>> >>>>> 4693: Line breaks in tooltips are wrong >>>>> http://code.google.com/p/pharo/issues/detail?id=4693 >>>>> >>>>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >>>>> http://code.google.com/p/pharo/issues/detail?id=4694 >>>>> >>>>> 4695: Time asString prints nanos unrounded >>>>> http://code.google.com/p/pharo/issues/detail?id=4695 >>>>> >>>>> >>>>> -- >>>>> Andrea BrÃ¼hlmann >>>>> >>> >>> >>> -- >>> AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >>> | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >>> | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 >>> | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >>> >> >> >> >

Sept. 5, 2011

Re: [Pharo-project] [Vm-dev] [VM-team] [ANN] VMMaker repository home is now http://source.squeak.org/VMMaker

by David T. Lewis

On Mon, Sep 05, 2011 at 09:38:02AM -0400, David T. Lewis wrote: > > The automated commit notices to the vm-dev list will now come from > source.squeak.org, and the commit notices from squeaksource.com have > been disabled. This is to permit files to be copied between > source.squeak.org/VMMaker and squeaksource.com/VMMaker without > duplicate commit notices. > Oops, the automated commit notices do not seem to be working yet, probably because of something I have configured wrong. I will manually bounce notices to the list until I get it sorted out (using commit notices from SqueakSource, which are still being directed to my email). Dave

Sept. 5, 2011

[Pharo-project] [VM-team] [ANN] VMMaker repository home is now http://source.squeak.org/VMMaker

by David T. Lewis

The VMMaker source repository is now located at: MCHttpRepository location: 'http://source.squeak.org/VMMaker' user: '' password: '' This is a mirror of the http://www.squeaksource.com/VMMaker repository, with all historical files, and with no change to policy. The intent of the move is to improve reliability and availability of the VMMaker repository for all project participants. The automated commit notices to the vm-dev list will now come from source.squeak.org, and the commit notices from squeaksource.com have been disabled. This is to permit files to be copied between source.squeak.org/VMMaker and squeaksource.com/VMMaker without duplicate commit notices. Commits to VMMaker should now be made to the new repository, and direct references to the VMMaker repository (e.g. ConfigurationOfVMMaker) should be updated to reflect the change. For Squeak and Pharo users who use VMMaker through Monticello or Metacello, there should be no immediate change. However, adding a repository for http://source.squeak.org/VMMaker is recommended at your earliest convenience. I wish to add my appreciation for SqueakSource, which serves as a valuable community resource and has for many years been the home of the VMMaker project. I further note that many plugins used by VMMaker are hosted on SqueakSource, and this will continue to be the case. Thanks also to Bert Freudenberg for setting up the new repository with a complete mirror copy of the VMMaker project. Dave

Sept. 5, 2011

[Pharo-project] #copyReplaceAll:with: vs. the schlemiel

by Camillo Bruni

I stumbled upon the horrible implementation of SequenceableCollection >> #copyReplaceAll:with: Not only was it horribly documented (only for strings) but also horribly inefficient nicely following the painters algorithm :). On to replacing this craftwork with a stream based solution I figured out that it breaks quite a few tests: Namely the #testCopyReplaceAllWith1Occurence test doesn't work with the following classes anymore: - LinkedList - Interval - SortedCollection - Symbol Now I think this test does't make much sense for SortedCollection/Intervals. SortedCollection enforces a certain order on the objects, meaning that replacing a slice of elements with something else yields a completely new intermediate collection. So unless the collection is first converted to an OrderedCollection I don't see much sense in supporting this method on SortedCollection. For Intervals there's a similar issue. Replacing elements in an Interval doesn't work (yetâ¦) so again, only an indirect OrderedCollection helps thereâ¦ On Symbol there's the problem of #streamContents which should use #species and an intermediate String to build up the Symbol. cami

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Nicolas Cellier

2011/9/5 Marcus Denker <marcus.denker(a)inria.fr>: > > On Sep 5, 2011, at 2:06 PM, Nicolas Cellier wrote: >> >> By the way, I would find it cool to have an optional byteCode view >> parallel to source code view and see the execution of byte codes, and >> why not, a view of Context stack frames. >> Also, the debugger might step message by message (AST-based) rather >> than byteCode by byteCode, is this what you mean by wrong abstraction >> level ? >> > With the wrong abstraction level: Why do we care about stepping bytecodes > at all? Why not only have an AST interpreter based debugger? > > Â Â Â Â Marcus > > OK, then I finally succeeded in decoding Marcus/Stef high level instructions into low level specifications. I translate here for those obscurantists speaking native gdb: you want step/jump instead of stepi/jumpi. But it would have been better to provide detailed explanations from the beginning for slow brained like me ;). Nonetheless, you still need to map execution machiney to source code because of initial program counter, and in case of AST-based stepping, the map must be bi-directional in order to execute multiple bytecodes sometimes required by a single instruction. Nicolas > > -- > Marcus Denker -- http://marcusdenker.de > > >

Sept. 5, 2011

Re: [Pharo-project] Zinc crashing image at start up

by Sven Van Caekenberghe

On 04 Sep 2011, at 22:35, Sven Van Caekenberghe wrote: > OK, thanks for the extra info. > I'll see what I can do tomorrow, after thinking about this a bit. > If I can't reproduce this, I can't debug it. I am really very confused and don't understand what is happening, but here is what I found out: Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/seaside3-zinc.st. Now the hang (100% cpu, no crash or any log to be seen) only happens in two cases: running from the command line (as in the build script): ./coglinux/bin/squeak -nodisplay -nosound seaside3.image /home/sven/Smalltalk/builder/scripts/seaside3-zinc.st or doing a file in of this file using the File Browser in Pharo. Executing the same code manually (selecting it and performing a doit) works fine. Note to replicate this you have to use a specific version, as in Gofer new squeaksource: 'ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.191'; package: 'Zinc-Seaside'; load. And then starting the Seaside adapter in one go. On Mac OS X, I cannot reproduce this at all. The difference between the working version (188) and the failing ones (up until 191) is very small IMHO, that's what is so strange. So I decided to revert back by pushing down the connection management functionality of ZnMultiThreadedServer to a new subclass called ZnManagingMultiThreadedServer. Now the code difference between working and failing code is even smaller. Note also that the server is just started, it is not yet receiving any connections! Any help would be appreciated ;-) Lukas, I think you could try to rebuild the failing Seaside jobs. Sven

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Marcus Denker

On Sep 5, 2011, at 2:06 PM, Nicolas Cellier wrote: > > By the way, I would find it cool to have an optional byteCode view > parallel to source code view and see the execution of byte codes, and > why not, a view of Context stack frames. > Also, the debugger might step message by message (AST-based) rather > than byteCode by byteCode, is this what you mean by wrong abstraction > level ? > With the wrong abstraction level: Why do we care about stepping bytecodes at all? Why not only have an AST interpreter based debugger? Marcus -- Marcus Denker -- http://marcusdenker.de

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Nicolas Cellier

2011/9/5 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/9/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> BTW mike roberts is building a tool to be able to understand and fix the code range of the debugger hilighting. >> Probably your bug is also related to the closure introduction. >> >> Now the abstraction used is so low level that this is a pain and fragile. >> Ideally using an AST would be much better but this is for the future. >> >> Stef >> > > Stef, > If you are saying that implementation is not crystal clear, I can only > agree with you. > Eliot did avoid a full rewrite (I guess he took the shortest path to > make the available implementation work with closures), and this design > decision can be questioned indeed. > > But speaking of abstraction level by itself, I don't understand your sentence. > To me, the abstraction is at the correct level. > The Debugger has to map the low level execution machinery > (Context/program counter/CompiledMethod/byteCodes) to high level > specification visible to the user (source code). > The Debugger does so by mapping bytecodes to source ranges via AST, no > more, no less. > > In case of inlined blocks, there are more instructions on the bytecode > side than messages sent on the AST side, just to make the problem a > bit more complex, so maybe there are more intelligent way to address > the mapping problem (maybe you mean via an intermediate transformation > of AST), but you'll have to explain this a bit deeper. > > Nicolas > By the way, I would find it cool to have an optional byteCode view parallel to source code view and see the execution of byte codes, and why not, a view of Context stack frames. Also, the debugger might step message by message (AST-based) rather than byteCode by byteCode, is this what you mean by wrong abstraction level ? Nicolas >> >> On Sep 5, 2011, at 9:07 AM, Andrea BrÃ¼hlmann wrote: >> >>> Hello Stef, >>> >>> I appreciate the work of the pharo community! We will continue reporting bugs and submit fixes that >>> we made. Of course I do not expect anyone to fix all reported bugs, but there are issues like 4694 >>> (debugger) where we really need your help. Other issues like the buggy code completion can be >>> workarounded by me by disabling code completion ;-) >>> >>> So thanks for the welcome and I am looking forward to having 4694 fixed! >>> >>> Andrea >>> >>> >>> >>> >>> StÃ©phane Ducasse schrieb: >>>> Thanks andrea >>>> Welcome to the pharo mailing-list and community. Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine) that you should also contribute. Bug reporting is already a contribution. Â Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that). I also understand that people can get frustrated by changes but what can we do? >>>> May be people can gather and check the fixes that are important to fix but we do not have the force to maintain. >>>> Imagine well that we have one engineer full time since 8 months. Stef >>>> On Aug 23, 2011, at 8:54 AM, Andrea BrÃ¼hlmann wrote: >>>>> Hello, >>>>> >>>>> I reported some bugs on the issue tracker and hope you can help me with them! >>>>> >>>>> >>>>> 4681: Accepting with the enter key does not work >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4681 >>>>> >>>>> 4682: Code completion makes strange cursor placements and too many spaces >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4682 >>>>> >>>>> 4683: Code completion breaks some search fields (errors during typing) >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4683 >>>>> >>>>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4684 >>>>> >>>>> 4685: Merge dialog: cannot resolve conflict with removed method >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4685 >>>>> >>>>> 4686: Method category change creates no new version >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4686 >>>>> >>>>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil) >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4687 >>>>> >>>>> 4688: Progress bar disappears on image save >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4688 >>>>> >>>>> 4689: MessageTally bug >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4689 >>>>> >>>>> 4690: Progress bar position >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4690 >>>>> >>>>> 4691: Bad line breaks in code until window is resized (because of bold text?) >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4691 >>>>> >>>>> 4692: Drop downs should select the default entry (topmost) instead of a middle one >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4692 >>>>> >>>>> 4693: Line breaks in tooltips are wrong >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4693 >>>>> >>>>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+. >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4694 >>>>> >>>>> 4695: Time asString prints nanos unrounded >>>>> Â Â http://code.google.com/p/pharo/issues/detail?id=4695 >>>>> >>>>> >>>>> -- >>>>> Andrea BrÃ¼hlmann >>>>> >>> >>> >>> -- >>> AB Â Â | Â ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >>> Â Â Â | Â NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >>> Â Â Â | Â TEL Â +41 31 356 42 54 Â· FAX Â +41 31 356 42 51 >>> Â Â Â | Â WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >>> >> >> >> >

Sept. 5, 2011