printf?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

printf?

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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

adrianv
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

OpenSCAD mailing list-2
In reply to this post by JordanBrown
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

JordanBrown
In reply to this post by adrianv
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

JordanBrown
In reply to this post by OpenSCAD mailing list-2
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

adrianv
In reply to this post by JordanBrown
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

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

Troberg
In reply to this post by JordanBrown
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

RevarBat
In reply to this post by JordanBrown
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

doug.moen
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 <[hidden email]> 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: printf?

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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: printf?

JordanBrown
On 10/3/2020 12:46 PM, Torsten Paul wrote:
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.

I'm an old-school C guy and can only barely spell C++, but based on experience with printf my guess is that the C/C++ library won't really help implement a printf-style function like this in your own language.  The problem is in data types and argument passing - somehow you have to take the arguments and data types from your language and massage them into being in the form that the underlying C/C++ library wants.  For C and printf it just isn't possible; there's no way to dynamically generate the call-style argument list that printf and its friends want.

Maybe the C++ function is more flexible - maybe it can take some kind of multi-type array as its argument list - but I wouldn't be too optimistic.

Thankfully, writing a traditional printf is not very hard, and I expect that this one is not much harder.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: printf?

nophead
That has always been the case, even in C. The solution was vprintf, which takes a structure holding the arguments instead of a variable number of arguments.

On Sat, 3 Oct 2020 at 23:47, Jordan Brown <[hidden email]> wrote:
On 10/3/2020 12:46 PM, Torsten Paul wrote:
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.

I'm an old-school C guy and can only barely spell C++, but based on experience with printf my guess is that the C/C++ library won't really help implement a printf-style function like this in your own language.  The problem is in data types and argument passing - somehow you have to take the arguments and data types from your language and massage them into being in the form that the underlying C/C++ library wants.  For C and printf it just isn't possible; there's no way to dynamically generate the call-style argument list that printf and its friends want.

Maybe the C++ function is more flexible - maybe it can take some kind of multi-type array as its argument list - but I wouldn't be too optimistic.

Thankfully, writing a traditional printf is not very hard, and I expect that this one is not much harder.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: printf?

tp3
In reply to this post by JordanBrown
On 04.10.20 00:46, Jordan Brown wrote:
> Maybe the C++ function is more flexible - maybe it can take
> some kind of multi-type array as its argument list - but I> wouldn't be too optimistic.

It's C++, it can handle custom data types quite well and
the library defines a dedicated interface to both parse
custom format specifiers and the actual formatting of
user defined data types.

Example: https://godbolt.org/z/nsdcTY

I have not tried with something more complicated like
the nested vectors, but it's not comparable to the printf
way of doing things at all.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: printf?

JordanBrown
[ Oops, sent the first time as a private message. ]

On 10/3/2020 4:25 PM, Torsten Paul wrote:
It's C++, it can handle custom data types quite well and the library defines a dedicated interface to both parse custom format specifiers and the actual formatting of user defined data types.

Indeed, it looks like it probably can handle it from a data type perspective.

And make_format_args and friends look like they provide a way to dynamically create an argument list, which is one of the big things that C lacks.

Cool.

Apologies for not checking it out first.

I have not tried with something more complicated like
the nested vectors, but it's not comparable to the printf
way of doing things at all.

I don't know that it needs to handle those.  Handling those would involve making decisions about how to format them, and the whole idea is to give formatting control to the OpenSCAD program.  You can always str() them if you just want OpenSCAD to format them.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org