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

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by Javier PimÃ¡s

On Tue, May 22, 2012 at 12:05 AM, chadwick <mathnoir(a)gmail.com> wrote: > > > On Tue, May 22, 2012 at 12:17 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com > > wrote: > >> Then probably the visualInfo has some problem. The symptom is that >> printOn: (inherited from NBExternalStructure) crashes while trying to show >> the fields. Now try niling the visualInfo visual field with code >> (visualInfo visual:nil) to see if it keeps crashing. > > > I can't - I tried moving self halt to after the creation of visualInfo, > and then self halt is never executed and the image progressively slows as > before, indicating that visualInfo was never initialized. > > What I also neglected to add before was that in visualInfo := > NBXLibVisualInfo fromPointer: it goes into handleFailureIn: nativeCode: > from NBFFICallout cdelc: emitCall: options: in NativeBoostLinux32 and > eventually hangs > > > > >> >> Also, what is the contents of NBXLibVisualInfo class>>#fieldsDesc ? >> > > fieldsDesc > " > self initializeAccessors > " > ^#( > NBXLibVisual "Visual*" visual; > VisualID visualid; > int screen; > uint depth; > int class; > ulong red_mask; > ulong green_mask; > ulong blue_mask; > int colormap_size; > int bits_per_rgb > ) > > this is good news! change "int class" to "int klass" and it'll probably start working. It's creating an accessor named "class", which breaks everything. It's a problem we saw before, I'll have to check because I thought I had uploaded the latest versions of monticello and the configuration. How did you load the code? Cheers! > >> >> You can send me the image via yousendit (I'll may look at it if I get >> some free time). >> > > yes will do that later.. > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

May 22, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by chadwick

On Tue, May 22, 2012 at 12:17 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Then probably the visualInfo has some problem. The symptom is that > printOn: (inherited from NBExternalStructure) crashes while trying to show > the fields. Now try niling the visualInfo visual field with code > (visualInfo visual:nil) to see if it keeps crashing. I can't - I tried moving self halt to after the creation of visualInfo, and then self halt is never executed and the image progressively slows as before, indicating that visualInfo was never initialized. What I also neglected to add before was that in visualInfo := NBXLibVisualInfo fromPointer: it goes into handleFailureIn: nativeCode: from NBFFICallout cdelc: emitCall: options: in NativeBoostLinux32 and eventually hangs > > Also, what is the contents of NBXLibVisualInfo class>>#fieldsDesc ? > fieldsDesc " self initializeAccessors " ^#( NBXLibVisual "Visual*" visual; VisualID visualid; int screen; uint depth; int class; ulong red_mask; ulong green_mask; ulong blue_mask; int colormap_size; int bits_per_rgb ) > > You can send me the image via yousendit (I'll may look at it if I get some > free time). > yes will do that later..

May 22, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by Javier PimÃ¡s

Then probably the visualInfo has some problem. The symptom is that printOn: (inherited from NBExternalStructure) crashes while trying to show the fields. Now try niling the visualInfo visual field with code (visualInfo visual:nil) to see if it keeps crashing. Also, what is the contents of NBXLibVisualInfo class>>#fieldsDesc ? You can send me the image via yousendit (I'll may look at it if I get some free time). Cheers. On Mon, May 21, 2012 at 10:38 PM, chadwick <mathnoir(a)gmail.com> wrote: > > > On Mon, May 21, 2012 at 10:04 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com > > wrote: > >> Could you put a self halt in NBGLXContextDriver>>createContext: and step >> over line by line to see which one is the offending one? >> > > > ok the line is: > colormap := display createColormapOn: window visual: visualInfo visual > alloc: AllocNone. > > and at that point the relevant local variables: > > window is 634 > display is a NBXLibDisplay( 0x896EFD0 ) > > it hangs when I touch visualInfo in the debugger, then eventually the VM > crashes with the following in the terminal: > > out of memory > > C stack backtrace: > ./NBCog/NBCog[0x8095489] > ./NBCog/NBCog(error+0x19)[0x8095709] > ./NBCog/NBCog[0x8075a5e] > ./NBCog/NBCog(createClosureNumArgsnumCopiedstartpc+0x54)[0x8076ab4] > ./NBCog/NBCog[0x8066bed] > [0xb57ab5e9] > ./NBCog/NBCog[0x808f694] > ./NBCog/NBCog(main+0x38a)[0x809668a] > /lib32/libc.so.6(__libc_start_main+0xf3)[0xf75800f3] > > > Smalltalk stack dump: > 0xffe7ac34 M Delay>schedule -1218533460: a(n) Delay > 0xffe7ac4c M Delay>wait -1218533460: a(n) Delay > 0xffe7ac64 M InputEventPollingFetcher>waitForInput -1247953104: a(n) > InputEventPollingFetcher > 0xffe7ac90 I InputEventPollingFetcher(InputEventFetcher)>eventLoop > -1247953104: a(n) InputEventPollingFetcher > 0xffe7acb0 I [] in > InputEventPollingFetcher(InputEventFetcher)>installEventLoop -1247953104: > a(n) InputEventPollingFetcher > 0xffe7acd0 I [] in BlockClosure>newProcess -1218533756: a(n) BlockClosure > > Most recent primitives > wait > signal > millisecondClockValue > millisecondClockValue > primSignal:atMilliseconds: > millisecondClockValue > wait > signal > wait > basicNew > millisecondClockValue > signal > primSignal:atMilliseconds: > millisecondClockValue > wait > primGetNextEvent: > at: > class > wait > signal > ... (this cycle repeats) > Aborted > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

