- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Slot Questions

by webwarrior

Sean P. DeNigris wrote > Sean P. DeNigris wrote >> Object subclass: #MyClass >> slots: { #var1 => MySlot adjustment: 10 } >> classVariables: { } >> category: '' >> â¦ >> but when I open a new browser on the class definition of MyClass, the >> slots >> are truncated to: >> slots: { #var1 => MySlot } > > It turns out that the slot is still "working" e.g. #adjustment is still > having its effect e.g. > read: anObject > ^ (super read: anObject) ifNotNil: [ :val | val + self adjustment ] > It's just that the class template has lost information. > > Another issue: > Changing the slots in the template from "{ #var1 => MySlot adjustment: 10 > }" > to "{ #var1 => MySlot adjustment: 100 }" has no effect unless I accept an > intermediate "{ #var1 }" > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html That's because you need to redefine #= and #definitionString (alternatively: redefine #printOn:) in your slot class. Also regarding tool support: there's bug tracker entry https://pharo.fogbugz.com/f/cases/19541/References-to-class-should-also-be-… <https://pharo.fogbugz.com/f/cases/19541/References-to-class-should-also-be-…> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 25, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 24. Mar 2018, at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Dear Eliot, >> d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. > > I wonder if there is sense in trying to come up with a general memory handle object that includes a session identifier, so that attempts to free stake memory always fail. I think it would help with the FT2Handle (to invalidate it on a new session) but it will not solve other image resume/FFI issues. Let's assume we have multiple calls into a C library (get a handle, call 1st method, call 2nd method, have a loop with backwards jumps). Something like: | memory | memory := GetSomeMemorySomewhere. 1 to: 5 do: [ self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. ... more C stuff ]. We could be interrupted at any point and when the execution is resumed the handles might be invalid. In Python terminology something like a context manager could help: # Image saving is delayed/inhibited until after the callout chain CCallOut with: [ 1 to: 5 do: [ self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. ... more C stuff ]. ] What do you think? holger

March 25, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 24. Mar 2018, at 17:03, Holger Freyther <holger(a)freyther.de> wrote: > > > > FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. The snippet below is my work-around. I think the proper fix is to get FT2Handle to invalidate handles a lot earlier (Gui->System startup?). Author useAuthor: 'Hacks' during: [ FreeTypeExternalMemory addInstVarNamed: 'session'. FreeTypeExternalMemory compile: 'validate (session == Smalltalk session and: [ self isValid ]) ifTrue: [ ^self ]. bytes ifNil: [ ^ self ]. session := Smalltalk session. self primCopyToExternalMemory: bytes. self isValid ifTrue: [ self class register: self ]' ]. Smalltalk snapshot: true andQuit: true.

March 25, 2018

Re: [Pharo-dev] Slot Questions

by Sean P. DeNigris

Sean P. DeNigris wrote > Object subclass: #MyClass > slots: { #var1 => MySlot adjustment: 10 } > classVariables: { } > category: '' > â¦ > but when I open a new browser on the class definition of MyClass, the > slots > are truncated to: > slots: { #var1 => MySlot } It turns out that the slot is still "working" e.g. #adjustment is still having its effect e.g. read: anObject ^ (super read: anObject) ifNotNil: [ :val | val + self adjustment ] It's just that the class template has lost information. Another issue: Changing the slots in the template from "{ #var1 => MySlot adjustment: 10 }" to "{ #var1 => MySlot adjustment: 100 }" has no effect unless I accept an intermediate "{ #var1 }" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

Re: [Pharo-dev] pharo64+load code=broken image

by Javier PimÃ¡s

