> > You keep ignoring my remark that as a consequence, the baudrate > setting and include serial need to be split. Why is this? Am I wrong? > Don't you concider this important?
I'm not ignoring, I just miss something :) Keep reading... > > But it pollutes our current libraries: they have to deal with an external > > constant, related to their proper usage. > Only to the degree that we might need to make a ez-lib (default-file) > for each other library and there is an include statement in the > orginal library. As I said, this is not perfect, but better then the > alternative. OK, so you prefer: - having a EZ constant, instead of a lib. - having baudrate defined as a default. Let's look what it would look like: With a constant, baudrate as default: """ include 16f88 const EZ = true include serial_hardware """ I don't like this : - which baudrate is it ? - what is the impact of EZ constant ? - will I have to look at all the different libraries to understand what's the behavior ? With a constant, no baudrate as default: """ include 16f88 const EZ = true const baudrate = 19_200 include serial_hardware """ I don't like this too: - what is the impact of EZ constant ? - will I have to look at all the different libraries to understand what's the behavior ? But what I like is: - baudrate is explicit, I know how to deal with it now. Now, example showing how to ovveride a default: """ include 16f88 const EZ = true const sync = true -- override include serial_hardware """ OK, the "sync" constant is near the include statement, we know it's related to this. (see later, with include statement). Now, why do you think having an EZ constant is better than having an include statement ? As I said (and I consider this as very important), having: """ if defined(EZ) == true & EZ == true then end if """ in all libs that could be "EZfied" is a real pollution, a "context leakage". >From the lib's point of view, it doesn't have to know in which context it executes, it does not have to handle it. There should be a clear separation/distinction between the libs we currently know, and the EZ mode. Having this EZ mode implemented in a lib: - centralize all defaults about it (really: do you want to open dozens of files to know how defaults are defined in each lib ?) - gives the opportunity to have different EZ mode (who knows), by defining more or less defaults in it (with a constant, it's a binary context) - don't confuse lib writers with an EZ constant: what should be in it ? why ? such questions don't have to be answered by the time you're writing the lib. Back to an example (baudrate not being a default) With an include """ include 16f88 include ez const baudrate = 19_200 include serial_hardware """ Clear, explicit. If I want, I can have a look at "ez.jal", I'll see all the defaults (and this will be a good exercise to understand all of them in order to leave the "EZ" mode if needed. Highly documented, this is also a nice source of information for people to learn the "behing the scene" mode. Same, but overriding a default: """ include 16f88 const sync = true include ez include serial_hardware """ OK, "sync" isn't just before serial_hardware. I'd prefer having the opportunity to overrule constants (and proc/func) as discussed in jallist few months ago, which would have given the opportunity to keep this const declaration near the include statement. That's the drawback here, and that's why we shouldn't put too much defaults to avoid this. But I think the advantages of having a lib worths it. More, when you start to do this, you're starting to leave the EZ mode. Either you can add your own EZ lib, or you decide to leave EZ mode. """ include 16f88 include my_not_so_ez -- EZ mode for everything except serial, because I'm a serial guru """ How would you do that with a const ? You won't let users define their own easy mode, as it's a binary switch. > >> But... I almost started on updating the pjal manual and if it was in > >> doc or docx format I probably would have. > > > > Nice ! Don't you think a format which could be put under SVN would be > better > > ? I mean ASCII format, like docbook or LaTEX ? What's the current format > ? > It is currently in lyx format.I downloaded an editor and played around > with it for an hour or so with little result, so I put it asside at > the time (also since no-one seems to give this a high prioriy). > I am willing to take the editor role but do need support - people > writing & reviewing parts and perferable a native english speaker to > translate it from denglish to english ;) Or frenglish to english... > > And about the baudrate: > I don't see the fundemental difference why you should specify baudrate > but can use a default for async (vs sync). Because baudrate is highly changeable, modifiable. Sync is rarely used. > But it is okay with me to > give defaults for all items execpt for baudrate. I do suspect that > there will be new 'baudrate' alike discussions so what would be the > criteria. I'm sure there will be ! > > For instance for the chip pragma's. I think most users use an external > oscillator at the highest possible frequency, do not use lvp and do > not want the watchdog. Could we agree that these become defaults > (provided it is doable)? what about internal osc ? It's also widely used, because it requires no external part. What if we can do, as I suggested: configure_clock(20_000,false) -- false: not internal clock This would give: """ include 16f88 include ez configure_clock(20_000,false) """ Is it easy enough ? Then, in a hardware file, you can default this. > > Note: one could argue those need to be in the hardware/board file. > This makes it easier when you have pre-defined board (jalduino..). But > it make things more complex in other cases (in the way that people > might see two different ways of handling - in the program itself or in > a board file). Sorry, I'm sure to catch all the meaning here... Why would it be more complex ? Seb -- 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 -~----------~----~----~----~------~----~------~--~---
