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

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Michael Roberts

what are the exact problems with the network? lukas' email said that the resolver behaviour had changed positively, not that there was an issue. or did i miss read? thanks, Mike On Mon, May 17, 2010 at 9:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > So what do you suggest > Â Â Â Â beta for two three weeks > Â Â Â Â then rc1 > > Stef > > On May 17, 2010, at 10:00 AM, Mariano Martinez Peck wrote: > >> >> >> On Mon, May 17, 2010 at 9:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Unstable is alpha. We called it that way so that people do not start to use it :) >> >> Ok, we can tag it beta then. >> >> But now we should go beta=releaseCandidate1 >> >> >> No, I don't agree. That's not the same. One thing is beta and another thing is a release candidate. >> >> >> Stef >> >> On May 16, 2010, at 11:18 PM, Mariano Martinez Peck wrote: >> >> > >> > >> > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > check the network problem. >> > But we can release rc1 anytime now. >> > >> > >> > No, please. We are not in a RC yet. We should first go as alpha, then beta and finally RC. >> > We cannot go in a RC with the first build ever. >> > >> > Cheers >> > >> > Mariano >> > >> > >> > Stef >> > >> > On May 16, 2010, at 11:00 PM, Alexandre Bergel wrote: >> > >> > > Mariano, >> > > >> > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a Pharo1.1 from a core, and it works perfectly, including condenseChange. >> > > >> > > Cheers, >> > > Alexandre >> > > >> > > >> > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: >> > > >> > >> We are basically ready >> > >> Waiting for feedback on network. >> > >> >> > >> Stef >> > >> >> > >> >> > >> On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: >> > >> >> > >>> We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: >> > >>> >> > >>> - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image >> > >>> - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) >> > >>> - Make publish all new VMs (for each OS) >> > >>> >> > >>> Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) >> > >>> >> > >>> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). >> > >>> >> > >>> Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. >> > >>> >> > >>> now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? >> > >>> >> > >>> Cheers >> > >>> >> > >>> Mariano >> > >>> _______________________________________________ >> > >>> Pharo-project mailing list >> > >>> Pharo-project(a)lists.gforge.inria.fr >> > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> > >> >> > >> _______________________________________________ >> > >> Pharo-project mailing list >> > >> Pharo-project(a)lists.gforge.inria.fr >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > Pharo-project(a)lists.gforge.inria.fr >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by StÃ©phane Ducasse

On Ma > > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > bit 0: 1 => open full screen, 0 => open using width & height > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > bit 4: 1 => preempting a process does not put it to the back of its run queue I was not clear how to read bit 3: 1 this information is not in the compiledMethods? Stef

May 17, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by StÃ©phane Ducasse

