Hi Clement,

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM).

- What are you doing with NativeBoost ? Is it FFI only or are you generating and executing hand-written machine code ? If it's FFI only, there might be alternative available working more or less out of the box. The Pharo image is using NativeBoost. If I open a File Browser on a network share (NFS) it tries to resolve environment variables (eg. HOME) by means of NativeBoost.

Regards Andreas

Best,

Clement

2015-03-10 20:26 GMT+01:00 Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>>: Hi all,

I have a question regarding the status of the PharoVM for UNIX operating systems, especially FreeBSD. As far as I have seen in the actual sources there is some support for FreeBSD available but for me it’s not clear whether it’s only partial or complete. For me it looks more partial (eg. there are no build instructions for FreeBSD and the default offers are only Mac, Linux and Windows), I haven’t tried to build it yet but I am thinking about to do that and want to get an idea about the efforts.

I have successfully build a PharoVM for openindiana (an OpenSolaris derivate). It runs both Pharo and Squeak images (at least partially, see below). I bootstrapped this on my Mac and used what was already available low level. Alas it has two problems until now: 1. Sound is not working properly (just a single click when doing some sound output and then silence). 2. NativeBoost is not working (atm it is based on the Linux version of NativeBoost).

As my time is very limited (doing everything in my spare time) I would like to get NativeBoost working on openindiana first, and then trying to build an actual PharoVM for FreeBSD. Therefore the question regarding the status of PharoVM for FreeBSD. Of course any hints where to start with the NativeBoost problem would be highly appreciated :)

Regards Andreas

Hi Eliot,

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Clement,

...

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

...

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

...

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work. Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development? And what is the status and what are the plans regarding Timothy’s (gettimothy) work? Regards Andreas

Hi Andreas, On Sun, Mar 15, 2015 at 12:23 PM, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Hi Eliot,

as promised I checked what I did and found something I changed:

The file platforms/unix/vm/sqUnixHeartbeat.c has the function void ioUpdateVMTimezone(). It was changed to something similar to what is in Cog's sqUnixITimerHeartbeat.c:

void ioUpdateVMTimezone() { updateMicrosecondClock(); #ifdef HAVE_TM_GMTOFF time_t utctt; utctt = (get64(utcMicrosecondClock) - MicrosecondsFrom1901To1970) / MicrosecondsPerSecond; vmGMTOffset = localtime(&utctt)->tm_gmtoff * MicrosecondsPerSecond; #else # ifdef HAVE_TIMEZONE extern time_t timezone, altzone; extern int daylight; vmGMTOffset = -1 * (daylight ? altzone : timezone) * MicrosecondsPerSecond; # else # error "cannot determine timezone correction" # endif #endif }

One thing is striking: the call to updateMicrosecondClock() is here before the #ifdef HAVE_TM_GMTOFF while in sqUnixITimerHeartbeat.c it is after the #ifdef.

Ah OK. Thanks!

I don't know which one is correct (I may have copied it wrongly from sqUnixITimerHeartbeat). Albeit the one here seems to be correct in my eyes. What do you think?

I think you're absolutely right. I'l make the change.

(Side note: As far as I remember Solaris does not have tm_gmtoff and thus the else part is being executed).

Regards Andreas

thanks, and welcome!

Am 14.03.15 18:33, schrieb Andreas Wacknitz:

Hi Eliot,

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

...

Hi Clement,

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working.

That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time).

I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work. Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development? And what is the status and what are the plans regarding Timothy’s (gettimothy) work?

Regards Andreas

-- best, Eliot

On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Andreas,

sorry to be late in replying. This has been a busy month (I moved house).

On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Eliot,

...

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Clement,

...

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

...

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

...

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work.

Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is).

Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here: https://ci.inria.fr/pharo/view/4.0-VM-Spur/ <https://ci.inria.fr/pharo/view/4.0-VM-Spur/> And as Eliot says… is not *much* work… except when it is :) In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didn’t finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with “official” spur support. We do not want to stay to much time in older versions. Also, our development process is different than squeak, AFAIK… we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions.

Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development?

Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration.

Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of “organisational” stuff to ensure traceability and “buildability” (if such word exists…). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request. To be able to do that: - we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. That’s why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In fact… I have a script “./newVM <commit>” that does a clone, prepares an image, generates sources and builds the vm… then I can test if a pull request is valid. But most of the time that is not needed, because: - for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not “vm specific tests”, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldn’t be possible without right traceability). - we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk. - finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using it… but we would like, in the future. So… obviously all of this can be achieved without using git and github… but there the infrastructure is already done. Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status: - in the VM itself there is almost no change. AFAIR, just two small things: a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot) b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different) - In the platforms we have the most important difference, because we deprecated the “Mac OS” branch in favor of “iOS”, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually) - in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, that’s just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged. After that, I think there will be some other minor changes… not many, and most probably we can remove those differences. hope this clarify all :) cheers, Esteban

