[Mono-list] Update on tasks (a compromise solution?)

[Robert Deviasse]

Rhys Weatherley wrote:
>Miguel de Icaza wrote:
> > TODO=ilasm,IL Assembler
> > ** IL Assembler.
> >
> > TODO=al,Assembly Linker
> > ** Assembly Linker.
>
>*sigh*
>
>Portable.NET 0.1.1 already has a working assembler, for
>small examples, with full Partition II support within the next
>couple of weeks.  A linker is about 24 hours worth of work
>for me, because I already have 99% of the code in place and
>just need to hook it up.
>
>Miguel, stop re-inventing the wheel, and start co-operating
>with the rest of the open source .NET efforts.
>

I agree with Miguel that ultimately, as much of the environment
should be written in C# as possible, since it makes porting quick
and easy once you have the CLI VM in place. It would also allow
more code to be shared with other pure C# groups like SharpDevel.
(As a side note, SharpDevel is writing its own pure C# parser.
Check out http://www.icsharpcode.net/OpenSource/SD/Forum/ in the
"Developer Discussions" section under thet article "Just some
FAQs, Annotations, Considerations". Maybe there's a potential
for collaboration.)

However, my professional experience tells me that although you
must *never* forget the long term goal, it's crucial to get some
sort of foundation in place quickly since that holds back a great
deal of the important high level work. It's especially important
in free software because when a project is actually usable,
people get more excited about it and contributors can directly
benefit from their contributions. Simply put, Mono can't accept
contributions from many Linux and BSD programmers until it's
available on those platforms.

If you put your time into defining good clean interfaces and you
plan for change *every step of the way*, the foundation can be
changed later with little or no impact on the higher layers.

Perhaps there's a solution that's long term idealistic, but
short term practical that Portable.Net, Mono and even SharpDevelop
can agree to? I mention SharpDevelop because they need a parser,
disassember, and debugger. Mono and Portable.Net will need to
define classes for these same things.

So, Miguel, could Rhys's work be temporarily used until all
the foundations are in place?

Rhys, relating to PInvoke. I agree 100% that implementing PInvoke
as a SWIG or autoconf type bridge written in C completely misses
the point of PInvoke. However, I also agree that PInvoke is big,
hairy, and more complex than we know how to deal with at the moment.
No matter what we implement now, it will be complex and it will
have to be changed when we come across new complications. Either
that or it will be underpowered. So perhaps we can use the suggested
PInvoke kludge (even if it's ugly and very inconvenient) until we get
more experience about what we actually need? This would allow quick
porting of the part of GTK+ that WinForms needs. We should depend
upon PInvoke as little as possible, but the little that we do need,
is crucial to getting anything done. Anyone using PInvoke will know
that the solution solution is a kludge because we can add version
numbers to the stuff that we change, as the following:

    [DllImport_v1("libc")]
    extern public static int_t stat(string pathname, out stat buf);
or

    [PosixType_v2]
    public struct off_t
    {
        private long value;

        public off_t(long x) { value = x; }

        public static operator implicit off_t(long x)
            { return new off_t(x); }
        public static operator implicit long(off_t x)
            { return x.value; }
    };

Yes, including the version is ugly ugly. That's the point.:-) The
prototype isn't important. What's important is that the C# code
*using* a struct defined as PosixType_v2 or a function defined as
DllImport_v1 doesn't have to change when the function or struct
upgrades its version. Only the C implementation (assuming this
version requires a manual bridge) of the function needs to change.

PInvoke calls of one version can only call PosixTypes of the same
version, so the complexity of supporting a few previous versions
should be linear and localized, not exponential and delocalized.

As we understand more of the issues, we can increase the version
numbers of the attributes. Code based on the old version number
doesn't have to be written right away, but when the cost of
supporting all versions is too big, some versions will be dropped.
When we're sure that we've worked out all the details, the version
numbers can be dropped, and all old version can be declared obsolete
only supported only for a limited time.

Is there any room for compromise between Portable.Net and Mono?

I apologize for being longwinded again, but I honestly don't see
why there's a conflict.

Take care,
     Robert



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp