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

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

by Mariano Martinez Peck

On Tue, May 22, 2012 at 5:46 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > we had same issue lately with Stef. > is there a fork introduced somewhere into MC code? > I think it was one of the things camillo did to improve performance with large package-cache but I may be wrong. > > On 22 May 2012 01:26, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > > 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. > >> > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

May 22, 2012

Re: [Pharo-project] [Sugar-devel] Dr.Geo on XO 1

by Marcus Denker

can you add an issue to the tracker? Then we can collect there all information that we have *and* we make sure that we are constantly reminded to look at it... On May 20, 2012, at 9:42 PM, Hilaire Fernandes wrote: > Is the memory object corrupted in Pharo 1.4? And explain the problem I > have in some situation with DrGeo on XO-1 256MB without swap. > > http://lists.squeak.org/pipermail/vm-dev/2012-May/010652.html > > Hilaire > > > Le 20/05/2012 13:57, Hilaire Fernandes a Ã©crit : >> With Pharo 1.4 (but not with Pharo 1.3) we have a problem leading to the >> crash of DrGeo (based on Pharo 1.4) on low memory machine. >> >> It is clearly a problem related to Pharo 1.4 >> >> Any idea why ? >> >> Hilaire >> >> >> -------- Original Message -------- >> Subject: Re: [Sugar-devel] Dr.Geo on XO 1 >> Date: Sun, 20 May 2012 13:46:01 +0200 >> From: Bert Freudenberg <bert(a)freudenbergs.de> >> To: Sascha Silbe <silbe(a)activitycentral.com> >> CC: Ariel Calzada <ariel.calzada(a)gmail.com>, Hilaire Fernandes >> <hilaire.fernandes(a)edu.ge.ch>, Sugar Devel >> <sugar-devel(a)lists.sugarlabs.org>, Rafael Ortiz >> <rafael(a)activitycentral.com> >> >> >> >> On 20.05.2012, at 11:00, Sascha Silbe wrote: >> >>> Bert Freudenberg <bert(a)freudenbergs.de> writes: >>> >>>> Nope, that was not it. I compiled with -mtune=geode, makes no >>>> difference. >>> >>> Make sure to set -march=<architecture> to something appropriate. -march >>> tells gcc what instructions it can use (so anything that doesn't support >>> these instructions will fail to run the resulting executable), whereas >>> -mtune only tells it to optimise for a certain processor type (but the >>> executable will continue to run on other processors as long as they >>> support the instruction set specified by -march). >> >> I actually had used "-march=pentiumpro -mtune=geode" as recommended here: >> >> http://wiki.laptop.org/go/Geode_LX >> >> and even with an additional -O0 it still crashes. >> >>> In gdb I see it's segfaulting inside the GC logic. It's really >>>> puzzling this only happens on the XO-1 ... >>> >>> You could try booting an XO-1.5 with mem=256M (append that to boot-file >>> in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1. >> >> >> YES! That reproduces the crash on XO-1.5. Good thinking! :) >> >> I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: >> >> Mem: 766204k total, 601588k used, 164616k free, 45624k buffers >> Swap: 0k total, 0k used, 0k free, 277024k cached >> >> but DrGeo still crashes. >> >> OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... >> >> - Bert - >> >> >> >> >> > > -- Marcus Denker -- http://marcusdenker.de

May 22, 2012

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

by Igor Stasenko

On 22 May 2012 06:41, chadwick <mathnoir(a)gmail.com> wrote: > admittedly I haven't loaded the very latest version! > > I tried changing class to clazz & now it fails with Generic Failure at > NBFFICallout > > cdecl: functionSpec emitCall: aCallEmittingBlock options: anOptions > handleFailureIn: aContext nativeCode: aBlock > ^ NBNativeCodeError signalError: lastError > > > and in the terminal: > > X Error: BadMatch (invalid parameter attributes) > Â Major opcode of failed request:Â 78 > Â Minor opcode of failed request:Â 0 > Â Serial number of failed request: 17 > X Error: BadColor (invalid Colormap parameter) > Â Major opcode of failed request:Â 1 > Â Minor opcode of failed request:Â 0 > Â Serial number of failed request: 18 > X Error: BadWindow (invalid Window parameter) > Â Major opcode of failed request:Â 8 > Â Minor opcode of failed request:Â 0 > Â Serial number of failed request: 19 > X Error: BadValue (integer parameter out of range for operation) > Â Major opcode of failed request:Â 135 > Â Minor opcode of failed request:Â 3 > Â Serial number of failed request: 32 > > > > So then I tried starting again with a fresh 1.4 image, following the > instructions at the top, but then: > > > registerPrimitiveSimulators > > Â Â Â ContextPart simulatePrimitive: #primitiveNativeCall module: > #NativeBoostPlugin with: self > > during ConfigurationOfNBOpenGL project lastVersion load. > and? this should be working just fine since its integrated in 1.4: http://code.google.com/p/pharo/issues/detail?id=5459 > > On Tue, May 22, 2012 at 1:25 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 22 May 2012 05:19, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >> > >> > >> > 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? >> > >> >> Hehe.. and i trapped myself with this too.. >> spent halt an hour trying to figure out why it goes into infinite >> recursion when generating the code, >> until recalled that we had this issue before ! :) >> >> Name: NBXLib-Core-JavierPimas.5 >> Author: JavierPimas >> Time: 16 April 2012, 10:54:45 am >> UUID: 94ca7907-d790-4740-8a63-51b1a2ec4a48 >> Ancestors: NBXLib-Core-JavierPimas.4 >> >> Rename field "class" in NBXLibVisualInfo to be klass so it doesn't >> break in pharo 1.4 >> >> > 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 >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

May 22, 2012

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

by Marcus Denker

On May 22, 2012, at 12:24 AM, Sean P. DeNigris 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? > yes. I added a report: http://code.google.com/p/pharo/issues/detail?id=5938 -- Marcus Denker -- http://marcusdenker.de

May 22, 2012

[Pharo-project] [update 2.0] #20087

by Marcus Denker

20087 ----- Issue 5933: cleanup use of Referencestream to load serialized fonts http://code.google.com/p/pharo/issues/detail?id=5933 Issue 5937: Continue cleaning ReferenceStream http://code.google.com/p/pharo/issues/detail?id=5937 Issue 5915: Cleaning Icons http://code.google.com/p/pharo/issues/detail?id=5915 -- Marcus Denker -- http://marcusdenker.de

May 22, 2012

[Pharo-project] Pharo Conference

by Torsten Bergmann

All the best for the first pharo conference - unfortunately I'm not able to attend. Please: if possible try to make videos available from the event. I'm sure people will be highly interested in the presented topics. Thx T. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

May 22, 2012

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

by Daniel Uber

On 05/21/2012 05:24 PM, Sean P. DeNigris 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. > I have seen this. In a 2.0 image updated to latest just now I can confirm it. I also get the trails in the commit message editor, and after a second try was able to get the red X as well. I can confirm noticing it yesterday. Daniel Uber

May 22, 2012

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

by chadwick

admittedly I haven't loaded the very latest version! I tried changing class to clazz & now it fails with Generic Failure at NBFFICallout cdecl: functionSpec emitCall: aCallEmittingBlock options: anOptions handleFailureIn: aContext nativeCode: aBlock ^ NBNativeCodeError signalError: lastError and in the terminal: X Error: BadMatch (invalid parameter attributes) Major opcode of failed request: 78 Minor opcode of failed request: 0 Serial number of failed request: 17 X Error: BadColor (invalid Colormap parameter) Major opcode of failed request: 1 Minor opcode of failed request: 0 Serial number of failed request: 18 X Error: BadWindow (invalid Window parameter) Major opcode of failed request: 8 Minor opcode of failed request: 0 Serial number of failed request: 19 X Error: BadValue (integer parameter out of range for operation) Major opcode of failed request: 135 Minor opcode of failed request: 3 Serial number of failed request: 32 So then I tried starting again with a fresh 1.4 image, following the instructions at the top, but then: registerPrimitiveSimulators ContextPart simulatePrimitive: #primitiveNativeCall module: #NativeBoostPlugin with: self during ConfigurationOfNBOpenGL project lastVersion load. On Tue, May 22, 2012 at 1:25 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 May 2012 05:19, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > > > > > 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? > > > > Hehe.. and i trapped myself with this too.. > spent halt an hour trying to figure out why it goes into infinite > recursion when generating the code, > until recalled that we had this issue before ! :) > > Name: NBXLib-Core-JavierPimas.5 > Author: JavierPimas > Time: 16 April 2012, 10:54:45 am > UUID: 94ca7907-d790-4740-8a63-51b1a2ec4a48 > Ancestors: NBXLib-Core-JavierPimas.4 > > Rename field "class" in NBXLibVisualInfo to be klass so it doesn't > break in pharo 1.4 > > > 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 > > > > -- > Best regards, > Igor Stasenko. > >

May 22, 2012

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

by Igor Stasenko

we had same issue lately with Stef. is there a fork introduced somewhere into MC code? On 22 May 2012 01:26, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > 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. >> > -- Best regards, Igor Stasenko.

May 22, 2012

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

by Igor Stasenko

On 22 May 2012 05:19, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > > 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? > Hehe.. and i trapped myself with this too.. spent halt an hour trying to figure out why it goes into infinite recursion when generating the code, until recalled that we had this issue before ! :) Name: NBXLib-Core-JavierPimas.5 Author: JavierPimas Time: 16 April 2012, 10:54:45 am UUID: 94ca7907-d790-4740-8a63-51b1a2ec4a48 Ancestors: NBXLib-Core-JavierPimas.4 Rename field "class" in NBXLibVisualInfo to be klass so it doesn't break in pharo 1.4 > 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 -- Best regards, Igor Stasenko.

May 22, 2012