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

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

by Eliot Miranda

On Mon, Sep 5, 2011 at 8:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 September 2011 17:49, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> 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. > >> > >> 2370 is old, from 18 March 2011. The current version is 2489 from 22 > >> August. Why are you using 2370? > > > > Hi Eliot, > > > > I am lazy. I don't update the VMs on my servers that often. If you > > think this helps with the socket issues, I am of course all for > > updating it right away? > > > > I recommend you to update. > The latest VMs containing a couple of critical bug fixes , which makes > a lot of difference. > Not sure it will help with sockets issue, but at least it will help > getting an up to date feedback :) > !right! :) > > > Lukas > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- best, Eliot

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Eliot Miranda

Hi Nicolas, that's quite a lot to absorb. Exactly what do you want me to review? The first thing it seems to me is to define what we want to be highlighted at different bytecodes in an optimized loop. A second thing is to think about how the debugger can avoid stepping through the hidden sends that are part of a loop. What I mean is that 1 to: n do: [:i| ....] is actually i := 1. [i <= n] whileTrue: [ and so the debugger steps through i:= 1 and i <= n, even though these aren't visible in the source. That's why one has to click several times to get into the body of the loop. The debugger could for example use the source ranges for the bytecodes to step until the source range changes. So if there is the same source range info for all the bytecodes involved in the loop iteration (not the loop body) the debugger will be able to respond to step properly. What do you think? [sorry for not having responded sooner; esug and personal issues have got in the way. apologies] On Thu, Aug 25, 2011 at 1:06 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > A few more notes: > > - Encoder>>rawSourceRanges answer a mapping AST Node -> sourceRange > Gnerally, I would expect sourceRange to be an Interval, but this has > to be confirmed. > Theses ranges are constructed at source code Parse time (see senders > of #noteSourceRange:forNode:) > - The program counters are assigned to AST nodes at byte code #generate > time > - for inlined macros, like #to:do: in our case, this pc is after the > initialize and test statements. > > in CompiledMethod>>#rawSourceRangesAndMethodDo: > I just evaluated this: > > methNode encoder rawSourceRanges collect: [:ival | > sourceText copyFrom: ival first to: ival last] > > And what I see is that the original to:do: message (before macros > inlining) has the right range > {1 > to: 5 > do: [:index | > temp := index. > collection > add: [temp]]}->a Text for 'to: 5 do: [ :index | > temp := index. > collection add: [ temp ] ]' > This node is the original #to:do: and has pc=42 > > There is also > {a LeafNode}->a Text for '[ :index | > temp := index. > collection add: [ temp ] ]' > which has a nil pc so it won't be taken into account in the source map. > > But one of the messages produced by the inlining has this curious range: > {index <= 5}->a Text for 'to: 5 do: [ :index | > temp := index. > c' > This node has pc = 40, so it will be selected before the correct one > above has a chance to be. > {index <= 5} is the test statement produced by inlining, and this > seems to be the incorrect highlighting we see. > Thus we know we have to concentrate on macro inlining. > This happens in MessageNode>>transformToDo: > We'll see this. > > In the interim, I played with eliminating the nodes having unitilialized pc > Let us try to evaluate this snippet in debugger's inspector: > (methNode encoder rawSourceRanges keys select: [:e | e pc > 0]) > collect: [:node | > | ival | > ival := methNode encoder rawSourceRanges at: node. > node -> (sourceText copyFrom: ival first to: ival last)] > > Oh god, a bug in the debugger: > DoItIn: homeContext > ^ ((homeContext namedTempAt: 2) encoder rawSourceRanges keys > select: [:e | e pc > 0]) > collect: [:node | > | ival | > ival := (node namedTempAt: 2) encoder > rawSourceRanges at: node. > node > -> (sourceText copyFrom: ival first to: ival > last)] > (node namedTempAt: 2) does not mean a thing... > A confusion occurred between the homeContext (DoItIn: method argument) > and node (the block argument) > Nevermind... forget about it. > > Now let's just concentrate on MessageNode>>transformToDo: > We see this code: > test := MessageNode new > receiver: blockVar > selector: (increment key > 0 ifTrue: [#<=] > ifFalse: [#>=]) > arguments: (Array with: limit) > precedence: precedence from: encoder > sourceRange: (myRange first to: blockRange > first). > > So the intention seems to select 'to: 5 do: ' > > But we see this: > BlockNode>>noteSourceRangeStart:end:encoder: > "Note two source ranges for this node. One is for the debugger > and is of the last expression, the result of the block. One is for > source analysis and is for the entire block." > encoder > noteSourceRange: (start to: end) > forNode: self closureCreationNode. > startOfLastStatement > ifNil: > [encoder > noteSourceRange: (start to: end) > forNode: self] > ifNotNil: > [encoder > noteSourceRange: (startOfLastStatement to: > end - 1) > forNode: self] > > So it seems intentional to select only the last instruction of the > block for the debugger. > We'd better not change this without prior asking Eliot. > But obviously, this is not what is expected by the #transformToDo: > > Nicolas > > 2011/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > tx nicolas this is a cool way to help :) > > > > Stef > > > > On Aug 24, 2011, at 9:54 PM, Nicolas Cellier wrote: > > > >> So the entries of interest for highlighting are > >> > >> Debugger>>contentsSelection > >> Debugger>>pcRange > >> CompiledMethod>>debuggerMap > >> DebuggerMethodMap class>>forMethod: > >> DebuggerMethodMap>>rangeForPC:contextIsActiveContext: > >> > >> Then you see the DebuggerMethodMap>>forMethod:methodNode: takes both a > >> CompiledMethod and its #methodNode. > >> CompiledMethod>>methodNode invokes the Parser to get the > >> AbstractSyntaxTree from method source, and if it ever fails ends up by > >> trying to decompile the byteCodes. > >> > >> This is the easy part. Now we to deal with #abstractPCForConcretePC: > >> and #abstractSourceMap. > >> > >> By reading CompiledMethod>>abstractPCForConcretePC: you should quickly > >> understand that a concrete PC is a byte offset of current byteCode > >> (the offsets displayed in the byteCode view) while the abstractPC is > >> just the rank of current byteCode in the list of byteCodes > >> instructions composing the CompiledMethod. This is just because > >> "byteCodes" may spread on several bytes beside their name... > >> This will use InstructionStream and InstructionClient which are just > >> an iterator and a sort of visitor on byteCode instructions. > >> So this is not really interesting. > >> > >> The more interesting part is #abstractSourceMap > >> There is a first step to obtain > CompiledMethod>>rawSourceRangesAndMethodDo: > >> This is the most important part. > >> The rest is again a mapping from concretePC (instruction byte offset) > >> to abstractPC (instruction rank). > >> And some build of a dictionary mapping instruction rank (abstractPC) > >> -> selected range. > >> > >> Note that the last trick seems to use a regenerated CompiledMethod > >> (theMethodToScan) rather than the original CompiledMethod. There is no > >> assertion whether these two are equivalent or not. A priori, they > >> should, unless the Compiler changed since last compilation or if its > >> behaviour is affected by some Preferences... Would we introduce some > >> customizable Compiler optimizations that this could become a problem > >> (We would then add to map decompiled AST to source code AST, probably > >> with guesses, unless the CompiledMethod would contain debugger > >> friendly hints...) > >> We will consider this is not a problem by now. > >> > >> So let's now concentrate on rawSourceRangesAndMethodDo: > >> The nice thing is that you now can just debug this > >> > >> (ClosureTests>>#testToDoOutsideTemp) methodNode > >> rawSourceRangesAndMethodDo: [:rs :mth | ] > >> > >> and see how it goes in Squeak. I did not look in Pharo yet, but I > >> would be amazed to see it much different. > >> It's now late, and my spare time is off, but you have clues to get > >> more insights. I wish you good debugging, and come back to me if it > >> ever goes in deeper complications. > >> > >> Cheers > >> > >> Nicolas > >> > >> 2011/8/24 Michael Roberts <mike(a)mjr104.co.uk>: > >>> > >>>> > >>>> Ok I'm curious to know then. > >>> > >>> Here is a little trace from this example method: > >>> > >>> toDoOutsideTemp > >>> | temp collection | > >>> collection := OrderedCollection new. > >>> 1 to: 5 do: [ :index | > >>> temp := index. > >>> collection add: [ temp ] ] > >>> > >>> Trace is start,stop position of the highlight for each 'step over'. > >>> > >>> Whilst the numbers are hard to visualise, below you can see how they > >>> slightly diverge. > >>> Left Pharo Right Squeak > >>> > >>> 50, 73 71, 73 diff > >>> 71, 73 71, 73 > >>> 50, 73 50, 73 > >>> 108, 115 79, 121 diff > >>> 79, 121 79, 121 > >>> 108, 115 108, 115 > >>> 132, 144 132, 144 > >>> 147, 146 146, 146 (diff negative size means no highlight) > >>> 146, 146 146, 146 > >>> 79, 121 79, 121 > >>> 108, 115 108, 115 > >>> 132, 144 132, 144 > >>> 147, 146 146, 146 > >>> 146, 146 146, 146 > >>> 79, 121 79, 121 > >>> 108, 115 108, 115 > >>> 132, 144 132, 144 > >>> 147, 146 146, 146 > >>> 146, 146 146, 146 > >>> 79, 121 79, 121 > >>> 108, 115 108, 115 > >>> etc... > >>> For example the first difference is because Pharo shows the whole > assignment > >>> of the first line as the first send, even though it is not. > >>> The second difference is that Pharo shows the assignment inside the > block as > >>> the first highlight of the loop even though the to:do should be > >>> highlighted....but both Pharo & Squeak get the to:do: wrong when they > choose > >>> to show it. > >>> hope you get the idea... > >>> Mike > >> > > > > > > > > -- best, Eliot

Sept. 5, 2011

[Pharo-project] AutoStart, where are you?

by Sean P. DeNigris

This class was in 1.2, but is missing in 1.3. Why was it removed and what has replaced it? Also, is there a flaw in the deprecation system that has me ask these questions in the first place? I can't load XMLRPC because of: Smalltalk addToStartUpList: self after: AutoStart. What do I replace this with? Sean p.s. I found mentions in several issues and ml posts, but nothing definitive. -- View this message in context: http://forum.world.st/AutoStart-where-are-you-tp3791613p3791613.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Eliot Miranda

On Mon, Sep 5, 2011 at 8:02 AM, 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. > Right. Basically the two levels, source and bytecode are all one needs and a fixation with ASs doesn't really help. The bytecode is quite tractible, and look at the different performance/quality of Smalltalk vs Ruby for what bytecode vs AST architectures get you. > 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, Eliot

Sept. 5, 2011

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

by Igor Stasenko

On 5 September 2011 17:49, Lukas Renggli <renggli(a)gmail.com> wrote: >>> 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. >> >> 2370 is old, from 18 March 2011. Â The current version is 2489 from 22 >> August. Â Why are you using 2370? > > Hi Eliot, > > I am lazy. I don't update the VMs on my servers that often. If you > think this helps with the socket issues, I am of course all for > updating it right away? > I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date feedback :) > Lukas > -- Best regards, Igor Stasenko AKA sig.

Sept. 5, 2011

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

by Lukas Renggli

>> 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. > > 2370 is old, from 18 March 2011. Â The current version is 2489 from 22 > August. Â Why are you using 2370? Hi Eliot, I am lazy. I don't update the VMs on my servers that often. If you think this helps with the socket issues, I am of course all for updating it right away? Lukas >> >> 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 >> >> > > > > -- > best, > Eliot > -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2011

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

by Eliot Miranda

On Mon, Sep 5, 2011 at 5:46 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > 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 > . > 2370 is old, from 18 March 2011. The current version is 2489 from 22 August. Why are you using 2370? > 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 > > > -- best, Eliot

Sept. 5, 2011

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

by Lukas Renggli

> 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. With Cog on some systems we had initially problems with Kom because the sockets were closed in a separate thread and we had to wait for that thread to terminate. I don't think Zn has any asynchronous behaviors. Or would it help to wait a second before the image is saved? > 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. Thank you for looking into this. The jobs are rebuilding right now. Lukas -- Lukas Renggli www.lukas-renggli.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 10:17:21AM -0400, David T. Lewis wrote: > > 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). Fixed. Dave

Sept. 5, 2011

Re: [Pharo-project] Some bugs

by Lukas Renggli

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. 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

Sept. 5, 2011