Hi Rob, > Well, better somewhat boring than nothing at all. It has been too quiet > here lately (and somewhat disappointingly few reactions in Jallist > too!)
This will take time I think. For now, we provide the same libraries as the one already existing (I mean, functionally equivalent). Yes, there's a lot more device file/supported PIC, which is definitively great, but if most people is using 16f877, they can't see the improvement. Now we need to provide more and more libraries, more external libs (see my post about inventoring external parts/libs we plan to add). Then, when there's a question about "how do I do that" or "is there a lib for this", more and more the answer will be "use jallib". That's my hope. At least :) One more thought: we should provide tutorials. This is highly time consuming, but some tutorials about blinking a led, setting up a serial com. with diagrams, code etc... would help a lot. Here I think again about a shared blog. We need to advertise, in one way or the other, what can be done using jallib. > I need to collect some energy to resume working for Jallib. I too. I currently have a lot of work with my "real" job, and I also spend some time on my own SirBot project. I also need to migrate my own code to jallib, before sharing back some of my libs. > BTW where has Richard Zengerink gone? I think he has. Hence the casualities... > Yes, the b<pic>.jal files must be removed and replaced by > blink_<pic>.jal files. OK. > I don't know how this could have happened. There is no PIC type 16hv615, > so remove this file. OK > > => what ever the changes, we should overwrite from unvalidated to > > validated. Right ? > > Yes. OK > 'Remaining' files are in unvalidated because these are not listed in the > test matrix. Do you think the test matrix should be emptied and > created fram scratch for 0.1beta to 0.1release Let's forget about the test matrix. It seems to complicated, at least, as it is right now. I just suggest we put things in "validated" map. I'll build a test matrix from this map, just to generate the test result pages (or not if you think it's not worthy). > Since I have now a set > of dedicated test boards I could do the re-testing of the blink samples > and some other tests pretty quickly. You can if you want. Or maybe we should populate again "validated", *then* test the whole thing, instead of having to go back/forward between "unvalidated" and "validated". > Updating the matrix file is a > different matter! So forget it :) > When a sample or library is FULLY tested I have no objection against the > move to validated. However I have my doubts about dependencies: I think > these should be full tested by a dedicated test-program _before_ being > used as dependent to ensure a full test of all its components. This may > be somewhat difficult. For example: how to make sure that all > declarations in a device file are correct? Compiling a blink program is > only a very limited test. Sure... The Eternal Testing Problem... I have no answer how to do this cleanly *and* easily. Except we may set our expectations too high. I could say we'd better release often and potentially release code with some errors, and build a user base. For now, if no one use it (except us here), no need to be so picky about testing. After all, we have a nice safety net: the bot. Of course it can't test for real, but it builds, and builds, and builds, and will report any compiling problem, starting with API changes, typos, unexisting dependencies, etc... That's quite a nice start, and for free. And that might be enough for now. I've spent a lot of time on the ETP (Eternal Testing Problem...), how to report, how to track changes, how to check quality. Maybe that's too early for now. I may prefer spending my time on advertizing jallib, for instance. So, how do we proceed ? Just send me a list of file you want to put in "validated". I'll take care of it. To prevent any confusion, one person should do this. I propose myself to do it. So, just send back your list of files, here, in the list, and I'll put them in "validated". BTW, are device files stable ? Any improvements in perspective, before we start doing this ? Cheers, Seb -- Sébastien LELONG http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
