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

Re: [Pharo-project] Some bugs

by Igor Stasenko

On 5 September 2011 18:02, Lukas Renggli <renggli(a)gmail.com> wrote: > Even if you have a AST debugger you still need at some point a bytecode to > AST (or source) mapping, because otherwise you cannot just break into a > debugger at a random point in the code. I imagine this jump from bytecode to > AST interpretation quite difficult; likely you still need a full bytecode > stepper to find a position where you can jump into the AST interpreter. > It depends, whether you able (or want to) insert a breakpoint which are inside a single AST node (for AST node which contains multiple bytecode), or allow to halt only at AST nodes boundaries. Consider C debugger - it has to deal with same situation: a single C statement could contain multiple machine code instructions, but when you stepping over that statement, you are not stepping over single machine code instruction(s) at a time, you stepping over single C statement. In some cases, stepping over single machine instruction is useful (especially when you dealing with generated machine code ;) but when you debugging a normal code, you don't need that, which means that if you have an AST -> bytecode ranges mapping you know the ranges and stepping points and don't have to interpret each bytecode separately, but intead just interpret what AST node does. > Lukas > > On Monday, 5 September 2011, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> 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 >>>>>> > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.

Sept. 6, 2011

Re: [Pharo-project] TextLint for Emacs & TextMate

by Damien Cassou

On Tue, Sep 6, 2011 at 9:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm how can I get it running? https://github.com/DamienCassou/textlint#readme -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 6, 2011

Re: [Pharo-project] Some bugs

by Igor Stasenko

On 6 September 2011 07:41, Michael van der Gulik <mikevdg(a)gmail.com> wrote: > On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> 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? > > Because the debugger might be looking at bytecodes that were generated > by something other than a Smalltalk compiler. > Then AST will serve for that even better, because a single AST node could be represented by several bytecodes, and by using a proper AST, debugger will know for sure how to step over single semantic element, written in your language. > Michael. > > > -- > http://gulik.pbwiki.com/ > > -- Best regards, Igor Stasenko.

Sept. 6, 2011

Re: [Pharo-project] TextLint for Emacs & TextMate

by StÃ©phane Ducasse

I'm how can I get it running? Stef On Sep 6, 2011, at 9:23 AM, Damien Cassou wrote: > Dear all, > > Lukas Renggli and I have worked on the integration of TextLint within > both TextMate and Emacs. TextLint is a tool to check your scientific > writing for common style errors. > > Integration within TextMate: http://www.youtube.com/watch?v=SrG29zWHqkk > Integration within Emacs: http://www.youtube.com/watch?v=CsG2DKgHanE > > It's written in Smalltalk and is currently accessible through: > > - Emacs (https://github.com/DamienCassou/textlint) > - TextMate (https://github.com/DamienCassou/textlint) > - The web (http://textlint.lukas-renggli.ch/) > - A Smalltalk IDE (http://scg.unibe.ch/research/textlint) > > Please report any issue to https://github.com/DamienCassou/textlint. > > I'm also very interested in feedback, code, and whatever can make the > whole thing better. > > If you have any problem or feedback, report on > https://github.com/DamienCassou/textlint > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

Sept. 6, 2011

[Pharo-project] TextLint for Emacs & TextMate

by Damien Cassou

Dear all, Lukas Renggli and I have worked on the integration of TextLint within both TextMate and Emacs. TextLint is a tool to check your scientific writing for common style errors. Integration within TextMate: http://www.youtube.com/watch?v=SrG29zWHqkk Integration within Emacs: http://www.youtube.com/watch?v=CsG2DKgHanE It's written in Smalltalk and is currently accessible through: - Emacs (https://github.com/DamienCassou/textlint) - TextMate (https://github.com/DamienCassou/textlint) - The web (http://textlint.lukas-renggli.ch/) - A Smalltalk IDE (http://scg.unibe.ch/research/textlint) Please report any issue to https://github.com/DamienCassou/textlint. I'm also very interested in feedback, code, and whatever can make the whole thing better. If you have any problem or feedback, report on https://github.com/DamienCassou/textlint -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 6, 2011

Re: [Pharo-project] Towards better HTTP client usage

by Sven Van Caekenberghe

On 06 Sep 2011, at 08:51, Philippe Marschall wrote: > On 09/05/2011 10:04 PM, Sven Van Caekenberghe wrote: >> >> On 05 Sep 2011, at 21:14, Philippe Marschall wrote: >> >>> Soâ¦ is that URL already percent encoded? If it isn't how do I specify >>> what encoding should be used? ;-) >> >> Url strings are fed to the ZnUrl parser. > > Does that mean they are expected to be percent encoded? In the case of #url: yes, with the 'construction' API, no: ZnNeoClient new url: 'http://www.example.com/Foo%20Bar/test.txt' is equivalent to ZnNeoClient new http; host: 'www.example.com'; addPath: 'Foo Bar'; addPath: 'test.txt' The idea is that the 'construction' API does the encoding for you. >> Ultimately percent encoding is resolved by String>>#unescapePercents which falls back to UTF-8. >> Currently, there is no option to specify another encoding. >> >> How/where would this be needed or useful ? > > When you want to use non-ASCII URLs and the server does not support > UTF-8, eg. VAST. > > I'm mostly concerned that the contract of the method is well specified, > not necessarily that every edge case is supported. OK, this might be a possible extension, one day. Sven

Sept. 6, 2011

Re: [Pharo-project] Towards better HTTP client usage

by Philippe Marschall

On 09/05/2011 10:04 PM, Sven Van Caekenberghe wrote: > > On 05 Sep 2011, at 21:14, Philippe Marschall wrote: > >> Soâ¦ is that URL already percent encoded? If it isn't how do I specify >> what encoding should be used? ;-) > > Url strings are fed to the ZnUrl parser. Does that mean they are expected to be percent encoded? > Ultimately percent encoding is resolved by String>>#unescapePercents which falls back to UTF-8. > Currently, there is no option to specify another encoding. > > How/where would this be needed or useful ? When you want to use non-ASCII URLs and the server does not support UTF-8, eg. VAST. I'm mostly concerned that the contract of the method is well specified, not necessarily that every edge case is supported. Cheers Philippe

Sept. 6, 2011

Re: [Pharo-project] Pharo is getting fast

by Max Leske

NICE! :D On 05.09.2011, at 23:15, Sean P. DeNigris wrote: > FileDirectory onto a disk and physically burn it, like in a bonfire; no > kidding)

Sept. 6, 2011

Re: [Pharo-project] Some bugs

by Michael van der Gulik

On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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? Because the debugger might be looking at bytecodes that were generated by something other than a Smalltalk compiler. Michael. -- http://gulik.pbwiki.com/

Sept. 6, 2011

Re: [Pharo-project] Pharo is getting fast

by Sean P. DeNigris

Igor Stasenko wrote: > > you seem very happy those days :) > This was a great Smalltalk month: * I've got a fast VM with all the plugins I need * I learned how to build and debug the VM * I ported my projects to 1.3 (and they seem to be working fine) * FileSystem (with all the other 1.4 goodies) is on the way (I may file out FileDirectory onto a disk and physically burn it, like in a bonfire; no kidding) -- View this message in context: http://forum.world.st/Pharo-is-getting-fast-tp3791983p3792156.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 5, 2011