May 22, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by chadwick

On Mon, May 21, 2012 at 10:04 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Could you put a self halt in NBGLXContextDriver>>createContext: and step > over line by line to see which one is the offending one? > ok the line is: colormap := display createColormapOn: window visual: visualInfo visual alloc: AllocNone. and at that point the relevant local variables: window is 634 display is a NBXLibDisplay( 0x896EFD0 ) it hangs when I touch visualInfo in the debugger, then eventually the VM crashes with the following in the terminal: out of memory C stack backtrace: ./NBCog/NBCog[0x8095489] ./NBCog/NBCog(error+0x19)[0x8095709] ./NBCog/NBCog[0x8075a5e] ./NBCog/NBCog(createClosureNumArgsnumCopiedstartpc+0x54)[0x8076ab4] ./NBCog/NBCog[0x8066bed] [0xb57ab5e9] ./NBCog/NBCog[0x808f694] ./NBCog/NBCog(main+0x38a)[0x809668a] /lib32/libc.so.6(__libc_start_main+0xf3)[0xf75800f3] Smalltalk stack dump: 0xffe7ac34 M Delay>schedule -1218533460: a(n) Delay 0xffe7ac4c M Delay>wait -1218533460: a(n) Delay 0xffe7ac64 M InputEventPollingFetcher>waitForInput -1247953104: a(n) InputEventPollingFetcher 0xffe7ac90 I InputEventPollingFetcher(InputEventFetcher)>eventLoop -1247953104: a(n) InputEventPollingFetcher 0xffe7acb0 I [] in InputEventPollingFetcher(InputEventFetcher)>installEventLoop -1247953104: a(n) InputEventPollingFetcher 0xffe7acd0 I [] in BlockClosure>newProcess -1218533756: a(n) BlockClosure Most recent primitives wait signal millisecondClockValue millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew millisecondClockValue signal primSignal:atMilliseconds: millisecondClockValue wait primGetNextEvent: at: class wait signal ... (this cycle repeats) Aborted

May 22, 2012

Re: [Pharo-project] addDeferredUIMessage: Documentation

by David T. Lewis

On Mon, May 21, 2012 at 03:46:21PM -0700, Sean P. DeNigris wrote: > I want to add a good comment to addDeferredUIMessage:. I know we use it > whenever we're updating Morphic from a background thread, but I've read > stuff saying to use it when Morphic is not in a "sane" state. In Squeak: addDeferredUIMessage: valuableObject "Arrange for valuableObject to be evaluated at a time when the user interface is in a coherent state." > > When, if ever, would you call addDeferredUIMessage: from the UI thread? > > I posted the following to the Squeak list 2 years ago.... > > I'm trying to add some documentation to addDeferredUIMessage:. What's a > good summary on this method? > > I collected the following snippets from the web... > > If you want to run something that accesses the Morphic UI, even though you > are not running from somewhere that the UI is in a sane state, you should > normally use addDeferredUIMessage:. Otherwise, you can put Morphic into > extremely confused states.... > > Per Ned Konz @ http://wiki.squeak.org/squeak/528: > Deferred UI messages are processed in the middle of the Morphic event loop, > just after responding to events, and before doing other step methods and > displaying the world. Look for implementors of #addDeferredUIMessage:, look > at the one in WorldState, look for senders of #deferredUIMessages, and > you'll see WorldState>>runStepMethodsIn: which empties the queue. And it's > called from doOneCycleNowFor: which is the body of the main Morphic event > loop. > > Per http://wiki.squeak.org/squeak/5689: > If you want to run something that accesses the Morphic UI, even though you > are not running from somewhere that the UI is in a sane state, you should > normally use addDeferredUIMessage:. Otherwise, you can put Morphic into > extremely confused states.... > > Per Wilhelm K Schwab @ > http://forum.world.st/Fwd-MouseOverHandler-td1300474.html#a1300474: > provides a clean way to interact with the GUI from background threads > > Per http://www.visoracle.com/squeak/faq/containerless.html: > As it is now, it's quite simple to put long-running computations in > background threads; you just don't let the background threads call methods > directly on Morphs. We have addDeferredUIMessage: to queue up action from > the background threads for later execution in the UI thread during the > next window cycle. > > Sean > > -- > View this message in context: http://forum.world.st/addDeferredUIMessage-Documentation-tp4631251.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2012

Re: [Pharo-project] Monticello Browser messing up Morphic?

by Fernando Olivero

