Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 04:10
    housel opened #1282
  • Dec 12 14:30

    housel on master

    source-records: Fix read-header… environment: Add an Emacs TAGS … Merge pull request #1281 from h… (compare)

  • Dec 12 14:30
    housel closed #1281
  • Dec 12 13:35

    cgay on master

    Update tests to match simplifie… Remove logging-test-suite-app; … Merge pull request #9 from cgay… (compare)

  • Dec 12 13:35
    cgay closed #9
  • Dec 12 13:35

    cgay on master

    Update to match simplified test… Merge pull request #9 from cgay… (compare)

  • Dec 12 13:35
    cgay closed #9
  • Dec 12 06:08
    housel closed #882
  • Dec 12 06:08
    housel commented #882
  • Dec 12 06:05
    housel opened #1281
  • Dec 12 05:37
    cgay opened #9
  • Dec 12 05:04
    cgay synchronize #9
  • Dec 12 04:40
    cgay opened #9
  • Dec 11 05:07

    cgay on master

    Update for simplified testworks… Merge pull request #7 from cgay… (compare)

  • Dec 11 05:07
    cgay closed #7
  • Dec 11 04:32
    housel commented #914
  • Dec 11 03:38
    housel closed #407
  • Dec 11 03:38
    housel commented #407
  • Dec 11 03:06
    cgay opened #7
  • Dec 10 20:23
    cgay commented #1278
Peter S. Housel
@housel
It doesn’t currently compile
(With the LLVM back-end, anyway, due to passing structs to FFI functions)
Carl Gay
@cgay
Excellent. Then I'm not going to worry about it. :)
Peter S. Housel
@housel
We could disable it from the Makefile for now
Carl Gay
@cgay
ok, I did that locally I can just add it to my PR unless you'd rather do it in a separate one.
Peter S. Housel
@housel
I’ll do it separately I guess
Carl Gay
@cgay
I need to update logging-test-suite and regular-expressions-test-suite, then ready to merge I hope.
Peter S. Housel
@housel
I’ll do a PR later
Peter S. Housel
@housel
It's not perfect, in that to get good coverage you have to load a project with a lot of dependencies (such as dylan-environment) and then do the export
That will write out tags for all of the libraries in the transitive set of dependencies, but won't do other things
There's no easy way to merge TAGS files
Still, it's a big improvement, especially since it's able to find definitions that are wrapped in macro invocations
AmberSaber
@AmberSaber
There are two types in D language, cent and ucent, representing signed and unsigned 128-bit values, respectively, and what scenario does this 128-bit value apply to?
Peter S. Housel
@housel
I don't know much about D, but from the docs it's not clear why they chose the name "cent" or what they intend to use it for
AmberSaber
@AmberSaber
it is a reserved keywords
Peter S. Housel
@housel
Yes, it's reserved as a type name but perhaps it isn't supported yet
AmberSaber
@AmberSaber
yes
thank you
AmberSaber
@AmberSaber
Maybe it's similar to some language of bigint
Carl Gay
@cgay
@housel I could pretty easily cons up a library that imports all other libraries with dylan-tool I suspect.
@housel I think for exception (<source-record-missing>) you want exception (ex :: <source-record-missing>)
Peter S. Housel
@housel
Probably (that part of the code is an expansion of something that was copied from elsewhere)
Carl Gay
@cgay
I think that would be a great place for a warning or lint error. Also in return values, which are often pretty natural to specify with only a type.
And it's nice that in Dylan the <naming-convention> makes it easy to see the intention.
Peter S. Housel
@housel
https://opendylan.org/books/drm/Statement_Macros#block says that the exception clause can either have a variable declaration (name :: type) or just the type expression
Peter S. Housel
@housel
The lint warning would be good for method return specs but this case is a bit different
Carl Gay
@cgay
huh. That's a bit odd, isn't it?
Carl Gay
@cgay
If changing one of them makes sense, to have better uniformity, I'd change the return values to allow either variable-name :: type or just type.
I've just used _ :: type in the past on occasion.
Predicates and <boolean> is probably where it comes up the most.
Peter S. Housel
@housel
C++ lets you catch (T) or catch (T e); they were probably trying to follow suit
Carl Gay
@cgay
I can't seem to spell "directory" tonight. (i.e. in PR description or in code)
Carl Gay
@cgay
argh. I deleted the logging and regex test suite apps too soon. Makefile uses them. I'm thinking I'll go ahead and try to make it use testworks run instead.
Peter S. Housel
@housel
👍
Carl Gay
@cgay
@housel do you find that it's a lot of work keeping up with the changes in LLVM across the major versions? From where I sit it doesn't seem like that's been a big problem for you. Someone who went to the SBCL meet-up said that was a topic of concern for getting SBCL on LLVM.
Peter S. Housel
@housel
It was a big problem in the LLVM 3.5/3.6 time frame, which is why I got behind after 2015
Since then, however, things have been much more stable
Since I'm integrating at the level of bitcode, I'm able to take advantage of the automatic compatibility upgraders in the bitcode reader
Carl Gay
@cgay
I told him maybe it was because you were targeting the bitcode level but had no idea why. Lucky guess.
Peter S. Housel
@housel
Literally nobody else is doing it that way
Seems like a good topic to cover in an ELS paper submission
Carl Gay
@cgay
I thought I'd do a quick tweet about aarch64/linux from the @DylanLanguage account. "Support for aarch64/linux added to Open Dylan: dylan-lang/opendylan#1280" Anything I should add?
Peter S. Housel
@housel
No, that says just about everything
Peter S. Housel
@housel
BTW, in case people haven't noticed this, if you're at the dylan-compiler interactive prompt and you want DFM output, you need to do build -output dfm, rather than just build -output dfm
Carl Gay
@cgay
Learn how to output DFM with this one weird trick...
Carl Gay
@cgay
TFW your octogenarian parent gets on Twitter...
Peter S. Housel
@housel
Perhaps I’m fortunate that my parents don’t have smartphones
dylan-lang/opendylan#1282 should fix the scary-looking (but harmless) code generation error when compiling collections using the LLVM back-end
Carl Gay
@cgay
:thumbsup: