Cog - dumb question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Cog - dumb question

Schwab,Wilhelm K
In skimming the messages, I thought I read both that an image saved from a Cog VM both can and cannot be later opened with an ordinary VM.  Which is it?  It makes sense for the image to have to include Cog support code, but does that and being saved from a Cog VM spoil the image for the current closure VMs?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Henrik Sperre Johansen

On Jun 22, 2010, at 1:21 37PM, Schwab,Wilhelm K wrote:

> In skimming the messages, I thought I read both that an image saved from a Cog VM both can and cannot be later opened with an ordinary VM.  Which is it?

Cannot.

>  It makes sense for the image to have to include Cog support code, but does that and being saved from a Cog VM spoil the image for the current closure VMs?
>
Yes.
The code works on both Cog and Closure VMs though, so development can continue on whatever VM you desire without a split in package versions.
As Cog is able to read closure-images, but not the other way around, I imagine we will want to keep releasing official images saved by the closure VM.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Yanni Chiu
Henrik Johansen wrote:
> The code works on both Cog and Closure VMs though, so development can
> continue on whatever VM you desire without a split in package
> versions. As Cog is able to read closure-images, but not the other
> way around, I imagine we will want to keep releasing official images
> saved by the closure VM.

IMHO, we should move to Cog as soon as possible - once any major bugs,
if any, are dealt with. So, change direction: abandon 1.2 (which just
started) and go for 2.0, which requires an image format change (due to
Cog VM). Is there a reason to hang back - Teleplace has used Cog for
about a year already?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Henrik Sperre Johansen

On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote:

> Henrik Johansen wrote:
>> The code works on both Cog and Closure VMs though, so development can
>> continue on whatever VM you desire without a split in package
>> versions. As Cog is able to read closure-images, but not the other
>> way around, I imagine we will want to keep releasing official images
>> saved by the closure VM.
>
> IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already?


- Platform availability (64bit is not supported, iPhone/iPad VM's can't run them)
- Still buggy (I've reported 2 so far)
- No process established yet how / if  to synch with current VMMaker (which contains quite a lot of fixes not found in Cog)
- Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably)
- No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Schwab,Wilhelm K
I am very excited about Cog, but also have to urge some caution: There was mention of Seaside not running on it, which is a show-stopper until fixed.



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Johansen
Sent: Tuesday, June 22, 2010 10:10 AM
To: [hidden email]
Subject: Re: [Pharo-project] Cog - dumb question


On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote:

> Henrik Johansen wrote:
>> The code works on both Cog and Closure VMs though, so development can
>> continue on whatever VM you desire without a split in package
>> versions. As Cog is able to read closure-images, but not the other
>> way around, I imagine we will want to keep releasing official images
>> saved by the closure VM.
>
> IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already?


- Platform availability (64bit is not supported, iPhone/iPad VM's can't run them)
- Still buggy (I've reported 2 so far)
- No process established yet how / if  to synch with current VMMaker (which contains quite a lot of fixes not found in Cog)
- Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably)
- No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Eliot Miranda-2
In reply to this post by Henrik Sperre Johansen
Hi All,

On Tue, Jun 22, 2010 at 8:09 AM, Henrik Johansen <[hidden email]> wrote:

On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote:

> Henrik Johansen wrote:
>> The code works on both Cog and Closure VMs though, so development can
>> continue on whatever VM you desire without a split in package
>> versions. As Cog is able to read closure-images, but not the other
>> way around, I imagine we will want to keep releasing official images
>> saved by the closure VM.
>
> IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already?


- Platform availability (64bit is not supported, iPhone/iPad VM's can't run them)
- Still buggy (I've reported 2 so far)
- No process established yet how / if  to synch with current VMMaker (which contains quite a lot of fixes not found in Cog)
- Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably)
- No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around.

