Re: [racket-users] Proxying websockets via web-server
On Tue, Jan 14, 2020 at 8:09 PM Jay McCarthy wrote: > > As far as examples, there are some in the github repository --- > https://github.com/tonyg/racket-rfc6455/tree/master/net/rfc6455/examples Yeah, I saw them, but they're all examples of just starting a websocket server. What's missing (and it's not even clear to me if it's possible without tweaking the library code) is some example that shows what Dominick asked: serving some pages together with a websocket. This is something that I suspect is the much more common case than starting just a websocket-only server. (And I basically "solved" it by starting another webserver on a different subdomain just for this.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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/CALO-guvz_sXrMR9czAYCNBzJ8urrL7qO-gBPBd%2BoybOo-4hdgg%40mail.gmail.com.
Re: [racket-users] Proxying websockets via web-server
On Fri, Jan 10, 2020 at 9:18 PM Jay McCarthy wrote: > > I don't completely understand what you want to do. Is there a reason > you can't use the WebSocket implementation --- > https://docs.racket-lang.org/rfc6455/index.html --- and then use > normal inter-Racket communication like channels and stuff to work with > the rest of your Web application? It would be nice if the documentation for that would have some examples, but after playing with it for a bit it looks like it's broken, possibly because I don't use it properly. I keep getting errors that look like "read-request: malformed request ..." with binary goo in the error message, which usually displayed like random unicode, sometimes it breaks the terminal due to weird escape sequences. Even if I'm not using it properly, such errors shouldn't happen. And as a side note, one of the errors I saw was: exception raised by error display handler: format: ill-formed pattern string explanation: tag `~l' not allowed pattern string: "read-request: malformed request ...junk...~l...more..."; original exception raised: read-request: ... which looks like a bad error re-raising in the web server code. A quick grep finds at least one suspicious line which erroneously uses a random string as a format string: (with-handlers ([exn:fail? (lambda (exn) (network-error 'output-file (exn-message exn)))]) ... -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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/CALO-gutiuJiDFnP1md14Y9%2B1gjBLiCDtmsRSDQo%2BrztpYbRNfA%40mail.gmail.com.
[racket-users] Question for the TR people
When my pl `define-type` thing is used in drr, there are three problems that would be nice to fix: 1. In a `define-type`, the variant names are shown as the predicates that are not actually visible to user code. For example: (define-type FOO [Foo Number]) when I hover over `Foo`, the tooltip shows `(-> Any Boolean : Foo)` but that's a description of the underlying struct predicate, which is not visible. It should really show the type of the resulting constructor (which is the thing that gets bound to `Foo`). (The implementation of `define-type` is the first part of "pl/lang/datatype.rkt" in my repo, which can be seen here too: http://tmp.barzilay.org/pl/) 2. Hovering over these variant names in `cases` doesn't show any binding arrow. 3. The tooltips show the types in the prefix-ish style, and it would be nice if it used the `type-output-sexpr-tweaker` thing too to make things more consistent. Any suggestions? -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] New web page
0. Warnings/disclaimers: as usual. Things that *really* bug me with the new page: 1. The boxes on top. Pretty much what Alexis originally said (https://github.com/racket/racket-lang-org/pull/28#issuecomment-267796721) 2. More concretely, in not-so-large screens (laptop/phone), I don't know what I'm looking at. On a typical ADD-style web glance, it looks like yet another "language framework" -- the typical yawn inducing JS things, not what Racket really is. This is from "make languages". But it really doesn't look like a language: from "solve problems" (way too generic; applies just as well to smart washing machines), through the rest of the titles that are visible on the top. Perhaps the only real clue that it's a language is "The best of Scheme and Lisp" -- and IMO/E that's not a great motivation... 3. Even on a large screen, the pictures seem to go out of their way trying to make me think that this is something related to graphics. 4. The whole business with the boxes becomes *MUCH* worse when viewed in a text browser. You get all the boxes text, and much later the blurb that says what it actually is. It pretty much looks like a kind of a quasi-random word cloud, all the way to the latter part that looks more organized. 5. "Who cares about text browsers?" -- Consider that they can reveal other problems, for example, the (oddly placed) main blurb text is shown as a list item with one of them. More severely, one of the very good points about trying a text browser is that you get to see the page as a search engine sees it. I initially thought that this must be bogus advice these days... Turns out it's not: when I search for "Racket" here's what google tells me about it: > Racket is a mature LGPL project that's actively developed and > maintained. Racket repositories. Main repository. The PLT Group. IMO, this is a *MAJOR* failure of the new layout. 5a. Google also makes a mess in the quick links that it infers for the site. 5b. For fun, I tried the other search engine. It's similarly confused -- here's what it says: > Racket’s crown jewel is its macro system, which lets you > freely extend the language. Intro to macros; Macros in depth; > Racket syntax model; Making new languages 5c. Yet another reason for using a text browser is accessibility. I tried the chromevox thing, and it just reads out what's on the page, top to bottom. It doesn't read the text hidden in the top boxes so it's not as bad as a text browser, but it's stil far, far from good. 6. Gray text. [IMO the universal default of black text on white background was a colossal mistake propagated by the misguided idea of making computer screens look like printed text -- and for years I thought that this was so bad that there's no way it could be worse. Then came the style of gray-ish texts and proved me wrong.] AFAICT, the only black text in the whole thing is the first "Racket" word. Section titles on the bottom part look like they should be black too but the font is thin enough that there are very few pixels that are actual black. Yes, I've seen some justification about gray being a common de-emphasizing tool, but in that case I look at the text that I would read if I ignore de-emphasized text, and that says "Racket, Software, Documentation & tutorials, ...". ObYoutube: https://www.youtube.com/watch?v=Excu14T7IxQ 7. "the world’s first ecosystem for developing and deploying new languages" -- This reads to me as a huge exaggeration. Wouldn't Lex/Yacc fit this description? Actually, an OS (Unix, specifically) could make this claim too. On the flip side, "enterprise people" probably read this as something that better fits what Visual Studio, or some JS thing like Esprima is doing. To put this differently -- IMO the thing that makes Racket unique is exactly the *opposite*: I don't have to "develop" a language, I can just dig around through my back back for a paper clip and some used gum and slap up a language, and then I most certainly *don't* need to "deploy" it! -- IMO, that's kind of the main sentiment whenever Matthias talks about making languages so easy that you can make a language for a single use -- again, the opposite of common thinking where a "language" is something so heavy that it doesn't make sense to not deploy it in some way. 8. Finally, phone rendering makes the above problems even worse. But in addition, it is still broken (for me, on a Nexus 6p using chrome): http://tmp.barzilay.org/x1.png http://tmp.barzilay.org/x2.png Both have overlapping texts, and the first one has a strange n
Re: [racket-users] Re: If a thunk is a proc of zero arguments, what is a proc of one argument?
On Sun, Nov 13, 2016 at 6:48 AM, Ian Barland <ibarl...@radford.edu> wrote:
> [...]
>
> Also, in this particular case, my chafing at the extra-characters was
> ameliorated by a tip from Eli Barzilay: drop the space after the "λ",
> e.g. `(λ(n) (+ n 1))`. It's still quite readable, and whittles away
> at the character-savings the other macros are providing.
BTW, for anyone who has a bad rection to the removal of the
holy-space-before-a-"(" -- it's not a random droppage of a character to
get things to be shorter... It's based on an idea from my thesis, where
the binding name is considered part of the syntax of the term. So in
that view "(x)" is actually part of the "λ" which clarifies that the
holy space there is not so holy since the "()"s are just a grouping
device and not a proper subform.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] Building regexen in at-exp
On Fri, Oct 28, 2016 at 3:18 PM, David Storrs <david.sto...@gmail.com> wrote:
> tl;dr : Why is the following an error?
>
> #lang at-exp racket
> (define a "this")
> @pregexp{^@a} ;; Should produce #px"^this" but errors out
> @pregexp{@(~a "^" a)} ;; This works but is clumsy
I see that the problem was pointed to you several times, but I didn't
see suggestions for a convenient replacement. I often have something
like this:
#lang at-exp racket
(define px (compose pregexp string-append)) ; <--- like this
(define a "this")
@px{^@a} ; works fine, and looks like a variant of #px"..."
[[ You can also do this for a one-time-use:
@(compose pregexp string-append){^@a}
but that's almost as bad as one of
@pregexp{@string-append{^@a}}
@pregexp[@string-append{^@a}]
(pregexp @string-append{^@a})
]]
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] docs for string-trim
On Wed, Nov 2, 2016 at 12:29 AM, Ben Greenman <benjaminlgreen...@gmail.com> wrote: > The trick is that 'whitespace' isn't just #\space. It's any sequence > of whitespace characters, like "\r\r\r" or " \r\n\t" ...and this happens because the default `sep` is a regexp, not a plain string. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Handin Issues
On Tue, Oct 11, 2016 at 9:35 AM, <matt...@udel.edu> wrote:
> Thanks for your detailed response!
>
> I do have the following additions at the top of the file:
> (add-header-line! (get-submission-timestamp))
> (add-report-line! (get-submission-timestamp))
>
> So would this mean there isn't an issue with back-end but rather my
> checker.rkt file?
Yeah: you cannot add header lines when the submissions are not converted
to text, because there's no functionality to modify the rich media file.
But it would be better if the checker would complain about an invalid
configuration instead of failing when the text file is not there --
which is the change that I suggested. This way you'd get a readable
error message telling you what's wrong instead of tracking the problem
youself.
> Would it be possible to link some example handin servers on a
> github/bitbucket/or even the racket website (particularly a
> checker.rkt file)? I think my main issue is there are alot of
> configurations that require particular details and I may miss some
> important documentation. I could help contribute a checker.rkt for my
> purposes after I get it fully working... [...]
(Unfortunately, most of your *real* issues are more high level problems
with how to handle submissions with images, how to test them, etc -- and
that's something that personally I have no experience with...)
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] [off-topic] any thoughts on gradescope?
On Tue, Oct 11, 2016 at 9:06 AM, Jay McCarthy <jay.mccar...@gmail.com> wrote:
> It looks neat. I've done similar things to Eli many times as well.
>
> https://github.com/jeapostrophe/grade-ninja -- Had the whole "give a
> free-form comment" or click a button to give the same feedback again
Yeah, I do have a GUI-kind-of thing too, hacked in Emacs... The idea is
that I choose from a number of pre-made comment+grade entries, and it's
easy to switch them as I go from one question to the next.
> https://github.com/jeapostrophe/grade-samurai --- Expanded that with a
> Web UI for students and gave more explicit rubrics plus a self-grading
> step followed by a professor review
>
> Now I'm going to make a new one similar to the previous two where the
> students host their work on their own Git repos.
My main problem is getting a text file with the comments embedded in,
following a specific format. If you get something generic enough it
would be cute.
But the main thing is that just doing the grading electronically is
pushing things in the right direction...
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] [off-topic] any thoughts on gradescope?
On Mon, Oct 10, 2016 at 11:14 PM, 'John Clements' via Racket Users <racket-users@googlegroups.com> wrote: > Sorry, this is totally off-topic; this is the second time I’ve heard > of gradescope.com, and it looks like it might actually be > useful/interesting. It might also be a sleazy scam site that I wind up > hating. Most of the educators whose opinions I respect most are going > to get this message; do any of you have opinions on gradescope? Sorry but this is a bit more off-topic... I haven't used this thing, but it makes a lot of sense to use something similar -- which I've been doing manually for ever: the idea is to have a fixed format for comments that include grades (or grade penalties), and that makes it natural to keep a file in a separate window with some pre-made comments and their grade (or penalty), and after a short while you have such comments for most cases. The missing feature is being able to update a number and have it reflect in all files, but if the format is fixed and comments are copy-pasted, then it's easy enough to change grades with a quick grep. It makes sense enough that many of my graders quickly pick it up. So it makes sense to me to automate this, but I wonder if they have a good way to do that with consuming text files, adding comments, then getting the graded versions without sending students to a different site. Also, in many cases I'll adjust penalties based on the number of other problems you have in the same question. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Handin Issues
On Thu, Oct 6, 2016 at 10:08 AM, <matt...@udel.edu> wrote: > So, I've been playing around with the handin server these days. > > My purposes of the handin require students to submit images using the > htdp image and universe libraries. > > First, I would like to note that for the images, you must turn off > textualization/create-text in your checker: > > (check: >; Get timestamp of the submission and add it to header and report ([*] Is there some code that does the addition described here?) >:language 'racket >:requires '(bsl-plus-image) >:create-text? #f >:textualize? #f > > My issues follow: > > 1) Initially, there is a conflict with one of the image functions and >[...]) (I don't know about these issues...) > 2) Afterwards, there is a permission denied error: > [2|2016-10-06T09:49:28] ERROR: Error in your code -- > [2|2016-10-06T09:49:28] file-exists?: `exists' access denied for libobj.dylib > [...] > As of now, I expose my path. I'm not sure how to create a better > solution than the one mentioned stating to add the following lines at > the top of your checker.rkt The "/" in the additional setting is a path, and the `read` allows reading any file under that path. So instead of "/", just use a path that includes only stuff that should be OK to read, including the "libobj.dylib" file. (I don't use OSX so I don't know where it is.) > 3) Finally, I found a very serious issue in the collection's handin >server code. students are not able to submit because of the server >was trying to write to a grading/text.rkt even though I specified >not to! I've traced the issue to the collection's handin server. > > From (collection-path "handin-server"), > > /Library/Racket/6.6/pkgs/handin/handin-server/checker.rkt: > > Starting around line 467 the below code is the culprit! > Essentially, at the bottom of the below segment, regardless if you > checked if you were creating a text file in your checker.rkt, it will > attempt to write the text with the below code: > (when (thread-cell-ref added-lines) (write-text)) > > Essentially, to fix this issue, you may replace it with > (when (and (thread-cell-ref added-lines) create-text?) (write-text)) That does look like a bug, but I think that a proper solution would make `add-header-line!` throw an error if there is no textualization happenning, except that getting the textualization flag there might be tricky, so a bit hackier solution is to make the code that you're talking about throw an error, so instead of (when (thread-cell-ref added-lines) (write-text)) it would be something like (untested): (when (thread-cell-ref added-lines) (unless create-text? (error* "bad checker: no text created, but header lines added")) (write-text)) This is better than what you're suggesting, which would silently ignore the added lines. If you do have some code that adds header lines (my [*] question at the top) then that's the problem, and the error should be a configuration error. (The thing is that additional headers are written to a generated text file -- there's no code that edits the student's media-format submission file.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] udelim package -- more parens than you can shake a stick at
On Mon, Sep 26, 2016 at 9:40 AM, Matthew Butterick <m...@mbtype.com> wrote: > > T as in "text": > > @-form => T-form > @-expression = > T-expression (or t-exp in shorthand) (Or "Texprs"...) > #lang at-exp racket => #lang t-exp racket > > #lang scribble/text => #lang t-exp/text > > #lang scribble/html => #lang t-exp/html > > Keep the old @-names for backward compatability of course. That sounds pretty good -- it follows the original intention of these being a convenient and uniform syntax for "text-rich expressions". That's if there's enough collective will-power to change it now... On Mon, Sep 26, 2016 at 11:34 AM, Greg Trzeciak <gtrzec...@gmail.com> wrote: > IMHO the "text expression" does precisely the same as current use of > scribble -> pigeonholing the syntax for one use: in the case of > scribble it is "documentation" in the case of text - "text > processing". It's fine for just "text", without the "processing" -- since the idea does revolve around text in code in all kinds of way.s > - You can place the expression "AT ANY PLACE inside your text or code" > - Expression is identified by the selected identifier "AT THE FRONT of > the expression" -> default @ > - With at-exp the function is "AT THE FRONT followed by > brackets/braces" > Ok maybe stretching it a bit but each to their own. Yeah, I think that this is stretching it... I think that it's perfectly fine to stick with "@" or "at" for historical reasons, but the confusion is certainly there, and that's not new. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] udelim package -- more parens than you can shake a stick at
d.
(Ha! The idea that $... behaving in different ways is *reducing*
complexity is amusing. Really.)
> So I'm not saying I want a different @-like character for each level
> down, but rather that I don't need any @-like character in the general
> case (just string delimiters, either normal or preferably nestable),
> and for rash in particular I want a magic character that does
> something different than what the @-reader magic character does.
The point is that "@" does the same thing at *all* level, including the
toplevel. It's *reducing* magic to an expected reader behavior. You're
nested strings -- at each level -- need some magic that *will*
eventually lead to parsing that string, leaving it implicit makes it
magical and not in a good way!
> And as for a $ escape character in a shell language syntax being
> confusing, I think that is maybe the most natural shell syntax choice
> I've made for rash for anyone coming to it from bash.
(As a side note, I ended up going back to intense shell scripting at my
$DAY_JOB. I *know* shell scripting. I've been doing it for a while. I
know people who *know* shell scripting. There is nothing natural about
them, *especially* around anything related to $-interpolation. Quick
example: I just recently found out something new about "..${a#$b}.."
which I was confused about, partly because of how it's different between
zsh and bash. Once you find out the difference between the two, you
will not be able to use "$" and "most natural" in the same syntax.
(Shell programming should come with an achievement system: as you write
a shell script, if you get to the dreaderd '"'"' quotation of ' there
should be some happy music and you get a master quoter badge. When you
write an expression that gets your editor to mis-highlight the quoted
and unquoted parts (as done with that ${a#$b} in bash and Emacs) you get
another out-of-mainstream-quoter achievemnt.))
> No, I *definitely* want rash and rash/out to be macros. I don't want
> to do any runtime parsing and evaluation for them. My current rash
> macro is perfectly capable of having runtime variable references
> inside the syntax that is nested in a string -- they all become syntax
> objects within the context the string was in (there are examples of
> this in the rash docs).
Yes, I see that. I assumed that you wanted both
(rash "blah blah")
(let ([x "blah blah"]) (rash x))
to be the same, mostly because you said how much you didn't want nested
@-forms. I see what you mean now, which is, like I said, pretty much
exactly what you get with @-forms. (BTW, note how @-forms are perfect
here: since `rash` should always be used with a string input, it ends up
having a single set of delimiters instead of the two that are obviously
redundant.)
-=- -=- -=-
But I'm guessing that I lost you again, so none of this would move you.
All I can do at this point is sigh and hope that you'll end up at the
best case of re-implementing @-expressions with the slightly more
verbose syntax that you want. The worst case will be ... well, much
worse.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] udelim package -- more parens than you can shake a stick at
On Sun, Sep 25, 2016 at 2:19 PM, Matthew Butterick <m...@mbtype.com> wrote:
>
> On Sep 25, 2016, at 2:10 AM, Eli Barzilay <e...@barzilay.org> wrote:
>> *Don't* confuse scribble-the-documentation-system with the syntax --
>> the syntax is useful for many other cases, and designed to make sense
>> in other cases. See my description (specifically section 4, which is
>> very relevant here), and the scribble/text and scribble/html
>> languages.
>
> To be fair, the documentation invites this kind of confusion. All the
> material about the at-reader is within the Scribble docs. This makes
> it look like it's dependent on Scribble, when really it's a separate
> thing.
Yes, I know, and yes, it could very much use a restructuring.
> In general, I think the word "Scribble" is misleadlingly overloaded
> within Racket. IMO "Scribble" should refer only to the family of
> languages that use the Scribble document model, including Racket
> documentation.
Well, it started with "scribble" being the name of the syntax, which
came first. Then Matthew built the documentation system on top of it,
and that was also named "scribble". When we realized that this is going
to be confusing, it was already clear that the latter meaning is already
"winning", so the syntax turned into @-forms, @-expressions etc -- I'm
probably the only one who still uses the first meaning from time to
time. And yes, that's not a good name since it can be customized too,
but I don't see a good way out of it...
> At some point the docs for "Scribble as a Preprocessor" were broken
> out from the main Scribble docs — I'm guessing to emphasize that
> they're conceptually separate from Scribble. But AFAICT what they
> really have in common is the at-reader, not the document
> model. Because they don't use the Scribble document model, I'm unclear
> why they're called `scribble/text` and `scribble/html`.
That also made more sense in the early days, since `scribble` was
supposed to be the place for all scribble (the syntax) related things.
> Meanwhile, I'd argue that the at-reader — itself an obsolete name,
> since one can swap out the @ for any Unicode char — deserves to have
> its documentation broken out into a separate top-level section, which
> would more accurately reflect its status within Racket.
At some point I intended to take the paper I wrote about it and make it
into a separate documentation about the syntax, but I never got to
actually do it.
> + String splitting within {...} delimiters: I agree this is the right
> default behavior, but it doesn't seem unreasonable to wish for
> shorthand for when you really do want things concatenated into a
> single argument, given that Racket is full of cognates like
> let/let*, for/for*, list/list*, etc. That said, I don't have a good
> idea what the notation would be.
For plain single-string use, I always encouraged using
`@string-append{...stuff...}`, but since this is horribly long, some
simple shorthand like (define ~ string-append) can be used. For cases
when you want to look at the result of some @-expression as a single
value but not pay the huge price of accumulating intermediate strings, a
plain old `list` does fine -- and that's what `scribble/text` is doing.
With that, it's very useful not only to @list{...stuff...} but also to
just quote it with '@{...} -- or the equivalent @'{...}, and, of course,
everything that comes out of throwing @`{...} into the mix.
> + I wish at-expressions could use multiple [...] and {...} parts, in
> any order.
Yeah, I considered it at some point, but decided to go with a more
restricted (but maximally useful) syntax to avoid possible problems and
maybe extended it later when needed. The idea of what we ended up with
is that you can always tell where the @-expression ends by looking at
the {}s, or putting them yourself to avoid getting things mixed up with
the following text.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] udelim package -- more parens than you can shake a stick at
ing a Racket runtime binding that gets used at the syntax level if you want to stick with `rash/out` doing its parsing as a macro implementation -- that's a problem that is inherently there regardless of concrete syntax. But the scribble syntax provides an easy way to handle this: you just need to define `rash/out` as a function (so do the parsing at runtime), and the result plays much nicer with any language it's used in. > I'm a little hard pressed to come up with examples I haven't thought > of remotely concretely yet, but it seems to me that it's much easier > to have these sort of #lang-embedding macros that do their own reading > if you just have a simple string. At this point I'm guessing that you'd still not be convinced. So maybe phrase this as a challenge: see if you can come up with an actual example where the scribble syntax won't do what you want, or examples that you're not sure how the scribble syntax would look like. Maybe doing this will lead to further enlightment. (Feel free to email me such examples off-list.) > I'm really sorry if my initial mail came off as offensive or > aggressive against the at-reader, because I really think it's great. > It's just that it doesn't seem to be the tool best suited to my > particular need, [...] I'm not trying to defend the scrible syntax's honor -- I'm only trying to show you why it solves your particular needs too... As a long postfix comment, the personal angle here is that I've been obsessed with such problems for a *very* long time. At some point I've had a system that I'm guessing would interest you: I've basically made a language where <<>> would delimit meta-level text to be run and its output used instead, then I made it so each of these could specify its own language so something like <> would run in a tcl interpreter (it was before python became popular), and you could nest any number of levels (using a different language in each). I've used some shreds of that years later in mzpp which is a much more simplistic language, and closer to a traditional template system. And since you've mentioned changing the "@" character at every level, I've also implemented something on that side of the spectrum -- mztext -- where the resulting language is more tex-like where you can do arbitrary parsing at each nested level down to changing how "functions" are written and arguments are parsed, and (just like tex) the result is pretty powerful in what it can do, but nobody ever needs that complication which makes the whole thing useless for practical purposes. The scribble syntax is the last thing I had in that long list of experiments which finally made sense at all levels, and was both something that was easy to understand yet flexible to express any of the complicated needs. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] udelim package -- more parens than you can shake a stick at
to be able to nest the string *delimiters*, than any string delimiter pair that is not using the same character will do... but more importantly I don't see any cases where you would want *that* but not the rest of the scribble syntax features. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] handin server error
On Wed, Sep 7, 2016 at 11:52 AM, Spencer Florence <spen...@florence.io> wrote: > This is a little bit of a hack and weakens the handin server security Your suggestion is pretty bad in that it's more significant than it looks. With it, you're allowing submission evaluation to read all files on the handin server. You should at least replace the "/" path with the system path that has the required libraries. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Racket Shell
On Mon, Aug 22, 2016 at 12:59 AM, William G Hatch <will...@hatch.uno> wrote: > I've looked over the scsh docs at various times, though I've never > actually used it -- it's never been pre-packaged for distros I've > used, and every time I've tried to build it I've run into errors. > Perhaps I should try again. As far as the process syntax goes, a > little bit of macros over my pipeline library should be able to get > you something pretty close. I'll probably do that later. There were some problematic points with the scsh macro -- something around the implicit backquoting that made things not compose nicely. I think that this was what Mike Sperber told me at some point. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] HTTP Headers use byte->string/utf-8
On Fri, May 6, 2016 at 11:49 AM, Tim Brown <tim.br...@cityc.co.uk> wrote: > > 1. I think Eli points out in issue where \277 and \276 are not ci=? >to each other. No -- my comment there is about \277 and \277 (itself), which are neither `bytes-ci=?` nor not because the implementation assumes that the two bytes to compare are both in utf-8 and therefore we get an exception instead of an answer. The source of the comment is that this was (I think) at some point in unstable, as a candidate to move to racket/bytes (hence my comment about the memory requirement, which is relevant in that context). [BTW, looking at that SO answer and the RFC it seems to me that latin-1 is wrong too for the values, which should remain opaque...] -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] opinion needed on best fix for handin-server problem
On Wed, May 4, 2016 at 5:36 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users > <racket-users@googlegroups.com> wrote: >> >> IIUC, it sounds like both you and Sam are suggesting the same >> thing. I think this *could* cause backward incompatibility for the >> *probably empty* set of handin checkers that use tests for >> non-transparent exceptions, but I’m happy to make this change if it >> makes sense to you guys. > > But don't those programs break now, with the error that led you to > originally start this discussion? [FWIW, yes, I'm completely with Sam -- including this confusion.] -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] opinion needed on best fix for handin-server problem
On Wed, May 4, 2016 at 5:12 PM, John Clements <cleme...@brinckerhoff.org> wrote: > > So, I’d say this is basically an ergonomics issue. If we change this > code to raise a new exception, then it might potentially confuse a > handin-server-checker-writer, who expects (e.g.) to see a > ‘exn:fail:contract:variable?’ but actually gets back a > ‘exn:fail:handin-server?’. IIUC, clear documentation could resolve > this. I have no opinion on breaking backward compatibility on expectations of user-code (I might have some but I can adjust), but things like `!defined`, `!bound`, and `!syntax` should definitely continue working -- and it seems worse to fix them by looking at the exception message. Another option to fix it would be to make it keep doing what it does now if the exceptions are transparent, and switch to some wrapper exception otherwise. This way you're only breaking hypothetical code that expects exceptions that make it fail now anyway, IOW -- there's no breaking... (And also document the fact that not all of the builtin exceptions are transparent, unless it's already done somewhere.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] opinion needed on best fix for handin-server problem
On Wed, May 4, 2016 at 1:14 PM, John Clements <cleme...@brinckerhoff.org> wrote:
>
>> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
>>
>> That seems fine, but the general approach the handin-server is taking
>> seems wrong to me. If it wants an exception with a different message,
>> it should just create that, rather than assuming that all exception
>> structures are reasonable to modify.
>
> Well, I can certainly do both.
>
> In general, perhaps the right solution for the handin server would be
> to deliver an exn:fail:handin-server with an additional field
> containing the original exception. That way, no information is lost.
>
> The danger, of course, is that this might break code that depends on
> the exception satisfying some predicate (the filesystem and network
> exceptions are the ones that worry me). Perhaps Eli can comment on
> this?
TBH, I have no memory of this -- and looking at the code (I'm assuming
it's the `reraise` bit in `wrap-evaluator`??) I'm not sure that I wrote
it.
[...Doing some archaeological digging...]
OK, I think that the following is everything that I can say about it,
and let you judge what would be the best way to re-solve it. I think
that the main thing that changed that you're talking about is Matthew's
comment that "All the built-in exn structs are fully transparent,
though". Also, there's the motivation for doing this: "It's important
to keep the same exception, because ...". (And both of these might be a
justification to make it transparent, or to fix it in a different way
that makes the "because" thing work, and maybe make a note of the lack
of transparency somewhere; I have no significant opinion about it.)
So -- assuming that function is the right place that you're talking
about, I see that this is code that I committed in:
> commit fd858f081c564a3c94a682aee5896bc535fd9956
> Author: Eli Barzilay <e...@racket-lang.org>
> Date: 2007-01-24 07:52:51 +
>
> removed the tweaker hack for a solution that creates a new exception
>
> svn: r5446
and it removes a simple hack that uses a `current-error-message-tweaker`
("tweaker" is surely mine...) and adds instead the code that assembles a
new exception.
I then did some more digging in my mail, and found this email exchange
between me and Matthew about this:
[Eli]
> For some corner of the handin server I wanted to capture exceptions,
> then reraise a modified version of the exception (basically turn any
> exn to one that has " while evaluating ").
> It's important to keep the same exception, because some tests rely
> on it (like catching an `exn:fail:contract:variable?' when testing
> for a bound identifier).
>
> Looks like `copy-struct' is not enough, because it wants a struct-id.
> Is there some easy way to do that? (I know that it's possible,
> because I did similar stuff in reflecting mzscheme structs as swindle
> classes, but I'm looking for a simple solution.)
[Matthew]
> If you have a sufficiently powerful inspector, then `struct-info'
> and `struct-type-info' let you do what you want, and that's the only
> possibility that I see.
[Eli]
> Does the code below look reasonable? -- I'm using struct-info just
> to make sure that struct->vector does return all the field values.
> (I think that this code will break with auto fields, but it should
> be fine with the exn hierarchy.)
>
> (define ((make-chatty-eval eval) expr)
> (define (reraise exn)
> (raise
>(let-values ([(struct-type skipped?) (struct-info exn)])
> (if (and struct-type (not skipped?))
>(let ([vals (vector->list (struct->vector exn))])
> (apply (struct-type-make-constructor struct-type)
> (string->immutable-string
> (format "while evaluating ~s:\n ~a" expr (cadr vals)))
> (cddr vals)))
>e
> (with-handlers ([exn? reraise]) (eval expr)))
[Matthew]
> Looks fine to me.
>
> I don't think the use of `struct-type' ensures that `struct->vector'
> returns all the fields. The immediate struct could be transparentand
> the next one opaque. All the built-in exn structs are fully
> transparent, though.
[Eli]
> OK -- so I thought that a proper solution would be to check the
> chain up the all the way (and just mention that in a comment in case
> someone uses this code), but then I realized that there is a much
> simpler way: simply define a local unique value, hand that as the
> second argument to struct->vector, and make sure that the unique
> value is not a memq of the
Re: [racket-users] How can I differentiate between a here string and a "" string?
On Wed, Apr 20, 2016 at 8:46 AM, Tim Brown <tim.br...@cityc.co.uk> wrote:
> Thank you for that suggestion. However, one of my motivations for
> using here strings is that they are inherently dumb. As long as I
> avoid the terminator at the end of my line, I can bosh characters into
> it without fear or favour. at-exp are on the other end of that
> dumb-smart spectrum; for example I have often been caught out when
> importing something with an email address within!
There is definitely explicit intention to cover the "dumb end" too:
@list|!!!<<<===---===<<<###{
foo
}###>>>===---===>>>!!!|
There's no requirement for a new line though since it's also intended to
live nicely in code too -- rather than the usual butchering of the
visual layout you get with here-strings. But if it's just emails that
bug you, you can switch from the "@" character to something less
problematic (up to the pollen way of using a unicode diamond).
> I expect an algorithm to determine the position of an error in a smart
> string (and I guess that even includes "" with its backslat escaping)
> to be harder than that in a dumb one. So I’m probably going to stick
> with a bit of arithmetic with the here string.
The @-forms are intended to make this easier too. Besides a syntax
property that identifies these forms you also get information about
which parts were the text (the {...} contents) and which were not (the
[...] stuff), each line ends up being its own string *and* it will have
its proper source location, and newlines will have indentation
information in case you want to depend on that too. So if you want, for
example, the line number, then it's much easier with the @ syntax.
(All of the above works fine with nested @-forms (which will break a
line where they appear) and @-comments too; but it sounds like you
*don't* want to ever leave the string world once you get in it.)
> I’m just surprised that, with Racket being touted as a programming
> language laboratory language, nobody has had to figure out where a
> syntax error lies within a string.
One of the main goals of the @ syntax was to make concrete-syntax-level
experiments easier instead of resorting to the much more complicated
problem of implementing a reader macro or your own parser.
[That last bit -- avoiding a parser -- is intended to be done by *using*
nested @-forms instead of rejecting them, so you get a mixture of
hopefully-easy-to-parse bits of text with nested expressions, so the
result is easier (in the S-expression sense) to handle than a monolithic
pile of text to parse.]
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] state of known issue: running handin server without x display
On Mon, Apr 18, 2016 at 5:56 PM, 'John Clements' via Racket Users
<racket-users@googlegroups.com> wrote:
>
> It seems like the right way (well, *one* right way) to fix this, then,
> would be to install a stub gui/main.rkt in “overridden-collects” that
> uses a textual approximation to extract text from the transmitted
> documents. Is that right? If so, has someone already written this? And
> if *that’s* so, is there some way that I could add a pointer to it to
> the documentation somehow?
`overridden-collects` was supposed to be a place for putting modules
that would get used in sandboxed evaluation of submissions ("was"
because AFAIK it was never really used), so that's not the way to do
this.
(But it will definitely be nice to break the need for X somehow...)
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] quoting in posts to this email list
On Thu, Apr 7, 2016 at 12:13 AM, Neil Van Dyke <n...@neilvandyke.org> wrote: > I suggest that people posting replies to posts on this email list try > to *minimize* quoting of the previous post(s). I've always had some text in my class about proper emailing, including this. But it's a lost fight. After N years with students just ignoring it (not to spite, just because they never remember it) I now see blank stares when I talk about it. Gmail managed to entrench top-posting to the point that they don't even know what I'm talking about. In an ideal world people would never quote thing unless it's really short, and your email client would have a little button that shows you the previous context when you need to instead of including it with every new email -- and I'm guessing that many people actually think that this is what happens. (All of that is related to the twitching you undoubtedly do whenever you get a bugreport with a jpg holding a screenshot just to show you a 40-character error message. A sign that you're a dinosaur. (I'm guessing that it won't take long for these emails to switch to a video capture of the error happening.)) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Modernizing scribble/html
On Fri, Apr 15, 2016 at 3:50 PM, Jens Axel Søgaard
<jensa...@soegaard.net> wrote:
> Hi All,
>
> The library scribble/html paired with at-expressions provide a really
> nice way to write html:
>
> @html[@head[@title{This is a title}]
> @body[@h1{This is a header}
> @p{This is a paragraph with text}]]
[FWIW, I had long planned to play with a mixture of this and markdown,
and not too long ago I finally hacked something that does this (using
cmark as a library) -- so for some elements the textual contents is
going through MD rendering where the MD text can itself have elements in
it. I've converted my whole class contents to using it. They
implementation is a bit hacky, but the resulting combination of at-forms
for the complicated things and MD for the text stuff is extremely
convenient.]
> The library represents html as structures. Each html element type has
> its own Racket structure.
That was intentional -- I disliked sxml/xexprs since I generally found
it way to easy to make mistakes with both of them (in a similar way to
other cases where sexprs are used as a catchall tool for representing
everything). I thought that using structs would be more robust both for
writing html and for holding representation of xml-like data. (And BTW,
exposing the structs more is definitely a good idea.)
> The simple solution is to take the elements from
>
> https://www.w3.org/TR/html/index.html#elements-1
>
> and add them to scribble/html.
>
> Is the simple solution also the right solution?
I've replied on GH (https://github.com/racket/scribble/pull/39). In
particular see #3, #4, and #5 -- I think that it's better to add stuff
in new modules, one for html4, one for html5, and then more for ones
that are more involved like svg and ruby. And also drop some of the
html4 exotic stuff that is ancient or deprecated or both. (Which makes
the exclusion of `map` seem natural instead of a problem, and push it
out to the html4 bindings only...)
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] DrRacket Coverage
On Tue, Feb 16, 2016 at 7:56 AM, Greg Hendershott
<greghendersh...@gmail.com> wrote:
> FWIW when you run tests with coverage in racket-mode (C-u C-c C-t)
> displays in the echo area either "Coverge complete" or "Missing
> coverage in N places". In the latter case, point moves to the first
> place. All such places are colored in red.
>
> One thing racket-mode should probably also do is have next-error to
> jump to later spots (if any). However I figured people would add
> coverage one spot at a time, so it didn't seem super compelling.
Actually, this is another idea: the coverage facility tweaks the code
anyway (through errortrace), so it can also add an expression at the end
of the `test` submodule that throws an error with sources pointing at
all of the uncovered expressions. It's more extreme, but it makes many
things work automatically -- for example, the handin server won't need
to explicitly check for coverage, just run the code and throw any errors
back to the client...
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] DrRacket Coverage
Re leaving the coverage colors: for the purpose of my class that would do fine, but for actual use, the lack of full coverage indication means that you'll need to scroll through the text to find out if you have it or not... So something like a status bar message would be better, either with leaving the coverage colors or not. Even better if it "jumps up" as John said, so that it draws attention to it. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] DrRacket Coverage
On Sun, Feb 14, 2016 at 5:06 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > Can you explain the use case a little bit more, please? This is the > *SL languages? No, a plain #lang with the syntactic code coverage enabled. > They run their program, they see black/orange, they add tests, they no > longer see black/orange, and they are confused? Yes exactly -- and that's after I mention it in class and describe it in the course pages. > Did they not understand what black/orange means or were they expecting > entirely black? I think that by the time they work hard to cover everything and the coverage colors disappear they quickly jump to a conclusion that something is wrong. -- I even have the server report to them about uncovered code, but even that doesn't help. In case it wasn't clear -- this is not too important, just something that strikes me as weird every time another student gets confused. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] DrRacket Coverage
Every semester there are always students that think that DrRacket is broken when they add tests and the coverage colors go away. I now tell them about it in advance (in class and in text), but it's still confusing people. So in the spirit of phone apps which teach you about themselves, how about something like a dialog popping up when coverage is enabled, and there is a non-trivial program, and there's complete coverage. Something like a short explanation of how the colors are the same since your code is completely covered, with a "got it" button to dismiss it. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] splicing conditional results in the surrounding block?
On Fri, Feb 12, 2016 at 10:45 PM, Nota Poin <notap...@gmail.com> wrote: > > at-exp really is a fascinating language, It's not a language in itself, it's a meta-language, which modifies the actual language with the @-form syntax. > but if a (flatten) isn't any more computationally expensive, you can > just splice all the lists at the end and use the regular racket > language. Either way would work fine, I suspect. This sounds confused. The purpose of the at-exp language is just to make it easier to write code with a lot of text, which is what you do. The scribble/text language that was mentioned is based on the same @-form syntax, and it adds the functionality of outputting strings (and other primitive values), with lists being scanned recursively (so it's essentially flattening everything), and it outputs nothing for #f and void, which makes it easy to embed `and`s and `when`s without the usual gymnastics involved in splicing the results back into a single-level list. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] using TR in PL class?
On Tue, Feb 9, 2016 at 11:01 PM, 'John Clements' via Racket Users <racket-users@googlegroups.com> wrote: > I’m running a fairly vanilla pre-pyret PLAI class, using the > plai-typed language. Has anyone looked into doing this using Typed > Racket? *cough* A long, long time ago, and still going. > I feel like my interactions with TR have gotten sufficiently smooth > that I might try using it for my PL class. +1, but IIRC, the plai-typed language is an HM thing, and therefore students have a bit more to learn when they use TR. But², IME this is not a big problem, at least not in my case since they're not used to any proper typecheckers. So, other "IME"s (which are all at varying levels of subjectiveness): > Potential problems: > > - mismatch with PLAI (though I’m already using an out-of-date PLAI > because I’m not using Pyret) My class diverges from PLAI (the pre-pre-whatever version), in some places significantly so. Things like laziness (where it had a kind of shallow haskell tangent), macros (which weren't there in a deep way), typechecking (IMO, it really needed some code to match the rest), continuations (way too little code), and of course some lambda calculus (if only to let students get some fun and some bragging done when they're done). With all of these, diverging from the language of the book was never a big point for me... > - loss of the wonderful define-type form. That was the very first thing I added -- in a proper ML-ish way. Actually, I added it before TR existed, and later converted it to TR. I still hope that at some point in the future the whole thing can be folded into TR (but it sounds like that's still not getting close). > - potentially baffling error messages. TBH, TR had some horrible errors too, but it had generally gotten pretty good. To the point that students no longer assume that the language is broken when they have a bug. > Potential benefits: > > - *much* richer libraries available without the use of typed-in. > - exposure to occurrence typing, a pretty nifty type system. +1; and it has a benefit of providing at least one different point when you get to talk about types. > - don’t have to explain the (quite painful) s-exp wrappers > - getting to use ‘match’ — better than plai-typed-s-exp-match because > you get binding as well as matching I do use `match`, but that's in addition to my `cases`, which tends to confuse students. (And see above.) > - somewhat better documentation (students always get hung up on the > plai-typed docs. yes, they just need to click on the *second* link…) And I have some issues there too, since I simplify / restrict some types in my language(s). > Opinions? Yes, I admit that I’m not giving Pyret a fair shake, and > I’ll admit that most of that is related to my commitment to Racket. (A general +1 about that too...) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Simple regex question. How to match this: "[X] foo"
On Sat, Jan 9, 2016 at 9:44 AM, Alex Knauth <alexan...@knauth.org> wrote:
>
>> On Jan 9, 2016, at 1:38 AM, David Storrs <david.sto...@gmail.com> wrote:
>>
>> Related question: Perl has a capacity to change your delimiters on
>> regexen in order to avoid having to backwhack everything.
>
> [...]
>
> And you can do this:
> #lang at-exp racket
> (define px pregexp)
> @px{\d} ; #px"\\d"
What Alex didn't mention is that this at-exp syntax is a generic tool
for many cases of dealing with text, and as such, it has a built-in way
to avoid backwhackages:
@px|{Even @ and } are plain text (but pregexp won't like the })}|
and
@px|~~~{Now |@ and }| are plain too}~~~|
And since this is just an alternative syntax for (px ...), you can
define it in any way you want, like
(define px (compose1 pregexp string-append))
@px{foo
bar}
;; => #px"foo\nbar"
You also get instant comment syntax:
@px{foo@; this is a comment, it includes the newline
bar}
;; #px"foobar"
or for an even more sophisticated example, ignore newlines and
indentation that is part of the at-form syntax:
(define-syntax (px stx)
(define (keep? x)
(define p (syntax-property x 'scribble))
(or (not p) (and (pair? p) (eq? (car p) 'form
(syntax-case stx ()
[(_ _ ...)
(with-syntax ([(x ...) (filter keep? (cdr (syntax->list stx)))])
#'(pregexp (string-append x ...)))]))
@px{(?:@; no need to capture this
@; one of these keywords:
foo|
bar|
@; baz too
baz
)
@; followed by a newline
@"\n"
}
;; => #px"(?:foo|bar|baz)\n"
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] racket users fight for their right to colon keywords
On Thu, Oct 15, 2015 at 3:37 PM, Anthony Carrico <acarr...@memebeam.org> wrote: > I didn't really want to get dragged into this, but keep in mind that: > > (symbol? #'test) ; -> #f > > IIRC the common lisp keywords you admire are symbols. I think that the > proposed syntax confuses symbols and keywords, which are distinct > types. Yes, CL keywords are symbols, but there's no confusion since they are very different from regular symbols. To complete the details for whoever might be interested, in CL symbols can be written as `foo:bar` for the (externally visible) "bar" symbol from the "foo" package. Symbols with no colon are implicitly in the current package. This is why `:foo` makes sense for keywords: it's the "foo" symbol from the special keyword package -- special since it has no name, and since all of its symbols are visible outside. Now, consider the fact that CL equates "identifiers" with "symbols", and uses packages as a half-assed[*] attempt to get some sanity with my code not stepping over your code -- and that should explain why `:foo` and `foo` are both "the same type" but are very different in nature -- to the point that your argument of a distinct type doesn't hold well in CL (and in Racket too, since Neil's suggestion would make `:foo` not be a symbol). Notes: 1. I use [*] in a technical way -- I once tried to explain hygiene to CLers by saying that it's as if each scope has its own (anonymous) package. 2. Also, talking about what counts as a symbol in CL is not too productive. CL can surprise you with gems like: (symbol? (cdr '(1))) returning true. 3. I didn't see it mentioned so: the original motivation for `#:foo` was an attempt to avoid the argument of `:foo` vs `foo:` vs "either one" vs whatever. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] syntax write using @-syntax
On Sun, Oct 4, 2015 at 2:53 AM, Neil Van Dyke <n...@neilvandyke.org> wrote:
> Thanks, Eli. That's one of the things I was afraid of.
>
> The other thing is: does a Scribble formatter ever look at the
> line/column position information in the syntax objects? (I thought I
> recalled it seeming to do this years ago, maybe for the start of a
> multi-line verbatim-like markup.)
The *reader* ignores uniform indentation, so when you write something like:
@foo{bar
baz
blah}
it reads two spaces for the second line and four for the third. There
are a few more rules that make sense in general. I think that they're
all listed in the reader documentation (which is also used as test
cases, assuming it hasn't changed).
If you're talking about the formatter which is part of the
html/latex/etc renderer in the documentation system, then I think that
it just treats the forms as anything, which means that it doesn't see
the source code indentation.
> I decided that just a normal Racket sexp write to the ".scrbl" file
> suits my needs, since the file doesn't need to be edited manually.
>
> I also like your idea of just copying the bits of original source
> text. (I've done similar things before, with
> "http://www.neilvandyke.org/racket-progedit/;.) Though that would
> seem to make it even harder to kludge navigating from Scribble errors
> on this semi-generated file to the original source bits in the
> original source files.
Right -- that was the reason for my comment: maybe there's some way to
keep the source code where it is, and refer to it from the files that
you generate, so no textual generation is actually needed...
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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] syntax write using @-syntax
On Wed, Sep 30, 2015 at 1:54 PM, Greg Hendershott
<greghendersh...@gmail.com> wrote:
> So a kind of pretty-printing for at-expressions?
>
> I'm not aware of an existing procedure to do this.
When I wrote about the reader implementation, I did it with a cute hack
that:
* Uses backslash as the command character instead of @
* Uses a language that extends scribble/text by making unknown
backslashed forms print themselves out
* Pipe the result into latex
The result of that is a combination of latex and racket: some random
\foo[bar]{baz} would spit itself out if `foo` is not defined, but if you
do define it, then it's the usual application of a function -- so you
can define some commands in latex, and other commands in racket.
The interesting bit is the second bullet which is doing, IIUC, roughly
what Neil wants and you try to do. I looked at the code at some point,
and it's not too good enough to just put out (mostly due to its age),
but if you're interested (Neil) I can send you the whole thing.
In any case, one major comment:
> (define (print/at-exp stx-or-sepxr)
> (match stx-or-sepxr
> [(? syntax? stx) (print/at-exp (syntax->datum stx))]
That's a major mistake! The reader puts useful information in the
syntax properties. It should tell you how what is a scribble form (so
you don't transform everything), and many expressions are in the datum
part. Without that, I'm guessing this code will break with common
expressions that look like @foo[#:bar "baz"]{blah}.
The strings also have useful properties that identify newlines and
indentation.
There's not enough to reconstruct the original source completely though
-- but if the forms come from an existing file, then I think that the
best way to hack that is to use the source information and just read the
contents of the file. (A bad hack that might lead to a better way to do
whatever, something that doesn't require copying source code...)
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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: line comment swallows paragraph break
On Thu, Sep 17, 2015 at 2:29 PM, Ben Lerner <bler...@ccs.neu.edu> wrote:
> Yes, in that case. I meant more the following:
>
> #lang at-exp racket
> '@stuff{
> Hello@; John
>
> World
> }
>
> which currently produces '(stuff "Hello" "\n" " " "World").
This sounds like it could be a more surprising behavior than just
swallowing a single newline. But there's really no right or wrong --
note that this kind of behavior would have made it go even farther than
what the OP wanted...
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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: line comment swallows paragraph break
On Thu, Sep 17, 2015 at 11:30 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > I imagine that Eli adopted that feature of @-expressions from TeX. Yes -- and it's also similar to a few other comment behaviors, like m4's `dnl`. But it sounds like it would be good to qualify the "similar to % in tex" comment in the docs given the weird thing it does with paragraph breaks... -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Should compose be so slow?
On Tue, Sep 15, 2015 at 8:35 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > PS: the code just above is not really valid for compose. But it might > be okay for compose1. Something similar could be done for compose too -- and to many other HO combinators (like curry and negate). (The general concept is similar to CL's compiler macros.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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] Search code
On Sat, Aug 8, 2015 at 11:23 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 08 Aug 2015 16:19:23 +0100, Paulo Matos wrote: Where can I find the code for : http://docs.racket-lang.org/search/index.html It's in scribblings/main/private in the racket-index package: https://github.com/plt/racket/tree/master/pkgs/racket-index/scribblings/main/private Note that some of that code is ancient, and could probably be organized much better these days. (For example, using something like promises instead of the hand-rolled quasi-cps thing for the search.) Worse, the complication of the search is not really needed now: originally, the search was lond enough to benefit from being interrupted by a new character, but now it's fast enough to not even be noticed. Another questionable feature is the loading of the whole index into memory and searching through it (unless someone cleaned that out since then...). Finally, the actual search has a bunch of not-too-organized hacks that try to get expected results higher than others, and a bunch of features (a query language) that practically no one knows about... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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.
