[racket-users] How to document modules that reprovide other modules?
If I have two modules `foo` and `foo/extra-thing`, and `foo` requires and re-provides all the exports of `foo/extra-thing`, how do I correctly document that fact with `defmodule` and `declare-exporting`? The documentation for those two scribble forms doesn't include examples, the grammars for them are fairly complex, and the only sign I'm using them wrong is that the search results for an identifier provided by `foo/extra-thing` doesn't include `foo` in the list of modules the identifier is exported from. Does someone have a short example of how to achieve this? -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] encountered old PLT Scheme GUI that still works great
Just an interesting thing. I restarted work back at a place that I left several years back where we still use a custom IDE written in PLT Scheme 4.25, just before it became Racket. It's about 25K lines of GUI. Out of curiosity, I recompiled everything today on 7.2.0.6 Chez racket. I ran into two small problems to fix and then it ran great, but faster. So, despite considerable and ongoing improvements, a considerable old piece of code continues doing just fine after a decade of Racket evolution. Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] performance, json
At Fri, 22 Feb 2019 16:34:24 -0500, Jon Zeppieri wrote: > On a related (but not too related) note: is there an efficient way to skip > multiple bytes in an input stream? It looks like there are two choices: > - You can read the bytes you want to skip, but that implies either > allocating a useless byte array or keeping one around for this very purpose. > - You can use (I think?) port-commit-peeked, bit given the API, it seems > like that was designed with a particular (and more complicated) use in mind. I've run into this a few times, too. Assuming that `file-position` doesn't apply, having a buffer for discarded byes is the best approach that I know. To make it faster, I think we'd have to build a `discard-bytes` function into the I/O layer. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] json, performance, racket cs, puzzlement, etc.
At Sat, 2 Mar 2019 12:24:22 -0500, Jon Zeppieri wrote: > By contrast, the same file parses in roughly 160ms with the json > module that ships with racket. > [...] > So I tested the existing library on the file, under racket-cs. (Actually, I > think the version that came with this racket-cs build includes Matthew's > recent improvements, so it's not exactly quite the same parser.) It parsed > the file in 45-50ms. Most of the difference there really us the new JSON parser, not Racket vs Racket CS. With the new JSON parser and with the recently overhauled I/O layers for Racket CS, I get 60ms for Racket and 40ms for Racket CS on my machine. > This 1MB sample file [...] takes about 20s to parse on my machine > using my aeson-alike library. [...] > > So really, really slow. > > Then I downloaded the most recent racket-cs build. My library parsed the > same file in about 3.3s. So an *enormous* improvement. That's a big difference between Racket and Racket CS. My initial thought was that the program must have a lot of indirect function calls, and Racket CS is faster at those... but not by such a big factor. You don't use `call/cc`, right? > It's not obvious to me why my parser is so slow. The haskell library from > which it is unabashedly copied is known to be fast, and I don't think it > leans heavily on laziness anywhere. One quirk of its design: each parser is > passed a failure and a success continuation; they never return. So, on top > of all the normal function-upon-function layering that you get in any > parser combinator library, you get some extra here, since the continuations > are heap-allocated closures. A difference of 60ms/140ms versus 3.3s sounds algorithmic, as opposed to something about the representation or cost of functions as continuations. How much memory does the program use, and how much of the run time is GC time? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Scribble: is there a way to inject content from another file without creating a section?
A `#lang scribble/base` module just defines and provides `doc` as an
instance of `part`, and `include-section` imports and returns that
`doc`. That is,
@include-section["x.scrbl"]
is equivalent to
@(require (rename-in "x.scrbl" [doc x:doc]))
@x:doc
You could instead extract the part's flow instead of using the whole
part, like this:
@(require (rename-in "x.scrbl" [doc x:doc])
scribble/core)
@(part-blocks x:doc)
At Sat, 2 Mar 2019 10:48:54 -0800 (PST), Eric Haney wrote:
> Scribble's include-section is great for splitting the document source into
> multiple files. I'm looking for a way to inject content from another file
> without making a numbered section.
>
> The motivation for this is to create problem sets for my math classes in a
> way that I could keep each question with its context (diagrams, space to
> leave an answer, etc) in an individual scribble file and then compose them
> together in the main file.
>
> I guess I either want (a) some way to supress the automatic indexing and
> linking that scribble does when using include-section or (b) some other way
> of automatically fetching the content from another file like 'include-part'
> or 'include-flow'---is there such a thing?
>
> Here's what I have in mind:
>
> #lang scribble/base
>
> @title{Problem Set 1}
>
> @section{Graphing}
>
> Directions...
>
> @itemlist[
>
> @item{@include-flow["path-to-graphing-question1"]}
>
> @item{@include-flow["path-to-graphing-question2"]}
>
> @item{@include-flow["path-to-graphing-question3"]}
>
>
> @section{Short Response}
>
> Directions...
>
> @include-flow["path-to-short-response-question"]
>
>
>
> Thanks!
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] json, performance, racket cs, puzzlement, etc.
On 3/2/2019 12:24 PM, Jon Zeppieri wrote: [http://www.serpentine.com/blog/2011/02/25/cps-is-great-cps-is-terrible/] ??? OpenDNS is blocking access to that site due to some unspecified security threat. George -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Scribble: is there a way to inject content from another file without creating a section?
Scribble's include-section is great for splitting the document source into
multiple files. I'm looking for a way to inject content from another file
without making a numbered section.
The motivation for this is to create problem sets for my math classes in a
way that I could keep each question with its context (diagrams, space to
leave an answer, etc) in an individual scribble file and then compose them
together in the main file.
I guess I either want (a) some way to supress the automatic indexing and
linking that scribble does when using include-section or (b) some other way
of automatically fetching the content from another file like 'include-part'
or 'include-flow'---is there such a thing?
Here's what I have in mind:
#lang scribble/base
@title{Problem Set 1}
@section{Graphing}
Directions...
@itemlist[
@item{@include-flow["path-to-graphing-question1"]}
@item{@include-flow["path-to-graphing-question2"]}
@item{@include-flow["path-to-graphing-question3"]}
@section{Short Response}
Directions...
@include-flow["path-to-short-response-question"]
Thanks!
--
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.
For more options, visit https://groups.google.com/d/optout.
[racket-users] json, performance, racket cs, puzzlement, etc.
After the recent discussion on json parsing performance, I spent some time doing a quick port of enough of attoparsec and aeson (haskell libraries providing, respectively, byte-oriented parser combinators and json parsing) to do some testing. The result: really slow. (This is where the puzzlement comes in. I'll get back to that in just a moment.) This 1MB sample file [ https://github.com/samoconnor/LazyJSON.jl/blob/master/test/ec2-2016-11-15.normal.json] takes about 20s to parse on my machine using my aeson-alike library. By contrast, the same file parses in roughly 160ms with the json module that ships with racket. So really, really slow. Then I downloaded the most recent racket-cs build. My library parsed the same file in about 3.3s. So an *enormous* improvement. (Caveat, I'm only measuring runtime here, not compilation/expansion time.) Still, sadly, very slow compared to the existing library. So I tested the existing library on the file, under racket-cs. (Actually, I think the version that came with this racket-cs build includes Matthew's recent improvements, so it's not exactly quite the same parser.) It parsed the file in 45-50ms. That's a long-winded way of saying that: - Racket CS provides a huge performance improvement to some programs. - My parser is slw. This is the part where I express puzzlement and ask for your help. It's not obvious to me why my parser is so slow. The haskell library from which it is unabashedly copied is known to be fast, and I don't think it leans heavily on laziness anywhere. One quirk of its design: each parser is passed a failure and a success continuation; they never return. So, on top of all the normal function-upon-function layering that you get in any parser combinator library, you get some extra here, since the continuations are heap-allocated closures. Apparently, this was a big win for the original library's performance [ http://www.serpentine.com/blog/2011/02/25/cps-is-great-cps-is-terrible/], but maybe that doesn't work so well in racket. I tried profiling. It was not very illuminating, and I suspect CPS is getting in the way there, too. (It's hard to measure the time between function call and return if there is no return.) Any clever ideas on how to find out where all the time is being spent? - Jon -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Is one path a direct or indirect subdirectory of another path?
What is a portable, correct, efficient way to check whether one path is "under" -- a direct or indirect subdir of -- another path? AFAICT there's no racket/path function for this. Over the years I've done various ad hoc things that seem non-ideal. Including: 1. Use path->string and regexp. 2. Use split-path recursively. 3. Use a combination of explode-path and split-common-prefix. And either way, hopefully remember to use simple-form-path to cleanse/simplify the starting inputs. I was thinking about this again when looking at security guards recently. A file guard might want to check that the access is in/under some approved directory. This usage ups the ante on both speed and correctness. Any suggestions or advice? -- 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. For more options, visit https://groups.google.com/d/optout.
