Thank you! (and test to vm list)

Ron

-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Monday, October 16, 2006 4:30 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Fwd: Include Cryptographic Primitives In VM's - DESPlugin

I'll add DESPlugin to the next release of VMMaker and you can then persuade the vm makers to make sure it is included for testing.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Great leaders inspire by example. When that's not an option, brute intimidation works pretty well.

+1 from n00b (so I don't really count).

By the way what are the chances that those people that are currently maintaining platform VMs will actually be building new VM's? Is there a schedule or process, or just random recompilation? (I'm not asking that a new vm be created since we have more plug-ins to contribute yet, I was just wondering)

Thanks, Ron

-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Monday, October 16, 2006 6:40 PM To: Squeak Virtual Machine Development Discussion Subject: VMMaker organzation (was: Re: [Vm-dev] Fwd: Include CryptographicPrimitives In VM's - DESPlugin)

Hi Tim and all -

I'm wondering if we shouldn't "decentralize" the development of VMMaker a little. Right now, it seems pretty awkward for someone developing a plugin to update that plugin in any reasonable way. For example, the current VMMaker release has a somewhat outdated CroquetPlugin which -while not horribly broken- fails a few important tests in replication (I only noticed that over the weekend btw). The current solution set consists of me sending something via email to you in the hope it'll end up in some future version of VMMaker. Whether it's gotten there or not I can't tell without actually looking at the code itself, e.g., there isn't an easy way for me to say "oh, no, Tim's forgotten to include the latest Croquet plugin for the 3.9 release! Where is the tar? Where are the feathers?" ;-)

So here is a question: What if we organize a monticello repository with sub-packages for the individual plugins which then get updated by individuals maintaining these? What I'm thinking about is something like:

VMMaker-Generation (CCodeGen, VMMaker, UI) VMMaker-Interpreter (ObjectMemory, Interpreter) VMMaker-Crypto (all the crypto plugins) VMMaker-Croquet (all the croquet related ones)

etc. This would allow (say) Ron to update the crypto plugin independently from me updating the Croquet plugins and it wouldn't require you to be in the loop for every minor change. "Real" releases might be managed simply by posting a Monticello configuration that lists all the packages for that particular version of VMMaker (plus optional file releases through SM - I've used load scripts to good effect for that in the FFI and one could probably even write a translator that takes a configuration as input and spits out an SM loadscript).

Does this make sense to anyone but me?

Cheers,

• Andreas

tim Rowledge wrote:

...

I'll add DESPlugin to the next release of VMMaker and you can then persuade the vm makers to make sure it is included for testing.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Great leaders inspire by example. When that's not an option, brute intimidation works pretty well.

Andreas,

Yeah we can do that already but it's been a major pain in the pa-toody too! That's why we want to go with an internal vm code. We lost one platform plugin and had to make a new one, and now with the des smalltalk representation if the plugin is not there it still works, just really badly (but good enough for testing).

I think we are fine for a temp solution and can handle most sophisticated users as is, but for a long term solution I was hoping to have the VM include it. No rush especially since we have more to add. Good luck with debugging the problem.

Maybe after reading Dave's docs I'll even understand what cc1 is! When all else fails check your compiler options!

Thanks again, Ron

-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Monday, October 16, 2006 7:30 PM To: Squeak Virtual Machine Development Discussion Subject: Re: VMMaker organzation (was: Re: [Vm-dev] Fwd:Include CryptographicPrimitives In VM's - DESPlugin)

Ron Teitelbaum wrote:

...

By the way what are the chances that those people that are currently maintaining platform VMs will actually be building new VM's? Is there a schedule or process, or just random recompilation? (I'm not asking that

a

...

new vm be created since we have more plug-ins to contribute yet, I was

just

...

wondering)

It's pretty random depending on whether time allows playing around with stuff or not. Like, for me, I'm currently facing this stupid cc1 crash when I try to compile a VM and downgrading to a previous version to figure out what exactly went wrong where has proven to be an extraordinary pain in the rear end.

If you want to update your plugin(s) on your own, you should get a build environment set up and build them externally (so people can use them as drop-in replacement).

Cheers,

• Andreas

Tim,

I know we've discussed this already. The code will work both internally and externally now, but there are still concerns and I still believe that this is one set of code that needs to be internal and not external.

The first concern is security. My concern is communication between the VM and the dll. I won't pretend to be and expert on the dll load and memory handling but simple is definitely better.

The second concern is packaging. One of the requirements of cryptographic validation is isolation. We need to find a way to isolate our code and guarantee that it is run unmodified. Having a single file to protect is a definite advantage, especially if part of our solution is a signed VM.

I think I understand the point you are trying to make, and still believe that internal is better and eventually it may be mandatory.

Thanks, Ron

-----Original Message----- From: tim Rowledge [mailto:tim@rowledge.org] Sent: Monday, October 16, 2006 7:59 PM To: Ron@USMedRec.com; Squeak Virtual Machine Development Discussion Subject: Re: VMMaker organzation (was: Re: [Vm-dev] Fwd:Include CryptographicPrimitives In VM's - DESPlugin)

Ron, I can't help thinking you're confused about something here. Internal or external makes no difference to the plugin. If you've written code that only works with it built and linked internal then you've written it wrong.

The *only* particular value to making a plugin internal is that it simplifies distribution for unix & windows platforms by having a single executable.

On 16-Oct-06, at 4:52 PM, Ron Teitelbaum wrote:

...

Andreas,

Yeah we can do that already but it's been a major pain in the pa- toody too! That's why we want to go with an internal vm code. We lost one platform plugin and had to make a new one, and now with the des smalltalk representation if the plugin is not there it still works, just really badly (but good enough for testing).

I'm confused about "We lost one platform plugin" - can you expand on this?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RJT: Read and Jam Tape

Ok, so I've started a VMMaker repository in SqueakSource ready to fill with stuff.

How fine grained would people like the sub-packages to be? We could go bananas and have each plugin separate, the VMMaker & VMMakerTool, the interpreter class, the object memory etc all split out. Or it could be main vm code, vmmaker, core plugins, andreas' plgins, ron's plugins... etc.

Whaddya want?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If brains were taxed, he'd get a rebate.

Am 17.10.2006 um 02:55 schrieb Andreas Raab:

Hi Tim -

tim Rowledge wrote:

...

Ok, so I've started a VMMaker repository in SqueakSource ready to fill with stuff.

Can we set one up on source.sqf.org? Squeaksource.com has been pretty unreliable for me.

Repeating myself, but *please* can we name it "vm"?

...

How fine grained would people like the sub-packages to be? We could go bananas and have each plugin separate, the VMMaker & VMMakerTool, the interpreter class, the object memory etc all split out. Or it could be main vm code, vmmaker, core plugins, andreas' plgins, ron's plugins... etc. Whaddya want?

Something in the middle perhaps. Like I/O (socket, files, async files), then graphics (bitblt, balloon, jpeg, bmp), sound (wave, gsm, midi) etc. (I don't have a list of plugins on my finger tips or else I would have made up a list from them).

I'd go for one MC package per plugin. If I were to start toying with a new plugin I'd put it into a separate package. In fact, that's what I did a couple of times. When the plugin gets ready for inclusion in the official repository, nothing would have to change, history is preserved etc.

vm-maker (building, UI) vm-translation (translator) ... might also be called "slang" to give noobs an a-ha vm-core (Interpreter, ObjectMemory) vm-io-socket vm-io-async vm-sound-midi vm-graphics-bitblt

What would be the downside downside of doing this? I see none really.

- Bert -

Bert Freudenberg writes:

I'd go for one MC package per plugin. If I were to start toying with a new plugin I'd put it into a separate package. In fact, that's what I did a couple of times. When the plugin gets ready for inclusion in the official repository, nothing would have to change, history is preserved etc.

I'd go for a total of one MC package for everything just as we have now. It makes it easier to load, to share, to branch, and to keep in sync. With a single package it's impossible to end up with versioning problems between sub-packages. I know that there are MCC thingies that should help when loading from a Monticello repository, but how easy are they to bundle for SqueakMap or merge, or fork in a private repository?

To increase decentralization, why not just give Andreas and Rob write access to a central publically readable repository? If Rob only needs access for Crypto, then let's just trust him not to abuse commit privileges. If commit privileges are abused then they can be removed and all changes will be under version control so should be able to be undone. Giving out write privileges would also allow people other than Tim to commit (harvest) obvious fixes. Tim can always be required to inspect any release then bless it before writing the commit message.

The biggest problem people strike when starting to help out on Exupery is assembling a VM build environment. Splitting VMMaker into separate projects will make this harder as Exupery has it's own VMMaker branch. With a single MC package this is easy to deal with. A single package makes it easier for people to maintain experimental branches outside of the mainstream VM.

VMMaker is still small enough to email comfortably. The only good reasons I can see to split it is if people want to mix and match versions of new packages or not install the entire thing. Neither seems probable especially as plugins can already be built separately.

Bryce