- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Polymorph

by Stan Shepherd

Nice looking app, Gary. Are those themes available yet? Do they help with things like making corner handles easier to use? Thanks, Stan -- View this message in context: http://forum.world.st/Polymorph-tp4440306p4496321.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 23, 2012

Re: [Pharo-project] Polymorph

by StÃ©phane Ducasse

Thursday 23 Friday 24 http://pharoconference-esearch.eventbrite.com/?srnk=1 http://rmod.lille.inria.fr/web/pier/Events would be cool to see you Stef > What's the date this year? > Would love to attend. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, March 21, 2012 9:57 PM > Subject: Re: [Pharo-project] R: Polymorph > > >> Btw , Gary, is there any chance to see you at Pharoconf? >> -- >> Best regards, >> Igor Stasenko. >> >

March 23, 2012

Re: [Pharo-project] Behavior modification VM crash

by StÃ©phane Ducasse

On Mar 22, 2012, at 2:45 PM, 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 > why would I do this? => we want first class layouts (most probably in 1.5) whoooo so exciting. Stef > > =============================================================================== > StackInterpreter VMMaker-oscog-EstebanLorenzano.139 > uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 > =============================================================================== > Recompiling Metaclass (2041/2046) 100% > =============================================================================== > Notice: Errors in script loaded from script.st > =============================================================================== > ==== Startup Error: MessageNotUnderstood: Dictionary>>asLowercase > Dictionary(Object)>>doesNotUnderstand: #asLowercase > ChangeSet>>noteClassStructure: > ChangeSet>>changeClass:from: > ChangeSet>>event: > WeakMessageSend>>valueWithArguments: > WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: > in Block: [answer := each valueWithArguments: anArray] > BlockClosure>>on:do: > WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: > WeakActionSequenceTrappingErrors>>valueWithArguments: > SystemEventManager(Object)>>triggerEvent:withArguments: > ... > > =============================================================================== > CoInterpreter VMMaker-oscog-EstebanLorenzano.139 > uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 > =============================================================================== > Recompiling Class class (924/2046) 45% > =============================================================================== > Notice: Errors in script loaded from script.st > =============================================================================== > ==== Startup Error: MessageNotUnderstood: ByteSymbol>>copyTraitExpression > ByteSymbol(Object)>>doesNotUnderstand: #copyTraitExpression > ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... > Array(SequenceableCollection)>>do: > ClassBuilder>>mutate:to: > ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... > Array(SequenceableCollection)>>do: > ClassBuilder>>mutate:to: > ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... > Array(SequenceableCollecti > ... > > =============================================================================== > > now and then the CogVM crashes due to a SEGFAULT. Under one of the old Squeak > VMs it compiles but depending on the VM version, has issues maintaining a sane > state. > > So this is most certainly a VM issue and not a bug in the image side code. > As far as I remember the CogVM opens a modified image without issues... > > > best > cami > > > >

March 23, 2012

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

by StÃ©phane Ducasse

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. Stef > > On Thu, Mar 22, 2012 at 6:17 AM, Ricardo Moran <richi.moran(a)gmail.com> wrote: >> >> On Wed, Mar 21, 2012 at 4:01 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> Thanks for bug description because I noticed also the problem. >>> This is probably related to my change to have only timeStamp and not >>> dateAndTime mixed and a problem I got but I do not remember exactly (working >>> too much) >>> >>> Can you open a bug entry? >> >> >> Done! http://code.google.com/p/pharo/issues/detail?id=5532 >> >> Richo >> >>> >>> Stef >>> >>> >>>> Hi, I just noticed when I load a project with a metacello configuration, >>>> all the method's timestamps are lost. I tried with this configuration: >>>> >>>> Gofer it >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfCTranslator'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfCTranslator) load. >>>> >>>> If then I load the project by hand (i.e. going through the Monticello >>>> browser), the timestamps are back. >>>> >>>> Also, when I add a new method to a class it gets added without a >>>> timestamp, just after I modify it the timestamp is added correctly. >>>> >>>> System Reporter info below: >>>> >>>> Image >>>> ----- >>>> C:\Documents and Settings\navegador\Mis documentos\Squeak >>>> images\Pharo\Pharo-1.4 (1)\Pharo-1.4\Pharo-1.4.image >>>> Pharo1.4a >>>> Latest update: #14406 >>>> Unnamed >>>> >>>> Virtual Machine >>>> --------------- >>>> C:\Documents and Settings\navegador\Mis documentos\Squeak >>>> images\Pharo\Pharo-1.4 (1)\Pharo-1.4\CogVM.exe >>>> CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: >>>> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Mar 12 2012, >>>> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: >>>> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Mar 12 2012, >>>> https://git.gitorious.org/cogvm/blessed.git Commit: >>>> ca2091e70cfef485fa511935f51d8c91b1c3f185 Date: Mon Mar 12 19:07:33 2012 >>>> +0100 By: Igor Stasenko <siguctua(a)gmail.com> >>>> Win32 built on Mar 12 2012 19:32:09 Compiler: 4.5.2 >>>> CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: >>>> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Mar 12 2012 >>>> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: >>>> 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Mar 12 2012 >>>> >>>> Operating System/Hardware >>>> ------------------------- >>>> Win32 5.1 IX86 >>>> >>>> Cheers, >>>> Richo >>> >>> >> >

