<div dir="ltr">Hi Sven,<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 1:57 AM, Sven Van Caekenberghe <span dir="ltr"><<a href="mailto:sven@stfx.eu" target="_blank">sven@stfx.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Here is my short, ordered list:<br>
<br>
- VM should run as a normal 64-bit citizen with the current 32-bit address space<br>
<br>
(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)<br></blockquote><div><br></div><div>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</div>
<div><br></div><div>- developing an x86-64 code generator that moves 32-bit units instead of the more natural 64-bit units</div><div><br></div><div>- developing a 64-bit FFI that uses the x86-64 ABIs and converts back and forth between 32-bit objects</div>
<div><br></div><div>Both of these are expensive to develop (especially the former), but give us nothing beyond what installing 32-bit libraries gives us.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- VM should break the 32-bit memory limitation and use a 64-bit address space<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
(we are currently limited to 1GB of memory in use, <a href="http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4696306" target="_blank">http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4696306</a> - today's hardware easily offers many times more for little money, which we should be able to use for monolithic memory persistent data structures)<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- Modularity in the core development<br>
<br>
(we have to keep Pharo lean and mean, we cannot make another mess like the one we are still cleaning up)<br>
<br>
- Capitalize on our tool set by improving it<br>
<br>
(the magic of Pharo is, for a large part, situated in the IDE, but we have to invest in that area to remain relevant)<br>
<br>
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.<br></blockquote><div><br></div><div>+1 (in fact I'm in emphatic agreement about this one; it is my core direction to provide a great Smalltalk platform via Cog).</div>
<div><br></div><div>Hence some other things that need to happen are:</div><div><br></div><div>- 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)<br>
</div><div><br></div><div>- 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)</div>
<div><br></div><div>- make NativeBoost cross platform, and implement the rules for the ARM and x86-64 ABIs in this system (this is being worked on by)</div><div><br></div><div>- 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.</div>
<div><br></div><div><br></div><div>And related to this I hope to make alpha 32-bit Spur Squeak VMs and images available today.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">Sven<br>
</font></span><div class=""><div class="h5"><br>
On 05 Jun 2014, at 10:14, <a href="mailto:phil@highoctane.be">phil@highoctane.be</a> wrote:<br>
<br>
> On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <<a href="mailto:tulipe.moutarde@gmail.com">tulipe.moutarde@gmail.com</a>> wrote:<br>
> As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.<br>
><br>
> However, here's my personal top 5:<br>
><br>
> - **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.<br>
> - **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?<br>
> - **Text Editor with sensible keybindings**.<br>
> - **ARM support**<br>
> - **Athens**<br>
><br>
> Keybindings that do work on Linux<br>
> VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15<br>
> 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)<br>
> Faster UI in general<br>
> Easier Git merges without metadata issues etc<br>
> Ability to recover frozen images (as in "Oz")<br>
> 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.<br>
> Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift).<br>
> +1 for Mpeg and Camera plugins;<br>
> Traits should indeed be given a better treatment in Nautilus.<br>
><br>
> Phil<br>
><br>
><br>
><br>
> On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <<a href="mailto:jannik.laval@gmail.com">jannik.laval@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> From my point of view, I like the progrss on the ARM VM.<br>
> I hope to have an Android VM that works.<br>
> Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.<br>
><br>
> Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin.<br>
> Is it possible to integrate them in the VM build ?<br>
><br>
> Thank you guys for all the work done.<br>
> Jannik<br>
><br>
><br>
> 2014-06-04 20:53 GMT+02:00 stepharo <<a href="mailto:stepharo@free.fr">stepharo@free.fr</a>>:<br>
><br>
><br>
> Hi Esteban,<br>
><br>
> As you mentioned a lot of new tools and protocols were introduced,<br>
> people (me included) does not well about those ones.<br>
> As an example I am slowly discovering announcement and now AFAIK the<br>
> image use three different protocols for this: change/update, observer<br>
> and Announcement!<br>
> Yes we know that the situation is not ideal.<br>
> We started to move more to announcement. The problem is that some of the widgets<br>
> requires the change/update. For the observer I do not know what you mean.<br>
><br>
><br>
> Personally I beg for a great Pharo 4.x series of iterative<br>
> cleaning+consolidations.<br>
><br>
> Thanks<br>
><br>
> Hilaire<br>
><br>
> Le 04/06/2014 17:36, Esteban Lorenzano a écrit :<br>
> Hi,<br>
><br>
> 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.<br>
> Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming.<br>
> In esence, we have two important drivers for this release:<br>
><br>
> 1) Improving tools<br>
> 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.<br>
> 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.<br>
><br>
> 2) Modularisation<br>
> 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.<br>
> 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.<br>
> This has huge advantages (I do not think is necesary to explain them, isn't ;)?)<br>
><br>
> 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 :) )<br>
><br>
> Web site:<br>
> - add catalog<br>
> - add videos<br>
> - enhance it in general<br>
><br>
> Infrastructure:<br>
> - support more vm platforms<br>
><br>
> VM:<br>
> - spur<br>
> - 64bits<br>
> - make vm embedable and UI independent (with SDL2 and OSWindow)<br>
><br>
> Image:<br>
> - Modularisation<br>
> - Removing old compiler<br>
> - Repackage Morphic (to allow better modularisation)<br>
> - Athens (replace old bitblt)<br>
><br>
> Tools<br>
> - Replace changes with Ombu/Epicea<br>
> - Replace sources with a better abstraction<br>
> - Git support inside image (with libgit2 + tools)<br>
> - Pass on Spec<br>
> - Include Glamour?<br>
> - Make Ring unloadable<br>
> - Fonts with FreeType<br>
><br>
> And lots of bugfixes :)<br>
><br>
> We would like to exchange ideas with you.<br>
> So, what do you think?<br>
><br>
> Esteban<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> ~~Jannik Laval~~<br>
> École des Mines de Douai<br>
> Enseignant-chercheur<br>
> <a href="http://www.jannik-laval.eu" target="_blank">http://www.jannik-laval.eu</a><br>
> <a href="http://www.phratch.com" target="_blank">http://www.phratch.com</a><br>
> <a href="http://car.mines-douai.fr/" target="_blank">http://car.mines-douai.fr/</a><br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>