And what is the status and what are the plans regarding Timothy’s (gettimothy) work?

Regards Andreas

-- best, Eliot

On 03 Apr 2015, at 13:04, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 03.04.15 11:13, schrieb Esteban Lorenzano:

...

...

On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

Hi Andreas,

sorry to be late in replying. This has been a busy month (I moved house).

On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Eliot,

...

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Clement,

...

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

...

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

...

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work.

Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is).

Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here:

https://ci.inria.fr/pharo/view/4.0-VM-Spur/ <https://ci.inria.fr/pharo/view/4.0-VM-Spur/>If I follow this link and what is being used there brings me to the ordinary PharoVm project on github:

https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> There are three branches: master, develop and spur64. Which one is being used to build PharoVM-spur32?

yes, I still didn’t merged with master. master still builds a regular cog vm. I’m working on spur64 branch now, here: https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> the spur jobs are built against my repository for the moment.

...

And as Eliot says… is not *much* work… except when it is :) In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didn’t finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with “official” spur support. We do not want to stay to much time in older versions. Also, our development process is different

This explanation irritates me: Pharo 4 will be released soon with a Spur VM? And then around summer Pharo 4S? Isn't it a contradiction?

no, Pharo 4 will be released *without* spur, then we will release a 4S *with* spur.

...

than squeak, AFAIK… we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions. That's OK, but I am still, hmm say confused, because Eliot is changing A LOT (just look at what has been released during the last days), but PharoVM hasn't been changed for some days (I am following the master branch closely). So there is a rapid development in the Cog branch of the SqueakVM. The changes in the PharoVM are much slower (at least as I recognise it).

just because you checked the master repository, not mine… mine changed yesterday :)

I have more questions but I am reluctant to disturb you further as you must be quite busy atm.

ask, I will answer when I can :)

Best regards Andreas

...

...

Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development?

Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration.

Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of “organisational” stuff to ensure traceability and “buildability” (if such word exists…). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request. To be able to do that: - we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. That’s why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In fact… I have a script “./newVM <commit>” that does a clone, prepares an image, generates sources and builds the vm… then I can test if a pull request is valid. But most of the time that is not needed, because: - for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not “vm specific tests”, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldn’t be possible without right traceability). - we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk. - finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using it… but we would like, in the future.

Is there an up-to-date documentation of the processes? Especially if I want to add more platform support (like openindiana or FreeBSD)?

the process, no… for now we accept pull requests… and we handle issues using the pharo issue tracker. This is not good, I would like to have a centralised issue tracker… but well, we will talk with Eliot about it soon (I suppose having alll sources in github also could lead us to us the issue tracker of github) the build process is explained in the README.md.

My time is very limited (my day job is quite different from what I do in my spare time + my family and my house also need a lot attention + next to my Smalltalk interets I am also interested in operating systems) so my reaction time is sometimes quite slow :)

...

So… obviously all of this can be achieved without using git and github… but there the infrastructure is already done.

Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status: - in the VM itself there is almost no change. AFAIR, just two small things: a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot) b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different) - In the platforms we have the most important difference, because we deprecated the “Mac OS” branch in favor of “iOS”, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually) - in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, that’s just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged.

After that, I think there will be some other minor changes… not many, and most probably we can remove those differences.

hope this clarify all :) That's a nice explanation at least. But I am still confused. Especially because you didn't mention NativeBoost :)

Nativeboost is just a plugin (and a cpp flag in generated sources to allocate executable memory).

The ffi area also seem to be different and i a flux.

but we are going to align that also (already half way from there) :) we want to be as close as possible… there is no point on keeping not needed divergences.

And still: How to integrate more platforms?

depends on the platform. regular process would be: 1) create a /platform directory, for example /platform/freebsd but since freebsd is a unix, probably you do not need to do that and you can handle it in same /platform/unix directory 2) create a PharoSpur32FreeBSDConfig, taking CogFreeBSDConfig and PharoSpur32UnixConfig (already there) as models. no idea what changes you need to have. we could probably get a freebsd slave to add the build to our building process, I don’t know :) cheers, Esteban

Regards Andreas

On 03 Apr 2015, at 17:27, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

Am 03.04.15 13:39, schrieb Esteban Lorenzano:

...

...

On 03 Apr 2015, at 13:04, Andreas Wacknitz <A.Wacknitz@gmx.de <mailto:A.Wacknitz@gmx.de>> wrote:

Am 03.04.15 11:13, schrieb Esteban Lorenzano:

...

...

On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

Hi Andreas,

sorry to be late in replying. This has been a busy month (I moved house).

On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Eliot,

...

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

Hi Clement,

...

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

...

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

...

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere...

PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work.

Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is).

Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here:

https://ci.inria.fr/pharo/view/4.0-VM-Spur/ <https://ci.inria.fr/pharo/view/4.0-VM-Spur/>If I follow this link and what is being used there brings me to the ordinary PharoVm project on github:

https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> There are three branches: master, develop and spur64. Which one is being used to build PharoVM-spur32?

yes, I still didn’t merged with master. master still builds a regular cog vm.

I’m working on spur64 branch now, here:

https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64>

the spur jobs are built against my repository for the moment.

I see, that wasn't obvious.

I know… because is till experimental :)

...

...

...

And as Eliot says… is not *much* work… except when it is :) In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didn’t finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with “official” spur support. We do not want to stay to much time in older versions. Also, our development process is different

This explanation irritates me: Pharo 4 will be released soon with a Spur VM? And then around summer Pharo 4S? Isn't it a contradiction?

no, Pharo 4 will be released *without* spur, then we will release a 4S *with* spur.

Ok, that makes sense.

...

...

...

than squeak, AFAIK… we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions. That's OK, but I am still, hmm say confused, because Eliot is changing A LOT (just look at what has been released during the last days), but PharoVM hasn't been changed for some days (I am following the master branch closely). So there is a rapid development in the Cog branch of the SqueakVM. The changes in the PharoVM are much slower (at least as I recognise it).

just because you checked the master repository, not mine… mine changed yesterday :)

...

I have more questions but I am reluctant to disturb you further as you must be quite busy atm.

ask, I will answer when I can :)

...

Best regards Andreas

...

...

Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development?

Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration.

Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of “organisational” stuff to ensure traceability and “buildability” (if such word exists…). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request. To be able to do that: - we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. That’s why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In fact… I have a script “./newVM <commit>” that does a clone, prepares an image, generates sources and builds the vm… then I can test if a pull request is valid. But most of the time that is not needed, because: - for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not “vm specific tests”, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldn’t be possible without right traceability). - we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk. - finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using it… but we would like, in the future.

Is there an up-to-date documentation of the processes? Especially if I want to add more platform support (like openindiana or FreeBSD)?

the process, no… for now we accept pull requests… and we handle issues using the pharo issue tracker. This is not good, I would like to have a centralised issue tracker… but well, we will talk with Eliot about it soon (I suppose having alll sources in github also could lead us to us the issue tracker of github) the build process is explained in the README.md.

...

My time is very limited (my day job is quite different from what I do in my spare time + my family and my house also need a lot attention + next to my Smalltalk interets I am also interested in operating systems) so my reaction time is sometimes quite slow :)

...

So… obviously all of this can be achieved without using git and github… but there the infrastructure is already done.

Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status: - in the VM itself there is almost no change. AFAIR, just two small things: a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot) b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different) - In the platforms we have the most important difference, because we deprecated the “Mac OS” branch in favor of “iOS”, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually) - in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, that’s just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged.

After that, I think there will be some other minor changes… not many, and most probably we can remove those differences.

hope this clarify all :) That's a nice explanation at least. But I am still confused. Especially because you didn't mention NativeBoost :)

Nativeboost is just a plugin (and a cpp flag in generated sources to allocate executable memory).

Ok, when I built my PharoVM for openindiana I was using the Linux version. Alas, that one doesn't work and thus Pharo 4 images have problems.

I don’t know… we are working for making NB not a requirement.

...

...

The ffi area also seem to be different and i a flux.

but we are going to align that also (already half way from there) :) we want to be as close as possible… there is no point on keeping not needed divergences.

...

And still: How to integrate more platforms?

depends on the platform. regular process would be:

