printf?
The issue with echo made me think: would people be interested in a
printf()-like module and function? The idea would be to give the
program complete or almost-complete control over the exact data written,
without adding any decoration and providing printf-like formatting.
Not a complete formatting solution, but you might find this interesting:
https://github.com/revarbat/BOSL2/wiki/strings.scad#str_format
JordanBrown wrote
The issue with echo made me think: would people be interested in a
printf()-like module and function? The idea would be to give the
program complete or almost-complete control over the exact data written,
without adding any decoration and providing printf-like formatting.
--
Sent from: http://forum.openscad.org/
Jordan Brown asked:
The issue with echo made me think: would people be interested >in a printf()-like module and function? The idea would be to give the>program complete or almost-complete control over the exact data written, >without adding any decoration and providing printf-like formatting.
I would be very glad of that.
What can be done to facilitate it?
William
On 10/2/2020 3:25 PM, adrianv wrote:
Not a complete formatting solution, but you might find this interesting:
https://github.com/revarbat/BOSL2/wiki/strings.scad#str_format
Give or take the familiarity of printf, that looks very much what I was
looking for. But ideally it would be in the core so always available.
I'm not quite sure why I say that, other than for whatever reason I
haven't personally adopted any of the existing libraries. Well, and
because I shudder to think what the implementation must look like.
What have you found to be the limitations of this design, both in terms
of using it and its implementation?
Looks like it's copied it from Python. Right? Looks like it's a
partial implementation; maybe a C implementation could be more
complete. Matching Python as much as possible would be a win, for
familiarity reasons.
printf's familiarity has pluses and minuses. It's familiar, but at the
same time the fact that it's got a strong notion of embedding the
expected type in the format string doesn't fit well with an environment
where the argument will tell you what type it is. Printf has mechanisms
for processing the values out of order, but they are ugly.
I have to say that I didn't know about Python's {n:opts} formatting
style until just now, but I think I like it better than printf. Given
that it's Python, one hopes that it will be well-adopted and thus
familiar to many... though I have to note that I haven't seen it used in
any of the Python I've seen. (Which might well date back to before it
was introduced in 2.6.)
On 10/2/2020 4:19 PM, William F. Adams via Discuss wrote:
I would be very glad of that.
What can be done to facilitate it?
The immediate answer is the one that Adrian gave: it looks like BOSL2
has a pretty good one already.
The question then becomes what the advantages and disadvantages would be
to moving it into C in the core.
Revar wrote this implementation and I personally haven't been using it.
Maybe that's a mistake on my part, but I haven't been doing a lot of output.
The implementation doesn't look horrible. The main function is 50 lines.
But it does rely on the whole strings library which provides things like
substr(), str_join(), str_split() and formatting functions for the different
types. (If you want to see something with a scary implementation I have an
eigenvector decomposition code...)
The only formatting thing I've been really wishing for is rectangular
display of matrices, which seems to be impossible in the current stable
version because of HTML interpretation. If I insert spaces for formatting
they get eaten, even non breaking spaces and other special spaces seem to
behave unpredictably. Being able to print in a non-proportional font with
spaces that take up one character would make this much easier to do. With
tabs it's possible to get something that kind of works, as long as you keep
all the numbers to well known lengths so you know where the tab positions
are. (It's easy to end up with stuff at the wrong tab.)
JordanBrown wrote
Give or take the familiarity of printf, that looks very much what I was
looking for. But ideally it would be in the core so always available.
I'm not quite sure why I say that, other than for whatever reason I
haven't personally adopted any of the existing libraries. Well, and
because I shudder to think what the implementation must look like.
What have you found to be the limitations of this design, both in terms
of using it and its implementation?
Looks like it's copied it from Python. Right? Looks like it's a
partial implementation; maybe a C implementation could be more
complete. Matching Python as much as possible would be a win, for
familiarity reasons.
printf's familiarity has pluses and minuses. It's familiar, but at the
same time the fact that it's got a strong notion of embedding the
expected type in the format string doesn't fit well with an environment
where the argument will tell you what type it is. Printf has mechanisms
for processing the values out of order, but they are ugly.
I have to say that I didn't know about Python's {n:opts} formatting
style until just now, but I think I like it better than printf. Given
that it's Python, one hopes that it will be well-adopted and thus
familiar to many... though I have to note that I haven't seen it used in
any of the Python I've seen. (Which might well date back to before it
was introduced in 2.6.)
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
It would be very nice, and it would be even better if the output could be
written to a file (which is overwritten on each run). That would remove a
bunch of very awkward solutions I have to use.
--
Sent from: http://forum.openscad.org/
Python also has printf style formatting via the % operator, but the new .format() function is highly recommended in Python 3. I took it as the inspiration.
-Revar
On Oct 2, 2020, at 8:22 PM, Jordan Brown openscad@jordan.maileater.net wrote:
On 10/2/2020 3:25 PM, adrianv wrote:
Not a complete formatting solution, but you might find this interesting:
https://github.com/revarbat/BOSL2/wiki/strings.scad#str_format
Give or take the familiarity of printf, that looks very much what I was looking for. But ideally it would be in the core so always available. I'm not quite sure why I say that, other than for whatever reason I haven't personally adopted any of the existing libraries. Well, and because I shudder to think what the implementation must look like.
What have you found to be the limitations of this design, both in terms of using it and its implementation?
Looks like it's copied it from Python. Right? Looks like it's a partial implementation; maybe a C implementation could be more complete. Matching Python as much as possible would be a win, for familiarity reasons.
printf's familiarity has pluses and minuses. It's familiar, but at the same time the fact that it's got a strong notion of embedding the expected type in the format string doesn't fit well with an environment where the argument will tell you what type it is. Printf has mechanisms for processing the values out of order, but they are ugly.
I have to say that I didn't know about Python's {n:opts} formatting style until just now, but I think I like it better than printf. Given that it's Python, one hopes that it will be well-adopted and thus familiar to many... though I have to note that I haven't seen it used in any of the Python I've seen. (Which might well date back to before it was introduced in 2.6.)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
C++20 adds std::format(), which is based on Python's string.format() method. It's more powerful than printf formatting. C# also has String.Format(), based on the Python syntax. In short, lots of people are standardizing on this design.
On Sat, Oct 3, 2020, at 10:46 AM, Revar Desmera wrote:
Python also has printf style formatting via the % operator, but the new .format() function is highly recommended in Python 3. I took it as the inspiration.
-Revar
On Oct 2, 2020, at 8:22 PM, Jordan Brown openscad@jordan.maileater.net wrote:
On 10/2/2020 3:25 PM, adrianv wrote:
Not a complete formatting solution, but you might find this interesting:
Give or take the familiarity of printf, that looks very much what I was looking for. But ideally it would be in the core so always available. I'm not quite sure why I say that, other than for whatever reason I haven't personally adopted any of the existing libraries. Well, and because I shudder to think what the implementation must look like.
What have you found to be the limitations of this design, both in terms of using it and its implementation?
Looks like it's copied it from Python. Right? Looks like it's a partial implementation; maybe a C implementation could be more complete. Matching Python as much as possible would be a win, for familiarity reasons.
printf's familiarity has pluses and minuses. It's familiar, but at the same time the fact that it's got a strong notion of embedding the expected type in the format string doesn't fit well with an environment where the argument will tell you what type it is. Printf has mechanisms for processing the values out of order, but they are ugly.
I have to say that I didn't know about Python's {n:opts} formatting style until just now, but I think I like it better than printf. Given that it's Python, one hopes that it will be well-adopted and thus familiar to many... though I have to note that I haven't seen it used in any of the Python I've seen. (Which might well date back to before it was introduced in 2.6.)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 03.10.20 17:45, Doug Moen wrote:
C++20 adds std::format()
And that would probably the interesting option. So we can
use a clearly defined spec.
Implementation wise c++20 is still far out of reach, but
the spec is based on the (even more flexible) fmt library
which, I believe, is c++14 compatible. This makes the lib
easily usable with OpenSCAD until a switch to c++20 is
possible.
ciao,
Torsten.