[jallib] r3056 committed - MCP4922 DAC lib & sample, contributed to jallib by Peter Renske....

29 views
Skip to first unread message

jal...@googlecode.com

unread,
Apr 30, 2012, 2:30:51 PM4/30/12
to jal...@googlegroups.com
Revision: 3056
Author: sebastien.lelong
Date: Mon Apr 30 11:30:40 2012
Log: MCP4922 DAC lib & sample, contributed to jallib by Peter Renske.
Sorry, I can't provide support...
http://code.google.com/p/jallib/source/detail?r=3056

Added:
/trunk/include/external/dac
/trunk/include/external/dac/mcp4922.jal
/trunk/sample/18f27j53_mcp4922.jal

mattschinkel

unread,
Apr 30, 2012, 6:46:19 PM4/30/12
to jallib
I suggest naming like dac_mcp4922.jal, I know you didn't write these
files though.

I guess it's too difficult to get good naming on our files.

Matt.

On Apr 30, 2:30 pm, jal...@googlecode.com wrote:
> Revision: 3056
> Author:   sebastien.lelong
> Date:     Mon Apr 30 11:30:40 2012
> Log:      MCP4922 DAC lib & sample, contributed to jallib by Peter Renske.
> Sorry, I can't provide support...http://code.google.com/p/jallib/source/detail?r=3056
>
> Added:
>   /trunk/include/external/dac
>   /trunk/include/external/dac/mcp4922.jal
>   /trunk/sample/18f27j53_mcp4922.jal

Oliver Seitz

unread,
May 1, 2012, 12:24:02 AM5/1/12
to jal...@googlegroups.com
I think people would easier accept to conform to style and naming conventions, if the existing files did.

"calendar.jal" doesn't do much. And, it does not conform to nothing. Well, the filename explains the function a bit, but that's all. If added today, this file would have no chance to survive. So, there's a discrepancy: Dumb old code is kept because it's already there, and new clever code must go, because its clothes don't conform to the dress code.

I think, either the standards must be lowered, or the existing code must brought up to the high standard.

Greets,
Kiste

Eur van Andel

unread,
May 1, 2012, 1:24:53 AM5/1/12
to jal...@googlegroups.com
On 1 mei 2012, at 06:24, Oliver Seitz <karl...@yahoo.com> wrote:

> calendar.jal" doesn't do much. And, it does not conform to nothing. Well, the filename explains the function a bit, but that's all. If added today, this file would have no chance to survive.

Calendar.jal takes care of everything except seconds, i.e. minutes, hours, date, month, year. It also keeps seconds below 60. The ISR increases the seconds.

The only function is named calendar(). It knows about the number of days in each month and the leap years until 2099.

How would you propose naming it?
What should it do extra?


Sent from my iPhone

Oliver Seitz

unread,
May 1, 2012, 1:36:26 AM5/1/12
to jal...@googlegroups.com

> "calendar.jal" doesn't do much. And, it does not conform to
> nothing. Well, the filename explains the function a bit, but
> that's all.

Thinking about that again, the filename is misleading. In the basic sense, a calendar is a device made from papaer or cardboard, used to find out today's date using knowledge of the weekday, or to find out the weekday using knowledge of the date. Both tasks are not covered by "calendar.jal". It only checks if a minute has passed, if yes, it moves a time pointer forward. If I should sum up this function very short, I would come to something like "carry seconds to * to years", but not "calendar".

Greets,
Kiste

Oliver Seitz

unread,
May 1, 2012, 1:55:33 AM5/1/12
to jal...@googlegroups.com
Hi, Eur,

> What should it do extra?

I've added a lib "big_calendar.jal" which has some extra functions:

- All leap years according to the gregorian calendar rules
- Function to calculate the weekday of a given date
- Function to add or subtract a number of days to/from a date
- Function to calculate the date of easter sunday for western churches

For a standard RTCC application, big_calendar has a bit a bigger footprint than calendar.jal, partly due to the use of records as parameters, but it can really act as a calendar for bigger applications.

Greets,
Kiste

Oliver Seitz

unread,
May 1, 2012, 2:06:47 AM5/1/12
to jal...@googlegroups.com
Hi again :-)

Eur, please do not feel you or your work as critisized. It was just an example of existing code I have read recently. When I wrote my lib, it took four days to write, and more than a week to comply with the wishes of jallib team members. Then I was a bit jealous, for your code is in there, and noone minds how global variables are named. Now, my extended version has to declare functions as internal, prefixes here, there, but not like that...

I just wanted to point out that it's probably not such a good idea to have very high standards for new additions, while existing code does not at all come near these standards.

Greets,
Kiste

(Kiste, of doos, als je niet het duits begrijpt :-)

Sebastien Lelong

unread,
May 1, 2012, 3:13:35 AM5/1/12
to jal...@googlegroups.com
Hi guys


Lib was renamed.

As for styles, dress code and clothes :) taking your library, Kiste, I had a quick look at that time and saw potential collision with variables names. I already faced this, while writing user code, so I think it's better to be paranoid on lib level. calendar.jal didn't suffer from this paranoid state, probably because it was the beginning of jallib, I don't know.

On this particular point (global variable), strictly speaking, this has nothing to do with styles/dress code. It was suggestions only, sharing my experience on this. Basically, if we add namespaces, things would be much easier. We could ask Kyle.

Finally, about naming conventions themselves (prefixes, etc...), I obviously have worries about this, thinking about Joep who deleted his files for instance (filenames issues IIUC). We, from the beginning, have setup these standard, someone could qualify them as "high", I think mostly because existing jal code was a great mess (no offense). It was so probably because there were no community project, so everyone had his own standard. When I dive into jal at that time, it really wasn't easy... This explains, I guess, why we are here today. We could obvioulsy lower standards, but we need some (that's my point of view), or we'll be in a mess in few months, not helping ourselves, neither our users. Compromise should be found, but that's no easy.

Now, should we have strict naming conventions ? Should we "lower" standards" ? I don't know, but my 0.02$ are: you can't just name things, as it's not a 1..1 relation. There can't be naming convention for samples, because one sample can have different libs involved. You would have a 150 chars filenames. We're closed to database issues here, we'd need to collect metadata about libs and samples in order to properly restitute what's in there.

When complains are about libraries, I often say to myself this is "just" about namespace (language limitation). When complains are about samples, I often say to myself it's about metadata, ie. we need to build a database. Do I often say to myself things making sense, or not ? :) Le me know !


Cheers,
Seb


2012/5/1 Oliver Seitz <karl...@yahoo.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


vasile surducan

unread,
May 1, 2012, 4:05:02 AM5/1/12
to jal...@googlegroups.com
At least here, calendar is the name used for something is keeping everything which is passing slower than hours (meaning day, week, month, year). I'm using clock-calendar.
Vasile

mattschinkel

unread,
May 1, 2012, 7:59:21 AM5/1/12
to jallib
Maybe Seb can enforce naming. I am obviously not the right person to
do it.

Matt.

Eur van Andel

unread,
May 19, 2012, 7:44:25 AM5/19/12
to jal...@googlegroups.com
On 1 May 2012, at 08:06 , Oliver Seitz wrote:

Hi again :-)

Eur, please do not feel you or your work as critisized.

I don't mind constructive criticism. This is open source. Anybody can improve it. 
As long as the code it not broken, feel free to modify or add to it. 


-- 
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.


---

ir EE van Andel e...@fiwihex.nl  http://www.fiwihex.nl

Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands

tel+31-546-491106 fax+31-546-491107



Reply all
Reply to author
Forward
0 new messages