[Vm-dev] Re: [Pharo-dev] Brainstorming Pharo4

Eliot Miranda eliot.miranda at gmail.com
Fri Jun 6 15:46:33 UTC 2014


Hi Sven,


On Thu, Jun 5, 2014 at 1:57 AM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Here is my short, ordered list:
>
> - VM should run as a normal 64-bit citizen with the current 32-bit address
> space
>
>   (it is really annoying that we need 32-bit libraries, it hinders
> deployment on modern virtual hardware like Xen, Docker, .. - and it makes
> us look weird and old)
>

Yes, this is annoying but unfortunately it does not make economic sense.
 To have a 64-bit compiled Cog VM with 32-bit objects means

- developing an x86-64 code generator that moves 32-bit units instead of
the more natural 64-bit units

- developing a 64-bit FFI that uses the x86-64 ABIs and converts back and
forth between 32-bit objects

Both of these are expensive to develop (especially the former), but give us
nothing beyond what installing 32-bit libraries gives us.


> - VM should break the 32-bit memory limitation and use a 64-bit address
> space
>

Now this does make sense.  In fact it is a key goal of the Spur work.  That
will produce a full 64-bit image complete with 61-bit SmallIntegers, and
61-bit immediate floats, and a full 64-bit FFI.  This should be in
production some time next year, probably second half.


>   (we are currently limited to 1GB of memory in use,
> http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4696306
> - today's hardware easily offers many times more for little money, which we
> should be able to use for monolithic memory persistent data structures)
>

In fact, we are able to allocate 1.9Gb reliably on Mac OS and 2.2Gb on
linux at Cadence.  But yes, the current ~ 2Gb limit is, um, limiting.  The
64-bit Spur system will not suffer from this limitation.  The 32-bit system
may be able to grow above 2Bg on MacOS X, because Spur uses memory
segments.  But I haven't done any work to to ensure this works.


> - Modularity in the core development
>
>   (we have to keep Pharo lean and mean, we cannot make another mess like
> the one we are still cleaning up)
>
> - Capitalize on our tool set by improving it
>
>   (the magic of Pharo is, for a large part, situated in the IDE, but we
> have to invest in that area to remain relevant)
>
> Of course, handle format X, talk protocol Y, connect to database Z are all
> important, but can contributed externally. But to remain successful, we
> need a solid, modern base.
>

+1 (in fact I'm in emphatic agreement about this one; it is my core
direction to provide a great Smalltalk platform via Cog).

Hence some other things that need to happen are:

- refactor the VM into a small main program, a core execution engine
dll/shared object, and a gui library/shared object to allow embedding
Pharo/Squeak in other programs, and smaller footprint when running headless
(AFAIA this is not being worked on)

- provide web browser plugin capability, probably via a rendering and event
channelling slave written in JavaScript that is connected to the Cog VM via
sockets. (AFAIA this is not being worked on)

- make NativeBoost cross platform, and implement the rules for the ARM and
x86-64 ABIs in this system (this is being worked on by)

- implement adaptive optimization ("sista") to provide another significant
performance boost (this is being worked on).  Again Clément and I think
Sista could be in production in 2015.


And related to this I hope to make alpha 32-bit Spur Squeak VMs and images
available today.

