- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some bugs

by Michael Roberts

http://code.google.com/p/pharo/wiki/DebuggerInternals

Aug. 25, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

;-) thanks! yes i looked at it a little with Marcus and got lost when the InstructionStream was invoked. Your analysis is really useful. i have a 4 hr train journey soon! Mike On Wed, Aug 24, 2011 at 10:08 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/8/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > 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 > > > > Oh, I couldn't resist and just tried, and it's indeed getting harder, > because it involves a zoo of Compiler internals, at least the Encoder, > the BlockAnalyzer... > Funny, the method node is once more generated in this phase :). All > this stuff is cached at upper level, but we have at least clues for > further optimizations ;) > > 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 > > > >

Aug. 25, 2011

Re: [Pharo-project] expanding text morph

by Tudor Girba

Ok, here comes a follow up question. I would like now to have the morph in a tab, have the tab in the expander, and get this tab to resize when the inner text morph changes. I tried to make the tab shrinkWrap, but it does not seem to work there. Is it possible that this is a problem of the TabGroupMorph? Here is the code I used: textMorph := UITheme builder newText: ''. textMorph hResizing: #spaceFill; borderWidth: 1; unlock. tabs := TabGroupMorph new. tabs vResizing: #shrinkWrap; hResizing: #spaceFill; addPage: textMorph label: 'Tab'. tabs selectedPageIndex: 1. (UITheme builder newColumn: { UITheme builder newExpander: 'One' for: tabs. UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. textMorph contentsWrapped: 'Some text here use #contentsWrapped: to change text' Cheers, Doru On 25 Aug 2011, at 01:24, Tudor Girba wrote: > Pretty cool! > > Thanks, > Doru > > > On 24 Aug 2011, at 11:54, Gary Chambers wrote: > >> In the following example the expander resizes >> >> |textMorph| >> textMorph := UITheme builder newText: ''. >> textMorph >> hResizing: #spaceFill; >> borderWidth: 1. >> (UITheme builder newColumn: { >> UITheme builder newExpander: 'One' for: textMorph. >> UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. >> >> textMorph contentsWrapped: 'Some text here >> use #contentsWrapped: to change text' >> >> In general, if the surrounding morph has #shrinkWrap constraints then changes to the (minimum) dimensions of its submorphs will propagate resulting in a change of size for the surrounding morph. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 23, 2011 1:36 PM >> Subject: Re: [Pharo-project] expanding text morph >> >> >> Thanks, Gary! >> >> And now the next question: >> If I place this one in a surrounding pane / expander / tab, how do I get the surrounding morph to resize when the text changes? >> >> Cheers, >> Doru >> >> >> On 22 Aug 2011, at 12:15, Gary Chambers wrote: >> >>> Hi Doru >>> >>> >>> |textMorph| >>> textMorph := UITheme builder newText: ''. >>> textMorph >>> hResizing: #spaceFill; >>> borderWidth: 1. >>> (UITheme builder newColumn: {textMorph}) openInWindow. >>> textMorph contentsWrapped: 'Some text here >>> >>> Get a halo and inspect the text morph >>> then use #contentsWrapped: to change text >>> >>> >>> and see the results! >>> >>> #rigid hResizing also works.' >>> >>> >>> >>> Have fun! >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 21, 2011 11:57 PM >>> Subject: [Pharo-project] expanding text morph >>> >>> >>> Hi, >>> >>> I would like to create a Text Morph that wraps the text horizontally, and expands the height to fit the text. Thus, this morph would never offer scrolling. >>> >>> How could I do that? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "There are no old things, there are only old ways of looking at them." >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Aug. 25, 2011

Re: [Pharo-project] [ANN] OpenDBXDriver Release - DBXTalk Release Step 1

by Guillermo Polito

Hmm, I confused and attached the tex file :P. Here is the pdf! On Wed, Aug 24, 2011 at 9:19 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi folks!! > > We are proud to make our first release of OpenDBXDriver -1.0 version-, > formerly known as SqueakDBX. Now the project involves much more than just a > database driver. This whole new project is called DBXTalk and OpenDBXDriver > is just one of the sub-projects. > > There are several changes between this version and the last one of > SqueakDBX, but most of them is about infrastructure: test were moved to a > separate package, platform packages and backend classes were renamed, all > "SqueakDBX" was replaced with its new name. > > To install it: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOpenDBXDriver'; > load. > > (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: #project) > perform: #version: with: #stable) load. > > > We have also created a new repository for all the code: > http://www.squeaksource.com/DBXTalk > > The issue tracker is in: http://code.google.com/p/dbxtalk/issues/list > > Thanks to Natacha Perrin we have a new DBXTalk logo that you can see in: > http://imageshack.us/photo/my-images/37/dbxtalk46.png > The license of the logo is Creative Commons. > > We have also started a Pharo By Example chapter. So far we are writing > about DBXTalk, but soon we will do about Glorp. We attach a draft of it > while it is integrated into the main git repository of the book. > Just in case here is the git repo fork: > https://github.com/guillep/PharoByExample-english. > > Just to let you know, we have already ported the last VW release of Glorp > to Pharo and we have it already working MySQL, PostgreSQL, Oracle and > Sqlite3. We are closing some last problems and we will soon make the first > release. We want to thanks Alan Night for all his help and his reviews :). > > 4 persons of the team are present at ESUG right now and we are going to > give a talk on Friday. We will upload then the slides. > > Finally, we would like to thanks ESUG for the sponsorship through this ESUG > SummerTalk. > > Thanks! > Guille, Mariano, Esteban, Santiago, Gise >

