Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

finalize printf format calling syntax #140

Closed
StefanKarpinski opened this issue Jul 20, 2011 · 14 comments
Closed

finalize printf format calling syntax #140

StefanKarpinski opened this issue Jul 20, 2011 · 14 comments
Assignees
Labels
breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@StefanKarpinski
Copy link
Member

See #29 (comment):

We should write a wrapper for printf that looks at the format string to check/convert arguments, then calls printf on each format specifier individually.

@ghost ghost assigned StefanKarpinski Jul 20, 2011
@JeffBezanson
Copy link
Member

Shall we 2.0 this?

@StefanKarpinski
Copy link
Member Author

No, I'm still aiming to get to this. Working on the last sections of the manual currently. After that I'm going to tackle all the printing and formatting stuff. It's hard to get any real work done without this.

@StefanKarpinski
Copy link
Member Author

Concluded at JuliaCon 1.0day1: should probably implement plain old functions that implement the various printf formatting features, then play around with different ways of invoking them.

@JeffBezanson
Copy link
Member

This is looking pretty good. What's left to do here?

@StefanKarpinski
Copy link
Member Author

The parsing all works, but actual printing doesn't always work. E.g. Zero padding is horribly broken, most conversion specifiers don't actually work, etc. I'll take another pass at it soon and whip it all into shape.

@StefanKarpinski
Copy link
Member Author

We still need to finalize the API to printf. That is a breaking change.

@JeffBezanson
Copy link
Member

Next step is to benchmark the function call version, printf("%d", n), with a cache mapping format strings to generated code. If performance is ok, we should go with that. Otherwise it should be printf(f"%d", n), or maybe print(f"%d", n) to cut down on f's, requiring the first argument to be an f"" formatter.

@StefanKarpinski
Copy link
Member Author

I kind of like print(f"%d", n). I've thought of that before. As a corollary, I feel like we'd also have to rename print_to_string as sprint.

@nolta
Copy link
Member

nolta commented Apr 19, 2012

printf"%d"(n) ?

@JeffBezanson
Copy link
Member

I think we pretty much concluded it had to look like a normal function call or it would be too weird.

The devious thing about print(f"%d",...) is that if you forget the f it's obviously not a printf, just a normal call to print where the first argument is a string. I like it.

The only remaining case is building a format string at run time, which people sometimes do. The best thing I can think of is an alternate formatting API that doesn't require parsing format strings. Hopefully it could call bits of printf's functionality. Then we can say to use that instead of building format strings.

@JeffBezanson
Copy link
Member

Other thought: maybe f"" should give something of a specific type other than Function.

@pao
Copy link
Member

pao commented Apr 19, 2012

FormatString, maybe, containing an anonymous formatter function in a field that gets accessed by printf and sprintf?

@StefanKarpinski
Copy link
Member Author

Ok, I like this plan. A FormatString object can also print nicely (like Regex objects do). The only issue this leaves is making sure that code using the print(f"", ...) and constructing an object containing a function at compile and then applying that at run time can be made fast enough. If that's not the case, I may as well rewrite the printf functionality to just parse at runtime like the C version does. I still think the code gen approach can with work on I/O be made faster than C, so I'd rather keep the code gen approach.

@StefanKarpinski
Copy link
Member Author

Closed by 04f542d.

KristofferC added a commit to KristofferC/julia that referenced this issue Feb 18, 2018
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Oct 11, 2021
Keno pushed a commit that referenced this issue Oct 9, 2023
* An export-worthy API for break_on_error

Some day we hope to have more possibilities for triggering automatic
breakpoints (issue #102). For now, let's at least establish an
extensible user-level API.
NHDaly pushed a commit that referenced this issue May 22, 2024
* --safe-crash-log-file flag

* Update init.c

* json escape jl_safe_printf when safe crash log file

* add timestamp to json logs

* port it to aarch64 darwin

* fix minor warning

* missing double quote

* Suggestion from code review: make sig_stack_size a const in signals-unix.c

Co-authored-by: Kiran Pamnany <[email protected]>

* Suggestion from code review: make sig_stack size a const in signals-win.c

Co-authored-by: Kiran Pamnany <[email protected]>

* more suggestions from Kiran's review

* more suggestions from review

---------

Co-authored-by: Malte Sandstede <[email protected]>
Co-authored-by: Adnan Alhomssi <[email protected]>
Co-authored-by: Kiran Pamnany <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

4 participants