Sven
>
> On 05 Jun 2014, at 10:14, phil at highoctane.be wrote:
>
> > On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <
> tulipe.moutarde at gmail.com> wrote:
> > As Kilon say, this is a personal wishlist. Any direction you mentioned
> is worth and will have impact.
> >
> > However, here's my personal top 5:
> >
> > - **Git in the image**, that would be awesome to be able integrate the
> gitflow way of developing in team. Easy branching/merging is a must.
> > - **Slots**. I still need to check the current implementation and see
> what's possible (Property slots?) but as I have understood you've planned
> even more for pharo4?
> > - **Text Editor with sensible keybindings**.
> > - **ARM support**
> > - **Athens**
> >
> > Keybindings that do work on Linux
> > VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15
> > Debugger that actually doesn't throws you in space after a couple of
> restart/through/over (this one really is taking power away from the whole
> experience)
> > Faster UI in general
> > Easier Git merges without metadata issues etc
> > Ability to recover frozen images (as in "Oz")
> > Ability to somehow get back control of the image through some mechanism
> at the VM level when frozen and no way to interrupt anything. I am ready to
> pay some performance in order to work that way.
> > Removal of all passwords, including whatever could be in the .changes
> (which will disappear per se but you get my drift).
> > +1 for Mpeg and Camera plugins;
> > Traits should indeed be given a better treatment in Nautilus.
> >
> > Phil
> >
> >
> >
> > On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval at gmail.com>
> wrote:
> > Hi all,
> >
> > From my point of view, I like the progrss on the ARM VM.
> > I hope to have an Android VM that works.
> > Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
> >
> > Another question is about two interesting plugins: Mpeg3Plugin and
> CameraPlugin.
> > Is it possible to integrate them in the VM build ?
> >
> > Thank you guys for all the work done.
> > Jannik
> >
> >
> > 2014-06-04 20:53 GMT+02:00 stepharo <stepharo at free.fr>:
> >
> >
> > Hi Esteban,
> >
> > As you mentioned a lot of new tools and protocols were introduced,
> > people (me included) does not well about those ones.
> > As an example I am slowly discovering announcement and now AFAIK the
> > image use three different protocols for this: change/update, observer
> > and Announcement!
> > Yes we know that the situation is not ideal.
> > We started to move more to announcement. The problem is that some of the
> widgets
> > requires the change/update. For the observer I do not know what you mean.
> >
> >
> > Personally I beg for a great Pharo 4.x series of iterative
> > cleaning+consolidations.
> >
> > Thanks
> >
> > Hilaire
> >
> > Le 04/06/2014 17:36, Esteban Lorenzano a écrit :
> > Hi,
> >
> > A couple of weeks ago we started to plan Pharo4. This work became
> stagnated for many reasons, but mainly because I needed to travel to
> Argentina.
> > Now I'm slowly resuming the work and I wanted to share with you what we
> have been talking/dreaming.
> > In esence, we have two important drivers for this release:
> >
> > 1) Improving tools
> > Turns out that we have introduced a lot of kernel improvements (opal
> compiler, layouts, slots, etc.) and tools are still not aware of them. Even
> worst: we have traits since a lot of time and our tools are still now aware
> enough to provide good interoperability.
> > But not just that: we have introduced things that are not well used yet:
> keybindings (who do not want a better keybindings structure... coherent and
> editable?), spec should allow us to continue enhancing existing tools and
> to replace old ones.
> >
> > 2) Modularisation
> > One of the fundamental ideas behind Pharo is to provide a modular
> environment. But well... since Pharo start to the moment, we prepared
> things to allow it, but still few direct effort has been made.
> > In our dreams, Pharo should be built starting for a small kernel image
> and adding different modules to get a complete version. In this idea
> Pharo=Kernel+GUI(Morphic)+Tools.
> > This has huge advantages (I do not think is necesary to explain them,
> isn't ;)?)
> >
> > We brainstomed around this and we get this list of issues (not all of
> them directly related to the objectives, but well... good stuff also :) )
> >
> > Web site:
> > - add catalog
> > - add videos
> > - enhance it in general
> >
> > Infrastructure:
> > - support more vm platforms
> >
> > VM:
> > - spur
> > - 64bits
> > - make vm embedable and UI independent (with SDL2 and OSWindow)
> >
> > Image:
> > - Modularisation
> > - Removing old compiler
> > - Repackage Morphic (to allow better modularisation)
> > - Athens (replace old bitblt)
> >
> > Tools
> > - Replace changes with Ombu/Epicea
> > - Replace sources with a better abstraction
> > - Git support inside image (with libgit2 + tools)
> > - Pass on Spec
> > - Include Glamour?
> > - Make Ring unloadable
> > - Fonts with FreeType
> >
> > And lots of bugfixes :)
> >
> > We would like to exchange ideas with you.
> > So, what do you think?
> >
> > Esteban
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > ~~Jannik Laval~~
> > École des Mines de Douai
> > Enseignant-chercheur
> > http://www.jannik-laval.eu
> > http://www.phratch.com
> > http://car.mines-douai.fr/
> >
> >
> >
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140606/dc4b71a8/attachment-0001.htm


More information about the Vm-dev mailing list