Sebastien LELONG wrote:
> [sorry for this boring post... :) ].
Well, better somewhat boring than nothing at all. It has been too quiet
here lately (and somewhat disappointingly few reactions in Jallist
too!). I need to collect some energy to resume working for Jallib.
BTW where has Richard Zengerink gone?
Line with "=>" is where I'd need your input.
> I've done some investigation, comparing "validated" and "unvalidated" map.
> The
> aim is the final 0.1 (because, IIUC, you'd want to release ?), and this is
> also useful to know what to put in validated.
Yes, let's hope a 'real' release triggers some more feedback!
> 1. Files only found in "validated":
>
>
> grep "^Only" out | grep -v \.svn | grep 'Only in validated' >
> only_in_validated.out
>
> These are mostly blink files, which have been renamed from "b<pic>.jal"
> to "blink_<pic>.jal".
>
> => Old blink files in validated must be copied again with new ones
Yes, the b<pic>.jal files must be removed and replaced by
blink_<pic>.jal files.
I have not re-tested (yet) all the blink samples which I tested for
0.1beta (those which I tested worked fine), and I have not updated the
matrix, so which to move and which not? Since the probablility that a
blink sample will not work is small as well as its impact I suggest to
copy all blink samples to the validated tree. In fact I sort of hope
that some blink samples do not work: would stimulate the discussion
about Jallib!
> Now, weird thing: sample directory "16hv615" cannot be found in unvalidated.
> This directory is empty...
>
> => Can I remove empty "validated/sample/by_device/16hv615" directory ?
I don't know how this could have happened. There is no PIC type 16hv615,
so remove this file.
> 2. Files found in both "validated" and "unvalidated", but changed:
>
> * grep '^diff -r' out | grep -v \.svn > changed.out
> * for f in `grep '^diff -r' out | grep -v \.svn | grep \.jal\$ |
> awk '{print $3}'`; do echo diff $f un$f;diff $f un$f; done >
> changed_details.out
> * cat changed_details.out | grep -v '^. --' | egrep -e '^diff|[\>\|\<]' >
> changed_code_only.out
>
> Many changes are due to the license changes (see "changed_details.out" file).
> And some are "real" fixes, I mean, impacts are in the code, not only in
> comments (see "changed_code_only.out")
>
> => what ever the changes, we should overwrite from unvalidated to
> validated. Right ?
Yes.
> 3. Finally, files only found in "unvalidated"
>
> grep "^Only" out | grep -v \.svn | grep 'Only in unvalidated' >
> only_in_unvalidated.out
>
>
> There are:
> * directories, found in unvalidated, but not in validated. I've added some,
> like "rtc", "temperature", "co2"
> * there're html files, about API. This is normal.
> * there's a "test" directory. Yes, no "test" directory in "validared".
> Should we consider adding it ?
> * and there's the remaining :) devide files, blink files, samples, libs.
>
> => This is where I need your help. From the remaining, what should go
> to "validated", and then in the release ?
'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? 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. Updating the matrix file is a
different matter!
> One more thought: maybe we should consider moving files from "unvalidated"
> to "validated", regurlarly, to avoid this. If there's no debate about API,
> about naming conventions, about I dunno, maybe the author should consider to
> copy his files and ALL ITS DEPENDENCIES to "validated". Because files would
> copied from time to time, I could also put a bot on "validated".
>
> What your point on this ? Do you see any potential problems ?
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.
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
