Re: [racket-users] Sharing a udp socket between threads via parameters
Cool, thanks! On Thu, Dec 5, 2019, 4:11 PM Matthew Flatt wrote: > At Thu, 5 Dec 2019 14:26:17 -0500, David Storrs wrote: > > My understanding is that parameters are copied between threads, but I'm > not > > sure how this interacts with things like file ports, network connections, > > etc. Would the following code be problematic? > > > > > > (define conn (make-parameter)) > > (define s (udp-open-socket)) > > (udp-bind! s #f 12345) > > (conn s) > > > > (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from bob"))) > > (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from fred"))) > > Yes, this works. > > As you say, a thread inherits parameter values (at the time that the > thread is created) from its creating thread, and a UDP socket can be > used from multiple threads at once and isn't tied to any particular > thread, so using `(conn)` in different threads is fine. > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKofJNSu_P1WgMK_UuaLhdv_w-DJJS7O9NV%3D4go84YAcJhA%40mail.gmail.com.
Re: [racket-users] Re: GUI (get-directory)
First, one thing I would suggest is that you can create pull requests for anything right from the GitHub UI, although that doesn't let you test them. Especially for small documentation changes where there's no chance you're breaking something, I find that to be very effective and lightweight. Second, here's how I would go about making a documentation change to something in the "main" documentation - I go to the relevant directory (such as racket/pkgs/racket-doc/scribblings/reference). - I look at the file name of the HTML page I want to change, such as https://docs.racket-lang.org/reference/envvars.html - Edit envvars.scrbl. Sometimes the file name is less easy to find, such as https://docs.racket-lang.org/reference/Manipulating_Paths.html Then I use grep (it's in "paths.scrbl", which would be easy to see from the larger section). - Create pull request. For most other packages, I'd do the following: - `raco pkg update --clone the-pkg` - cd the-pkg # and then look around for the documentation - Other steps as above. Sam On Thu, Dec 5, 2019 at 7:56 PM Matt Jadud wrote: > > It feels like much of the information needed to make some of the sign posts > for easy contribution are available either 1) automatically available at time > of documentation build, or 2) could be added to the info file. > > Would someone in the Racket team be able to recommend or suggest some > concrete ways the community might approach work that begins addressing the > task of making it easier to contribute to docs? > > Or, really, anyone with some insight into the tools. Some pointers would help > make it easier to contribute productively. > > Cheers, > Matt > > On Thu, Dec 5, 2019, 18:29 wanderley.guimar...@gmail.com > wrote: >> >> I think your point is totally valid, and I feel that I already saw such >> discussion in the mail list. >> >> You can simplify the process by searching a piece of the documentation in >> github. For example, I search for a piece of the docs from rackjure (1) >> which is the second result in my search. >> >> >> (1) >> https://github.com/search?l==macro+automatically+adds+the+parentheses+language%3ARacket=Code >> >> >> On Thu, Dec 5, 2019 at 12:27 PM David Storrs wrote: >>> >>> For the record, my big concern with the documentation is that it's >>> extremely hard to contribute to. I would be delighted to contribute >>> documentation if the process was easy, but it's just not. For a language >>> as amazing as Racket and a documentation set as high-quality as Racket's, >>> the difficulty of helping with it is surprising. >>> >>> tl;dr : Using literate programming techniques(*) for documentation is a >>> bad idea. So is having random tiny files scattered around instead of one >>> single .scrbl file in a location that maps to the URL of the page. >>> >>> (*) (i.e., having random tiny files with documentation on one particular >>> thing and then automating the process of assembling them) >>> >>> >>> My understanding is that the sequence goes like this: >>> >>> 1) Notice a thing you would like to change (a typo fix, add an example, etc) >>> 1a) Ask on the mailing list how to contribute changes since the Guide / >>> Reference / package does not have clear directions built in >>> 2) Go to Github >>> 3) Find which racket-related repository is the one that matters for this >>> documentation. The Racket project itself has half a dozen repositories and >>> it's not obvious (to me, at least) which one is which. Things on the >>> package server will have a direct link, which helps a lot. >>> 4) git fork the appropriate repository, git clone it to your local machine >>> 5) grep -r through the clone to find the document that you want to modify. >>> It will not be in a location apparent from the URL of the page you were >>> looking at, nor will it be named what that page was named, nor will it >>> contain all of the content from that page. Also, it will be in Scribble, >>> which is a DSL that requires non-trivial effort to learn and is non-trivial >>> to read. Still, it produces amazing output so that's probably worth it. >>> It's intimidating when you're just getting started, though. >>> 6a) make your change >>> 6b) google for how to rebuild scribble documentation >>> 6c) rebuild (by default this will rebuild all documentation), verify you >>> made the change correctly >>> 7) git commit, git push >>> 8) go back to github and submit a pull request >>> 9) (when (eq? (sync pr-msg-ch) 'Accepted) (exit)) >>> 10) make requested changes >>> 11) git commit, git push, goto 9 >>> >>> Compare that to what it looks like in, e.g., Perl >>> >>> 1) Notice a thing you would like to change (a typo fix, add an example, etc) >>> 2) got to CPAN and search for the package / tutorial / etc. clicking on >>> the name of the package gets you a listing of all files in the package (cf >>> https://metacpan.org/release/ETHER/Moose-2.2012) >>> 3) click on the 'Package::Name::Contributing' file
Re: [racket-users] Re: GUI (get-directory)
It feels like much of the information needed to make some of the sign posts for easy contribution are available either 1) automatically available at time of documentation build, or 2) could be added to the info file. Would someone in the Racket team be able to recommend or suggest some concrete ways the community might approach work that begins addressing the task of making it easier to contribute to docs? Or, really, anyone with some insight into the tools. Some pointers would help make it easier to contribute productively. Cheers, Matt On Thu, Dec 5, 2019, 18:29 wanderley.guimar...@gmail.com < wanderley.guimar...@gmail.com> wrote: > I think your point is totally valid, and I feel that I already saw such > discussion in the mail list. > > You can simplify the process by searching a piece of the documentation in > github. For example, I search for a piece of the docs from rackjure (1) > which is the second result in my search. > > > (1) > https://github.com/search?l==macro+automatically+adds+the+parentheses+language%3ARacket=Code > > > On Thu, Dec 5, 2019 at 12:27 PM David Storrs > wrote: > >> For the record, my big concern with the documentation is that it's >> extremely hard to contribute to. I would be delighted to contribute >> documentation if the process was easy, but it's just not. For a language >> as amazing as Racket and a documentation set as high-quality as Racket's, >> the difficulty of helping with it is surprising. >> >> tl;dr : Using literate programming techniques(*) for documentation is a >> bad idea. So is having random tiny files scattered around instead of one >> single .scrbl file in a location that maps to the URL of the page. >> >> (*) (i.e., having random tiny files with documentation on one particular >> thing and then automating the process of assembling them) >> >> >> My understanding is that the sequence goes like this: >> >> 1) Notice a thing you would like to change (a typo fix, add an example, >> etc) >> 1a) Ask on the mailing list how to contribute changes since the Guide / >> Reference / package does not have clear directions built in >> 2) Go to Github >> 3) Find which racket-related repository is the one that matters for this >> documentation. The Racket project itself has half a dozen repositories and >> it's not obvious (to me, at least) which one is which. Things on the >> package server will have a direct link, which helps a lot. >> 4) git fork the appropriate repository, git clone it to your local machine >> 5) grep -r through the clone to find the document that you want to >> modify. It will not be in a location apparent from the URL of the page you >> were looking at, nor will it be named what that page was named, nor will it >> contain all of the content from that page. Also, it will be in Scribble, >> which is a DSL that requires non-trivial effort to learn and is non-trivial >> to read. Still, it produces amazing output so that's probably worth it. >> It's intimidating when you're just getting started, though. >> 6a) make your change >> 6b) google for how to rebuild scribble documentation >> 6c) rebuild (by default this will rebuild all documentation), verify you >> made the change correctly >> 7) git commit, git push >> 8) go back to github and submit a pull request >> 9) (when (eq? (sync pr-msg-ch) 'Accepted) (exit)) >> 10) make requested changes >> 11) git commit, git push, goto 9 >> >> Compare that to what it looks like in, e.g., Perl >> >> 1) Notice a thing you would like to change (a typo fix, add an example, >> etc) >> 2) got to CPAN and search for the package / tutorial / etc. clicking on >> the name of the package gets you a listing of all files in the package (cf >> https://metacpan.org/release/ETHER/Moose-2.2012) >> 3) click on the 'Package::Name::Contributing' file and do what it says. >> This will probably be similar to the Racket workflow except that: >> >> a) The complete details are spelled out. >> b) There is a link directly to the repository >> c) The location of the file you need to edit is obvious from the URL of >> the documentation page that you're changing >> d) The file contains the complete text of the page so it's easier to find >> and easier to verify that your edits were correct >> e) The file is in POD, which is so simple that you can generally learn >> what you need just from glancing at the file, and it's easier to read than >> Scribble. It's simple enough that you generally don't need to rebuild it >> to HTML, but if you choose to then you can easily rebuild just that page. >> >> Example of a Contributing file: >> https://metacpan.org/pod/release/ETHER/Moose-2.2012/lib/Moose/Manual/Contributing.pod >> >> (NB: All major Perl packages have a Contributing file and the 'create >> a package' tool for generating Perl modules creates a stub version for you >> so it's hard to forget. If the author somehow *does* forget and the >> package doesn't have its own Contributing file then CPAN will show you a >> default
Re: [racket-users] Re: GUI (get-directory)
I think your point is totally valid, and I feel that I already saw such discussion in the mail list. You can simplify the process by searching a piece of the documentation in github. For example, I search for a piece of the docs from rackjure (1) which is the second result in my search. (1) https://github.com/search?l==macro+automatically+adds+the+parentheses+language%3ARacket=Code On Thu, Dec 5, 2019 at 12:27 PM David Storrs wrote: > For the record, my big concern with the documentation is that it's > extremely hard to contribute to. I would be delighted to contribute > documentation if the process was easy, but it's just not. For a language > as amazing as Racket and a documentation set as high-quality as Racket's, > the difficulty of helping with it is surprising. > > tl;dr : Using literate programming techniques(*) for documentation is a > bad idea. So is having random tiny files scattered around instead of one > single .scrbl file in a location that maps to the URL of the page. > > (*) (i.e., having random tiny files with documentation on one particular > thing and then automating the process of assembling them) > > > My understanding is that the sequence goes like this: > > 1) Notice a thing you would like to change (a typo fix, add an example, > etc) > 1a) Ask on the mailing list how to contribute changes since the Guide / > Reference / package does not have clear directions built in > 2) Go to Github > 3) Find which racket-related repository is the one that matters for this > documentation. The Racket project itself has half a dozen repositories and > it's not obvious (to me, at least) which one is which. Things on the > package server will have a direct link, which helps a lot. > 4) git fork the appropriate repository, git clone it to your local machine > 5) grep -r through the clone to find the document that you want to > modify. It will not be in a location apparent from the URL of the page you > were looking at, nor will it be named what that page was named, nor will it > contain all of the content from that page. Also, it will be in Scribble, > which is a DSL that requires non-trivial effort to learn and is non-trivial > to read. Still, it produces amazing output so that's probably worth it. > It's intimidating when you're just getting started, though. > 6a) make your change > 6b) google for how to rebuild scribble documentation > 6c) rebuild (by default this will rebuild all documentation), verify you > made the change correctly > 7) git commit, git push > 8) go back to github and submit a pull request > 9) (when (eq? (sync pr-msg-ch) 'Accepted) (exit)) > 10) make requested changes > 11) git commit, git push, goto 9 > > Compare that to what it looks like in, e.g., Perl > > 1) Notice a thing you would like to change (a typo fix, add an example, > etc) > 2) got to CPAN and search for the package / tutorial / etc. clicking on > the name of the package gets you a listing of all files in the package (cf > https://metacpan.org/release/ETHER/Moose-2.2012) > 3) click on the 'Package::Name::Contributing' file and do what it says. > This will probably be similar to the Racket workflow except that: > > a) The complete details are spelled out. > b) There is a link directly to the repository > c) The location of the file you need to edit is obvious from the URL of > the documentation page that you're changing > d) The file contains the complete text of the page so it's easier to find > and easier to verify that your edits were correct > e) The file is in POD, which is so simple that you can generally learn > what you need just from glancing at the file, and it's easier to read than > Scribble. It's simple enough that you generally don't need to rebuild it > to HTML, but if you choose to then you can easily rebuild just that page. > > Example of a Contributing file: > https://metacpan.org/pod/release/ETHER/Moose-2.2012/lib/Moose/Manual/Contributing.pod > > (NB: All major Perl packages have a Contributing file and the 'create a > package' tool for generating Perl modules creates a stub version for you so > it's hard to forget. If the author somehow *does* forget and the package > doesn't have its own Contributing file then CPAN will show you a default > version that contains all critical information. Also, it's easy to find > the Contributing file: Go to the package listing that's available directly > on CPAN and Ctrl+F for "Contributing") > > > > On Tue, Dec 3, 2019 at 5:26 PM James Platt wrote: > >> >> On Nov 25, 2019, at 1:29 PM, Stephen De Gabrielle wrote: >> >> > Many packages contain an /examples folder, and adding examples is an >> easy way to contribute. >> >> I did not know that. So, I guess the strategy is to find the git >> repository for the package and look there? In any case, I haven't been >> finding these examples with a general web search. >> >> > >> > There is also https://github.com/racket/racket/wiki/Artifacts >> > >> >> This page captures useful code
Re: [racket-users] Vector length and indices contracts
What if we had a `(vector-index/c vec)` contract combinator? It would be equivalent to `(integer-in 0 (sub1 (vector-length vec)))`. On Wednesday, December 4, 2019 at 1:29:22 PM UTC-8, Matthew Flatt wrote: > > At Wed, 4 Dec 2019 22:24:10 +0100, Dominik Pantůček wrote: > > What about all the vector-ref, -set! and basically all indices > > contracts? That should probably be the same. > > I'm less enthusiastic about that change. It turns out that a non-fixnum > argument won't work for `vector-ref`, but the stronger constraint is > that the argument needs to be less than the vector's length. So, it > seems redundant in an unhelpful way to require that the argument > individually is a fixnum --- but I'm not completely sure. > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6bf86e11-ca19-4619-845c-98b0478a7ebc%40googlegroups.com.
Re: [racket-users] GUI (get-directory)
FWIW I just found an introduction to Racket GUIs by Andres Ramos:
https://www.youtube.com/watch?v=yo6wVXS6dkU
/soegaard
Den tir. 19. nov. 2019 kl. 18.49 skrev pow bam :
> Hello, I am very new to programming and up until this point I had only
> seriously messed with the AutoIt language - it was easy to search and find
> out how to do things as their forums were quite active and already
> possessed a wealth of data that any determined person could get by on with
> just search alone and never needing to actively post. I built myself an
> entire program in this fashion, learning as I went. I decided I wanted to
> learn how to do this in a "real" full-blown language (tho you could easily
> argue that AutoIt is a full language now). I've decided that I love the
> idea of Lisp and Racket in particular but I am hitting roadblocks to that
> goal as the search functionality and community just isn't near the level of
> AutoIt. So here I am, actually posting in the only place it appears I can..
>
> I am trying to make use of (get-directory) which pops up a GUI prompt
> asking a user to select a directory..
>
> https://docs.racket-lang.org/gui/Windowing_Functions.html#%28def._%28%28lib._mred%2Fmain..rkt%29._get-directory%29%29
>
> Here is my code which works..
>
> #lang racket/gui
> (require racket/class)
> (define gds-main
> (new frame%
>[label "GD Switcher"]
>[width 250]
>[height 300]
>[style '(no-resize-border)]))
> (define panel-1
> (new vertical-panel%
>[parent gds-main]
>[style '(border)]
>[alignment '(center center)]))
> (new choice%
> [parent panel-1]
> [label #f]
> [choices '("Forgotten Gods"
> "Ashes of Malmouth"
> "Vanilla Ice Cream")])
> (get-directory)
> (send gds-main center 'both)
> (send gds-main show #t)
>
>
> ..if I just use get directory as-is but if I try
>
> (get-directory [message "Select a folder.."])
>
> in any combination, and I've tried so many, it only ever gives me back the
> error..
>
> message: unbound identifier in: message
>
> What am I missing, how do I make this work?
>
> Thank you in advance for any insight.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/67dff8ff-cbd2-4d26-8901-34fc2be43928%40googlegroups.com
>
> .
>
--
--
Jens Axel Søgaard
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/CABefVgzEfWzbbrosdotifEhVHn3eQ%3DAbCeTY%2BZUGdRLEodT8DA%40mail.gmail.com.
Re: [racket-users] Sharing a udp socket between threads via parameters
At Thu, 5 Dec 2019 14:26:17 -0500, David Storrs wrote: > My understanding is that parameters are copied between threads, but I'm not > sure how this interacts with things like file ports, network connections, > etc. Would the following code be problematic? > > > (define conn (make-parameter)) > (define s (udp-open-socket)) > (udp-bind! s #f 12345) > (conn s) > > (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from bob"))) > (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from fred"))) Yes, this works. As you say, a thread inherits parameter values (at the time that the thread is created) from its creating thread, and a UDP socket can be used from multiple threads at once and isn't tied to any particular thread, so using `(conn)` in different threads is fine. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20191205211101.41EDF650182%40mail-svr1.cs.utah.edu.
Re: [racket-users] Re: GUI (get-directory)
For the record, my big concern with the documentation is that it's extremely hard to contribute to. I would be delighted to contribute documentation if the process was easy, but it's just not. For a language as amazing as Racket and a documentation set as high-quality as Racket's, the difficulty of helping with it is surprising. tl;dr : Using literate programming techniques(*) for documentation is a bad idea. So is having random tiny files scattered around instead of one single .scrbl file in a location that maps to the URL of the page. (*) (i.e., having random tiny files with documentation on one particular thing and then automating the process of assembling them) My understanding is that the sequence goes like this: 1) Notice a thing you would like to change (a typo fix, add an example, etc) 1a) Ask on the mailing list how to contribute changes since the Guide / Reference / package does not have clear directions built in 2) Go to Github 3) Find which racket-related repository is the one that matters for this documentation. The Racket project itself has half a dozen repositories and it's not obvious (to me, at least) which one is which. Things on the package server will have a direct link, which helps a lot. 4) git fork the appropriate repository, git clone it to your local machine 5) grep -r through the clone to find the document that you want to modify. It will not be in a location apparent from the URL of the page you were looking at, nor will it be named what that page was named, nor will it contain all of the content from that page. Also, it will be in Scribble, which is a DSL that requires non-trivial effort to learn and is non-trivial to read. Still, it produces amazing output so that's probably worth it. It's intimidating when you're just getting started, though. 6a) make your change 6b) google for how to rebuild scribble documentation 6c) rebuild (by default this will rebuild all documentation), verify you made the change correctly 7) git commit, git push 8) go back to github and submit a pull request 9) (when (eq? (sync pr-msg-ch) 'Accepted) (exit)) 10) make requested changes 11) git commit, git push, goto 9 Compare that to what it looks like in, e.g., Perl 1) Notice a thing you would like to change (a typo fix, add an example, etc) 2) got to CPAN and search for the package / tutorial / etc. clicking on the name of the package gets you a listing of all files in the package (cf https://metacpan.org/release/ETHER/Moose-2.2012) 3) click on the 'Package::Name::Contributing' file and do what it says. This will probably be similar to the Racket workflow except that: a) The complete details are spelled out. b) There is a link directly to the repository c) The location of the file you need to edit is obvious from the URL of the documentation page that you're changing d) The file contains the complete text of the page so it's easier to find and easier to verify that your edits were correct e) The file is in POD, which is so simple that you can generally learn what you need just from glancing at the file, and it's easier to read than Scribble. It's simple enough that you generally don't need to rebuild it to HTML, but if you choose to then you can easily rebuild just that page. Example of a Contributing file: https://metacpan.org/pod/release/ETHER/Moose-2.2012/lib/Moose/Manual/Contributing.pod (NB: All major Perl packages have a Contributing file and the 'create a package' tool for generating Perl modules creates a stub version for you so it's hard to forget. If the author somehow *does* forget and the package doesn't have its own Contributing file then CPAN will show you a default version that contains all critical information. Also, it's easy to find the Contributing file: Go to the package listing that's available directly on CPAN and Ctrl+F for "Contributing") On Tue, Dec 3, 2019 at 5:26 PM James Platt wrote: > > On Nov 25, 2019, at 1:29 PM, Stephen De Gabrielle wrote: > > > Many packages contain an /examples folder, and adding examples is an > easy way to contribute. > > I did not know that. So, I guess the strategy is to find the git > repository for the package and look there? In any case, I haven't been > finding these examples with a general web search. > > > > > There is also https://github.com/racket/racket/wiki/Artifacts > > > >> This page captures useful code snippets that are too small to be a > package. > >> > >> Please contribute your own! > > > > Though these might be better places in documentation, or in /examples > > That artifacts wiki a good thing to know about. Most of these are a > little more complex than I am thinking are good for documentation but I may > well contribute some small but useful code. I sometimes create my own > examples as I go because I often look back through my own code to refresh > my memory on how to do something. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To
[racket-users] Sharing a udp socket between threads via parameters
My understanding is that parameters are copied between threads, but I'm not sure how this interacts with things like file ports, network connections, etc. Would the following code be problematic? (define conn (make-parameter)) (define s (udp-open-socket)) (udp-bind! s #f 12345) (conn s) (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from bob"))) (thread (thunk (udp-send-to (conn) "8.8.8.8" 5 #"hi from fred"))) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoeUGiwFA0FmrW6YMCLHaooyzkGRtZPMbwx8WJacCj%3D2uQ%40mail.gmail.com.
Re: [racket-users] Limiting consecutive identical elements with match
While playing around with this I came across an error message in match that could perhaps stand some improvement ... > (define (super-cool?/flawed ds) (match ds [(list _ ... a a ... _) #t] [_ #f])) a59: unbound identifier; also, no #%top syntax transformer is bound in: a59 Dan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFKxZVVJYL%3Du%2BJ_pKvRfjHhBZCJz3APH8b0Hnkbwttoj6mNXeg%40mail.gmail.com.
Re: [racket-users] Scribble output without navigation
The usual way I've done this is with some custom CSS to set the navigation to "display: none". Sam On Wed, Dec 4, 2019 at 5:12 PM 'Reuben Thomas' via Racket Users wrote: > > How can I get scribble/base to output HTML without the navigation elements? I > just want a plain HTML page, similar to the look of the LaTeX output. > > I can of course extract the "main" div from the standard output, but that > seems to be somewhat shutting the stable door after the horse has bolted. > > Grepping the package reveals mentions of "nonavigation" but that seems to be > to do with when links are omitted because you can go no further in one > direction or another. > > -- > https://rrt.sc3d.org > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAOnWdohXeROf75DQmdN75hZ8G_rMieT6-A-%3D8fYisJhptbgjiw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BaA8tp3AqP1APjmTQfVziva83t1YKD-zDzTmzS9sa_DgA%40mail.gmail.com.
