Re: [racket-dev] Questions about the GC code
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 a stock build of Boehm's GC, so we can get out of the business of upgrading and modifying it. So far, it has been easier to upgrade occasionally than to sort that out. Meanwhile, Racket includes a slower and more portable "SGC" for building the conservative-GC variant of Racket. You can enable it with `--enable-sgc` as a flag to `configure`. Probably we should switch to SGC as the default, since RacketCGC is now mainly used just to build normal Racket. At Tue, 15 Jul 2014 04:37:45 +0200, Juan Francisco Cantero Hurtado wrote: > 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 know if the adding of HEURISTIC2 was an error or > really there a good reason to select one or other. > > --- > > There is some recommended benchmark to test the performance of MMAP vs > sbrk? I've tried both with generic code and I don't see the difference. > > --- > > OpenBSD only supports MIPS64. Should I add ELFCLASS64 to the MIPS block > within gcconfig.h? > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Questions about the GC code
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 know if the adding of HEURISTIC2 was an error or really there a good reason to select one or other. --- There is some recommended benchmark to test the performance of MMAP vs sbrk? I've tried both with generic code and I don't see the difference. --- OpenBSD only supports MIPS64. Should I add ELFCLASS64 to the MIPS block within gcconfig.h? _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] FOOL 2014 Call for Papers
Call For Papers 21th International Workshop on Foundations of Object-Oriented Languages (FOOL 2014) A Workshop of SPLASH (OOPSLA) 2014 Portland, Oregon, United States. http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/ Important dates: - August 15, 2014 Abstract submission - August 23, 2014 Full paper submission - September 26, 2014 Notification - October 10, 2014 Paper due for informal proceedings - October 20-24, 2014 Workshop (the day is still to be decided) The search for sound principles for object-oriented languages has given rise to much work during the past two decades, leading to a better understanding of the key concepts of object-oriented languages and to important developments in type theory, semantics, program verification, and program development. Submissions for this event are invited in the general area of foundations of object-oriented languages. Topics of interest include language semantics, type systems, type modifiers, memory models, program verification, object capabilities, formal calculi, concurrent and distributed languages, database languages, and language-based security issues. Papers are welcome to include formal descriptions and proofs, but these are not required; the key consideration is that papers should present novel and valuable ideas or experiences. The main focus in selecting workshop contributions will be the intrinsic interest and timeliness of the work, so authors are encouraged to submit polished descriptions of work in progress as well as papers describing completed projects. We solicit submissions on original research not previously published or currently submitted for publication elsewhere. The program chair should be informed of any related submissions; see the ACM SIGPLAN Republication Policy. Submissions should be PDF in standard SIGPLAN 10pt conference format for a US-letter size page. While submissions can be up to 12 pages, shorter papers describing promising preliminary work are also encouraged. Papers must be submitted electronically via EasyChair. ***NEW: Future of Object-Oriented Foundations session at FOOL 2014*** Over the past 20 years, research presented at FOOL has lead to a more solid understanding of the foundations of today's object-oriented programming languages. At the same time, new object-oriented languages and concepts are constantly being proposed, and there remain core topics that have not yet been fully explored. This year at FOOL 2014, we will hold a special session on the Future of Object-Oriented Foundations (FOOF). For this session, we solicit short papers as well as brief position statements regarding future research in object-oriented foundations: - A short paper will have the same format as regular submissions to FOOL, and will be reviewed in a similar way, but will be limited to 4 pages. - A position statement includes a title, authors, and 2-3 paragraphs of text summarizing the position. These will be lightly evaluated to ensure the position is of interest to the community. Authors of short papers will be given short presentation slots to present them in the FOOF session. One author of each position statement will be invited to participate in an panel related to the position statement's topic. Possible topics include, but are not limited to: brands, tags, and pattern matching; module systems and modularity; protocols, typestate, and sessions; ownership, permissions, and immutability; concurrent and distributed object models; OO logics and reasoning; and gradual/hybrid types and verification. An informal proceedings will be made publicly available on the web page. However, presentation at FOOL does not count as prior publication, and many of the results presented at FOOL have later been published at ECOOP, OOPSLA, POPL, and other main conferences. Program Committee Ferruccio Damiani (University of Turin) Sophia Drossopoulou (Imperial College London) Truong Anh Hoang (Vietnam National University Hanoi) Hidehiko Masuhara (Tokyo Institute of Technology) Rosemary Monahan (National University of Ireland, Maynooth) Alex Potanin (Victoria University of Wellington) Sukyoung Ryu (Korea Advanced Institute of Science and Technology) Marco Servetto (Victoria University of Wellington) Asumu Takikawa (Northeastern University) Thomas Wies (New York Univeristy) Tobias Wrigstad (Uppsala University) Elena Zucca (University of Genova) -- Organizers Marco Servetto (PC Chair) (Victoria University of Wellington) James Noble (Victoria University of Wellington) Jonathan Aldrich (Carnegie Mellon University ) - Steering Committee Jeremy Siek (Indiana University Bloomington) John Boyland (University of Wisconsin-Milwaukee) Atsushi Igarashi (Kyoto University) Shriram Krishnamurthi (Brown University) James Noble (Victoria University of
Re: [racket-dev] [plt] Push #29023: master branch updated
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 additional line in that error message is very
helpful, and it's already a long and scary error message.
Sam
> Let's try this experiment for a while and see what happens.
>
>
>
>
> On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt wrote:
>
>> 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 a simple contract error:
>>
>> -> (require scribble/core)
>> -> (part-parts 7)
>> ; part-parts: contract violation
>> ; expected: part?
>> ; given: 7
>> ; in: the 1st argument of
>> ; (-> part? (listof part?))
>> ; contract from:
>> ; /scribble-lib/scribble/core.rkt
>> ; blaming: top-level
>> ;(assuming the contract is correct)
>> ; at: /scribble-lib/scribble/core.rkt:164.2
>>
>> What does the "assuming the contract is correct" mean to the
>> programmer here? They can't change the contract, and it's not obvious
>> in what sense the contract being incorrect would change anything.
>>
>> In general, I think that your new message makes a lot of sense if
>> programmers mostly experience contracts as strong invariants
>> protecting complex components specified publicly -- the sort of thing
>> you've talked about as a "marketplace of components". But I don't
>> think that's how Racket programmers typically experience contracts --
>> instead, they're more like the example above: simple specifications
>> protecting small functions implemented privately and used as
>> error-checking.
>>
>> Sam
>>
>> On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
>> wrote:
>>> 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
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, 2014 at 9:11 AM, wrote:
> robby has updated `master' from 737330deb6 to 1dda800ca2.
> http://git.racket-lang.org/plt/737330deb6..1dda800ca2
>
> =[ One Commit ]=
> Directory summary:
> 100.0% racket/collects/racket/contract/private/
>
> ~~
>
> 1dda800 Robby Findler 2014-07-14 08:09
> :
> | add contract-correct caveat to contract violation error messages
> :
> M racket/collects/racket/contract/private/blame.rkt | 1 +
>
> =[ Overall Diff ]===
>
> racket/collects/racket/contract/private/blame.rkt
> ~
> --- OLD/racket/collects/racket/contract/private/blame.rkt
> +++ NEW/racket/collects/racket/contract/private/blame.rkt
> @@ -320,6 +320,7 @@
>from-line
>on-line
>blaming-line
> + " (assuming the contract is correct)"
>at-line))
>
> ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
>> _
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
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 wrote:
> 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 a simple contract error:
>
> -> (require scribble/core)
> -> (part-parts 7)
> ; part-parts: contract violation
> ; expected: part?
> ; given: 7
> ; in: the 1st argument of
> ; (-> part? (listof part?))
> ; contract from:
> ; /scribble-lib/scribble/core.rkt
> ; blaming: top-level
> ;(assuming the contract is correct)
> ; at: /scribble-lib/scribble/core.rkt:164.2
>
> What does the "assuming the contract is correct" mean to the
> programmer here? They can't change the contract, and it's not obvious
> in what sense the contract being incorrect would change anything.
>
> In general, I think that your new message makes a lot of sense if
> programmers mostly experience contracts as strong invariants
> protecting complex components specified publicly -- the sort of thing
> you've talked about as a "marketplace of components". But I don't
> think that's how Racket programmers typically experience contracts --
> instead, they're more like the example above: simple specifications
> protecting small functions implemented privately and used as
> error-checking.
>
> Sam
>
> On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
> wrote:
>> 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
>>> 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, 2014 at 9:11 AM, wrote:
robby has updated `master' from 737330deb6 to 1dda800ca2.
http://git.racket-lang.org/plt/737330deb6..1dda800ca2
=[ One Commit ]=
Directory summary:
100.0% racket/collects/racket/contract/private/
~~
1dda800 Robby Findler 2014-07-14 08:09
:
| add contract-correct caveat to contract violation error messages
:
M racket/collects/racket/contract/private/blame.rkt | 1 +
=[ Overall Diff ]===
racket/collects/racket/contract/private/blame.rkt
~
--- OLD/racket/collects/racket/contract/private/blame.rkt
+++ NEW/racket/collects/racket/contract/private/blame.rkt
@@ -320,6 +320,7 @@
from-line
on-line
blaming-line
+ " (assuming the contract is correct)"
at-line))
;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
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 a simple contract error:
-> (require scribble/core)
-> (part-parts 7)
; part-parts: contract violation
; expected: part?
; given: 7
; in: the 1st argument of
; (-> part? (listof part?))
; contract from:
; /scribble-lib/scribble/core.rkt
; blaming: top-level
;(assuming the contract is correct)
; at: /scribble-lib/scribble/core.rkt:164.2
What does the "assuming the contract is correct" mean to the
programmer here? They can't change the contract, and it's not obvious
in what sense the contract being incorrect would change anything.
In general, I think that your new message makes a lot of sense if
programmers mostly experience contracts as strong invariants
protecting complex components specified publicly -- the sort of thing
you've talked about as a "marketplace of components". But I don't
think that's how Racket programmers typically experience contracts --
instead, they're more like the example above: simple specifications
protecting small functions implemented privately and used as
error-checking.
Sam
On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
wrote:
> 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
>> 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, 2014 at 9:11 AM, wrote:
>> > robby has updated `master' from 737330deb6 to 1dda800ca2.
>> > http://git.racket-lang.org/plt/737330deb6..1dda800ca2
>> >
>> > =[ One Commit ]=
>> > Directory summary:
>> > 100.0% racket/collects/racket/contract/private/
>> >
>> > ~~
>> >
>> > 1dda800 Robby Findler 2014-07-14 08:09
>> > :
>> > | add contract-correct caveat to contract violation error messages
>> > :
>> > M racket/collects/racket/contract/private/blame.rkt | 1 +
>> >
>> > =[ Overall Diff ]===
>> >
>> > racket/collects/racket/contract/private/blame.rkt
>> > ~
>> > --- OLD/racket/collects/racket/contract/private/blame.rkt
>> > +++ NEW/racket/collects/racket/contract/private/blame.rkt
>> > @@ -320,6 +320,7 @@
>> > from-line
>> > on-line
>> > blaming-line
>> > + " (assuming the contract is correct)"
>> > at-line))
>> >
>> > ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
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 different because the error message is really saying
only "I detected an inconsistency between the contract and the
program". The messages in previous releases were 100% one-sided. I
lean towards keeping the emphasis on the "code is wrong" side and not
the "contract is wrong" side, since that seems to make more intuitive
sense to people, but I would not mind a change that moves us more
towards an error message that is more balanced (proposals welcome!).
Not even admitting the second possibility seems unwise, however.
Robby
On Mon, Jul 14, 2014 at 8:30 AM, Robby Findler
wrote:
> 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
>> 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, 2014 at 9:11 AM, wrote:
>> > robby has updated `master' from 737330deb6 to 1dda800ca2.
>> > http://git.racket-lang.org/plt/737330deb6..1dda800ca2
>> >
>> > =[ One Commit ]=
>> > Directory summary:
>> > 100.0% racket/collects/racket/contract/private/
>> >
>> > ~~
>> >
>> > 1dda800 Robby Findler 2014-07-14 08:09
>> > :
>> > | add contract-correct caveat to contract violation error messages
>> > :
>> > M racket/collects/racket/contract/private/blame.rkt | 1 +
>> >
>> > =[ Overall Diff ]===
>> >
>> > racket/collects/racket/contract/private/blame.rkt
>> > ~
>> > --- OLD/racket/collects/racket/contract/private/blame.rkt
>> > +++ NEW/racket/collects/racket/contract/private/blame.rkt
>> > @@ -320,6 +320,7 @@
>> > from-line
>> > on-line
>> > blaming-line
>> > + " (assuming the contract is correct)"
>> > at-line))
>> >
>> > ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
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
> 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, 2014 at 9:11 AM, >
> wrote:
> > robby has updated `master' from 737330deb6 to 1dda800ca2.
> > http://git.racket-lang.org/plt/737330deb6..1dda800ca2
> >
> > =[ One Commit ]=
> > Directory summary:
> > 100.0% racket/collects/racket/contract/private/
> >
> > ~~
> >
> > 1dda800 Robby Findler > 2014-07-14
> 08:09
> > :
> > | add contract-correct caveat to contract violation error messages
> > :
> > M racket/collects/racket/contract/private/blame.rkt | 1 +
> >
> > =[ Overall Diff ]===
> >
> > racket/collects/racket/contract/private/blame.rkt
> > ~
> > --- OLD/racket/collects/racket/contract/private/blame.rkt
> > +++ NEW/racket/collects/racket/contract/private/blame.rkt
> > @@ -320,6 +320,7 @@
> > from-line
> > on-line
> > blaming-line
> > + " (assuming the contract is correct)"
> > at-line))
> >
> > ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
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, 2014 at 9:11 AM, wrote:
> robby has updated `master' from 737330deb6 to 1dda800ca2.
> http://git.racket-lang.org/plt/737330deb6..1dda800ca2
>
> =[ One Commit ]=
> Directory summary:
> 100.0% racket/collects/racket/contract/private/
>
> ~~
>
> 1dda800 Robby Findler 2014-07-14 08:09
> :
> | add contract-correct caveat to contract violation error messages
> :
> M racket/collects/racket/contract/private/blame.rkt | 1 +
>
> =[ Overall Diff ]===
>
> racket/collects/racket/contract/private/blame.rkt
> ~
> --- OLD/racket/collects/racket/contract/private/blame.rkt
> +++ NEW/racket/collects/racket/contract/private/blame.rkt
> @@ -320,6 +320,7 @@
> from-line
> on-line
> blaming-line
> + " (assuming the contract is correct)"
> at-line))
>
> ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
_
Racket Developers list:
http://lists.racket-lang.org/dev
