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

[Pharo-project] Callback(?) debugging - bad number of arguments

by Schwab,Wilhelm K

Eliot, I am calling something that I *think* simply tells GSL where to find the callbacks and a relevant structure. But I am getting a primitive failure in VMCallbackContext32>>primReturnAs:fromContext:, which I assume means that the library is attempting to call into Pharo. In the debugger's context, ec is set to #'bad number of arguments'. I have looked at the signatures and the blocks, and the argument counts look correct at first glance, albeit toward the end of a long day. Am I being naive? Any better ideas? My next inclination is to set breakpoints in all of the callbacks to seee if any of them get hit. I can't see why they would, but it's possible - especially given other weirdness that I have observed in GSL. It work, but it's a little rough around the (design/elegance) edges at times. Bill

March 23, 2012

Re: [Pharo-project] ProtoObject initialize

by Hernan Wilkinson

I don't understand why it does not understand #doesNotUnderstand:... shouldn't ProtoObject understand #doesNotUnderstand:??? (it is not a joke, I'm serious) On Thu, Mar 22, 2012 at 6:44 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Answering myself, thanks to Esteban: > > It hangs because It does not understand #initialize, so It throws a DNU, > and it also does not understand #doesNotUnderstand: > > > On Thu, Mar 22, 2012 at 6:12 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> hanged my image :3. >> >> Is that something I was not supposed to do? >> >> Guille >> > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - 4311 - 8404** Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

March 22, 2012

[Pharo-project] Montcello question

by Schwab,Wilhelm K

Is there a way to save a global variable into an MC package? I will probably just gzip some data and make a class method with the reduced byte array as a literal, but it would be nice to simply somehow tag a global and have it magically part of the package. Bill

March 22, 2012

Re: [Pharo-project] Behavior modification VM crash

by Eliot Miranda

