64 bit VM, source anyone?

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

64 bit VM, source anyone?

Göran Krampe-2
 
Hi folks!

Ok, so I was stupid enough to pick Debian Etch 64 bit when configuring
my last server. I knew it would bite me :) and here I am confused about
where to find a 64 bit VM to compile.

AFAIK lots of small patches have been flying around lately, but where
can I find a tar ball that has most of those? David, could you perhaps
create one?

Right now I use the binary i386 VM from ftp.squeak.org/debian, it seems
to work but looks slowish to me (tinyBenchmarks):

295 million bytecods/sec
9.5 million sends/sec

And regardless of that it seems reasonable to at least use a 64 bit VM.
:)

regards, Göran

---
Debian-40-etch-64-minimal:~/squeak# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 67
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
stepping        : 3
cpu MHz         : 1000.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm
cr8_legacy
bogomips        : 2063.10
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Bert Freudenberg
 

On Dec 4, 2007, at 18:56 , [hidden email] wrote:

> Right now I use the binary i386 VM from ftp.squeak.org/debian, it  
> seems
> to work but looks slowish to me (tinyBenchmarks):
>
> 295 million bytecods/sec
> 9.5 million sends/sec
>
> And regardless of that it seems reasonable to at least use a 64 bit  
> VM.
> :)



For one, try to not think with your gut ;)

Secondly, since there seems to be more interest lately, I'm sure  
someone will provide answers. At least you are the first one posting  
actual benchmark numbers - until now, I have only suspected a 64 bit  
VM would actually be slower than a 32 bit VM. It's what my gut tells  
me ;)

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Göran Krampe
 
Hi!

Bert Freudenberg <[hidden email]> wrote:

> On Dec 4, 2007, at 18:56 , [hidden email] wrote:
>
> > Right now I use the binary i386 VM from ftp.squeak.org/debian, it  
> > seems
> > to work but looks slowish to me (tinyBenchmarks):
> >
> > 295 million bytecods/sec
> > 9.5 million sends/sec
> >
> > And regardless of that it seems reasonable to at least use a 64 bit  
> > VM.
> > :)
>  
> For one, try to not think with your gut ;)

I know - I just felt tempted to give 64 bits a shot. It was probably a
bad decision. :)

> Secondly, since there seems to be more interest lately, I'm sure  
> someone will provide answers. At least you are the first one posting  
> actual benchmark numbers - until now, I have only suspected a 64 bit  
> VM would actually be slower than a 32 bit VM. It's what my gut tells  
> me ;)

I have absolutely no idea. Note though that the above numbers are for
the binary 32 bit VM running on Debian AMD64.
One can hope that the 64 bit VM is faster - but as you say, it might be
more realistic to be slower.

> - Bert -

regards, Göran

PS. The reason I said "slowish" is that... well, it is definitely not
much faster than my Pentium-M laptop. But after talking on IRC it became
clear that those numbers may very well be the expected.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Michael van der Gulik-2
 
On Dec 5, 2007 10:23 AM, <[hidden email]> wrote:


PS. The reason I said "slowish" is that... well, it is definitely not
much faster than my Pentium-M laptop. But after talking on IRC it became
clear that those numbers may very well be the expected.

Why would a 64-bit VM be slower?

Would it be because it's moving twice as much memory around, or because it's fiddling with 32-bit pointers using 64-bit registers?

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

David T. Lewis
In reply to this post by Göran Krampe-2
 
On Tue, Dec 04, 2007 at 07:56:54PM +0200, [hidden email] wrote:
> Ok, so I was stupid enough to pick Debian Etch 64 bit when configuring
> my last server. I knew it would bite me :) and here I am confused about
> where to find a 64 bit VM to compile.
>
> AFAIK lots of small patches have been flying around lately, but where
> can I find a tar ball that has most of those? David, could you perhaps
> create one?

Here is my current recipe:

1) Load VMMaker from SqueakMap.

2) Load the 32/64 bit-clean change sets. Presumably these will be merged into
VMMaker, but in the mean time John has stashed them in the SVN platform
sources. Go to platforms/Mac OS/vm/specialChangeSets/VmUpdates-dtl/ and
load the following change sets:
        VmUpdates-1001-dtl.1.cs
        VmUpdates-1002-dtl.1.cs
        VmUpdates-1003-dtl.1.cs
        VmUpdates-1004-dtl.1.cs
        VmUpdates-1005-dtl.1.cs
        VmUpdates-1006-dtl.1.cs
        JMM-VmUpdates32bitclean.2.cs

3) Load the fix from Mantis 5688 (otherwise you cannot use SqueakMap):
        http://bugs.squeak.org/view.php?id=5688

4) Load the fix from Mantis 5238 (needed only for 64 bit image, but you
may as well fix it while you're updating the rest):
        http://bugs.squeak.org/view.php?id=5238

5) Load the fix from Mantix 5403 (you don't need this, but I do):
        http://bugs.squeak.org/view.php?id=5403

6) Load SlangBrowser (you don't need it, but you'll want it if you are
going to look at the VM and plugin code):
        http://bugs.squeak.org/view.php?id=5932
        http://wiki.squeak.org/squeak/5916

7) Load the 32/64 bit updates for AsyncFilePlugin:
        http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001675.html

8) Load the 32/64 bit updates for FileCopyPlugin:
        http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001679.html

9) Load the 32/64 bit updates for LargeIntegersPlugin (unit tests only, the
plugin is good as long as you have installed the Mantis 5238 patch from step 4):
        http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001693.html

That's all for now,

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Re: 64 bit VM, source anyone?

ccrraaiigg
 

      Wow, I hope Tim makes a new VMMaker release before the recipe gets
to twenty steps. ;)

      I'm also guilty... I have changes for making LargeIntegersPlugin
run in simulation that I made last year and still haven't submitted to Tim.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Reply | Threaded
Open this post in threaded view
|

Re: Re: 64 bit VM, source anyone?

timrowledge
 

On 4-Dec-07, at 9:39 PM, Craig Latta wrote:

>
>     Wow, I hope Tim makes a new VMMaker release before the recipe  
> gets to twenty steps. ;)
There's a Simple Solution (tm) - $1,000,000 (CAD) would do nicely.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Inoculatte (v): To take coffee intravenously when you are running late


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Philippe Marschall
In reply to this post by Göran Krampe
 
2007/12/4, [hidden email] <[hidden email]>:

>
> Hi!
>
> Bert Freudenberg <[hidden email]> wrote:
> > On Dec 4, 2007, at 18:56 , [hidden email] wrote:
> >
> > > Right now I use the binary i386 VM from ftp.squeak.org/debian, it
> > > seems
> > > to work but looks slowish to me (tinyBenchmarks):
> > >
> > > 295 million bytecods/sec
> > > 9.5 million sends/sec
> > >
> > > And regardless of that it seems reasonable to at least use a 64 bit
> > > VM.
> > > :)
> >
> > For one, try to not think with your gut ;)
>
> I know - I just felt tempted to give 64 bits a shot. It was probably a
> bad decision. :)
>
> > Secondly, since there seems to be more interest lately, I'm sure
> > someone will provide answers. At least you are the first one posting
> > actual benchmark numbers - until now, I have only suspected a 64 bit
> > VM would actually be slower than a 32 bit VM. It's what my gut tells
> > me ;)
>
> I have absolutely no idea. Note though that the above numbers are for
> the binary 32 bit VM running on Debian AMD64.
> One can hope that the 64 bit VM is faster - but as you say, it might be
> more realistic to be slower.
On my machine, gentoo, Core 2 6600, 2.40GHz

64bit VM
509960159 bytecodes/sec; 14417913 sends/sec

32bit VM in emulation mode:
535845107 bytecodes/sec; 14728594 sends/sec

On the 32bit VM in emulation mode stuff like the cUrl plugin doesn't work.

Cheers
Philippe

> > - Bert -
>
> regards, Göran
>
> PS. The reason I said "slowish" is that... well, it is definitely not
> much faster than my Pentium-M laptop. But after talking on IRC it became
> clear that those numbers may very well be the expected.
>
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Göran Krampe
In reply to this post by Michael van der Gulik-2
 
Hi!

"Michael van der Gulik" <[hidden email]> wrote:

> On Dec 5, 2007 10:23 AM, <[hidden email]> wrote:
> > PS. The reason I said "slowish" is that... well, it is definitely not
> > much faster than my Pentium-M laptop. But after talking on IRC it became
> > clear that those numbers may very well be the expected.
>
> Why would a 64-bit VM be slower?
>
> Would it be because it's moving twice as much memory around, or because it's
> fiddling with 32-bit pointers using 64-bit registers?
>
> Gulik.

Ok, some clarifications:

1. My numbers were for the 32-bit binary VM, not a 64 bit VM.

2. There are reasons going both ways regarding speed. On the AMD64
architecture (see some details here: http://www.debian.org/ports/amd64)
there is potential for higher speed through better abilities for the
compiler BUT... there are also things slowing it down (8 bytes instead
of 4 in lots of situations). Also, I don't know how/if the gnuifier is
affected by this (perhaps not).

As Phillipe's post suggests - the 32 bit VM is actually a tad faster on
his box. It might be interesting to know if he has toyed with
optimization flags.

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Göran Krampe
In reply to this post by David T. Lewis
 
Hi David!

"David T. Lewis" <[hidden email]> wrote:

> On Tue, Dec 04, 2007 at 07:56:54PM +0200, [hidden email] wrote:
> > Ok, so I was stupid enough to pick Debian Etch 64 bit when configuring
> > my last server. I knew it would bite me :) and here I am confused about
> > where to find a 64 bit VM to compile.
> >
> > AFAIK lots of small patches have been flying around lately, but where
> > can I find a tar ball that has most of those? David, could you perhaps
> > create one?
>
> Here is my current recipe:
>
> 1) Load VMMaker from SqueakMap.
>
> 2) Load the 32/64 bit-clean change sets. Presumably these will be merged into
> VMMaker, but in the mean time John has stashed them in the SVN platform
> sources. Go to platforms/Mac OS/vm/specialChangeSets/VmUpdates-dtl/ and
> load the following change sets:
>         VmUpdates-1001-dtl.1.cs
>         VmUpdates-1002-dtl.1.cs
>         VmUpdates-1003-dtl.1.cs
>         VmUpdates-1004-dtl.1.cs
>         VmUpdates-1005-dtl.1.cs
>         VmUpdates-1006-dtl.1.cs
>         JMM-VmUpdates32bitclean.2.cs
>
> 3) Load the fix from Mantis 5688 (otherwise you cannot use SqueakMap):
>         http://bugs.squeak.org/view.php?id=5688
>
> 4) Load the fix from Mantis 5238 (needed only for 64 bit image, but you
> may as well fix it while you're updating the rest):
>         http://bugs.squeak.org/view.php?id=5238
>
> 5) Load the fix from Mantix 5403 (you don't need this, but I do):
>         http://bugs.squeak.org/view.php?id=5403
>
> 6) Load SlangBrowser (you don't need it, but you'll want it if you are
> going to look at the VM and plugin code):
>         http://bugs.squeak.org/view.php?id=5932
>         http://wiki.squeak.org/squeak/5916
>
> 7) Load the 32/64 bit updates for AsyncFilePlugin:
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001675.html
>
> 8) Load the 32/64 bit updates for FileCopyPlugin:
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001679.html
>
> 9) Load the 32/64 bit updates for LargeIntegersPlugin (unit tests only, the
> plugin is good as long as you have installed the Mantis 5238 patch from step 4):
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001693.html
>
> That's all for now,

Great, thank you! Now for some stupid questions:

- You use this recipe together with the current trunk in SVN or?
- ...eh, ok, perhaps that was my only question. :)

I am considering creating two Mercurial repos:

- One mirroring Ian's SVN.
- One that I push all the above into and make available for write to
people asking. :)
- And a VMMaker repo.

Why? Because:

1. I would like to see if that works technically.
2. I would like to see if there is enough interest from others in a more
distributed and open "experimental" approach to maintaining the VM.

> Dave

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Philippe Marschall
In reply to this post by Göran Krampe
 
2007/12/5, [hidden email] <[hidden email]>:

