[Pharo-project] Cog - dumb question
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
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
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?
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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Tuesday, June 22, 2010 10:10 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi All, On Tue, Jun 22, 2010 at 8:09 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (6)
-
David T. Lewis -
Eliot Miranda -
Henrik Johansen -
Schwab,Wilhelm K -
Stéphane Ducasse -
Yanni Chiu