From mint-bounce@lists.fishpool.fi Sun Jan 31 00:47:16 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qh9oFXG1JNs2AQ/ZrE0F/+W1SpB+7ErXXa8oLhDp9cg=; b=lr3o24Zk8mlMHwVuEXRsTuSP8n86/sPGVom0dQ4QfHUrIf5p8G9SOC5kOSuax5U35+ +/f/wYKqxx47AhQE6XN8HaTd0lJpAC8Y7MS61yeVQYuEwYTxXCda2Zjcv+e34yYvGxC0 2GcWm4FGPjZtVLElxuNKRor3tp5NlM1wtJnXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cjH/PvEt2FPSLLQ6fDuBhiJD8CZNk/uHc5fk1Nl+RONZHAuD07CQ6e9H4HK7C/aF63 zdVtUIuLbBMvs7knacHIY1vI86lkIoIHXKhJ1NJJNIZF/fMrVczeDKA27aOIqjzjsKUo 5BmShl8Bpi/MDSDA9CxSHmSPz1fbPG8KxTchk= MIME-Version: 1.0 In-Reply-To: References: <11a6f2b11001270642j41b73ecepfd4a7a7cbb3fb354@mail.gmail.com> Date: Sat, 30 Jan 2010 23:44:44 -0600 Message-ID: <11a6f2b11001302144r453c353xdb21efddf53b2ee4@mail.gmail.com> Subject: Re: [MiNT] mono (was: Re: QED) From: Paul Wratt To: mint Content-Type: text/plain; charset=ISO-8859-1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: paul.wratt@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > On Jan 27, 2010, at 3:42 PM, Paul Wratt wrote: > >> On Tue, Jan 26, 2010 at 6:18 AM, Miro Kropacek >> wrote: >>> >>>> >>>> http://kdiff3.sourceforge.net/ >>>> >>>> but I just noticed it's C++ >>>> >>>> Is it possible to use C++ with our GCC yet ? >>> >>> Yet? It's possible for at least 10 years :) The problem with kdiff isn't >>> c++ >>> but Qt/kdelibs dependency. >>> -- >> >> this may be rectified sometime in the future, Qt3 & Qt4 for MiNT/TOS. >> GTK also. By then a look at mono.. >> >> There may be an easier way to "hotwire" some kde base libs, but that >> is just theory atm, an still requires a usable intermediate.. >> >> Paul >> >> On Wed, Jan 27, 2010 at 2:19 PM, Standa Opichal 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