From: Pharo-dev [mailto:[email protected]] On Behalf Of
[email protected]
Ron,
Sure but at this time, not being able to run the simulator in a full Pharo
environment is a severe issue.
The key advantage is that the Smalltalk VM is written in itself.
Now, what do I experience is that it is hard to embark on VM work.
Why? Even if the PharoVMBuilders help in generating and compiling the VM for
several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this
is only one part of the puzzle.
The next step, is to understand how things do work for real, the interpret()
C loop isn't gonna help me one bit, I need to be able to simulate this one
in a Simulator. And I want to do that on the Pharo platform. Currently on
2.0 - this will (again) be fun to get to work on 3.0.
I understand. I'm suggestion that our shared goal should be to
bring the communities together for the VM. We can all benefit from the
contributions on all sides. It would seem to me that the COG simulator
would work for Pharo if we can get closer in sync but you are correct: It
will take time, collaboration and resources.
All the best,
Ron Teitelbaum
[snip]
The core system should be the same for Pharo/Squeak/... :
VMMaker-MemoryManager
VMMaker-Interpreter
VMMaker-InterpreterSimulation
VMMaker-MemoryManagerSimulation
and of course the Slang things (VMMaker-Support and VMMaker-Translation to
C).
What I'd love to end up with is an embeddable VM that we could hook into
other environments, languages etc (a bit like TCL for example). This
requires work on how the VM core runs. And to explore this, simulation is
needed.
Sorry for the long post. I wish I was a millionaire to pour in some cash
into the project to speed some areas up. Working on it :-) Maybe should we
work in that direction for funding. http://www.gv.com/ where are you?
Phil
On Thu, Feb 13, 2014 at 10:38 AM, Ron Teitelbaum <[email protected]> wrote:
> Stefan Marr
>
> Hi Eliot:
>
> On 13 Feb 2014, at 05:46, Eliot Miranda <[email protected]> wrote:
>
> > Hmm. What's the easiest way to map this to a Monticello mcz so I can
> integrate your changes back into my packages?
>
> I think the bigger question is whether you actually want to adopt those
things.
That the vm says in sync should be a core requirement for our communities.
I realize that there is a split. There are some really great advancements
going on in pharo-vm including new build methods and configurations. All of
that has value if pharo can stay in sync with COG developments. It doesn't
make sense to require Pharo developers to redo Eliot's work or to eliminate
Pharo VM advancements from the Squeak / Newspeak community. The VM is the
one place where we can continue to work together for the benefit of all
three communities. We should not, if at all possible, diverge, lest we lose
some excellent contributions from some really terrific people, in one or
another community.
All the best,
Ron Teitelbaum
> If you skim over the diffs on Github [1], you will probably find that most
of the
> changes are necessary to adopt Pharo-specific API changes.
> Not sure what the best way forward would be to avoid having the two Squeak
> and Pharo flavors diverge even more.
>
> I am open to suggestions, don't have a good idea how to properly
'modularize'
> these differences myself.
>
> Best regards
> Stefan
>
> [1] https://github.com/pharo-project/pharo-vm/pull/18
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>