>
> Hi!
>
> "Michael van der Gulik" <[hidden email]> wrote:
> > On Dec 5, 2007 10:23 AM, <[hidden email]> wrote:
> > > PS. The reason I said "slowish" is that... well, it is definitely not
> > > much faster than my Pentium-M laptop. But after talking on IRC it became
> > > clear that those numbers may very well be the expected.
> >
> > Why would a 64-bit VM be slower?
> >
> > Would it be because it's moving twice as much memory around, or because it's
> > fiddling with 32-bit pointers using 64-bit registers?
> >
> > Gulik.
>
> Ok, some clarifications:
>
> 1. My numbers were for the 32-bit binary VM, not a 64 bit VM.
>
> 2. There are reasons going both ways regarding speed. On the AMD64
> architecture (see some details here: http://www.debian.org/ports/amd64)
> there is potential for higher speed through better abilities for the
> compiler BUT... there are also things slowing it down (8 bytes instead
> of 4 in lots of situations). Also, I don't know how/if the gnuifier is
> affected by this (perhaps not).
>
> As Phillipe's post suggests - the 32 bit VM is actually a tad faster on
> his box. It might be interesting to know if he has toyed with
> optimization flags.

Nah, he was happy that it worked.

Cheers
Philippe
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

David T. Lewis
In reply to this post by Göran Krampe
 
On Wed, Dec 05, 2007 at 10:26:44AM +0200, [hidden email] wrote:
>
> Great, thank you! Now for some stupid questions:
>
> - You use this recipe together with the current trunk in SVN or?
> - ...eh, ok, perhaps that was my only question. :)

Yes, I use the most recent SVN. This is important because it contains
a recent patch that supports the "32 bit clean" change sets.

> I am considering creating two Mercurial repos:
>
> - One mirroring Ian's SVN.
> - One that I push all the above into and make available for write to
> people asking. :)
> - And a VMMaker repo.

I don't know anything about Mercurial, but IMHO the only real
missing piece is that it would be helpful to get a copy of the
VMMaker Montecello files copied over to a SqueakSource repository.
That's not a tools problem, it's just a matter of convincing Tim
to do it.

> Why? Because:
>
> 1. I would like to see if that works technically.
> 2. I would like to see if there is enough interest from others in a more
> distributed and open "experimental" approach to maintaining the VM.

It would be an interesting experiment, but speaking just for myself
I'm more interested in making best use of existing resources (people
plus tools) and I really do not have enough free time to keep track
of more development repositories. Shucks, I can't even keep up with
all the different Squeak images, never mind tracking any more VM
projects ;)

Dave

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit VM, source anyone?

Göran Krampe
 
Hi!

"David T. Lewis" <[hidden email]> wrote:
> On Wed, Dec 05, 2007 at 10:26:44AM +0200, [hidden email] wrote:
> > Great, thank you! Now for some stupid questions:
> >
> > - You use this recipe together with the current trunk in SVN or?
> > - ...eh, ok, perhaps that was my only question. :)
>
> Yes, I use the most recent SVN. This is important because it contains
> a recent patch that supports the "32 bit clean" change sets.

Ok, got it.
 

> > I am considering creating two Mercurial repos:
> >
> > - One mirroring Ian's SVN.
> > - One that I push all the above into and make available for write to
> > people asking. :)
> > - And a VMMaker repo.
>
> I don't know anything about Mercurial, but IMHO the only real
> missing piece is that it would be helpful to get a copy of the
> VMMaker Montecello files copied over to a SqueakSource repository.

Mercurial is a really nice distributed SCM (like git, but simpler to
use).
The main advantage is of course that each developer has his/her own repo
and can publish a branch etc without ever talking to "upstream".

So I can easily publish a branch with all these 64 bit fixes and
eventually - when Ian has time - he could pull those into the official
repo, but in the meantime people can use my branch etc. Much like with
MC in fact.

> That's not a tools problem, it's just a matter of convincing Tim to do it.

Yeah... the VMMaker thingy I am not clear on how to best "synch" with
the rest. Put the mcz into the tree? Not sure.

> > Why? Because:
> >
> > 1. I would like to see if that works technically.
> > 2. I would like to see if there is enough interest from others in a more
> > distributed and open "experimental" approach to maintaining the VM.
>
> It would be an interesting experiment, but speaking just for myself
> I'm more interested in making best use of existing resources (people
> plus tools) and I really do not have enough free time to keep track
> of more development repositories.

I agree - but it would have been SOOO much nicer if I could just pull
your repo and go, go, go - instead of having to dig through a 20-step
guide. :)

> Shucks, I can't even keep up with
> all the different Squeak images, never mind tracking any more VM
> projects ;)

I agree. :) But hey, I just want to test it.
 
> Dave

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: Re: 64 bit VM, source anyone?

keith1y
In reply to this post by Göran Krampe
 
Sounds cool to me, I have been maintaining my changes as a mercurial queue.

Keith

