[Vm-dev] How to generate a consistent iOS and Unix VM?

Fri Apr 22 13:18:54 UTC 2011

On Fri, Apr 22, 2011 at 2:33 PM, Stefan Marr <squeak at 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
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110422/1831aadf/attachment.htm