[Vm-dev] pharo-vm-spur status & strategy
estebanlm at gmail.com
Thu Aug 13 17:08:24 UTC 2015
> On 13 Aug 2015, at 18:54, Ben Coman <btc at openInWorld.com> wrote:
>> From the github network graph for pharo-vm
> https://github.com/pharo-project/pharo-vm/network ...
> * I see pharo-vm-spur branch was forked from pharo-vm-master by
> Esteban ~ July 2014 with lots of commits to align with and keep
> synchronised with Eliot's Cog trunk
> * I presume Esteban's pharo-vm-spur branch will become the 64-bit-VM
> for Pharo 5?
yes… well, not completely: it will be the spur 32bits. 64bits still depends (time, etc.).
> * What is the plan for the current pharo-vm-master branch? Will it be
> retagged pharo-vm-legacy? I see ongoing commits (mostly libgit?) to
> the (presumed)-pharo-vm-legacy, which sparks the questions:
I will take changes in master that are relevant, then I will rename “master” as “legacy” and rename the branch “spur64” as “master”.
> ** Is it feasible to merge pharo-vm-legacy into pharo-vm-spur?
> Maybe we'll need to cherrypick commits? (Actually later I noticed
it is, there are not so many… and they are out of VMMaker (they are lateral/plugin/etc. code).
> ** At what point would it make sense for people to start
> contributing to pharo-vm-spur rather than pharo-vm-legacy
legacy is legacy.
but… we still need some time to move the development to spur. Right now the blocker stuff is just NB (we need to drop ASMJIT and adopt regular FFI), I’m working on it but is not easy… I don’t know when I will finish… hopefully not too much.
In the mean time pharo-spur-vm is usable (without NB and NB-related fwks like Athens) and very stable.
Pharo5 image is being auto-converted by CI. Right now I’m having a small issue (someone removed ImmediateLayout from image), but is working fine.
> * When should Esteban's spur branch be pulled into the official
> pharo-project/pharo-vm repository (continuing tagged as spur)?
> Possibly making it more inviting for other to contribute to that
when I’m ready.
> On a slightly different track...
> * Regarding the work on CMakeVMMaker. Was that was somewhat based off
> PharoVMMaker? How feasible is it to merge PharoVMMaker into
> CMakeVMMaker and retire PharoVMMaker ?
PharoVMMaker is just an extension… we could merge but I do not see the point (the original idea was that people wanting to produce their own flavour or just the vanilla can use the cmakemaker)
> * How is the synchronising between Cog svn repo and pharo-vm git repo
> currently being done? Is something like git-svn run manually?
With this job: https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/Spur-VMMaker-Tracker/ <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/Spur-VMMaker-Tracker/>
> * I remember one major concern with moving CogVM trunk to github was
> learning new tools. I just noticed subversion clients can work
> directly with github to support hybrid teams  . Any interest in
> exploring that?
that’s not a question for me, I’m a lot more confortable with gut tools than svn tools :)
>  https://github.com/blog/1178-collaborating-on-github-with-subversion
>  https://github.com/blog/966-improved-subversion-client-support
> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev