March 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] GSoC13: Google Summer of Code started, your ideas please!
by Janko MivÅ¡ek March 26, 2013

March 26, 2013

Dear Smalltalkers, Time for your cool project ideas on this year Smalltalk GSoC! For now just express any idea you have here on the mailing list. Later we will together develop it to be in complete format together with two mentors needed. Deadline is end of Mart, so we have three weeks of time. To see how fully developed ideas look like please look at 2012 ones at: http://gsoc2012.esug.org/ideas. Note also that students yourselves can propose a GSoC project. So if you like to be a student on this year GSoC and have a nice idea, don't be shy and propose it here! The community will listen you and guide to the really nicely proposed project. Last year 6 student proposed projects were accepted and finished successfully! For the community, start looking around for students. Think about how to approach the universities near by you, do you know who to contact there, etc. We are namely preparing an application to this year Smalltalk Google Summer of Code under ESUG umbrella, as last year. If accepted, Google will pay few stipendiums to students on our Smalltalk projects. More on our special Smalltalk GSoC 2013 website: http://gsoc2013.esug.org I'm specially inviting mentors of all past GSoCs to rejoin the mentors mailing list, where we discuss all details about this year GSoC: http://groups.google.com/group/smalltalk-gsoc-mentors While students interested on GSoC please join a special Smalltalk GSoC mailing list for you: http://groups.google.com/group/smalltalk-gsoc-students Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

11 23

Re: [Pharo-project] [Vm-dev] Re: Reproducible VM crash when loading FFI
by Guillermo Polito March 26, 2013

March 26, 2013

