[Pharo-project] The Pharo Linux Vm [WAS] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green
If someone is interested, these are all the packages I needed to install in order not to have problems in my Ubuntu 9.10:
sudo apt-get install linux-libc-dev libecasound2.2-dev libasound2-dev libc6-dev gnulib libc6-dev libpulse-dev libxrender-dev uuid-dev
Should be on Pharo website, given the popularity of Ubuntu.
I was thinking to add that to the readme.txt. Laurent, can you please download VM: http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip
From my point of view, we need to distribute a Linux VM that:
- Has a easy way to install. I think your VM is cool in these point. I found Exupery a bit more tricky. - Has FreeType installed - Has an EXCELLENT README.TXT that explains how to compile from source, how to install it, how to use it, and a FAQ for tipical questions. For example, in Ubuntu, these libraries has to be installed in order to compile. What happend with 64 bits? All that has to be explained in that file - In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY confusing for newcomers. - It has to include sources. I know a lot of people that says "I won't put anything in production that I cannot compile by myself first". - It has to be a Standard VM, not Exupery. Exupery without the exupery package, has no sense at all. It is in Pharo download just because of history reasons. Bryce was very helpful and was the first in put closures in the VM. So, we used that. Now, it has no sense anymore. - Pass all PharoRC3 tests in green - The process has to be repeatable. Someone has to be able to came in 1 year, donwload the same VM and repeat the steps without major problems. - The readme.txt has to include the SVN revision where the C code was taken. - It would also be good to said which ConfigurationOfVmMaker version was used. Cheers Mariano
Ok.....but not only plugins. For exaple, if I don't want UTF-8 ?
errr... maybe it's time to ask to the vm-dev list :)
ufff.....what an idiot...thanks! did you already discovered I am a newbie here ? :)
Me too, but a little less every day :)
Laurent Laffont
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/3/28 Mariano Martinez Peck <marianopeck@gmail.com>
If someone is interested, these are all the packages I needed to install in order not to have problems in my Ubuntu 9.10:
sudo apt-get install linux-libc-dev libecasound2.2-dev libasound2-dev libc6-dev gnulib libc6-dev libpulse-dev libxrender-dev uuid-dev
Should be on Pharo website, given the popularity of Ubuntu.
I was thinking to add that to the readme.txt. Laurent, can you please download VM:
http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip
Yes.
From my point of view, we need to distribute a Linux VM that:
- Has a easy way to install. I think your VM is cool in these point. I found Exupery a bit more tricky. - Has FreeType installed - Has an EXCELLENT README.TXT that explains how to compile from source, how to install it, how to use it, and a FAQ for tipical questions. For example, in Ubuntu, these libraries has to be installed in order to compile. What happend with 64 bits? All that has to be explained in that file
I don't know, my system is 32 bits, don't have the courage to install a 64 bits one :)
- In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY confusing for newcomers.
I agree we need to explain better the distinction between the VM and the image. I'm not sure about renaming squeak-vm -> pharo-vm. It's not a fork. I tend to think it will bring higher confusion.
- It has to include sources. I know a lot of people that says "I won't put anything in production that I cannot compile by myself first".
Yes, I'm one of those people :)
- It has to be a Standard VM, not Exupery. Exupery without the exupery package, has no sense at all. It is in Pharo download just because of history reasons. Bryce was very helpful and was the first in put closures in the VM. So, we used that. Now, it has no sense anymore.
I haven't been able to build Exupery ...
- Pass all PharoRC3 tests in green - The process has to be repeatable. Someone has to be able to came in 1 year, donwload the same VM and repeat the steps without major problems. - The readme.txt has to include the SVN revision where the C code was taken. - It would also be good to said which ConfigurationOfVmMaker version was used.
Agree. Maybe you can open a git repository on INRIA servers so we can keep track of patches + README included in the VM for Pharo. I've used Javier and Levente patches and these are not included in squeak-vm svn. I sent a mail last week on vm-dev but no answers. This way builders can do: git clone git://......squeak-vm cd ..squeak-vm../build ... configure && make && make install. For packagers it would be cool. Developpers can have their own branches and submit patches more easily, add more visibility. With git-svn we can synchronize from official Squeak-VM svn (until they switched to git or another DVCS :) What do you think ? Laurent Laffont
Cheers
Mariano
Ok.....but not only plugins. For exaple, if I don't want UTF-8 ?
errr... maybe it's time to ask to the vm-dev list :)
ufff.....what an idiot...thanks! did you already discovered I am a newbie here ? :)
Me too, but a little less every day :)
Laurent Laffont
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY confusing for newcomers.
I agree we need to explain better the distinction between the VM and the image. I'm not sure about renaming squeak-vm -> pharo-vm. It's not a fork. I tend to think it will bring higher confusion.
I don't agree. Image you are a new comer. For you, Pharo is Pharo. You probaly have no idea what Squeak is. So...you go to Pharo website, and download the image, and the VM. Imagine when you go to download the VM and it says "SqueakVM". I would say "WTF?????" "WTF is squeak?" I am not saying forking the VM. Just to rename it. Actually, the windows VM has that name: " http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip" And the same with exupery: " http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip"
- Pass all PharoRC3 tests in green - The process has to be repeatable. Someone has to be able to came in 1 year, donwload the same VM and repeat the steps without major problems. - The readme.txt has to include the SVN revision where the C code was taken. - It would also be good to said which ConfigurationOfVmMaker version was used.
Agree.
Maybe you can open a git repository on INRIA servers so we can keep track of patches + README included in the VM for Pharo. I've used Javier and Levente patches and these are not included in squeak-vm svn. I sent a mail last week on vm-dev but no answers. This way builders can do: git clone git://......squeak-vm cd ..squeak-vm../build ... configure && make && make install. For packagers it would be cool. Developpers can have their own branches and submit patches more easily, add more visibility. With git-svn we can synchronize from official Squeak-VM svn (until they switched to git or another DVCS :)
What do you think ?
I like the idea....but what about the sync with the public/official SVN repo ? how we will be able to merge ? or the GIT repo will be only for patches ? Cheers Mariano
Laurent Laffont
Cheers
Mariano
Ok.....but not only plugins. For exaple, if I don't want UTF-8 ?
errr... maybe it's time to ask to the vm-dev list :)
ufff.....what an idiot...thanks! did you already discovered I am a newbie here ? :)
Me too, but a little less every day :)
Laurent Laffont
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/3/29 Mariano Martinez Peck <marianopeck@gmail.com>:
- In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY confusing for newcomers.
I agree we need to explain better the distinction between the VM and the image. I'm not sure about renaming squeak-vm -> pharo-vm. It's not a fork. I tend to think it will bring higher confusion.
I don't agree. Image you are a new comer. For you, Pharo is Pharo. You probaly have no idea what Squeak is. So...you go to Pharo website, and download the image, and the VM. Imagine when you go to download the VM and it says "SqueakVM". I would say "WTF?????"Â Â Â "WTF is squeak?" I am not saying forking the VM. Just to rename it. Actually, the windows VM has that name: "http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip" And the same with exupery: "http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip"
Yes and also having a Pharo icon and not a Squeak one. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Mon, Mar 29, 2010 at 4:23 AM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
2010/3/29 Mariano Martinez Peck <marianopeck@gmail.com>:
- In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY
confusing
for newcomers.
I agree we need to explain better the distinction between the VM and the image. I'm not sure about renaming squeak-vm -> pharo-vm. It's not a fork. I tend to think it will bring higher confusion.
I don't agree. Image you are a new comer. For you, Pharo is Pharo. You probaly have no idea what Squeak is. So...you go to Pharo website, and download the image, and the VM. Imagine when you go to download the VM and it says "SqueakVM". I would say "WTF?????" "WTF is squeak?" I am not saying forking the VM. Just to rename it. Actually, the windows VM has that name: "http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip" And the same with exupery: " http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip"
Yes and also having a Pharo icon and not a Squeak one.
Yes! The windows VM has already that. The MacVM, I sent an email few months ago to explain how to do it. If you want, I can upload a Squeak 4.2.2beta1U.app but with the Pharo icons and named Pharo 4.2.2beta1U.app Then we link from the website to that VM. What do you think ? I know there are newer MacOS VMs, but they are still in beta and for the Pharo 1.0 I think the best VM is the 4.2.2.beta1 What do you think ? Cheers Mariano
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 29, 2010, at 9:29 45AM, Mariano Martinez Peck wrote:
Yes! The windows VM has already that. The MacVM, I sent an email few months ago to explain how to do it. If you want, I can upload a Squeak 4.2.2beta1U.app but with the Pharo icons and named Pharo 4.2.2beta1U.app Then we link from the website to that VM. What do you think ?
I know there are newer MacOS VMs, but they are still in beta and for the Pharo 1.0 I think the best VM is the 4.2.2.beta1
What do you think ?
Cheers
Mariano
Please use 4.2.3.beta1, as it includes the bitblt fixes which affects StrikeFont rendering. So if someone switches to Bitmap DejaVu fonts, they don't have to be annoyed their text looks strange when dragging windows :) Cheers, Henry
On Mon, Mar 29, 2010 at 6:16 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On Mar 29, 2010, at 9:29 45AM, Mariano Martinez Peck wrote:
Yes! The windows VM has already that. The MacVM, I sent an email few
months ago to explain how to do it.
If you want, I can upload a Squeak 4.2.2beta1U.app but with the Pharo icons and named Pharo 4.2.2beta1U.app Then we link from the website to that VM. What do you think ?
I know there are newer MacOS VMs, but they are still in beta and for the Pharo 1.0 I think the best VM is the 4.2.2.beta1
What do you think ?
Cheers
Mariano
Please use 4.2.3.beta1, as it includes the bitblt fixes which affects StrikeFont rendering. So if someone switches to Bitmap DejaVu fonts, they don't have to be annoyed their text looks strange when dragging windows :)
Thanks Henrik I wasn't aware (actually, I think I forgot) about that. I have just tested and seems to work perfect. All tests pass and it is a little (very little) more faster than 4.2.2. So...I agree we should put 4.2.3.beta1. Cheers Mariano
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2010-03-29, at 12:29 AM, Mariano Martinez Peck wrote:
Yes! The windows VM has already that. The MacVM, I sent an email few months ago to explain how to do it. If you want, I can upload a Squeak 4.2.2beta1U.app but with the Pharo icons and named Pharo 4.2.2beta1U.app Then we link from the website to that VM. What do you think ?
I know there are newer MacOS VMs, but they are still in beta and for the Pharo 1.0 I think the best VM is the 4.2.2.beta1
What do you think ?
Cheers
Mariano
That would be a 4.2.3b1 VM since it contains the bitblt fixes that the Squeak folks wanted. I have no idea how that impacts text rendering on Pharo. Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap? Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode? -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
On 2010-03-29, at 12:29 AM, Mariano Martinez Peck wrote:
Yes! The windows VM has already that. The MacVM, I sent an email few months ago to explain how to do it. If you want, I can upload a Squeak 4.2.2beta1U.app but with the Pharo icons and named Pharo 4.2.2beta1U.app Then we link from the website to that VM. What do you think ?
I know there are newer MacOS VMs, but they are still in beta and for the Pharo 1.0 I think the best VM is the 4.2.2.beta1
What do you think ?
Cheers
Mariano
That would be a 4.2.3b1 VM since it contains the bitblt fixes that the Squeak folks wanted. I have no idea how that impacts text rendering on Pharo.
Uffff sorry John. My bad. I wanted to say 4.2.3.b1, thanks.
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything. We even started to remove part of it in Pharo. And SqueakMap was completely removed. I think for Pharo 1.0 is better a well tested VM like the 4.2.3.b1 is, and let version 5 for Pharo 1.1. What do you think ? Cheers Mariano
Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote:
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything.
Mariano, I know you know image segments, but I think this is may be confusing for others. So I like to say something ;) Image segments work very well; both from a reliability and performance point of view. We are using them for hundreds of customers. DabbleDB uses images segments as well AFAIK. There are two parts, the primitives implemented by the VM in C and the image-side code. The code in the image consists of support code to load and store a segment and on top of this there is code for swapping in/out classes, projects etc. Especially the latter is a mess and we already started cleaning it. As images segments are not used by core code we also consider moving it into a separate, external package (of course, the primitives should stay in the VM).
We even started to remove part of it in Pharo. And SqueakMap was completely removed.
Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not critical for us. Cheers, Adrian
On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote:
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything.
Mariano, I know you know image segments, but I think this is may be confusing for others. So I like to say something ;)
Image segments work very well; both from a reliability and performance point of view. We are using them for hundreds of customers. DabbleDB uses images segments as well AFAIK.
There are two parts, the primitives implemented by the VM in C and the image-side code. The code in the image consists of support code to load and store a segment and on top of this there is code for swapping in/out classes, projects etc. Especially the latter is a mess and we already started cleaning it. As images segments are not used by core code we also consider moving it into a separate, external package (of course, the primitives should stay in the VM).
Thanks for the remark Adrian :) I know you know more for ImageSegments than all of us. As you said, it works pretty well for a piece of the domain. For example, in your case, you just export the segment, but did you try to swap them out (but letting the segment inside) and load it again ? it was broken. Exporting a segment, and bring them back again but where classes were modified or removed in the image, was broken also. If you load segments from older versions, it was broken too (this was what they fixed now). The symbols, you explained me that problem. In your case it works perfect because, as you say, almost only use the primitives, no more. But that's a very limited piece of ImageSegment. That piece, in that way, it works. For big segments, I am not sure if it works well neither. The segment allocates more than 2 times what needed. In DabbleDB I read they had that problem. The segments were too big, that having to allocate 2 or 3 times, crash everything. Cheers Mariano
We even started to remove part of it in Pharo. And SqueakMap was completely removed.
Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not critical for us.
Cheers, Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Adrian and Mariano for this interesting discussion. Alexandre On 29 Mar 2010, at 16:23, Mariano Martinez Peck wrote:
On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote:
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything.
Mariano, I know you know image segments, but I think this is may be confusing for others. So I like to say something ;)
Image segments work very well; both from a reliability and performance point of view. We are using them for hundreds of customers. DabbleDB uses images segments as well AFAIK.
There are two parts, the primitives implemented by the VM in C and the image-side code. The code in the image consists of support code to load and store a segment and on top of this there is code for swapping in/out classes, projects etc. Especially the latter is a mess and we already started cleaning it. As images segments are not used by core code we also consider moving it into a separate, external package (of course, the primitives should stay in the VM).
Thanks for the remark Adrian :) I know you know more for ImageSegments than all of us.
As you said, it works pretty well for a piece of the domain. For example, in your case, you just export the segment, but did you try to swap them out (but letting the segment inside) and load it again ? it was broken. Exporting a segment, and bring them back again but where classes were modified or removed in the image, was broken also. If you load segments from older versions, it was broken too (this was what they fixed now). The symbols, you explained me that problem. In your case it works perfect because, as you say, almost only use the primitives, no more. But that's a very limited piece of ImageSegment. That piece, in that way, it works.
For big segments, I am not sure if it works well neither. The segment allocates more than 2 times what needed. In DabbleDB I read they had that problem. The segments were too big, that having to allocate 2 or 3 times, crash everything.
Cheers
Mariano
We even started to remove part of it in Pharo. And SqueakMap was completely removed.
Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not critical for us.
Cheers, Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mar 29, 2010, at 22:23 , Mariano Martinez Peck wrote:
On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote:
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything.
Mariano, I know you know image segments, but I think this is may be confusing for others. So I like to say something ;)
Image segments work very well; both from a reliability and performance point of view. We are using them for hundreds of customers. DabbleDB uses images segments as well AFAIK.
There are two parts, the primitives implemented by the VM in C and the image-side code. The code in the image consists of support code to load and store a segment and on top of this there is code for swapping in/out classes, projects etc. Especially the latter is a mess and we already started cleaning it. As images segments are not used by core code we also consider moving it into a separate, external package (of course, the primitives should stay in the VM).
Thanks for the remark Adrian :) I know you know more for ImageSegments than all of us.
As you said, it works pretty well for a piece of the domain. For example, in your case, you just export the segment, but did you try to swap them out (but letting the segment inside) and load it again ? it was broken. Exporting a segment, and bring them back again but where classes were modified or removed in the image, was broken also. If you load segments from older versions, it was broken too (this was what they fixed now). The symbols, you explained me that problem. In your case it works perfect because, as you say, almost only use the primitives, no more. But that's a very limited piece of ImageSegment. That piece, in that way, it works.
Yes, exactly. And I think that's the most important piece and the one valuable to maintain. We just create a segment, write it to disc, and read it back from there into a fresh image. The only problem we had was with the symbols you mentioned above. We do migrations with scripts inside the image so that the segment's instances are always in sync with the code of the image we load them into.
For big segments, I am not sure if it works well neither. The segment allocates more than 2 times what needed. In DabbleDB I read they had that problem. The segments were too big, that having to allocate 2 or 3 times, crash everything.
Depends on what you think is big. Most of our segments are smaller than 50MB but I have seen larger ones that worked too. Cheers, Adrian
Cheers
Mariano
We even started to remove part of it in Pharo. And SqueakMap was completely removed.
Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not critical for us.
Cheers, Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
would be nice to have a **new** and separate package with clean code for your scenario adrian. Stef On Mar 30, 2010, at 8:48 AM, Adrian Lienhard wrote:
On Mar 29, 2010, at 22:23 , Mariano Martinez Peck wrote:
On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote:
2010/3/29 John M McIntosh <johnmci@smalltalkconsulting.com>
Also this week I will ship a 4.2.4b1 VM which is the result of some Squeak 4.0 base VM merge processing and contains the fix to enable the loading of old image segments used I guess by squeakmap?
I am not sure. ImageSegment is a full of c...and maybe it will be even removed. It was not working since a lot of time and nobody says anything.
Mariano, I know you know image segments, but I think this is may be confusing for others. So I like to say something ;)
Image segments work very well; both from a reliability and performance point of view. We are using them for hundreds of customers. DabbleDB uses images segments as well AFAIK.
There are two parts, the primitives implemented by the VM in C and the image-side code. The code in the image consists of support code to load and store a segment and on top of this there is code for swapping in/out classes, projects etc. Especially the latter is a mess and we already started cleaning it. As images segments are not used by core code we also consider moving it into a separate, external package (of course, the primitives should stay in the VM).
Thanks for the remark Adrian :) I know you know more for ImageSegments than all of us.
As you said, it works pretty well for a piece of the domain. For example, in your case, you just export the segment, but did you try to swap them out (but letting the segment inside) and load it again ? it was broken. Exporting a segment, and bring them back again but where classes were modified or removed in the image, was broken also. If you load segments from older versions, it was broken too (this was what they fixed now). The symbols, you explained me that problem. In your case it works perfect because, as you say, almost only use the primitives, no more. But that's a very limited piece of ImageSegment. That piece, in that way, it works.
Yes, exactly. And I think that's the most important piece and the one valuable to maintain. We just create a segment, write it to disc, and read it back from there into a fresh image. The only problem we had was with the symbols you mentioned above. We do migrations with scripts inside the image so that the segment's instances are always in sync with the code of the image we load them into.
For big segments, I am not sure if it works well neither. The segment allocates more than 2 times what needed. In DabbleDB I read they had that problem. The segments were too big, that having to allocate 2 or 3 times, crash everything.
Depends on what you think is big. Most of our segments are smaller than 50MB but I have seen larger ones that worked too.
Cheers, Adrian
Cheers
Mariano
We even started to remove part of it in Pharo. And SqueakMap was completely removed.
Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not critical for us.
Cheers, Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
John it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. Now who is using 5.0 ? what are the problem left? I got some glitches like not been able to open two images but this was at the beginning. Now I thought that 5.0 was not officially out. Stef On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote:
Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?
Well 5.0 is still in Alpha. Feedback is slow, so the issue is how to drive acceptance? The problem with the 64bit VM with 32bit images is that all the plugins have to be recompiled. Mind I did do the FreeType one. However I was thinking that we could run the 5.0 VM in 32bit mode and use the existing plugins to minimize impact. On 2010-03-30, at 11:46 PM, Stéphane Ducasse wrote:
John
it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. Now who is using 5.0 ? what are the problem left? I got some glitches like not been able to open two images but this was at the beginning. Now I thought that 5.0 was not officially out.
Stef
On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote:
Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Mar 31, 2010, at 9:25 AM, John M McIntosh wrote:
Well 5.0 is still in Alpha. Feedback is slow, so the issue is how to drive acceptance?
I suggest to release 1.0 with the altest 4er Mac VM, than advacate 5.0 for 1.1. Marcus
The problem with the 64bit VM with 32bit images is that all the plugins have to be recompiled. Mind I did do the FreeType one. However I was thinking that we could run the 5.0 VM in 32bit mode and use the existing plugins to minimize impact.
On 2010-03-30, at 11:46 PM, Stéphane Ducasse wrote:
John
it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. Now who is using 5.0 ? what are the problem left? I got some glitches like not been able to open two images but this was at the beginning. Now I thought that 5.0 was not officially out.
Stef
On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote:
Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On 2010-03-31, at 12:29 AM, Marcus Denker wrote:
I suggest to release 1.0 with the altest 4er Mac VM, than advacate 5.0 for 1.1.
Marcus
Agreeable -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
+1 Stef On Mar 31, 2010, at 9:29 AM, Marcus Denker wrote:
On Mar 31, 2010, at 9:25 AM, John M McIntosh wrote:
Well 5.0 is still in Alpha. Feedback is slow, so the issue is how to drive acceptance?
I suggest to release 1.0 with the altest 4er Mac VM, than advacate 5.0 for 1.1.
Marcus
The problem with the 64bit VM with 32bit images is that all the plugins have to be recompiled. Mind I did do the FreeType one. However I was thinking that we could run the 5.0 VM in 32bit mode and use the existing plugins to minimize impact.
On 2010-03-30, at 11:46 PM, Stéphane Ducasse wrote:
John
it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. Now who is using 5.0 ? what are the problem left? I got some glitches like not been able to open two images but this was at the beginning. Now I thought that 5.0 was not officially out.
Stef
On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote:
Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 31, 2010, at 9:25 33AM, John M McIntosh wrote:
Well 5.0 is still in Alpha. Feedback is slow, so the issue is how to drive acceptance?
The problem with the 64bit VM with 32bit images is that all the plugins have to be recompiled. Mind I did do the FreeType one. However I was thinking that we could run the 5.0 VM in 32bit mode and use the existing plugins to minimize impact.
Here's a little feedback on the building-from-svn part (for rev 193, not sure if you plan on consolidating that with the 5.0 releases or not, in that case just ignore the last part): - MainWindow.xib is included in resources for both PureObjC targets , it is not needed, and causes an error if you try to build without the iPhone libs installed. (i.e. a "vanilla" xcode install) - SqueakOSXAppDelegate.m complains sqSqueakOSXInfoPlistInterface is undeclared, adding #import "sqSqueakOSXInfoPlistInterface.h" fixes it, not sure if you feel that's the approriate place though. - the #error THIS IS BROKEN... labelled code could be written as attached, to work with width/height which are non-multiples of four. (in short, save dividedWidth/Height as floats, as per their definitions, and use the rounded value of end- start coords as width/height instead. ) After that, it still won't work, of course :) It seems the underlying bitmap is not updated when a resize occurs, and there's still a multiple-of-four error somewhere (e.g. my stored window size was 1133x761, but the underlying bitmap for opened window seemed to be 1132x761, which leads to a tilted initial view) Cheers, Henry
Thank you very much for the work. Given your efforts I proceeded to spend a couple of hours again today to resolve the problem. I took a slightly different approach and made a number of changes to properly deal with the window size not working properly when the size is not a multiple of four. . I've checked these changes into the V5 tree. You should check out the current source and see what changed. It does draw the window properly now even when the window size is not a multiple of 4. However there is some work to resolve what to do when the window is in live resize. What happens now is that it appears to display pixels from video memory as it's attempting to resize the window size. I'm not quite sure exactly *why* it's wrong yet. One of the problems is that the window size changes, but the display buffer in squeak doesn't change right away. It's possible we may have to show a snapshot of the screen surface when the resize starts, then update it after the resize terminates. On the other hand the side effect is interesting, as long as it doesn't crash it's not high on the list to fix. On 2010-03-31, at 6:07 AM, Henrik Johansen wrote:
sqSqueakOSXInfoPlistInterface.h
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2010/3/29 Mariano Martinez Peck <marianopeck@gmail.com>
- In the README.TXT we also have to put links for help: squeakvm site, posts like Laurent or Adrain - Gunification - It needs to have a name of PharoXXX. Not squeak. This is VERY confusing for newcomers.
I agree we need to explain better the distinction between the VM and the image. I'm not sure about renaming squeak-vm -> pharo-vm. It's not a fork. I tend to think it will bring higher confusion.
I don't agree. Image you are a new comer. For you, Pharo is Pharo. You probaly have no idea what Squeak is. So...you go to Pharo website, and download the image, and the VM. Imagine when you go to download the VM and it says "SqueakVM". I would say "WTF?????" "WTF is squeak?" I am not saying forking the VM. Just to rename it. Actually, the windows VM has that name: " http://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip" And the same with exupery: " http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip"
OK. So this is one more argument to have a git repository to snapshot VM sources + patches for Pharo. Then the VM build process should produce binaries named pharo / pharovm / pharo.sh for all platforms. I don't know if it's easy, I'll try to take a look.
Maybe you can open a git repository on INRIA servers so we can keep track
of patches + README included in the VM for Pharo. I've used Javier and Levente patches and these are not included in squeak-vm svn. I sent a mail last week on vm-dev but no answers. This way builders can do: git clone git://......squeak-vm cd ..squeak-vm../build ... configure && make && make install. For packagers it would be cool. Developpers can have their own branches and submit patches more easily, add more visibility. With git-svn we can synchronize from official Squeak-VM svn (until they switched to git or another DVCS :)
What do you think ?
I like the idea....but what about the sync with the public/official SVN repo ? how we will be able to merge ? or the GIT repo will be only for patches ?
You can have a git branch synchronized with squeak-vm subversion (see http://progit.org/book/ch8-1.html), a git branch for pharo-vm. Then push regularly changes from squeak-vm branch to pharo-vm branch. Maybe there's a git expert reading this list ? (I'm not one). Laurent Laffont
Cheers
Mariano
Laurent Laffont
Cheers
Mariano
Ok.....but not only plugins. For exaple, if I don't want UTF-8 ?
errr... maybe it's time to ask to the vm-dev list :)
ufff.....what an idiot...thanks! did you already discovered I am a newbie here ? :)
Me too, but a little less every day :)
Laurent Laffont
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, 2010-03-28 at 18:21 -0300, Mariano Martinez Peck wrote:
- It has to be a Standard VM, not Exupery. Exupery without the exupery package, has no sense at all. It is in Pharo download just because of history reasons. Bryce was very helpful and was the first in put closures in the VM. So, we used that. Now, it has no sense anymore.
If you're not using Exupery it should make no difference if you're using an Exupery VM or not. It's just a regular VM with a few small hooks in it. That said, I'd prefer to put my Squeak/Pharo time into Exupery so am very happy that other people are maintaining the general purpose VMs. Bryce
participants (10)
-
Adrian Lienhard -
Alexandre Bergel -
Bryce Kampjes -
Henrik Johansen -
John M McIntosh -
laurent laffont -
Marcus Denker -
Mariano Martinez Peck -
Serge Stinckwich -
Stéphane Ducasse