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

Re: [Pharo-project] Pharo and an old plotter

by StÃ©phane Ducasse

cool Stef On Mar 22, 2012, at 2:47 PM, Pavel Krivanek wrote: > <pharo-plotter2.JPG>

March 23, 2012

Re: [Pharo-project] Where should debug file name be?

by StÃ©phane Ducasse

On Mar 23, 2012, at 2:33 AM, Guillermo Polito wrote: > > On Wed, Mar 21, 2012 at 3:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > There is no fight.. > > - first we would like to see if class can be lookup dynamically (and cached) > > are you talking about environments/namespaces stuff?? kind of but not necessarily. > > - second Smalltalk tools log does not hard code yet another global. > We got problem when we want to change code in the compiler that relied on transcript > when we changed transcript. At the end we removed the message because it was useless > but this illustrates the point. > > But I see Transcript as logging machinery... same as Smalltalk tools log. Then there are two ways to access log machinery (in real we have more because of #log: and family in Object, so I count three). so first remove hardcoded transcript > > Guille > > > Stef > > > > Transcript global var vs Smalltalk tools log > > > > ... but It will surely not be as fun, he > > > > > > > > > > Guille > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > >

March 23, 2012

Re: [Pharo-project] Montcello question

by StÃ©phane Ducasse

On Mar 23, 2012, at 12:01 AM, Schwab,Wilhelm K wrote: > Is there a way to save a global variable into an MC package? not that I know > 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 23, 2012

Re: [Pharo-project] ProtoObject initialize

by HernÃ¡n Morales Durand

I think others could explain the technical reasons, which sincerely I don't care at all. Conceptually I guess the designer :) wanted to have a closure with some kind of dummy object to represent the "Je pense donc je suis" (ego cogito, ergo sum), similarly, ProtoObject knows that it doesn't understand, then it doesn't understand... but that's only a cartesian-platonic route to knowledge representation, if you want to expand the system at this level, you may start modeling interesting knowledge acquisition and cognitive processes, only to finally be accused of not making money for your boss :) Cheers, HernÃ¡n 2012/3/22 Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > 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 23, 2012

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

by Schwab,Wilhelm K

Eliot, I did some more looking at the code, added a method to control when thing halt. The callback methods get exercised two ways: as ordinary methods with FFI objects, and then as actual callbacks with Alien parameters. I abstracted wrapping the arguments as arrays and matrices. What I had overlooked elsewhere was that I fell into the old trap of doing something like solver set:callback thunk address (or whatever the right incantation is). The point is that something is probably getting gc'd before activity dies out. With suitable temp variables to hold things, I got further. It's now it is seg faulting in a GSL call via FFI. Below is what I think is relevant from the crash dump. #set:set:set:guess: appears to be hitting the callbacks (successfully according to the debugger), and conks out "on the way out" of the FFI call that triggers everything. I need to set intermediate breakpoints in that method to see if it really is blowing up where I suspect. Any other ideas? Thanks! Bill ------------------------------------------------------------- Segmentation fault Thu Mar 22 22:59:14 2012 Squeak VM version: 3.9-7 #1 Mon Feb 20 23:15:24 CET 2012 gcc 4.1.2 Built from: CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Feb 20 2012 With: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Feb 20 2012 Revision: https://git.gitorious.org/cogvm/blessed.git Commit: 0f55a39cb3f41907fca6d102845154da5dfa597f Date: Mon Feb 20 18:59:49 2012 -0300 By: Esteban Lorenzano <estebanlm(a)gmail.com> Build host: Linux pharo-build.lille.inria.fr 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 14:13:46 EST 2010 i686 i686 i386 GNU/Linux plugin path: /home/bills/Work2012/Pharo-1.3/ [default: /home/bills/Work2012/Pharo-1.3/] C stack backtrace: /home/bills/Work2012/Pharo-1.3/CogVM[0x80968b1] /home/bills/Work2012/Pharo-1.3/CogVM[0x8096a3c] [0xb774e410] /usr/lib/libgsl.so.0(gsl_multifit_fdfsolver_set+0xdd)[0x75a2a72d] /home/bills/Work2012/Pharo-1.3/libSqueakFFIPrims.so(primitiveCallout+0x4b2)[0x75c962a2] /home/bills/Work2012/Pharo-1.3/CogVM(interpret+0x3f68)[0x808dcc8] /home/bills/Work2012/Pharo-1.3/CogVM[0x808fc97] /home/bills/Work2012/Pharo-1.3/CogVM[0x8090664] /home/bills/Work2012/Pharo-1.3/CogVM(main+0x38a)[0x809774a] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb75aebd6] /home/bills/Work2012/Pharo-1.3/CogVM[0x805acc1] Smalltalk stack dump: 0xbfd96e20 I GSLNonLinearLeastSquaresWithDerivatives>set:set:set:guess: 2035750124: a(n) GSLNonLinearLeastSquaresWithDerivatives 0xbfd96e68 I GSLModelGaussianPlusConstant(GSLModel)>fit: 2035750096: a(n) GSLModelGaussianPlusConstant 0xbfd96e90 I GSLModelGaussianPlusConstant class>example 2026112964: a(n) GSLModelGaussianPlusConstant class 0xbfd96ea8 M GSLModel class>? 2026110492: a(n) GSLModel class ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, March 22, 2012 10:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Callback(?) debugging - bad number of arguments On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: 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? Uh, ignore my reply. It was confused and wrong. Alas can't attend to this right now (dinner calls and it's a school night). Apologies.... later... Understandably so. I believe the issue is the callback selector in place in recreateSpecialObjectsArray. It needs to be newArray at: 54 put: #invokeCallbackContext:. not the older newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:. And you need to have invokeCallbackContext: implemented in Alien class. HTH 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 -- best, Eliot -- best, Eliot

