[Win32][ANN][TEST][VM] Yet another Win32 VM (3.4.2)
Andreas Raab
andreas.raab at gmx.de
Mon Mar 10 10:15:04 UTC 2003
Hi PhiHo,
I guess we simply have different opinions on that matter. All my experience
drives me strongly into the direction of "if possible have all plugins
builtin" but I can certainly understand that other people may have other
opinions about this. Nonetheless I'd like to point out two things:
> My 'weird problems' reported in previous posting is proof that
> the conservative approach doesn't solve the 'plugin
> conflict' problem.
[...]
> I proved that the 'builtin' solution does not solve the
> problem.
If you read my message carefully, then I am saying "in the vast majority of
cases" and "as far as possible". I never claimed that the current solution
completely solves this problem but it reduces it to a manageable amount.
Also, your "proof" relies heavily on a mismatch in the proxy numbers. The
current vm proxy version is 1.5 including the 64bit int values and your
proxy defines a whole lot of other things in this place. Considering this,
it is not surprising that it almost immediately fails. If I would send you
an external file plugin your MobVM would break in equal horrible ways. So I
think your proof is not exactly convincing. Hint: define yourself a new
proxy major version instead of using v1. Then retry your proof.
> > As you don't have an answer to this problem
>
> I think I do. Did you notice that for the last couple
> releases of MobVM.
> the plugin directory is changed automagically.
No I didn't notice (my fault). I need to check this out - what is used to
determine the directory name?! But even if that's the case, I could still
adapt that scheme and have everything builtin ;-) The mere fact that it is
possible to handle the conflict problem (assuming it really is) doesn't
change the fact that most users feel very happy with a "single file
solution". If they don't, they are absolutely free to use MobVM.
Perhaps you don't realize this, but I am not at all opposed to MobVM -
personally, I find it a refreshingly different approach. And the competition
posed by it can only be helpful. But considering all the tradeoffs I will
stick to a more conservative approach.
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> Behalf Of PhiHo Hoang
> Sent: Monday, March 10, 2003 4:49 AM
> To: The general-purpose Squeak developers list
> Subject: Re: [Win32][ANN][TEST][VM] Yet another Win32 VM (3.4.2)
>
>
> Hi Andreas,
>
> > What's the point of your message? I see a vast number of
> arguments that seem
> > to be making _my_ point rather than yours as the problems
> you describe
> > clearly result from plugin conflicts.
>
> If you read between the paragraphs and between the lines,
> you will see I made _my_ points quite clear and strongly sound.
> (and it's not the first time either ;-)
>
> > As you don't have an answer to this problem
>
> I think I do. Did you notice that for the last couple
> releases of MobVM.
> the plugin directory is changed automagically.
>
> From next release, there will only be SqM.exe and SqM.ini
> at the root.
> SqMOM.ini and all dll are in the plugin directory, the
> name of which is
> different from release to release.
>
> > it appears to me that the more conservative approach of having
> > everything builtin is clearly preferrable (since it rules
> out the vast
> > majority of the problems you are seeing).
>
> My 'weird problems' reported in previous posting is proof that
> the conservative approach doesn't solve the 'plugin
> conflict' problem.
>
> > Also, as for "eating your own dog food" I do this on a
> daily basis as I am
> > running a variety of VMs and images in various combinations.
>
> There are many different "dog food" waiting to be eaten ;-)
> The two that I am referring to are the 'dynamic, late binding'
> and 'true plugin'.
>
> > It is _exactly_ this what led me to come to the conclusion that
> > for the end-user the best you can do is to provide a solution which
> > rules out the potential for conflicts as far as possible.
>
> I proved that the 'builtin' solution does not solve the
> problem.
>
> > Considering this, what is it you are trying to say?
>
> Considering that the 'builtin' solution does not solve
> the problems
> that it was suppoed to solve.
>
> Considering that the new design of looking for the plugins only
> at one known location does solve the problems of conflicting
> plugins.
>
> Considering that true plugins are nicer and better designed
> than stuckins.
>
> Considering that MobVM can do anything that the legacy VM
> can do and NOT the other way around (due to the fact that
> MobVM is pretty well componentized).
>
> I would say that let's perfect the plugin design.
>
> Let's componentize the VM.
> Let's make everything an object from ground zero.
> Let's make a Window/Display object, a BrowserPlugin object.
> Let's make a BytecodeInterpreter object.
> Let's make an ObjectMemory object.
> Let's make everything an object, even in the VM
>
> I know, I know, I know,
> I am 'preaching to the choir'.
>
> Better shut up now ;-)
>
> Cheers,
>
> PhiHo.
>
> P.S: It takes an intelligent person to come up with a
> nice solution .
> It takes an equally intteligent and wise and
> brave person to
> regconise the short comings of his solution and
> correct them.
>
>
>
More information about the Squeak-dev
mailing list
|