On Fri, Mar 23, 2018 at 11:17 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Mar 23, 2018 at 7:54 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> > wrote: > >> Hi Eliot, the crash.dmp shows what I put in the first mail, gdb shows >> some more info: >> >> #0 __GI___libc_free (mem=0x7f15fc1d15d0) at malloc.c:2965 >> #1 0x00000000004c745b in primitiveFFIFree () at >> /home/travis/build/OpenSmalltalk/opensmalltalk-vm/src/ >> plugins/SqueakFFIPrims/X64SysVFFIPlugin.c:6352 >> #2 0x0000000000457f64 in primitiveExternalCall () at >> /home/travis/build/OpenSmalltalk/opensmalltalk-vm/spur64src/ >> vm/gcc3x-cointerp.c:75751 >> #3 0x00000000004595cb in interpretMethodFromMachineCode () at >> /home/travis/build/OpenSmalltalk/opensmalltalk-vm/spur64src/ >> vm/gcc3x-cointerp.c:18524 >> #4 0x000000000045bc69 in ceSendsupertonumArgs (selector=<optimized out>, >> superNormalBar=0, rcvr=<optimized out>, numArgs=0) >> at /home/travis/build/OpenSmalltalk/opensmalltalk-vm/spur64src/ >> vm/gcc3x-cointerp.c:16602 >> #5 0x00000000009000bb in ?? () >> #6 0x00007fffffffdbc0 in ?? () >> #7 0x000000000045ce56 in interpret () at /home/travis/build/OpenSmallta >> lk/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:2731 >> #8 0x00000000009ccf7f in ?? () >> #9 0x00000000045e39c8 in ?? () >> #10 0x00000000045e39c8 in ?? () >> ... >> >> As it is just loading, I think that it is trying to free some memory that >> was allocated before the image was saved. Looks like there is an external >> address that should have been niled but for some reason wasn't. >> > > I can take a look at the image in the simulator and/or debugger and see if > any stale pointers exist. Put the image and changes somewhere where I can > download them. > > Thanks! I'll try to do something better instead: do it by myself asking questions if needed, it might take some time before I start though. Cheers, Pocho >> On Fri, Mar 23, 2018 at 11:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> Hi Javier, >>> >>> what does the crash.dmp file say? Or what does a gdb stacktrace say? >>> >>> _,,,^..^,,,_ (phone) >>> >>> On Mar 23, 2018, at 7:18 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>> wrote: >>> >>> no luck with this one :( >>> >>> On Fri, Mar 23, 2018 at 4:48 AM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>> >>>> Hi Javier, >>>> >>>> On 23 March 2018 at 04:54, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>> wrote: >>>> > Hi folks, I take a fresh Pharo6.1 (spur64), load a git repository and >>>> save >>>> > the image. When reopening I get a segmentation fault. OS is ubuntu >>>> 17.04/64 >>>> > bits. I just cannot make it work, tried with all the vms I could >>>> (vmI61, >>>> > vmT61, vmLatest70, vmTLatest70). I suspect it is related to using git >>>> but >>>> > I'm not even sure. >>>> > >>>> > Below I put the involved code, crash dump at the end (seems to be the >>>> same >>>> > with any vm). btw, the vmILatest70 script does not seem to work (curl >>>> > https://get.pharo.org/64/vmILatest70 | bash). >>>> > >>>> > Any ideas? >>>> >>>> I'm using the following VM on Ubuntu 16.04 without any issues: >>>> >>>> http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86 >>>> _64threaded-201803160215-43a2f5c.zip >>>> >>>> >>>> HTH, >>>> Alistair >>>> >>>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >>> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 24, 2018

Re: [Pharo-dev] Slot Questions

by Sean P. DeNigris

Question #3: Shouldn't the following (from the paper): slots: { #staff => ManySlot opposite: #boss class: Clerk. } Be: slots: { #staff => (ManySlot opposite: #boss class: Clerk). } Also, what is that code actually doing? Is #opposite:class: a class-side method of ManySlot? If so, what does it return? Ah, I see now - #=>> does some magic to accept either a Slot class or instance. Question #4: Given: Object subclass: #MyClass slots: { #var1 => MySlot } classVariables: { } category: '' and MyClass >>#var1: anObject var1 := anObject MySlot>#write:to: doesn't seem to be sent when I `myClassInstance var1: 2`. I tried to insert a halt, 1 inspect, etc. I am able to intercept #read: on the other hand Question #5: I tried: Object subclass: #MyClass slots: { #var1 => MySlot adjustment: 10 } "with and without () around `MySlot adjustment: 10`" classVariables: { } category: '' where: InstanceVariableSlot subclass: #MySlot slots: { #adjustment } and: adjustment ^ adjustment ifNil: [ 0 ] but when I open a new browser on the class definition of MyClass, the slots are truncated to: slots: { #var1 => MySlot } ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

Slot Questions

by Sean P. DeNigris

Stateful traits inspired me to reread the flexible object layout paper and I came up with a few questions about slots: - What is the plan for tool support? For example, it seems that to make slots discoverable like any other class or message, "References to it" should include class definitions, which should be the primary slot client. - Why does IndexedSlot have a #name slot? I thought the index and name were "either or" for instVars. Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Eliot Miranda