> Great, thank you! Now for some stupid questions:
>
> - You use this recipe together with the current trunk in SVN or?
> - ...eh, ok, perhaps that was my only question. :)
>
> I am considering creating two Mercurial repos:
>
> - One mirroring Ian's SVN.
> - One that I push all the above into and make available for write to
> people asking. :)
> - And a VMMaker repo.
>
> Why? Because:
>
> 1. I would like to see if that works technically.
> 2. I would like to see if there is enough interest from others in a more
> distributed and open "experimental" approach to maintaining the VM.
>
>  
>> Dave
>>    
>
> regards, Göran
>
>  

Reply | Threaded
Open this post in threaded view
|

Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

Bert Freudenberg
In reply to this post by David T. Lewis
 
On Dec 5, 2007, at 12:07 , David T. Lewis wrote:

> On Wed, Dec 05, 2007 at 10:26:44AM +0200, [hidden email] wrote:
>> I am considering creating two Mercurial repos:
>>
>> - One mirroring Ian's SVN.
>> - One that I push all the above into and make available for write to
>> people asking. :)
>> - And a VMMaker repo.
>
> I don't know anything about Mercurial, but IMHO the only real
> missing piece is that it would be helpful to get a copy of the
> VMMaker Montecello files copied over to a SqueakSource repository.
> That's not a tools problem, it's just a matter of convincing Tim
> to do it.

Well, Tim made clear he is only willing to be convinced by money. So  
unless we can pony up a million in his preferred currency, we're  
going to have to do it ourselves.

>> Why? Because:
>>
>> 1. I would like to see if that works technically.
>> 2. I would like to see if there is enough interest from others in  
>> a more
>> distributed and open "experimental" approach to maintaining the VM.
>
> It would be an interesting experiment, but speaking just for myself
> I'm more interested in making best use of existing resources (people
> plus tools) and I really do not have enough free time to keep track
> of more development repositories. Shucks, I can't even keep up with
> all the different Squeak images, never mind tracking any more VM
> projects ;)

I'd be interested in having a single repository host both VMMaker  
sources and platform code. Maybe it even needs to host a VMMaker  
image. It's unbelievably hard to reproduce an official VM from first  
principles, let alone doing serious VM development on your own in a  
way that can be easily integrated back into the main line by the  
maintainers. We must find a way that lets them evaluate and integrate  
proposed changes without much effort. The current setup requires too  
much energy on both maintainers and developers, leading to stagnation.

The official maintainers carry a great responsibility, if something  
breaks, *they* are going to get blamed. So they are conservative, for  
a good reason. Other developers are maintaining their own VMs,  
without being able to effectively share. A de-centralized environment  
with a pull model a la Mercurial or git could help this a lot, as it  
allows independent development as well as easy cherry-picking for the  
official versions.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

Göran Krampe
 
Hi!

Bert Freudenberg <[hidden email]> wrote:
> I'd be interested in having a single repository host both VMMaker  
> sources and platform code. Maybe it even needs to host a VMMaker  
> image.

I agree, or we could do like we do in Gjallar - we have a script that
builds the base Gjallar image using Keith's Installer etc. This means we
could keep the VMMaker MC snapshot and the script inside Mercurial and
then just rig a make script that sucks down a vanilla base image, builds
a VMMaker image using the script and the VMMaker snapshot - and hey, we
could even instrument VMMaker so that it can be run headless and produce
the source code.

> It's unbelievably hard to reproduce an official VM from first  
> principles, let alone doing serious VM development on your own in a  
> way that can be easily integrated back into the main line by the  
> maintainers. We must find a way that lets them evaluate and integrate  
> proposed changes without much effort. The current setup requires too  
> much energy on both maintainers and developers, leading to stagnation.
>
> The official maintainers carry a great responsibility, if something  
> breaks, *they* are going to get blamed. So they are conservative, for  
> a good reason. Other developers are maintaining their own VMs,  
> without being able to effectively share. A de-centralized environment  
> with a pull model a la Mercurial or git could help this a lot, as it  
> allows independent development as well as easy cherry-picking for the  
> official versions.

Hear, hear. I will try to get the time to set up an SVN mirror (hgsvn or
Tailor) to begin with - then setup another repo and play with David's
recipe.

> - Bert -

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

timrowledge
 

On 5-Dec-07, at 5:48 AM, [hidden email] wrote:
> - and hey, we
> could even instrument VMMaker so that it can be run headless and  
> produce
> the source code.
Oh come on guys, RFTM! VMMaker has been scriptable since day zero. In  
fact to be strictly correct VMMaker is *only* scriptable; it's  
VMMakerTool that is interactive and provides the UI. It was originally  
written so the exobox could do automated nightly VM builds.

I do actually have a vmmaker project on squeaksource - dating from  
when it first started up - but I never really got into the habit of  
using it because - IIRC - I had a lot of problems. I just tried to  
take a look and the site isn't even up right now. Doesn't inspire a  
lot of confidence.

Ideally, yes a more public repository than my hard disc farm would be  
nice. We really ought to have a copy of the relevant version of the  
vmmaker package in the svn tree for each release - and we really ought  
not have so many layers of crap stuffed into the svn tree!  I suppose  
an image prebuilt for each release would be nice but there is after  
all the developer image being maintained anyway. A direct interface to  
svn from the image would be nice too. Time to get some development  
work done would be a pleasant  surprise, which is why I have to point  
out that money gets involved. I'm not independently wealthy any more  
than most of you.

Oh, and I did ask a while back (on the twin of this thread on the  
seaside list) for advice, discussion, doc pointers etc about how to  
handle allowing open access to an MC repo whilst still maintaining an  
official branch etc. No responses; anybody here going to actually help  
rather than whine?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His future is behind schedule.


Reply | Threaded
Open this post in threaded view
|

Re: Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

Damien Pollet
 
On 05/12/2007, tim Rowledge <[hidden email]> wrote:
> Oh, and I did ask a while back (on the twin of this thread on the
> seaside list) for advice, discussion, doc pointers etc about how to
> handle allowing open access to an MC repo whilst still maintaining an
> official branch etc. No responses; anybody here going to actually help
> rather than whine?

I guess the simplest way would be to create an official, read-only
repo, and a separate open one for contributions.


--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
Reply | Threaded
Open this post in threaded view
|

Re: Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

keith1y
In reply to this post by timrowledge
 

> Oh, and I did ask a while back (on the twin of this thread on the
> seaside list) for advice, discussion, doc pointers etc about how to
> handle allowing open access to an MC repo whilst still maintaining an
> official branch etc. No responses; anybody here going to actually help
> rather than whine?
>
> tim
>
Dear Tim,

for seaside and MC in general it appears to have been done fairly
informally. Many people simply load the latest package which includes
the initials of a known-to-be-reliable developer. Installer facilitates
this approach by allowing the initials (or multiple matches including
initials) to be specified in the package name.

Installer ss project: 'Seaside'; install: #('Seaside2.8a1-lr'
'Seaside2.8a1-pmm')

Since the "blessing" scheme implemented in the squeaksource web
interface does not have any in-image mc support. There is nothing to
stop you hijacking the initials field for an informal marker to "bless"
packages. E.g. MyPackage-kph_RELEASE.123 , since MC does give you the
opportunity to change the name of the package before you save it  and
typically it ignores the initials section of the package names.

MC1.5 has better parsing of MC filenames and so enables more
interesting, or should I say more typical, version numbering so that
MyPackage-kph.1.0.12.mcz is a perfectly usable package name. Users can
then pick the latest minor release, and contributions will automatically
be commited as bug-fix releases.

Chris uses another alternative.  He manages Magma in two separate
Repositories, one for developers to contribute to (MagmaTester) and one
for formal releases (Magma).

best regards

Keith
Reply | Threaded
Open this post in threaded view
|

Re: Decentralizing VM development (was Re: Re: 64 bit VM, source anyone?)

Göran Krampe
In reply to this post by Damien Pollet
 
"Damien Pollet" <[hidden email]> wrote:
> On 05/12/2007, tim Rowledge <[hidden email]> wrote:
> > Oh, and I did ask a while back (on the twin of this thread on the
> > seaside list) for advice, discussion, doc pointers etc about how to
> > handle allowing open access to an MC repo whilst still maintaining an
> > official branch etc. No responses; anybody here going to actually help
> > rather than whine?
>
> I guess the simplest way would be to create an official, read-only
> repo, and a separate open one for contributions.

The simplest way is just to let anyone add MC snapshots but "declare"
tpr snaps as being the "trunk". That is how we do it in Gjallar and I
guess this is also the way other project do it. Just rely on a leader to
merge in (or reject) snapshots.

regards, Göran
12