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 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.
>

> On 23 January 2013 16:40, Esteban Lorenzano <[hidden email]> 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)

>
>
>> 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 <[hidden email]> wrote:
>
>> On 23 January 2013 16:40, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>> On Jan 23, 2013, at 4:56 PM, Igor Stasenko <[hidden email]> wrote:
>>
>>> On 23 January 2013 16:40, Esteban Lorenzano <[hidden email]> 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?
>

> 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 Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 23 January 2013 17:27, Sean P. DeNigris <[hidden email]> 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.