VM Maker: VMMaker-dtl.222.mcz

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

VM Maker: VMMaker-dtl.222.mcz

squeak-dev-noreply
 
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.

Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

David T. Lewis
 
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?
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


JPEGReadWriter2PluginTest.st (4K) Download Attachment
MiscPrimitivePluginTest.st (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

Eliot Miranda-2
 


On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis <[hidden email]> wrote:
 
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?

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



Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

VMMaker branching

Tapple Gao
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)
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Bert Freudenberg


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 -


Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

Levente Uzonyi-2
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?
I'm not really a VM dev, but I agree. :)


Levente

>
> best,
> Eliot
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

Bert Freudenberg
In reply to this post by Eliot Miranda-2
 
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 -


Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker-dtl.222.mcz

David T. Lewis
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

Reply | Threaded
Open this post in threaded view
|

re: a single coherent factoring for all four VMs (was "VM Maker: VMMaker-dtl.222.mcz")

ccrraaiigg
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



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Levente Uzonyi-2
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Igor Stasenko
 
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.
>
>
Any insights how we can migrate to newer version (if that's possible at all)?

> Levente
>
>>
>>> Dave
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Tapple Gao
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)
Reply | Threaded
Open this post in threaded view
|

Re: VMMaker branching

Tobias Pape
 

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
12