4.6/5.0 -- how to help users manage different formats?
Locked
4.6/5.0 -- how to help users manage different formats?
 
|
Hi Eliot and all, for this release I wonder whether we should provide
alternate binary's in the bin directory of the VM to help users manage the different image formats. What if, in addition to bin/squeak, Cog would include bin/cog and Spur would include bin/spur. In that case, although bin/squeak would be whoever was installed last, at least users could be explicit about which VM they want to launch which image. I know we also talked about some universal bin/squeak which could id the image format and launch the appropriate binary, which would be great. We should plan on doing _something_ in this area for the release. |
|
|
What's happened to the "write once, run everywhere" that used to be
the hallmark of Smalltalk?
On 11.03.2015 21:34, Chris Muller
wrote:
Hi Eliot and all, for this release I wonder whether we should provide alternate binary's in the bin directory of the VM to help users manage the different image formats. What if, in addition to bin/squeak, Cog would include bin/cog and Spur would include bin/spur. In that case, although bin/squeak would be whoever was installed last, at least users could be explicit about which VM they want to launch which image. I know we also talked about some universal bin/squeak which could id the image format and launch the appropriate binary, which would be great. We should plan on doing _something_ in this area for the release. |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
On Wed, Mar 11, 2015 at 3:45 PM, Trygve Reenskaug <[hidden email]> wrote:
> What's happened to the "write once, run everywhere" that used to be the > hallmark of Smalltalk? LOL, nothing, all the code which has been written once can still be ran everywhere. This thread is about helping users manage the transition to the new image-format of the future for Squeak, Spur. |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Trygve
It's right where we left it. Spur introduces a new object memory
format, so we're doing the right thing: we're breaking the format and telling people. When you load packages into a Spur image, things will just work. When you load changesets, things will just work. As far as I know, we've taken care that ImageSegments will also load into Spur, and just work. But sometimes, if you want to actually make progress, you're going to have to bite the bullet and make breaking changes. frank On 11 March 2015 at 20:45, Trygve Reenskaug <[hidden email]> wrote: > What's happened to the "write once, run everywhere" that used to be the > hallmark of Smalltalk? > > > On 11.03.2015 21:34, Chris Muller wrote: > > Hi Eliot and all, for this release I wonder whether we should provide > alternate binary's in the bin directory of the VM to help users manage > the different image formats. > > What if, in addition to bin/squeak, Cog would include bin/cog and Spur > would include bin/spur. In that case, although bin/squeak would be > whoever was installed last, at least users could be explicit about > which VM they want to launch which image. > > I know we also talked about some universal bin/squeak which could id > the image format and launch the appropriate binary, which would be > great. > > We should plan on doing _something_ in this area for the release. > > > > > > |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
On Thu, Mar 12, 2015 at 7:24 AM, Frank Shearar <[hidden email]> wrote: It's right where we left it. Spur introduces a new object memory Ah, not quite. Image segments saved in 32-bit Spur will load in 32-bit Spur. Image segments saved in 64-bit Spur will load in 64-bit Spur. Image segments saved in Cog will load in Cog. But no interoperability is possible (yet!). And indeed I believe that image segments saved in the 64-bit Interpreter VM will only load in that 64-bit VM. The problem with image segments is that they are in the format of the VM's heap objects. However, Bert and I want co co-mentor a project to implement image-level support for loading segments from "foreign" object memories. Alas GSoC did not approve our organization this year. Maybe soon. Or maybe some student at one of the teaching institutions using Squeak or Pharo would be interested in having a go. Note that e.g. Fuel does not have this problem. But sometimes, if you want to actually make progress, you're going to +1. Spur has lots of advantages over the existing system but these can't be introduced without forcing a change to a new image and a new VM. frank best,
Eliot |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Frank Shearar-3
At the risk of giving myself an assignment ...
One thing we should do for the upcoming release is provide something in a welcome workspace that gives a clear explanation of Spur from an end user perspective. Something along the lines of what it is, why we are doing it now, and what you (the end user) will gain from it now and in the future. This should be at the "elevator speech" level of detail, as opposed to deep technical details (for which we just give a pointer to Eliot's blog). Dave > It's right where we left it. Spur introduces a new object memory > format, so we're doing the right thing: we're breaking the format and > telling people. > > When you load packages into a Spur image, things will just work. When > you load changesets, things will just work. As far as I know, we've > taken care that ImageSegments will also load into Spur, and just work. > > But sometimes, if you want to actually make progress, you're going to > have to bite the bullet and make breaking changes. > > frank > > On 11 March 2015 at 20:45, Trygve Reenskaug <[hidden email]> wrote: >> What's happened to the "write once, run everywhere" that used to be the >> hallmark of Smalltalk? >> >> >> On 11.03.2015 21:34, Chris Muller wrote: >> >> Hi Eliot and all, for this release I wonder whether we should provide >> alternate binary's in the bin directory of the VM to help users manage >> the different image formats. >> >> What if, in addition to bin/squeak, Cog would include bin/cog and Spur >> would include bin/spur. In that case, although bin/squeak would be >> whoever was installed last, at least users could be explicit about >> which VM they want to launch which image. >> >> I know we also talked about some universal bin/squeak which could id >> the image format and launch the appropriate binary, which would be >> great. >> >> We should plan on doing _something_ in this area for the release. >> >> >> >> >> >> > |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Eliot Miranda-2
>> It's right where we left it. Spur introduces a new object memory
>> format, so we're doing the right thing: we're breaking the format and >> telling people. >> >> When you load packages into a Spur image, things will just work. When >> you load changesets, things will just work. As far as I know, we've >> taken care that ImageSegments will also load into Spur, and just work. > > > Ah, not quite. Image segments saved in 32-bit Spur will load in 32-bit > Spur. Image segments saved in 64-bit Spur will load in 64-bit Spur. Image > segments saved in Cog will load in Cog. But no interoperability is possible > (yet!). And indeed I believe that image segments saved in the 64-bit > Interpreter VM will only load in that 64-bit VM. 64-bit will not be ready in time for 5.0 on 4/30 right? > The problem with image segments is that they are in the format of the VM's > heap objects. However, Bert and I want co co-mentor a project to implement > image-level support for loading segments from "foreign" object memories. > Alas GSoC did not approve our organization this year. Maybe soon. Or maybe > some student at one of the teaching institutions using Squeak or Pharo would > be interested in having a go. > > Note that e.g. Fuel does not have this problem. Nor does Ma Object Serializer. Ma Object Serializer has been updated to be transparently Spur compatible, so for 32-bit systems anyway, one could load ImageSegment file into a Cog image, save it with Ma, go into spur and load it with Ma, and then finally save it as ImageSegment. You could even stay as Ma for a while because I intend to do the same for 64-bit. > +1. Spur has lots of advantages over the existing system but these can't be > introduced without forcing a change to a new image and a new VM. Now that we've answered the troll-style question extensively, may we please talk about ideas to help users manage multiple formats? |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Eliot Miranda-2
Hey Eliot,
On 12.03.2015, at 17:44, Eliot Miranda <[hidden email]> wrote: > > The problem with image segments is that they are in the format of the VM's heap objects. However, Bert and I want co co-mentor a project to implement image-level support for loading segments from "foreign" object memories. Alas GSoC did not approve our organization this year. Maybe soon. Or maybe some student at one of the teaching institutions using Squeak or Pharo would be interested in having a go. Can you or Bert give me an outline or a heads up? (maybe off-list…) Best -Tobias |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Chris Muller-3
On Thu, Mar 12, 2015 at 3:51 PM, Chris Muller <[hidden email]> wrote: >> It's right where we left it. Spur introduces a new object memory Right. I don't even have the optimized 64-bit Spur StackInterpreter working on Mac. The assert VM works fine, but optimized crashes on start-up. Let alone having a working 64-bit Spur StackInterpreter on Windows and Mac. And let alone having a 64-bit Spur Cog JIT. > The problem with image segments is that they are in the format of the VM's best,
Eliot |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Tobias Pape
On Thu, Mar 12, 2015 at 3:56 PM, Tobias Pape <[hidden email]> wrote: Hey Eliot, An ImageSegment is a WordArray whose contents are a sequence of heap objects in the VM's native object format. A segment is loaded by invoking a primitive that swizzles the pointers in the word array so that they become valid objects, and then shortening the word array, leaving the objects behind in memory. Since the contents of the WordArray are specific to a given VM architecture one cannot use the primitive loading mechanism to load segments from VMs with different object representations. Here different means - 32-bit V3 vs 64-bit V3 - the contents of the CompactClassesArray (if they're not the same in the saving and loading system, objects could be loaded with the wrong class, which could crash the VM) - V3 vs Spur - Spur 32-bit vs Spur 64-bit But there is no reason why Smalltalk code could not parse the contents of the WordArray and hence load objects by creating them based on the data in the WordArray. This would allow image segments to be loaded in any format the Smalltalk code supported (and it would be interesting to compare performance and see how much slower "synthesized" loading would be). This would provide legacy support for segments from "old" versions, and maybe even provide a oath to adopting a more neutral format such as Fuel. To implement such a system one would have to understand the object formats of each system, using the VM source code as a guide, both the object representation and the load and save primitives themselves. Does this answer your question? (maybe off-list…) best,
Eliot |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
Hi eliot
On 14.03.2015, at 13:32, Eliot Miranda <[hidden email]> wrote: > On Thu, Mar 12, 2015 at 3:56 PM, Tobias Pape <[hidden email]> wrote: > Hey Eliot, > > On 12.03.2015, at 17:44, Eliot Miranda <[hidden email]> wrote: > > > > > The problem with image segments is that they are in the format of the VM's heap objects. However, Bert and I want co co-mentor a project to implement image-level support for loading segments from "foreign" object memories. Alas GSoC did not approve our organization this year. Maybe soon. Or maybe some student at one of the teaching institutions using Squeak or Pharo would be interested in having a go. > > Can you or Bert give me an outline or a heads up? > An ImageSegment is a WordArray whose contents are a sequence of heap objects in the VM's native object format. A segment is loaded by invoking a primitive that swizzles the pointers in the word array so that they become valid objects, and then shortening the word array, leaving the objects behind in memory. Since the contents of the WordArray are specific to a given VM architecture one cannot use the primitive loading mechanism to load segments from VMs with different object representations. Here different means > - 32-bit V3 vs 64-bit V3 > - the contents of the CompactClassesArray (if they're not the same in the saving and loading system, objects could be loaded with the wrong class, which could crash the VM) > - V3 vs Spur > - Spur 32-bit vs Spur 64-bit > > But there is no reason why Smalltalk code could not parse the contents of the WordArray and hence load objects by creating them based on the data in the WordArray. This would allow image segments to be loaded in any format the Smalltalk code supported (and it would be interesting to compare performance and see how much slower "synthesized" loading would be). This would provide legacy support for segments from "old" versions, and maybe even provide a oath to adopting a more neutral format such as Fuel. > > To implement such a system one would have to understand the object formats of each system, using the VM source code as a guide, both the object representation and the load and save primitives themselves. > > Does this answer your question? > Yes. Thank you :) I'll see whether some students could work with that… (no promise tho) Best -Tobias > > (maybe off-list…) > > Best > -Tobias |
Re: 4.6/5.0 -- how to help users manage different formats?
|
Administrator
|
In reply to this post by Chris Muller-3
Coincidentally, we just discussed "trolling" on the Pharo list. The consensus was that the key is whether the intention is disruption rather than productivity (and Wikipedia agrees [1]). I interpreted the post rather as a concern about a core value. And I hope we can give the inventor of MVC the benefit of the doubt ;) IMHO is is an honor to have him still a part of our community. [1] "posting… with the deliberate intent of… disrupting normal on-topic discussion" - http://en.wikipedia.org/wiki/Troll_%28Internet%29
Cheers,
Sean |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
On Sat, Mar 14, 2015 at 10:40 AM, Sean P. DeNigris
<[hidden email]> wrote: > Chris Muller-3 wrote >> Now that we've answered the troll-style question extensively > > Coincidentally, we just discussed "trolling" on the Pharo list. The > consensus was that the key is whether the intention is disruption rather > than productivity (and Wikipedia agrees [1]). I interpreted the post rather > as a concern about a core value. > > And I hope we can give the inventor of MVC the benefit of the doubt ;) IMHO > is is an honor to have him still a part of our community. I have no doubts Trygve was joking, and so was I, while trying to discuss this issue of having multiple formats.. |
re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by David T. Lewis
> At the risk of giving myself an assignment ... Yes, I vote for you to create an issue for this on bugs.squeak.org and assign it to yourself. I'll happily review it. ;) -C -- Craig Latta netjam.org March 2015: + 1 510 480 5860 (SMS ok) +31 20 893 2796 (no SMS) afterward: +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Re: 4.6/5.0 -- how to help users manage different formats?
|
|
In reply to this post by Chris Muller-3
A couple of folks have contacted me privately, and suggested that I
may have misinterpreted Trygve. Trygve, if you were not making a joke, I apologize. Spur is remarkably backward compatible code-wise, I thought you were giving Eliot a hard time (in fun) about the image format change. My comment was a dumb attempt to play along in the "joke" too. If I've offended you, I apologize, please forgive my misunderstanding. On Sun, Mar 15, 2015 at 1:48 PM, Chris Muller <[hidden email]> wrote: > On Sat, Mar 14, 2015 at 10:40 AM, Sean P. DeNigris > <[hidden email]> wrote: >> Chris Muller-3 wrote >>> Now that we've answered the troll-style question extensively >> >> Coincidentally, we just discussed "trolling" on the Pharo list. The >> consensus was that the key is whether the intention is disruption rather >> than productivity (and Wikipedia agrees [1]). I interpreted the post rather >> as a concern about a core value. >> >> And I hope we can give the inventor of MVC the benefit of the doubt ;) IMHO >> is is an honor to have him still a part of our community. > > I have no doubts Trygve was joking, and so was I, while trying to > discuss this issue of having multiple formats.. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |