Re: [racket-dev] replacement for #:namespace arg in dispatch/servlet
I'm not sure how much this helps, but you can at least postpone the problem by using this config file (a modified version of the one in the handin server quick start docs): ((active-dirs (test)) (use-https #f)) This way, the web server won't be started. I think students should still be able to hand things in, but they won't be able to check on the status of things. Robby On Sun, Jan 2, 2011 at 3:32 PM, John Clements cleme...@brinckerhoff.org wrote: I'm trying to use the 'handin-server' code, which depends on a now-defunct #:namespace argument to dispatch/servlet. Your change eliminating this argument (commit c7995e247e8300) was in response to Shriram's PR about port number assignments, but that doesn't help me to figure out why that argument would have disappeared. I'm guessing that it's going to be something simple like using parameterize on current-namespace instead of specifying it as an optional argument, but since the handin server code isn't mine, I wouldn't be confident that my change was a sane one. So: is there a simple mechanism that replaces this optional argument? John Clements _ 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] replacement for #:namespace arg in dispatch/servlet
The option was removed because it didn't do anything. #:namespace in other places in the Web Server is used to allow dynamically loaded code to share module instantiations with the Web Server (and therefore with each other.) dispatch/servlet does not dynamic load any code. It runs a servlet that is passed as a closure argument. That closure has whatever namespace the author of the servlet wants it to and it would be misleading to have this argument that really only effects dynamic loading of code within the servlet itself. The handin server should just work if you delete the argument, because as I said, it isn't doing anything. Jay 2011/1/2 John Clements cleme...@brinckerhoff.org: I'm trying to use the 'handin-server' code, which depends on a now-defunct #:namespace argument to dispatch/servlet. Your change eliminating this argument (commit c7995e247e8300) was in response to Shriram's PR about port number assignments, but that doesn't help me to figure out why that argument would have disappeared. I'm guessing that it's going to be something simple like using parameterize on current-namespace instead of specifying it as an optional argument, but since the handin server code isn't mine, I wouldn't be confident that my change was a sane one. So: is there a simple mechanism that replaces this optional argument? John Clements -- 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/dev
Re: [racket-dev] up-to-date libgtk for drracket on debian stable?
Matthew Flatt wrote: The main change seems to be dropping the 0 version. Does replacing '(0) with '(0 ) also work, so that a versionless name is tried when the versioned name fails? That part seems to work. See the error message below. It looks a bit strange though because the error message from ffi-lib points to libcairo.so.2 when in fact the library that ffi-lib ends up trying to load is libcairo.so.11.0. Just to make things more annoying, libcairo needs libpthread: [...] so I also had to change the define-runtime-lib macro from collects/racket/draw/private/libs.rkt so that the unix case of the macro accepts multiple libraries. I'm not sure that's the best way to go about adding libpthread though, and I'm definitely not sure that my simple change to collects/racket/draw/unsafe/cairo.rkt to add libpthread works on other platforms... Won't libpthread get loaded auomatically when libcairo is loaded? Apparently not: $ ldd /usr/local/lib/libcairo.so.11.0 | grep pthread 0318a000 2318e000 rlib 011 0 /usr/X11R6/lib/libpthread-stubs.so.1.0 $ So it looks like it has to be done explicitely. This is what currently happens with the latest version (without any of my patches): $ gracket/gracket3m gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_destroy' gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_settype' gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_init' ffi-lib: couldn't open libcairo.so.2 (File not found) === context === /home/meunier/lang/plt/collects/racket/draw/unsafe/cairo.rkt: [running body] /home/meunier/lang/plt/collects/racket/draw/private/font.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw/private/post-script-dc.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/kernel.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/const.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/check.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/mred.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/main.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/base.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/gui/init.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/init.rkt: [traversing imports] gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_mutex_lock' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_mutex_unlock' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_cond_signal' [... 20 more lines like this ...] gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_attr_getschedparam' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_setspecific' link: reference (phase 0) to a variable in module /home/meunier/lang/plt/collects/racket/draw/unsafe/cairo.rkt that is uninitialized (phase level 0); reference appears in module: /home/meunier/lang/plt/collects/racket/draw/unsafe/pango.rkt in: _cairo_t === context === /home/meunier/lang/plt/collects/racket/draw/unsafe/pango.rkt: [running body] /home/meunier/lang/plt/collects/racket/draw/private/font.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw/private/post-script-dc.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/kernel.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/const.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/check.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/mred.rkt: [traversing imports] Philippe _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] replacement for #:namespace arg in dispatch/servlet
Thanks Jay. I've removed the use of the argument and verified that the handin-server still seems to work. I'll push the change when I get to school. Robby On Monday, January 3, 2011, Jay McCarthy jay.mccar...@gmail.com wrote: The option was removed because it didn't do anything. #:namespace in other places in the Web Server is used to allow dynamically loaded code to share module instantiations with the Web Server (and therefore with each other.) dispatch/servlet does not dynamic load any code. It runs a servlet that is passed as a closure argument. That closure has whatever namespace the author of the servlet wants it to and it would be misleading to have this argument that really only effects dynamic loading of code within the servlet itself. The handin server should just work if you delete the argument, because as I said, it isn't doing anything. Jay 2011/1/2 John Clements cleme...@brinckerhoff.org: I'm trying to use the 'handin-server' code, which depends on a now-defunct #:namespace argument to dispatch/servlet. Your change eliminating this argument (commit c7995e247e8300) was in response to Shriram's PR about port number assignments, but that doesn't help me to figure out why that argument would have disappeared. I'm guessing that it's going to be something simple like using parameterize on current-namespace instead of specifying it as an optional argument, but since the handin server code isn't mine, I wouldn't be confident that my change was a sane one. So: is there a simple mechanism that replaces this optional argument? John Clements -- 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/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
At Mon, 3 Jan 2011 11:39:28 -0600, Robby Findler wrote: I've changed the handin server so it puts its docs in the main tree like (I believe) it is supposed to. That breaks the distribution build. The handin-server docs were intentionally not installed into the main tree, because handin-server is not included in the distribution. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
On Mon, Jan 3, 2011 at 11:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 11:39:28 -0600, Robby Findler wrote: I've changed the handin server so it puts its docs in the main tree like (I believe) it is supposed to. That breaks the distribution build. The handin-server docs were intentionally not installed into the main tree, because handin-server is not included in the distribution. So what the irc person was doing is just not supposed to work, I guess? I'd still like to find out what preference was getting set, so if Jon tries again, that'd be interesting to me. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
On 01/03/2011 10:52 AM, Robby Findler wrote: On Mon, Jan 3, 2011 at 11:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 11:39:28 -0600, Robby Findler wrote: I've changed the handin server so it puts its docs in the main tree like (I believe) it is supposed to. That breaks the distribution build. The handin-server docs were intentionally not installed into the main tree, because handin-server is not included in the distribution. So what the irc person was doing is just not supposed to work, I guess? I'd still like to find out what preference was getting set, so if Jon tries again, that'd be interesting to me. As of commit commit e6d45e2ae6804a73c9cea2a41d544c4a65b7a5d9 Author: Robby Findler ro...@racket-lang.org Date: Mon Jan 3 08:19:51 2011 -0600 a 'sudo make install' does not create the ~/.racket directory and things install fine into /usr/local when --prefix=/usr/local is given to `configure' _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
Ah. So the problem was that root owned the .racket directory itself. Should I revert my commit? Robby On Mon, Jan 3, 2011 at 1:39 PM, Jon Rafkind rafk...@cs.utah.edu wrote: On 01/03/2011 10:52 AM, Robby Findler wrote: On Mon, Jan 3, 2011 at 11:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 11:39:28 -0600, Robby Findler wrote: I've changed the handin server so it puts its docs in the main tree like (I believe) it is supposed to. That breaks the distribution build. The handin-server docs were intentionally not installed into the main tree, because handin-server is not included in the distribution. So what the irc person was doing is just not supposed to work, I guess? I'd still like to find out what preference was getting set, so if Jon tries again, that'd be interesting to me. As of commit commit e6d45e2ae6804a73c9cea2a41d544c4a65b7a5d9 Author: Robby Findler ro...@racket-lang.org Date: Mon Jan 3 08:19:51 2011 -0600 a 'sudo make install' does not create the ~/.racket directory and things install fine into /usr/local when --prefix=/usr/local is given to `configure' _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
Won't that make .racket be owned by root again when some preference file gets written out during 'make install'? On 01/03/2011 12:47 PM, Robby Findler wrote: Ah. So the problem was that root owned the .racket directory itself. Should I revert my commit? Robby On Mon, Jan 3, 2011 at 1:39 PM, Jon Rafkind rafk...@cs.utah.edu wrote: On 01/03/2011 10:52 AM, Robby Findler wrote: On Mon, Jan 3, 2011 at 11:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 11:39:28 -0600, Robby Findler wrote: I've changed the handin server so it puts its docs in the main tree like (I believe) it is supposed to. That breaks the distribution build. The handin-server docs were intentionally not installed into the main tree, because handin-server is not included in the distribution. So what the irc person was doing is just not supposed to work, I guess? I'd still like to find out what preference was getting set, so if Jon tries again, that'd be interesting to me. As of commit commit e6d45e2ae6804a73c9cea2a41d544c4a65b7a5d9 Author: Robby Findler ro...@racket-lang.org Date: Mon Jan 3 08:19:51 2011 -0600 a 'sudo make install' does not create the ~/.racket directory and things install fine into /usr/local when --prefix=/usr/local is given to `configure' _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
On 01/03/2011 12:55 PM, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Yea, I kind of feel like 'make' should build all the collects and docs and whatnot. Unless there is a good reason not to. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
At Mon, 3 Jan 2011 14:55:05 -0500, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Well, moving work from `make install' to `make' does nothing in itself. What you're suggesting is that we change what `make install' produces. In particular, I think you're suggesting that no user-specific actions take place as a result of a build and install. That change sounds ok to me, and it can be accomplished by passing `--no-user' to `raco setup' during `make install'. Unless anyone objects, I'll push that change soon. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
Would this mean that the handin server docs don't get built? Robby On Mon, Jan 3, 2011 at 3:11 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 14:55:05 -0500, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Well, moving work from `make install' to `make' does nothing in itself. What you're suggesting is that we change what `make install' produces. In particular, I think you're suggesting that no user-specific actions take place as a result of a build and install. That change sounds ok to me, and it can be accomplished by passing `--no-user' to `raco setup' during `make install'. Unless anyone objects, I'll push that change soon. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
Yes, unless you run `raco setup' later. At Mon, 3 Jan 2011 15:15:42 -0600, Robby Findler wrote: Would this mean that the handin server docs don't get built? Robby On Mon, Jan 3, 2011 at 3:11 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 14:55:05 -0500, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Well, moving work from `make install' to `make' does nothing in itself. What you're suggesting is that we change what `make install' produces. In particular, I think you're suggesting that no user-specific actions take place as a result of a build and install. That change sounds ok to me, and it can be accomplished by passing `--no-user' to `raco setup' during `make install'. Unless anyone objects, I'll push that change soon. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sudo make install
See also http://lists.racket-lang.org/users/archive/2010-January/037610.html Like Eli, I remember that we've discussed this before, but I haven't been able to track down the earlier discussion, yet... At Mon, 3 Jan 2011 14:17:42 -0700, Matthew Flatt wrote: Yes, unless you run `raco setup' later. At Mon, 3 Jan 2011 15:15:42 -0600, Robby Findler wrote: Would this mean that the handin server docs don't get built? Robby On Mon, Jan 3, 2011 at 3:11 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 14:55:05 -0500, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Well, moving work from `make install' to `make' does nothing in itself. What you're suggesting is that we change what `make install' produces. In particular, I think you're suggesting that no user-specific actions take place as a result of a build and install. That change sounds ok to me, and it can be accomplished by passing `--no-user' to `raco setup' during `make install'. Unless anyone objects, I'll push that change soon. _ 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] sudo make install
At the moment the only thing that seems to stand in the way of matching user's expectations a little bit better is the handin server's docs. How about we just distribute it? It does require a bit more sophistication to use but surely less than building from source? Robby On Monday, January 3, 2011, Matthew Flatt mfl...@cs.utah.edu wrote: See also http://lists.racket-lang.org/users/archive/2010-January/037610.html Like Eli, I remember that we've discussed this before, but I haven't been able to track down the earlier discussion, yet... At Mon, 3 Jan 2011 14:17:42 -0700, Matthew Flatt wrote: Yes, unless you run `raco setup' later. At Mon, 3 Jan 2011 15:15:42 -0600, Robby Findler wrote: Would this mean that the handin server docs don't get built? Robby On Mon, Jan 3, 2011 at 3:11 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 3 Jan 2011 14:55:05 -0500, Sam Tobin-Hochstadt wrote: On Mon, Jan 3, 2011 at 2:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Or maybe there is another possible solution that involves changing how the distribution and or the docs build works? I think the conventional solution is for `make install' to do much less work than it current does. In normal Make-built software, `make' does all of the compilation, and `make install' just does the copying. That way, `make install' wouldn't be doing things like reading preferences and creating the '.racket' directory. Well, moving work from `make install' to `make' does nothing in itself. What you're suggesting is that we change what `make install' produces. In particular, I think you're suggesting that no user-specific actions take place as a result of a build and install. That change sounds ok to me, and it can be accomplished by passing `--no-user' to `raco setup' during `make install'. Unless anyone objects, I'll push that change soon. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] drracket and rectangles
I decided to report on the few occasions when I switch from DrRacket to Emacs to accomplish something Racket-related. Just now I changed (connect* S round-n round-n-ne round-ne) (connect* SW round-ne round-ne-se round-se) (connect* NW round-se round-se-s round-s) (connect* N round-s round-s-sw round-sw) (connect* NE round-sw round-sw-nw round-nw) (connect* SE round-nw round-nw-n round-n) to (connect* round-n round-n-ne round-ne S ) (connect* round-ne round-ne-se round-se SW) (connect* round-se round-se-s round-s NW) (connect* round-s round-s-sw round-sw N ) (connect* round-sw round-sw-nw round-nw NE) (connect* round-nw round-nw-n round-n SE) I switched to Emacs because I get rectangle operations (and the only other thing I had to do is move to parens). _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drracket and rectangles
A few things for which I switch to Emacs, even when using DrRacket: * M-q to re-flow Racket comments that span multiple lines, to fill to some margin (like 79 or 80 columns). Note that Emacs has fancy adaptive-fill, but something simple and Racket-comment-specific would be fine. * M-x quack-tidy RET to reindent all lines and tidy up extraneous whitespace. Using the pretty-printer, DrRacket could go a step further, to line-breaking. * Keyboard macros. These can get pretty powerful. Matthias's argument-reordering would be a simple example, and even for that, keyboard macros using sexp movement operations would be more robust than rectangle killyank. * Working with (editing, viewing, or doing keyboard macros with) more than 2 or 3 files at once. * Doing version control operations. * Editing non-Racket/Scheme text files. The first two have been on my mental list to add to DrRacket someday. But if any students are bored over winter break... :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
