Hi guys, I remember such a discussion at the very beginning of jallib. Samples were once organized by PIC, but it's been flatten because some lib onlly had one sample for a given PIC, "deeply" into directory hierarchy and hidden from users. When flatten like now, users can see which sample are available for a given lib, even it doesn't match his own PIC.
I guess entry points could be either by PIC, or by libs. I remember we also talked about having a database, where such entry points could be implemented... Not such user friendly, but could be used by an IDE and a website. Cheers, Seb 2012/4/23 Sunish Issac <[email protected]> > Separating the samples based on PIC type would be the simplest for the > user, I divided the samples to 10f,12f,16f,18f in the jaledit pack. It > broke the docs html but still better than have all samples in one folder. > > Also for the blink samples, better to use internal oscillator > configuration whenever possible. > > > Sunish > > On Mon, Apr 23, 2012 at 3:32 PM, Joep Suijs <[email protected]> wrote: > >> Hi, >> >> 2012/4/23 Rob Hamerling <[email protected]>: >> > But we probably should have two discussion threads: >> > - structure of the repository >> > - structure of the distribution package >> > because these have different requirements (and different 'users'). >> > For the repository the highest priority is probably maintenance. >> > For the distibution package the most important is probably >> categorisation of >> > the samples. >> Right (more accurate as always :) >> >> > To start with we could separate the elementary (generated!) blink >> samples >> > from the rest, both in the repository and in the distribution package. >> So >> > there will be about 600 'real' samples left, and because of the naming >> > convention of the samples it will not be too difficult for a user to >> find >> > what he is looking for. >> Good point, I agree. We should not bother the user with development >> related issues. >> And about development related issues: I guess there are other ways to >> deal with it too (like the text I have added). >> >> > At the moment I do not see how to split the samples further in >> categories in >> > an 'obvious' way for the user. Maybe we should not put the device as >> first >> > part of the name but as last part (and the primary library as first >> part). >> Two separate issues here: >> - The device at the end is okay with me and actually more appropriate: >> you search for a particular function of your device or a similar one. >> - the generated samples are now named after the test file, which is >> not always the name of the lib. We might have multiple testfiles for a >> lib (basic, advanced) and also testfiles that combine multiple libs. >> IMO it is good to name the sample (test file) equal to the lib, but >> this might not always be that obvious. I will look into this once we >> have agreed all old generated samples can be removed before >> regeneration ;) >> >> -- >> 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. >> >> > -- > 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. > -- Sébastien Lelong -- 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.
