Hi all.
Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
My reasons are: 1. source control is Monticello. (and if you generate the source tree, the pharo folks can use that to pipe into git--so that sorta-kinda-syncs things up a bit) 2. modification and maintenance is in Squeak. 3. it should be fun. 4. Modular (looking at the CMake generators, it just begs for OOP approach) 5. Each plugin is responsible for its own CMakeLists.txt (i.e. cmake configuration file) ....
whaddya think?
Also, if you are ok with the idea, what do you want it named? Do you want some classes added to VMMaker or do you want something elsewhere?
p.s. I am suffering from a bit of Spring Fever and took the weekend and Monday and most of today off. I am still studying CMaker before I even look at the existing project for Interpreter and I will probably not look at the existing Interpreter CMake project until I go through the exercise of writing my own from scratch (unless I fall flat on my face, then I will take a peek (: )
Would it be simpler to just generate Makefiles from Smalltalk?
On Apr 15, 2014, at 5:08 PM, gettimothy gettimothy@zoho.com wrote:
Hi all.
Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
My reasons are: 1. source control is Monticello. (and if you generate the source tree, the pharo folks can use that to pipe into git--so that sorta-kinda-syncs things up a bit) 2. modification and maintenance is in Squeak. 3. it should be fun. 4. Modular (looking at the CMake generators, it just begs for OOP approach) 5. Each plugin is responsible for its own CMakeLists.txt (i.e. cmake configuration file) ....
whaddya think?
Also, if you are ok with the idea, what do you want it named? Do you want some classes added to VMMaker or do you want something elsewhere?
p.s. I am suffering from a bit of Spring Fever and took the weekend and Monday and most of today off. I am still studying CMaker before I even look at the existing project for Interpreter and I will probably not look at the existing Interpreter CMake project until I go through the exercise of writing my own from scratch (unless I fall flat on my face, then I will take a peek (: )
On 16.04.2014, at 02:08, gettimothy gettimothy@zoho.com wrote:
Hi all.
Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
My reasons are: 1. source control is Monticello. (and if you generate the source tree, the pharo folks can use that to pipe into git--so that sorta-kinda-syncs things up a bit) 2. modification and maintenance is in Squeak. 3. it should be fun. 4. Modular (looking at the CMake generators, it just begs for OOP approach) 5. Each plugin is responsible for its own CMakeLists.txt (i.e. cmake configuration file) ....
whaddya think?
afaik, that is _exactly_ how the CMakeVMMaker works…
[1](blogpost) https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us... [2](filetree package) https://github.com/pharo-project/pharo-vm/tree/master/mc/CMakeVMMaker.packag... [3](some people using it…) http://forum.world.st/Adapting-CMakeVMMaker-to-build-BochsIA32Plugin-td47438...
Best -Tobias
Also, if you are ok with the idea, what do you want it named? Do you want some classes added to VMMaker or do you want something elsewhere?
p.s. I am suffering from a bit of Spring Fever and took the weekend and Monday and most of today off. I am still studying CMaker before I even look at the existing project for Interpreter and I will probably not look at the existing Interpreter CMake project until I go through the exercise of writing my own from scratch (unless I fall flat on my face, then I will take a peek (: )
On Tue, Apr 15, 2014 at 05:08:39PM -0700, gettimothy wrote:
Hi all.
Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
This is exactly the approach of the CMakeVMMaker package (hosted in the VMMaker repository), so please take a close look at that before you do anything new along these lines. There is some very good work that has been done there, and there would be no point in duplicating it.
Also, please take a careful look at Ian Piumarta's CMake procedures in trunk. There is a good reason why Ian chose to organize the build procedures in this manner, and there is also a good reason why he chose to maintain the build scripts in Subversion along with the source code.
The overall organization of Ian's CMake build is more or less this:
- A single CMake script platforms/unix/CMakeLists.txt controls the overall build.
- That script calls INCLUDE to include the instructions for the plugins, the VM modules, and for the main VM.
- The various individual program modules, such as plugins, may have files called config.cmake and build.cmake. These live in the source directories for their respective modules, and provide any module-specific customization needed for configuring or building the module in that directory.
- For the main VM, the build.cmake and config.cmake files are in the platforms/unix/vm directory. These two files control the build of the VM itself.
- There is a unix shell script platforms/unix/cmake/configure that serves as a utility to drive the main platforms/unix/CMakeLists.txt. This is a convenience script that provides a front end to the entire process (for example, it lets you specify --image64 to build a VM for the 64-bit image format).
In order to get the stack interpreter and Cog sources to build in Unix, my expectation is that the config.cmake and build.cmake scripts in platforms/unix/vm will need to be changed to build the necessary sources that Eliot has added to the main VM. In all likelihood, nothing at all will need to be changed in any of the plugin directories, or in any of the VM module directories (such as vm-display-X11 or vm-sound-ALSA).
Dave
Hi,
Is a bit frustrating so I will say it again: CMakeMaker already does that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs some work). Nothing prevents you to copy the pharo flavour and adapt it as squeak flavour. Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
On 16 Apr 2014, at 03:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Apr 15, 2014 at 05:08:39PM -0700, gettimothy wrote:
Hi all.
Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
This is exactly the approach of the CMakeVMMaker package (hosted in the VMMaker repository), so please take a close look at that before you do anything new along these lines. There is some very good work that has been done there, and there would be no point in duplicating it.
Also, please take a careful look at Ian Piumarta's CMake procedures in trunk. There is a good reason why Ian chose to organize the build procedures in this manner, and there is also a good reason why he chose to maintain the build scripts in Subversion along with the source code.
The overall organization of Ian's CMake build is more or less this:
A single CMake script platforms/unix/CMakeLists.txt controls the overall build.
That script calls INCLUDE to include the instructions for the plugins, the
VM modules, and for the main VM.
- The various individual program modules, such as plugins, may have files
called config.cmake and build.cmake. These live in the source directories for their respective modules, and provide any module-specific customization needed for configuring or building the module in that directory.
- For the main VM, the build.cmake and config.cmake files are in the
platforms/unix/vm directory. These two files control the build of the VM itself.
- There is a unix shell script platforms/unix/cmake/configure that serves
as a utility to drive the main platforms/unix/CMakeLists.txt. This is a convenience script that provides a front end to the entire process (for example, it lets you specify --image64 to build a VM for the 64-bit image format).
In order to get the stack interpreter and Cog sources to build in Unix, my expectation is that the config.cmake and build.cmake scripts in platforms/unix/vm will need to be changed to build the necessary sources that Eliot has added to the main VM. In all likelihood, nothing at all will need to be changed in any of the plugin directories, or in any of the VM module directories (such as vm-display-X11 or vm-sound-ALSA).
Dave
2014-04-16 9:42 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Is a bit frustrating so I will say it again: CMakeMaker already does that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs some work). Nothing prevents you to copy the pharo flavour and adapt it as squeak flavour. Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
Thanks Tobias too. Esteban, don't be frustrated, tty must still be considered a noob and is welcome to ask. Once he gathers all the pieces, we'll start converging !
Nicolas
On 16 Apr 2014, at 03:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Apr 15, 2014 at 05:08:39PM -0700, gettimothy wrote:
Hi all.
Unless I am talked out of it , I am going to generate the CMMake
"stuff" from Smalltalk classes similar to the way that VMMaker generates source code.
This is exactly the approach of the CMakeVMMaker package (hosted in the VMMaker repository), so please take a close look at that before you do anything new along these lines. There is some very good work that has been done there, and there would be no point in duplicating it.
Also, please take a careful look at Ian Piumarta's CMake procedures in
trunk.
There is a good reason why Ian chose to organize the build procedures in
this
manner, and there is also a good reason why he chose to maintain the
build
scripts in Subversion along with the source code.
The overall organization of Ian's CMake build is more or less this:
- A single CMake script platforms/unix/CMakeLists.txt controls the
overall build.
- That script calls INCLUDE to include the instructions for the plugins,
the
VM modules, and for the main VM.
- The various individual program modules, such as plugins, may have files
called config.cmake and build.cmake. These live in the source directories for their respective modules, and provide any module-specific
customization
needed for configuring or building the module in that directory.
- For the main VM, the build.cmake and config.cmake files are in the
platforms/unix/vm directory. These two files control the build of the VM itself.
- There is a unix shell script platforms/unix/cmake/configure that serves
as a utility to drive the main platforms/unix/CMakeLists.txt. This is a convenience script that provides a front end to the entire process (for example, it lets you specify --image64 to build a VM for the 64-bit image format).
In order to get the stack interpreter and Cog sources to build in Unix, my expectation is that the config.cmake and build.cmake scripts in platforms/unix/vm will need to be changed to build the necessary sources that Eliot has added to the main VM. In all likelihood, nothing at all will need to be changed in any of the plugin directories, or in any of the VM module directories (such as vm-display-X11 or vm-sound-ALSA).
Dave
Hi Estaban,
>>Is a bit frustrating so I will say it again: CMakeMaker already does that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work). >>Nothing prevents you to copy the pharo flavour and adapt it as squeak flavour. >>Nothing prevents you to do the same for newspeak.
>>cheers, >>Esteban
>>ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
(:
I am still going to take a couple of days to touch all the Commands, Modules and Variables in CMake because it is a useful exercise. When I am done with that, I have saved this thread and I will examine all existing work and get the project done.
cordially,
tty
p.s. thank you all for the heads ups and pointers
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
On 16 Apr 2014, at 18:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote: Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see
https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see
https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
2014-04-16 19:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
>Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
>Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
>Nothing prevents you to do the same for newspeak.
>cheers, >Esteban
>ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see
https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
If the problem is the compiler, or a compielr flag, can the simulator find the problem? My understanding is that the simulator is going to emulate slang, and eventually jitted code. But the slang is AFAICT correct (with another compiler/flags the problem vanishes)...
Nicolas
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
-- best, Eliot
yeah, that script does not fails for me :(
On 16 Apr 2014, at 20:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 19:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote: Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
If the problem is the compiler, or a compielr flag, can the simulator find the problem? My understanding is that the simulator is going to emulate slang, and eventually jitted code. But the slang is AFAICT correct (with another compiler/flags the problem vanishes)...
Nicolas
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
-- best, Eliot
On 17 April 2014 00:59, Esteban Lorenzano estebanlm@gmail.com wrote:
yeah, that script does not fails for me :(
you should have transcript window opened.
it doesn't fails if it closed..
which, btw a good sign where the problem might be hiding - in process switching code.
On 16 Apr 2014, at 20:33, Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 19:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote:
Hi Estaban,
>>Is a bit frustrating so I will say it again: CMakeMaker already does that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work). >>Nothing prevents you to copy the pharo flavour and adapt it as squeak flavour. >>Nothing prevents you to do the same for newspeak.
>>cheers, >>Esteban
>>ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see
https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
If the problem is the compiler, or a compielr flag, can the simulator find the problem? My understanding is that the simulator is going to emulate slang, and eventually jitted code. But the slang is AFAICT correct (with another compiler/flags the problem vanishes)...
Nicolas
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
-- best, Eliot
On 17 Apr 2014, at 02:09, Igor Stasenko siguctua@gmail.com wrote:
On 17 April 2014 00:59, Esteban Lorenzano estebanlm@gmail.com wrote:
yeah, that script does not fails for me :(
you should have transcript window opened. it doesn't fails if it closed..
ha! there you go… hello my not-so-missed bug-friend! :) now I see it :P
which, btw a good sign where the problem might be hiding - in process switching code.
On 16 Apr 2014, at 20:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 19:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote: Hi Estaban,
Is a bit frustrating so I will say it again: CMakeMaker already does
that. And it does it for *any* vm flavour (we are generating pharovm because that’s what we are using, but the builders for cog, stack and even interpreter are there, and working… bah the interpreter version needs >>some work).
Nothing prevents you to copy the pharo flavour and adapt it as
squeak flavour.
Nothing prevents you to do the same for newspeak.
cheers, Esteban
ps: Thanks Dave for noticing :)
I did not know that project existed; of course I will start with that and with the existing Interpreter stuff Dave mentioned.
Its is refreshing to know my instincts on how to approach the project where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
If the problem is the compiler, or a compielr flag, can the simulator find the problem? My understanding is that the simulator is going to emulate slang, and eventually jitted code. But the slang is AFAICT correct (with another compiler/flags the problem vanishes)...
Nicolas
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
-- best, Eliot
-- Best regards, Igor Stasenko.
Hi Folks,
I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it. Please note that I am NOT looking for an answer to this specific build issue--I can trace that down and fix it just fine. I merely need a sense of the community's sense of the tools robustness so I can keep that in mind as future issues come up.
I am currently using the source tree from git clone git://gitorious.org/cogvm/blessed.git and running the generator.image in the blessed/image directory that is downloaded via the newImage.sh script.
It seems to run really well except I am getting what looks like a basic error
[ 95%] Building C object CMakeFiles/CogVM.dir/home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c.o In file included from /home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c:41:0: /home/wm/usr/src/smalltalk/blessed/platforms/Cross/vm/sqSCCSVersion.h:17:54: fatal error: vmVersionInfo.h: No such file or directory #include "vmVersionInfo.h" // defines REVISION_STRING
when running this script:
CogUnixConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "generateForDebug;" generateSources; generate.
That missing #include threw up a red-flag for me (which I have not investigated) that made me question the tools maturity.
FWIW, I *really* like the approach of this tool. Having the configurations in their own objects makes perfect sense to me and it is nice to not have to deal with #IFNDEF foo #DEF bar #UNLESS oops #THEN hack #ENDIF stuff.
The blessed/image/newImage.sh is a nice feature as well.
thanks for your time.
tty
This repository is largely outdated and no longer maintained. The official Pharo Cog VM is now hosted on github:
https://github.com/pharo-project/pharo-vm
I feel sorry that you wasted your time on it :/
On 23 April 2014 18:24, gettimothy gettimothy@zoho.com wrote:
Hi Folks,
I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it. Please note that I am NOT looking for an answer to this specific build issue--I can trace that down and fix it just fine. I merely need a sense of the community's sense of the tools robustness so I can keep that in mind as future issues come up.
I am currently using the source tree from git clone git:// gitorious.org/cogvm/blessed.git and running the generator.image in the blessed/image directory that is downloaded via the newImage.sh script.
It seems to run really well except I am getting what looks like a basic error
[ 95%] Building C object CMakeFiles/CogVM.dir/home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c.o In file included from /home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c:41:0: /home/wm/usr/src/smalltalk/blessed/platforms/Cross/vm/sqSCCSVersion.h:17:54: fatal error: vmVersionInfo.h: No such file or directory #include "vmVersionInfo.h" // defines REVISION_STRING
when running this script:
CogUnixConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "generateForDebug;" generateSources; generate.
That missing #include threw up a red-flag for me (which I have not investigated) that made me question the tools maturity.
FWIW, I *really* like the approach of this tool. Having the configurations in their own objects makes perfect sense to me and it is nice to not have to deal with #IFNDEF foo #DEF bar #UNLESS oops #THEN hack #ENDIF stuff.
The blessed/image/newImage.sh is a nice feature as well.
thanks for your time.
tty
Hi Igor:
On 23 Apr 2014, at 18:31, Igor Stasenko siguctua@gmail.com wrote:
I am currently using the source tree from git clone git://gitorious.org/cogvm/blessed.git
Could we just kill the repo? Or, set up a cronjob to push the changes from github?
It’s not the first time someone wasted time because of this confusion.
Best regards Stefan
On 23 April 2014 20:03, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi Igor:
On 23 Apr 2014, at 18:31, Igor Stasenko siguctua@gmail.com wrote:
I am currently using the source tree from git clone git://
gitorious.org/cogvm/blessed.git
Could we just kill the repo? Or, set up a cronjob to push the changes from github?
It’s not the first time someone wasted time because of this confusion.
i guess it should be noted somewhere that it is outdated. killing it not
really possible, since there's many forks created by different users and only they has rights to administer those.
And it is written there already: https://gitorious.org/cogvm
WARNING: This project is NOT mantained here anymore. Please go to: https://github.com/pharo-project/pharo-vm
Best regards
Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Hi Igor:
On 23 Apr 2014, at 22:16, Igor Stasenko siguctua@gmail.com wrote:
WARNING: This project is NOT mantained here anymore. Please go to: https://github.com/pharo-project/pharo-vm
Obviously, people do not read ;)
How about one last commit, the removes everything and places a README with the content:
“””
WARNING: This project is NOT mantained here anymore. Please go to: https://github.com/pharo-project/pharo-vm
“”"
Then, even the people that don’t read will notice it once they cloned the repo.
Best regards Stefan
On Wed, Apr 23, 2014 at 1:35 PM, Stefan Marr smalltalk@stefan-marr.dewrote:
Hi Igor:
On 23 Apr 2014, at 22:16, Igor Stasenko siguctua@gmail.com wrote:
WARNING: This project is NOT mantained here anymore. Please go to: https://github.com/pharo-project/pharo-vm
Obviously, people do not read ;)
How about one last commit, the removes everything and places a README with the content:
“””
WARNING: This project is NOT mantained here anymore. Please go to: https://github.com/pharo-project/pharo-vm
“”"
Then, even the people that don’t read will notice it once they cloned the repo.
+1!
Best regards Stefan
-- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
I took the liberty of modifying the class comment and pushing the change live.
Cordially,
tty
On 23-04-2014, at 9:24 AM, gettimothy gettimothy@zoho.com wrote:
Hi Folks,
I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it.
It’s great that you’re digging into this but do remember one of the key points is that the end result must satisfy Ian P so that it is accepted into the squeakvm.org build tree. Do make sure to contact him as part of your research.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Money can't buy love. But it CAN rent a very close imitation.
Hi Tim.
I will be sure to do so.
---- On Wed, 23 Apr 2014 10:05:11 -0700 tim Rowledge<tim@rowledge.org> wrote ----
On 23-04-2014, at 9:24 AM, gettimothy <gettimothy@zoho.com> wrote:
> Hi Folks, > > I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it.
It’s great that you’re digging into this but do remember one of the key points is that the end result must satisfy Ian P so that it is accepted into the squeakvm.org build tree. Do make sure to contact him as part of your research.
tim
hi,
you are having two problems (one depending on the other).
1) you are using an old version. That branch was moved to http://github.com/pharo-project/pharo-vm like more than a year ago… there the scripts are outdated. 2) in your version, before execute sh build.sh, you need to execute (in “build" dir): ../script[I really do not remember the subdir name]/extract-commit-info.sh
that should generate the vmVersionInfo.h file
but well… I highly recommend you to use the correct branch before continue.
cheers, Esteban
On 23 Apr 2014, at 18:24, gettimothy gettimothy@zoho.com wrote:
Hi Folks,
I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it. Please note that I am NOT looking for an answer to this specific build issue--I can trace that down and fix it just fine. I merely need a sense of the community's sense of the tools robustness so I can keep that in mind as future issues come up.
I am currently using the source tree from git clone git://gitorious.org/cogvm/blessed.git and running the generator.image in the blessed/image directory that is downloaded via the newImage.sh script.
It seems to run really well except I am getting what looks like a basic error
[ 95%] Building C object CMakeFiles/CogVM.dir/home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c.o In file included from /home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c:41:0: /home/wm/usr/src/smalltalk/blessed/platforms/Cross/vm/sqSCCSVersion.h:17:54: fatal error: vmVersionInfo.h: No such file or directory #include "vmVersionInfo.h" // defines REVISION_STRING
when running this script:
CogUnixConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "generateForDebug;" generateSources; generate.
That missing #include threw up a red-flag for me (which I have not investigated) that made me question the tools maturity.
FWIW, I *really* like the approach of this tool. Having the configurations in their own objects makes perfect sense to me and it is nice to not have to deal with #IFNDEF foo #DEF bar #UNLESS oops #THEN hack #ENDIF stuff.
The blessed/image/newImage.sh is a nice feature as well.
thanks for your time.
tty
he, I answered before getting the full thread. But well, the idea is there :) I support the last commit idea :)
cheers, Esteban
On 24 Apr 2014, at 01:53, Esteban Lorenzano estebanlm@gmail.com wrote:
hi,
you are having two problems (one depending on the other).
- you are using an old version. That branch was moved to http://github.com/pharo-project/pharo-vm like more than a year ago… there the scripts are outdated.
- in your version, before execute sh build.sh, you need to execute (in “build" dir): ../script[I really do not remember the subdir name]/extract-commit-info.sh
that should generate the vmVersionInfo.h file
but well… I highly recommend you to use the correct branch before continue.
cheers, Esteban
On 23 Apr 2014, at 18:24, gettimothy gettimothy@zoho.com wrote:
Hi Folks,
I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it. Please note that I am NOT looking for an answer to this specific build issue--I can trace that down and fix it just fine. I merely need a sense of the community's sense of the tools robustness so I can keep that in mind as future issues come up.
I am currently using the source tree from git clone git://gitorious.org/cogvm/blessed.git and running the generator.image in the blessed/image directory that is downloaded via the newImage.sh script.
It seems to run really well except I am getting what looks like a basic error
[ 95%] Building C object CMakeFiles/CogVM.dir/home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c.o In file included from /home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c:41:0: /home/wm/usr/src/smalltalk/blessed/platforms/Cross/vm/sqSCCSVersion.h:17:54: fatal error: vmVersionInfo.h: No such file or directory #include "vmVersionInfo.h" // defines REVISION_STRING
when running this script:
CogUnixConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "generateForDebug;" generateSources; generate.
That missing #include threw up a red-flag for me (which I have not investigated) that made me question the tools maturity.
FWIW, I *really* like the approach of this tool. Having the configurations in their own objects makes perfect sense to me and it is nice to not have to deal with #IFNDEF foo #DEF bar #UNLESS oops #THEN hack #ENDIF stuff.
The blessed/image/newImage.sh is a nice feature as well.
thanks for your time.
tty
Hi Nicolas,
On Apr 16, 2014, at 11:33 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 19:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
On 16 Apr 2014, at 18:33, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2014-04-16 14:38 GMT+02:00 Göran Krampe goran@krampe.se:
Hey!
On 04/16/2014 01:22 PM, gettimothy wrote: > Hi Estaban, > > > >>Is a bit frustrating so I will say it again: CMakeMaker already does > that. And it does it for *any* vm flavour (we are generating pharovm > because that’s what we are using, but the builders for cog, stack and > even interpreter are there, and working… bah the interpreter version > needs >>some work). > >>Nothing prevents you to copy the pharo flavour and adapt it as > squeak flavour. > >>Nothing prevents you to do the same for newspeak. > > >>cheers, > >>Esteban > > >>ps: Thanks Dave for noticing :) > > I did not know that project existed; of course I will start with that > and with the existing Interpreter stuff Dave mentioned. > > Its is refreshing to know my instincts on how to approach the project > where correct! Heck, we even came up with the same name for it!
Just wanted to mention that at 3DICC we are in the process of moving over to the Pharo build system for our client side (OSX and Windows) VMs.
Just a reflection: It was quite easy to get started, finding a proper place to add 3DICC subclasses, adding in methods for our plugins etc. I got distracted by other things but now I am picking up our OSX build again so soon we should be using it for real.
And also, it builds fine with clang! Thanks Esteban :)
regards, Göran
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-...
that’s a real strange case, that does not happens all the time (in fact, that’s one of the problems we have: it is hard to have a reproducible case),
For me, the ssnippet from Stephan Eggermont works reliably well (I mean allways fails in official 3.0 distribution for MacOSX )
1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
When Transcript is opened, I never reached iteration 1000 on my mac with official VM. There's always an Integer that does not understand reversed in my way.
Hence to get a rep[roducible case, that you could even look at in the Simulator, merely evaluate
Smalltalk snapshot: true andQuit: true. 1 to: 1000 do: [ :i | | string | Transcript show: 'Iteration '; show: i; cr. 1 timesRepeat: [ (string := String new: 1000 withAll: $a) reversed. ]. ].
and when you start-up the image it should crash with no user intervention. Voila, a reproducible case...
If the problem is the compiler, or a compielr flag, can the simulator find the problem? My understanding is that the simulator is going to emulate slang, and eventually jitted code. But the slang is AFAICT correct (with another compiler/flags the problem vanishes)...
Ah, you're probably right. That said, I did find and fix a register usage bug in the simulator recently that affected the store check machine code in Sour but not in classic ObjectMemory. I still think it's a) worth-while trying to get it to crash from start-up without user input (for repeatability) and b) running it in the simulator just to check. It at least tells you whether the bug is in VM code or in the way it's compiled.
Eliot (phone)
Nicolas
Either we are back to disecting correct set of gcc/clang flags Or we shall revert to an older gcc (4.2.1 works for me OSX 10.6.8 Xcode 3.2.6)
Nicolas
-- best, Eliot
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
David Ungar -
Eliot Miranda -
Esteban Lorenzano -
gettimothy -
Göran Krampe -
Igor Stasenko -
Nicolas Cellier -
Stefan Marr -
tim Rowledge -
Tobias Pape