outdated samples

[Joep Suijs]

Hi guys, Seb,

I found two samples that are not regenerated today:
16f88_ir_ranger_gp2d02.jal
16f88_pwm_led.jal

I'll remove them unless anybody objects.

Regards,
Joep

[Sebastien Lelong]

Hi Joep,

Why removing them ? They can still be useful, or am I missing something ?

Cheers

Seb

2012/4/22 Joep Suijs <jsu...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--
Sébastien Lelong

[Rob Hamerling]

Hi Joep,

On 04/22/12 07:47 pm, Joep Suijs wrote:

> I found two samples that are not regenerated today:
> 16f88_ir_ranger_gp2d02.jal
> 16f88_pwm_led.jal
>
> I'll remove them unless anybody objects.

What is the definition of an 'outdated sample'?

- There is an 'ir_ranger_gp2d02' library and you want
to remove the only sample for this library?
- What's wrong with the 16f88_pwm_led sample?

Regards, Rob.

--
R. Hamerling, Netherlands --- http://www.robh.nl

[Joep Suijs]

These samples were once generated by jallib.py, but are not any
longer. This means they are not updated when the board files or test
files are updated.

It is okay to keep those if you trust they are okay.
From now on, I intend to remove all samples with the text
'generated.by.jallib.py' before placing the newly generated samples.
This way *generated* samples remain up to date.

Joep

2012/4/22 Rob Hamerling <robham...@gmail.com>:

[mattschinkel]

Hey Joep, I'm not sure if you saw my other message.

Can you please rename the files to eeprom_24lc256 so everyone knows
it's an eeprom?

For example,

lib name:
24lc256_extended.jal

sample:
18f4550_24lc256_extended.jal

As you can see, all the current samples and libs contain the word
"eeprom" in them. It may be good to keep naming them this way. The
naming you have chosen is quite close to the naming of the device
files.

There are other libs with names that don't tell me what it is, for
example mcp9800.jal. I won't know what it is till I open the file.
Most other file names are clear.

Matt.

On Apr 22, 2:10 pm, Joep Suijs <jsu...@gmail.com> wrote:
> These samples were once generated by jallib.py, but are not any
> longer. This means they are not updated when the board files or test
> files are updated.
>
> It is okay to keep those if you trust they are okay.
> From now on, I intend to remove all samples with the text
> 'generated.by.jallib.py' before placing the newly generated samples.
> This way *generated* samples remain up to date.
>
> Joep
>

> 2012/4/22 Rob Hamerling <robhamerl...@gmail.com>:

>
>
>
>
>
>
>
>
>
> > Hi Joep,
>
> > On 04/22/12 07:47 pm, Joep Suijs wrote:
>
> >> I found two samples that are not regenerated today:
> >> 16f88_ir_ranger_gp2d02.jal
> >> 16f88_pwm_led.jal
>
> >> I'll remove them unless anybody objects.
>
> > What is the definition of an 'outdated sample'?
>
> > - There is an 'ir_ranger_gp2d02' library and you want
> >  to remove the only sample for this library?
> > - What's wrong with the 16f88_pwm_led sample?
>
> > Regards, Rob.
>
> > --

> > R. Hamerling, Netherlands ---http://www.robh.nl

[mattschinkel]

sorry, posted in the wrong topic

[Joep Suijs]

Hi Matt,

I've seen you've made different, contradicting naming suggestions.

Specific about this 24lc* functionality: I guess when there is a lib
called '24lc256', people tend to use this and not notice one called
'24lc256_enhanced'. I'd rather have the difference in both names, e.g.
like _compact vs _fast (of _enhanced).

> As you can see, all the current samples and libs contain the word
> "eeprom" in them. It may be good to keep naming them this way. The
> naming you have chosen is quite close to the naming of the device
> files.

There is no 24lc* lib or sample with 'eeprom' in the name. Your libs
have ee_ in the name, which is probably only informative once you know
it means eeprom. The samples lack ee_ in the name, so there is no
direct link. And you used the name space that would be logic for my
(current) lib name.
I'm not sure in what way such a description in the name is useful. The
function of a particular chip is easy to find with google if required,
and it is also described in the lib itself. A user will be looking
for a library supporting his particular chip and not 'an eeprom',
regardless of the type, size, interface etc?

Note that the naming mismatch between the sample and lib is true for
quite a few samples and we might consider to change this: a sample is
mandatory for each lib and unless there is a good reason, the name of
the sample should be the same as the lib.


2012/4/30 mattschinkel <mattsc...@hotmail.com>:

[mattschinkel]

> There is no 24lc* lib or sample with 'eeprom' in the name.

I am only concerned about the file name, not the procedure names. See
here:
http://jallib.googlecode.com/svn/trunk/include/external/storage/eeprom/

> for a library supporting his particular chip and not 'an eeprom',
> regardless of the type, size, interface etc?

First the user will look for the word eeprom, then they will look for
a particular chip. In grouping things, you usually look for the most
common word first.

For example, If you go to the microchip website, you will first click
on memory, then eeprom, then lastly, the device name.

> Your libs have ee_ in the name, which is probably only informative once you know it means eeprom.

Yes, you will know what ee_ is after you read the file name. If you
feel it needs to be changed, we can do so.

> The function of a particular chip is easy to find with google if required, and it is also described in the lib itself.

True, but this is about advertizing and an easy way for someone to
find an eeprom in the jallib pack.

As a jallib user shopping for an eeprom, I first look in the jallib
pack to see what jallib supports before I go out and purchase. I would
not like to open every file in the package to read what it is until I
find an eeprom. I think this is the most important point. How many
files do we have?

> Note that the naming mismatch between the sample and lib is true for
> quite a few samples and we might consider to change this: a sample is
> mandatory for each lib and unless there is a good reason, the name of
> the sample should be the same as the lib.

I do believe future samples can be named better, and according to the
lib. Maybe this should go in JSG. Libs must be named correctly
however.

Anyways, I hope you conciser my suggestion.

Matt.

[Joep Suijs]

Hi Matt,

I gave you an alternative with arguments to you failed to respond, so
I guess 'I hope you conciser my suggestion' means 'do it my way'.
This has happened before with new libraries and does happen again: I
spend more time on making libraries jallib compliant (with comment,
samples and so) and lengthy discussions than on the library
development itself. This is just not effective any more. I'm done with
this and similar discussions.
I will revoke the recent additions and will think twice before adding
a new library again.

Joep


2012/4/30 mattschinkel <mattsc...@hotmail.com>:

[mattschinkel]

> I gave you an alternative with arguments to you failed to respond

I'm not sure what I failed to respond to. Maybe this?

> Specific about this 24lc* functionality: I guess when there is a lib
> called '24lc256', people tend to use this and not notice one called
> '24lc256_enhanced'. I'd rather have the difference in both names, e.g.
> like _compact vs _fast (of _enhanced).

I don't mind changing the name of my files to _simple or _compact.
However, it should also contain eeprom_

I thought I mentioned this in the other topic, that I am willing to
rename files.

Was there another point I did not respond to?

I'm surprised you get upset about suggestions. Name them as you like.
When I stated "Anyways, I hope you conciser my suggestion. ", this
meant that if you don't like my suggestion, don't do it. It does not
mean do it my way. I'm not sure how you pulled that out of the
sentence that I wrote.

I only wish to help new users find and use our libraries.

I apologize if I have offended you in any way, although i don't know
how I did that.

Matt.