Aug. 24, 2011

Re: [Pharo-project] expanding text morph

by Tudor Girba

Pretty cool! Thanks, Doru On 24 Aug 2011, at 11:54, Gary Chambers wrote: > In the following example the expander resizes > > |textMorph| > textMorph := UITheme builder newText: ''. > textMorph > hResizing: #spaceFill; > borderWidth: 1. > (UITheme builder newColumn: { > UITheme builder newExpander: 'One' for: textMorph. > UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. > > textMorph contentsWrapped: 'Some text here > use #contentsWrapped: to change text' > > In general, if the surrounding morph has #shrinkWrap constraints then changes to the (minimum) dimensions of its submorphs will propagate resulting in a change of size for the surrounding morph. > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, August 23, 2011 1:36 PM > Subject: Re: [Pharo-project] expanding text morph > > > Thanks, Gary! > > And now the next question: > If I place this one in a surrounding pane / expander / tab, how do I get the surrounding morph to resize when the text changes? > > Cheers, > Doru > > > On 22 Aug 2011, at 12:15, Gary Chambers wrote: > >> Hi Doru >> >> >> |textMorph| >> textMorph := UITheme builder newText: ''. >> textMorph >> hResizing: #spaceFill; >> borderWidth: 1. >> (UITheme builder newColumn: {textMorph}) openInWindow. >> textMorph contentsWrapped: 'Some text here >> >> Get a halo and inspect the text morph >> then use #contentsWrapped: to change text >> >> >> and see the results! >> >> #rigid hResizing also works.' >> >> >> >> Have fun! >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Sunday, August 21, 2011 11:57 PM >> Subject: [Pharo-project] expanding text morph >> >> >> Hi, >> >> I would like to create a Text Morph that wraps the text horizontally, and expands the height to fit the text. Thus, this morph would never offer scrolling. >> >> How could I do that? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > -- www.tudorgirba.com "We are all great at making mistakes."

Aug. 24, 2011

Re: [Pharo-project] [squeak-dev] new Cog VMs available

by Levente Uzonyi

On Tue, 16 Aug 2011, Eliot Miranda wrote: > in http://www.mirandabanda.org/files/Cog/VM/VM.r2487/. > > Fix bugs described in the "[Pharo-project] Troubles with #flushCache and > #run:with:in:" thread http://lists.gforge.inria.fr/pipermail/pharo-project/ > 2011-July/050858.html. The PIC machinery wrongly treated invoke-as-method > sends as MNUs. > > Closely related, finally fully implement PIC MNU cacheing where, by calling > a > special abort, a PIC is able to record that a gven selector is an MNU for a > particular class. Speeds up a simple MNU benchmark by 33% (with more > performance the deeper the receiver's cass hierarchy is). Sounds great. Does it work with #cannotInterpret:? Levente > > On Mac fix mis-editing of Info.plist to insert revision info so that VM .app > once again starts on 10.5.x. > -- > best, > Eliot >

Aug. 24, 2011

Re: [Pharo-project] Some bugs

by Nicolas Cellier

2011/8/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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 > Oh, I couldn't resist and just tried, and it's indeed getting harder, because it involves a zoo of Compiler internals, at least the Encoder, the BlockAnalyzer... Funny, the method node is once more generated in this phase :). All this stuff is cached at upper level, but we have at least clues for further optimizations ;) 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 >

Aug. 24, 2011

Re: [Pharo-project] Some bugs

by Nicolas Cellier

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

Aug. 24, 2011

Re: [Pharo-project] [ANN] OpenDBXDriver Release - DBXTalk Release Step 1

by StÃ©phane Ducasse

Excellent! Stef On Aug 24, 2011, at 1:19 PM, Guillermo Polito wrote: > Hi folks!! > > We are proud to make our first release of OpenDBXDriver -1.0 version-, formerly known as SqueakDBX. Now the project involves much more than just a database driver. This whole new project is called DBXTalk and OpenDBXDriver is just one of the sub-projects. > > There are several changes between this version and the last one of SqueakDBX, but most of them is about infrastructure: test were moved to a separate package, platform packages and backend classes were renamed, all "SqueakDBX" was replaced with its new name. > > To install it: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOpenDBXDriver'; > load. > > (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: #project) perform: #version: with: #stable) load. > > > We have also created a new repository for all the code: http://www.squeaksource.com/DBXTalk > > The issue tracker is in: http://code.google.com/p/dbxtalk/issues/list > > Thanks to Natacha Perrin we have a new DBXTalk logo that you can see in: http://imageshack.us/photo/my-images/37/dbxtalk46.png > The license of the logo is Creative Commons. > > We have also started a Pharo By Example chapter. So far we are writing about DBXTalk, but soon we will do about Glorp. We attach a draft of it while it is integrated into the main git repository of the book. > Just in case here is the git repo fork: https://github.com/guillep/PharoByExample-english. > > Just to let you know, we have already ported the last VW release of Glorp to Pharo and we have it already working MySQL, PostgreSQL, Oracle and Sqlite3. We are closing some last problems and we will soon make the first release. We want to thanks Alan Night for all his help and his reviews :). > > 4 persons of the team are present at ESUG right now and we are going to give a talk on Friday. We will upload then the slides. > > Finally, we would like to thanks ESUG for the sponsorship through this ESUG SummerTalk. > > Thanks! > Guille, Mariano, Esteban, Santiago, Gise > <dbxtalk_logo.png><DBXTalk.tex>

Aug. 24, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

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

Aug. 24, 2011