The "gc" directory is Boehm's GC. We've modified it a little (grep for
"PLTSCHEME"), but we try not to maintain the GC itself, except to
upgrade every once in a while.
See
http://www.hboehm.info/gc/
for the latest version, the mailing list, etc.
I should look again at making Racket work with
I've been reading the code of the files gc/os_dep.c and
gc/include/private/gcconfig.h. I've some questions related to OpenBSD.
---
In the X86_64 config, the file defines STACKBOTTOM and HEURISTIC2
(unused because racket picks STACKBOTTOM). What's the preferred?. I'm
asking because I don't kno
Call For Papers
21th International Workshop on
Foundations of Object-Oriented Languages
(FOOL 2014)
A Workshop of SPLASH (OOPSLA) 2014
Portland, Oregon, United States.
htt
On Mon, Jul 14, 2014 at 10:57 AM, Matthias Felleisen
wrote:
>
> Unfortunately, it is impossible to distinguish the two kinds of
> contracts. Even if we introduced two different linguistic mechanisms,
> we would simply confuse programmers more.
I certainly agree with that.
I just don't think the
Unfortunately, it is impossible to distinguish the two kinds of
contracts. Even if we introduced two different linguistic mechanisms,
we would simply confuse programmers more.
Let's try this experiment for a while and see what happens.
On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt wro
I think the vast majority of contract errors that Racket programmers
see will be from contracts that the particular programmer didn't
write. For example: standard library contracts, or contracts from
packages they install, or contracts generated by Typed Racket, or
other such.
For example, here's
Sorry-- I replied on my phone and too tersely the first time.
What I'm trying to say is that I do not agree that compiler bugs or
ffi bugs that corrupt memory or things along these lines are
analogous. I do agree that those things do not deserve lines in our
contract error messages.
Contracts are
I do not buy this argument: the user didn't write the compiler but they
wrote the contract.
Robby
On Monday, July 14, 2014, Sam Tobin-Hochstadt wrote:
> This seems like a situation where the new error message is potentially
> more confusing, even though it's technically more correct. There are
This seems like a situation where the new error message is potentially
more confusing, even though it's technically more correct. There are
lots of other caveats we could add ("assuming there isn't a compiler
bug", etc) but I think adding them would make Racket harder to use.
Sam
On Mon, Jul 14,
9 matches
Mail list logo
