(Does it have
#b?)
any idea if neovim merges from vim or if I need to submit separately?
(floats are separate btw and they look correct)
while doing that I found out that
single in C gets converted to double when you pass it to a varargs function.
that's why there is no format specifier for single.
Okay, day 3 of AoC is done, anyone wishing to see pretty bad dylan code can look; https://github.com/Slids/advent-of-code-2021
question: Can I write lambdas in dylan?
map(method(p) as(<directory-locator>, p) end,
tokenize-environment-variable(path))
@housel what would be the best way to convert 8 big-endian bytes representing a two's complement int64 to a Dylan
<integer>? I'm currently doing this: https://github.com/cgay/time/blob/master/tzif.dylan#L288 but it broken for a couple of reasons and I'm wondering if using <machine-word> and then coercing to integer would be a better way to go.
I can make it work with my current approach but getting the sign right and not overflowing unnecessarily is a bit finicky.
I also stumbled once more over the question of where <byte-character> should be imported from. I remember having a conversation with bruce (IMO?) about this where he told me that it shouldn't matter much, and he is technically right. but I still find it a little bit annoying. I know it's not always trivial to do these changes, but I do think that they are worthwhile.
the characters should really just be in
dylan. or common-dylan. it makes little difference to me.
@slids experience the other day has motivated me to work on single-file libraries again soon. After re-reading https://opendylan.org/proposals/dep-0006-single-file-library.html I still think it's okay, but it's sort of a toss-up between that and just throwing the
define library and define module into the same file with the code, making certain assumptions, and making it "just work".
The DEP is probably closer to what people are used to: putting imports at the top in a header-like arrangement.
@housel I thought about eliminating <byte-string> in Marlais. it's not hard to do, but my affinity for C bindings makes me hesitate. my strategy right now is to treat <byte-string> as equivalent to a locale-correct
char *, <unicode-string> is backed by UCS2 because ICU prefers it, and I added <wide-string> as a direct equivalent to wchar_t *.
then there is <buffer> and <byte-vector>. I planned to implement copy-bytes for both of them as well as any string - at byte level.
(or more generally any vector that is restricted to immediates in a way that makes this useful)
but that isn't really terribly useful because of endianness IMO - so I'm not decided.
our approaches are compatible though. I want to concentrate on <unicode-string> too. the others are just binding voodoo.
@housel yeah. I only did it this way because none of my dependencies provides a full set of string functions for UCS4. I'll switch when it's convenient. It shouldn't make much difference for the user in the beginning.
other things I have defined is a "codepoint" limited type for each character size.
<unicode-codepoint>, <wide-codepoint> and obviously <byte>.
these make method definition beautifully explicit and move the error handling problem to the type system.
(which I think is a good thing)
I should really document those things.
that's old and closed actually.
ah. now I see. is there no way to link an issue from another project?