March 23, 2012

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

by Eliot Miranda

On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> 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? >> > Uh, ignore my reply. It was confused and wrong. Alas can't attend to this right now (dinner calls and it's a school night). Apologies.... later... > > Understandably so. I believe the issue is the callback selector in place > in recreateSpecialObjectsArray. It needs to be > > newArray at: 54 put: #invokeCallbackContext:. > > not the older > > newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:. > > And you need to have invokeCallbackContext: implemented in Alien class. > > HTH > > > >> 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 >> >> > > > -- > best, > Eliot > > -- best, Eliot

March 23, 2012

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

by Eliot Miranda

On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > 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? > Understandably so. I believe the issue is the callback selector in place in recreateSpecialObjectsArray. It needs to be newArray at: 54 put: #invokeCallbackContext:. not the older newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:. And you need to have invokeCallbackContext: implemented in Alien class. HTH > 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 > > -- best, Eliot

March 23, 2012

Re: [Pharo-project] Pharo and an old plotter

by GermÃ¡n Arduino

Wow, what a cool project! And I m not saying that only because you mentioned "Arduino" :D 2012/3/22, Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > I would like to mention one funny usage of Pharo. I have got an old > simple czech plotter from 1989 named XY4150. It is no secret that the > interactive environment of Smalltalk is ideal for controlling such > machines because it is very easy to send commands to it and experiment > with drawing capabilities. > > Even today such old hardware can find a real-life production > deployment. I currently use it to write owner names to plastic cards > with pre-printed bar codes by a special pen destined to sign credit > cards :-) > > It is controlled by Arduino however LPT can be used too. > > Btw. there was several interesting czech plotters. The most > interesting one was named Merkur Alfi. It was a construction set for > children with two stepper motors and one relay. > http://www.youtube.com/watch?v=yUmFYzyL9eo > > And they started to sell it recently again so if you are looking for > some cool hardware for your children, you can look here: > http://www.merkurtoys.cz/vyrobky/plotrovy-zapisovac-alfi-z-merkuru[1] > But it's about 139â¬ so it's quite expensive... > > Cheers, > -- Pavel > -- Enviado desde mi dispositivo mÃ³vil ============================================ GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================

March 23, 2012

Re: [Pharo-project] About NonInteractiveUIManager>>#onSnapshot: and related

by Guillermo Polito