Hi Holger, > On Mar 24, 2018, at 10:03 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > >> On 24. Mar 2018, at 16:42, Holger Freyther <holger(a)freyther.de> wrote: >> >> >> >> 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! >> > > > >> I think implementing: >> >> FreeTypeExternalMemory class >> #bytes: aByteArray >> ^(aByteArray copy) >> pin; >> yourself >> >> could solve most of it? (We can argue about the copy...) > > It doesn't because most of FT2Plugin expects the "handle" it invented. But if we look at it... > > FreeTypeFace>validate > SmalltalkImage>session > SessionManager class>default > SessionManager>currentSession > SmalltalkImage>session > FreeTypeFace>create > FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: > FreeTypeExternalMemory>validate > FreeTypeExternalMemory(FT2Handle)>isValid > > FreeTypeFace>>#validate already does: > > (session == Smalltalk session > ... > > > And this is why FreeTypeFace>>#create is being called and that will call validate on the FreeTypeExternalMemory instance... > > > FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. > > > So back to the ideas. > > a.) Make sure FT2Handler class>>#startUp runs a lot earlier > b.) Find out which UI thing uses freetype earlier (but FreeType can be used in non GUI apps. E.g. to draw text to an image...) > c.) Keep the session in FreeTypeExternalMemory as well and use it in >>#validate.. (not relying on the startUp order) > d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. I wonder if there is sense in trying to come up with a general memory handle object that includes a session identifier, so that attempts to free stake memory always fail. > holger

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 24. Mar 2018, at 16:42, Holger Freyther <holger(a)freyther.de> wrote: > > > > 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! > > I think implementing: > > FreeTypeExternalMemory class >> #bytes: aByteArray > ^(aByteArray copy) > pin; > yourself > > could solve most of it? (We can argue about the copy...) It doesn't because most of FT2Plugin expects the "handle" it invented. But if we look at it... FreeTypeFace>validate SmalltalkImage>session SessionManager class>default SessionManager>currentSession SmalltalkImage>session FreeTypeFace>create FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: FreeTypeExternalMemory>validate FreeTypeExternalMemory(FT2Handle)>isValid FreeTypeFace>>#validate already does: (session == Smalltalk session ... And this is why FreeTypeFace>>#create is being called and that will call validate on the FreeTypeExternalMemory instance... FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. So back to the ideas. a.) Make sure FT2Handler class>>#startUp runs a lot earlier b.) Find out which UI thing uses freetype earlier (but FreeType can be used in non GUI apps. E.g. to draw text to an image...) c.) Keep the session in FreeTypeExternalMemory as well and use it in >>#validate.. (not relying on the startUp order) d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. holger

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 21. Oct 2017, at 20:30, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hey! > Thanks thomas we should find the problem. > my CI started to suffer from this too (and I have one where it is broken and now one where I can reproduce it). I started the macOS VM with --trace[1] and have the attached the trace. What is note-worthy: 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! (GlobalIdentifier, Delay, DelaySpinScheduler, ProcessorScheduler seem to have went through >>#startUp:) 2.) No one calls >>#fileContentsExternalMemory: 3.) We touch old memory and crash! FreeTypeGlyphRenderer class>current FreeTypeSubPixelAntiAliasedGlyphRenderer>subGlyphOf:colorValue:mono:subpixelPosition:font: FreeTypeSubPixelAntiAliasedGlyphRenderer>renderStretchedGlyph:depth:subpixelPosition:font: ... FreeTypeFont>face FreeTypeFace>validate SmalltalkImage>session SessionManager class>default SessionManager>currentSession SmalltalkImage>session FreeTypeFace>create FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: I don't know what the actions should be? * Don't touch anything with fonts in the start-up path? * Run FT2Handle class >> #startUp earlier? * Pass the ByteArray to FreeTypeFace and let it pin it to memory? I think FreeTypeExternalMemory could go away with Spur? * Reset FreeTypeFace instVar fileContentsExternalMemory in >>#beNull? * Throw away all FreeTypeFace when we have a new Session? I think implementing: FreeTypeExternalMemory class >> #bytes: aByteArray ^(aByteArray copy) pin; yourself could solve most of it? (We can argue about the copy...) holger [1] Well it is broken as VMOPTIONOBJ adds the "-" to the front but all code that is using numbers do not handle the extra digit in sqSqueakOSXApplication.m. Maybe somebody beats me with a PR for it. ;)

March 24, 2018