[racket-dev] RacketCon: Final Call for Presentations
Calling All Racketeers! This is the third announcement of RacketCon: 23 24 July 2011 http://con.racket-lang.org/ We will continue accepting presentation proposals for RacketCon through *this weekend*. We hope to have a preliminary schedule out soon thereafter. To obtain a slot on the program, please send a title and a brief abstract on what you would like to present to the organizers at: racketcon at racket-lang.org Specify how much time you would like for your presentation (anything as short as 5 minutes and as long as 30 minutes works). We will try to accommodate as many presentations as possible. The meeting will take place at Northeastern University in Boston, MA. It will be an opportunity for developers, researchers, and educators using Racket, DrRacket, Program By Design, and related technologies to come together to share plans, ideas, and enthusiasm. To make it accessible, we will not charge any registration fees; we'll also serve you breakfast and lunch. RacketCon will feature presentations by key members of the development team, including Matthew Flatt on the future of Racket and Matthias Felleisen on the Program By Design curriculum. Most importantly, though, we also want it to feature you. We are interested in presentations of any length on using Racket in industrial software development, academic research, or education -- as well as anything that we haven't thought of. All sorts of presentations are welcome, from extended tutorials to short demos to experience reports. Be creative! Additional information can be found on the web page: http://con.racket-lang.org -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
On Wed, Jun 22, 2011 at 6:53 PM, Robby Findler ro...@eecs.northwestern.edu wrote: To really know what is going on, one has to trace thru the re-provides for each of these identifiers and match them up to the declare-exporting declarations. In the declaration below, you're essentially saying any identifiers documented in this module should appear to come from the typed/scheme/base, typed/scheme, and typed-scheme modules, but they are really actually exported from one of the modules listed in the #:use-sources keyword which means, to the documentation system that any module that re-exports an identifier from, say, typed-scheme/base-env/base-types-extra, will have its documentation attached to the docs in the file with the declare-exporting below and the docs system will then point userse to typed/scheme/base. I don't think that this is what you want, since you probably want to to point people to typed/racket. That's not what's going on here, although you couldn't tell that from my email. That `declare-exporting' is in a subsection which only documents `typed/scheme' etc, and not any of the actual forms in Typed Racket. To know what the right answer is for the declare-exporting below, I'd have to know how typed/racket fits into the picture. In particular, is it re-exporting things from typed/scheme? Or from those helper modules you have listed? Or from some other place? It's probably easier to just consider `typed/racket/base' and `typed/scheme/base' here. Both of them export identifiers from the modules listed in the `declare-exporting' declaration. For example, `with-handlers' is defined in `typed-scheme/base-env/prims'. Here's what the documentation for `typed/racket/base' looks like: @(defmodulelang* (typed/racket/base typed/racket) #:use-sources (typed-scheme/typed-scheme typed-scheme/base-env/prims typed-scheme/base-env/extra-procs typed-scheme/base-env/base-types typed-scheme/base-env/base-types-extra)) Also, I don't think this is a problem with the general setup of documentation for Typed Racket. In particular, the identifier `define-type' is defined in the same module as `with-handlers', and it gets handled properly by Scribble, by DrRacket, and by `check-docs'. You can see this by searching for `define-type' in the documentation, or for `U', which is defined in the same module as `-'. Instead, I think the problem is that `with-handlers' and `-' are both identifiers exported from `racket', and this is causing some sort of confusion in the Scribble doc system, but I don't know exactly what, and I'm therefore confused about how to try to fix it. Of course, it might be something totally different, also -- the vagaries of Scribble linking are still opaque to me. Robby On Thu, Jun 23, 2011 at 3:16 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Currently, the documentation completeness checker (a wonderful tool; thanks, Robby!) for Typed Racket complains that `-' and `with-handlers' are not documented when provided from `typed/scheme', `typed/scheme/base', and `typed-scheme'. However, these identifiers are fine when provided from `typed/racket', and are both defined in modules where `check-docs' finds the documentation for other things just fine, such as `define:' and `All'. The documentation looks like this: (declare-exporting typed/scheme/base typed/scheme typed-scheme #:use-sources (typed-scheme/typed-scheme typed-scheme/base-env/prims typed-scheme/base-env/extra-procs typed-scheme/base-env/base-types typed-scheme/base-env/base-types-extra)) where `-' is defined in `typed-scheme/base-env/base-types-extra' and `with-handlers' is defined in `typed-scheme/base-env/prims'. Is there something else I should be doing here? Is there a bug in `check-docs'? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
On Jun 23, 2011 6:17 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Is the with-handlers that typed/racket exports the same identifier as the one exported by racket, or is it a different binding? 'with-handlers' in 'typed/racket' is a different binding. Basically, it just adds some annotations to help the type checker. Robby On Fri, Jun 24, 2011 at 2:46 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Jun 22, 2011 at 6:53 PM, Robby Findler ro...@eecs.northwestern.edu wrote: To really know what is going on, one has to trace thru the re-provides for each of these identifiers and match them up to the declare-exporting declarations. In the declaration below, you're essentially saying any identifiers documented in this module should appear to come from the typed/scheme/base, typed/scheme, and typed-scheme modules, but they are really actually exported from one of the modules listed in the #:use-sources keyword which means, to the documentation system that any module that re-exports an identifier from, say, typed-scheme/base-env/base-types-extra, will have its documentation attached to the docs in the file with the declare-exporting below and the docs system will then point userse to typed/scheme/base. I don't think that this is what you want, since you probably want to to point people to typed/racket. That's not what's going on here, although you couldn't tell that from my email. That `declare-exporting' is in a subsection which only documents `typed/scheme' etc, and not any of the actual forms in Typed Racket. To know what the right answer is for the declare-exporting below, I'd have to know how typed/racket fits into the picture. In particular, is it re-exporting things from typed/scheme? Or from those helper modules you have listed? Or from some other place? It's probably easier to just consider `typed/racket/base' and `typed/scheme/base' here. Both of them export identifiers from the modules listed in the `declare-exporting' declaration. For example, `with-handlers' is defined in `typed-scheme/base-env/prims'. Here's what the documentation for `typed/racket/base' looks like: @(defmodulelang* (typed/racket/base typed/racket) #:use-sources (typed-scheme/typed-scheme typed-scheme/base-env/prims typed-scheme/base-env/extra-procs typed-scheme/base-env/base-types typed-scheme/base-env/base-types-extra)) Also, I don't think this is a problem with the general setup of documentation for Typed Racket. In particular, the identifier `define-type' is defined in the same module as `with-handlers', and it gets handled properly by Scribble, by DrRacket, and by `check-docs'. You can see this by searching for `define-type' in the documentation, or for `U', which is defined in the same module as `-'. Instead, I think the problem is that `with-handlers' and `-' are both identifiers exported from `racket', and this is causing some sort of confusion in the Scribble doc system, but I don't know exactly what, and I'm therefore confused about how to try to fix it. Of course, it might be something totally different, also -- the vagaries of Scribble linking are still opaque to me. Robby On Thu, Jun 23, 2011 at 3:16 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Currently, the documentation completeness checker (a wonderful tool; thanks, Robby!) for Typed Racket complains that `-' and `with-handlers' are not documented when provided from `typed/scheme', `typed/scheme/base', and `typed-scheme'. However, these identifiers are fine when provided from `typed/racket', and are both defined in modules where `check-docs' finds the documentation for other things just fine, such as `define:' and `All'. The documentation looks like this: (declare-exporting typed/scheme/base typed/scheme typed-scheme #:use-sources (typed-scheme/typed-scheme typed-scheme/base-env/prims typed-scheme/base-env/extra-procs typed-scheme/base-env/base-types typed-scheme/base-env/base-types-extra)) where `-' is defined in `typed-scheme/base-env/base-types-extra' and `with-handlers' is defined in `typed-scheme/base-env/prims'. Is there something else I should be doing here? Is there a bug in `check-docs'? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
On Jun 23, 2011 6:39 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I think I'd need to actually look at the code next. I didn't seem to find it, tho; can you give me a pointer? It should be in 'collects/typed-scheme/scribblings/ts-reference.scrbl' for typed/racket and 'collects/typed-scheme/scribblings/reference/compatibility.scrbl' for typed/scheme. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
On Thu, Jun 23, 2011 at 9:19 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
On Fri, Jun 24, 2011 at 8:58 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Jun 23, 2011 6:39 PM, Robby Findler ro...@eecs.northwestern.edu
wrote:
I think I'd need to actually look at the code next. I didn't seem to
find it, tho; can you give me a pointer?
It should be in 'collects/typed-scheme/scribblings/ts-reference.scrbl' for
typed/racket and
'collects/typed-scheme/scribblings/reference/compatibility.scrbl' for
typed/scheme.
I don't see any docs for with-handlers in there:
[robby@gaoping] ~/git/exp/plt/collects/typed-scheme/scribblings$ find
. -name \*scrbl -exec grep -H with-handlers {} \;
[robby@gaoping] ~/git/exp/plt/collects/typed-scheme/scribblings$
Perhaps the confusion is this?: scribble only associates documentation
with actual bindings (well, when you have re-exporting and use
#:with-sources the situation is more complex, but what I'm writing in
this sentence is the right way to think of it as a baseline and then
other things are exceptions) so because the typed/racket with-handlers
binding is a different binding, it needs different @defwhatever.
And, as further rationale for that (something that has been said
before, but I forget if it was said here or not), macros can tell the
difference so documenting the bindings separately, even if all the
docs say is behaves like X [with link], is the right thing.
Or are there actually docs that I still just didn't find?
I think your copy of the tree must be out of date; you can see the
docs for `with-handlers' in git head here:
https://github.com/plt/racket/blob/master/collects/typed-scheme/scribblings/reference/special-forms.scrbl#L387
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
On Thu, Jun 23, 2011 at 9:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: So I think the fix is to do the renaming for with-handlers before it gets exported from typed-scheme/base-env/prims (or introduce another module and put that one in the #:use-sources and use it as the one where the re-providing is happening). Ok, I did this, and it worked nicely. Thanks! Unfortunately, the issue with `-' seems to be different. In particular, `-' in `typed/scheme' and in `typed/racket' are both defined in typed-scheme/base-env/base-types-extra.rkt, under the name `-', and it isn't renamed in between. Other identifiers, such as `U', are defined in the same place, and treated identically, but the docs for `U' work just fine. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
What's wrong is that for typed/scheme check-docs thinks that - is undocumented, even though it's able to find the docs for the same identifier provided from typed/racket. It's the same problem as with with-handlers, but if appears not to have the same cause. On Jun 24, 2011 8:53 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not seeing something wrong. Maybe it would help if you could make a smaller example. Robby On Sat, Jun 25, 2011 at 8:15 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Jun 23, 2011 at 9:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: So I think the fix is to do the renaming for with-handlers before it gets exported from typed-scheme/base-env/prims (or introduce another module and put that one in the #:use-sources and use it as the one where the re-providing is happening). Ok, I did this, and it worked nicely. Thanks! Unfortunately, the issue with `-' seems to be different. In particular, `-' in `typed/scheme' and in `typed/racket' are both defined in typed-scheme/base-env/base-types-extra.rkt, under the name `-', and it isn't renamed in between. Other identifiers, such as `U', are defined in the same place, and treated identically, but the docs for `U' work just fine. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
Ah, I see. Well, that makes two of us. I'll try to make a small example collection. On Fri, Jun 24, 2011 at 9:46 PM, Robby Findler ro...@eecs.northwestern.edu wrote: What I meant is that I don't see what is wrong with your code, not that I don't see check-docs complaining. On Sat, Jun 25, 2011 at 9:14 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: What's wrong is that for typed/scheme check-docs thinks that - is undocumented, even though it's able to find the docs for the same identifier provided from typed/racket. It's the same problem as with with-handlers, but if appears not to have the same cause. On Jun 24, 2011 8:53 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not seeing something wrong. Maybe it would help if you could make a smaller example. Robby On Sat, Jun 25, 2011 at 8:15 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Jun 23, 2011 at 9:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: So I think the fix is to do the renaming for with-handlers before it gets exported from typed-scheme/base-env/prims (or introduce another module and put that one in the #:use-sources and use it as the one where the re-providing is happening). Ok, I did this, and it worked nicely. Thanks! Unfortunately, the issue with `-' seems to be different. In particular, `-' in `typed/scheme' and in `typed/racket' are both defined in typed-scheme/base-env/base-types-extra.rkt, under the name `-', and it isn't renamed in between. Other identifiers, such as `U', are defined in the same place, and treated identically, but the docs for `U' work just fine. -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Strange problem with `check-docs' and `#:use-sources'
I'll try to make a small example collection.
Ok, I've narrowed the bug down. It's something with the use of
`defform*'. Attached is a patch that creates a `ts' collection. If
you apply it, and then do the following:
% raco setup ts
% cd collects/ts
% racket test-docs-complete.rkt
ts/scheme has undocumented exports:
(x1)
You see the problem. The relevant use of `defform*' is:
@defform*[#:id x1 [(qqq x1)]]
Basically any change to this removes the bug, for example, moving the
`qqq' *after* `x1' causes the bug to go away.
What should I run that's lower-level than `check-docs' to see if the
problem is there?
--
sam th
sa...@ccs.neu.edu
From 81b873954b0529decdddb23eb54ec2098d2a7f74 Mon Sep 17 00:00:00 2001
From: Sam Tobin-Hochstadt sa...@racket-lang.org
Date: Sun, 26 Jun 2011 10:01:39 -0400
Subject: [PATCH] demo bug
---
collects/ts/b.rkt |5 +
collects/ts/doc.scrbl |8
collects/ts/info.rkt |2 ++
collects/ts/racket.rkt |3 +++
collects/ts/scheme.rkt |3 +++
collects/ts/test-docs-complete.rkt |4
6 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 collects/ts/b.rkt
create mode 100644 collects/ts/doc.scrbl
create mode 100644 collects/ts/info.rkt
create mode 100644 collects/ts/racket.rkt
create mode 100644 collects/ts/scheme.rkt
create mode 100644 collects/ts/test-docs-complete.rkt
diff --git a/collects/ts/b.rkt b/collects/ts/b.rkt
new file mode 100644
index 000..1d8da33
--- /dev/null
+++ b/collects/ts/b.rkt
@@ -0,0 +1,5 @@
+#lang racket/base
+(require (for-syntax racket/base))
+(define-syntax x1 #f)
+(define-syntax x2 #f)
+(provide (all-defined-out))
diff --git a/collects/ts/doc.scrbl b/collects/ts/doc.scrbl
new file mode 100644
index 000..0fecc26
--- /dev/null
+++ b/collects/ts/doc.scrbl
@@ -0,0 +1,8 @@
+#lang scribble/manual
+@(require (for-label ts/racket))
+@title{T}
+@(defmodulelang* (ts/racket) #:use-sources (ts/b))
+@defform*[#:id x1 [(qqq x1)]]
+@defform[(x2)]
+@section{S}
+@(defmodulelang* (ts/scheme) #:use-sources (ts/b))
diff --git a/collects/ts/info.rkt b/collects/ts/info.rkt
new file mode 100644
index 000..870d7a1
--- /dev/null
+++ b/collects/ts/info.rkt
@@ -0,0 +1,2 @@
+#lang setup/infotab
+(define scribblings '((doc.scrbl () (language
diff --git a/collects/ts/racket.rkt b/collects/ts/racket.rkt
new file mode 100644
index 000..e46bf95
--- /dev/null
+++ b/collects/ts/racket.rkt
@@ -0,0 +1,3 @@
+#lang racket
+(require ts/b)
+(provide (all-from-out ts/b))
diff --git a/collects/ts/scheme.rkt b/collects/ts/scheme.rkt
new file mode 100644
index 000..e46bf95
--- /dev/null
+++ b/collects/ts/scheme.rkt
@@ -0,0 +1,3 @@
+#lang racket
+(require ts/b)
+(provide (all-from-out ts/b))
diff --git a/collects/ts/test-docs-complete.rkt b/collects/ts/test-docs-complete.rkt
new file mode 100644
index 000..97fd52c
--- /dev/null
+++ b/collects/ts/test-docs-complete.rkt
@@ -0,0 +1,4 @@
+#lang racket/base
+(require rackunit/docs-complete)
+(check-docs (quote ts/scheme))
+(check-docs (quote ts/racket))
--
1.7.4.1
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Getting github to recognize .scrbl files
On Mon, Jun 27, 2011 at 4:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jun 27, 2011, at 4:42 PM, Eli Barzilay wrote: []s hightlighted in red... But that's a general scheme issue now too. No [] in Scheme proper :-) Not true, see: http://docs.racket-lang.org/r6rs-std/r6rs-Z-H-7.html#node_sec_4.3 -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] getting symbol documentation URL quickly within Emacs
On Tue, Jun 28, 2011 at 9:58 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jun 28, 2011, at 9:55 AM, Eli Barzilay wrote: (2) things from libraries can be excluded from specific languages because we know they won't run That won't work right too... Should I list a whole bunch of modules for my language? What happens when one of these modules becomes compatible when I or the module's author change something? So you're working in #lang racket as a naive Racket beginner, and you find some r6rs library that uses set-car!. Hey what a great idea! That enables me to do all the things I dutifully learned in a data structure course on linked lists. So I require it and it fails ... Yes I think we should be able to specify the list of 'good' xor 'bad' libraries, whichever is shorter. This should work fine: #lang racket (require my-r6rs-lib) (my-r6-fun (mlist 1 2 3)) I can't think of any non-trivial language with `require' where you can divide libraries sensibly into good and bad. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] okay to require rackunit in modules required at startup?
On Wed, Jun 29, 2011 at 8:10 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Wed, Jun 29, 2011 at 7:40 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Jun 29, 2011 at 2:52 AM, Eli Barzilay e...@barzilay.org wrote: [*] As an example, rackunit might become dependent on drr in the future, if it becomes a drr plugin. The cost of that is obvious: you need drr to use rackunit. A possible solution to that, if it becomes necessary, is to have another package for the plugin, one that depends on rackunit and drr. This is already the case for rackunit. There's a drracket tool for rackunit gui integration. I don't know the full story on the dependencies, but drracket plugins do not make direct links; they are discovered as drracket starts up and, if not present, nothing bad happens (unless two plugins need each other to be present, which is possible and happens in the current tree). Right, I was trying to say that Rackunit has already gone in the good direction that Eli pointed out wrt. DrRacket integration. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax taints instead of syntax certificates
On Wed, Jun 29, 2011 at 9:19 PM, Matthew Flatt mfl...@cs.utah.edu wrote: * If you write program-processing tools or languages that use `syntax-recertify', you'll need to change them to use `syntax-disarm' and possibly `syntax-rearm'. Does this change (more generally than the part I've quoted here) mean that code that uses `syntax-recertify' and related functions will no longer compile and/or work in new versions of Racket? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] documentation reorganization
On Fri, Jul 1, 2011 at 9:41 PM, Ryan Culpepper r...@cs.utah.edu wrote: re misc: Do you mean Other? Would you prefer Other Languages and Libraries or Other Manuals? I think those should just go under Experimental Languages, since they're both languages, and at least one is experimental. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OK, how do I fix this DrDr complaint?
On Mon, Jul 4, 2011 at 8:36 PM, Stephen Bloch sbl...@adelphi.edu wrote: As of this evening's DrDr build, test-docs-complete is complaining of a gazillion undocumented exports from picturing-programs. In fact, these identifiers are all required from 2htdp/image and re-exported from picturing-programs, so I didn't bother re-documenting them. How do I tell test-docs-complete where they're documented? The answer is to use `declare-exporting'. You'd write something like this in the documentation for `picturing-programs': (declare-exporting picturing-programs #:use-sources (2htdp/image)) Unfortunately, because of the way `declare-exporting' works, this might not be entirely correct. You need to name the file that the various exports of `2htdp/image' are *defined* in, not just where they're exported. But the line above is the general direction you want to go in. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] RacketCon -- July 23 24 -- Second Call for Participation
Calling All Racketeers! Join us at RacketCon, 23 24 July 2011. http://con.racket-lang.org/ The schedule for RacketCon is now available, and includes presentations by key members of the Racket team, including Matthew Flatt on the future of Racket and Matthias Felleisen on the Program By Design curriculum, as well as tutorials on building web applications and accessing low-level libraries. The meeting will take place at Northeastern University in Boston, MA. It will be an opportunity for developers, researchers, and educators using Racket, DrRacket, Program By Design, and related technologies to come together to share plans, ideas, and enthusiasm. To make it accessible, we will not charge any registration fees; we'll also serve you breakfast and lunch. We're excited about RacketCon and hope you'll join us there. To register for RacketCon, please send an email with your name and affiliation to racket...@racket-lang.org . Additional information, including registration, transportation and hotel information, can be found on the web page: http://con.racket-lang.org Sam Tobin-Hochstadt _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
Why not `interactive'? And this is for the name of the module, right? On Sun, Jul 10, 2011 at 6:55 AM, Eli Barzilay e...@barzilay.org wrote: I'm close to adding my interactive hack to the tree (in a much improved form). Does anyone have a good idea for a name? (I started with `repl', looked too generic so I switched to `replcommand', but that looks too verbose.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
I agree -- this is not going to be something people write often; it goes into your .racketrc. There's no reason to have a short and confusing name. On Sun, Jul 10, 2011 at 12:40 PM, Jon Rafkind rafk...@cs.utah.edu wrote: command-repl +1 crepl -1 On 07/10/2011 09:54 AM, Eli Barzilay wrote: It's no longer mine, and it's really been years since it was really a hack. I think that I'll go with a shortened command-repl: `crepl'. On 2011-07-10, Matthias Felleisen matth...@ccs.neu.edu wrote: how about ElisInteractiveHack On Jul 10, 2011, at 8:39 AM, Eli Barzilay wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: Why not `interactive'? Interactive what? -- It's way too generic. And this is for the name of the module, right? A new toplevel collection. Used similarly to readline. (And supersedes it, hopefully, for casual users.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
On Tue, Jul 12, 2011 at 9:00 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jul 12, 2011, at 3:15 AM, Neil Van Dyke wrote: Yes! Name your favorite brand and I'll bring it... I don't know a good beer to name, but I'm sure that the Bukowski Tavern near us has some sufficiently pricey imported craft ones. :) Ask them for an Isreali import. And btw, Eli will order Coke. Or: http://www.shmaltz.com/HEBREW/index.html -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23009: master branch updated
On Wed, Jul 13, 2011 at 12:08 PM, stamo...@racket-lang.org wrote: ;; we assume indexes are 2 bits shorter than fixnums ;; We're generating a reference to fixnum? rather than calling it, so ;; we're safe from fixnum size issues on different platforms. -(define (index? x) (and (fixnum? x) (= x 0) (fixnum? (* x 4 +(define (index? x) + (and (fixnum? x) (unsafe-fx= x 0) (fixnum? (unsafe-fx* x 4 How is this possibly ok? If `x' is (/ MAX_FIXNUM 2), then this code has no semantics. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] for/vector much slower than vector-set! ?
On Mon, Jul 18, 2011 at 6:01 PM, John Clements cleme...@brinckerhoff.org wrote: Does the first one somehow have to check some things that the second one doesn't? Yes, how long the vector is going to be. Try: (for/vector #:length (* 100 sr) ([i (in-range (* 100 sr))]) 0.243) which is just as a fast as the `vector-set!' code on my machine. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] RacketCon -- July 23 24 -- Room Change Final Call for Participation
Calling All Racketeers! Join us at RacketCon, 23 24 July 2011. http://con.racket-lang.org/ NOTE: To accommodate all the people who want to attend, the room hosting RacketCon has been changed; please see the web page for details. The schedule for RacketCon is now available, and includes presentations by key members of the Racket team, including Matthew Flatt on the future of Racket and Matthias Felleisen on the Program By Design curriculum, as well as tutorials on building web applications and accessing low-level libraries. The meeting will take place at Northeastern University in Boston, MA. It will be an opportunity for developers, researchers, and educators using Racket, DrRacket, Program By Design, and related technologies to come together to share plans, ideas, and enthusiasm. To make it accessible, we will not charge any registration fees; we'll also serve you breakfast and lunch. We're excited about RacketCon and hope you'll join us there. To register for RacketCon, please send an email with your name and affiliation to racket...@racket-lang.org . Additional information, including registration, transportation and hotel information, can be found on the web page: http://con.racket-lang.org Sam Tobin-Hochstadt _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 12:21 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 2011-07-26 1:20 PM, Jay McCarthy wrote: I don't have a lot of expertise on the ORM side, but I think Snooze would probably be awesome and my MongoDB-backed structs may be helpful too. Is there a way of generically traversing all structure in a completely privileged way in Racket, without programming at the VM level? For example, one might wish to serialize some arbitrary data structure or write an object inspector or interactive debugger. If you have a sufficiently powerful inspector, you can traverse any structure. In principle, you can even traverse closures this way, but no inspector with the needed power exists. See `struct-vector'. I'm guessing no is the answer, based on the existence of separate serializable and non-serializable structure definitions. I guess that if I were to try it out I'd be defeated by opaque closures and by the inspector mechanism. Does that sound right? Regards, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote: No such alchemy exists, it's just intended as part of the conceptual framework. Would it be fair to say that were such a thing to come into existence, the VM would need to be changed as part of that work? Yes. No, `struct-vector' uses the chaperoned accessors, but doesn't represent their structure. OK. And there's nothing else that can expose that structure? Right. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Jul 28, 2011 7:26 AM, Noel Welsh noelwe...@gmail.com wrote: On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: Would it be fair to say that were such a thing to come into existence, the VM would need to be changed as part of that work? There is nothing you can't do with a brave heart and a disassembler. In other words, I've occasionally thought it would be fun to write a generic object inspector via abuse of the FFI. Certainly. That's how the disassembler I wrote works. It's not a stable solution, but it is effective. sam th _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23142: master branch updated
On Fri, Jul 29, 2011 at 6:59 PM, rafk...@racket-lang.org wrote: +(define-lex-abbrev block-comment (:: /* + (complement (:: any-string */ any-string)) + */)) Can we please not make the same mistake that C made of having comments not nest? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Mon, Aug 1, 2011 at 11:48 AM, Eli Barzilay e...@barzilay.org wrote: * Simplified error messages in student languages, and use colors to add visual information (see the teachpack manual for guidelines on writing teachpacks). (Is this the right place? IIRC it moved.) I don't believe the colors are implemented in the tree yet. * Sam, Vincent: TR news? (Many new types from Eric Dobson? Optimizer logs?) Almost all core Racket data structures and operations now work with Typed Racket (most of this work is due to prolific contributor Eric Dobson). -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Mon, Aug 1, 2011 at 1:10 PM, Eli Barzilay e...@barzilay.org wrote: About a minute ago, Vincent St-Amour wrote: - Typed Racket now optimizes at the REPL and inside typed regions. This sounds too uninteresting for most users. Have we run out of space for release notes? This certainly isn't as important as places, but I think we should err on the side of more rather than less in the release notes. - Typed Racket now provides a command-line static performance debugging tool. It is? In any case, I'd prefer announcing it when the whole thing is ready, ... Typed Racket does, in the release, provide exactly that. Should it not be announced because it will get better in the future? A DrRacket-based graphical version will be available in the next release. ... and avoid pre-announcements for future features. The reason that we wanted to include this is that Vincent demo'd this feature at RacketCon; the sentence clarifies for anyone who saw or heard about this when it will be available, and that it isn't the version of the feature provided in 5.1.2. Unrelated to TR: - A high-level interface to Racket's logging facilities is now available in `unstable/logging'. So far there were no announcements about anything in `unstable', and I like to keep it out of the very public announcements. (Unrelated to posting about it privately as a process to consider moving things out.) This is something that lots of people have asked for, and feedback from them on the interface would be useful while it's still in development. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Mon, Aug 1, 2011 at 1:52 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Monday, August 1, 2011, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Aug 1, 2011 at 1:10 PM, Eli Barzilay e...@barzilay.org wrote: About a minute ago, Vincent St-Amour wrote: - Typed Racket now optimizes at the REPL and inside typed regions. This sounds too uninteresting for most users. Have we run out of space for release notes? This certainly isn't as important as places, but I think we should err on the side of more rather than less in the release notes. This doesn't make any sense to me so I expect people who read release notes will be even more confused. Then we should clarify. Does the following help? The Typed Racket optimizer now applies to typed programs entered at the REPL and inside of typed regions created by `with-type', not just to modules written in the `typed/*' family of languages. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Mon, Aug 1, 2011 at 2:50 PM, Eli Barzilay e...@barzilay.org wrote: `with-type' sounds too specific to be broadly applicable. `with-type' allows embedding typed regions inside arbitrary other blocks of untyped code -- it's certainly generally applicable. (And BTW, there *is* limited space for release notes -- otherwise these discussions would never happen.) There's certainly limited space for the most prominent elements of the release notes. But I think the right solution there is to pick some small number of items (say, 5) that are most significant, and highlight them. Then much more can be included below that, and finally some information about minor changes (fixed bugs, for example). The git release notes are an example of this style: http://kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] racket doesn't work with Mac OSX 10.7 (Lion)?
On Mon, Aug 1, 2011 at 12:43 PM, Joseph Maline joe.mal...@me.com wrote: I've downloaded Racket, copied the directory into applications, and try and run and get the following crash report … Any users having similar problem? Anyone from dev have any thoughts (note, I've tried this 4 times …) Please try the pre-release version (for the soon-to-be-released next version), which works on Lion: http://pre.plt-scheme.org/release/installers/ -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Tue, Aug 2, 2011 at 6:14 AM, Eli Barzilay e...@barzilay.org wrote: -- * The download page includes 64-bit installers for Mac OS X, Windows, and two Debian flavors. We should emphasize OS X Lion support here. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
No, the issue is that 5.1.1 doesn't work at all on Lion, and we should emphasize that the new release does work. On Aug 2, 2011 10:01 AM, Eli Barzilay e...@barzilay.org wrote: An hour ago, Sam Tobin-Hochstadt wrote: On Tue, Aug 2, 2011 at 6:14 AM, Eli Barzilay e...@barzilay.org wrote: -- * The download page includes 64-bit installers for Mac OS X, Windows, and two Debian flavors. We should emphasize OS X Lion support here. I'm not sure that it makes any difference that the *installer* was built on Lion. How does this look (added Win7 for the same reason): * The download page includes 64-bit installers for Mac OS X (built on Lion), Windows (built on Windows7), and two Debian flavors. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
[switch to dev] On Thu, Aug 11, 2011 at 12:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote: DrRacket's interactions window has to use `eval' in the sense that it reads an expression to evaluate and then passes it on to the program for an answer. When you run a module in DrRacket, the interactions window treats expressions as being in the language of the module body. Furthermore, since the interactions window works through `eval', it turns out that DrRacket sets `eval' globally to use the module's language while evaluating expressions in the interactions window. In Racket terminology, DrRacket sets the `current-namespace' parameter to the module's namespace when it initializes the interactions window. I think this paragraph (the rest is great!) points to the key problem. The fact that insufficiently-namespaced uses of `eval' work in the interactions window leads people to the wrong conclusion about how things work in general. Also, whereas everything else has a good reason given, this behavior is described with it turns out that and an explanation about the implementation. How problematic would it be if the DrRacket interactions window didn't make the namespace it uses for evaluation available to the expressions being evaluated? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler ro...@eecs.northwestern.edu wrote: How problematic would it be if the DrRacket interactions window didn't make the namespace it uses for evaluation available to the expressions being evaluated? How would that work? Could drracket compile the expression in the namespace that has the insides of the module and then, when evaluating it, set the namespace back to the one in effect while running the definitions window? (That seems a bit strange; I don't have a good idea how it would work.) What I was thinking was more along the lines of disconnecting the value of `current-namespace' that DrRacket sees from the value that the user program sees -- in other words, having that parameter not be part of the underlying shared portion of Racket like `+', but more like the things that DrRacket doesn't share, like its inspector. I think that would require lower-level changes, though. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] pretty-big-#lang (was: External connection toFinndesign Liitin)
On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler ro...@eecs.northwestern.edu wrote: How problematic would it be if the DrRacket interactions window didn't make the namespace it uses for evaluation available to the expressions being evaluated? How would that work? Could drracket compile the expression in the namespace that has the insides of the module and then, when evaluating it, set the namespace back to the one in effect while running the definitions window? (That seems a bit strange; I don't have a good idea how it would work.) What I was thinking was more along the lines of disconnecting the value of `current-namespace' that DrRacket sees from the value that the user program sees -- in other words, having that parameter not be part of the underlying shared portion of Racket like `+', but more like the things that DrRacket doesn't share, like its inspector. I think that would require lower-level changes, though. Well, lower-level is not a complete magic wand here :). I think there would have to be some way to understand what you expect the lower-level to be doing and then, after that, figure out what level that fits best at. Yes, I agree. Like having two versions of current-namespace: I think what you're saying is that drracket should do something like this: (parameterize ([current-namespace repl-namespace-with-all-the-goodies]) (eval `(parameterize ([current-namespace ,the-actual-likely-empty-users-namespace]) ,users-program))) maybe? Yeah, that seems like a nice and simple way of doing it. Another way would be: (parameterize ([current-eval (let ([old (current-eval)] [ns (current-namespace)]) (lambda (e) (parameterize ([current-namespace ns]) (old e]) (eval users-program repl-namespace/goodies)) Which is basically just a version of the two-argument `eval' that doesn't do the parameterization. The lower-level change is, it seems, not needed, since this is already easily expressible. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Sam _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Aug 13, 2011 2:13 PM, Eli Barzilay e...@barzilay.org wrote: Two minutes ago, Sam Tobin-Hochstadt wrote: On Aug 13, 2011 1:35 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Sat, Aug 13, 2011 at 1:26 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Aug 13, 2011, at 12:58 PM, Sam Tobin-Hochstadt wrote: On Sat, Aug 13, 2011 at 12:51 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Sam Tobin-Hochstadt wrote: `match' also currently adds a syntax property to help the Typed Racket type checker understand the expansion. Like 'disappeared-use for Check Syntax, this property is in theory semantically independent of Typed Racket, but only used there. No, when your property is called `typechecker:called-in-tail-position' it is not independent of a typecheker. It will be, if it gets a generic name, and gets documented which turns it from a backdoor for a backward dependency to a known API. The *semantic* independence of the property and the typechecker implementation is not determined either by the name of the property or the documentation. There are two levels of semantics here: -- operational semantics of your module, which makes you correct -- 'in spirit' semantics, which makes Eli correct. I will say that even though I cannot define 'in spirit' formally, I am with Eli here. How about instead of in spirit, we focus on program logic. There is no semantic dependence on the typechecker -- Racket can tell what the program does without it. However, programmers cannot read that code and know what it is for and whether it is correct without reference to the typechecker. That's a meaningful dependency. It makes maintaining that line of code 100% dependent on the typechecker. +1. What I mean by semantically independent I mean exactly that your statement is not correct. The meaning of the property is defined without reference to the type checker. To rephrase what Carl said: what if you change the TR type chekcer to a type verifier? You'd change the property name, which means that a TR change has lead to a change in match. That's the actual dependency. It means this let-bound function is probably called in tail position wrt the let.. This says nothing about types, and can be reasoned about independently. Exactly -- having typechecker: in the name is bogus. Would you mind changing it to `swindle:called-in-tail-position'? Is this just an argument about how to name these syntax properties? If so, I'm happy with whatever you think I should name it. That doesn't seem to get us anywhere on the other questions, though. Sam _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] spam bug reports
On Sat, Aug 13, 2011 at 4:26 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Well, someone has figured out how to defeat the recaptcha thingy and I'm now getting about (on average, ish) two spam bug reports per hour for the last several days (and a slower, but still annoying rate for several weeks before that). Any advice? (poking around the web suggests that captchas are basically useless nowadays anyways). If it's spam that's inserting links, you might try rewriting the HTML in bugs to use rel=nofollow on all outbound links [1]. But sadly probably the only solution is requiring logins, either through us or through someone else who validates that people are real. [1] http://en.wikipedia.org/wiki/Nofollow -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)
On Tue, Aug 16, 2011 at 5:31 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks. We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling. Aren't syntax properties precisely this abstraction? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] syntax property duplication
The following idiom duplicates the syntax properties on `stx': (define-syntax (m stx) (datum-syntax #'here 'id stx stx)) This is a problem for me because I use syntax properties to indicate polymorphic type instantiation. If an expression that's actually a macro using this idiom is instatiated, then Typed Racket tries to do the type instantiation twice, resulting in an error. See the below program, which fails. Should I expect that duplicate syntax properties are a natural result of expansion, and find some way to handle them? Or is there something else that should happen? #lang typed/racket (: id : (All (A) (A - A))) (define (id x) x) (define-syntax (m stx) (datum-syntax #'here 'id stx stx)) (inst m Integer) -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax property duplication
On Thu, Aug 18, 2011 at 8:14 AM, Carl Eastlund c...@ccs.neu.edu wrote: On Wed, Aug 17, 2011 at 6:25 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The following idiom duplicates the syntax properties on `stx': (define-syntax (m stx) (datum-syntax #'here 'id stx stx)) This is a problem for me because I use syntax properties to indicate polymorphic type instantiation. If an expression that's actually a macro using this idiom is instatiated, then Typed Racket tries to do the type instantiation twice, resulting in an error. See the below program, which fails. Should I expect that duplicate syntax properties are a natural result of expansion, and find some way to handle them? Or is there something else that should happen? #lang typed/racket (: id : (All (A) (A - A))) (define (id x) x) (define-syntax (m stx) (datum-syntax #'here 'id stx stx)) (inst m Integer) Merging syntax properties -- duplicating in this case, since the macro's input and output have the same properties -- are a natural result of expansion, as you say. See the third paragraph in the reference on syntax properties: Yes, I understand why this happens. As I see it, there are a few possibilities: 1. The expander should check for duplicates, in some fashion. 2. This idiom is problematic, in the case where `stx' is both the input and used for the syntax properties of the output. 3. Macros may freely duplicate syntax properties. All of these have drawbacks, but (3), which you are suggesting, means either that syntax properties can only be used to specify idempotent information or that the non-idempotent ones need to have some *explicit* means by which equal elements can be distinguished, which must be part of the API of that syntax property. If we think this is how syntax properties ought to work, then we should add something to the documentation making this clear, and we should recognize that it's a limitation. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23306: master branch updated
On Fri, Aug 19, 2011 at 9:55 PM, mfl...@racket-lang.org wrote: | Is there a better name than `path-piece?'? `path-component?' -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Bite-Size Racket Projects
It's clear that there are lots of people who are interested in hacking with Racket, or improving Racket, but don't know where to start. In response, some of us have put together a list of bite-size Racket projects, which are good places for learning Racket, contributing, and just having fun programming. The list is here: https://github.com/plt/racket/wiki/Intro-Projects It's a wiki, so feel free to add projects, let people know that you're working something, or provide more info on that page. Ask questions about any of the projects on this list, on the #racket IRC channel, or by sky-writing, -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Warnings in source code
On Fri, Aug 26, 2011 at 12:21 PM, Paulo J. Matos pa...@matos-sorge.com wrote: Hi, I was just looking at the warnings in racket source code after Sam posted the bite size projects threads with the link to the wiki. I can't access http://drdr.racket-lang.org/ (the page just doesn't load) So, I cloned racket, configured it and did a make. I only get two warning on the whole build: gcc -I./.. -I../../../racket/src/racket/gc2/../include -g -O2 -pthread -Wall -c xsrc/place.c -o place.o ../../../racket/src/racket/gc2/../src/place.c: In function ‘place_async_send’: ../../../racket/src/racket/gc2/../src/place.c:2450:14: warning: operation on ‘ch-in’ may be undefined ../../../racket/src/racket/gc2/../src/place.c: In function ‘scheme_place_async_try_receive’: ../../../racket/src/racket/gc2/../src/place.c:2589:17: warning: operation on ‘ch-out’ may be undefined This is with GCC4.5. Great. It might be helpful to try building with clang as well, as it gives very helpful warning/error messages. The next step is to figure out how to patch that file to remove the warning. I will try later GCC4.6 though but I am amazed GCC4.5 only shows two warnings. Well, it's definitely a good sign but I was wondering if I overlooked something. I don't think so -- the default configuration builds everything. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drRacket Close/Close tab
On Wed, Aug 31, 2011 at 8:13 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Linux, in my File menu the Ctrl-w shortcut is always listed as shortcut for Close, while Close Tab has no shortcut, but I see now that Ctrl-w's behavior is actually to close the current tab. So in this case my suggestion comes down to just relabelling the menu items from: File - Close to File - Close Window I'm going to follow the apple human interface guidelines on this point and leave things as they are: http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html and fixing the moving of the Ctrl+W keybinding in the labels. In this case you should fix the above-mentioned moving, because on Gtk Ctrl+W stays put no matter the number of tabs. The GTK interface guidelines suggest that close (and thus control-w) should close the current document which, to me, means the current tab, not the current window. I find that here: http://developer.gnome.org/hig-book/3.0/hig-book.html#the-file-menu (This is different from Apple's which say that close always closes a window.) I suppose that means that I should change the meaning of the close menu under gtk without changing the label of the menu but I think that's probably slightly more confusing than the status quo (well, when the bug mentioned below gets fixed). I tried 4 different tabbed application on my system (Ubuntu 11.04). Firefox, which doesn't try as hard to follow platform guidelines, doesn't have a close menu entry at all, and Ctrl-w closes the currently-open tab, unless there's only one, and then it closes the window. The other three applications (Pidgin, Epiphany, Gedit) all follow the behavior described in the HIG: there is only a Close menu entry (no Close Tab), it closes the current tab, and its shortcut is Ctrl-w. I think we should follow the platform guidelines here as well, and do the same. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23408: master branch updated
On Thu, Sep 1, 2011 at 3:13 AM, Eli Barzilay e...@barzilay.org wrote: 8 hours ago, Sam Tobin-Hochstadt wrote: On Wed, Aug 31, 2011 at 1:51 PM, Eli Barzilay e...@barzilay.org wrote: An hour ago, sa...@racket-lang.org wrote: +Modified to use `syntax-parse' and multiple macros by Sam +Tobin-Hochstadt, 2011. AFAICT, you're not using anything that `synatx-rules' can't do, so what's the point? Better error messages, hopefully. Um, but you didn't do that: Indeed, the error messages could be improved in lots of ways -- I just took the reference implementation and improved it in the most obvious ways. I had hoped that things like the following would get better errors from `syntax-parse' automatically: - (let-values) - (let-values 3 4 5 6) - (let-values (3 . 4) 3 4 5) But they didn't, unfortunately. I don't know if Ryan will change that ever. If there was something between `syntax-parser' and `define-simple-macro', that would be the right tool here. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23424: master branch updated
On Sat, Sep 3, 2011 at 5:37 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 3 Sep 2011 17:25:58 -0400, Sam Tobin-Hochstadt wrote: On Thu, Sep 1, 2011 at 5:20 PM, t...@racket-lang.org wrote: src/racket/src/place.c ~~ + REGISTER_SO(quote_symbol); + quote_symbol = scheme_intern_symbol(quote); This is the third definition of 'quote_symbol' in the source. Are repeated definitions a problem? It doesn't seem like a problem to me. What did you have in mind? I was just generically worried about duplicated code. Looking more deeply, it seems the only potential problem is one more (very small) GC root, and root traversal surely isn't the current GC bottleneck. Can these be shared (other than via the intern table)? A `scheme_quote_symbol' could be defined somewhere and exported to the other places. The tradeoff is writing `(define QUOTE 'quote)' multiple times versus making a global change. Make sense. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] New runtime charting for DrDr
DrDr now has colorful, up-to-date, interactive charts for runtime on every file. For example, check out: http://drdr.racket-lang.org/23468/collects/tests/racket/benchmarks/common/ray.rkt The quick explanation: the solid yellow line shows the overall runtime of the file. The circles show the timing of uses of `time' inside the file. You can select any region of the chart to zoom into it. The reset button goes back to the initial state. You can turn the legend on and off with the show/hide legend button. Mousing over an individual point will tell you the exact timing at a particular push #. If the internal timing is much much shorter-duration than the overall runtime, it's shown on a different scale on the right y-axis. This is all built on the Flot [1] JavaScript charting library. Using this, it's possible to see trends in performance. For example, I want your feedback about this. Is it readable? Should I add the gc/system time for uses of `time'? Should I switch from points to lines? Is there anything else you'd like? [1] http://code.google.com/p/flot/ -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax property duplication
On Tue, Sep 6, 2011 at 8:05 PM, John Clements cleme...@brinckerhoff.org wrote: On Aug 18, 2011, at 5:32 AM, Sam Tobin-Hochstadt wrote: Yes, I understand why this happens. As I see it, there are a few possibilities: 1. The expander should check for duplicates, in some fashion. 2. This idiom is problematic, in the case where `stx' is both the input and used for the syntax properties of the output. 3. Macros may freely duplicate syntax properties. All of these have drawbacks, but (3), which you are suggesting, means either that syntax properties can only be used to specify idempotent information or that the non-idempotent ones need to have some *explicit* means by which equal elements can be distinguished, which must be part of the API of that syntax property. If we think this is how syntax properties ought to work, then we should add something to the documentation making this clear, and we should recognize that it's a limitation. Would syntax-property guards solve this problem? I don't really see how. What are you thinking of? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
On Wed, Sep 7, 2011 at 2:52 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Wed, Sep 7, 2011 at 9:24 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Now, when you click on a point, the tooltip stays in place (until you click again). This makes it easy to click on the link now in the tooltip, which goes to the file at the selected push #. Ah, thanks. I missed that there was a link in the tooltip. But why not make clicking on the point actually just go to that revision? Sorry, that wasn't clear. The link in the tooltip is new too. I don't want to make just clicking the point jump; that seems like it would make zooming perilous. Also, a less important one, but since you're taking feature requests :), would it be possible to have a mode where you can see the separate lines individually, so that wildly different values that are in two different timing tests don't pollute the scale? That is, it would be nice if I could click something and see only one of the lines of cpu times by itself (I wouldn't want this to be the default tho). I'll probably add something where you can turn off individual data sets. Would that do what you want? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
On Wed, Sep 7, 2011 at 3:40 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Also, a less important one, but since you're taking feature requests :), would it be possible to have a mode where you can see the separate lines individually, so that wildly different values that are in two different timing tests don't pollute the scale? That is, it would be nice if I could click something and see only one of the lines of cpu times by itself (I wouldn't want this to be the default tho). I'll probably add something where you can turn off individual data sets. Would that do what you want? Yes, thanks (it would re-scale, right?). Now (or rather, once Jay updates the version running on the DrDr machine), you can click the individual entries in the legend to turn them on or off. The legend entries will be printed in italics when not displayed, and it will automatically re-scale. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
On Wed, Sep 7, 2011 at 8:46 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks. Is it possible to make it remember the setting? Specifically, when go from this page: http://drdr.racket-lang.org/23400/collects/tests/drracket/memory-log.rkt to this one: http://drdr.racket-lang.org/23400/ to see what the commit was, and then I go back, I lose the settings. I'll see what I can do. I just use tabs as a workaround, though. Also, can you make clicking on the little boxes in teh legend do the same thing as clicking the words? I wanted to do that, but I haven't figured out how yet. The library gives me a lot of control over the labels, but not over the boxes. On Wed, Sep 7, 2011 at 5:39 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Sep 7, 2011 at 3:40 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Also, a less important one, but since you're taking feature requests :), would it be possible to have a mode where you can see the separate lines individually, so that wildly different values that are in two different timing tests don't pollute the scale? That is, it would be nice if I could click something and see only one of the lines of cpu times by itself (I wouldn't want this to be the default tho). I'll probably add something where you can turn off individual data sets. Would that do what you want? Yes, thanks (it would re-scale, right?). Now (or rather, once Jay updates the version running on the DrDr machine), you can click the individual entries in the legend to turn them on or off. The legend entries will be printed in italics when not displayed, and it will automatically re-scale. -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
On Wed, Sep 7, 2011 at 8:59 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: n Wed, Sep 7, 2011 at 8:46 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks. Is it possible to make it remember the setting? Specifically, when go from this page: http://drdr.racket-lang.org/23400/collects/tests/drracket/memory-log.rkt to this one: http://drdr.racket-lang.org/23400/ to see what the commit was, and then I go back, I lose the settings. I'll see what I can do. I just use tabs as a workaround, though. Once Jay updates DrDr, this should work for the zoom level. Let me know if it doesn't. It won't remember which series are hidden, though. If you want that too, I can probably implement it pretty easily. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
This should be up soon. On Thu, Sep 8, 2011 at 12:43 PM, Robby Findler ro...@eecs.northwestern.edu wrote: The hidden series thing was the one I was asking for. Sorry for the lack of clarity. Robby On Thu, Sep 8, 2011 at 11:34 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Sep 7, 2011 at 8:59 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: n Wed, Sep 7, 2011 at 8:46 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks. Is it possible to make it remember the setting? Specifically, when go from this page: http://drdr.racket-lang.org/23400/collects/tests/drracket/memory-log.rkt to this one: http://drdr.racket-lang.org/23400/ to see what the commit was, and then I go back, I lose the settings. I'll see what I can do. I just use tabs as a workaround, though. Once Jay updates DrDr, this should work for the zoom level. Let me know if it doesn't. It won't remember which series are hidden, though. If you want that too, I can probably implement it pretty easily. -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] build error with gcc 4.5.2
That fixed the problem, thanks. On Mon, Sep 12, 2011 at 11:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think the problem is that I changed xform without adjusting the version number as I should have. A fresh build directory or throwing out build/racket/gc2/xform-collects and build/racket/gc2/xsrc should avoid the problem. [I planned to push a change that adjusts the version number, but I haven't gotten to it.] At Mon, 12 Sep 2011 11:38:37 -0400, Sam Tobin-Hochstadt wrote: I'm currently getting the following compilation error from HEAD: make[4]: Entering directory `/home/samth/sw/plt/src/build/racket/gc2' gcc -I./.. -I../../../racket/gc2/../include -g -O2 -pthread -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -c xsrc/jit.c -o jit.o ../../../racket/gc2/../src/jit.c: In function ‘scheme_get_native_arity’: ../../../racket/gc2/../src/jit.c:3870:5: error: invalid use of flexible array member make[4]: *** [jit.o] Error 1 This is with gcc 4.5.2, Ubuntu 11.04. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket docs and data-driven design
The same is true of HtDP: http://htdp.org/2003-09-26/Book/curriculum-Z-H-13.html#node_chap_9 and HtDP 2e: http://www.ccs.neu.edu/home/matthias/HtDP2e/htdp2e-part2.html . (search for [else in a similar way). On Fri, Sep 16, 2011 at 11:52 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: I introduced templates today. Almost as if on cue, one student asked whether he could use else instead of (cons? l). I told them I was going to make a MORAL judgment about why it was EVIL, and spent ten minutes talking about all that. As class ended, one of my students came up and said, So why doesn't the Racket language Web site agree with you? http://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html (Look for [else.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] heads-up on gcc-clang switch
Apple has already switched to clang, that happened with XCode 4. Previously, they shipped both and old version of GCC (4.2), and a compiler which used the GCC frontend and an LLVM backend. They made this switch because they didn't like the GPL version 3, which recent versions of GCC (and other GNU software) use. There are two different projects for using GCC as a frontend for LLVM, called llvm-gcc and DragonEgg, with the latter being more up-to-date, I believe. There wouldn't be any point in using GCC as a front-end for clang, since clang is just a front-end for LLVM. On Sun, Sep 18, 2011 at 6:28 PM, John Clements cleme...@brinckerhoff.org wrote: FYI: Extracted from an audio mailing list, of possible interest re: Mac compilation; it looks like Apple's switching to clang. In fact, gcc may (already? soon?) be a front end for clang. John Begin forwarded message: From: Kyle Sluder kyle.slu...@gmail.com Date: September 17, 2011 8:58:27 PM PDT To: Paul Davis p...@linuxaudiosystems.com Cc: coreaudio-...@lists.apple.com API coreaudio-...@lists.apple.com Subject: Re: Commandline Tool Chain? ... So while you can invoke clang directly (don't use GCC anymore; it's unsupported) to produce fully functional Mac OS X binaries ... ... _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] repeatable segfault in expander
The below program segfaults the expander, but not the compiler (tested with git HEAD): [samth@punge:~/sw/plt/collects/tests/racket/benchmarks/shootout (master) plt] r Welcome to Racket v5.1.3.9. - (define x '(module m racket (require racket/require) (require (filtered-in (lambda (n) foo) scheme - (compile x) ; reference to an identifier before its definition: foo in module: 'm phase: 1 - (expand x) SIGSEGV MAPERR si_code 1 fault on addr 0x10 Aborted Back trace: (gdb) where #0 0x0012e416 in __kernel_vsyscall () #1 0x001a3e71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x001a734e in abort () at abort.c:92 #3 0x0822ed2d in fault_handler (sn=11, si=0x876726c, ctx=0x87672ec) at ../../../racket/gc2/sighand.c:118 #4 signal handler called #5 scheme_register_unbound_toplevel (env=0xa51fec70, id=0xa5234950) at ../../../racket/gc2/../src/compenv.c:644 #6 0x082501ee in scheme_bind_syntaxes (where=0x8264d87 local syntax definition, names=0xa51fed20, a=0xa5234f68, exp_env=0xa5734220, insp=0xb7250828, rec=0xa75484d0, drec=0, stx_env=0xa51fec70, rhs_env=0xa51fec70, _pos=0xa75484ec, rename_rib=0xa51fe9f0) at ../../../racket/gc2/../src/compile.c:3623 #7 0x0807e7f4 in local_eval (argc=3, argv=0xa88a6ec8) at ../../../racket/gc2/../src/eval.c:5161 #8 0x002f196a in ?? () #9 0x002e1094 in ?? () #10 0x002dfee4 in ?? () #11 0x002ee0a4 in ?? () #12 0x002e15f4 in ?? () #13 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223416, rands=0xa7548a14, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #14 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #15 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #16 0x0809f016 in scheme_apply_macro (name=0xa51fe278, menv=0xa570c3c8, rator=0xa5721688, code=0xa51fe2f8, env=0xa51fded8, boundname=0x82a7644, rec=0xa7548c38, drec=0, for_set=0) at ../../../racket/gc2/../src/fun.c:1796 #17 0x0824a02c in compile_expand_macro_app (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #18 scheme_compile_expand_expr (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #19 0x0824d84e in scheme_expand_expr (form=0xa51fe258, env=0xa51fded8, erec=0xa7548c38, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #20 0x0807d9b6 in expand_k () at ../../../racket/gc2/../src/eval.c:4201 #21 0x0809d858 in scheme_top_level_do_worker (k=0x807d600 expand_k, eb=0, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #22 0x0809da48 in scheme_top_level_do (k=0x807d600 expand_k, eb=0) at ../../../racket/gc2/../src/fun.c:1041 #23 0x08082a4b in do_local_expand (name=0x8264e28 local-expand, for_stx=0, catch_lifts=value optimized out, for_expr=0, argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4766 #24 0x08083379 in local_expand (argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4814 #25 0x002df5f6 in ?? () #26 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223352, rands=0xa7549320, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #27 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #28 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #29 0x0809f016 in scheme_apply_macro (name=0xa51fdd40, menv=0xa570bd58, rator=0xa570c388, code=0xa51fddc0, env=0xa5736238, boundname=0x82a7644, rec=0xa7549668, drec=0, for_set=0) ---Type return to continue, or q return to quit--- at ../../../racket/gc2/../src/fun.c:1796 #30 0x0824a02c in compile_expand_macro_app (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #31 scheme_compile_expand_expr (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #32 0x0824d84e in scheme_expand_expr (form=0xa5756168, env=0xa5736238, erec=0xa7549668, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #33 0x0812fbc0 in do_module_begin_at_phase (form=0xa57361d8, env=0xa57349c0, rec=0xa7549ef4, drec=0, erec=0xa7549ef4, derec=0, phase=0, body_lists=0x82a7f1c, bxs=0xa5736208) at ../../../racket/gc2/../src/module.c:6610 #34 0x08132f7e in do_module_begin (orig_form=0xa5735fd8, env=0xa57349c0, rec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:6264 #35 0x08134536 in module_begin_expand (form=0xa5735fd8, env=0xa57349c0, erec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:7465 #36 0x0824af63 in scheme_compile_expand_expr (form=0xa5735fd8, env=0xa57349c0, rec=0xa7549ef4, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4614 #37 0x0824d84e in scheme_expand_expr (form=0xa5735fd8, env=0xa57349c0,
[racket-dev] error with futures and the compiler
The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu tst.rkt Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] error with futures and the compiler
Here's a rather smaller version, with the same error: #lang racket/base (require racket/future racket/flonum racket/fixnum racket/cmdline) (define N (command-line #:args (n) (string-number n))) (define (M Ci) (let loop ([Zr 0.0]) (fl+ 0. Ci) (loop 0.0))) (for ([y N]) (future (λ () (let loop-x () (fx 0 N) (M 1.1) (loop-x) On Tue, Sep 20, 2011 at 5:36 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Removing the unsafe operations doesn't change the error. On Tue, Sep 20, 2011 at 5:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Are the unsafe operations ever misapplied? Robby On Tue, Sep 20, 2011 at 4:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23578: master branch updated
On Tue, Sep 20, 2011 at 6:13 PM, mfl...@racket-lang.org wrote: | convert C++-style comments to C-style comments | | As far as I know, // isn't a C comment form, although | MSVC and gcc both accept it. // was made a legal comment syntax by C99. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] contract-out
Right now, in the Typed Racket implementation, there's forms like this: (provide-cond-contract [foo foo?]) Option #2 would be something like this: (provide (cond-contract-out enable-contracts? [foo foo?])) and everywhere has to reference the `enable-contracts?' identifier. I'm not convinced that this is that much nicer than rolling your own. On Sun, Sep 25, 2011 at 7:41 PM, J. Ian Johnson i...@ccs.neu.edu wrote: Everyone rolling their own is bad. We want people to contract their code, and they don't want to always pay for the overhead. #2 sounds the best, since that could be again abstracted over by the user, this time with one line instead of the sevel it takes to implement provide-cond-contract. This also has the advantage that the user can have access to any subforms someone else adds later. -Ian - Original Message - From: Sam Tobin-Hochstadt sa...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: Matthew Flatt mfl...@cs.utah.edu, dev@racket-lang.org Sent: Sun, 25 Sep 2011 11:34:39 -0400 (EDT) Subject: Re: [racket-dev] contract-out On Sun, Sep 25, 2011 at 10:55 AM, J. Ian Johnson i...@ccs.neu.edu wrote: Very nice! Is it easy to make a provide form that conditionally provides with contracts, such as Sam's provide-cond-contract in typed-scheme/utils/utils.rkt? The trouble with this is that it's not clear how it should be controlled. There are a few obvious possibilities: 1. There's a global flag for all of Racket which turns contracts on and off. It should be pretty clear that this is a bad idea. 2. There's a form like `(contract-cond-out expr stuff ...)' which uses the contracts in `stuff' IFF `expr' is true. This is easy to implement, but pretty inconvenient to use. 3. Something like the status quo, where everyone defines their own thing, but maybe with some abstraction. 4. A compiler flag. We don't have anything like this, though, currently, and it's not clear how it should work. -Ian - Original Message - From: Matthew Flatt mfl...@cs.utah.edu To: dev@racket-lang.org Sent: Sat, 24 Sep 2011 09:41:17 -0400 (EDT) Subject: [racket-dev] contract-out The `racket/contract' and `racket' modules now provide `contract-out', which is a `provide' form for contracts. Use (provide (contract-out )) instead of (provide/contract ) There's one difference between `(provide (contract-out ))' and `(provide/contract )': contract expressions in contract-out' are implicitly moved to the end of the module, which means that they can refer to variables that are defined later. For example, the following program works as you'd expect: #lang racket (provide (contract-out [mask-of (turtle? . - . color?)]) turtle? color?) (define (turtle? v) (memq v '(Leonardo Michelangelo Donatello Raphael))) (define (color? v) (memq v '(blue orange purple red))) (define (mask-of t) (match t ['Leonardo 'blue] ['Michelangelo 'orange] ['Donatello 'purple] ['Raphael 'red])) The `contract-out' form is implemented as a provide pre-transformer, which is a new kind of `provide' form that is now supported by `racket/provide-transform'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] contract-out
That's the best solution I've come up with, which is basically the abstraction I suggested under #4. sam th On Sunday, September 25, 2011, Carl Eastlund wrote: How about we write a define-toggle-contract-out form, so everyone can define their own without actually implementing their own. Something like so: (define-toggle-contract-out my-contract-out #:disable) ;; comment out keyword to enable (provide (my-contract-out [thing thing/c])) Carl Eastlund On Sun, Sep 25, 2011 at 7:41 PM, J. Ian Johnson i...@ccs.neu.edu wrote: Everyone rolling their own is bad. We want people to contract their code, and they don't want to always pay for the overhead. #2 sounds the best, since that could be again abstracted over by the user, this time with one line instead of the sevel it takes to implement provide-cond-contract. This also has the advantage that the user can have access to any subforms someone else adds later. -Ian - Original Message - From: Sam Tobin-Hochstadt sa...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: Matthew Flatt mfl...@cs.utah.edu, dev@racket-lang.org Sent: Sun, 25 Sep 2011 11:34:39 -0400 (EDT) Subject: Re: [racket-dev] contract-out On Sun, Sep 25, 2011 at 10:55 AM, J. Ian Johnson i...@ccs.neu.edu wrote: Very nice! Is it easy to make a provide form that conditionally provides with contracts, such as Sam's provide-cond-contract in typed-scheme/utils/utils.rkt? The trouble with this is that it's not clear how it should be controlled. There are a few obvious possibilities: 1. There's a global flag for all of Racket which turns contracts on and off. It should be pretty clear that this is a bad idea. 2. There's a form like `(contract-cond-out expr stuff ...)' which uses the contracts in `stuff' IFF `expr' is true. This is easy to implement, but pretty inconvenient to use. 3. Something like the status quo, where everyone defines their own thing, but maybe with some abstraction. 4. A compiler flag. We don't have anything like this, though, currently, and it's not clear how it should work. -Ian - Original Message - From: Matthew Flatt mfl...@cs.utah.edu To: dev@racket-lang.org Sent: Sat, 24 Sep 2011 09:41:17 -0400 (EDT) Subject: [racket-dev] contract-out The `racket/contract' and `racket' modules now provide `contract-out', which is a `provide' form for contracts. Use (provide (contract-out )) instead of (provide/contract ) There's one difference between `(provide (contract-out ))' and `(provide/contract )': contract expressions in contract-out' are implicitly moved to the end of the module, which means that they can refer to variables that are defined later. For example, the following program works as you'd expect: #lang racket (provide (contract-out [mask-of (turtle? . - . color?)]) turtle? color?) (define (turtle? v) (memq v '(Leonardo Michelangelo Donatello Raphael))) (define (color? v) (memq v '(blue orange purple red))) (define (mask-of t) (match t ['Leonardo 'blue] ['Michelangelo 'orange] ['Donatello 'purple] ['Raphael 'red])) The `contract-out' form is implemented as a provide pre-transformer, which is a new kind of `provide' form that is now supported by `racket/provide-transform'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] contract-out
On Sun, Sep 25, 2011 at 8:14 PM, Eli Barzilay e...@barzilay.org wrote: IMO, a better approach for disabling contracts is to have the client decide whether it wants the contracted version or the plain one -- which is a rough mirror of how unsafe operations are done (with the choice being made by requiring one file or another). Then, there could be a facility that associates a safe identifier with an unsafe version, so you could write (unsafe foo) -- which will be the unsafe operation for builtins that have one, and in case of a contracted function it will be the uncontracted one. This wouldn't work for the Typed Racket use case, where I want to flip one switch for contracts throughout the TR code base. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] weirdness with racket or typed racket module requiring startup time?
On Sun, Sep 25, 2011 at 9:24 PM, Danny Yoo d...@cs.wpi.edu wrote: [snip TR taking a long time to load] Is that something that's supposed to happen? I guess I'm just trying to understand the repercussions of requiring a module from Typed Racket into regular Racket. This looks a little worse than I expected, but in general, modules in Typed Racket incur some startup time overhead. Right now, this is inherent in the architecture of how Typed Racket modules communicate with each other, and the semantics of `require' in Racket. The plan is that adding facets or sub-modules will allow this time to be reduced or eliminated, but right now you can't avoid it. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] contract-out
On Sun, Sep 25, 2011 at 9:36 PM, Eli Barzilay e...@barzilay.org wrote: An hour and a half ago, Sam Tobin-Hochstadt wrote: On Sun, Sep 25, 2011 at 8:14 PM, Eli Barzilay e...@barzilay.org wrote: IMO, a better approach for disabling contracts is to have the client decide whether it wants the contracted version or the plain one -- which is a rough mirror of how unsafe operations are done (with the choice being made by requiring one file or another). Then, there could be a facility that associates a safe identifier with an unsafe version, so you could write (unsafe foo) -- which will be the unsafe operation for builtins that have one, and in case of a contracted function it will be the uncontracted one. This wouldn't work for the Typed Racket use case, where I want to flip one switch for contracts throughout the TR code base. (define-for-syntax contracts-on? #t) (define-syntax (switch stx) (syntax-case stx () [(_ id) (if contracts-on? #'id #'(unsafe id))])) But now I have to change all the places that use these identifiers. The turn on and off internal contracts and give me unchecked access to this library use cases are genuinely different. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 7:47 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. I agree with Robby. We've gotten a lot better about backwards compatibility, and I don't think the win here is worth breaking that. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 2:15 PM, Eli Barzilay e...@barzilay.org wrote: If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) There's a really really big difference between my old code runs, and the pictures look ever-so-slightly different and I have to edit my code. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] More places questions
On Fri, Sep 30, 2011 at 12:26 AM, John Clements cleme...@brinckerhoff.org wrote: I'm guessing that calling place-channel-put with a descriptor pulls out the associated channel... should the docs indicate this? The docs here: http://pre.racket-lang.org/docs/html/reference/places.html?q=place#%28tech._place._descriptor%29 say that. Also, my tiny experiments suggest that place-channel-put is blocking, is that right? I think that's correct (like with `channel-put'), but the docs don't seem to say. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Gathering GC statistics for Racket programs
With regard to my GC statistics tool, I said the following: On Sat, Oct 1, 2011 at 6:50 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: 2. If you have multiple places, it will do totally the wrong thing. Fixing this will require a little more information from Racket. I implemented the necessary bits in Racket today, but it didn't help. It turns out that the initial value of `(current-logger)' only receives events from the initial place. That means that a program can't set up a log receiver for the whole program, just for one place. It would be nice to have a way to get around this limitation -- either forward on child-place log messages, have the main place log all GC events, or something else. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Wed, Oct 5, 2011 at 5:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Basically, it calls the app function on the second element of the list even though the head of the list has failed to pattern match. This is not a bug. `match' makes no guarantee about the order in which it checks elements of the pattern. If it were to try to support this kind of use case, it would have to specify how many times it would call each function that might be embedded in a match, which requires a detailed semantics of backtracking in the matcher, and lock in a particular implementation. I will clarify the documentation to say that you shouldn't use functions that aren't safe to call 0, 1, or more times, in various orders, inside `match' patterns. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
In Le Fessant and Maranget, ICFP 2001, they have measurements that show a 30% speedup of whole (toy) programs, with a similar but smaller suite of optimizations. Given the extensibility of `match', the performance difference can be made arbitrarily large. For example, Eli's example doesn't call the `one??' function, which could take arbitrarily long (imagine a database query). On Thu, Oct 6, 2011 at 5:56 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Do we have performance measurements that show the importance of such reorderings? Robby On Thursday, October 6, 2011, Neil Toronto neil.toro...@gmail.com wrote: On 10/06/2011 01:20 PM, Eli Barzilay wrote: Just now, Neil Toronto wrote: On 10/06/2011 12:28 PM, Prabhakar Ragde wrote: On 10/6/11 2:12 PM, Eli Barzilay wrote: Sam is talking about building the ASTs *while* matching, which is what Jay was trying to do with uses of `app'. I think that a teaching context is in particular one where such a thing doesn't fit -- it obscures the distinction between the side the sexpr goes into, and the side where an AST comes out. Okay, I see the distinction, and I apologize for not having fully understood Jay's example. I agree that this obscurity is hazardous. I think, though, that I have always assumed left-to-right matching, though I may never have constructed anything that would break if it didn't happen. --PR I think most people expect branching constructs like 'match' to make in-order (left-to-right/depth-first), short-cutting decisions. Additionally, the cases themselves do this. So I think the fact that the patterns don't is very surprising. IIRC, the cases are also reordered to optimize tests -- and that's an even more important optimization: - (define (list?? x) (printf list-checking ~s\n x) (list? x)) - (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) - (match '(1 (2) 3) [(list (? one??) 2 3) 1] [(list _ (? list??) _) 2] [(list (? one??) 20 30) 3]) list-checking (2) 2 and after Jay broke it, you get one-checking 1 list-checking (2) 2 IMO it is perfectly fine to require that stuff used in `match' patterns is side-effect-free, and therefore cachable and reorderable. Well I'll be darned. I suppose this shows just how deeply I hold assumptions about order and shortcutting. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 6:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote: In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? No, definitely not! `match' might test components in whatever order it wants, but the semantics of when a match is found is just top-to-bottom, and `match' always takes the first successful match. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/match is broken
On Thu, Oct 6, 2011 at 6:23 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Oct 6, 2011 at 6:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote: In Eli's example, only the second pattern could match But if we wrote it this way: (define (list?? x) (printf list-checking ~s\n x) (list? x)) (define (one?? x) (printf one-checking ~s\n x) (eq? 1 x)) (match '(1 (2) 3) [(list (? one??) (list 2) 3) 1] [(list _ (? list??) _) 2] [(list (? one??) (list 20) 30) 3]) Are you saying that match is allowed to return 1 or 2 depending on these reorderings and this is in some sense an illegal match expression? No, definitely not! `match' might test components in whatever order it wants, but the semantics of when a match is found is just top-to-bottom, and `match' always takes the first successful match. So in this case, match has to call one?? because all the other components match on the first case? Exactly. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct + match not interacting via a macro
On Sun, Oct 9, 2011 at 8:31 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: What exactly does the struct form of match (in the ASL language) use to identify the structure? The following works fine: I'm not sure if ASL's match is the same as the one in `racket/match', but almost certainly it's using the static struct info bound by to `foo' by `define-struct'. You can see the documentation about that here: http://docs.racket-lang.org/reference/structinfo.html -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct + match not interacting via a macro
On Mon, Oct 10, 2011 at 9:42 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Wait, now I realize I misunderstood Sam's proposal. Doesn't this just make all structs into lists? Like back to the bad old days of 1995? No, that was just an example of how to define the `make-foo', `foo-x', etc functions. More sensible definitions should work too. The runtime meaning of the functions should be irrelevant. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. sam th On Oct 20, 2011 9:17 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: I also believe that we don't support these programs well as it is. I didn't program with closures until I experienced them in Scheme 84 in 1984. Perhaps people haven't programmed in syntax REPLs because there aren't any. But then again, perhaps people see no need. I do start seeing a need and I am surprised why we haven't thought of this before. Or someone has and I can't recall -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 9:29 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. I don't understand your unless. Just to be clear, I am imagining two different REPLs. One REPL you get when you click Run. One REPL you get when you click some other button and the second REPL has the compile-time bindings of the program in the definitions window. This sounds very nice, although I don't see why they need to be separate. We could just have a way to switch one repl back and forth (as Eli just suggested), or two tabs in the interaction window, or something else. But I would think one click of Run should be sufficient. For programs that take a while to run, I'd be frustrated having to do that multiple times. The second RPEL may or may not be instantly available depending on whether or not it is (internally) using the results of the online expansion. I guess I don't see why online check syntax is even relevant here. This seems like a case of premature optimization, and one with semantic restrictions. In addition to the issues discussed already, there would be a bunch of things that a REPL hooked up to a separate place couldn't do. For example, syntax snips would be really important at a syntax-time REPL, and they would be tricky if not impossible in the architecture. So would writing out code to a separate file. Eli's argument boil down to saying that there are programs that don't work in online check syntax (and implicitly saying we should support those programs in this new REPL). If you agree with that, then what programs have you written that have this property? I think here's it's important to draw a distinction between two kinds of compile-time I/O. One kind is done whenever a module is visited, eg (begin-for-syntax (printf foo)). This isn't very well handled at the moment in Racket, because how many times that happens is hard to predict. The other kind is I/O done in the course of a particular transcription step, such as `include'. That's quite well supported at the moment by Racket, and something that we shouldn't break. For examples of the second kind, here are a few I've written, used, or wanted to use: - logging to a file during expansion - opening up a macro-debugger window during expansion - Dave Herman's or Jay's C compiler libraries - Felix Klock's FFI generation tools (for Larceny, but a really nice idea that we could use) run the C compiler at expansion time - Invoking an external SAT solver for Typed Racket type checking -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] for/match construct?
Matthew and I talked about this today, and we decided that we should create a parallel set of matchized versions of the `for' macros, rather than my previous experiment which added an `in-match' form that changed the semantics of `for' clause bindings. I've started implementing this; fortunately it doesn't require exposing `define-for-variants'. The one semantic question is about match failure, should that be treated as dropping the element from the sequence, or as a dynamic error. For the parallel, ie non-* variants, I don't think it makes sense. For the nested versions, it would make sense, but I'm unsure about whether it's a good idea. Any thoughts, particularly in the form of use cases, are welcome. On Tue, Oct 25, 2011 at 6:42 AM, J. Ian Johnson i...@ccs.neu.edu wrote: I'm considering putting in some effort to generalize the binding construct in for-clauses so that we can have for[*]/match/X macros. This will require modifying and exposing define-for-variants (due to circularity in requiring match in for). Does anyone object? I'll of course need the code reviewed by those more familiar with for, but I'm hoping I don't need to mess with complicated implementation details such as taints. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] match in Advanced Student?
[switching to dev@] Probably the right way to do this is for me to add a `prop:match-expander' which can be added to arbitrary structure, and then to use that in lang/private/firstorder on the `fo' struct. On Mon, Oct 31, 2011 at 11:41 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I think extending define-primitive the right thing to do... just saying it isn't what I did. On Mon, Oct 31, 2011 at 9:02 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Are you referring to the special case on line 2730 of teach.rkt when you say posns? I think that means that I'd have to make the teaching language depend on 2htdp/image, which doesn't seem right. I would have thought that the right thing would be to extend the define-primitive protocol so that I can declare that 'color' is both a function and a struct constructor and then match would not have to special case 'color'. No? Robby On Mon, Oct 31, 2011 at 9:48 PM, Jay McCarthy jay.mccar...@gmail.com wrote: The HtDP match implementation has a list of such things and goes and finds them to turn them back into the non-primitive bound things. That's why it works with posns. Something better could be done, but for now you could add it to the white list. Jay On Mon, Oct 31, 2011 at 8:45 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Oh, I see why. 'color' is bound using define-primitive in order to cooperate with the beginner language (and so that 'color' can be a constructor). But doing that interferes with the usual information bound by a struct that match picks up. I'm not sure what the right way to resolve this is. Robby On Mon, Oct 31, 2011 at 9:39 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Is make-color coming from 2htdp/image? I see that's not working (not sure why yet). Robby On Mon, Oct 31, 2011 at 9:34 PM, Adam Shaw adams...@cs.uchicago.edu wrote: Thanks! That still doesn't work for color: match: color does not refer to a structure definition although it does work with my own custom color struct: (define-struct clr (r g b)) (match (make-clr 1 2 3) [(struct clr (r g b)) (* r g b)]) - Adam On Oct 31, 2011, at 9:26 PM, Jay McCarthy wrote: One of the branches of the pattern language is | (struct id (pattern ...)) Your pattern should be (struct color (r g b)) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.2
On Wed, Nov 2, 2011 at 11:06 AM, Eli Barzilay e...@barzilay.org wrote: * The new db library offers a high-level, functional interface to popular relational database systems, including PostgreSQL, MySQL, and SQLite, as well as other systems via ODBC. I think this should go first, ahead of XREPL. * Typed Racket: - Typed Racket provides static performance debugging support to show which code gets optimized and point out code that does not. Use the Performance Report button. add in DrRacket at the end here. - Function definitions with optional arguments now work. Replace with Typed Racket now supports defining function with optional arguments using the same syntax as Racket. * Fixed several GUI problems. This should explicitly mention Ubuntu 11.10/GTK3, and go ahead of most of the others. * DrRacket comes with an experimental, on-line check syntax function. By default, it is turned off. To turn it on, right click on the red circle in the buttom right corner of the DrRacket window. Warning: turning this on makes DrRacket less stable. This belongs in the major items category -- it's certainly more significant than the changes to Typed Racket, for example. * The Algol language implementation is now available as other languages, use `#lang algol60' for Algol code. The as here is confusing. * The `typed-scheme' collection was renamed to `typed-racket'. This doesn't even belong in the release notes -- it has no user-visible impact. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.2, second call
On Wed, Nov 2, 2011 at 5:31 PM, Eli Barzilay e...@barzilay.org wrote: - Typed Racket now supports defining function with optional arguments using the same syntax as Racket. * Fixed several GUI problems, including problems on Ubuntu 11.10 (GTK+ 3) and 64-bit Mac OS X. This should go right after 'raco link'. Any reason? (I've put it near the end since it's not really something that has new functionality like the others in the `raco link' neighborhood.) Just because it's a significant bug fix -- without it, we look pretty bad, and we should alert our users that it's fixed. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] read-line performance problem
On StackOverflow [1], someone reported that Racket's I/O performance on large files was substantially worse than other languages for a simple task. I haven't yet tried it on a similarly large volume of data, but I did see a performance difference relative to Chicken for large but not huge files, and Ryan seems to have gotten similar results. [1] http://stackoverflow.com/questions/7946745/i-o-performance-in-mzscheme -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] REPL broken for #lang racket language?
This just started happening to me as well. On Fri, Nov 4, 2011 at 5:25 PM, John Clements cleme...@brinckerhoff.org wrote: It looks to me like my drracket REPL is unusable. To wit: 1) unset PLTCOLLECTS. 2) move ~/Library/Racket 3) move ~/Library/Preferences/*racket* 4) start drracket 5) Choose Use Language Declared in Source 6) Run 7) In REPL, evaluate 13 ... get this error message: -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] DrRacket autocompletion change
I've just pushed a change that will hopefully make DrRacket's autocompletion more helpful. It now will suggest results based on the same fuzzy search that the documentation search uses. So, if you enter: #lang racket cur-dir and hit Ctrl-/ You'll get a menu with the following choices: current-directory current-load-relative-directory current-target-directory-getter current-target-plt-directory-getter current-write-relative-directory The search method and ranking is still pretty simple. I'm happy to take suggestions on how to improve it, especially if there are particular cases where you don't get the results you'd like. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] struct type properties and field accesses
Many built-in structure type properties (such as `prop:procedure' and `prop:set!-transformer') support providing an integer index into the structure to reference a particular field that should supply the value. This is a very useful pattern, but unfortunately, it's not one that any Racket programs can use. In particular, the procedure calling mechanism and the expander get around the inspector system to implement this behavior. It would be nice if additional structure type properties could do this as well. Here's a suggestion of how it could work. `make-struct-type-property' adds an optional argument which specifies that an integer value is an index into the structure. In that case, the generated property accessor procedure performs the field lookup itself, avoiding the inspector system. Note that this doesn't reduce the power of the inspector system, since the structure type property value could be the struct accessor procedure paired with the index, and then you could write your own struct property accessor procedure that did the dispatch. This is less convenient for both users and definers, and thus it would be nice to build it in. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct type properties and field accesses
On Sun, Nov 13, 2011 at 11:29 PM, Ryan Culpepper r...@cs.utah.edu wrote: On 11/13/2011 09:21 PM, Sam Tobin-Hochstadt wrote: Many built-in structure type properties (such as `prop:procedure' and `prop:set!-transformer') support providing an integer index into the structure to reference a particular field that should supply the value. This is a very useful pattern, but unfortunately, it's not one that any Racket programs can use. In particular, the procedure calling mechanism and the expander get around the inspector system to implement this behavior. It would be nice if additional structure type properties could do this as well. Here's a suggestion of how it could work. `make-struct-type-property' adds an optional argument which specifies that an integer value is an index into the structure. In that case, the generated property accessor procedure performs the field lookup itself, avoiding the inspector system. Note that this doesn't reduce the power of the inspector system, since the structure type property value could be the struct accessor procedure paired with the index, and then you could write your own struct property accessor procedure that did the dispatch. This is less convenient for both users and definers, and thus it would be nice to build it in. I think you can do this yourself already using the guard argument of make-struct-type-property. The guard function gets a list that contains the values that struct-type-info would return for the new structure type if it skipped the immediate current-inspector control check. Ah, that's very nice. Thanks! -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23903: master branch updated
On Wed, Nov 23, 2011 at 1:12 PM, Jay McCarthy j...@racket-lang.org wrote: I'll revert the commit and put a new HTTP library on my list to code and discuss with Eli. I feel like we want to fix the bug that `string-url' and `url-string' don't round-trip properly. Could you store some data in a substructure to enable that while keeping the rest of the url structure the same? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23903: master branch updated
I agree with that, but software and timelines have a way of not working together. :) On Wed, Nov 23, 2011 at 1:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: If the new url stuff were to come out this release, then I wouldn't mind not fixing that one. FWIW. Robby On Wed, Nov 23, 2011 at 12:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Nov 23, 2011 at 1:12 PM, Jay McCarthy j...@racket-lang.org wrote: I'll revert the commit and put a new HTTP library on my list to code and discuss with Eli. I feel like we want to fix the bug that `string-url' and `url-string' don't round-trip properly. Could you store some data in a substructure to enable that while keeping the rest of the url structure the same? -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] regexp-split produces immutable cons when rnrs/base-6 is required
On Fri, Nov 25, 2011 at 8:15 AM, Marijn hk...@gentoo.org wrote: regexp-split produces an immutable cons when rnrs/base-6 is required: `regexp-split' is still being obtained from `racket/base' in this example: $ echo m | racket -e '(require rnrs/base-6) (car (regexp-split + (read-line (current-input-port 'mcar: expects argument of type mutable-pair; given '(m) but but all of these bindings are shadowed by `rnrs/base-6', and so manipulate mutable pairs. $ echo m | racket -e '(require rnrs/base-6) (car (list (read-line (current-input-port' m so apparently regexp-split is the culprit, R6RS doesn't specify regular expressions, so there isn't a custom version of the regular expression functionality that works with R6RS (ie, mutable) lists. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] generating tex with a different component order from Scribble
I'd like to create a language in Scribble from writing papers
according to the `acmsmall' documentclass. Unfortunately, the guide
for this documentclass says, right at the beginning:
Following order is mandatory to generate a correct title page:
\documentclass{acmsmall}
%\acmVolume{V}
%\acmNumber{N}
%\acmArticle{A}
%\acmYear{}
%\acmMonth{0}
\markboth{}{}
\title{}
\author{...
\affil{...}}
\begin{abstract}
...
\end{abstract}
\category{}{}{}
\terms{}
\keywords{}
\acmformat{}
\begin{document}
\begin{bottomstuff}
...
\end{bottomstuff}
\maketitle
which is unfortunately quite different from the order that scribble
generates. What's the easiest way to change this? Do I need to write
a new renderer, replacing the latex renderer?
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] generating tex with a different component order from Scribble
Given that I have an existing paper in Scribble, which I need to get
into this format, which of the following would be
easiest/prettiest/most useful for the future?
- writing a new renderer
- generalizing the existing latex renderer
- hacking prefix.tex (although I don't see how this would work)
On Fri, Nov 25, 2011 at 6:50 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I think you could probably make it work with a replacement
prefix.tex, although it won't be easy or pretty.
At Fri, 25 Nov 2011 17:43:24 -0600, Robby Findler wrote:
Yes, I believe that is not possible without creating a new renderer.
Robby
On Fri, Nov 25, 2011 at 4:49 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
I'd like to create a language in Scribble from writing papers
according to the `acmsmall' documentclass. Unfortunately, the guide
for this documentclass says, right at the beginning:
Following order is mandatory to generate a correct title page:
\documentclass{acmsmall}
%\acmVolume{V}
%\acmNumber{N}
%\acmArticle{A}
%\acmYear{}
%\acmMonth{0}
\markboth{}{}
\title{}
\author{...
\affil{...}}
\begin{abstract}
...
\end{abstract}
\category{}{}{}
\terms{}
\keywords{}
\acmformat{}
\begin{document}
\begin{bottomstuff}
...
\end{bottomstuff}
\maketitle
which is unfortunately quite different from the order that scribble
generates. What's the easiest way to change this? Do I need to write
a new renderer, replacing the latex renderer?
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Does anyone know how to grep backwards through the history of a file, using git? I'd do this: % cd collects/test-engine % git log -p -Senable . where 'enable' might be something else. However, that exact query shows that either you broke the code in commit 1b29fd590b which I find unlikely from the text of the commit, or it was something not found by that query. :( -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23941: master branch updated
You need to set the 'responsible' property using the 'git props' command that Eli has added for your new collection, probably to 'ntoronto'. On Tue, Nov 29, 2011 at 1:22 AM, ntoro...@racket-lang.org wrote: 4012373 Neil Toronto ntoro...@racket-lang.org 2011-11-28 23:01 : | Started icon reorganization | | - SVG icon sources | - Playback-style icons, logos, stop signs, magnifying glasses, etc., in diffuse and shiny styles | - Program to pre-render SVG files (icons/private/svg/render-png.rkt) | - Pre-rendered icons (PNGs in power-of-2 sizes) | - Made `icons' a module, with functions to conveniently load icons and convert to/from picts | - Scribble docs for `icons' | - Used new icons in DrRacket toolbar -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Responding to old bug reports
On Fri, Dec 2, 2011 at 4:39 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Sam Tobin-Hochstadt wrote: In my role as bug czar, I've been trying to work through the backlog of old unexamined bugs. Unfortunately, many of them (a) have very little information and (b) are from a long time ago. A good example is this one: http://bugs.racket-lang.org/query/?cmd=viewpr=9481 There are a few options here: 1. Close old (how old?) bugs that don't have enough information to triage/reproduce. 2. Put them in the feedback state, with a general request for more information. 3. Attempt to guess at what component this belongs to, and assign it that way. 4. Leave it in the current state. I think 3 and 4 are both unacceptable. I'm leaning toward 2. The major drawback of 2 vs 1 is that we accumulate lots of bugs that nothing will ever happen with. The major drawback of 1 is that we're saying to someone who took the time to report a bug we didn't care about this bug at the time, so now we're closing it. I think that a sensible choice would be to combine #1 and #2: decide that PRs that have been in feedback state for a while are retired. It's easy to do this -- here's a query that shows all of these PRs sorted by date of last modification: That's basically what Robby suggested as well, and it seems right to me as well. I also did just close the example bug I gave. http://bugs.racket-lang.org/query/?State=feedback;columns=Category;columns=Synopsis;columns=Last-Modified;sortby=Last-Modified;cmd=submit%20query Looks like there are very few of them and most could be closed. Unfortunately, some of these need to be re-triaged. For example, 6285 is a real bug, and I think is only accidentally in the feedback state. But there aren't that many, so it's ok. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] error using local-expand
On Fri, Dec 9, 2011 at 4:53 PM, Stephen Chang stch...@ccs.neu.edu wrote: Say I have the following program: #lang racket (define-for-syntax (loc-expand stx) (local-expand stx 'expression '())) (define-syntax (my-begin stx) (syntax-case stx () [(_ e ...) (with-syntax ([(x ...) (map loc-expand (syntax-list #'(e ...)))]) #'(begin x ...))])) (define-syntax (my-lambda1 stx) (syntax-case stx () [(_ args body ...) #'(lambda args (my-begin body ...))])) `my-lambda1' does the local expansion after the `lambda' form introduces the bindings from `args' into the environment. (define-syntax (my-lambda2 stx) (syntax-case stx () [(_ args body ...) (with-syntax ([(x ...) (map loc-expand (syntax-list #'(body ...)))]) #'(lambda args (begin x ...)))])) `my-lambda2' does the local expansion before the `lambda' form introduces the bindings from `args' into the environment, meaning that there's no binding yet for any of the arguments. An expression (my-lambda1 (y) (+ y 1)) works fine but (my-lambda2 (y) (+ y 1)) produces the error: expand: unbound identifier in module in: y I can't figure out why this is the case. Anyone know? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
I like the idea too, but I think we should bring more content from other parts of the site to the front page. The Ruby home page [http://www.ruby-lang.org/en/] has most of our participate section on the front page, for example. The Clojure home page [http://clojure.org/] does a nice job with the blog integration. And the node.js download link [http://nodejs.org/] is very well done. On Tue, Dec 20, 2011 at 4:07 AM, Robby Findler ro...@eecs.northwestern.edu wrote: I like the idea, but I think our twitter feed and blog aren't updated enough. Robby On Mon, Dec 19, 2011 at 11:34 PM, Asumu Takikawa as...@ccs.neu.edu wrote: Hi all, Currently, the Racket home page is really nice, but it leaves a significant amount of vertical space unused that could be used to communicate information. How would people feel about adding more content below the fold on the website? To be more concrete about this, here's a mockup I made: http://www.ccs.neu.edu/home/asumu/racket-home/ (should look fine on Firefox, Opera, and Chrome at least) Notably, it contains a twitter feed for @racketlang and entries from the blog. These might help to give the first impression that we're an active community. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
On Tue, Dec 20, 2011 at 8:02 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I do NOT like pages that have text below my laptop screen 'fold'. My eyes do glaze over. And I am off the page quickly. The important questions about this are: 1. Does it affect your attention to the above-the-fold text? 2. Are you more likely to read below-the-fold text than text on another page that you have to click to? Most significantly, we should really really use Noel et al's Myna [http://mynaweb.com/] tool to test this empirically. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