1) create a /platform directory, for example /platform/freebsd but since freebsd is a unix, probably you do not need to do that and you can handle it in same /platform/unix directory

2) create a PharoSpur32FreeBSDConfig, taking CogFreeBSDConfig and PharoSpur32UnixConfig (already there) as models.

Hm, atm I am trying to build a new vm for openindiana based on what is on the official repository. Would it be better to switch to your branch?

well, I can offer support with my sources… so yes, I would say so :)

...

no idea what changes you need to have. we could probably get a freebsd slave to add the build to our building process, I don’t know :)

FreeBSD will be my 2nd choice. First I want a fully working openindiana version. Even if it's a niche os in my eyes it's superior compared to all the others. But maybe I am biased because I am using it since it forked from OpenSolaris. I became a Solaris fan while working at my former employer…

I don’t know openindiana nor freebsd… but well, matter of choices :) cheers, Esteban

Cheers, Andreas

Hi, there is no real rationale :( the reason why they are there now and not in their corresponding #defaultInternalPlugins or #defaultExternalPlugins is historic, configurations growth organically (we would need a refactor there). at least: FT2Plugin and SqueakSSLPlugin should be in defaults (and in the future SDL2 too). for starting your build I suggest you to exclude all the additions (plugins and external libraries). then add them one by one. cheers, Esteban

On 06 Apr 2015, at 08:49, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 03.04.15 17:31, schrieb Esteban Lorenzano:

...

...

...

...

I have more questions but I am reluctant to disturb you further as you must be quite busy atm.

ask, I will answer when I can :)

Hi Esteban,

I am trying to understand the rationale behind PharoVMBuilder>>buildUnix32 (and similar methods like >>buildMacOSX32, >>buildFreeBSD32). How to determine which plugins and libraries to use? Linux makes use of PharoUnixConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SqueakSSLPlugin SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' 'libsdl2');

For FreeBSD it looks like this: PharoFreeBSDConfig new "generateForDebug;" addExternalPlugins: #( SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' );

Mac OSX: PharoOSXConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SDL2DisplayPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'cairo' 'libgit2' 'libssh2' 'libsdl2');

Windows: PharoWindowsConfig new addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); addInternalPlugins: #( SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'cairo' 'libssh2' 'libgit2' 'libsdl2');

I assume that FreeBSD's configuration is not up-to-date (sdl2 and cairo not yet available?). Should I try to configure cairo, libssh2, libgit2 and libsdl2 libraries for openindiana, like it is done for Windows and MacOSX? Furthermore, should I try to configure SqueakSSLPlugin, FT2Plugin and SDL2DisplayPlugin as external plugins and UnixOSProcessPlugin as internal plugin?

Regards Andreas

On 06 Apr 2015, at 09:41, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 06.04.15 09:01, schrieb Esteban Lorenzano:

...

Hi,

there is no real rationale :( the reason why they are there now and not in their corresponding #defaultInternalPlugins or #defaultExternalPlugins is historic, configurations growth organically (we would need a refactor there). I fear not so many people could do that. I am scratching my head quite often while reading the code. BTW: PharoS is being used for Stack vm's so you should either find another abbreviation for Spur or choose the full name (that's what I would prefer). Otherwise it will get even harder in the future…

we plan to drop support for plain cog vm and replace it for spur… so Pharo and PharoS will be both spur VMs… no need to complicate things here.

...

at least: FT2Plugin and SqueakSSLPlugin should be in defaults (and in the future SDL2 too).

for starting your build I suggest you to exclude all the additions (plugins and external libraries). then add them one by one. I already have a running version from almost one year ago. This time I will try to get further (eg. NativeBoost) and want to enhance my documentation. But it is time consuming and I would like to spend my time with more interesting things (using Pharo :))

:)

Cheers, Andreas

...

cheers, Esteban

...

On 06 Apr 2015, at 08:49, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 03.04.15 17:31, schrieb Esteban Lorenzano:

...

...

...

...

I have more questions but I am reluctant to disturb you further as you must be quite busy atm. ask, I will answer when I can :) Hi Esteban,

I am trying to understand the rationale behind PharoVMBuilder>>buildUnix32 (and similar methods like >>buildMacOSX32, >>buildFreeBSD32). How to determine which plugins and libraries to use? Linux makes use of PharoUnixConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SqueakSSLPlugin SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' 'libsdl2');

For FreeBSD it looks like this: PharoFreeBSDConfig new "generateForDebug;" addExternalPlugins: #( SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' );