thanks On May 17, 2010, at 8:03 PM, Eliot Miranda wrote: > Hi Steph, > > On Sun, May 16, 2010 at 11:24 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > elliot > > that the format is in the image is good know. Do you know where we can find the information I imagine in VMmaker > But sometimes we want to be able to script the image itself without restarting it. > > The method is Interpreter>>writeImageFileIO:. Here's the relevant extract from the slightly extended method in Cog: > > headerSize := 64. "header size in bytes; do not change!" > > f := self cCode: 'sqImageFileOpen(imageName, "wb")'. > f = nil ifTrue: "could not open the image file for writing" > [^self primitiveFail]. > > headerStart := self cCode: 'sqImageFileStartLocation(f,imageName,headerSize+imageBytes)'. > self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'. > "position file to start of header" > self sqImageFile: f Seek: headerStart. > > self putLong: self imageFormatVersion toFile: f. > self putLong: headerSize toFile: f. > self putLong: imageBytes toFile: f. > self putLong: self startOfMemory toFile: f. > self putLong: specialObjectsOop toFile: f. > self putLong: self newObjectHash toFile: f. > self putLong: self ioScreenSize toFile: f. > self putLong: self getImageHeaderFlags toFile: f. > self putLong: extraVMMemory toFile: f. > self putShort: desiredNumStackPages toFile: f. > self putShort: self unknownShortOrCodeSizeInKs toFile: f. > self putLong: desiredEdenBytes toFile: f. > self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f. > self putShort: 0 toFile: f. > 1 to: 4 do: [:i | self putLong: 0 toFile: f]. "fill remaining header words with zeros" > > So the simple header (the header without an initial 512 bytes used on some Mac systems) looks like: > > bytes 0 to 3: image version number in either little or big endian order (used to determine header and image byte order) > 6504 for 32-bit images > 68002 for 64-bit images > 6505 for 32-bit Cog images (slightly different compact class layout) > bytes 4 to 7: header size (e.g. 64 bytes) > bytes 8 to 11: image size in bytes > bytes 12 to 15: address of start of first object in image (nil) when image was saved (*) > bytes 16 to 19: address of specialObjectsOop (not start of specialObjectsOop) when image was saved (*) > bytes 20 to 23: next object hash (unused in Cog) > bytes 24 to 27: screen width << 16 + screen height > big endian: bytes 24 & 25 are width, little endian: bytes 24 & 25 are height > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > bit 0: 1 => open full screen, 0 => open using width & height > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > bit 4: 1 => preempting a process does not put it to the back of its run queue > bytes 32 to 35: extra vm memory (typically 0) > bytes 36 to 37: number of stack pages to allocate > bytes 38 to 39: amount of memory for JITed code in 1024k units (63 MB max) > bytes 40 to 43: size of the eden zone > really a value that determines how much memory to allocate before doing an incremental collection > bytes 44 to 45: max size of the external semaphore table (64k max) > bytes 46 to 47: 0, reserved for future use > bytes 48 to 63: 0, reserved for future use > > > So e.g. if anyone writes an image modification utility please try and preserve the entirety of the header, modifying only what you need to modify, so as not to break future VMs. > > > HTH > Eliot > > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by StÃ©phane Ducasse

I can confirm that this is exactly the same trace than the one reported by laurent (no debug file). Stef On May 17, 2010, at 7:51 PM, David T. Lewis wrote: > On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: >> Hi guys >> >> I took seaside the latest one click image and when I have to save a MC package >> I get a core dump with UUID new:... >> I checke the so.UUIDplugin is there and I do not understand. >> Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. > > Hi Stef, > > This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 > > It is not clear to me if the issue is resolved in the Ian's latest VM > build, so if you or anyone else can confirm the UUID crash happening > with this VM, that would be helpful to clarify. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Eliot Miranda

Hi Steph, On Sun, May 16, 2010 at 11:24 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > elliot > > that the format is in the image is good know. Do you know where we can find > the information I imagine in VMmaker > But sometimes we want to be able to script the image itself without > restarting it. > The method is Interpreter>>writeImageFileIO:. Here's the relevant extract from the slightly extended method in Cog: headerSize := 64. "header size in bytes; do not change!" f := self cCode: 'sqImageFileOpen(imageName, "wb")'. f = nil ifTrue: "could not open the image file for writing" [^self primitiveFail]. headerStart := self cCode: 'sqImageFileStartLocation(f,imageName,headerSize+imageBytes)'. self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'. "position file to start of header" self sqImageFile: f Seek: headerStart. self putLong: self imageFormatVersion toFile: f. self putLong: headerSize toFile: f. self putLong: imageBytes toFile: f. self putLong: self startOfMemory toFile: f. self putLong: specialObjectsOop toFile: f. self putLong: self newObjectHash toFile: f. self putLong: self ioScreenSize toFile: f. self putLong: self getImageHeaderFlags toFile: f. self putLong: extraVMMemory toFile: f. self putShort: desiredNumStackPages toFile: f. self putShort: self unknownShortOrCodeSizeInKs toFile: f. self putLong: desiredEdenBytes toFile: f. self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f. self putShort: 0 toFile: f. 1 to: 4 do: [:i | self putLong: 0 toFile: f]. "fill remaining header words with zeros" So the simple header (the header without an initial 512 bytes used on some Mac systems) looks like: bytes 0 to 3: image version number in either little or big endian order (used to determine header and image byte order) 6504 for 32-bit images 68002 for 64-bit images 6505 for 32-bit Cog images (slightly different compact class layout) bytes 4 to 7: header size (e.g. 64 bytes) bytes 8 to 11: image size in bytes bytes 12 to 15: address of start of first object in image (nil) when image was saved (*) bytes 16 to 19: address of specialObjectsOop (not start of specialObjectsOop) when image was saved (*) bytes 20 to 23: next object hash (unused in Cog) bytes 24 to 27: screen width << 16 + screen height big endian: bytes 24 & 25 are width, little endian: bytes 24 & 25 are height bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 bit 0: 1 => open full screen, 0 => open using width & height bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) bit 4: 1 => preempting a process does not put it to the back of its run queue bytes 32 to 35: extra vm memory (typically 0) bytes 36 to 37: number of stack pages to allocate bytes 38 to 39: amount of memory for JITed code in 1024k units (63 MB max) bytes 40 to 43: size of the eden zone really a value that determines how much memory to allocate before doing an incremental collection bytes 44 to 45: max size of the external semaphore table (64k max) bytes 46 to 47: 0, reserved for future use bytes 48 to 63: 0, reserved for future use So e.g. if anyone writes an image modification utility please try and preserve the entirety of the header, modifying only what you need to modify, so as not to break future VMs. HTH Eliot Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by David T. Lewis

On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: > Hi guys > > I took seaside the latest one click image and when I have to save a MC package > I get a core dump with UUID new:... > I checke the so.UUIDplugin is there and I do not understand. > Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. Hi Stef, This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 It is not clear to me if the issue is resolved in the Ian's latest VM build, so if you or anyone else can confirm the UUID crash happening with this VM, that would be helpful to clarify. Dave

May 17, 2010

[Pharo-project] UUID on ubuntu 10.04

by StÃ©phane Ducasse

Hi guys I took seaside the latest one click image and when I have to save a MC package I get a core dump with UUID new:... I checke the so.UUIDplugin is there and I do not understand. Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. Stef

May 17, 2010

Re: [Pharo-project] FFI examples?

by StÃ©phane Ducasse

> StÃ©phane Ducasse wrote: >> >> Does anybody with experience have a bit of time to get some text for the >> website >> > > You read my mind... stop that! In another life we did telepathy magicianwith alex and it was fun > > I've been working on this for a few days. I almost have a summary for > more-knowledgeable folks to critique. excellent I'm eager to read that. > > Sean > -- > View this message in context: http://forum.world.st/FFI-examples-tp2219674p2219873.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] FFI examples?

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > Does anybody with experience have a bit of time to get some text for the > website > You read my mind... stop that! I've been working on this for a few days. I almost have a summary for more-knowledgeable folks to critique. Sean -- View this message in context: http://forum.world.st/FFI-examples-tp2219674p2219873.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2010

Re: [Pharo-project] TextEditor and NewTextMorph merges and fixes

by Fernando olivero

De nada ! Actually i just published another version of the CodeMorph. I found no need for subclassing CodeMorph, since the accepting behavior is on the announcements now, having specific ClassDescriptionMorph and MethodMorph wouldn't be beneficial. Also removed the dependency with the Shout ( and the styler). Name: Morphic-FernandoOlivero.589 Rethought the CodeMorph class hierarchy, removed the subclasses and added CodeMorph class methods for creating "MethodMorph" and "ClassDefinitionMorph" Fernando On May 17, 2010, at 3:35 PM, StÃ©phane Ducasse wrote: > Tx!!!! > Gaucho man > > On May 17, 2010, at 3:32 PM, Fernando olivero wrote: > >> Issue: 2375 >> >> Name: System-Text-FernandoOlivero.8 >> Author: FernandoOlivero >> Time: 17 May 2010, 3:22:14 pm >> >> >> >> ###################################### >> Issue: -- >> >> Name: Morphic-FernandoOlivero.588 >> Author: FernandoOlivero >> Time: 17 May 2010, 1:42:04 pm >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010