Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:38

    cgay on master

    [doc,library] Move logging and … Add links to other useful strin… [doc,strings] Add additional us… and 13 more (compare)

  • 02:38
    cgay closed #11
  • 02:24
    cgay opened #11
  • 02:19
    cgay closed #3
  • 02:19
    cgay commented #3
  • May 17 20:10

    cgay on master

    Publish http@1.1.1 Publish melange@0.1.1 Publish logging@2.2.0 and 4 more (compare)

  • May 17 20:10
    cgay closed #13
  • May 17 20:07
    cgay opened #13
  • May 17 19:52

    cgay on v3.2.0

    (compare)

  • May 17 19:47

    cgay on master

    Update package file for dylan-t… Update submodules to current ma… Add documentation, copied from … and 1 more (compare)

  • May 17 19:47
    cgay closed #28
  • May 17 18:08
    abeaumont unassigned #435
  • May 17 18:07
    abeaumont unassigned #301
  • May 17 18:04
    cgay opened #28
  • May 17 15:10

    cgay on v2.2.0

    (compare)

  • May 17 15:08
    cgay closed #16
  • May 17 15:08

    cgay on master

    Add dylan-package.json Copy logging documentation from… Update docs to match v2.0 Fixe… and 1 more (compare)

  • May 17 15:08
    cgay closed #20
  • May 17 15:01

    cgay on master

    Fix build/install of dylan-tool… Merge pull request #1434 from c… (compare)

  • May 17 15:01
    cgay closed #1434
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
Carl Gay
@cgay
ah. that's a thing.
Peter S. Housel
@housel
Or element.io
promovicz
@promovicz
I don't normally check this place on my phone. To many notifications on the phone are bad for the brain.
promovicz
@promovicz
do we have code somewhere that abstracts key bindings in a nice way?
what I mean is something like emacs key bindings. parsable key combination descriptors and state machine based function dispatch.
I am looking for use in command-interface.
Peter S. Housel
@housel
The only possible place for that would be in DEUCE, and I'm not that familiar with how key bindings work there
promovicz
@promovicz
DUIM doesn't seem to have advanced keyboard support either. guess I'll put it on the todo then. it's not that critical.
I'll do dumb terminal support next. then you can finally use it in emacs.
Carl Gay
@cgay
Something about /usr/share/zoneinfo/US/Aleutian has tickled a bug in my code. :) But progress...
promovicz
@promovicz
laughs
promovicz
@promovicz
I've made some progress with Marlais. With refactoring-heavy jobs like this I tend to keep backlog and squash it a little before pushing.
Carl Gay
@cgay
@Slids :point_up: January 17, 2020 12:41 AM
Jon Godbout
@Slids
tanks!
Carl Gay
@cgay
Oh man, link-target needs some love.
(file-system)