[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] mono (was: Re: QED)



Hi Paul!

I know it is probably not the thing what most people here would want to hear but IMO it would be less time consuming to port FreeMiNT/TOS APIs, VDI and AES on top of the current NetBSD/FreeBSD codebase then trying to implement the necessary functionality into the FreeMiNT kernel itself. We could nicely call it e.g. Mint(Free|Net)BSD! :)

There you get all the apps bundled.... m68k specific patches could still be applied from their SpareMiNT RPMs. And you might even get cross-compile capable packaging
system.

But that's probably way off the discussion here. I am just trying to put man-years quote
on the work to be done to reach the goal...

Standa



On Jan 31, 2010, at 6:44 AM, Paul Wratt wrote:

On Wed, Jan 27, 2010 at 2:19 PM, Standa Opichal <opichals@seznam.cz> wrote:
Hi Paul!

WRT mono... tried to port it on several occasions and then gave up. Got to
the point the mono CLI
was dissasm working. But not the interpreter, not talking about the JIT
itself. Two basic common
things missing in our kernel for easy ports: virtual memory (and the libc
mmap()) and threading (pthreads).

Thanks for the update, MONO is a large effort

Yeah, these seem to be recurring issues, even for non-port
development, it is really an essentual parts of modern OS, an VM would
allow a lot of older machines to run more software.

Pthreads is another "kettle of fish", and may require complete
redo/overhaul of multitasking parts of kernel. This is a tough one
because there are not many people who can do such things even outside
of ST/mint development.

One way I have proposed to tackle these issue related to porting at
least, is to use dummy or replacement libraries, so the functions used
in code dont need to change, and the lib supports what it can, and
does other things where the OS cant handle it.

Its not a perfect fix, and something like pthreads would probably just
be easier to add the missing parts to kernel to get the correct
support.

Somebody should provide these for FreeMiNT on the CF machine (and perhaps on
040/060) or you
risk porting modern packages will always be great pain + rarely ever a
possibility for upstream
acceptance.

Standa

There are a lot of people around atm, and I expect at least for the
next 12 months. Something will happen here I have no doubt. It might
get done quicker if peeps knew what was needed, and could supply
chucks to get the project(s) completed faster, as opposed to relying
on one person, or team.

One thing I have noticed about Atari ST/Mint development (atm), is
that most people either have family (kids), school or job, which means
they dont have a lot of time to dedicate to projects. However, if they
could spend a few hours here and there supplying pieces, then even a
relatively large project could be achieved.

There are a few like me who do have the time to put into documenting
what is needed and where (and doing other boring stuff). I am
constantly on the look out for things that can fill or help fill a
need in Atari ST/Mint development, especially source code, and have a
large collection atm.

If I can collect such things as you have done with mono, document what
is needed, and where, which is part of providing cross-referenced docs
and dev docs, then others can take a look at specific things as time
allows, instead of "re-inventing the wheel" or ending up with another
dead project.

I, to do these things, and others, to find, discuss and provide these
things, need to have an infrastructure which can support these types
of initiatives. The beginning of which is a useful wiki.

The other thing I note about ST/mint development, is that one person
often takes on the job of providing something, but as pointed out
above, they do not have the time to commit 100% to getting it
completed ASAP.

In this case (bare with me here people), the wiki is a good example.
Yes content structure and clarity are required. But if only one person
is allowed to provide the content, then what is the point of using
wiki in the first place. In this example, everything that was needed
could have been added within a week by many people, and the person
taking responsibility for it could have re-organised everything, once
a layout was decide, others could then have assisted in the
restructuring.

In this case also, wiki is less about structure, and more about
structure evolution. There is only ever a small set of key things
needed documentation wise (for any project), everything else is an
added bonus, and evolves as needed or as time permits.

So, with that in mind, I hope to start providing these currently
missing access points for projects, documentation, help docs, dev
environments, required downloads, or quickstart guide, in such a way
as others can both use and edit/add as there time permits..

ATM it is differcult to provide the required integration simply
because I believe it should not reside on my servers. The majority of
information is physically available on one server, and to that should
be added more dead and abandoned projects (like mono mentioned here)
that have relevance. This should extend to at least a minimum set of
full apps and libraries that allow full OS usage and/or development
(including porting)

However the management of all of this needs a user system like wiki,
which does not need any human response or confirmation in order to
sign up and contribute, and yet keeps history and makes branching
possible (for dev work), without the need for setup from any one
individual who may otherwise be unavailable for whatever reason.

OK, nuff for the moment, every minute spent replying to mailing lists
eats into the time I need to provide the above. To anyone associated
with comments made in this, please do not take offense, it was not
meant in that way, and is unproductive, which is counter to the
essence of this post, working solutions are always better

If anyone else has dead projects (I already know about the abandoned
projects on the ICQ site) or has incentive to provide written material
(ala http://wikipendium.free.fr/) please speak up, there are a ton of
areas to contribute too, many of which are not boring :)

Paul