Re: [racket-dev] local-transformer-expand behavior
At Tue, 25 Jun 2013 01:11:45 -0400, Asumu Takikawa wrote: Hi all, Does anyone know what the behavior of (local-transformer-expand #'(define x 3) 'top-level null) should be? I'm not sure, but I expected something like what `local-expand` would do. Instead, I get an error like this: (define-syntax (m stx) (local-transformer-expand #'(define x 3) 'top-level null)) (m) ; readline-input:14:51: define: not allowed in an expression context ; in: (define x 3) ; [,bt for context] Am I just misuing the function? That error is due to a bug in handling the 'top-level context, and I've pushed a repair. I also tried to wrap the quoted definition with a `let`, but then got errors saying `let-values` is unbound (which seems odd since it's a core form). That's actually the right error. The `let' successfully expands to `let-values' in phase 1. The `let-values' identifier in the expansion has a phase-1 binding, but not a phase-0 binding. When the `let-values' form is returned as the result of expanding `(m)', then it ends up in a phase-0 context, and that triggers the error you. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] engine-kill from racket/engine
I think that has to be a bug, and so a repair would be welcome. At Tue, 25 Jun 2013 01:44:11 -0400, Asumu Takikawa wrote: Hi all, I was trying to write an example for the racket/engine docs and stumbled on a case that seems to cause a deadlock. I'm curious if this is intentional or just accidental behavior. Here's the example: #lang racket (require racket/engine) (define e (engine (lambda (s) (sleep 5 (thread (lambda () (sleep 2) (engine-kill e))) (engine-run never-evt e) This will never terminate. If you comment out the fourth line, it will terminate. If you change `never-evt` to 4000 (or any other event that will become ready), it's also fine. What seems to be going on is that `engine-kill` does actually kill the thread underlying the engine. However, `engine-run` is `sync`ed on (1) the given event (2) the engine being done or (3) an exception being raised. Since `engine-kill` does not trigger any of those, the `sync` is blocked. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Triggered a macro system internal error
Hi all, I accidentally triggered what appears to be an internal error message from the macro expander (to do with syntax taints). Unfortunately, I have no idea how to come up with a narrow test case since it happens due to changing Typed Racket's `struct:` expansion. I've attached a short patch below that shows what's needed to trigger it though. Here's the interaction I get with the patch applied: $ racket -I typed/racket Welcome to Racket v5.3.900.1. - (struct: Foo ([x : Integer])) ; internal error: cannot copy taint armings from tainted source [,bt for ; context] Any ideas on how I can get a better test case? Cheers, Asumu From 4abd6636420c0425b77015ca5a00ecb73230f3c7 Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Tue, 25 Jun 2013 10:03:02 -0400 Subject: [PATCH] Patch that triggers internal taint error --- .../typed-racket-lib/typed-racket/base-env/prims.rkt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt index 548bfe4..d3a8b53 100644 --- a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt +++ b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt @@ -593,7 +593,10 @@ This file defines two sorts of primitives. All of them are provided into any mod nm.old-spec (fs ...) #:maker #,cname #,@mutable?))]) -#'(begin d-s dtsi)))] +(if (eq? (syntax-local-context) 'top-level) +#'(begin (module a typed/racket d-s dtsi) + (eval '(require 'a))) +#'(begin d-s dtsi] ;Copied from racket/private/define-struct -- 1.7.10.4 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] local-transformer-expand behavior
On 2013-06-25 11:02:37 +0200, Matthew Flatt wrote: That error is due to a bug in handling the 'top-level context, and I've pushed a repair. Thanks for the repair and nice explanation! Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] New keyword arguments to `racket/file` procedures
The package reorganization also involved some changes to `racket/file`, which added keyword arguments to, at least, `find-files`, `delete-directory/files`, `copy-directory/files`, and `pathlist-closure`. Unfortunately, none of these arguments are documented. Should they have documentation, or are they purely internal? If the latter, I'd like to provide versions without the arguments for the purpose of Typed Racket, which is sensitive to whether functions have keyword arguments. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] New keyword arguments to `racket/file` procedures
At Tue, 25 Jun 2013 11:57:52 -0400, Sam Tobin-Hochstadt wrote:
The package reorganization also involved some changes to
`racket/file`, which added keyword arguments to, at least,
`find-files`, `delete-directory/files`, `copy-directory/files`, and
`pathlist-closure`. Unfortunately, none of these arguments are
documented. Should they have documentation, or are they purely
internal? If the latter, I'd like to provide versions without the
arguments for the purpose of Typed Racket, which is sensitive to
whether functions have keyword arguments.
They're meant to be public, and they need to be documented.
I must admit that there were so many little changes in the conversion
that I started keeping a list of things to fix the docs instead of
fixing the docs right away. I still haven't really started working
through the list, but I certainly should get it done this week.
For what it's worth, here is my list:
doc redirect-part property
'indirect-link: racketmonname, seclink
'no-depend-on as trigger for direct
info-domain and 'lib-relative
'config-dir for `find-system-path'
removed path-relative-string/setup
installer actions: 3rd argument is `user?'
#:keep-modify-seconds? on copy-directory/files
#:must-exist? on delete-directory/files
'relative? implies framework-dir, dll-dir, config-dir as #f
'exe-name handling: a relative GUI
added 'core-exe-name
pkg install --skip-installed, --catalog
pathlist-closure, find-files, and #:follow-links
tar and links
.startmenu, .extreg, 'install-mode
find-relevant-directories and 'no-user
fix file-stamp-in-collection
find-dir-for-pkg-link and --link-search
pkg-desc can have a path
pkg-install docs wrong: arg is pkg-desc list
html-properties: {install,link}-resource
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] single-collection packages
I had suggested a `multi-collection?' definition in info.rkt to designate a multi-collection package, but I don't like having `single-collection' and `multi-collection?' (e.g., what happens if you define then in a conflicting way?). So, I think it's better to define `collection': * (define collection string) --- a single-collection package whose collection name is string. * (define collection 'multi) --- a multi-collection package. * (define collection 'same-as-pkg) --- a single-collection package whose collection name is the package's name. (I don't think anyone should write this in the long run, since it will be the same as leaving out a `collection' definition.) For now, the default is 'multi for compatibility. The intent is to change the default to 'same-as-pkg after a brief transition period. I'm about to push the change with 'multi as the default, but I'm happy to revise further if there's a better idea soon. If this proposal stands after a day or two, then I'll update my existing packages with `(define collection 'multi)', expect that everyone else does the same, and then flip the default in a week or son. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] single-collection packages
On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Things we could move out of the core
While moving some files around between packages, I realized that there
are a number of things that could be moved out of the core and into
packages. Here's a partial list of things that I think are not needed
at all by the rest of the core:
- racket/sandbox and the rest of the sandbox code
- data/{union-find, interval-map, splay-tree, skip-list, order, gvector, heap}
- srfi/4
- unstable/{options, contract}
- errortrace (once sandbox is removed)
- compatibility/*
- mzlib/{pconvert, class100, serialize, thread, transcr}
- a bunch of other parts of mzlib that are just reprovides
The following are libraries that could be removed with (I believe)
small changes to the rest of the core:
- rackunit
- srfi/13
- mzlib/unit200 (maybe, this might be hard)
- mzlib/kw
If this seems like a good idea to people, I'm happy to go ahead and
start doing the work.
Sam
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] `raco link', links.rktd, pkgs, and config.rktd
Caveat 1: In case you don't use the top-level default `make' target when building from the repo, this change means that you need to run `make pkg-links' when you next update. Caveat 2: Feel free to skip the rest. This message is on the far end of what most of us care about in the package system. I think the changes are unavoidable, though, and I think the mostly get us to a complete and consistent design point for multi-user installations (likely common) and /usr versus /usr/lib conventions (not so much, but I think there is demand for that). When single-collection packages become the default, I don't see much use for `raco link', and instead it will be better for most of us to use `raco pkg install --link'. But I see `raco link' sticking around as an layer that some may want to use or look inside. To bring `raco link' and `raco pkg' more in line with each other, and to generally clean up a mistake (IMO) in `raco link', I've changed the behavior of `raco link -u' to be like `raco pkg ... -u': it installs a link in a user- and version-specific way, instead of in a user-specific but all-version way. Naturally, the `raco link' command now supports `-s'/`--shared', just like `raco pkg'. Links installed with `-u' now go into a links.rktd file that's in the version-labeled directory in the user's add-on directory, instead of in links.rktd (with a version regexp) outside the version-labeled directory. The config.rktd file in etc can now specify a location for the installation-wide links.rktd file and pkgs installed-package directory (with its pkgs.rktd). Furthermore, config.rktd can provide a list of additional files/directories to search. This allows the main links.rktd and pkgs to act like /usr/lib things, while additional directories can act like /lib things. The `-C'/`--links' command-line flag to `racket' has been removed. The default location for the installation-wide links.rtkd and pkgs.rktd files have moved from etc back into lib. Either location seems sensible to me, but with the generalization to support a installation-wide search list, it works better to keep pkgs.rktd together with the installed package implementations, and it seems best to keep pkgs and links.rktd together. Note that the search path for collections goes through user-specific, version-specific links first (i.e., user scope), then user-specific, all-version links (i.e.,shared scope), and then installation-wide links (i.e., installation scope). The package system should similarly work sensibly if you, say, install a package at user scope that shadows collections for a package (possibility using the same package name) at installation scope. For now, you have to use `raco pkg install --force' to make that happen; longer term, I think we want an option that is like `--force' but limited to sensible shadowings. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] single-collection packages
+1 On Jun 25, 2013, at 4:27 PM, Sam Tobin-Hochstadt wrote: On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On 2013-06-25 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
- mzlib/{pconvert, class100, serialize, thread, transcr}
According to the 5.3 release announcement, class100 is set to be removed
by the August release, so maybe we can just remove it entirely now.
Cheers,
Asumu
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] `raco link', links.rktd, pkgs, and config.rktd
On Tue, Jun 25, 2013 at 3:49 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Caveat 1: In case you don't use the top-level default `make' target when building from the repo, this change means that you need to run `make pkg-links' when you next update. You may also find old, wrong version .zo files hanging around confusing things after this update (I did, anyways). Probably easiest to just delete them all; since the version number changed they all have to be rebuilt regardless. Robby Caveat 2: Feel free to skip the rest. This message is on the far end of what most of us care about in the package system. I think the changes are unavoidable, though, and I think the mostly get us to a complete and consistent design point for multi-user installations (likely common) and /usr versus /usr/lib conventions (not so much, but I think there is demand for that). When single-collection packages become the default, I don't see much use for `raco link', and instead it will be better for most of us to use `raco pkg install --link'. But I see `raco link' sticking around as an layer that some may want to use or look inside. To bring `raco link' and `raco pkg' more in line with each other, and to generally clean up a mistake (IMO) in `raco link', I've changed the behavior of `raco link -u' to be like `raco pkg ... -u': it installs a link in a user- and version-specific way, instead of in a user-specific but all-version way. Naturally, the `raco link' command now supports `-s'/`--shared', just like `raco pkg'. Links installed with `-u' now go into a links.rktd file that's in the version-labeled directory in the user's add-on directory, instead of in links.rktd (with a version regexp) outside the version-labeled directory. The config.rktd file in etc can now specify a location for the installation-wide links.rktd file and pkgs installed-package directory (with its pkgs.rktd). Furthermore, config.rktd can provide a list of additional files/directories to search. This allows the main links.rktd and pkgs to act like /usr/lib things, while additional directories can act like /lib things. The `-C'/`--links' command-line flag to `racket' has been removed. The default location for the installation-wide links.rtkd and pkgs.rktd files have moved from etc back into lib. Either location seems sensible to me, but with the generalization to support a installation-wide search list, it works better to keep pkgs.rktd together with the installed package implementations, and it seems best to keep pkgs and links.rktd together. Note that the search path for collections goes through user-specific, version-specific links first (i.e., user scope), then user-specific, all-version links (i.e.,shared scope), and then installation-wide links (i.e., installation scope). The package system should similarly work sensibly if you, say, install a package at user scope that shadows collections for a package (possibility using the same package name) at installation scope. For now, you have to use `raco pkg install --force' to make that happen; longer term, I think we want an option that is like `--force' but limited to sensible shadowings. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Tue, 25 Jun 2013 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
While moving some files around between packages, I realized that there
are a number of things that could be moved out of the core and into
packages. Here's a partial list of things that I think are not needed
at all by the rest of the core:
- racket/sandbox and the rest of the sandbox code
- data/{union-find, interval-map, splay-tree, skip-list, order, gvector, heap}
- srfi/4
- unstable/{options, contract}
- errortrace (once sandbox is removed)
- compatibility/*
- mzlib/{pconvert, class100, serialize, thread, transcr}
- a bunch of other parts of mzlib that are just reprovides
The following are libraries that could be removed with (I believe)
small changes to the rest of the core:
- rackunit
- srfi/13
- mzlib/unit200 (maybe, this might be hard)
- mzlib/kw
If this seems like a good idea to people, I'm happy to go ahead and
start doing the work.
That seems like a good idea to me.
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] `raco link', links.rktd, pkgs, and config.rktd
8 hours ago, Matthew Flatt wrote: The config.rktd file in etc can now specify a location for the installation-wide links.rktd file and pkgs installed-package directory (with its pkgs.rktd). On a clean build I get an empty etc directory -- explained by moving the files that were in it -- but is it now a bug, or is it a placeholder for an optional config file? (Would there be anything else there?) Furthermore, config.rktd can provide a list of additional files/directories to search. This allows the main links.rktd and pkgs to act like /usr/lib things, while additional directories can act like /lib things. Can you explain this more? I don't see the connection. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
Two.5 notes:
* IMO the sandbox and errortrace should stay in -- even if they're not
needed, they are both intimately tied to the core so there wouldn't
be any benefit from moving them to a package.
* I think that it makes sense to move compatibility into its own
package, and move the mzlib stuff into that same package.
* Maybe the same for data?
9 hours ago, Sam Tobin-Hochstadt wrote:
While moving some files around between packages, I realized that there
are a number of things that could be moved out of the core and into
packages. Here's a partial list of things that I think are not needed
at all by the rest of the core:
- racket/sandbox and the rest of the sandbox code
- data/{union-find, interval-map, splay-tree, skip-list, order, gvector, heap}
- srfi/4
- unstable/{options, contract}
- errortrace (once sandbox is removed)
- compatibility/*
- mzlib/{pconvert, class100, serialize, thread, transcr}
- a bunch of other parts of mzlib that are just reprovides
The following are libraries that could be removed with (I believe)
small changes to the rest of the core:
- rackunit
- srfi/13
- mzlib/unit200 (maybe, this might be hard)
- mzlib/kw
If this seems like a good idea to people, I'm happy to go ahead and
start doing the work.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
Racket Developers list:
http://lists.racket-lang.org/dev
