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, <[hidden email]> 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? -- Best regards, Igor Stasenko AKA sig. |
On Sat, Mar 19, 2011 at 04:39:05PM +0100, Igor Stasenko wrote: > > On 19 March 2011 17:09, <[hidden email]> 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? 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 JPEGReadWriter2PluginTest.st (4K) Download Attachment MiscPrimitivePluginTest.st (10K) Download Attachment |
On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis <[hidden email]> 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 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
|
On 19 March 2011 19:33, Eliot Miranda <[hidden email]> 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 -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by David T. Lewis
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. -- Matthew Fulmer (a.k.a. Tapple) |
On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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) > -- Best regards, Igor Stasenko AKA sig. |
On 19.03.2011, at 19:48, Igor Stasenko wrote: > > On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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 <[hidden email]> wrote: > > > On 19.03.2011, at 19:48, Igor Stasenko wrote: > >> >> On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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 - -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Eliot Miranda-2
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? Levente > > best, > Eliot |
In reply to this post by Eliot Miranda-2
On 19.03.2011, at 19:33, Eliot Miranda wrote:
Yep.
That would be awesome!
+1 - Bert - |
In reply to this post by Eliot Miranda-2
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 <[hidden email]>wrote: > > > <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 |
In reply to this post by Eliot Miranda-2
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 |
In reply to this post by Igor Stasenko
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote: > > On 20 March 2011 12:37, Bert Freudenberg <[hidden email]> wrote: > > > > On 19.03.2011, at 19:48, Igor Stasenko wrote: > >> > >> On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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 <[hidden email]> wrote: > > On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote: >> >> On 20 March 2011 12:37, Bert Freudenberg <[hidden email]> wrote: >> > >> > On 19.03.2011, at 19:48, Igor Stasenko wrote: >> >> >> >> On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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 > -- Best regards, Igor Stasenko AKA sig. |
On Tue, Mar 22, 2011 at 11:01:04PM +0100, Igor Stasenko wrote: > > On 22 March 2011 22:30, David T. Lewis <[hidden email]> wrote: > > > > On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote: > >> > >> On 20 March 2011 12:37, Bert Freudenberg <[hidden email]> wrote: > >> > > >> > On 19.03.2011, at 19:48, Igor Stasenko wrote: > >> >> > >> >> On 19 March 2011 19:44, Matthew Fulmer <[hidden email]> 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 |
In reply to this post by Igor Stasenko
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 <[hidden email]> 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. > > > Levente > >> >>> Dave >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Levente Uzonyi-2
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 -- Matthew Fulmer (a.k.a. Tapple) |
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 |
Free forum by Nabble | Edit this page |