On Wed, Mar 21, 2012 at 2:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 March 2012 15:25, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > So, If I have an image with no GUI, which UIManager should I install, > how > > and when? Because at image startup I can't use a MorphicUIManager if I > > don't have it loaded into the image :). > > > Commanline ui manager? or just stick with non-interative one. > Hehe, but Commandline ui manager does the same :P. It is meant to be replacing another uiManager :/. > > See the implementation of #default in UIManager class. > It implies that one of its subclasses should answer 'true' on > #isActiveManager. > > actually we could use that, by niling the default manager at snapshot time, > so then once image boots, it will detect a new manager.. or fail (hehe). > > > > > > On Wed, Mar 21, 2012 at 8:00 AM, Camillo Bruni <camillobruni(a)gmail.com> > > wrote: > >> > >> indeed the non-interactive one keeps the previous version alive in the > >> instvar... > >> > >> I just copied the existing implementation (without much motivation). > >> Bit for simplicity's sake we should simply instantiate every time the > >> proper ui manager, that would simplify these ugly methods quite a bit. > >> > >> cami > >> > >> > >> On 2012-03-21, at 04:12, Igor Stasenko wrote: > >> > >> > the logic there was to set a non-interactive ui manager > >> > for headless sessions only , and then restore back a previous one > >> > (whatever it is), once session is changed back to headfull. > >> > > >> > if its uiManager is nil, it should reset the default manager, > >> > if i remember correctly, then UImanager itself will take care > >> > instantiating default one. > >> > > >> > On 21 March 2012 04:35, Guillermo Polito <guillermopolito(a)gmail.com> > >> > wrote: > >> >> Hi, > >> >> > >> >> I was doing some hacking, and playing with NonInteractiveUIManager. > >> >> And it > >> >> puzzled me that I realized that it has an inst var uiManager that > seems > >> >> to > >> >> refer to an uiManager it's replacing. > >> >> But my UIManager is not replacing anyone, it's my default and unique > >> >> UIManager and this var points to nil :S! > >> >> > >> >> So the code below does not work... > >> >> > >> >> onSnapshot: resuming > >> >> "The resuming argument is true when image boots from disk, > >> >> and false, if user just did an image snapshot." > >> >> > >> >> resuming ifTrue: [ > >> >> Smalltalk isHeadless ifFalse: [ > >> >> "restore old, or nil, so it will be set in #default " > >> >> uiManager beDefault. > >> >> UIManager default onSnapshot: resuming. > >> >> ^ self ]. > >> >> Smalltalk isInteractive ifTrue: [ > >> >> "use a headless but interactive manager" > >> >> ^ self headlessManager onSnapshot: resuming ]]. > >> >> > >> >> > >> >> " this flag set to true only if we are saving a snapshot before > >> >> quitting > >> >> " > >> >> doNotQuitOnRestart ifTrue: [ > >> >> Smalltalk snapshot: false andQuit: true]. > >> >> > >> >> > >> >> I made it work in my image adding within the controversial lines: > >> >> > >> >> uiManager ifNotNil: [ > >> >> uiManager beDefault. > >> >> UIManager default onSnapshot: resuming. > >> >> ] > >> >> > >> >> But it really looks like a hack because that inst var is ment to do > >> >> something else... > >> >> Is it asking me for a refactor? Or am I using this stuff in the > wrong > >> >> way? > >> >> Camillo, Igor? :P > >> >> > >> >> Guille > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Igor Stasenko. > >> > > >> > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

March 23, 2012

Re: [Pharo-project] Where should debug file name be?

by Guillermo Polito

On Wed, Mar 21, 2012 at 3:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > There is no fight.. > > - first we would like to see if class can be lookup dynamically > (and cached) > are you talking about environments/namespaces stuff?? > - second Smalltalk tools log does not hard code yet another global. > We got problem when we want to change code in the compiler > that relied on transcript > when we changed transcript. At the end we removed the > message because it was useless > but this illustrates the point. > But I see Transcript as logging machinery... same as Smalltalk tools log. Then there are two ways to access log machinery (in real we have more because of #log: and family in Object, so I count three). Guille > > Stef > > > > Transcript global var vs Smalltalk tools log > > > > ... but It will surely not be as fun, he > > > > > > > > > > Guille > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > >

March 23, 2012