On 23 mrt, 19:23, Joep Suijs <[email protected]> wrote:
> Hi Guys,
>
> Seb, if you don't know which lib to choose, then there probably will
> be more people out there. So maybe it is good to go into the
> difference first.
>
> format.jal was created by Stef and provides functions to print vars
> and control the format. This can be fixed point format, date etc. The
> functions take more parameters then just straight forward output of
> vars.
> IMHO format.jal is very usefull if you want to print into a tight
> space, like lcd's.
> Downside of the lib iirc is that it does not support var types of jal.
> And it does not always does fill exactly the space given.
>
> For my personal use (debugging via the serial port) I needed a lib
> that can print all jal var types in hex and decimal format. Formatting
> is not needed. So I created print.jal, based on the genious structure
> of 'pseudo var streams' that Stef used for format.jal.
>
> Richard, I don't know if you intend to go to one interface for both
> simple and formatted print. I would not be in favor for this, because
> I think the formatted output is valuable, but the (more compact call
> of) print interface is also good to have. So I'd like to keep both
> API's.
Don’t get me wrong, i only started a discussion because i always use
both
and i think it must be possible to combine them without making
concessions.
I will only change (of course with some of your help) if every body is
in favour.
>
> Now about merging of files
> I think there remains a need for both libs' function. But if it is
> more easy to base one lib on the other or share functions, this would
> be wise. Duplicate code should be avoided, just like similar code.
> Apart from this, we need to decide for the structure.
> - We could merge both into one lib. The one to be depricated should
> contain two lines: one with the message and one to include the
> remaining lib.
Good idea, it keeps compiling but wil generate a warning so people can
change
> - We could use one lib as the base and the second one just for the
> stubs. The second one should then include the first one
> - The base could be moved to a third, generic lib, leaving the stubs
> into the two current libs.
>
> But this is technical.
but interesting , if we all agree, i will (if its ok with you) need
more information from you.
Not everything is clear to me what you want and how you want it.
For instance the “n_tot” in format could give more trouble than
benefits as far
as i can see at this point (value counting up en down in a loop).
But maybe we can discuss this later.
> If it is difficult to choose, then merging them would be best because
> users not have to choose any more *and* see the alternative functions
> when they look at the documentation.
i will wait for you all to decide
greetz
Richard
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
