Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 08 22:56

    cgay on master

    file-system: Document link-targ… Merge pull request #1409 from c… (compare)

  • Dec 08 22:56
    cgay closed #1409
  • Dec 08 22:54
    cgay synchronize #1409
  • Dec 08 05:21
    cgay opened #1409
  • Dec 08 04:47
    cgay opened #1408
  • Dec 08 04:47
    cgay labeled #1408
  • Dec 08 04:41

    housel on master

    ssl: Update openssl-1.1 compati… Merge pull request #1405 from p… (compare)

  • Dec 08 04:41
    housel closed #1405
  • Dec 07 01:36

    cgay on master

    Rewrite DEP 6 -- single-file li… Merge pull request #127 from cg… (compare)

  • Dec 07 01:36
    cgay closed #127
  • Dec 07 01:34

    cgay on master

    Document the extention to numer… Merge pull request #1407 from c… (compare)

  • Dec 07 01:34
    cgay closed #1407
  • Dec 05 05:39

    cgay on master

    Iteration cheatsheet: add itera… Merge pull request #126 from cg… (compare)

  • Dec 05 05:39
    cgay closed #126
  • Dec 04 22:48
    cgay labeled #1407
  • Dec 04 22:48
    cgay opened #1407
  • Dec 04 22:19

    cgay on master

    Fix factorial-big registry entry (compare)

  • Dec 04 22:15
    cgay labeled #1406
  • Dec 04 22:15
    cgay opened #1406
  • Dec 04 20:38
    cgay opened #127
Carl Gay
@cgay
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)
I'm going to document it but not going to shave this yak just yet.
Peter S. Housel
@housel
What's wrong with it?
Seems straightforward
(Other than outdated Windows support)
Carl Gay
@cgay
It looks like if this unless https://github.com/dylan-lang/opendylan/blob/master/sources/system/file-system/unix-file-system.dylan#L162 does not call unix-file-error the function will infinite loop because link won't change. ?
Peter S. Housel
@housel
Ah. Yes, that should get fixed
Carl Gay
@cgay
But there are no tests so ... :)
It's just that feeling of "oh, it's not documented. No worries I'll just quickly write some simple doc for it. Oh, it's not tested, and oh isn't that a bug?"
Peter S. Housel
@housel
Indeed
Carl Gay
@cgay
TIL that when I put TODO(b/12345): in my code, the TODO shows up in the bug tracker for b/12345. Boy do I love good tooling. (Also, when I close b/12345 I'll get an email at some point reminding me to remove the TODO.)
Peter S. Housel
@housel
I’ve finally got my debugger-nub back to the point I had it at in late July, before I started a major refactor to split it into separate CORBA and debugger domains (and spent some time adding bits of functionality to the LLVM project's JIT support, and had to adapt to various evolving JIT interfaces)