Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 29 18:52
    cgay opened #1355
  • Nov 29 01:08
    cgay opened #38
  • Nov 29 00:55
    cgay opened #37
  • Nov 28 16:45
    cgay commented #1325
  • Nov 28 14:20

    cgay on master

    common-dylan: integer-to-string… io: %x formatter outputs lowerc… Add release note for format(%x) and 4 more (compare)

  • Nov 28 14:20
    cgay closed #1353
  • Nov 28 14:20
    cgay closed #1054
  • Nov 28 14:19
    cgay edited #1353
  • Nov 28 14:17
    cgay opened #1354
  • Nov 28 03:45

    cgay on master

    Show the compiler version durin… Make dylan-compiler -help outpu… Merge pull request #1351 from c… (compare)

  • Nov 28 03:45
    cgay closed #1351
  • Nov 28 03:44
    cgay edited #973
  • Nov 28 02:55
    cgay commented #23
  • Nov 28 02:39
    cgay commented #23
  • Nov 28 02:26

    cgay on master

    Add a link to the dylan domain … (compare)

  • Nov 27 23:40
    cgay opened #23
  • Nov 27 20:28
    cgay commented #1352
  • Nov 27 17:46
    housel commented #1352
  • Nov 27 15:10
    pedro-w commented #1353
  • Nov 27 14:43
    cgay commented #1353
Carl Gay
@cgay
@housel any objection to print-out and print-err? Maybe the playground is too niche of an application? I guess in a real REPL they're not strictly necessary.
I can always provide a one-off definition in the playground.
Peter S. Housel
@housel
print-err is probably overkill, but print-out seems okay
Peter S. Housel
@housel
I don’t have lldb available on RISC-V, so if I want to debug the problem I’m having I’ll need to adapt object inspection for gdb scripting
Carl Gay
@cgay
Sigh, we're now over #x100 bug reports.
Carl Gay
@cgay
In the playground generic-function-methods(\^) doesn't return any of the methods defined in the transcendentals module , even though it works to call them. This looks non-DRM-conforming to me, since the choices are to return all methods or signal an error. Could there be something else going on?
Peter S. Housel
@housel
That’s interesting; generic-function-methods gets called in the course of regular method dispatch, so it’s not clear what would be different
Carl Gay
@cgay
Another one: log(0.0) infinite loops on x86_64-linux llvm back end. Not getting SIGFPE I guess but...i'm off to bed.
There are a few bugs about signal handlers but looks like for C back-end.
g'night
Peter S. Housel
@housel
Anything in the LLVM run-time is my fault
‘night
Carl Gay
@cgay
@pedro-w I enjoy that hand-slapping-face emoji :)
Peter Hull
@pedro-w
I just can't understand how I looked through all the commits in that PR and didn't see you'd already written the tests. Face-palm was my only possible reaction!
Also I see you're on a bit of a streak with the bug fixes, great stuff!
Carl Gay
@cgay
Sometimes doing the small, relatively easy bugs is all I can handle.
Feels good when we close a few. :)
cgay @cgay wonders why skip-multi-line-comment wasn't done as part of the lexer state machine...
Carl Gay
@cgay
I haven't looked closely yet, but maybe because we drop comments on the floor instead of making a comment fragment.
(As usual, speaking before thinking....)
Peter S. Housel
@housel
For log(0.0), it looks like the sequence is: (1) Trigger SIGFPE (2) emulate a call to float-divide-by-0 (3) in the process of calling error, try to save the vector registers onto an unaligned stack (4) signal SIGSEGV (5) Fail to properly handle SIGSEGV and end up signaling it again
(On FreeBSD it's not necessary to try handling SIGSEGV because it's only on Linux that integer divide-by-0 inexplicably turns into a segmentation fault)
Carl Gay
@cgay
@housel do you know the difference between all the inlining adjectives off-hand? dylan-lang/dylan-mode#37
Carl Gay
@cgay
yep, sorry
did it again
Peter S. Housel
@housel
Some of those are aspirational rather than descriptive of the current implementation
Carl Gay
@cgay
lol
Peter S. Housel
@housel
I have a fix for the segfault problem, but trying to catch the <division-by-zero-error> fails to unwind
Peter S. Housel
@housel
(and the backtrace goes astray if you don’t attempt to catch)
Carl Gay
@cgay
glad it was a useful test :)
(wouldn't've tried it without the playground, probably)
it also uncovered that my code to kill long-running playground code isn't working, so don't try it in the playground :)
Carl Gay
@cgay
This definitely can't be right. My lexer changes passed on the first try (after first watching the tests fail).
Peter S. Housel
@housel
It happens
Carl Gay
@cgay
No, it's definitely broken. I'll have to figure out why the tests pass (tomorrow).
Carl Gay
@cgay
Today I want to work on dylan-mode a bit.
Carl Gay
@cgay
We don't actually want tabs in between words, like define<tab>function<tab>foo, so any objection if I remove support for that from dylan-mode?
(It just simplifies regular expressions a bit.)
Peter S. Housel
@housel
You don't want to use [:blank:] ?
Or \s-?
Carl Gay
@cgay
I would prefer to explicitly not support tabs. If you want them then I can use one of those.
Peter S. Housel
@housel
I certainly don’t want them, I just don’t think of it as the editor’s job per se to prevent them by acting weird in some contexts
Carl Gay
@cgay
I have no problem with supporting tabs at the beginning of a line, should a Dylan user community that likes that develop. :)
Peter S. Housel
@housel
Ideally iut would be better to have a lint tool that complained about it explicitly rather than an editor that silently broke
Carl Gay
@cgay
I was thinking of it as negative feedback. "hey my code stopped highlighting correctly. what am i doing wrong?" But I suppose you're right. I'll just leave the \ts in there
Peter S. Housel
@housel
makefile-mode turns ordinary leading spaces hot pink, maybe we could adopt something similar for tabs
Peter S. Housel
@housel
(and I mean literally hot pink, "hotpink" is there in the face declaration)
Carl Gay
@cgay
SGTM. I've also seen that (well, red) for end-of-line whitespace.
Peter S. Housel
@housel
Yes, I have that turned on globally