I just want to endorse Henry's caution.  Clearly Cog is not ready to replace the existing VMs.  But do note that the Stack VM is included and that should be a portable VM.  I know that John McIntosh is looking at the Stack VM for iPhone.  The Stack VM is not a JIT and so is cross-platform; but it does use the same context-to-stack mapping scheme as the Cog VM.  What I hope will happen is that the Stack VM will replace the standard VM pretty soon, and that, because the Stack VM and the Cog VM can read each other's images that once the VM maintainers have integrated the Stack VM into the VM sources then images will move forward to the Cog format.  But for the present Henry is absolutely right.

best
Eliot




Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Yanni Chiu
In reply to this post by Schwab,Wilhelm K
Schwab,Wilhelm K wrote:
> I am very excited about Cog, but also have to urge some caution: There was mention of Seaside not running on it, which is a show-stopper until fixed.

Yes, that's what I meant by fix major bugs. But given the level of
excitement and interest, I figured these would be fixed, long before a
Pharo 1.2 would be released.

>> Henrik Johansen wrote:
>
> - Platform availability (64bit is not supported, iPhone/iPad VM's can't run them)
> - Still buggy (I've reported 2 so far)
> - No process established yet how / if  to synch with current VMMaker (which contains quite a lot of fixes not found in Cog)
> - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably)
> - No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around.

Yes, these are all very good points. The last point is the best, there's
no reason not to, since Cog can translate it.

I just have a feeling that dragging out a transition like this would be
more painful than a quick leap. I know that for me, as soon as Seaside
runs on MacOSX and Linux, I'd make the move. I'd probably hold back if
it was only 1.5 times speed-up, but likely 3 times or more, is hard to
resist. It's not easy to always know which VM you're running, so there's
almost certainly going to be image mis-matches, the longer the
transition takes.

Now that I think about it, for me, I can simply change the two VM's I
use. It's just the image builders that need to pick up the right VM (if
they happen to use Cog day-to-day), and keep everything straight.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Cog - dumb question

Stéphane Ducasse
We will see :)
let us make 1.2 another cool version. For now let us release 1.1
each step at the time....

Stef
On Jun 22, 2010, at 8:17 PM, Yanni Chiu wrote:

> Schwab,Wilhelm K wrote:
>> I am very excited about Cog, but also have to urge some caution: There was mention of Seaside not running on it, which is a show-stopper until fixed.
>
> Yes, that's what I meant by fix major bugs. But given the level of excitement and interest, I figured these would be fixed, long before a Pharo 1.2 would be released.
>
>>> Henrik Johansen wrote:
>> - Platform availability (64bit is not supported, iPhone/iPad VM's can't run them)
>> - Still buggy (I've reported 2 so far)
>> - No process established yet how / if  to synch with current VMMaker (which contains quite a lot of fixes not found in Cog)
>> - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably)
>> - No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around.
>
> Yes, these are all very good points. The last point is the best, there's no reason not to, since Cog can translate it.
>
> I just have a feeling that dragging out a transition like this would be more painful than a quick leap. I know that for me, as soon as Seaside runs on MacOSX and Linux, I'd make the move. I'd probably hold back if it was only 1.5 times speed-up, but likely 3 times or more, is hard to resist. It's not easy to always know which VM you're running, so there's almost certainly going to be image mis-matches, the longer the transition takes.
>
> Now that I think about it, for me, I can simply change the two VM's I use. It's just the image builders that need to pick up the right VM (if they happen to use Cog day-to-day), and keep everything straight.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Cog direction (was: Cog - dumb question)

David T. Lewis
In reply to this post by Eliot Miranda-2
Excerpted from thread on pharo list:

On Tue, Jun 22, 2010 at 10:22:18AM -0700, Eliot Miranda wrote:
>
> What I hope will
> happen is that the Stack VM will replace the standard VM pretty soon, and
> that, because the Stack VM and the Cog VM can read each other's images that
> once the VM maintainers have integrated the Stack VM into the VM sources
> then images will move forward to the Cog format.

This sounds like a very reasonable and achievable goal to me.

Dave


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project