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
On Dec 4, 2007, at 18:56 , goran.krampe@msc.se 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 -
Hi!
Bert Freudenberg bert@freudenbergs.de wrote:
On Dec 4, 2007, at 18:56 , goran.krampe@msc.se 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.
On Dec 5, 2007 10:23 AM, goran@krampe.se 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.
Hi!
"Michael van der Gulik" mikevdg@gmail.com wrote:
On Dec 5, 2007 10:23 AM, goran@krampe.se 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
2007/12/5, goran@krampe.se goran@krampe.se:
Hi!
"Michael van der Gulik" mikevdg@gmail.com wrote:
On Dec 5, 2007 10:23 AM, goran@krampe.se 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:
My numbers were for the 32-bit binary VM, not a 64 bit VM.
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
2007/12/4, goran@krampe.se goran@krampe.se:
Hi!
Bert Freudenberg bert@freudenbergs.de wrote:
On Dec 4, 2007, at 18:56 , goran.krampe@msc.se 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.
On Tue, Dec 04, 2007 at 07:56:54PM +0200, goran.krampe@msc.se 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
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)]
On 4-Dec-07, at 9:39 PM, Craig Latta wrote:
Wow, I hope Tim makes a new VMMaker release before the recipegets to twenty steps. ;)
There's a Simple Solution (tm) - $1,000,000 (CAD) would do nicely.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Inoculatte (v): To take coffee intravenously when you are running late
Hi David!
"David T. Lewis" lewis@mail.msen.com wrote:
On Tue, Dec 04, 2007 at 07:56:54PM +0200, goran.krampe@msc.se 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:
Load VMMaker from SqueakMap.
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
Load the fix from Mantis 5688 (otherwise you cannot use SqueakMap): http://bugs.squeak.org/view.php?id=5688
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
Load the fix from Mantix 5403 (you don't need this, but I do): http://bugs.squeak.org/view.php?id=5403
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
Load the 32/64 bit updates for AsyncFilePlugin: http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001675.html
Load the 32/64 bit updates for FileCopyPlugin: http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001679.html
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
On Wed, Dec 05, 2007 at 10:26:44AM +0200, goran@krampe.se 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:
- I would like to see if that works technically.
- 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
Hi!
"David T. Lewis" lewis@mail.msen.com wrote:
On Wed, Dec 05, 2007 at 10:26:44AM +0200, goran@krampe.se 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:
- I would like to see if that works technically.
- 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
On Dec 5, 2007, at 12:07 , David T. Lewis wrote:
On Wed, Dec 05, 2007 at 10:26:44AM +0200, goran@krampe.se 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:
- I would like to see if that works technically.
- 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 -
Hi!
Bert Freudenberg bert@freudenbergs.de 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
On 5-Dec-07, at 5:48 AM, goran@krampe.se 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His future is behind schedule.
On 05/12/2007, tim Rowledge tim@rowledge.org 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" damien.pollet@gmail.com wrote:
On 05/12/2007, tim Rowledge tim@rowledge.org 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
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
Hi!
tim Rowledge tim@rowledge.org wrote:
On 5-Dec-07, at 5:48 AM, goran@krampe.se 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.
Sure, fine - I didn't recall, my bad. But it is definitely not wired up into the "regular VM building make script etc" - which is probably the reason I didn't recall it actually is "scriptable".
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.
SS is much more stable these days - even though it actually was down today. The absolutely easiest way to host an MC repo IMHO is to use Apache (or whatever) serving a directory readonly and then use say pure-ftpd to give write access to the same directory using ftp (with a user/password).
regards, Göran
tim Rowledge wrote:
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.
Personally, I can now vouch for the Gemstone version. It is very reliable (much better than our previous attempt).
Cheers, - Andreas
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:
- I would like to see if that works technically.
- 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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Craig Latta -
Damien Pollet -
David T. Lewis -
goran.krampe＠msc.se -
goran＠krampe.se -
Keith Hodges -
Michael van der Gulik -
Philippe Marschall -
tim Rowledge