March 23, 2012

Re: [Pharo-project] Behavior modification VM crash

by Eliot Miranda

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. -- best, Eliot

March 23, 2012

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

by Schwab,Wilhelm K

The vm really needs to tell us what is trying to do when translating names to numbers, and probably needs to ask the image for help (not sure how to do that, but these defects are all too comon). I would have thought that either a symlink or using numbers (BTW, how does THAT work? <g>) would be enough. Interesting about the parallel port. I have a book at home (IIRC, its The Robot Builder's Bonanza) that described using a particular type of buffer-driver chip to receive commands from a parallel port. I soon realized that quad or whatever prefix was irrelevant, and what was really going on was that the buffer-driver chip was able decode the parallel port lines (correct logic type) and the buffer business allowed it to give a little kick to things like relays. Bottom line: I had the parallel port switching relays that controlled electronic valves. It worked great. In the current world, I would probably drag out an AccesIO A/D board and use its digital outputs to do the work, but the chip did the job. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.krivanek(a)gmail.com] Sent: Thursday, March 22, 2012 10:52 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo and an old plotter The plotter needs only 6 pins (gnd, pen, axe, direction, step, ready) so it can be controlled directly via LPT. I firstly successfully tried a windows machine with a parallel port. For USB connection I used Arduino with serial communication where Arduino accepts simple basic commands and when it's done it sends a message to get the next ones. It's on Linux with latest CogVM but I had to create symlink from /dev/ttyUSB0 to /dev/ttySx and open the port by number (x), not by the name. See http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg60816.ht… -- Pavel On Thu, Mar 22, 2012 at 2:56 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Nice! What is the physical/electrical connection? Serial, parallel, etc.? If serial, did you have any problems with opening ports? On which VM? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.krivanek(a)gmail.com] > Sent: Thursday, March 22, 2012 9:47 AM > To: Pharo Development > Subject: [Pharo-project] Pharo and an old plotter > > 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 >

March 23, 2012

Re: [Pharo-project] R: Polymorph

by Hilaire Fernandes

Le 21/03/2012 22:37, Gary Chambers a Ã©crit : > The promised vid... nearly does it justice in use... > > http://www.youtube.com/watch?v=OTIJZZeGsC8&feature=youtu.be Hey, Charlotte sometime... The flow in the application looks fantastic.

March 23, 2012

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

by Pavel Krivanek

The plotter needs only 6 pins (gnd, pen, axe, direction, step, ready) so it can be controlled directly via LPT. I firstly successfully tried a windows machine with a parallel port. For USB connection I used Arduino with serial communication where Arduino accepts simple basic commands and when it's done it sends a message to get the next ones. It's on Linux with latest CogVM but I had to create symlink from /dev/ttyUSB0 to /dev/ttySx and open the port by number (x), not by the name. See http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg60816.ht… -- Pavel On Thu, Mar 22, 2012 at 2:56 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Nice! Â What is the physical/electrical connection? Â Serial, parallel, etc.? Â If serial, did you have any problems with opening ports? Â On which VM? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.krivanek(a)gmail.com] > Sent: Thursday, March 22, 2012 9:47 AM > To: Pharo Development > Subject: [Pharo-project] Pharo and an old plotter > > 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 >

March 23, 2012

Re: [Pharo-project] Behavior modification VM crash

by Camillo Bruni

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

March 23, 2012

Re: [Pharo-project] Behavior modification VM crash

by Stefan Marr

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. 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. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 23, 2012