I removed the extra message send (just in case to get this version) | newSpecialObjectsArray oldSpecialObjectsArray | newSpecialObjectsArray := self newSpecialObjectsArray. oldSpecialObjectsArray := self specialObjectsArray. self vm voidCogVMState. oldSpecialObjectsArray becomeForward: newSpecialObjectsArray Which so far works fine :D !! I'll publish a slice for people to test. Thank you very much for the help!! On Tue, Mar 26, 2013 at 5:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > Hi Guille, > > On Tue, Mar 26, 2013 at 9:33 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> Ok, as a summary. I've tried >> >> 1) not recreating the compact classes array without voiding vm caches: >> works ok. >> >> 2) making another compact classes array, voiding the vm caches >> (primitive 214): random crashes :/. Sometimes it works, some times it does >> not... >> I've tried, just for the record, to void the cache before, after and >> (before and after) the become forward of the special objects array: >> > > You need to void the cache *after* creating the new array and *immediately > before* installing it. Voiding the cache before creating it gives the VM > too much time to run and recache. So try > > d) > | newSpecialObjectsArray | > newSpecialObjectsArray := self newSpecialObjectsArray. > self vm voidCogVMState. > self specialObjectsArray becomeForward: newSpecialObjectsArray > > a) >> | newSpecialObjectsArray | >> self vm voidCogVMState. >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> >> b) >> | newSpecialObjectsArray | >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> self vm voidCogVMState. >> >> c) >> | newSpecialObjectsArray | >> self vm voidCogVMState. >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> self vm voidCogVMState. >> >> All with different results when executing several times... :/ >> >> voidCogVMState is the following in Pharo: >> >> VirtualMachine class>>voidCogVMState >> "Void any internal caches the VM maintains other than the method lookup >> caches. >> These comprise >> - the stack zone, where method activations are stored, and >> - the machine code zone, where the machine code form of CompiledMethods >> is held." >> <primitive: 214> >> ^self primitiveFailed >> >> The comment says it does not clean method lookup caches... >> > > Right, and that's fine. We're only wanting to discard cached machine code > etc. > >> >> any ideas? >> > > As explained, try d). > > >> Guille >> >> On Tue, Mar 26, 2013 at 11:48 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Ok, first I'm sorry for the evil upload. That was the first at hand >>> :$. I'll get a more trustful way to do it the next one... >>> Second, thanks for taking the time to look at it :). >>> >>> Now, I've some questions: >>> >>> - this "bug" is particular to Cog, isn't it? I mean, only related to >>> inlining with JIT, so a Stack vm does not play with these rules, right? >>> - Why is voiding the cache hackish? I mean, replacing the special >>> objects array is a very low level operation, and a very special one which >>> is not commonly performed. Voiding the cache looks like normal to me in >>> such a case... >>> >>> Tx! >>> Guille >>> >>> On Mon, Mar 25, 2013 at 11:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com >>> > wrote: >>> >>>> >>>> >>>> >>>> On Mon, Mar 25, 2013 at 3:22 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>>> >>>>> >>>>> Thanks for the findings! >>>>> >>>> >>>> you're welcome :) >>>> >>>> >>>>> >>>>> I opened an issue http://bugs.pharo.org/issues/id/10134 with the >>>>> contents >>>>> of your solution. >>>>> >>>>> I think for completeness we should implement both solution, and of >>>>> course >>>>> use the one that does not #becomeForward: in the standard case. >>>>> >>>> >>>> To be clear, becomeForward: is the correct way to install the >>>> specialObjectsArray. The issue is what entries in the specialObjectsArray >>>> need to remain constant. The Character table, the compactClassesArray, all >>>> the classes and a few other entries (semaphores, etc) must remain the same. >>>> This could do with better documenting of the method :-/ >>>> >>>> >>>> >>>>> >>>>> On 2013-03-25, at 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> >>>>> wrote: >>>>> > Hi Guille, >>>>> > >>>>> > thanks for this. The problem is that Pharo's >>>>> > recreateSpecialObjectsArray uses newCompactClassesArray to recreate >>>>> the >>>>> > compact classes array and on Cog that is not supported. Cog caches >>>>> the >>>>> > compactClassesArray (specialObjectsArray at: 29) in every jitted >>>>> method >>>>> > prolog to reduce the time taken to derive the receiver's class in >>>>> message >>>>> > lookup. The Pharo 2.0 code for recreating the specialObjectsArray >>>>> can >>>>> > therefore create a dangling pointer where the only reference to the >>>>> old >>>>> > compactClassesArray is in machine code, and the machine code GC >>>>> doesn't >>>>> > cope with there being roots in machine code. Note that Cog also >>>>> caches the >>>>> > characterTable and class SmallInteger in machine code. >>>>> > >>>>> > There are two solutions to this. >>>>> > One would be to reuse the compactClassesArray (my recommendation). >>>>> So that >>>>> > recreateSpecialObjectsArray looks like >>>>> > >>>>> > ... >>>>> > "An array of the 255 Characters in ascii order. >>>>> > Cog inlines table into machine code at: prim so do not regenerate >>>>> it." >>>>> > newArray at: 25 put: Character characterTable. >>>>> > ... >>>>> > "A 32-element array with up to 32 classes that have compact >>>>> instances. >>>>> > Cog inlines table into machine code class lookup so do not >>>>> regenerate it." >>>>> > newArray at: 29 put: self compactClassesArray. >>>>> > ... >>>>> > >>>>> > where compactClassesArray, like Character characterTable, answers the >>>>> > existing object. >>>>> > >>>>> > The second solution (rather hackish) is to void all machine code on >>>>> > installing the new specialObjectsArray. e.g. >>>>> > recreateSpecialObjectsArray >>>>> > "Smalltalk recreateSpecialObjectsArray" >>>>> > "To external package developers: >>>>> > **** DO NOT OVERRIDE THIS METHOD. ***** >>>>> > If you are writing a plugin and need additional special object(s) >>>>> for your >>>>> > own use, >>>>> > use addGCRoot() function and use own, separate special objects >>>>> registry " >>>>> > "The Special Objects Array is an array of objects used by the Squeak >>>>> > virtual machine. >>>>> > Its contents are critical and accesses to it by the VM are >>>>> unchecked, so >>>>> > don't even >>>>> > think of playing here unless you know what you are doing." >>>>> > "Replace the interpreter's reference in one atomic operation. >>>>> > Void machine code to avoid crashing Cog." >>>>> > | newSpecialObjectsArray | >>>>> > newSpecialObjectsArray := self newSpecialObjectsArray. >>>>> > self specialObjectsArray becomeForward: newSpecialObjectsArray. >>>>> > Smalltalk vm voidCogVMState >>>>> > >>>>> > >>>>> > this is my fault for not ensuring recreateSpecialObjectsArray was >>>>> properly >>>>> > commented. I had commented the inlining of Character table, but not >>>>> the >>>>> > inlining of the CompactClasses array. Apologies. >>>>> > >>>>> > HTH, >>>>> > Eliot >>>>> > >>>>> > On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito < >>>>> > guillermopolito(a)gmail.com> wrote: >>>>> > >>>>> >> Hi! >>>>> >> >>>>> >> In my quest to crash the vm, i've found an ugly common case :(. >>>>> >> I am trying to port the opendbx driver to 2.0, but I'm getting vm >>>>> crashes >>>>> >> when my configuration loads FFI :(. I updated my configuration to >>>>> load >>>>> >> version 1.7 of FFI (which I assume is the latest). >>>>> >> >>>>> >> I tried to do it in Pharo 2.0 with latest pharovm, and with eliot's >>>>> Cog >>>>> >> 2701 from his website, failing in both cases. >>>>> >> The snippet of code that gets a sistematic crash is: >>>>> >> >>>>> >> Gofer it >>>>> >> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>>>> >> package: 'ConfigurationOfOpenDBXDriver'; >>>>> >> load. >>>>> >> ((Smalltalk at: #ConfigurationOfOpenDBXDriver) project >>>>> version:#stable) >>>>> >> load >>>>> >> >>>>> >> >>>>> >> This snippet crashes always with a segmentation fault (at least the >>>>> >> fifteen times i tried :), with several different output in the >>>>> console... >>>>> >> >>>>> >> Surprisingly, if I load FFI alone and not from the OpenDBXDriver >>>>> >> configuration, it loads well... :/ >>>>> >> >>>>> >> So I'm deferring the OpenDBX port a bit longer :( >>>>> >> >>>>> >> Thanks! >>>>> >> Guille >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > best, >>>>> > Eliot >>>>> >>>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>>> >>> >> >> > > > -- > best, > Eliot > >