I haven't experienced it. To recover: The trail generally happens when you have to UI process installed. Terminate the extra one and things will be back to normal. (try with both, and the current UI process will tell you it cant be killed). Fernando On Tue, May 22, 2012 at 12:24 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Every time I go to save a package in the latest 2.0, the world gets messed up > like http://code.google.com/p/pharo/issues/detail?id=5013. It seems to start > when I click "Save" and the commit message editor comes up. If I drag it > around, it leaves a trail (the Process Browser shows a "nil" process at the > UI priority in addition to the UI process). Once I accept the comment, MC > Browser gets that big red X thing replacing the list on the left. > > Is anyone else seeing this? > > Sean > > -- > View this message in context: http://forum.world.st/Monticello-Browser-messing-up-Morphic-tp4631248.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 21, 2012

[Pharo-project] addDeferredUIMessage: Documentation

by Sean P. DeNigris

I want to add a good comment to addDeferredUIMessage:. I know we use it whenever we're updating Morphic from a background thread, but I've read stuff saying to use it when Morphic is not in a "sane" state. When, if ever, would you call addDeferredUIMessage: from the UI thread? I posted the following to the Squeak list 2 years ago.... I'm trying to add some documentation to addDeferredUIMessage:. What's a good summary on this method? I collected the following snippets from the web... If you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states.... Per Ned Konz @ http://wiki.squeak.org/squeak/528: Deferred UI messages are processed in the middle of the Morphic event loop, just after responding to events, and before doing other step methods and displaying the world. Look for implementors of #addDeferredUIMessage:, look at the one in WorldState, look for senders of #deferredUIMessages, and you'll see WorldState>>runStepMethodsIn: which empties the queue. And it's called from doOneCycleNowFor: which is the body of the main Morphic event loop. Per http://wiki.squeak.org/squeak/5689: If you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states.... Per Wilhelm K Schwab @ http://forum.world.st/Fwd-MouseOverHandler-td1300474.html#a1300474: provides a clean way to interact with the GUI from background threads Per http://www.visoracle.com/squeak/faq/containerless.html: As it is now, it's quite simple to put long-running computations in background threads; you just don't let the background threads call methods directly on Morphs. We have addDeferredUIMessage: to queue up action from the background threads for later execution in the UI thread during the next window cycle. Sean -- View this message in context: http://forum.world.st/addDeferredUIMessage-Documentation-tp4631251.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

Re: [Pharo-project] DateAndTime>>asDosTime

by Sean P. DeNigris

Camillo Bruni-3 wrote > > yep I would say so too... > the major user is zip compression hence no one will ever notice the > possibly flawed implementation :P > Yes, since the error is internally consistent (zip and unzip cancel each other out), the image doesn't notice. But I manually unzipped an mcz file and the date was way off... I created an issue and uploaded a fix: Issue 5936: DateAndTime DOS conversion http://code.google.com/p/pharo/issues/detail?id=5936 Neither #fromDosTime: nor #asDosTime seem to correctly translate from DateAndTime to DOS timestamps. Delete comment Comment 1 by project member sean.p.denigris, Today (2 hours ago) Fix in inbox: Name: SLICE-Issue-5936-DateAndTime-DOS-conversion-SeanDeNigris.1 * Fix conversion to/from DateAndTime and DOS timestamps. DOS format per http://blogs.msdn.com/b/oldnewthing/archive/2003/09/05/54806.aspx and http://mindprod.com/jgloss/zip.html * Deprecated and renamed DateAndTime>>asDosTime to #asDosTimestamp (it is not a time, but an encoded date/time) * Deprecated and renamed DateAndTime class>>fromDosSeconds: to #fromDosTimestamp (it is not a number of seconds, like a UNIX or Squeak date/time) * Updated ZipArchiveMember to use new method names * Create DosTimestamp class, and move all DOS-related logic out of DateAndTime * Update tests, removing #testAsDosTimeIndependentOfTimezone (they are not independent; DOS timestamps are in local time), and add tests, which all pass Sean -- View this message in context: http://forum.world.st/DateAndTime-asDosTime-tp4630789p4631250.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

[Pharo-project] Monticello Browser messing up Morphic?

by Sean P. DeNigris

Every time I go to save a package in the latest 2.0, the world gets messed up like http://code.google.com/p/pharo/issues/detail?id=5013. It seems to start when I click "Save" and the commit message editor comes up. If I drag it around, it leaves a trail (the Process Browser shows a "nil" process at the UI priority in addition to the UI process). Once I accept the comment, MC Browser gets that big red X thing replacing the list on the left. Is anyone else seeing this? Sean -- View this message in context: http://forum.world.st/Monticello-Browser-messing-up-Morphic-tp4631248.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

Re: [Pharo-project] Pharo conference schedule

by stephane ducasse

Here are the links. https://www.google.com/calendar/ical/2d97rjlqso704v09d49sgcsjec%40group.cal… https://www.google.com/calendar/embed?src=2d97rjlqso704v09d49sgcsjec%40grou… Stef On May 21, 2012, at 10:59 PM, StÃ©phane Ducasse wrote: > Hi guys > > I'm fighting a bit with the google calendar and the program. > Here are the latest schedule. > Remember that we want to have discussions.<Screen Shot 2012-05-21 at 10.50.40 PM.pdf><Screen Shot 2012-05-21 at 10.58.09 PM.pdf>

May 21, 2012