On Thu, Mar 22, 2012 at 3:32 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-03-22, at 17:26, Eliot Miranda wrote: > > > > > > > On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > > On 2012-03-22, at 15:06, Stefan Marr wrote: > > > > > > > > On 22 Mar 2012, at 14:45, Camillo Bruni wrote: > > > > > >> let's have some fun and do > > >> > > >> Object subclass: #Behavior > > >> uses: TPureBehavior > > >> instanceVariableNames: 'superclass methodDict format layout' > > >> classVariableNames: 'ObsoleteSubclasses' > > >> poolDictionaries: '' > > >> category: 'Kernel-Classes' > > >> > > >> proceed over the several warnings not to change Behavior and BOOM! :D > > > > > > Check classNameIndex and thisClassIndex in the VM implementation. > > > They are typically the hardcoded indices into the expected object > layout of Class objects. > > > > > > And you just changed the layout -> BOOM! magic ;) > > > > > > I don't know how much overhead it is to examine such kind of indices > dynamically, but we do deduce indices based on inst var names to be able to > support the different object layouts. > > > For my stuff, I do that at VM startup, which would not help you. > > > > They would be expensive to recompute all the time (they're used in debug > printing). But they're not expensive to compute. So they could be > recomputed easily. See below. > > > > > > > David did it dynamically for the Process class and checked the object > identity of the class I think, to know when to update the index table after > a layout change. > > > > right. I guess I will have to move it to some further position... > > although I have an old image with: > > > > Behavior subclass: #ClassDescription > > layout: PointerLayout > > uses: TClassAndTraitDescription > > slots: { > > #instanceVariables => Slot. > > #organization => Slot. > > #layout => Slot. > > } > > classSlots: {} > > globals: '' > > category: #'Kernel-Classes' > > > > > > which works under said Cog version :/. I guess I will just have to find > some older VM which will support the changes > > > > I think we should make the VM work for this. classNameIndex and > thisClassIndex should only be used for debug printing, at least thats my > intent, and it would be possible to flush them and recompute them as a > side-effect of e.g. a flushCache primitive. > > > > Camilo, would you create a reproducible case for me, an image that > applies this change at start-up? Thanks. > > > > Also, can we please get into the habit of cc'ing vm-dev for issues that > touch on the VM? I ask this so that subsequent searching for VM issues can > be confined to a search of vm-dev archives. Again AdvThanksance. > > Submitted a bug report here: > http://code.google.com/p/cog/issues/detail?id=76 > > the attached *.st files fail under Cog / StackVM. It would be indeed nice > if they would work. > Which maybe it will one day if you can put in the effort to describe how to reproduce the bug properly. There's no pointer to a suitable image. There are no instructions beyond "use these files". How about a link to an image, plus a small script that files in the files? Or even better how about constructing an image that does this at startup so that the VM maintainers only have to fire up the image instead of wasting time setting up files? > best > cami > > > > > > -- best, Eliot

March 22, 2012

Re: [Pharo-project] Behavior modification VM crash

by Camillo Bruni

On 2012-03-22, at 17:26, Eliot Miranda wrote: > > > On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-03-22, at 15:06, Stefan Marr wrote: > > > > > On 22 Mar 2012, at 14:45, Camillo Bruni wrote: > > > >> let's have some fun and do > >> > >> Object subclass: #Behavior > >> uses: TPureBehavior > >> instanceVariableNames: 'superclass methodDict format layout' > >> classVariableNames: 'ObsoleteSubclasses' > >> poolDictionaries: '' > >> category: 'Kernel-Classes' > >> > >> proceed over the several warnings not to change Behavior and BOOM! :D > > > > Check classNameIndex and thisClassIndex in the VM implementation. > > They are typically the hardcoded indices into the expected object layout of Class objects. > > > > And you just changed the layout -> BOOM! magic ;) > > > > I don't know how much overhead it is to examine such kind of indices dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts. > > For my stuff, I do that at VM startup, which would not help you. > > They would be expensive to recompute all the time (they're used in debug printing). But they're not expensive to compute. So they could be recomputed easily. See below. > > > > David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change. > > right. I guess I will have to move it to some further position... > although I have an old image with: > > Behavior subclass: #ClassDescription > layout: PointerLayout > uses: TClassAndTraitDescription > slots: { > #instanceVariables => Slot. > #organization => Slot. > #layout => Slot. > } > classSlots: {} > globals: '' > category: #'Kernel-Classes' > > > which works under said Cog version :/. I guess I will just have to find some older VM which will support the changes > > I think we should make the VM work for this. classNameIndex and thisClassIndex should only be used for debug printing, at least thats my intent, and it would be possible to flush them and recompute them as a side-effect of e.g. a flushCache primitive. > > Camilo, would you create a reproducible case for me, an image that applies this change at start-up? Thanks. > > Also, can we please get into the habit of cc'ing vm-dev for issues that touch on the VM? I ask this so that subsequent searching for VM issues can be confined to a search of vm-dev archives. Again AdvThanksance. Submitted a bug report here: http://code.google.com/p/cog/issues/detail?id=76 the attached *.st files fail under Cog / StackVM. It would be indeed nice if they would work. best cami

March 22, 2012

Re: [Pharo-project] ProtoObject initialize

by Guillermo Polito

Answering myself, thanks to Esteban: It hangs because It does not understand #initialize, so It throws a DNU, and it also does not understand #doesNotUnderstand: On Thu, Mar 22, 2012 at 6:12 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > hanged my image :3. > > Is that something I was not supposed to do? > > Guille >

March 22, 2012

[Pharo-project] ProtoObject initialize

by Guillermo Polito

hanged my image :3. Is that something I was not supposed to do? Guille

March 22, 2012

[Pharo-project] TAssertable isBehavior -> false

by Guillermo Polito

shouldn't TraitBehavior implement isBehavior ^true ? Or maybe put that method in TPureBehavior Guille

March 22, 2012

Re: [Pharo-project] Dumb question: Cog and CPU temp??

by Schwab,Wilhelm K

Stef, Thanks - hadn't thought of that, but it makes sense. 1.3 has been treating me well. Some of the ffi troubles I was having might have been related to the old/new confusion. I still have to pass my DOUBLEArray as void*, but maybe Sig can suggest how to make FFI aware of the "type." I keep waiting for reality to crash around me, but if you had told me that, in a day, I'd have a first cut at ridding my GSL wrapper of the obsolete structs and methods, I'd have bet against it. I am still finding some broken features, but most of those were hacks to start. Thanks for the insight, and for Pharo! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, March 22, 2012 3:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Dumb question: Cog and CPU temp?? On Mar 22, 2012, at 7:35 PM, Schwab,Wilhelm K wrote: > Hello all, > > I am clobbering my cherished laptop today. I have it scanning the entire image for references and senders, but have been surprised that the fan has not started. The fan could have died, but the machine does not seem to be unusually warm. In the past, tasks like these always caused it to warm up and turn on its fan. Could Cog be the differnce???? Not only also the optimizations made on changes and sources. > > Bill > > > >

March 22, 2012

Re: [Pharo-project] Something is messing with the method's timestamps

by Marcus Denker

On Mar 22, 2012, at 6:27 PM, StÃ©phane Ducasse wrote: > > On Mar 21, 2012, at 10:02 PM, Martin Sandiford wrote: > >> MCFileInTest>>testStWriter is failing in Jenkins due to empty >> timestamps on fileIn. >> >> Not sure if this is related. > > > normally this was fixed by pavel. > There is a fix (workaround) proposed but not yet integrated: http://code.google.com/p/pharo/issues/detail?id=5461 -- Marcus Denker -- http://marcusdenker.de

March 22, 2012