Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.222.mcz
==================== Summary ====================
Name: VMMaker-dtl.222 Author: dtl Time: 19 March 2011, 11:09:09 am UUID: 809d5eb5-6f73-4e6a-a595-428ed4536dc0 Ancestors: VMMaker-dtl.221
Fix MiscPrimitivePluginTest to properly test behavior of #primitiveFindSubstring and verify presence of a fix in TMethod>>argConversionExprFor:stackIndex: that performs type checking on string arguments.
On 19 March 2011 17:09, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.222.mcz
==================== Summary ====================
Name: VMMaker-dtl.222 Author: dtl Time: 19 March 2011, 11:09:09 am UUID: 809d5eb5-6f73-4e6a-a595-428ed4536dc0 Ancestors: VMMaker-dtl.221
Fix MiscPrimitivePluginTest to properly test behavior of #primitiveFindSubstring and verify presence of a fix in TMethod>>argConversionExprFor:stackIndex: that performs type checking on string arguments.
Dave, could you check it for oscog branch too?
On Sat, Mar 19, 2011 at 04:39:05PM +0100, Igor Stasenko wrote:
On 19 March 2011 17:09, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.222.mcz
==================== Summary ====================
Name: VMMaker-dtl.222 Author: dtl Time: 19 March 2011, 11:09:09 am UUID: 809d5eb5-6f73-4e6a-a595-428ed4536dc0 Ancestors: VMMaker-dtl.221
Fix MiscPrimitivePluginTest to properly test behavior of #primitiveFindSubstring and verify presence of a fix in TMethod>>argConversionExprFor:stackIndex: that performs type checking on string arguments.
Dave, could you check it for oscog branch too?
Hi Igor,
Actually I was going to reply to your earlier question about tests that you can run in an image (without VMMaker) that provide coverage for the VM. But as soon as I looked at it I realized that I has screwed this one up, so I fixed it and this the change you see posted here.
There are a number of tests in the VMMaker package, mostly accumlated during bug fixing but also some stuff to support the work I did to support 64 and 32 bit images from a single code base (hence not immediately relevant for inclusion in oscog). The two tests that might be useful outside of VMMaker are JPEGReadWriter2PluginTest and MiscPrimitivePluginTest, so I am attaching fileouts for these two. Have a look and see if you thing they should go in the main Squeak/Pharo images, or stay in VMMaker(s). These two along with BitBltSimulationTest would also be suitable to include in oscog.
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
Dave
On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis lewis@mail.msen.comwrote:
On Sat, Mar 19, 2011 at 04:39:05PM +0100, Igor Stasenko wrote:
On 19 March 2011 17:09, squeak-dev-noreply@lists.squeakfoundation.org
wrote:
Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.222.mcz
==================== Summary ====================
Name: VMMaker-dtl.222 Author: dtl Time: 19 March 2011, 11:09:09 am UUID: 809d5eb5-6f73-4e6a-a595-428ed4536dc0 Ancestors: VMMaker-dtl.221
Fix MiscPrimitivePluginTest to properly test behavior of
#primitiveFindSubstring and verify presence of a fix in TMethod>>argConversionExprFor:stackIndex: that performs type checking on string arguments.
Dave, could you check it for oscog branch too?
Hi Igor,
Actually I was going to reply to your earlier question about tests that you can run in an image (without VMMaker) that provide coverage for the VM. But as soon as I looked at it I realized that I has screwed this one up, so I fixed it and this the change you see posted here.
There are a number of tests in the VMMaker package, mostly accumlated during bug fixing but also some stuff to support the work I did to support 64 and 32 bit images from a single code base (hence not immediately relevant for inclusion in oscog). The two tests that might be useful outside of VMMaker are JPEGReadWriter2PluginTest and MiscPrimitivePluginTest, so I am attaching fileouts for these two. Have a look and see if you thing they should go in the main Squeak/Pharo images, or stay in VMMaker(s). These two along with BitBltSimulationTest would also be suitable to include in oscog.
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
I think we urgently need to merge. I haven't looked yet but has Interpreter been refactored out from under ObjectMemory? If it hasn't would you be happy for me to do that? Things that I think need to be done to Interpreter are
a) refactor it out from under ObjectMemory and under InterpreterPrimitives b) use NewObjectMemory (it's a tad faster) c) throw away four of the method cache fields used only by Jitter, which de facto is now obsolete, and use the StackInterpreter's folding of primitiveIndex and primitiveFunction (it's a tad faster) d) also use platform-order floats (it's a tad faster)
What is useful about Interpreter is a) it doesn't need a threaded or interrupt-driven heartbeat so it is simpler to port to bare metal b) it uses contexts and lacks all the complexity of context-to-stack mapping and so for many VM experiments it is significantly simpler to understand and extend, and for certain context-intensive computations it may be faster
So for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line.
are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
best, Eliot
Dave
On 19 March 2011 19:33, Eliot Miranda eliot.miranda@gmail.com wrote:
So for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line. are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
I am.
best, Eliot
On Sat, 19 Mar 2011, Eliot Miranda wrote:
I think we urgently need to merge. I haven't looked yet but has Interpreter been refactored out from under ObjectMemory? If it hasn't
Not yet.
would you be happy for me to do that? Things that I think need to be done to Interpreter are
a) refactor it out from under ObjectMemory and under InterpreterPrimitives b) use NewObjectMemory (it's a tad faster) c) throw away four of the method cache fields used only by Jitter, which de facto is now obsolete, and use the StackInterpreter's folding of primitiveIndex and primitiveFunction (it's a tad faster) d) also use platform-order floats (it's a tad faster)
What is useful about Interpreter is a) it doesn't need a threaded or interrupt-driven heartbeat so it is simpler to port to bare metal b) it uses contexts and lacks all the complexity of context-to-stack mapping and so for many VM experiments it is significantly simpler to understand and extend, and for certain context-intensive computations it may be faster
So for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line.
are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
I'm not really a VM dev, but I agree. :)
Levente
best, Eliot
On 19.03.2011, at 19:33, Eliot Miranda wrote:
I think we urgently need to merge.
Yep.
I haven't looked yet but has Interpreter been refactored out from under ObjectMemory? If it hasn't would you be happy for me to do that?
That would be awesome!
Things that I think need to be done to Interpreter are
a) refactor it out from under ObjectMemory and under InterpreterPrimitives b) use NewObjectMemory (it's a tad faster) c) throw away four of the method cache fields used only by Jitter, which de facto is now obsolete, and use the StackInterpreter's folding of primitiveIndex and primitiveFunction (it's a tad faster) d) also use platform-order floats (it's a tad faster)
What is useful about Interpreter is a) it doesn't need a threaded or interrupt-driven heartbeat so it is simpler to port to bare metal b) it uses contexts and lacks all the complexity of context-to-stack mapping and so for many VM experiments it is significantly simpler to understand and extend, and for certain context-intensive computations it may be faster
So for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line.
are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
+1
- Bert -
Hi Eliot, sorry I could not reply earlier.
Yes I agree it is worthwhile (and tedious) to get to one main line. I'm pretty good at being tedious, so I can probably help with some of that ;) Other comments in line below, mainly related to the VMMaker package as opposed to support code, build processes, etc.
On Sat, Mar 19, 2011 at 11:33:36AM -0700, Eliot Miranda wrote:
On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis lewis@mail.msen.comwrote:
<snip>
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
I think we urgently need to merge. I haven't looked yet but has Interpreter been refactored out from under ObjectMemory? If it hasn't would you be happy for me to do that? Things that I think need to be done to Interpreter are
a) refactor it out from under ObjectMemory and under InterpreterPrimitives b) use NewObjectMemory (it's a tad faster) c) throw away four of the method cache fields used only by Jitter, which de facto is now obsolete, and use the StackInterpreter's folding of primitiveIndex and primitiveFunction (it's a tad faster) d) also use platform-order floats (it's a tad faster)
No, I have not done any of this refactoring. So far I have only incorporated simple things when I am confident that I understand the impact. Which makes for slow going giving the range of things I don't understand. I've also focused on trying to tidy up things that show up as "lots of changes" in a Monticello browser, but which are often just minor changes or cosmetic differences.
If you are able to step in and do some of the more complex refactoring, that will get the job done much faster and better than waiting for me to figure it out, so yes please!!! The only concern here is that along the way we maintain the ability of the interpreter to read and write old (6502 and 68000) images, and to continue to be able to build the 64-bit image interpreter from the single code base. It hopefully is a non-issue, but in any case I think I can help with that aspect of it, so between us I'm sure we can make it work.
What is useful about Interpreter is a) it doesn't need a threaded or interrupt-driven heartbeat so it is simpler to port to bare metal b) it uses contexts and lacks all the complexity of context-to-stack mapping and so for many VM experiments it is significantly simpler to understand and extend, and for certain context-intensive computations it may be faster
So for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line.
are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
I agree.
Thanks, Dave
Hi Eliot--
...for me its worth keeping all these VMs, but the merge task is tedious and expensive so I would like there to be only one main line.
are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in agreement?
Yes!
-C
-- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
-- Matthew Fulmer (a.k.a. Tapple)
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
- Bert -
On 20 March 2011 12:37, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
Yes, but i don't want it to be same, so its not lost in a list of Squeak (non-Cog) VMMaker packages.
- Bert -
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:
On 20 March 2011 12:37, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
Yes, but i don't want it to be same, so its not lost in a list of Squeak (non-Cog) VMMaker packages.
If multiple people are going to be committing to the oscog branch, then I think that Matthew is pointing us in a good direction. Just to try it out, I made a local repository on my own hard drive, and copied all of the cog MCZs into it from SqueakSource. It is simple (though a bit tedious) to set up a repository like this on SqueakSource such that we would have two companion VMMaker repositories while working through the code merge. It does look to me like it this organization would make it easier to keep track of things, and I will be happy to set it up if you (Eliot and Igor especially) agree it is the right thing to do.
So let me ask a couple of questions:
- Eliot, are you happy to have other people commit MCZ updates for the oscog branch? In particular, is it OK if I do that?
- Are you comfortable working with two repositories as opposed to keeping both branches in one repository as currently set up?
If yes to both, then I will volunteer to set up the SqueakSource project to do this. After it is set up, we can turn on email commit notifications so that it will work exactly like the current VMMaker project. Assuming that we successfully accomplish the merge, we can move things back into one repository at a later date.
Dave
On 22 March 2011 22:30, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:
On 20 March 2011 12:37, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into reconciling the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
Yes, but i don't want it to be same, so its not lost in a list of Squeak (non-Cog) VMMaker packages.
If multiple people are going to be committing to the oscog branch, then I think that Matthew is pointing us in a good direction. Just to try it out, I made a local repository on my own hard drive, and copied all of the cog MCZs into it from SqueakSource. It is simple (though a bit tedious) to set up a repository like this on SqueakSource such that we would have two companion VMMaker repositories while working through the code merge. It does look to me like it this organization would make it easier to keep track of things, and I will be happy to set it up if you (Eliot and Igor especially) agree it is the right thing to do.
So let me ask a couple of questions:
- Eliot, are you happy to have other people commit MCZ updates for
the oscog branch? In particular, is it OK if I do that?
- Are you comfortable working with two repositories as opposed to
keeping both branches in one repository as currently set up?
If yes to both, then I will volunteer to set up the SqueakSource project to do this. After it is set up, we can turn on email commit notifications so that it will work exactly like the current VMMaker project. Assuming that we successfully accomplish the merge, we can move things back into one repository at a later date.
Dave, one of the problems with having distributed branches that history is not so easily accessible (to check delta between two packages if they are in different repositories will be tedious task). I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
Dave
On Tue, Mar 22, 2011 at 11:01:04PM +0100, Igor Stasenko wrote:
On 22 March 2011 22:30, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:
On 20 March 2011 12:37, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote: > I have stayed away from committing anything directly to the oscog > branch out of concern that it may lead to confusion between the > two branches if my 'dtl' initials start showing up there. I do > have some changes that can be applied to oscog (mostly to get > rid of cosmetic differences between the two branches that clutter > up the Montecello browser). I've sent a few of these to Eliot but > I don't know if that is the preferred approach going forward. > Advice welcome, as I do want to put some more effort into reconciling > the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
Yes, but i don't want it to be same, so its not lost in a list of Squeak (non-Cog) VMMaker packages.
If multiple people are going to be committing to the oscog branch, then I think that Matthew is pointing us in a good direction. Just to try it out, I made a local repository on my own hard drive, and copied all of the cog MCZs into it from SqueakSource. It is simple (though a bit tedious) to set up a repository like this on SqueakSource such that we would have two companion VMMaker repositories while working through the code merge. It does look to me like it this organization would make it easier to keep track of things, and I will be happy to set it up if you (Eliot and Igor especially) agree it is the right thing to do.
So let me ask a couple of questions:
- Eliot, are you happy to have other people commit MCZ updates for
the oscog branch? In particular, is it OK if I do that?
- Are you comfortable working with two repositories as opposed to
keeping both branches in one repository as currently set up?
If yes to both, then I will volunteer to set up the SqueakSource project to do this. After it is set up, we can turn on email commit notifications so that it will work exactly like the current VMMaker project. Assuming that we successfully accomplish the merge, we can move things back into one repository at a later date.
Dave, one of the problems with having distributed branches that history is not so easily accessible (to check delta between two packages if they are in different repositories will be tedious task). I personally don't feel a need to do that right now.
OK
We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
Yes, something certainly seems wrong there. I don't know if it is associated with the commit notifications, or just something generally flakey with the upload mechanism.
Dave
On Tue, 22 Mar 2011, Igor Stasenko wrote:
I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
That's a nice idea, and hopefully SqueakSource 3 is implemented that way, but squeaksource.com uses SqueakSource 1. I guess it uses some old version of Squeak (3.9 maybe), where the diff algorithm, MC, collections, streams, compression and the VM are much slower than what's available today.
Levente
Dave
-- Best regards, Igor Stasenko AKA sig.
On 23 March 2011 05:43, Levente Uzonyi leves@elte.hu wrote:
On Tue, 22 Mar 2011, Igor Stasenko wrote:
I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
That's a nice idea, and hopefully SqueakSource 3 is implemented that way, but squeaksource.com uses SqueakSource 1. I guess it uses some old version of Squeak (3.9 maybe), where the diff algorithm, MC, collections, streams, compression and the VM are much slower than what's available today.
Any insights how we can migrate to newer version (if that's possible at all)?
Levente
Dave
-- Best regards, Igor Stasenko AKA sig.
On Wed, Mar 23, 2011 at 05:43:24AM +0100, Levente Uzonyi wrote:
On Tue, 22 Mar 2011, Igor Stasenko wrote:
I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
That's a nice idea, and hopefully SqueakSource 3 is implemented that way, but squeaksource.com uses SqueakSource 1. I guess it uses some old version of Squeak (3.9 maybe), where the diff algorithm, MC, collections, streams, compression and the VM are much slower than what's available today.
Squeaksource runs on Squeak 3.6 or 3.7, and Seaside 1.x, to my knowledge
Am 2011-03-23 um 17:49 schrieb Matthew Fulmer:
On Wed, Mar 23, 2011 at 05:43:24AM +0100, Levente Uzonyi wrote:
On Tue, 22 Mar 2011, Igor Stasenko wrote:
I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
That's a nice idea, and hopefully SqueakSource 3 is implemented that way, but squeaksource.com uses SqueakSource 1. I guess it uses some old version of Squeak (3.9 maybe), where the diff algorithm, MC, collections, streams, compression and the VM are much slower than what's available today.
Squeaksource runs on Squeak 3.6 or 3.7, and Seaside 1.x, to my knowledge
It is running on Squeak 3.8 with Seaside 2.7 and MEWA as description framework (cf. Magritte)
So Long, -Tobias
Am 2011-03-23 um 05:43 schrieb Levente Uzonyi:
On Tue, 22 Mar 2011, Igor Stasenko wrote:
I personally don't feel a need to do that right now. We should really look why committing VMMaker package to SqS takes so much time. To my impression there is something wrong with uploading mechanism, because it should just transfer the file, save it on disk, close a connection and only then start various processing like send mails or computing diffs.
That's a nice idea, and hopefully SqueakSource 3 is implemented that way, but squeaksource.com uses SqueakSource 1. I guess it uses some old version of Squeak (3.9 maybe), where the diff algorithm, MC, collections, streams, compression and the VM are much slower than what's available today.
Not yet implemented that way. But I'll put that somewhere at the top of my list. I think that quite important.
So Long, -Tobias
On Tue, Mar 22, 2011 at 2:30 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:
On 20 March 2011 12:37, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.03.2011, at 19:48, Igor Stasenko wrote:
On 19 March 2011 19:44, Matthew Fulmer tapplek@gmail.com wrote:
On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
I have stayed away from committing anything directly to the oscog branch out of concern that it may lead to confusion between the two branches if my 'dtl' initials start showing up there. I do have some changes that can be applied to oscog (mostly to get rid of cosmetic differences between the two branches that clutter up the Montecello browser). I've sent a few of these to Eliot but I don't know if that is the preferred approach going forward. Advice welcome, as I do want to put some more effort into
reconciling
the code bases pretty soon.
MC supports branching, but lacks a built in way to mark the branches as seperate. We have 3 branches of Cobalt currently, and we keep them seperate by keeping them in seperate repositories.
Well, i am actually used different naming for oscog branch (VMMaker-<name>-oscog). And MC lists it as a separate package.
Because the MC UI treats everything up to the last hyphen as package
name (it does not look inside for the actual package name). If you named it e.g. VMMaker-<name>_oscog then it would be listed as the same package.
Yes, but i don't want it to be same, so its not lost in a list of Squeak (non-Cog) VMMaker packages.
If multiple people are going to be committing to the oscog branch, then I think that Matthew is pointing us in a good direction. Just to try it out, I made a local repository on my own hard drive, and copied all of the cog MCZs into it from SqueakSource. It is simple (though a bit tedious) to set up a repository like this on SqueakSource such that we would have two companion VMMaker repositories while working through the code merge. It does look to me like it this organization would make it easier to keep track of things, and I will be happy to set it up if you (Eliot and Igor especially) agree it is the right thing to do.
So let me ask a couple of questions:
- Eliot, are you happy to have other people commit MCZ updates for
the oscog branch? In particular, is it OK if I do that?
At the moment I'm a little uncomfortable with this. I think its still a few weeks too early. VMMaker-oscog.N is my reviewed/approved line of Cog sources. Once I'm using INRIA-Lille's Hudson server to do builds and have tests green etc I'll be happy either to allow VMMaker-oscog.N to be used by everybody, or to see it die and folded into VMMaker-whoever.N. Until then would you mind following Igor's convention, e.g. VMMaker-oscog-dtl.N?
- Are you comfortable working with two repositories as opposed to
keeping both branches in one repository as currently set up?
Doesn't seem to me to make sense. We've agreed that the right arc is to refactor Interpreter out from under ObjectMemory in which case we're clearly heading to merge to one VMMaker containing 4 or more VMs (context and stack interpreters, Cog and CogMT jits, with possibly/hopefully someone doing a StackMT). Splitting the VMMaker repository seems to be going against this direction. Nothing stops people form committing a VMMaker wherever they choose but in our main-line work I don't think we want to be using other than www.squeaksource.com/VMMaker.
But then I may be missing something.
BTW, I /so/ agree with Igor that "we should really look why committing VMMaker package to SqS takes so much time". It's agony :)
best, Eliot
If yes to both, then I will volunteer to set up the SqueakSource project to do this. After it is set up, we can turn on email commit notifications so that it will work exactly like the current VMMaker project. Assuming that we successfully accomplish the merge, we can move things back into one repository at a later date.
Dave
On Thu, Mar 24, 2011 at 11:30:58AM -0700, Eliot Miranda wrote:
On Tue, Mar 22, 2011 at 2:30 PM, David T. Lewis lewis@mail.msen.com wrote:
If multiple people are going to be committing to the oscog branch, then I think that Matthew is pointing us in a good direction. Just to try it out, I made a local repository on my own hard drive, and copied all of the cog MCZs into it from SqueakSource. It is simple (though a bit tedious) to set up a repository like this on SqueakSource such that we would have two companion VMMaker repositories while working through the code merge. It does look to me like it this organization would make it easier to keep track of things, and I will be happy to set it up if you (Eliot and Igor especially) agree it is the right thing to do.
So let me ask a couple of questions:
- Eliot, are you happy to have other people commit MCZ updates for
the oscog branch? In particular, is it OK if I do that?
At the moment I'm a little uncomfortable with this. I think its still a few weeks too early. VMMaker-oscog.N is my reviewed/approved line of Cog sources. Once I'm using INRIA-Lille's Hudson server to do builds and have tests green etc I'll be happy either to allow VMMaker-oscog.N to be used by everybody, or to see it die and folded into VMMaker-whoever.N. Until then would you mind following Igor's convention, e.g. VMMaker-oscog-dtl.N?
Yes, that sounds fine, thanks.
- Are you comfortable working with two repositories as opposed to
keeping both branches in one repository as currently set up?
Doesn't seem to me to make sense. We've agreed that the right arc is to refactor Interpreter out from under ObjectMemory in which case we're clearly heading to merge to one VMMaker containing 4 or more VMs (context and stack interpreters, Cog and CogMT jits, with possibly/hopefully someone doing a StackMT). Splitting the VMMaker repository seems to be going against this direction. Nothing stops people form committing a VMMaker wherever they choose but in our main-line work I don't think we want to be using other than www.squeaksource.com/VMMaker.
Agreed, Igor had the same view.
Dave
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Craig Latta -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Levente Uzonyi -
Matthew Fulmer -
squeak-dev-noreply＠lists.squeakfoundation.org -
Tobias Pape