Mac OSX: PharoOSXConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SDL2DisplayPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'cairo' 'libgit2' 'libssh2' 'libsdl2');

Windows: PharoWindowsConfig new addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); addInternalPlugins: #( SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'cairo' 'libssh2' 'libgit2' 'libsdl2');

I assume that FreeBSD's configuration is not up-to-date (sdl2 and cairo not yet available?). Should I try to configure cairo, libssh2, libgit2 and libsdl2 libraries for openindiana, like it is done for Windows and MacOSX? Furthermore, should I try to configure SqueakSSLPlugin, FT2Plugin and SDL2DisplayPlugin as external plugins and UnixOSProcessPlugin as internal plugin?

Regards Andreas

On 06 Apr 2015, at 09:58, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

Am 06.04.15 09:51, schrieb Esteban Lorenzano:

...

...

On 06 Apr 2015, at 09:41, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 06.04.15 09:01, schrieb Esteban Lorenzano:

...

Hi,

there is no real rationale :( the reason why they are there now and not in their corresponding #defaultInternalPlugins or #defaultExternalPlugins is historic, configurations growth organically (we would need a refactor there). I fear not so many people could do that. I am scratching my head quite often while reading the code. BTW: PharoS is being used for Stack vm's so you should either find another abbreviation for Spur or choose the full name (that's what I would prefer). Otherwise it will get even harder in the future… we plan to drop support for plain cog vm and replace it for spur… so Pharo and PharoS will be both spur VMs… no need to complicate things here. Ah, OK. So probably I should wait until this happened and everythings settled down. One more question regarding the future: I guess there will be Spur32 and Spur64 vm's, right? If so, what are the plans regarding NativeBoost? Will there be a 64 bit version, too? (Ok, that's more than one question :))

I’m working on a replacement that takes same syntax but uses regular FFI implementation instead ASM. This will re-orientate our efforts into a common FFI strategy in all platforms and joint with Eliot work. In that direction, there is some important work to speed up (with a new bytecode set and functions to FFI, Ronie and Eliot were working on it), plus a threaded ffi implementation, plus 64bits, plus ARM. So, no need on reinvent the wheel here. NB was important and a very good idea, but sadly we cannot maintain it as-is. Esteban

Regards Andreas

...

...

...

at least: FT2Plugin and SqueakSSLPlugin should be in defaults (and in the future SDL2 too).

for starting your build I suggest you to exclude all the additions (plugins and external libraries). then add them one by one. I already have a running version from almost one year ago. This time I will try to get further (eg. NativeBoost) and want to enhance my documentation. But it is time consuming and I would like to spend my time with more interesting things (using Pharo :)) :)

...

Cheers, Andreas

...

cheers, Esteban

...

On 06 Apr 2015, at 08:49, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 03.04.15 17:31, schrieb Esteban Lorenzano:

...

...

...

...

I have more questions but I am reluctant to disturb you further as you must be quite busy atm. ask, I will answer when I can :) Hi Esteban,

I am trying to understand the rationale behind PharoVMBuilder>>buildUnix32 (and similar methods like >>buildMacOSX32, >>buildFreeBSD32). How to determine which plugins and libraries to use? Linux makes use of PharoUnixConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SqueakSSLPlugin SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' 'libsdl2');

For FreeBSD it looks like this: PharoFreeBSDConfig new "generateForDebug;" addExternalPlugins: #( SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' );

Mac OSX: PharoOSXConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SDL2DisplayPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'cairo' 'libgit2' 'libssh2' 'libsdl2');

Windows: PharoWindowsConfig new addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); addInternalPlugins: #( SDL2DisplayPlugin ); addThirdpartyLibraries: #( 'cairo' 'libssh2' 'libgit2' 'libsdl2');

I assume that FreeBSD's configuration is not up-to-date (sdl2 and cairo not yet available?). Should I try to configure cairo, libssh2, libgit2 and libsdl2 libraries for openindiana, like it is done for Windows and MacOSX? Furthermore, should I try to configure SqueakSSLPlugin, FT2Plugin and SDL2DisplayPlugin as external plugins and UnixOSProcessPlugin as internal plugin?

Regards Andreas

Hi Andreas, On Apr 3, 2015, at 4:04 AM, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:

Am 03.04.15 11:13, schrieb Esteban Lorenzano:

...

...

On 02 Apr 2015, at 19:20, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Andreas,

sorry to be late in replying. This has been a busy month (I moved house).

On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

...

Hi Eliot,

...

Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

HI Andreas,

On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

...

Hi Clement,

...

Am 11.03.2015 um 09:23 schrieb Clément Bera <bera.clement@gmail.com>:

Hello,

About the FreeBSD VM, Holger Freyther worked on it so he's the best person to answer. I think some people used it and it was at least partially working. That’s my impression. The VMMaker contains some FreeBSD classes but I have the impression that they are not complete (and probably outdated).

...

About your NativeBoost bug on openSolaris, need more information:

- Can you confirm that you use an intel processor on your openSolaris machine ? I assume that yes but I ask because solaris were typically running on other processors. NativeBoost, as of today, works only with intel processor.

Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).

...

- Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by default, that may be your problem. There's a fix somewhere... PharoVM from "branch 'master' of https://github.com/pharo-project/pharo-vm" (thus Cog VM).

I would like to fold back any changes into the svn master repository for Cog. What are the diffs? (If you have time to send me the diffs that would save me a lot of time). I don’t know whether there is much to harvest from what I did. As far as I remember most of my work was hacking the generator image created by the pharo vm scripts (for my Mac) in order to make the resulting C code to compile under openindiana. The basis for Solaris was already there (and as far as I can see it is also in the Squeak VM sources). I only tweaked some definitions and includes. I will look at my notes tomorrow and will post if I will find something relevant.

I am curios about the future of the PharoVM. The main development of the VM seem to happen in the SqueakVM (by you). Getting the Spur changes into the PharoVM seem to be a lot of work.

Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is).

Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here:

https://ci.inria.fr/pharo/view/4.0-VM-Spur/

If I follow this link and what is being used there brings me to the ordinary PharoVm project on github: https://github.com/pharo-project/pharo-vm There are three branches: master, develop and spur64. Which one is being used to build PharoVM-spur32?

...

And as Eliot says… is not *much* work… except when it is :) In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didn’t finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with “official” spur support. We do not want to stay to much time in older versions. Also, our development process is different

This explanation irritates me: Pharo 4 will be released soon with a Spur VM? And then around summer Pharo 4S? Isn't it a contradiction?

...

than squeak, AFAIK… we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions. That's OK, but I am still, hmm say confused, because Eliot is changing A LOT (just look at what has been released during the last days), but PharoVM hasn't been changed for some days (I am following the master branch closely). So there is a rapid development in the Cog branch of the SqueakVM. The changes in the PharoVM are much slower (at least as I recognise it).

It may seem like I'm changing a lot, but I am /not/ changing the base and Spur VMs much. I am only fixing bugs I. spur. That's because I'm stabilising the VM for the Squeak 5 release. The changes are in two areas that are as yet unreleased. One area is the JIT for ARM that Tim and I are working on. The other area is Sista, the speculative inliner, that Clément and I are working on.

I have more questions but I am reluctant to disturb you further as you must be quite busy atm.

Best regards Andreas

...

...

...

Wouldn’t it be better to move back the changes of the PharoVM into the SqueakVM and have a united development?

Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration.

Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of “organisational” stuff to ensure traceability and “buildability” (if such word exists…). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request. To be able to do that: - we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. That’s why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In fact… I have a script “./newVM <commit>” that does a clone, prepares an image, generates sources and builds the vm… then I can test if a pull request is valid. But most of the time that is not needed, because: - for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not “vm specific tests”, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldn’t be possible without right traceability). - we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk. - finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using it… but we would like, in the future.

Is there an up-to-date documentation of the processes? Especially if I want to add more platform support (like openindiana or FreeBSD)? My time is very limited (my day job is quite different from what I do in my spare time + my family and my house also need a lot attention + next to my Smalltalk interets I am also interested in operating systems) so my reaction time is sometimes quite slow :)

...

So… obviously all of this can be achieved without using git and github… but there the infrastructure is already done.

Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status: - in the VM itself there is almost no change. AFAIR, just two small things: a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot) b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different) - In the platforms we have the most important difference, because we deprecated the “Mac OS” branch in favor of “iOS”, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually) - in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, that’s just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged.

After that, I think there will be some other minor changes… not many, and most probably we can remove those differences.

hope this clarify all :) That's a nice explanation at least. But I am still confused. Especially because you didn't mention NativeBoost :) The ffi area also seem to be different and i a flux.

And still: How to integrate more platforms?

Regards Andreas