32 bits and 64 bits VM
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it. Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3. Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX? Hilaire -- Dr. Geo http://drgeo.eu
Hello, The work to port Pharo to 64 bits has started. The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port. Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed. At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM. Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits. At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM. Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning. Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know. I don't know about the working keypad. Perhaps someone more aware could help. 2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Hilaire
-- Dr. Geo http://drgeo.eu
For me this are good news. Thank you for your work. Cheers. Uko On 14 May 2014, at 21:43, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
The work to port Pharo to 64 bits has started.
The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port.
Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed.
At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM.
Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits.
At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM.
Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning.
Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know.
I don't know about the working keypad. Perhaps someone more aware could help.
2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com>: Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Hilaire
-- Dr. Geo http://drgeo.eu
On Wed, May 14, 2014 at 9:43 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hello,
The work to port Pharo to 64 bits has started.
The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port.
Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed.
At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM.
Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits.
At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM.
Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning.
Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know.
Keypad works on my linux build. There was a lost commit somewhere and I fwded the file to Esteban for integration. Phil
I don't know about the working keypad. Perhaps someone more aware could help.
2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com> :
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Hilaire
-- Dr. Geo http://drgeo.eu
On 14 May 2014, at 22:28, phil@highoctane.be wrote:
On Wed, May 14, 2014 at 9:43 PM, Clément Bera <bera.clement@gmail.com> wrote: Hello,
The work to port Pharo to 64 bits has started.
The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port.
Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed.
At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM.
Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits.
At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM.
Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning.
Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know.
Keypad works on my linux build. There was a lost commit somewhere and I fwded the file to Esteban for integration.
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work. Esteban
Phil
I don't know about the working keypad. Perhaps someone more aware could help.
2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com>: Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Hilaire
-- Dr. Geo http://drgeo.eu
Are you sure? Because VM fetched with "curl get.pharo.org/vmLatest | bash" has no working keypad. Hilaire Le 15/05/2014 00:46, Esteban Lorenzano a écrit :
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work.
-- Dr. Geo http://drgeo.eu
damn⦠I was sure. I need to check now :) Esteban On 15 May 2014, at 09:21, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Are you sure? Because VM fetched with "curl get.pharo.org/vmLatest | bash" has no working keypad.
Hilaire
Le 15/05/2014 00:46, Esteban Lorenzano a écrit :
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work.
-- Dr. Geo http://drgeo.eu
On Thu, May 15, 2014 at 10:44 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
damn⦠I was sure. I need to check now :)
Hey, when will we get a CentOS 6.x slave running? ;-) [sorry, couldn't resist. But, truth be told, having a CentOS version helps with credibility when it comes to the enterprise - My clients aren't using Ubuntu for sure, it is CentOS/RHEL with a LooooooongTS) One tiny glitch I noticed is that my PharoVM running on CentOS6 doesn't catches all keys under VMWare Workstation when I run it in a window. When VMWare is fullscreen, there is no issue at all. The keys do work fine in a linux terminal, so this is linked to the PharoVM as well. Phil
Esteban
On 15 May 2014, at 09:21, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Are you sure? Because VM fetched with "curl get.pharo.org/vmLatest | bash" has no working keypad.
Hilaire
Le 15/05/2014 00:46, Esteban Lorenzano a écrit :
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work.
-- Dr. Geo http://drgeo.eu
On 15 May 2014, at 10:52, phil@highoctane.be wrote:
On Thu, May 15, 2014 at 10:44 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote: damn⦠I was sure. I need to check now :)
Hey, when will we get a CentOS 6.x slave running? ;-) [sorry, couldn't resist. But, truth be told, having a CentOS version helps with credibility when it comes to the enterprise - My clients aren't using Ubuntu for sure, it is CentOS/RHEL with a LooooooongTS)
well⦠it will be when I finish :) right now Iâm working on the debian weezy slave (but AFAIK, builds there should work also on centos, Iâm not sure⦠anyway I will check once finished and if not, I will prepare the centos slave). Esteban
One tiny glitch I noticed is that my PharoVM running on CentOS6 doesn't catches all keys under VMWare Workstation when I run it in a window. When VMWare is fullscreen, there is no issue at all. The keys do work fine in a linux terminal, so this is linked to the PharoVM as well.
Phil
Esteban
On 15 May 2014, at 09:21, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Are you sure? Because VM fetched with "curl get.pharo.org/vmLatest | bash" has no working keypad.
Hilaire
Le 15/05/2014 00:46, Esteban Lorenzano a écrit :
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work.
-- Dr. Geo http://drgeo.eu
so yes⦠I integrated the fix, created a pull request, waited until validation⦠and then I forget to merge :S it should be in process to build now. Esteban On 15 May 2014, at 10:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:
damn⦠I was sure. I need to check now :)
Esteban
On 15 May 2014, at 09:21, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Are you sure? Because VM fetched with "curl get.pharo.org/vmLatest | bash" has no working keypad.
Hilaire
Le 15/05/2014 00:46, Esteban Lorenzano a écrit :
and is integrated but still not promoted to stable (I think it will be next week). In the mean time, vmLatest will work.
-- Dr. Geo http://drgeo.eu
Great. As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)? Hilaire Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
so yes⦠I integrated the fix, created a pull request, waited until validation⦠and then I forget to merge :S it should be in process to build now.
-- Dr. Geo http://drgeo.eu
Le 15 mai 2014 18:49, "Hilaire Fernandes" <hilaire.fernandes@gmail.com> a écrit :
Great.
As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)?
We may want to have a statically linked version...
Hilaire
Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
so yes⦠I integrated the fix, created a pull request, waited until validation⦠and then I forget to merge :S it should be in process to build now.
-- Dr. Geo http://drgeo.eu
On 15 May 2014, at 18:46, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Great.
As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)?
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history: - you need a 64bits image (so trace, export, etc.) - you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all) Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm. Now. In the agenda for this year is to work on a 64bits spur version. If everything is fine and the stars align properly, it will be ready around christmas. Esteban
Hilaire
Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
so yes⦠I integrated the fix, created a pull request, waited until validation⦠and then I forget to merge :S it should be in process to build now.
-- Dr. Geo http://drgeo.eu
On Fri, May 16, 2014 at 10:20 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On 15 May 2014, at 18:46, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Great.
As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)?
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history:
- you need a 64bits image (so trace, export, etc.)
ImageTracers are intriguing to me :-) Is this in some way relatable to Oz? What's that project doing now? It was very interesting/useful. Guille?
- you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all)
And... * 64-bit aware hashing functions as the current ones are 32-bit centric. So, not so trivial I'd say. (what's the plan?) * special care of the Float which will be directly in a 64 bit "oop" - I guess we'll face some fun here. Especially with the float plugin. As a side note, I see that http://www.mpfr.org/ is supported by INRIA. WTF aren't we considering this ? LGPL and INRIA may help getting some special thing for Pharo. Phil
Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm.
Now. In the agenda for this year is to work on a 64bits spur version. If everything is fine and the stars align properly, it will be ready around christmas.
Esteban
Hilaire
Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
so yes⦠I integrated the fix, created a pull request, waited until
validation⦠and then I forget to merge :S
it should be in process to build now.
-- Dr. Geo http://drgeo.eu
On 16 May 2014, at 10:27, phil@highoctane.be wrote:
On Fri, May 16, 2014 at 10:20 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 May 2014, at 18:46, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Great.
As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)?
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history:
- you need a 64bits image (so trace, export, etc.)
ImageTracers are intriguing to me :-) Is this in some way relatable to Oz? What's that project doing now? It was very interesting/useful. Guille?
- you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all)
And...
* 64-bit aware hashing functions as the current ones are 32-bit centric. So, not so trivial I'd say. (what's the plan?)
* special care of the Float which will be directly in a 64 bit "oop" - I guess we'll face some fun here. Especially with the float plugin.
yes, the plan is to introduce SmallFloat, etc. So, in summary: a lot of work :)
As a side note, I see that http://www.mpfr.org/ is supported by INRIA. WTF aren't we considering this ? LGPL and INRIA may help getting some special thing for Pharo.
Phil
Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm.
Now. In the agenda for this year is to work on a 64bits spur version. If everything is fine and the stars align properly, it will be ready around christmas.
Esteban
Hilaire
Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
so yes⦠I integrated the fix, created a pull request, waited until validation⦠and then I forget to merge :S it should be in process to build now.
-- Dr. Geo http://drgeo.eu
* 64-bit aware hashing functions as the current ones are 32-bit centric.
This issue might not be the most urgent because the 32 bit hash functions should be sufficient to deal with at least moderately sized 64 bit images. But how much stuff would you have to allocate before seeing a problem? Suppose object headers are 16 bytes and your hash functions are producing 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance variables and zero byte data is kind of silly, so we put in at least one instance variable making those objects at least 24 bytes. Then you also need a hashed collection with a single table large enough to hold all those objects (ignoring e.g. hash buckets), the load factor of which will be kept at 80%. So... 24 * 2^28 * 4 // 5 + (2^28 * 8) => about 7gb So, the current hash functions should be fine for images up to 7gb in size, and probably much larger than that because 7gb is the rock bottom low estimate. Probably one might hash strings or other objects with more data than 8 bytes. In that case, the low bound in that case will be higher. Andres.
On Fri, May 16, 2014 at 12:38 PM, Andres Valloud < avalloud@smalltalk.comcastbiz.net> wrote:
* 64-bit aware hashing functions as the current ones are 32-bit centric.
This issue might not be the most urgent because the 32 bit hash functions should be sufficient to deal with at least moderately sized 64 bit images. But how much stuff would you have to allocate before seeing a problem?
Suppose object headers are 16 bytes and your hash functions are producing 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance variables and zero byte data is kind of silly, so we put in at least one instance variable making those objects at least 24 bytes. Then you also need a hashed collection with a single table large enough to hold all those objects (ignoring e.g. hash buckets), the load factor of which will be kept at 80%. So...
24 * 2^28 * 4 // 5 + (2^28 * 8) => about 7gb
So, the current hash functions should be fine for images up to 7gb in size, and probably much larger than that because 7gb is the rock bottom low estimate. Probably one might hash strings or other objects with more data than 8 bytes. In that case, the low bound in that case will be higher.
Thanks for this, always enlightening. Phil
Andres.
the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say: ldd squeakvm Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a). Pharo 2 does not work as this vm is too old. Where am I wrong? Hilaire Le 16/05/2014 10:20, Esteban Lorenzano a écrit :
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history:
-- Dr. Geo http://drgeo.eu
Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well. http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-sta... (not my work at all - just sharing). -cbc On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say:
ldd squeakvm
Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a).
Pharo 2 does not work as this vm is too old.
Where am I wrong?
Hilaire
Le 16/05/2014 10:20, Esteban Lorenzano a écrit :
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history:
-- Dr. Geo http://drgeo.eu
I wonder how. AFAIK different length of word will warranty that you cannot use most of the plugins (in the case you actually can compile the vm without made any change). I know Dave made the interpreter vm compilable in 64bits, with a flag or something. But that not talks about the plugins (FFI, in particular, I do not think will work). For compiling the stack/cog there are other problems, I think. I may be wrong, but even the StackVM will have some problems because registers change in 64bits. ⦠or Iâm having wrong assumptions, and it is easily feasible, but I do not think so. Esteban On 16 May 2014, at 16:31, Chris Cunningham <cunningham.cb@gmail.com> wrote:
Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well. http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-sta... (not my work at all - just sharing).
-cbc
On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote: the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say:
ldd squeakvm
Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a).
Pharo 2 does not work as this vm is too old.
Where am I wrong?
Hilaire
Le 16/05/2014 10:20, Esteban Lorenzano a écrit :
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits⦠thatâs another very different history:
-- Dr. Geo http://drgeo.eu
On Fri, May 16, 2014 at 10:20:47AM +0200, Esteban Lorenzano wrote:
On 15 May 2014, at 18:46, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Great.
As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)?
I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits? that?s another very different history:
- you need a 64bits image (so trace, export, etc.) - you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all)
Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm.
It's experimental 64 bit image is not really all that experimental any more, although Ian still labels it as such on squeakvm.org/unix. A compiled VM is available there. Building it from source is just a matter of specifying --image64 in the configure step, then doing a make. Up to date Squeak trunk images in 64-bit format are traced daily at http://build.squeak.org/job/Squeak%2064-bit%20image/ Dave
Is your build done against not too recent libc et al. ? If so I will be interested to have an archive of it. Thanks Le 14/05/2014 22:28, phil@highoctane.be a écrit :
Keypad works on my linux build. There was a lost commit somewhere and I fwded the file to Esteban for integration.
-- Dr. Geo http://drgeo.eu
On Thu, May 15, 2014 at 9:08 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Is your build done against not too recent libc et al. ? If so I will be interested to have an archive of it.
I've sent you a dropbox link. The thing is uploading now. Tell me how it works. Phil
Thanks
Le 14/05/2014 22:28, phil@highoctane.be a écrit :
Keypad works on my linux build. There was a lost commit somewhere and I fwded the file to Esteban for integration.
-- Dr. Geo http://drgeo.eu
May be I was not clear. I just mean VM compiled on a 64 bits architecture, not porting to 64bits architecture. I remember years ago, a friend, without knowledge on Squeakvm, told me he compiled it on its 64bits host. Was he wrong somewhere? Hilaire Le 14/05/2014 21:43, Clément Bera a écrit :
The work to port Pharo to 64 bits has started.
-- Dr. Geo http://drgeo.eu
Hilaire, Am 14.05.2014 um 21:08 schrieb Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
ubuntu 14.04 changed to way catalogs are loaded. i386 is not included by default. Please try sudo dpkg --add-architecture i386 and then apt-get update and then try to install again. I noticed that a few weeks before, told it Damien and he immediately put it on the website to prevent exactly your situation. Please reconsider looking at http://www.pharo-project.org/pharo-download/ubuntu and tell me if it is working. Norbert
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Hilaire
-- Dr. Geo http://drgeo.eu
On Wed, May 14, 2014 at 12:08 PM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it.
Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3.
Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX?
Mac OS X handles the situation. 32-bits requires no special installation or support. They use their "fat binary" scheme to provide both 32-bit and 64-bit versions of libraries in the same file: McStalker.image$ file /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa: Mach-O universal binary with 3 architectures /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture i386): Mach-O dynamically linked shared library i386 /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Hilaire
-- Dr. Geo http://drgeo.eu
-- best, Eliot
On Wed, May 14, 2014 at 9:08 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working
Following these simple instructions would have fixed the problem in 2 minutes: http://www.pharo-project.org/pharo-download/ubuntu I run the exact same OS and Pharo works perfectly. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
I know for years[1], only solve partially, on some Linux distribution, not really user friendly, support of this solution may change over making installation of 32bits libs even more complicated for average user. Now my question was related to 64bits, and I am really curious about this 64bits squeakvm compiled for Debian AMD64 Le 16/05/2014 18:17, Damien Cassou a écrit :
On Wed, May 14, 2014 at 9:08 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working
Following these simple instructions would have fixed the problem in 2 minutes: http://www.pharo-project.org/pharo-download/ubuntu
I run the exact same OS and Pharo works perfectly.
[1] http://www.drgeo.eu/community/faq#TOC-Can-I-run-it-in-my-Linux-64-bits-host- -- Dr. Geo http://drgeo.eu
On Fri, May 16, 2014 at 7:27 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
I know for years[1], only solve partially, on some Linux distribution, not really user friendly, support of this solution may change over making installation of 32bits libs even more complicated for average user.
the PPA I have created hides all these details. You just have to install the pharo-vm-desktop package and dependencies will follow. It works on both 32bits and 64bits. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Definitely helpful for developer but not for user of an application developed with Pharo. I know I am probably the only one facing this situation, developing desktop applications with Pharo but VM packages does not solve my problem. Indeed, when releasing DrGeo (and iStoa) to the public I have to provide a VM: I don't know the target linux system nor its version. Hilaire Le 19/05/2014 17:26, Damien Cassou a écrit :
the PPA I have created hides all these details. You just have to install the pharo-vm-desktop package and dependencies will follow. It works on both 32bits and 64bits.
-- Dr. Geo http://drgeo.eu
On Mon, May 19, 2014 at 5:49 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Indeed, when releasing DrGeo (and iStoa) to the public I have to provide a VM: I don't know the target linux system nor its version.
on Ubuntu, I can only recommend to use the PPA system. I do that for Phratch, Pillar and Launcher. I'm simplifying the infrastructure to facilitate the creation of Pharo-based end-user applications on Ubuntu. But it already works. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
For me shipping the VM with the application eases the installation by the user and the production of release. The alternative will be to build a .debian package of Drgeo with only the image, then do the same for each ubuntu version (the two last ubuntu LTS have different approach for 32 bits compatibilty, so debian installation script need to be different). Of course, work need to be duplicated for the different Linux systems, probably the most popular only, but still will close the door to distribution I do not provide package. I just can't cope with that. Hilaire Le 19/05/2014 17:52, Damien Cassou a écrit :
On Mon, May 19, 2014 at 5:49 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Indeed, when releasing DrGeo (and iStoa) to the public I have to provide a VM: I don't know the target linux system nor its version.
on Ubuntu, I can only recommend to use the PPA system. I do that for Phratch, Pillar and Launcher. I'm simplifying the infrastructure to facilitate the creation of Pharo-based end-user applications on Ubuntu. But it already works.
-- Dr. Geo http://drgeo.eu
2014-05-19 17:00 GMT+01:00 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
For me shipping the VM with the application eases the installation by the user and the production of release.
Of course, work need to be duplicated for the different Linux systems, probably the most popular only, but still will close the door to distribution I do not provide package. I just can't cope with that.
I hear you ! Cheers, Sergi
Hi Damien, On Mon, May 19, 2014 at 8:26 AM, Damien Cassou <damien.cassou@gmail.com>wrote:
On Fri, May 16, 2014 at 7:27 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
I know for years[1], only solve partially, on some Linux distribution, not really user friendly, support of this solution may change over making installation of 32bits libs even more complicated for average user.
the PPA I have created hides all these details. You just have to install the pharo-vm-desktop package and dependencies will follow. It works on both 32bits and 64bits.
Can you point me to this? I'd like to see if I can use it with my linux installs.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- best, Eliot
On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Can you point me to this? I'd like to see if I can use it with my linux installs.
it works in most of the supported Ubuntu releases: http://www.pharo-project.org/pharo-download/ubuntu -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Am 19.05.2014 um 22:01 schrieb Damien Cassou <damien.cassou@gmail.com>:
On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Can you point me to this? I'd like to see if I can use it with my linux installs.
it works in most of the supported Ubuntu releases: http://www.pharo-project.org/pharo-download/ubuntu
Right! Ich have 20 images running in different versions and everything is working like a breeze. Well, sometimes my code sucks :) Norbert
On Mon, May 19, 2014 at 1:01 PM, Damien Cassou <damien.cassou@gmail.com>wrote:
On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Can you point me to this? I'd like to see if I can use it with my linux installs.
it works in most of the supported Ubuntu releases: http://www.pharo-project.org/pharo-download/ubuntu
Ah, oh. Am I right to think the magic command is "sudo dpkg --add-architecture i386"? If so is there a dpkg command to check if the i386 architecture has been installed? --
Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- best, Eliot
Am 20.05.2014 um 00:01 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, May 19, 2014 at 1:01 PM, Damien Cassou <damien.cassou@gmail.com> wrote: On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Can you point me to this? I'd like to see if I can use it with my linux installs.
it works in most of the supported Ubuntu releases: http://www.pharo-project.org/pharo-download/ubuntu
Ah, oh. Am I right to think the magic command is "sudo dpkg --add-architecture i386"? If so is there a dpkg command to check if the i386 architecture has been installed?
Yes you are right. And the command is $ dpkg --print-foreign-architectures Norbert
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill -- best, Eliot
On 05/19/2014 05:01 PM, Eliot Miranda wrote:
On Mon, May 19, 2014 at 1:01 PM, Damien Cassou <damien.cassou@gmail.com <mailto:damien.cassou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda <eliot.miranda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:eliot.miranda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote: > Can you point me to this? I'd like to see if I can use it with my linux > installs.
it works in most of the supported Ubuntu releases: http://www.pharo-project.org/pharo-download/ubuntu
Ah, oh. Am I right to think the magic command is "sudo dpkg --add-architecture i386"? If so is there a dpkg command to check if the i386 architecture has been installed?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- best, Eliot
I am running Crunchbang #! Linux using the Jessie repositories. Crunchbang is a Debian distribution with only a number of preconfigured items, such as OpenBox, Tint2, etc. to give a nice out of the box Debian experience. The Ubuntu PPAs do not work well or could cause problems for Debian systems. From the pharo-vm GitHub page I downloaded and modified this script to work on my system. It should work on most any 64bit Debian Jessie/Testing and probably Sid/Unstable systems. I am not sure about Wheezy. https://github.com/pharo-project/pharo-vm/blob/master/scripts/setup-ubuntu.s... Download the above and edit. Or copy the below into a file and save. I called mine setup-pharo.sh. Hope this helps. Jimmie dpkg --add-architecture i386 apt-get update # INSTALL BUILD LIBRARIES ====================================================== apt-get --yes install cmake zip bash-completion ruby git xz-utils debhelper devscripts apt-get --yes install libc6-dev:i386 libasound2:i386 libasound2-dev:i386 libasound2-plugins:i386 apt-get --yes install libssl-dev:i386 libssl1.0.0:i386 libfreetype6-dev:i386 libx11-dev:i386 libsm-dev:i386 libice-dev:i386 apt-get --yes install build-essential gcc-multilib g++ # due to https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/949606 we cannot directly install libgl1-mesa-dev:i386 apt-get --yes install libgl1-mesa-dev:i386 libgl1-mesa-glx:i386 #ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so /usr/lib/i386-linux-gnu/libGL.so #ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/mesa/libGL.so
participants (13)
-
Andres Valloud -
Chris Cunningham -
Clément Bera -
Damien Cassou -
David T. Lewis -
Eliot Miranda -
Esteban Lorenzano -
Hilaire Fernandes -
Jimmie Houchin -
Norbert Hartl -
phil＠highoctane.be -
Sergi Reyner -
Yuriy Tymchuk