[Pharo-project] about the VM and Pharo
Hi, Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list: - the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support. in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented) in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). So, for Pharo 2.0 now we are working on this twi issues: - Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. Cheers, Esteban
On 23 January 2013 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins.
Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list:
- the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support.
in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented)
you forgot: - OSProcess (VMs should include it default, so then we can use it instead of writing bash scripts) - Freetype (this is already default) - .. and bundling Cairo library
in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now).
So, for Pharo 2.0 now we are working on this twi issues:
- Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :)
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost.
For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
sounds like a lot of work for me :)
Cheers, Esteban
-- Best regards, Igor Stasenko.
On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins.
Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list:
- the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support.
in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented)
you forgot:
- OSProcess (VMs should include it default, so then we can use it instead of writing bash scripts) yup
- Freetype (this is already default)
yup
- .. and bundling Cairo library
afaik, thats for 3.0 :)
in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now).
So, for Pharo 2.0 now we are working on this twi issues:
- Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :)
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost.
For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
sounds like a lot of work for me :)
yes it is... well... we'll see :)
Cheers, Esteban
-- Best regards, Igor Stasenko.
On 23 Jan 2013, at 17:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins.
Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list:
- the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support.
in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented)
The SSL Plugin is also very important ;-)
you forgot:
- OSProcess (VMs should include it default, so then we can use it instead of writing bash scripts) yup
- Freetype (this is already default)
yup
- .. and bundling Cairo library
afaik, thats for 3.0 :)
in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now).
So, for Pharo 2.0 now we are working on this twi issues:
- Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :)
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost.
For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
sounds like a lot of work for me :)
yes it is... well... we'll see :)
Cheers, Esteban
-- Best regards, Igor Stasenko.
and is already there... I just forgot to mention it :P he, I was writing by memory... I probably miss a lot of the work we did last year ;) On Jan 23, 2013, at 5:13 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Jan 2013, at 17:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins.
Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list:
- the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support.
in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented)
The SSL Plugin is also very important ;-)
you forgot:
- OSProcess (VMs should include it default, so then we can use it instead of writing bash scripts) yup
- Freetype (this is already default)
yup
- .. and bundling Cairo library
afaik, thats for 3.0 :)
in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now).
So, for Pharo 2.0 now we are working on this twi issues:
- Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :)
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost.
For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
sounds like a lot of work for me :)
yes it is... well... we'll see :)
Cheers, Esteban
-- Best regards, Igor Stasenko.
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :) EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly? Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)? Cheers, Sean -- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 23 January 2013 17:27, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :)
EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly?
no it is not integrated yet. After discussing with Eliot, he recommended to use last object format to denote ephemerons. Existing implementation is a bit hackish way to determine if object is ephemeron. So, before we do such change, assume they are not working yet.
Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)?
which server?
Cheers, Sean -- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)?
which server?
http://pharo.gforge.inria.fr/ci/vm/pharo/ -- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664909.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 23 January 2013 18:07, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)?
which server?
yes, this is JIT Cog VMs branded for Pharo
-- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664909.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 17:27, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :)
EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly?
no it is not integrated yet. After discussing with Eliot, he recommended to use last object format to denote ephemerons. Existing implementation is a bit hackish way to determine if object is ephemeron. So, before we do such change, assume they are not working yet.
Yes, please. This is the only thing that has kept me from integrating the ephemeron work. We can use instSpec/format #5. The instSpec/formats are 0: zero-fixed-sized pointers (e.g. UndefinedObject) 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) 2: zero-fixed-size variable pointers (e.g. Array) 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState (method,selector)) 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem (list,next,executor) 5. unused 6. variable 32-bit non-pointers (e.g. Float) 7. unused (but should be odd bit for length of format 6 objects in 64-bit system) 8. variable 8-bit non-pointers (e.g. ByteArray, String) 9,10,11 odd bits for length of format 8 objects 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) 13,14,15 odd bits for length of format 12 objects So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 contain pointers. 7's a really bad choice. And I won't bore you with the extension to 64-bits and a 5 bit field.
Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)?
which server?
Cheers, Sean -- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- best, Eliot
On 23 January 2013 20:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 17:27, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :)
EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly?
no it is not integrated yet. After discussing with Eliot, he recommended to use last object format to denote ephemerons. Existing implementation is a bit hackish way to determine if object is ephemeron. So, before we do such change, assume they are not working yet.
Yes, please. This is the only thing that has kept me from integrating the ephemeron work. We can use instSpec/format #5. The instSpec/formats are 0: zero-fixed-sized pointers (e.g. UndefinedObject) 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) 2: zero-fixed-size variable pointers (e.g. Array) 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState (method,selector)) 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem (list,next,executor) 5. unused 6. variable 32-bit non-pointers (e.g. Float) 7. unused (but should be odd bit for length of format 6 objects in 64-bit system) 8. variable 8-bit non-pointers (e.g. ByteArray, String) 9,10,11 odd bits for length of format 8 objects 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) 13,14,15 odd bits for length of format 12 objects
So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 contain pointers. 7's a really bad choice.
Good.
And I won't bore you with the extension to 64-bits and a 5 bit field.
:) As a tangent.. i looking for a ways to have simpler model where we have only 2 object formats: - objects which fields are pointers - objects which contain no pointers because this is the only thing that matters for VM/GC most of the time. For other contracts, like how to treat pointers (whether they weak or ephemeron or any other kind), we could use a 'marker' object, i.e. a special object stored in first slot of questioned object. So, for example, if a first slot has reference to 'WeakKind' special object, then rest references is held weakly. By analogy, putting 'EphemeronKind' will automatically mark object as ephemeron. So, instead of using bits in header, we using extra slot. The advantage is that we're no longer constrained by the number of bits reserved for object format, and future VM can introduce any other kind, if needed, without need to touch rest. dreams, dreams.. :) -- Best regards, Igor Stasenko.
On Jan 23, 2013, at 5:27 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :)
EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly?
Also, is the Pharo branded VM on the static file server based on Jit Cog (as opposed to stack, etc)?
which server? I'm currently working on that... it will be a Jit and a Stack version of the branded VMs, but so far I'm working on the Jit (simple to adapt, anyway) so far you can find it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ but as you can see, I'm having some problems :P cheers, Esteban
Cheers, Sean
-- View this message in context: http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
esteban ***THANKS*** for this mail. Could you consolidate a version (including igor feedback) and post it as a blog post on the pharo web site? This is for this kind of work that we need a stronger consortium. Stef On Jan 23, 2013, at 12:40 PM, Esteban Lorenzano wrote:
Hi,
Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins.
Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list:
- the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support.
in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented)
in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now).
So, for Pharo 2.0 now we are working on this twi issues:
- Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :)
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost.
For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Cheers, Esteban
participants (6)
-
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe