Hi:
I am a bit lost on what the current status with the whole SqueakVM story is today. Do I want the SVN code base, do I want the git repo (the later would be much much more convenient to keep in sync with you...)?
What I would like to do is to generate a consistent code base for the VM (preferable the standard non-Cog non-Stack interpreter). My target platforms are iOS (MacOSX would be nice, but iPhone/iPad are the primary target) and Unix (MacOSX,Linux). My goal is to get all the RoarVM plugin code and the other stuff that is not related to the VM in sync with the Squeak VM.
So, how do I do that? More precisely, which would be the right VMMaker version for the correct code repository version?
I noticed that the SVN contains all the generated code for the iPhone, but it seems to be outdated and out of sync with the rest of the code base.
Thanks a lot Stefan
Hi Stefan, maybe you can follow Mariano's blog, he explain very easily how to get and compile a vm by your self:
http://marianopeck.wordpress.com/
Cheersm Esteban
El 20/04/2011, a las 3:37p.m., Stefan Marr escribió:
Hi:
I am a bit lost on what the current status with the whole SqueakVM story is today. Do I want the SVN code base, do I want the git repo (the later would be much much more convenient to keep in sync with you...)?
What I would like to do is to generate a consistent code base for the VM (preferable the standard non-Cog non-Stack interpreter). My target platforms are iOS (MacOSX would be nice, but iPhone/iPad are the primary target) and Unix (MacOSX,Linux). My goal is to get all the RoarVM plugin code and the other stuff that is not related to the VM in sync with the Squeak VM.
So, how do I do that? More precisely, which would be the right VMMaker version for the correct code repository version?
I noticed that the SVN contains all the generated code for the iPhone, but it seems to be outdated and out of sync with the rest of the code base.
Thanks a lot Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Esteban:
On 20 Apr 2011, at 20:41, Esteban Lorenzano wrote:
Hi Stefan, maybe you can follow Mariano's blog, he explain very easily how to get and compile a vm by your self: http://marianopeck.wordpress.com/
I read the blog, briefly. Perhaps not deeply enough since my questions were not answered.
But, to make it clear: my goal is to bring the platform/plugin code up to date. And, to bring it into a shape which allows us to stay in sync with you guys.
Especially with your work Esteban, since our primary platform for the day to day stuff is OSX.
So, Mariano told me that the git repository does not contain the standard interpreter code anymore, well, that is a pity.
But what about the iPhone/iOS code? Which is the authoritative source for code?
I would like to avoid the implications of Cog/StackVM since there are some changes which would have to be propagated to our VM code, I think. And I don't see the immediate need for that.
I am not so much worried about how to generate the code and these kind of things, since Mariano's blog will probably help me with that. My problem is more basic: Which is the right code to start with.
Thanks Stefan
On Wed, Apr 20, 2011 at 8:37 PM, Stefan Marr squeak@stefan-marr.de wrote:
Hi:
I am a bit lost on what the current status with the whole SqueakVM story is today. Do I want the SVN code base, do I want the git repo (the later would be much much more convenient to keep in sync with you...)?
All I can help is what I wrote here: http://marianopeck.wordpress.com/2011/04/05/first-stop-vms-scm-and-related-s...
What I would like to do is to generate a consistent code base for the VM (preferable the standard non-Cog non-Stack interpreter).
Only CogVMs are in Git, not Interpreter VM.
My target platforms are iOS (MacOSX would be nice, but iPhone/iPad are the primary target) and Unix (MacOSX,Linux). My goal is to get all the RoarVM plugin code and the other stuff that is not related to the VM in sync with the Squeak VM.
So, how do I do that? More precisely, which would be the right VMMaker version for the correct code repository version?
I am not quite sure how to know that with the Interpreter VM, which in fact is one of the problems I commented in the link I send you at the beginning of the post.
I noticed that the SVN contains all the generated code for the iPhone, but it seems to be outdated and out of sync with the rest of the code base.
Sorry, I cannot help there. But if you can live with a StackVM (which if fact I think it may be good for iPhone/iPad), I think all the necessary information you need are explained in this two posts:
part1http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/
part2http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/
Thanks a lot Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Mariano:
On 20 Apr 2011, at 20:47, Mariano Martinez Peck wrote:
Only CogVMs are in Git, not Interpreter VM.
Ok, good to know. Thanks.
Sorry, I cannot help there. But if you can live with a StackVM (which if fact I think it may be good for iPhone/iPad), I think all the necessary information you need are explained in this two posts:
Well, I do not really care about the interpreter VM itself, I just want to avoid unnecessary Cog/StackVM specific changes (like the heartbeat thread). In the end, I want to run on both cores of the iPad, with the RoarVM. That is the goal, and we have a proof of concept that works, but it is an unsustainable mess and needs to get integrated into our mainline of code.
Any hits on which code-base to chose for that are very welcome.
My main platforms I want to run on are Linux, OSX, and iOS. And ideally without any code duplication, since we have to touch some details here and there. Well, and as I said, ideally in a way that I can pull in upstream changes.
Thanks Stefan
On Wed, Apr 20, 2011 at 9:32 PM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Mariano:
On 20 Apr 2011, at 20:47, Mariano Martinez Peck wrote:
Only CogVMs are in Git, not Interpreter VM.
Ok, good to know. Thanks.
Sorry, I cannot help there. But if you can live with a StackVM (which if
fact I think it may be good for iPhone/iPad), I think all the necessary information you need are explained in this two posts: Well, I do not really care about the interpreter VM itself, I just want to avoid unnecessary Cog/StackVM specific changes (like the heartbeat thread). In the end, I want to run on both cores of the iPad, with the RoarVM. That is the goal, and we have a proof of concept that works, but it is an unsustainable mess and needs to get integrated into our mainline of code.
Any hits on which code-base to chose for that are very welcome.
CogVMs' platform code is in GIT AND in SVN cog branch. Interpreter VM is in the trunk sVN. Esteban is the Squeak VM Mac maintainer. If you download the latest code from svn or git and it doesn't work with the latest of VMMaker, send an email, and hopefully Esteban or someone will try to fix it.
My main platforms I want to run on are Linux, OSX, and iOS. And ideally without any code duplication, since we have to touch some details here and there. Well, and as I said, ideally in a way that I can pull in upstream changes.
Thanks Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Mariano:
Here some feedback to your blog posts, since, well, I had several issues with it.
So I did:
$ wget --no-check-certificate http://www.pharo-project.org/pharo-download/unstable-core
which gets me: PharoCore-1.3-13159
Then opening a workspace:
----- Deprecation raiseWarning: false. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load.
(Smalltalk at: #ConfigurationOfCog) project latestVersion load. ---
Bye the way there is a typo on your blog: #latestVersion was originally #la_s_testVersion
Executing the code results in a 'MessageNotUnderstood: AnObsoleteAutoStart class>>addLauncherFirst:'
Ok, just commenting that out and continuing, I run into the next obstacles: No class comments, and your blog posts also do not tell me whether I can just use a plain CocoaIOSCogConfig or whether I have to chose between the JIT or Stack variant. (That might be obvious for you, but it is not)
Ok, next problem:
You customize the following properties:
resourcesDir:'/Users/mariano/Pharo/vm/git/cogVM2/blessed/macbuild/resources'; outputDir: '/Users/mariano/binaries/results';
but they do not seem to exist.
Ok, lets continue without them.
Still undecided what I want, I go with CocoaIOSCogConfig:
CocoaIOSCogStackConfig new srcDir: '/tmp/make-squeak-vm/squeak-src'; platformsDir: '/tmp/make-squeak-vm/from_squeak'; buildDir: '/tmp/make-squeak-vm/build'; generateSources; generate.
That fails with a very inappropriate error: primCreateDirectory: failed.
*sigh* lets see what's going on:
self primCreateDirectory: (self fullNameFor: localFileName) asVmPathName
inspecting '(self fullNameFor: localFileName) asVmPathName' reveals '/${topDir}' *sigh*
Ok, what ever, I will probably just have to choose the StackConfig then...
And that of course fails too... because the platform directory was not existing. But it fails without reasonable error message and I think it should not fail, because you say it is not actually used, and a quick test reveals it does not matter whether the directory is empty or the actual code is there since the generated code is identical.
Hope that helps ironing out some of the rough edges.
Best regards Stefan
On Fri, Apr 22, 2011 at 1:34 PM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Mariano:
Here some feedback to your blog posts, since, well, I had several issues with it.
So I did:
$ wget --no-check-certificate http://www.pharo-project.org/pharo-download/unstable-core
which gets me: PharoCore-1.3-13159
Then opening a workspace:
Deprecation raiseWarning: false. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load.
(Smalltalk at: #ConfigurationOfCog) project latestVersion load.
Bye the way there is a typo on your blog: #latestVersion was originally #la_s_testVersion
First, thanks a lot for the feedback, is really appreaciated. I've just updated that typo.
Executing the code results in a 'MessageNotUnderstood: AnObsoleteAutoStart class>>addLauncherFirst:'
Yes. This is because thelastes unstable PharoCore was really *unstable*, and hence the problem. This is why in the first post ("Building the VM from scratch using Git and CMakeVMMaker") I say explicitly which pharo image to use (to avoid problems like this one). Pharo guys want to be sure that Hudson can always buid the VM, and if it doesn't (like in this case), be able to detect it and fix it ASAP.
Ok, just commenting that out and continuing, I run into the next obstacles: No class comments,
There are class comment. Not in all classes, but there are. And of course, you are welcome to help also. Just ask access and commit.
and your blog posts also do not tell me whether I can just use a plain CocoaIOSCogConfig or whether I have to chose between the JIT or Stack variant. (That might be obvious for you, but it is not)
In fact, I have explained that several times. Take into account that my blog is a sequence of posts. So...just reading a single post may not be enough, like in this case. I wrote it here: http://marianopeck.wordpress.com/2011/04/02/departure-vm-introduction/ under the section "Cog VM and current status" and here http://marianopeck.wordpress.com/2011/04/16/buildin g-the-vm-second-part/ under thesection "Available CogVMs" and "CMakeVMaker available configurations"
what was not clear in particular ?
Ok, next problem:
You customize the following properties:
resourcesDir:'/Users/mariano/Pharo/vm/git/cogVM2/blessed/macbuild/resources'; outputDir: '/Users/mariano/binaries/results';
but they do not seem to exist.
That was an example just to show that you can customize them and set the directories to whatever place you want. I've added a comment. Anyway, using the "default" behavior (copying the image to a subdirectory of /blessed), you should have not that problem.
Ok, lets continue without them.
Still undecided what I want, I go with CocoaIOSCogConfig:
CocoaIOSCogStackConfig new srcDir: '/tmp/make-squeak-vm/squeak-src'; platformsDir: '/tmp/make-squeak-vm/from_squeak'; buildDir: '/tmp/make-squeak-vm/build'; generateSources; generate.
That fails with a very inappropriate error: primCreateDirectory: failed.
I am not sure why that problem. But this is something expected. In order to customize the paths, you may have such problems. Again, if you don't want to face such problems use the default behavior. And if you find a problem, and have a solution, please submit it.
*sigh* lets see what's going on:
self primCreateDirectory: (self fullNameFor: localFileName) asVmPathName
inspecting '(self fullNameFor: localFileName) asVmPathName' reveals '/${topDir}' *sigh*
Ok, what ever, I will probably just have to choose the StackConfig then...
And that of course fails too... because the platform directory was not existing.
You should point platformsDir: to the platforms directory of the "platform code". That is, in git for example /blessed/platforms or in svn the same /trunk/platforms. I've just added this piece of text "The "platformsDir" *must* map with "platforms" directory that we downloaded with Git, it cannot be choosed randomly. The same with the "resourcesDir" (which in fact is only for Mac). The rest of the directories (src, build and output) are not created by VMMaker nor Git. They are just directories that I have created by my own and I want to use them instead of the default."
But it fails without reasonable error message and I think it should not
fail, because you say it is not actually used, and a quick test reveals it does not matter whether the directory is empty or the actual code is there since the generated code is identical.
Sorry, I did not understand.
Conclusion for your last problems: use the default/recommended approach: copy your image to a subdirectory where you downloaded git. And all paths will be set automatically. The only thing you have to do is XXXConf generateWithSources. And, if you want to use specific paths, then send a clear mail to the mailing lsit, with a way to reproduce it and hopefully someone will fix it.
Cheers
Mariano
Hope that helps ironing out some of the rough edges.
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Mariano:
Sorry, my mail client makes a mess out of your emails, proper quoting seems impossible.
On 22 Apr 2011, at 14:04, Mariano Martinez Peck wrote:
Yes. This is because thelastes unstable PharoCore was really *unstable*, and hence the problem. This is why in the first post ("Building the VM from scratch using Git and CMakeVMMaker") I say explicitly which pharo image to use (to avoid problems like this one). Pharo guys want to be sure that Hudson can always buid the VM, and if it doesn't (like in this case), be able to detect it and fix it ASAP.
That does not help anyone who uses the snipped you provided as a 'summary'. Perhaps it would be a better idea to stick with fixed links for such blog posts.
what was not clear in particular ?
From your posts, I have the feeling that at least the naming scheme is inconsistent. In case CocoaIOSCogConfig is supposed to be an abstract class, then it should tell me that. And it is not clear form the blog post that only *StackConfig and *JitConfig classes are meant to be used. Thats all I am saying.
Ok, next problem:
You customize the following properties:
resourcesDir:'/Users/mariano/Pharo/vm/git/cogVM2/blessed/macbuild/resources'; outputDir: '/Users/mariano/binaries/results';
but they do not seem to exist.
That was an example just to show that you can customize them and set the directories to whatever place you want. I've added a comment. Anyway, using the "default" behavior (copying the image to a subdirectory of /blessed), you should have not that problem.
The thing is, in the version of the code that gets loaded by the snippets your provide there is nothing like #resourcesDir: and #outputDir: in the whole image. Again that is all based on following the snippets in this post: http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/
All I say here is, that the snippets are buggy/inconsistent with respect to what you provide in the post.
Ok, lets continue without them.
Still undecided what I want, I go with CocoaIOSCogConfig:
CocoaIOSCogStackConfig new srcDir: '/tmp/make-squeak-vm/squeak-src'; platformsDir: '/tmp/make-squeak-vm/from_squeak'; buildDir: '/tmp/make-squeak-vm/build'; generateSources; generate.
That fails with a very inappropriate error: primCreateDirectory: failed.
I am not sure why that problem. But this is something expected. In order to customize the paths, you may have such problems. Again, if you don't want to face such problems use the default behavior. And if you find a problem, and have a solution, please submit it.
*sigh* lets see what's going on:
self primCreateDirectory: (self fullNameFor: localFileName) asVmPathName
inspecting '(self fullNameFor: localFileName) asVmPathName' reveals '/${topDir}' *sigh*
Sorry, my fault. The code I was executing did use CocoaIOSCogConfig instead of CocoaIOSCogStackConfig. And then again, it fails with an error which looks like some parameter was not probably setup. However, that is not a problem when the concrete class CocoaIOSCogStackConfig is used.
Again, all I say here is: make CocoaIOSCogConfig abstract and do not fail with strange errors nobody knows where they come from.
Bye the way, my contribution is all this feedback. If you think that is not valuable, and not worth to be considered, well, then it might at least help someone who is googling for advice.
You should point platformsDir: to the platforms directory of the "platform code".
Why? It does not seem to influence what code is generated at all. If there is a technical reason why I can't just point it to a directory where I know that eventually the code will be that belongs there, then please tell me. Otherwise, I think it is a bug, and instead of failing, it should give me a warning and allow me to proceed: Because I know Exactly What I am Doing (TM)
Conclusion for your last problems: use the default/recommended approach: copy your image to a subdirectory where you downloaded git. And all paths will be set automatically. The only thing you have to do is XXXConf generateWithSources. And, if you want to use specific paths, then send a clear mail to the mailing lsit, with a way to reproduce it and hopefully someone will fix it.
Again: why can't I set platformsDir to a path of my chose, which *eventually* will contain the right code? The code generation does not seem to depend on it.
Best regards Stefan
On 22 April 2011 14:33, Stefan Marr squeak@stefan-marr.de wrote:
Again: why can't I set platformsDir to a path of my chose, which *eventually* will contain the right code? The code generation does not seem to depend on it.
good point. The source code generator don't needs platform files. The cmake configuration generation needs only a dir name (so it will generate configs which pointing to that path). But the problem is (if i remember correctly ), that i use platforms path as a default anchor point , starting from which, all other directories are assigned by default.
So, if you set only platform sources path, then you will get:
root:
platforms/..
build:
platforms/../build
src:
platforms/../src
etc.
Therefore, since code generator writes files to src and build dirs, you cannot leave platforms dir unspecified.
But of course, when you specify all output dirs by yourself , then it should not force you to use valid (existing) platforms dir anymore.
On Fri, Apr 22, 2011 at 3:18 PM, Igor Stasenko siguctua@gmail.com wrote:
On 22 April 2011 14:33, Stefan Marr squeak@stefan-marr.de wrote:
Again: why can't I set platformsDir to a path of my chose, which
*eventually* will contain the right code? The code generation does not seem to depend on it.
good point. The source code generator don't needs platform files.
and what are the uses of #platformRootDirectory, #platformDirectory, etc ... why we set #platformRootDirectoryName: in Cmake ?
The cmake configuration generation needs only a dir name (so it will generate configs which pointing to that path). But the problem is (if i remember correctly ), that i use platforms path as a default anchor point , starting from which, all other directories are assigned by default.
no, I think you use topDir instead.
So, if you set only platform sources path, then you will get:
root:
platforms/..
build:
platforms/../build
src:
platforms/../src
etc.
Therefore, since code generator writes files to src and build dirs, you cannot leave platforms dir unspecified.
But of course, when you specify all output dirs by yourself , then it should not force you to use valid (existing) platforms dir anymore.
But it does.
prepareVMMaker
| maker allPlugins |
"In CogVMs (in contrast to Interpreter VM) the generated sources are platform independent, therefore Cross is ok" maker := VMMaker forPlatform: 'Cross'.
maker sourceDirectoryName: self srcDir. maker platformRootDirectoryName: self platformsDir.
I don't understand.
-- Best regards, Igor Stasenko AKA sig.
On 22 April 2011 15:24, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Fri, Apr 22, 2011 at 3:18 PM, Igor Stasenko siguctua@gmail.com wrote:
On 22 April 2011 14:33, Stefan Marr squeak@stefan-marr.de wrote:
Again: why can't I set platformsDir to a path of my chose, which *eventually* will contain the right code? The code generation does not seem to depend on it.
good point. The source code generator don't needs platform files.
and what are the uses of #platformRootDirectory, #platformDirectory, etc ... why we set #platformRootDirectoryName: in Cmake ?
because at some places it needs a directory (instance of FileDirectory) and in another places it needs just its name (hence platformRootDirectory vs platformRootDirectoryName etc)
The cmake configuration generation needs only a dir name (so it will generate configs which pointing to that path). But the problem is (if i remember correctly ), that i use platforms path as a default anchor point , starting from which, all other directories are assigned by default.
no, I think you use topDir instead.
i don't remember exactly :)
So, if you set only platform sources path, then you will get:
root:
platforms/..
build:
platforms/../build
src:
platforms/../src
etc.
Therefore, since code generator writes files to src and build dirs, you cannot leave platforms dir unspecified.
But of course, when you specify all output dirs by yourself , then it should not force you to use valid (existing) platforms dir anymore.
But it does.
prepareVMMaker
| maker allPlugins |
"In CogVMs (in contrast to Interpreter VM) the generated sources are platform independent, therefore Cross is ok" maker := VMMaker forPlatform: 'Cross'.
maker sourceDirectoryName: self srcDir. maker platformRootDirectoryName: self platformsDir.
well, it needs an investigation, why VMMaker needs that dir. Most probably it has no use anymore.
I don't understand.
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
On Fri, Apr 22, 2011 at 2:33 PM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Mariano:
Sorry, my mail client makes a mess out of your emails, proper quoting seems impossible.
On 22 Apr 2011, at 14:04, Mariano Martinez Peck wrote:
Yes. This is because thelastes unstable PharoCore was really *unstable*,
and hence the problem. This is why in the first post ("Building the VM from scratch using Git and CMakeVMMaker") I say explicitly which pharo image to use (to avoid problems like this one).
Pharo guys want to be sure that Hudson can always buid the VM, and if it
doesn't (like in this case), be able to detect it and fix it ASAP. That does not help anyone who uses the snipped you provided as a 'summary'. Perhaps it would be a better idea to stick with fixed links for such blog posts.
Thanks. It is a good idea. Next posts I will use a fixed image.
what was not clear in particular ?
From your posts, I have the feeling that at least the naming scheme is inconsistent.
Yes, it is. I agree.
In case CocoaIOSCogConfig is supposed to be an abstract class, then it should tell me that.
agree
And it is not clear form the blog post that only *StackConfig and *JitConfig classes are meant to be used. Thats all I am saying.
Ahh now I see...Yes true. In addition, cococa configs say *Git* in the name, while the rest say Cog. And some OS have some more debug configs that other ones. There are several things that are inconsistent. All these CMakeVMMaker is all new, and it was done in a very little time. It has improved a lot of things, but still a lot of things can be improved. No doubt about it. As said...any help is more than welcome, even simple things like submitting a class comment.
Ok, next problem:
You customize the following properties:
resourcesDir:'/Users/mariano/Pharo/vm/git/cogVM2/blessed/macbuild/resources';
outputDir: '/Users/mariano/binaries/results';
but they do not seem to exist.
That was an example just to show that you can customize them and set the
directories to whatever place you want.
I've added a comment. Anyway, using the "default" behavior (copying the
image to a subdirectory of /blessed), you should have not that problem. The thing is, in the version of the code that gets loaded by the snippets your provide there is nothing like #resourcesDir: and #outputDir: in the whole image. Again that is all based on following the snippets in this post: http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/
Ahhh good catch. Sorry. It seems the latest version of ConfigurationOfCog points to 1.7, which has an "old" version of CMakeVMMaker that does not include those selectors. Loading the last version of the package CMakeVMMaker should work. In addition, I've just create a ConfigurationOfCog version 1.8 which has the latest VMMaker and CMakeVMMaker package. However, since I tag it as development you have to load it explicitly with:
(ConfigurationOfCog project version: '1.8') load or ConfigurationOfCog projec lastVersion load
All I say here is, that the snippets are buggy/inconsistent with respect to what you provide in the post.
Ok, lets continue without them.
Still undecided what I want, I go with CocoaIOSCogConfig:
CocoaIOSCogStackConfig new srcDir: '/tmp/make-squeak-vm/squeak-src'; platformsDir: '/tmp/make-squeak-vm/from_squeak'; buildDir: '/tmp/make-squeak-vm/build'; generateSources; generate.
That fails with a very inappropriate error: primCreateDirectory: failed.
I am not sure why that problem. But this is something expected. In order
to customize the paths, you may have such problems.
Again, if you don't want to face such problems use the default behavior.
And if you find a problem, and have a solution, please submit it.
*sigh* lets see what's going on:
self primCreateDirectory: (self fullNameFor: localFileName)
asVmPathName
inspecting '(self fullNameFor: localFileName) asVmPathName' reveals
'/${topDir}' *sigh*
Sorry, my fault. The code I was executing did use CocoaIOSCogConfig instead of CocoaIOSCogStackConfig. And then again, it fails with an error which looks like some parameter was not probably setup. However, that is not a problem when the concrete class CocoaIOSCogStackConfig is used.
Good.
Again, all I say here is: make CocoaIOSCogConfig abstract and do not fail with strange errors nobody knows where they come from.
Good. I will try to open a bug ticket for that.
Bye the way, my contribution is all this feedback. If you think that is not valuable, and not worth to be considered, well, then it might at least help someone who is googling for advice.
It is more than valuable. This is why I am answering and updating as much as I can. My time, as yours, and as everybody is limited. So..I will try to do as much as my time let me.
You should point platformsDir: to the platforms directory of the
"platform code". Why? It does not seem to influence what code is generated at all. If there is a technical reason why I can't just point it to a directory where I know that eventually the code will be that belongs there, then please tell me.
I don't know why, probably Dave or someone can tell you (I would create a new thread for that) but it seems that the class VMMaker (the one used to generate the C code), requires the paltforms directory. Check VMMAker #platformRootDirectoryName: aString Why it is needed? i have no idea.
Otherwise, I think it is a bug, and instead of failing, it should give me a warning and allow me to proceed: Because I know Exactly What I am Doing (TM)
Conclusion for your last problems: use the default/recommended approach:
copy your image to a subdirectory where you downloaded git. And all paths will be set automatically. The only thing you have to do is XXXConf generateWithSources.
And, if you want to use specific paths, then send a clear mail to the
mailing lsit, with a way to reproduce it and hopefully someone will fix it. Again: why can't I set platformsDir to a path of my chose, which *eventually* will contain the right code? The code generation does not seem to depend on it.
Maybe you are right, I don't know. So...you are saying that sending the #platformRootDirectoryName: from CMakeVMMaker is not necessary ? I would love not to depend in the "platforms" directory while generating sources.
Best regards,
mariano
Best regards
Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Wed, Apr 20, 2011 at 08:37:05PM +0200, Stefan Marr wrote:
Hi:
I am a bit lost on what the current status with the whole SqueakVM story is today. Do I want the SVN code base, do I want the git repo (the later would be much much more convenient to keep in sync with you...)?
What I would like to do is to generate a consistent code base for the VM (preferable the standard non-Cog non-Stack interpreter). My target platforms are iOS (MacOSX would be nice, but iPhone/iPad are the primary target) and Unix (MacOSX,Linux). My goal is to get all the RoarVM plugin code and the other stuff that is not related to the VM in sync with the Squeak VM.
So, how do I do that? More precisely, which would be the right VMMaker version for the correct code repository version?
For the standard interpreter VM, use the latest platforms sources from Subversion www.squeakvm.org (currently at revision level 2378) and use VMMaker from SqueakSource (http://www.squeaksource.com/VMMaker/VMMaker-dtl.227.mcz as of this writing).
Esteban is the maintainer of the iOS and Mac platforms, so follow his guidance there.
At present, Cog is built with its own branch of the VMMaker package and its own branch of the platform sources. If you are building Cog and Stack VMs, you should focus on those branches, and if you are building standard interpreter VMs you should use the main branches.
In addition to the Cog development, Igor is heading up some very active work on cross platform, automated build systems. That work as well as the Cog development are making use of the git repository, which mirrors the SVN repository at squeakvm.org but which presumably will contain new and different things as well (development is quite active). Nevertheless, you can safely rely on SVN at squeakvm.org as the canonical repository if your work is based on the standard interpreter VM.
I noticed that the SVN contains all the generated code for the iPhone, but it seems to be outdated and out of sync with the rest of the code base.
I am not certain of the status here, but Esteban can probably help.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
Mariano Martinez Peck -
Stefan Marr