From mint-bounce@lists.fishpool.fi Sun Dec 6 11:03:50 2009 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 :content-transfer-encoding; bh=EIio/1N/Manu5tl1lQQJPpAfeq4oUy6JteJKRn+6gZI=; b=TDtJXvkxc3bHvqKbt4vsdBO8e45a0ZqM3GRdwVTIlMtiqZhQEbw5Xvzi1YNG0Djthi 239MgFHCNI9Qgw2aypjNt/NZN0HaRPVoQyg+Vg6ByJSTsvVK/xJBLRF9ApHy/Vujw7N9 31ihG1fUmvwVz+Taih9IOxgcAr/iaoSxA8d8g= 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:content-transfer-encoding; b=UPHXebj0jhpdxXJIJ1Pcph1yXITBFTZdr9vHsMJNwleqlyp10xcINVXCz9g5qNO/qp J7WVC7RuqK2F2nO3jWgNkhlv7mBoBcZH3uU0d4Ab75FccoSzFTedcr/72A21BoGDdXIo +SlYFkB3yDYXBk+Ec5Imzsr5Ymtsie9JGDsSU= MIME-Version: 1.0 In-Reply-To: <11a6f2b10912060757j55cdc533re2d452f7cb8b780f@mail.gmail.com> References: <11a6f2b10912031803h290d38a8i916fc270ce6c6d76@mail.gmail.com> <11a6f2b10912050321p7918ef60gb17ba429f719b4e9@mail.gmail.com> <752526d20912050438o49cf5e4fw37e1d423afcd2935@mail.gmail.com> <11a6f2b10912050915r6e8d3e5ejfec9970990326f25@mail.gmail.com> <4B1AF6D9.5030704@freesbee.fr> <11a6f2b10912060757j55cdc533re2d452f7cb8b780f@mail.gmail.com> Date: Mon, 7 Dec 2009 02:59:01 +1100 Message-ID: <11a6f2b10912060759i75e3f72sf7bf3bc78a6399df@mail.gmail.com> Subject: [MiNT] XaAES crash errors 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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id nB6G3n0P021892 First, thank you ALL for your replys 2009/12/6 Vincent Rivière : > Paul Wratt wrote: >> >> The question: how do I pass "char *line" through to an intermediate >> function that can then pass "&line" correctly. Would passing "*line" >> be enough.. > > Things are not so simple, that *, ** and & are not here by chance. > We can't answer this question without knowing the context. It seems you want > to split a function into 2 functions, which is probably good. > > You should post here the relevant elements of the function in question and > we will answer on a concrete example. > Thanks, I will be "explicit" with future posts > But we must keep in mind that writing C programs is complicated. > With a basic knowledge of any programming language, it is possible to read > and understand most C code (except some language elements which are tricky). > yes, this is my understanding also, I must experience, or be told about, the tricky bits, "searching" for them turns up nothing atm. > Writing C code is another story. It is usually quite difficult for C > beginners to manage to compile a program. And when it finally compiles, they > say "Hoorah !" but most of the time the program is full of bugs, and it > crashes at runtime or does a wrong thing. The C language is even more evil: > sometimes it seems the program does the right thing, but actually it writes > to illegal memory, so it works by chance and it is trashing something else > which will crash later in a incomprehensible way... > This is also my understanding, hence coding many languages for 20+ years, I skip straight to "the good stuff", as long as it compiles, and the base code is "stable" > I just want to say that refactoring a complex code as you are doing require > solid C skills, there are good chances that you will break something away > without seeing the effects. Then it will be a headache to find bugs... > What I know of code in general, and I include differing coding styles in that, XaAES is for the most part "fairly clean" and well written. The are area, as noted by others also, that are "not so great", which just means a lot more back and forth cross-referencing and searching in order to make sure any "changes" do not have "hidden" repercussions, or "brake other things". Refactoring in general is not differcult (for me) even without experience in the language, as long as the code is "well layed out", which for the most part it is, so most changes are just "cut and past" with the odd bit of #if and #define to get it working again. > So you should really begin by improving your C knowledge, as it has already > been told here. > Well, this is just an advice. > > Vincent Rivière > I think the one this "doing theme related changes" qualifies as "improving your C knowledge". The bit that is missing from every bodies comments "as it has already been told here", is "XaAES is out of your league". I dont believe it is, I consider kernal at the beginning of that boundary, not interface related kernal modules. Everyone, Please dont take the above paragraph the wrong way, I do understand that it means a "filling some very big shoes", and is a learning curve that most would not climb by choice, but I am up to the job. By christmas you will have a more stable and prettier version of XaAES in Beta status (including Helmuts work that is, and any other patches floating around). The for runner to a v1 Release for BOTH 1.16 and 1.17 which is still light and compatible with current configs. At some point after that things will branch, or a "rewrite" will be forth coming, but that is for later, and may or may not be open for discussion.. To drive home what I do understand, can I as why a kernel module can "fail to exit". It is one of (possibly) many all designed to work together, therefore one can not afford to lock the system if it does fail. Is it possible that I caused an underly bug to be exposed, resulting in the output of this threads first post. Is there any way to test this. Is anyone available to test it. ATM it is beyond me (soon maybe) Again thanks to everyone for there advice, in future I will be more explicit in my questions, with supplied code. I will also seek to NOT make advanced changes with out doing incremental tests. BTW, what I think "broke" the km, was reverted, and I can say that it was unrelated to anything I have posted about or ask (weird) questions about. I added "SKIN_DIR" to path loading, which also required "fixing" XA_XTOBJ.RSC loading, and I used XAAESWDG.RSC loading as a basis for that. There are however some underly differences in how those two resources are handled, which was the part that broke. ALSO, the question that was related to *, **, an &, my current solution is to NOT use intermediate functions. This just meeans "code double ups" for certain functions which was my greater concern (other people reading the code, and extra binary space taken), but I can look at that later on, when I do "have more experience". It is possible that what I have will work, but I was concerned that it may have contributed to the "inital crash". ANYWAYs, anyone who does not know yes, a new version of MyAES should be out "just now" (soon), and I have got "the 1st of many" gradient files completed for compile inclusion. I will release a download and patches of these sources when I have completed another 5 of them. screen shots are here (at the top): http://paulwratt.110mb.com/afros/skins/xaaes/ Anyone with XaAES and 1.16 can get an "improved" version ("make all" binaries with "strip -s") for all targets (top link). http://paulwratt.110mb.com/afros/skins/ Thanks again for peoples time and wealth of knowledge (and previous years of hard work) Paul Thanks to Henk for off-topic opportunity :)