- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] CMake for Windows?

by laurent laffont

easy_squeakvm here http://github.com/lolgzs/easy_squeakvm. It's github so you can fork it easily (I would love squeakvm sources on github :). Don't hesitate to ask for write access. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Mon, May 17, 2010 at 5:37 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, May 16, 2010 at 11:15 PM, Geoffroy Couprie <geo.couprie(a)gmail.com>wrote: > >> >> Hello, >> >> Here is the latest set of files for CMake: >> http://eleves.ec-lille.fr/~couprieg/divers/changes-16-05-10.tar.gz<http://eleves.ec-lille.fr/%7Ecouprieg/divers/changes-16-05-10.tar.gz> >> (you have to remove platforms/win32/vm/config.h to make it build) >> >> I tried to remove the dependency on the Squeak-win2-tools package. The >> Direct3D code still uses a lot of DirectX 7 structures, and the recent >> MinGW toolchain provides DirectX 8, so the B3DAccelerator plugin >> doesn't build right now. If it's ok, I'll send other patches to make >> it work with the new version. Otherwise, it's possible to modify >> config.cmake for B3DAccelerator to use DirectX 7. >> >> Could these patches be included now? The Unix VM builds without any >> problem, so it can become the main way to build it (just replace >> platforms/unix/cmake/configure by platforms/cmake/configure in the >> tutorials). There may still be some problems with the Windows build, >> but I'll send more patches once these are pushed in the svn :) >> >> > Hi Geoffroy. This is cool work. I cannot help you in the details of how to > commit that in SVN as I have no idea. Listen to David. > > Now...I have a couple of ideas: > > 1) regardless that, it would be really really cool if you can document all > this in the pharo collaborative book. As you can see there is already a > chapter for VM > > http://book.pharo-project.org/book/Virtual-Machine/ > > and the windows part is empty: > http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnWindow… > > So...we can write the two possibilities to compile in Windows: the standard > one and this new one using CMake. > You can start writing the one of CMake :) > If you want, please just let us know and we create a user for you. > > 2) In addition, I think it would be a good idea to have a Git for scripts > for the VM. If Squeak VM developers like them, they can also include it in > the svn. > > Laurent Laffont already has a git repository with scripts like > easy_squeakvm or something like that. So, you may want to commit your code > there too. > > 3) What about integrating like easy_squeakvm with this ? or do a > easy_squeakvm version of CMake for winwows ? I would love to do for > example: > > ./easy_squeakvm.sh --os=Windows or ./easy_squeakvm.sh --os=Unix > > 4) Would be really great to have a Screencast about how to compile windows > with CMake :) > > Cheers and continue pushing. > > Mariano > > > >> Best regards, >> >> Geoffroy >> > >

May 17, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by laurent laffont

On ArchLinux I have the problem when UUID is built external. Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me (UUID is internal). Can you try with this one click image I made once (uses 4.0.3.2202 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Mon, May 17, 2010 at 8:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 > > > _______________________________________________ > 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] maybe a stupid question :)

by Michael Roberts

way back then there was a thread about not calling Pharo what we should not call it.... but we have as a group consistently failed to do this. i would suggest that if people can't drop using *it*, then we have to give up. it is very difficult doing such brand management in an online group. we should be aware that Pharo is a specific brand we are trying to maintain. we can't control what comes out of folks keyboards.... thanks Mike On Sat, May 15, 2010 at 10:54 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > This was decided a long time ago: > - PharoCore is PharoCore > - PharoDev is Pharo (and from now on, perhaps it would be great to not talk > about PharoDev anymore) > > So, Pharo is PharoDev. In fact, only for very few people will PharoCore be > interesting. For most, Pharo(Dev) it is the interesting part. > > Cheers, > Doru > > > On 14 May 2010, at 20:48, Igor Stasenko wrote: > >> On 14 May 2010 21:36, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> I mean "pharo" is "pharo core" >>> >>> Is Linux only the Kernel? No. >>> You have a Linux version (distro) and the kernel version. >>> >>>> and "pharo dev" is just pharo+packages loaded >>> >>> Pharo-dev is what is distributed by default and typically >>> called "Pharo". Similar to the platform and loaded packages >>> in Eclipse or the linux kernel with loaded packages to form >>> a Linux system. >>> >> >> My 2c. >> >> I think that the difference here is that Pharo-Core maintained by >> Pharo team and under their direct >> responsibility, while Pharo-dev includes various packages, which is >> maintained separately. >> >> Pharo team, of course having a strong influence on Pharo-dev shape, >> but main focus is core. >> >>> Bye >>> T. >>> >>> >>> >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > 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] 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