Hi guys,
Once upon a time samples were split by device. I was quite happy with this
structure, because I could access all samples available for a given target.
Then samples were all put into a single directory. And even if there were a
lot of files, this flat structure was something easy to use (search for a
sample not available for your PIC, using a feature, just to get some example
code, ...). I now like this structure.
So, I agree with Rob, current structure does the trick, and splitting it
isn't that easy. Since one sample can use multiple libraries, it can be that
simply flat. Splitting by family is like splitting by device, you may get
lots of file in PIC16, and not much in PIC10.
Splitting samples should bring a functionality other than "there are less
files into a single directory". Jallib API doc (jalapi), for each library,
provides samples using it. This is an interesting entry point. Since going
from samples to libraries isn't that flat, maybe we can go further and start
to build a database, queried from our website ("I want some samples using
SPI library, whatever the PIC, or using 16F886, or using a PIC in PIC16
family, or using a PIC closed to mine, that is in the same datasheet, or the
same datasheet as PIC X, Y, Z, ......)
Cheers,
Seb
2009/12/6 Sunish Issac <[email protected]>
> Yes Rob. I was thinking of splitting the sample folder, not the lib/include
> files.
> I had not thought about sample files using multiple libraries.
>
> If no other split is possible, may be we can atleast split by PIC10,12,16
> and 18 families.
>
> Sunish
>
>
> On Sun, Dec 6, 2009 at 2:18 PM, Rob Hamerling <[email protected]>wrote:
>
>>
>> Hi
>>
>> Sunish Issac wrote:
>> > With the release of so many samples, looks like its time to split the
>> > samples folder. Spliting by sample type would be more sensible than by
>> > PIC name. IIRC there was discussion about this before.
>>
>> Yes, the collection has happily grown, and finding the right sample
>> maybe some work. But is that so bad? It's nothing compared to the effort
>> to build and provide this collection, and for free. You must not look a
>> gift horse in the mouth!
>>
>> Specify your criterium for splitting of the sample directory. Number of
>> files, other? It may already help to split off the blink samples, these
>> use no libraries at all.
>> Splitting by type (I suppose you mean used library) is not so straight
>> forward since many samples use more than one library. So be more
>> specific with your suggestion.
>>
>> About splitting the include library: Device files might be put in a
>> separate directory, which would require one extra directory in the
>> include pathspec. But in my view there is even less reason to split,
>> because users have hardly any reason to look in a library.
>>
>> 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]<jallib%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jallib?hl=en.
>>
>>
>>
> --
> 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]<jallib%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/jallib?hl=en.
>
--
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.
