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
e 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 Barz
sed 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
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 newline
before "dream language".
--
((x=>x(x))(x=>x(x))) Eli Bar
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 sti
(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 unsubscri
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 unsub
y 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)))
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)))
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
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 -- t
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)))
([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
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 cas
g 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 who
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 Lif
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 rece
quoting 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 mess
ich 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/ M
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
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)
o 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
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
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 Barzil
((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 e
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=>
cally -- 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/
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
s 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
"Racke
((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 rece
ed `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
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)))
;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|
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 G
s 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)))
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.or
" " " "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...
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 messag
y 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 Gro
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
40 matches
Mail list logo
