- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 4.0 MethodContext Fuel

by Johannes Rasche Kreuzberg

Am 16.06.15 um 13:16 schrieb Mariano Martinez Peck: > FLMaterializer newDefault > migrateClassNamed: #MethodContext > toClass: Context. Great Mariano, many Thanks

June 16, 2015

Re: [Pharo-users] World lastKeystroke and openInWorld: aPasteUpMorph

by Hilaire

Le 10/06/2015 23:50, Markus Schlager a Ã©crit : > > I'm using pharo to teach smalltalk as first 'real' programming > language at school. With older versions of pharo I was glad that my > pupils could track keystrokes so easily by evaluating Off topic, but I am curious as a teacher: how old the pupils you are teaching to? Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 16, 2015

Re: [Pharo-users] Pharo 4.0 MethodContext Fuel

by Mariano Martinez Peck

Hi Johannes, MethodContext are a bit complicated as you know. However, remembering a bit the code, i THINK the class migration hook may work with it. Have you read: http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration Try the materialization with something like: FLMaterializer newDefault migrateClassNamed: #MethodContext toClass: Context. Cheers, On Tue, Jun 16, 2015 at 5:02 AM, Johannes Rasche Kreuzberg < Johannes(a)rasche-kreuzberg.de> wrote: > > > > > > > > > > > > > > > > *Hi there, I'm still migration some stuff to Pharo 4.0 and am aware of the > fact that MethodContext was deprecated and Context has to be used instead > I'm migrating objects from Pharo 3 using Fuel - that works fine - except if > an object is an instantion of a class containing blockclosures any advice ? > thanks in advance Johannes * > -- Mariano http://marianopeck.wordpress.com

June 16, 2015

Re: [Pharo-users] breaking infinite loop from saved image

by Stephan Eggermont

On 16-06-15 10:44, Peter UhnÃ¡k wrote: > I guess making tools for image surgery ain't easy, but it certainly is > interesting. :) I suppose in the long term this will get easier when we can have tools in one image operating on another image. Stephan

June 16, 2015

Re: [Pharo-users] breaking infinite loop from saved image

by Peter UhnÃ¡k

On Tue, Jun 16, 2015 at 10:09 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi! > > El mar., 16 de jun. de 2015 a la(s) 8:55 a. m., Peter UhnÃ¡k < > i.uhnak(a)gmail.com> escribiÃ³: > >> I ended up fileouting what I could in headless mode (had utf8 issues for >> whatever reason so I didn't get it all), and rewriting the rest. :/ >> But what happens once will happen again... so some more generic solution >> for this would be nice. >> >> Given command line was usable you could have used it to break the loop. > > Let's say you had your method that recurses looks like > > BadGuy>>recursive > self recursive > > then you can do > > ./pharo eval "BadGuy compile: 'recursive'" > As I have said originally, I did recompile the method to get rid of it (albeit from StartupScript and not eval), but there was already to much stuff on stack (every call fired a new announcement and the observer called the method again), so the system resources were already clogged, and even after I recompiled it it crashed shortly thereafter. Another useful debugging tool, maybe you knew about it, is sending the > SIGUSR1 signal to the VM process. It will print out the stack and help you > detect possible problems. > Well on crash I did receive the stack so I knew what was the problem, but it might be helpful in the future. Well, Oz has never left the prototype stage, and I doubt it will soon with > the time I have and the hackish VM requirements. I guess making tools for image surgery ain't easy, but it certainly is interesting. :) Peter

June 16, 2015

Re: [Pharo-users] breaking infinite loop from saved image

by Guillermo Polito

Hi! El mar., 16 de jun. de 2015 a la(s) 8:55 a. m., Peter UhnÃ¡k < i.uhnak(a)gmail.com> escribiÃ³: > I ended up fileouting what I could in headless mode (had utf8 issues for > whatever reason so I didn't get it all), and rewriting the rest. :/ > But what happens once will happen again... so some more generic solution > for this would be nice. > > Given command line was usable you could have used it to break the loop. Let's say you had your method that recurses looks like BadGuy>>recursive self recursive then you can do ./pharo eval "BadGuy compile: 'recursive'" that will break your method but will help you recover the rest :) Another useful debugging tool, maybe you knew about it, is sending the SIGUSR1 signal to the VM process. It will print out the stack and help you detect possible problems. Yuriy mentioned Oz, and it looks viable, provided it works with current > pharo version and is capable of dealing with (most likely) corrupted memory. > Well, Oz has never left the prototype stage, and I doubt it will soon with the time I have and the hackish VM requirements. Guille

June 16, 2015

Pharo 4.0 MethodContext Fuel

by Johannes Rasche Kreuzberg

/Hi there, I'm still migration some stuff to Pharo 4.0 and am aware of the fact that MethodContext was deprecated and Context has to be used instead I'm migrating objects from Pharo 3 using Fuel - that works fine - except if an object is an instantion of a class containing blockclosures any advice ? thanks in advance Johannes /

June 16, 2015

right-aligned Spec labels ?

by Hartmut

how 2 right-align a label text in Spec ? I assigned a Text instance to a label with textAlignment rightFlush: self /labelKey/ label: (/key/ asText addAttribute: TextAlignment rightFlush). However, LabelModel ignores the TextAlignment. Can it be done? and how? Thanks -- Hartmut Krasemannâ¨ KÃ¶nigsberger Str. 41 c â¨D 22869 Schenefeldâ¨ Tel. 040.8307097â¨ Mobil 0171.6451283â¨ krasemann(a)acm.org

June 16, 2015

Re: [Pharo-users] NativeBoost nested structures

by Matthieu Lacaton

> > Are you bound to exactly this structure? > If you can define the structure, you can use a nested structure that uses > pointers instead of values: > > NBTestNestedStructure2>> > fieldsDesc > > ^ #( > NBTestStructure1byte* oneByte; > int otherField > ) > > Now you can create and access the innerstructure like this > > myStruct := (NBTestNestedStructure2 new oneByte: (NBTestStructure1byte > externalNew field: 1)). > myStruct oneByte field. " -> 1 " > myStruct oneByte field: 4. > myStruct oneByte field. " -> 4 " > Well I'm not bound to anything really, but what you did here seems nice and should do the trick for me. Initially i just got rid of the second struct and incorporated each element of the second struct inside the first one. I guess if the size they take in memory is the same it should work too. But I'll use your solution cause it looks nicer :) Whereas I don't know if the external memory is freed. > >From what is written in NBExternalStructure it probably isn't but I'll just have to remember to do so. On the other hand, I am curious about the internal mechanisms here. yes, self struct2 will create a copy of the struct2 and any change to > struct2 value only applies to this copy. > If "self struct2" returns a copy it means that even if it is not a struct and simply an int it also returns me a copy right ? However, when you call "self struct2: ..." or "self otherField: ..." it actually modifies the object itself. So why doesn't it let me access the actual object directly ? If I can modify the whole object why can't I modify just a part of it ? What is the inherent issue ?

June 16, 2015

Re: [Pharo-users] breaking infinite loop from saved image

by Peter UhnÃ¡k

I ended up fileouting what I could in headless mode (had utf8 issues for whatever reason so I didn't get it all), and rewriting the rest. :/ But what happens once will happen again... so some more generic solution for this would be nice. Yuriy mentioned Oz, and it looks viable, provided it works with current pharo version and is capable of dealing with (most likely) corrupted memory. However as I personally prefer time traveling over archaeology, I would like having multiple snapshot of the image (10 minutes ago, 20 minutes ago) so if my image gets corrupted I loose at most 10 minutes of time. I can always dig it out, but there is always some work involved (downloading new image, setting it up, downloading work packages, digging out the old changeset, ...). On Tue, Jun 16, 2015 at 8:45 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > Did you try to open (a copy of) the changes file with a new/fresh image? > Or you can use : > > ExternalChangesBrowser openOn:'FULLNAME_OF_OTHER_CHANGES_FILE' > to open a changes browser. > Good to know this is available now (I am still in Pharo 4 tho), but this is still archaeology for me. :) Anyway, I've resolved my current problem, so the question now is how to add some extra fault tolerance. Peter

June 16, 2015