1 0

Re: [Pharo-project] [Vm-dev] Re: Reproducible VM crash when loading FFI
by Guillermo Polito March 26, 2013

March 26, 2013

Ok, as a summary. I've tried 1) not recreating the compact classes array without voiding vm caches: works ok. 2) making another compact classes array, voiding the vm caches (primitive 214): random crashes :/. Sometimes it works, some times it does not... I've tried, just for the record, to void the cache before, after and (before and after) the become forward of the special objects array: a) | newSpecialObjectsArray | self vm voidCogVMState. newSpecialObjectsArray := self newSpecialObjectsArray. self specialObjectsArray becomeForward: newSpecialObjectsArray. b) | newSpecialObjectsArray | newSpecialObjectsArray := self newSpecialObjectsArray. self specialObjectsArray becomeForward: newSpecialObjectsArray. self vm voidCogVMState. c) | newSpecialObjectsArray | self vm voidCogVMState. newSpecialObjectsArray := self newSpecialObjectsArray. self specialObjectsArray becomeForward: newSpecialObjectsArray. self vm voidCogVMState. All with different results when executing several times... :/ voidCogVMState is the following in Pharo: VirtualMachine class>>voidCogVMState "Void any internal caches the VM maintains other than the method lookup caches. These comprise - the stack zone, where method activations are stored, and - the machine code zone, where the machine code form of CompiledMethods is held." <primitive: 214> ^self primitiveFailed The comment says it does not clean method lookup caches... any ideas? Guille On Tue, Mar 26, 2013 at 11:48 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Ok, first I'm sorry for the evil upload. That was the first at hand > :$. I'll get a more trustful way to do it the next one... > Second, thanks for taking the time to look at it :). > > Now, I've some questions: > > - this "bug" is particular to Cog, isn't it? I mean, only related to > inlining with JIT, so a Stack vm does not play with these rules, right? > - Why is voiding the cache hackish? I mean, replacing the special objects > array is a very low level operation, and a very special one which is not > commonly performed. Voiding the cache looks like normal to me in such a > case... > > Tx! > Guille > > On Mon, Mar 25, 2013 at 11:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> >> On Mon, Mar 25, 2013 at 3:22 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> >>> Thanks for the findings! >>> >> >> you're welcome :) >> >> >>> >>> I opened an issue http://bugs.pharo.org/issues/id/10134 with the >>> contents >>> of your solution. >>> >>> I think for completeness we should implement both solution, and of course >>> use the one that does not #becomeForward: in the standard case. >>> >> >> To be clear, becomeForward: is the correct way to install the >> specialObjectsArray. The issue is what entries in the specialObjectsArray >> need to remain constant. The Character table, the compactClassesArray, all >> the classes and a few other entries (semaphores, etc) must remain the same. >> This could do with better documenting of the method :-/ >> >> >> >>> >>> On 2013-03-25, at 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > Hi Guille, >>> > >>> > thanks for this. The problem is that Pharo's >>> > recreateSpecialObjectsArray uses newCompactClassesArray to recreate the >>> > compact classes array and on Cog that is not supported. Cog caches the >>> > compactClassesArray (specialObjectsArray at: 29) in every jitted method >>> > prolog to reduce the time taken to derive the receiver's class in >>> message >>> > lookup. The Pharo 2.0 code for recreating the specialObjectsArray can >>> > therefore create a dangling pointer where the only reference to the old >>> > compactClassesArray is in machine code, and the machine code GC doesn't >>> > cope with there being roots in machine code. Note that Cog also >>> caches the >>> > characterTable and class SmallInteger in machine code. >>> > >>> > There are two solutions to this. >>> > One would be to reuse the compactClassesArray (my recommendation). So >>> that >>> > recreateSpecialObjectsArray looks like >>> > >>> > ... >>> > "An array of the 255 Characters in ascii order. >>> > Cog inlines table into machine code at: prim so do not regenerate it." >>> > newArray at: 25 put: Character characterTable. >>> > ... >>> > "A 32-element array with up to 32 classes that have compact instances. >>> > Cog inlines table into machine code class lookup so do not regenerate >>> it." >>> > newArray at: 29 put: self compactClassesArray. >>> > ... >>> > >>> > where compactClassesArray, like Character characterTable, answers the >>> > existing object. >>> > >>> > The second solution (rather hackish) is to void all machine code on >>> > installing the new specialObjectsArray. e.g. >>> > recreateSpecialObjectsArray >>> > "Smalltalk recreateSpecialObjectsArray" >>> > "To external package developers: >>> > **** DO NOT OVERRIDE THIS METHOD. ***** >>> > If you are writing a plugin and need additional special object(s) for >>> your >>> > own use, >>> > use addGCRoot() function and use own, separate special objects >>> registry " >>> > "The Special Objects Array is an array of objects used by the Squeak >>> > virtual machine. >>> > Its contents are critical and accesses to it by the VM are unchecked, >>> so >>> > don't even >>> > think of playing here unless you know what you are doing." >>> > "Replace the interpreter's reference in one atomic operation. >>> > Void machine code to avoid crashing Cog." >>> > | newSpecialObjectsArray | >>> > newSpecialObjectsArray := self newSpecialObjectsArray. >>> > self specialObjectsArray becomeForward: newSpecialObjectsArray. >>> > Smalltalk vm voidCogVMState >>> > >>> > >>> > this is my fault for not ensuring recreateSpecialObjectsArray was >>> properly >>> > commented. I had commented the inlining of Character table, but not >>> the >>> > inlining of the CompactClasses array. Apologies. >>> > >>> > HTH, >>> > Eliot >>> > >>> > On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito < >>> > guillermopolito(a)gmail.com> wrote: >>> > >>> >> Hi! >>> >> >>> >> In my quest to crash the vm, i've found an ugly common case :(. >>> >> I am trying to port the opendbx driver to 2.0, but I'm getting vm >>> crashes >>> >> when my configuration loads FFI :(. I updated my configuration to load >>> >> version 1.7 of FFI (which I assume is the latest). >>> >> >>> >> I tried to do it in Pharo 2.0 with latest pharovm, and with eliot's >>> Cog >>> >> 2701 from his website, failing in both cases. >>> >> The snippet of code that gets a sistematic crash is: >>> >> >>> >> Gofer it >>> >> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>> >> package: 'ConfigurationOfOpenDBXDriver'; >>> >> load. >>> >> ((Smalltalk at: #ConfigurationOfOpenDBXDriver) project >>> version:#stable) >>> >> load >>> >> >>> >> >>> >> This snippet crashes always with a segmentation fault (at least the >>> >> fifteen times i tried :), with several different output in the >>> console... >>> >> >>> >> Surprisingly, if I load FFI alone and not from the OpenDBXDriver >>> >> configuration, it loads well... :/ >>> >> >>> >> So I'm deferring the OpenDBX port a bit longer :( >>> >> >>> >> Thanks! >>> >> Guille >>> >> >>> > >>> > >>> > >>> > -- >>> > best, >>> > Eliot >>> >>> >> >> >> -- >> best, >> Eliot >> >> >

1 0

[Pharo-project] Nautilus: A fix for bad subclass indentation
by Damien Cassou March 26, 2013

March 26, 2013

Hi, in Nautilus, sometimes, subclasses are not indented properly, i.e., Nautilus shows that a class is a subclass of another one, but this is not the case. I have a fix for this bad behavior. To be sure the fix works fine, could you please tell me where you found hierarchies that are not properly indented? Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

1 0

[Pharo-project] fog monkey bugz
by Norbert Hartl March 26, 2013

March 26, 2013

Yesterday I registered for an account on bugs.pharo.org. I enteres username (NorbertHartl) and email and assured I'm not monkey. I got to the fogbugz page but not logged in. I didn't receive an email to set a password or something like that. How is it supposed to work? Norbert

4 7

[Pharo-project] how can I move an issue from resolved to work needed?
by StÃ©phane Ducasse March 26, 2013

March 26, 2013

for example 10071

3 3

[Pharo-project] NB additions
by Torsten Bergmann March 26, 2013

March 26, 2013

Pharo 2.0 has "NativeBoost-Core-EstebanLorenzano.116" which is in http://ss3.gemstone.com/ss/Pharo20 since NB is now in Pharo 2.0 The same version is not in the old squeaksource/NativeBoost repo and also not in the new SmalltalkHub native boost project. When having additions to NB where should I place them?

3 3

[Pharo-project] [3.0] 9 issues need reviews
by Marcus Denker March 26, 2013

March 26, 2013

Hi, Even with the integrations of saturday, there was a lot done that need attention: https://pharo.fogbugz.com/f/filters/22/3-0-Integration 6 are ready to be integrated, 9 need a code review. (for getting an account at fogbugz, see http://bugs.pharo.org ) Marcus

3 8

[Pharo-project] Bug about the multiplyBy with CairoMatrix
by Tristan Bourgois March 26, 2013

March 26, 2013

Hi! I found a bug with the method multiplyBy in the class CairoMatrix. I think the bug come from the fact that you send to the primitive the self in the result field and also in the parameter field (I found the difference using the multiply method in VisualWorks and saw the difference on the graphics result of my work): self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self, AthensCairoMatrix * m , AthensCairoMatrix * self ) ) For example : a := AthensCairoMatrix new. c := AthensCairoMatrix new. c rotateByDegrees: 40. c translateBy: 50@50. a := a multiplyBy: c. a AthensCairoMatrix ( sx: 0.766044443118978 shx: 0.6427876096865393 shy: -0.6427876096865393 sy: 0.766044443118978 x: 6.1628416716219405 y: 70.44160264027587 ) If you just swap the 2nd field with the 3rd field the result change: self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self, AthensCairoMatrix * self , AthensCairoMatrix * m) ) a AthensCairoMatrix ( sx: 0.766044443118978 shx: 0.6427876096865393 shy: -0.6427876096865393 sy: 0.766044443118978 x: 50.0 y: 50.0 ) (the graphic result are good with the 2nd option and I have the same result with VisualWork) I think the problem come from this part of the doc of Cairo: "void cairo_matrix_multiply (cairo_matrix_t *result, const cairo_matrix_t *A, const cairo_matrix_t *B); Multiplies the affine transformations in a and b together and stores the result in result. The effect of the resulting transformation is to first apply the transformation in a to the coordinates and then apply the transformation in b to the coordinates." Because of Cairo change the result first with the new matrix A and store it in the result you change too the 2nd matrix after his application. I think to avoid some edge effect it will be more clean to send a new matrix for the result matrix and not "self". What do you think? Tristan.

1 0

[Pharo-project] [update 3.0] #30013
by Marcus Denker March 26, 2013

March 26, 2013

5 9