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 <[hidden email]> wrote:
|
In reply to this post by tty
On 16.04.2014, at 02:08, gettimothy <[hidden email]> 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? > > [1](blogpost) https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/ [2](filetree package) https://github.com/pharo-project/pharo-vm/tree/master/mc/CMakeVMMaker.package [3](some people using it…) http://forum.world.st/Adapting-CMakeVMMaker-to-build-BochsIA32Plugin-td4743813.html 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 (: ) > signature.asc (1K) Download Attachment |
In reply to this post by tty
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 <[hidden email]> 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 <[hidden email]>:
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
|
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 |
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 <[hidden email]>:
BEWARE: it builds fine, but the resulting VM behaves weirdly : see https://pharo.fogbugz.com/f/cases/11130/Special-byte-code-sequences-mess-up-the-stack-of-VM 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 <[hidden email]> wrote:
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),
|
2014-04-16 18:48 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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. ]. ]. There's always an Integer that does not understand reversed in my way.
|
On Wed, Apr 16, 2014 at 9:58 AM, Nicolas Cellier <[hidden email]> wrote:
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...
best, Eliot
|
2014-04-16 19:13 GMT+02:00 Eliot Miranda <[hidden email]>:
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
|
yeah, that script does not fails for me :( On 16 Apr 2014, at 20:33, Nicolas Cellier <[hidden email]> wrote:
|
In reply to this post by Nicolas Cellier
Hi Nicolas, On Apr 16, 2014, at 11:33 AM, Nicolas Cellier <[hidden email]> wrote:
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)
|
In reply to this post by EstebanLM
On 17 April 2014 00:59, Esteban Lorenzano <[hidden email]> wrote:
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.
-- Best regards, Igor Stasenko. |
On 17 Apr 2014, at 02:09, Igor Stasenko <[hidden email]> wrote:
ha! there you go… hello my not-so-missed bug-friend! :) now I see it :P
|
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
when running this script:
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 On 23 April 2014 18:24, gettimothy <[hidden email]> wrote:
-- Best regards, Igor Stasenko. |
In reply to this post by tty
On 23-04-2014, at 9:24 AM, gettimothy <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Money can't buy love. But it CAN rent a very close imitation. |
Free forum by Nabble | Edit this page |