From spxtr to ~sircmpwn/hare-dev
LGTM DEFAULT seems wrong to me as a language thing. Normally I would just write 0, but if it's the standard for hare then it's fine.
From Joe Finney to ~sircmpwn/hare-dev
My apologies. Signed-off-by: Joe Finney <me@spxtr.net> --- Feel free to disregard this patch if it's not worth the bother. cmd/harec/context.ha | 2 +- cmd/harec/qbe.ha | 2 +- crypto/aes/cbc+test.ha | 2 +- crypto/aes/ct64+test.ha | 2 +- crypto/aes/rt+test.ha | 2 +- crypto/aes/xts/xts.ha | 2 +- crypto/bcrypt/+test.ha | 2 +- crypto/bcrypt/bcrypt.ha | 2 +- [message trimmed]
From spxtr to ~sircmpwn/hare-dev
LGTM. I just sent another patch that tests the result of this, and it all passes.
From Joe Finney to ~sircmpwn/hare-dev
Signed-off-by: Joe Finney <me@spxtr.net> --- This will only pass after ecs' patch goes in. I wasn't sure how to make it send in reply to that message. strconv/+test/ftos_test.ha | 43 +++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/strconv/+test/ftos_test.ha b/strconv/+test/ftos_test.ha index 2adb55c6..5aa668ac 100644 --- a/strconv/+test/ftos_test.ha +++ b/strconv/+test/ftos_test.ha @@ -1,7 +1,9 @@ // SPDX-License-Identifier: MPL-2.0 [message trimmed]
From Joe Finney to ~sircmpwn/hare-dev
Signed-off-by: Joe Finney <me@spxtr.net> --- strconv/ftos.ha | 2 ++ 1 file changed, 2 insertions(+) diff --git a/strconv/ftos.ha b/strconv/ftos.ha index accb470c..c4f5b90b 100644 --- a/strconv/ftos.ha +++ b/strconv/ftos.ha @@ -10,6 +10,7 @@ use memio; use strings; use types; // Format styles for the [[ftosf]] functions.[message trimmed]
From Joe Finney to ~sircmpwn/hare-dev
For void precision, uses Ryu algorithm. For uint precision, uses a multiprecision implementation heavily based on golang's strconv. The rounding and encoding functions are highly nontrivial, largely because I decided to add a SHOW_POINT flag. Signed-off-by: Joe Finney <me@spxtr.net> --- v6: and also fix lint. this should be added to make check imo. makefiles/freebsd.aarch64.mk | 4 +- makefiles/freebsd.riscv64.mk | 4 +- makefiles/freebsd.x86_64.mk | 4 +- makefiles/linux.aarch64.mk | 4 +- makefiles/linux.riscv64.mk | 4 +- [message trimmed]
From Joe Finney to ~sircmpwn/hare-dev
For void precision, uses Ryu algorithm. For uint precision, uses a multiprecision implementation heavily based on golang's strconv. The rounding and encoding functions are highly nontrivial, largely because I decided to add a SHOW_POINT flag. Signed-off-by: Joe Finney <me@spxtr.net> --- v5: addressed Ember's comments. fftosf does make sense despite the abundance of fs. makefiles/freebsd.aarch64.mk | 4 +- makefiles/freebsd.riscv64.mk | 4 +- makefiles/freebsd.x86_64.mk | 4 +- [message trimmed]
From Joe Finney to ~sircmpwn/hare-dev
For void precision, uses Ryu algorithm. For uint precision, uses a multiprecision implementation heavily based on golang's strconv. The rounding and encoding functions are highly nontrivial, largely because I decided to add a SHOW_POINT flag. Signed-off-by: Joe Finney <me@spxtr.net> --- This is roughly the same as v3, except I changed the interface to one single ftosf and ftosfh function, rather than one for each type. IMO this is better. stdlib.mk | 7 +- strconv/+test/ftos_test.ha | 230 ++++++++ [message trimmed]
From spxtr to ~sircmpwn/hare-users
In main, you have for(let i = 1; i < 10; i += 1) { let newlink: link = link{val:int = i, pnext = null}; ins_link(cur, &newlink); }; newlink is stored on the stack. from one loop iteration to the next the memory may be reused. it's the same issue as if you try to return a pointer to a local variable in a function. you need to alloc(link {...}) to get a pointer to a heap-allocated struct. let newlink: *link = alloc(link{val:int = i, pnext = null}); ins_link(cur, newlink);
From Joe Finney to ~sircmpwn/hare-dev
For void precision, uses Ryu algorithm. For uint precision, uses a
multiprecision implementation heavily based on golang's strconv.
The rounding and encoding functions are highly nontrivial, largely
because I decided to add a SHOW_POINT flag.
Signed-off-by: Joe Finney <me@spxtr.net>
---
1. Is this interface okay? I don't like that every function is
duplicated for f64 and f32, only to be recombined in the generic
function. It doesn't seem necessary. Why not just one ftosf (and
ftos) that takes a (f32 | f64), like floatingtos?
2. The code is significantly more complicated than I would prefer. I
think this is largely because of SHOW_POINT and G. I'll look for ways
[message trimmed]