Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
promovicz
@promovicz
any idea if neovim merges from vim or if I need to submit separately?
(floats are separate btw and they look correct)
Peter S. Housel
@housel
Do they handle d (<double-float>) or s (<single-float>) as well as e exponent?
promovicz
@promovicz
oh you can specify that!? is there an e for <extended-float> too?
Peter S. Housel
@housel
There's an x but we don't implement <extended-float> in OD
promovicz
@promovicz
I don't think it does. it misses the type specifier.
Peter S. Housel
@housel
e is just floating exponent without a type specified; DFMC picks a type based on how many digits of precision you include (not intuitive if you ask me)
promovicz
@promovicz
sure. I know we don't really do <extended-float>. I just recently considered adding it to marlais because it looked easy. which it isn't because libc and libm don't do a lot of long double.
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.
Jon Godbout
@Slids
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?
Peter S. Housel
@housel
Yes, lambda is spelled method
    map(method(p) as(<directory-locator>, p) end,
        tokenize-environment-variable(path))
Jon Godbout
@Slids
tanks!
Jon Godbout
@Slids
having a programming language with the same name as a major artist leads to mediocre googling...
Carl Gay
@cgay
@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.
Carl Gay
@cgay
Just have a feeling I might be overlooking something obvious.
Peter S. Housel
@housel
No, that looks perfectly reasonable
Carl Gay
@cgay
ok :thumbsup:
promovicz
@promovicz
I plan to reintroduce "fluid" <big-integer> in Marlais. that will allow me to define anything from <byte> to <uint128> with no trouble. I wish it was that easy in OD. or is it?
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.
Peter S. Housel
@housel
I have a Unicode branch where I've eliminated <byte-string> and <byte-character> entirely, all strings are immutable UTF-8
Carl Gay
@cgay
@promovicz I agree with you that little annoyances like "where do i import <byte-character> from?" are worth fixing, especially when they're for essential things like that. They can make a big difference to new learners.
Carl Gay
@cgay
@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.
Carl Gay
@cgay
No, it's not a toss-up. The non-DEP way is better because it allows for implementation and interface modules, which also supports making a test library for a single-file library better. I think I'll redo the DEP, if only to write down current thoughts for when I get a round tuit.
promovicz
@promovicz
@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.
Peter S. Housel
@housel
ICU prefers UCS2 only for historical reasons, and because so many platforms (also for historical reasons) have 16-bit wchar_t
promovicz
@promovicz
I provide aliases called <standard-character> and <standard-string> that get used for things like as(<string>, s).
@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.
promovicz
@promovicz
in the future there will likely be UCS4 support in libc on modern platforms. char16_t and char32_t already exist after all.
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.
Carl Gay
@cgay
PRs, if anyone wants to look. I'll merge 126 tonight.
promovicz
@promovicz
#126 ?
that's old and closed actually.
ah. now I see. is there no way to link an issue from another project?
Peter S. Housel
@housel
promovicz
@promovicz
:)
Carl Gay
@cgay
They show up on the right side panel. :arrow_right:
Peter S. Housel
@housel
Unless you're using the mobile app