Re: [racket-users] [racket] suggestions on scribble/example

[Matthew Flatt]

At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
> 1. Could you please treat the exn:fail:unsupported like a normal case as if
> it is wrapped by (eval:error)?
> 
> http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
> d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
> 
> this example is about ExtFlVector which is not supported in my openindiana
> box.

Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
sounds reasonable to me.

> 2.
> http://docs.racket-lang.org/reference/Reading.html?q=read-language#%28def._%28%
> 28quote._~23~25kernel%29._read-language%29%29
> 
> this example is about (read-language), algol60 is not special here, however
> user-developers have to install it.

I'll adjust that example to avoid an extra dependency.

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] Simple regex question. How to match this: "[X] foo"

[Alex Knauth]

> On Jan 9, 2016, at 1:38 AM, David Storrs  wrote:
> 
> Related question:  Perl has a capacity to change your delimiters on regexen 
> in order to avoid having to backwhack everything.  

The raw-string package allows this for strings:
#lang raw-string/raw-string racket #\$
(pregexp $"\d") ; #px"\\d"

And the at-exp language allows this:
#lang at-exp racket
@pregexp{\d} ; #px"\\d"

And you can do this:
#lang at-exp racket
(define px pregexp)
@px{\d} ; #px"\\d"


-- 
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] [racket] suggestions on scribble/example

[WarGrey Gyoudmon Ju]

1. Could you please treat the exn:fail:unsupported like a normal case as if
it is wrapped by (eval:error)?

http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._typed-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29

this example is about ExtFlVector which is not supported in my openindiana
box.

2.
http://docs.racket-lang.org/reference/Reading.html?q=read-language#%28def._%28%28quote._~23~25kernel%29._read-language%29%29

this example is about (read-language), algol60 is not special here, however
user-developers have to install it.




These two do not make sense in everyday use, just be mentioned by raco pkg
install, however it affects the auto-update script.

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] typed/racket (or foo #f) doesn't work as expected

[Norman Gray]

Greetings.

Consider the following:

#lang typed/racket
;#lang typed/racket/no-check  ; <-- this works as expected

(: func (case->
   ([#:as (U Integer False)] -> Any)
   (Integer [#:as (U Integer False)] -> Any)))
(define (func (arg1 #f) #:as (opt-arg #f))
  (cond (arg1 (or arg1 #f)); <-- removing this expression means 
things work as expected

(else
 (eprintf "func: opt-arg=~s, so (or ~s #f) -> ~s~%"
  opt-arg opt-arg (or opt-arg #f))
 (or opt-arg #f

(func #:as 1)
(func 1)

When run...

% racket -v
Welcome to Racket v6.3.
% racket test.rkt
func: opt-arg=1, so (or 1 #f) -> #f
#f
1
%

That is, in the first case (or 1 #f) appears to evaluate to #f, not 1 as 
expected.  Very much not as expected.


If I replace the definition with

(define (func (arg1 #f) #:as (opt-arg : (U Integer False) #f))
  ...)

then this works as expected.  That is, TR appears to be typing opt-arg, 
within the function, as False, and rewriting the (or opt-arg #f) 
accordingly.  It's not doing the same with the (arg1 (or arg1 #f)) 
clause.


Given that I've typed the func function before defining it, and have 
typed the #:as argument as (U Integer False), I would not expect to have 
to repeat myself in the function definition.


Related, perhaps: If I declare the type of 'func' as follows:

(: func (case->
   ([#:as Integer] -> Any)
   (Integer [#:as Integer] -> Any)))

Then the default opt-arg value does not match the function type.  This 
does not produce any error or warning, and this suggests to me that this 
declaration is not being examined when the function is defined.  I would 
have expected this to be caught as a type error.


That said, the following program 'works'

#lang typed/racket

(: f ([#:o Integer] -> Any))
(define (f #:o (opt-arg #f))
  (or opt-arg #f))
(f #:o 1) ; --> 1

So it's not just a matter of 'type of optional arguments is too narrow'.

Also, this program has the same glaring type error in it.



What _may_ be a related issue is that, if I try the program at the top 
in DrRacket with the 'Debug' button, I get an error message:


Welcome to DrRacket, version 6.3 [3m].
Language: typed/racket [custom]; memory limit: 128 MB.
exception raised by error display handler: normalize-path: element 
within the input path is not a directory or does not exist
  element: /home/ryan; original exception raised: 
expr-syntax-object-iterator: unknown expr: (quote-syntax (:-internal 
func (case-> ((#:as Integer) -> Any) (Bytes (#:as Integer) -> Any))) 
#:local)




But this may be a separate issue, because if I put the smaller program, 
above, into DrRacket, and press Debug, I get



../../Data/LocalApplications/Racket/6.3/share/pkgs/drracket/gui-debugger/annotator.rkt:227:6: 
expr-syntax-object-iterator: unknown expr: (quote-syntax (:-internal f 
((#:o Integer) -> Any)) #:local)


I don't know if this is related, but I wouldn't have expected to see a 
/home/ryan above.  Additionally, doing


find /Data/LocalApplications/Racket/6.3 -type f | xargs grep 
/home/ryan


...I get _lots_ of matches.  Is there a possible build glitch here?



I'm on OS X, 10.10.5

The same thing happens as far back as Racket 5.3.6, which is the 
earliest I have to hand.


Best wishes,

Norman


--
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

--
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] suggestions on scribble/example

[Matthew Flatt]

At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
> At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
> > 1. Could you please treat the exn:fail:unsupported like a normal case as if
> > it is wrapped by (eval:error)?
> > 
> > 
> http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
> > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
> > 
> > this example is about ExtFlVector which is not supported in my openindiana
> > box.
> 
> Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
> sounds reasonable to me.

On further reflection, that seems like a bad idea  --- repeating the
mistakes of `scribble/eval`.

I think it's better in this case to adjust the documentation. I don't
have a good idea on how to prevent this kind of problem in the future,
though.

-- 
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] suggestions on scribble/example

[Robby Findler]

Could this problem be helped if we run something like drdr, but in
more configurations? (That doesn't seem particularly simple, tho.)

Robby


On Sat, Jan 9, 2016 at 10:07 AM, Matthew Flatt  wrote:
> At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
>> At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
>> > 1. Could you please treat the exn:fail:unsupported like a normal case as if
>> > it is wrapped by (eval:error)?
>> >
>> >
>> http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
>> > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
>> >
>> > this example is about ExtFlVector which is not supported in my openindiana
>> > box.
>>
>> Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
>> sounds reasonable to me.
>
> On further reflection, that seems like a bad idea  --- repeating the
> mistakes of `scribble/eval`.
>
> I think it's better in this case to adjust the documentation. I don't
> have a good idea on how to prevent this kind of problem in the future,
> though.
>
> --
> 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] [racket] suggestions on scribble/example

[Gustavo Massaccesi]

In TravisCI, building with the "main-distribution" packge, the
versions in linux that don't have "--disable-jit" finish corretly just
a minutes after an hour. (I think the official max time is 1 hour, but
apparently there are some bonus minutes.)

The versions with "--disable-jit" take longer and are broken automatically.

See https://travis-ci.org/gus-massa/racket/builds/100167233 (The error
was caused by an unrelated problem.)

Gustavo

On Sat, Jan 9, 2016 at 2:38 PM, Sam Tobin-Hochstadt
 wrote:
> We do run the core racket tests without exflonums on Travis; you can
> see an example here:
> https://travis-ci.org/racket/racket/jobs/101270780
>
> Unfortunately, building all of Racket + everything else takes more
> time that various hosted CI systems allow. If there was a build of
> Racket without extflonums, then the Typed Racket CI could test that,
> but there are a lot of different configurations to test, and that
> requires individual per-package effort.
>
> Sam
>
> On Sat, Jan 9, 2016 at 11:13 AM, Robby Findler
>  wrote:
>> Could this problem be helped if we run something like drdr, but in
>> more configurations? (That doesn't seem particularly simple, tho.)
>>
>> Robby
>>
>>
>> On Sat, Jan 9, 2016 at 10:07 AM, Matthew Flatt  wrote:
>>> At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
 At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
 > 1. Could you please treat the exn:fail:unsupported like a normal case as 
 > if
 > it is wrapped by (eval:error)?
 >
 >
 http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
 > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
 >
 > this example is about ExtFlVector which is not supported in my 
 > openindiana
 > box.

 Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
 sounds reasonable to me.
>>>
>>> On further reflection, that seems like a bad idea  --- repeating the
>>> mistakes of `scribble/eval`.
>>>
>>> I think it's better in this case to adjust the documentation. I don't
>>> have a good idea on how to prevent this kind of problem in the future,
>>> though.
>>>
>>> --
>>> 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.
>
> --
> 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] [racket] suggestions on scribble/example

[Robby Findler]

Yes, right. This is why I suggested drdr.

Robby

On Sat, Jan 9, 2016 at 11:38 AM, Sam Tobin-Hochstadt
 wrote:
> We do run the core racket tests without exflonums on Travis; you can
> see an example here:
> https://travis-ci.org/racket/racket/jobs/101270780
>
> Unfortunately, building all of Racket + everything else takes more
> time that various hosted CI systems allow. If there was a build of
> Racket without extflonums, then the Typed Racket CI could test that,
> but there are a lot of different configurations to test, and that
> requires individual per-package effort.
>
> Sam
>
> On Sat, Jan 9, 2016 at 11:13 AM, Robby Findler
>  wrote:
>> Could this problem be helped if we run something like drdr, but in
>> more configurations? (That doesn't seem particularly simple, tho.)
>>
>> Robby
>>
>>
>> On Sat, Jan 9, 2016 at 10:07 AM, Matthew Flatt  wrote:
>>> At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
 At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
 > 1. Could you please treat the exn:fail:unsupported like a normal case as 
 > if
 > it is wrapped by (eval:error)?
 >
 >
 http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
 > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
 >
 > this example is about ExtFlVector which is not supported in my 
 > openindiana
 > box.

 Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
 sounds reasonable to me.
>>>
>>> On further reflection, that seems like a bad idea  --- repeating the
>>> mistakes of `scribble/eval`.
>>>
>>> I think it's better in this case to adjust the documentation. I don't
>>> have a good idea on how to prevent this kind of problem in the future,
>>> though.
>>>
>>> --
>>> 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.

-- 
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] suggestions on scribble/example

[Sam Tobin-Hochstadt]

We do run the core racket tests without exflonums on Travis; you can
see an example here:
https://travis-ci.org/racket/racket/jobs/101270780

Unfortunately, building all of Racket + everything else takes more
time that various hosted CI systems allow. If there was a build of
Racket without extflonums, then the Typed Racket CI could test that,
but there are a lot of different configurations to test, and that
requires individual per-package effort.

Sam

On Sat, Jan 9, 2016 at 11:13 AM, Robby Findler
 wrote:
> Could this problem be helped if we run something like drdr, but in
> more configurations? (That doesn't seem particularly simple, tho.)
>
> Robby
>
>
> On Sat, Jan 9, 2016 at 10:07 AM, Matthew Flatt  wrote:
>> At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
>>> At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
>>> > 1. Could you please treat the exn:fail:unsupported like a normal case as 
>>> > if
>>> > it is wrapped by (eval:error)?
>>> >
>>> >
>>> http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
>>> > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
>>> >
>>> > this example is about ExtFlVector which is not supported in my openindiana
>>> > box.
>>>
>>> Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
>>> sounds reasonable to me.
>>
>> On further reflection, that seems like a bad idea  --- repeating the
>> mistakes of `scribble/eval`.
>>
>> I think it's better in this case to adjust the documentation. I don't
>> have a good idea on how to prevent this kind of problem in the future,
>> though.
>>
>> --
>> 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.

-- 
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"

[Matthew Butterick]

> ...and extract the following strings:
> "[X] Escape with Inoue-sensei"
> "[X] Forget all these disloyal options and stick with Shikigami-sensei's
> plan"
> What method would you suggest for that?


There's nothing wrong with `regexp-whatever`. But because Racket has so
many good tools for list processing, it can be helpful to recharacterize a
problem in terms of lists. (Repeated application of `string-split` is my
secret weapon.) In this case, you needn't resort to regexp:

(filter (curryr string-prefix? "[X]") (string-split str "\n"))






On Fri, Jan 8, 2016 at 11:34 PM, David Storrs 
wrote:

>
>
> On Fri, Jan 8, 2016 at 10:56 PM, Neil Van Dyke 
> wrote:
>
>> David Storrs wrote on 01/09/2016 01:38 AM:
>>
>>>
>>> (regex-match*
>>> #px"\[[xX\d]\]"
>>> "[1] foo \n [2] bar \n [x] baz \n [X] baz \n"")
>>>
>>
>> (regexp-match*
>>  #px"\\[[xX\\d]\\]"
>>  "[1] foo \n [2] bar \n [x] baz \n [X] baz \n")
>> ;;==> ("[1]" "[2]" "[x]" "[X]")
>>
>> Looks like maybe a typo in the procedure name, and the backslashes needed
>> to be escaped for the string literal.
>>
>
> Drat.  I kept looking for issues with the escape code, I missed the fact
> that the problem was with the 'regexP' function.  Thanks.
>
>
>
>>
>> Related question:  Perl has a capacity to change your delimiters on
>>> regexen in order to avoid having to backwhack everything.
>>>
>>
>> You could make a Racket reader that did this.  Or you can find some of
>> the interesting s-expression regular expression languages (I think Olin
>> Shivers did one).  Or just not use regexps so much ("
>> http://regex.info/blog/2006-09-15/247;).
>>
>
> Before I even clicked that link, I knew what it was going to be.  I've
> heard that expression a lot and never quite understood it, because it seems
> so unilateral. Serious question, not being snarky:  what would you suggest
> using for simple text processing if not regular expressions?  For example,
> my project right now is to take this chunk of text:
>
> ===QUOTE
> [X] Escape with Inoue-sensei
> *No. of votes: 10*
> Usernames 
> Ridiculously Average Guy
> 
> Brain_Caster 
> Xyzarach 
> gbear605 
> fictionfan 
> Chronic 
> _brightwing 
> Rihaku 
> Sigil 
>
> [X] Forget all these disloyal options and stick with Shikigami-sensei's
> plan
> ===/QUOTE
>
> ...and extract the following strings:
>
> "[X] Escape with Inoue-sensei"
> "[X] Forget all these disloyal options and stick with Shikigami-sensei's
> plan"
>
> What method would you suggest for that?
>
>

-- 
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] warning on use trie functions in #lang racket?

[Robby Findler]

I gave this a try here: https://github.com/rfindler/tr-pfds but got stuck.

Robby


On Fri, Jan 8, 2016 at 9:14 AM, Sam Tobin-Hochstadt
 wrote:
> On Fri, Jan 8, 2016 at 10:10 AM, Robby Findler
>  wrote:
>> I think we must be talking past each other. Let me try to back out a bit.
>>
>> It is my understanding that the trie library's slowness that John
>> reported is all about contract overhead. Specifically, there are some
>> (effectively) lazy contracts on the trie structs that pile up, leading
>> to surprisingly bad performance and that these contracts are generated
>> by TR.
>>
>> Our initial round of discussion came to the conclusion there's no
>> simple fix to TR or the contract system that can avoid this overhead.
>>
>> So, instead of adding a big warning to the trie library (that Asumu
>> rightly is not excited about :), we could use TR's unsafe require
>> support to implement a small wrapper file that does a more efficient
>> version of the contract checking and then John's problem would be
>> fixed.
>>
>> Over the period between the current and next release we could, in
>> addition, improve TR and the contract system to the point where that
>> wrapper file isn't necessary. That seems good too. It also seems
>> useful to have the short-term fix as part of doing the longer-term fix
>> because that will help us be sure we've really gotten the right
>> contracts in there by comparing the performance of the two versions.
>>
>> Does this make sense as the right way to proceed?
>
> Yes, that's definitely the right thing to do. I was thinking that
> since the pfds library isn't part of the main distribution, if we can
> fix TR to do better here, even if not before the release, then adding
> this workaround wouldn't be necessary. But of course that's wrong --
> anyone using 6.3 or 6.4 would still see the awful performance that
> John noticed. So we should fix pfds now using the technique you
> suggest.
>
> Sorry being confused here,
> Sam
>
>>
>> Robby
>>
>>
>>
>> On Fri, Jan 8, 2016 at 8:49 AM, Sam Tobin-Hochstadt
>>  wrote:
>>> My suggestion did involve changing TR. I think your suggestion was to
>>> change the trie library, which doesn't have to worry about the Racket
>>> release schedule.
>>>
>>> Sam
>>>
>>> On Fri, Jan 8, 2016 at 9:48 AM, Robby Findler
>>>  wrote:
 I thought your suggestion involved a change to TR.

 But whatever. Do what you want.

 Robby

 On Fri, Jan 8, 2016 at 8:45 AM, Sam Tobin-Hochstadt
  wrote:
> This library isn't part of the Racket distribution, so the release 
> schedule
> doesn't really matter here.
>
> Sam
>
> On Fri, Jan 8, 2016 at 9:42 AM Robby Findler 
> wrote:
>>
>> We can do the simpler thing for this release, tho. And changing TR
>> won't happen for months. The simple suggestion is an easy, immediate
>> fix, and it will also give us goalposts to shoot for.
>>
>> Robby
>>
>> On Fri, Jan 8, 2016 at 8:19 AM, Sam Tobin-Hochstadt
>>  wrote:
>> > I think a better solution is just to add immutable hash tables to TR,
>> > and then use them in the trie modules. That would allow TR to generate
>> > exactly the contracts that we could write by hand.
>> >
>> > Sam
>> >
>> > On Fri, Jan 8, 2016 at 9:06 AM, Robby Findler
>> >  wrote:
>> >> We know there is a much more efficient set of contracts than what TR
>> >> generates right? How about an unsafe export of TR functions to a
>> >> wrapper
>> >> module that implements the safe checks by hand (by macro?)? Maybe that
>> >> exercise will even feed back into an improvement to TR?
>> >>
>> >> Robby
>> >>
>> >>
>> >> On Tuesday, January 5, 2016, Asumu Takikawa  wrote:
>> >>>
>> >>> On 2016-01-05 14:39:17 -0500, 'John Clements' via Racket Users wrote:
>> >>> > Asumu, does this make sense to you? Note that in particular, I 
>> >>> > think
>> >>> > that a
>> >>> > warning at the top of the pfds package wouldn’t have helped me; I
>> >>> > think
>> >>> > a
>> >>> > warning at the top of each pfds page would make a lot more sense.
>> >>>
>> >>> I'd be happy to take a pull request for this. Though I'd also prefer
>> >>> that
>> >>> the
>> >>> library just worked well.
>> >>>
>> >>> The pfds could library could also just export everything without
>> >>> contracts
>> >>> unsafely. Alternatively we could set it up to generate untyped
>> >>> variants of
>> >>> each (with a different module path) that don't optimize or use
>> >>> contracts.
>> >>>
>> >>> Cheers,
>> >>> Asumu
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to 

Re: [racket-users] Simple regex question. How to match this: "[X] foo"

[Eli Barzilay]

On Sat, Jan 9, 2016 at 9:44 AM, Alex Knauth  wrote:
>
>> On Jan 9, 2016, at 1:38 AM, David Storrs  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] suggestions on scribble/example

[WarGrey Gyoudmon Ju]

Oh, I see the alternative solution for  #1.
https://github.com/racket/typed-racket/pull/288

Your discussion there is delightful.
Thanks.

On Sun, Jan 10, 2016 at 2:51 AM, Robby Findler 
wrote:

> Yes, right. This is why I suggested drdr.
>
> Robby
>
> On Sat, Jan 9, 2016 at 11:38 AM, Sam Tobin-Hochstadt
>  wrote:
> > We do run the core racket tests without exflonums on Travis; you can
> > see an example here:
> > https://travis-ci.org/racket/racket/jobs/101270780
> >
> > Unfortunately, building all of Racket + everything else takes more
> > time that various hosted CI systems allow. If there was a build of
> > Racket without extflonums, then the Typed Racket CI could test that,
> > but there are a lot of different configurations to test, and that
> > requires individual per-package effort.
> >
> > Sam
> >
> > On Sat, Jan 9, 2016 at 11:13 AM, Robby Findler
> >  wrote:
> >> Could this problem be helped if we run something like drdr, but in
> >> more configurations? (That doesn't seem particularly simple, tho.)
> >>
> >> Robby
> >>
> >>
> >> On Sat, Jan 9, 2016 at 10:07 AM, Matthew Flatt 
> wrote:
> >>> At Sat, 9 Jan 2016 08:34:45 -0700, Matthew Flatt wrote:
>  At Sat, 9 Jan 2016 22:58:00 +0800, WarGrey Gyoudmon Ju wrote:
>  > 1. Could you please treat the exn:fail:unsupported like a normal
> case as if
>  > it is wrapped by (eval:error)?
>  >
>  >
> 
> http://docs.racket-lang.org/ts-reference/type-ref.html#%28form._%28%28lib._type
>  > d-racket%2Fbase-env%2Fbase-types..rkt%29._.Ext.Fl.Vector%29%29
>  >
>  > this example is about ExtFlVector which is not supported in my
> openindiana
>  > box.
> 
>  Treating an `exn:fail:unsupported` error as if wrapped by `eval:error`
>  sounds reasonable to me.
> >>>
> >>> On further reflection, that seems like a bad idea  --- repeating the
> >>> mistakes of `scribble/eval`.
> >>>
> >>> I think it's better in this case to adjust the documentation. I don't
> >>> have a good idea on how to prevent this kind of problem in the future,
> >>> though.
> >>>
> >>> --
> >>> 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.
>

-- 
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] Re: HTTPS for Racket web sites and packages

[Juan Francisco Cantero Hurtado]

Can you change also the snapshots in utah.edu to access to the catalog 
with https? The server supports https.


On 09/01/16 04:54, Matthew Flatt wrote:

Sam, Ryan, I, and others have been moving Racket services to HTTPS:

   https://racket-lang.org/

We're changing all references to use HTTPS, so if you go to
"http://racket-lang.org; (no "s"), the "Download" link takes you to
"https://download.racket-lang.org/;. The default download button on
that page similarly points to "https://mirror.racket-lang.org/;.

We have not yet started enforcing HTTPS on any of our pages, either
through a redirect from "http://; to "https://; or through HSTS. We
want to gain more confidence in our setup before taking that step.


Packages and catalog:

You can set "https://pkgs.racket-lang.org/; as your package catalog,
and we've made that the default for the next release. Beware, however,
that `raco pkg` in v6.3 and earlier does not actually make a secure
connection for HTTPS references (because it doesn't validate the
server's certificate); we've fixed that for the next release.

With the development version of Racket, if you want to use an insecure
HTTPS reference for some reason with `raco pkg` (e.g., to a server with
a self-signed certificate), set the `PLT_PKG_SSL_NO_VERIFY` environment
variable.


General security note:

Except for "https://mirror.racket-lang.org;, HTTPS content is provided
via CloudFlare from an HTTP (not HTTPS) access of S3. So, you can only
trust the content of "https://pkgs.racket-lang.org; to the degree that
you trust Amazon, CloudFlare, and the channel between them to provide
the data that we put on S3. We may eventually strengthen the channel
between our data (especially package metadata) and HTTPS services, but
we're not working on that right now.




--
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"

[Daniel Prager]

Matthew writes:
> Repeated application of `string-split` is my secret weapon.

(filter (curryr string-prefix? "[X]") (string-split str "\n"))


To say nothing of  string-prefix? (new in 6.3) and curryr - nice!

Somewhat more explicit (and verbose) variations:

(filter (λ (line) (string-prefix? line "[X]")) (string-split str "\n"))


or

(for/list ([line (string-split str "\n")]
   #:when (string-prefix? line "[X]"))

  line)


Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: HTTPS for Racket web sites and packages

[Matthew Flatt]

The snapshots from Utah should be configured that way already, at least
in the most recent snapshots (6.3.0.14). Were you looking at an older
build? If not, can you say more about where you're seeing non-HTTPS
URLs?

At Sun, 10 Jan 2016 00:45:52 +0100, Juan Francisco Cantero Hurtado wrote:
> Can you change also the snapshots in utah.edu to access to the catalog 
> with https? The server supports https.
> 
> On 09/01/16 04:54, Matthew Flatt wrote:
> > Sam, Ryan, I, and others have been moving Racket services to HTTPS:
> >
> >https://racket-lang.org/
> >
> > We're changing all references to use HTTPS, so if you go to
> > "http://racket-lang.org; (no "s"), the "Download" link takes you to
> > "https://download.racket-lang.org/;. The default download button on
> > that page similarly points to "https://mirror.racket-lang.org/;.
> >
> > We have not yet started enforcing HTTPS on any of our pages, either
> > through a redirect from "http://; to "https://; or through HSTS. We
> > want to gain more confidence in our setup before taking that step.
> >
> >
> > Packages and catalog:
> >
> > You can set "https://pkgs.racket-lang.org/; as your package catalog,
> > and we've made that the default for the next release. Beware, however,
> > that `raco pkg` in v6.3 and earlier does not actually make a secure
> > connection for HTTPS references (because it doesn't validate the
> > server's certificate); we've fixed that for the next release.
> >
> > With the development version of Racket, if you want to use an insecure
> > HTTPS reference for some reason with `raco pkg` (e.g., to a server with
> > a self-signed certificate), set the `PLT_PKG_SSL_NO_VERIFY` environment
> > variable.
> >
> >
> > General security note:
> >
> > Except for "https://mirror.racket-lang.org;, HTTPS content is provided
> > via CloudFlare from an HTTP (not HTTPS) access of S3. So, you can only
> > trust the content of "https://pkgs.racket-lang.org; to the degree that
> > you trust Amazon, CloudFlare, and the channel between them to provide
> > the data that we put on S3. We may eventually strengthen the channel
> > between our data (especially package metadata) and HTTPS services, but
> > we're not working on that right now.
> >
> 
> 
> -- 
> 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] Re: HTTPS for Racket web sites and packages

[Juan Francisco Cantero Hurtado]

Yes, I was testing 6.3.0.13. Sorry for the noise.

On sábado, 9 de enero de 2016 17:39:02 (CET) Matthew Flatt wrote:
>The snapshots from Utah should be configured that way already, at least
>in the most recent snapshots (6.3.0.14). Were you looking at an older
>build? If not, can you say more about where you're seeing non-HTTPS
>URLs?
>
>At Sun, 10 Jan 2016 00:45:52 +0100, Juan Francisco Cantero Hurtado 
wrote:
>> Can you change also the snapshots in utah.edu to access to the
>> catalog
>> with https? The server supports https.
>> 
>> On 09/01/16 04:54, Matthew Flatt wrote:
>> > Sam, Ryan, I, and others have been moving Racket services to HTTPS:
>> >https://racket-lang.org/
>> > 
>> > We're changing all references to use HTTPS, so if you go to
>> > "http://racket-lang.org; (no "s"), the "Download" link takes you to
>> > "https://download.racket-lang.org/;. The default download button on
>> > that page similarly points to "https://mirror.racket-lang.org/;.
>> > 
>> > We have not yet started enforcing HTTPS on any of our pages, either
>> > through a redirect from "http://; to "https://; or through HSTS. We
>> > want to gain more confidence in our setup before taking that step.
>> > 
>> > 
>> > Packages and catalog:
>> > 
>> > You can set "https://pkgs.racket-lang.org/; as your package
>> > catalog,
>> > and we've made that the default for the next release. Beware,
>> > however,
>> > that `raco pkg` in v6.3 and earlier does not actually make a secure
>> > connection for HTTPS references (because it doesn't validate the
>> > server's certificate); we've fixed that for the next release.
>> > 
>> > With the development version of Racket, if you want to use an
>> > insecure
>> > HTTPS reference for some reason with `raco pkg` (e.g., to a server
>> > with a self-signed certificate), set the `PLT_PKG_SSL_NO_VERIFY`
>> > environment variable.
>> > 
>> > 
>> > General security note:
>> > 
>> > Except for "https://mirror.racket-lang.org;, HTTPS content is
>> > provided
>> > via CloudFlare from an HTTP (not HTTPS) access of S3. So, you can
>> > only
>> > trust the content of "https://pkgs.racket-lang.org; to the degree
>> > that
>> > you trust Amazon, CloudFlare, and the channel between them to
>> > provide
>> > the data that we put on S3. We may eventually strengthen the
>> > channel
>> > between our data (especially package metadata) and HTTPS services,
>> > but
>> > we're not working on that right now.


-- 
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] Web server with x-expressions vs templates

[Marc Kaufmann]

Hi all,

I was just about to start encoding my forms as formlets when I remembered that 
there are templates for web development. Do people advise using templates over 
x-expressions for web development with Racket, that is, what are most people 
using who do that kind of thing? After rereading it, my feeling is that 
templates are probably easier, and formlets can simply be implemented via 
templates.

Thanks,

Marc

-- 
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] warning on use trie functions in #lang racket?

[Sam Tobin-Hochstadt]

Here's an initial pull request: https://github.com/takikawa/tr-pfds/pull/6

It runs John's test case in about 2 ms, instead of multiple seconds.

Sam

On Sat, Jan 9, 2016 at 2:21 PM, Robby Findler
 wrote:
> I gave this a try here: https://github.com/rfindler/tr-pfds but got stuck.
>
> Robby
>
>
> On Fri, Jan 8, 2016 at 9:14 AM, Sam Tobin-Hochstadt
>  wrote:
>> On Fri, Jan 8, 2016 at 10:10 AM, Robby Findler
>>  wrote:
>>> I think we must be talking past each other. Let me try to back out a bit.
>>>
>>> It is my understanding that the trie library's slowness that John
>>> reported is all about contract overhead. Specifically, there are some
>>> (effectively) lazy contracts on the trie structs that pile up, leading
>>> to surprisingly bad performance and that these contracts are generated
>>> by TR.
>>>
>>> Our initial round of discussion came to the conclusion there's no
>>> simple fix to TR or the contract system that can avoid this overhead.
>>>
>>> So, instead of adding a big warning to the trie library (that Asumu
>>> rightly is not excited about :), we could use TR's unsafe require
>>> support to implement a small wrapper file that does a more efficient
>>> version of the contract checking and then John's problem would be
>>> fixed.
>>>
>>> Over the period between the current and next release we could, in
>>> addition, improve TR and the contract system to the point where that
>>> wrapper file isn't necessary. That seems good too. It also seems
>>> useful to have the short-term fix as part of doing the longer-term fix
>>> because that will help us be sure we've really gotten the right
>>> contracts in there by comparing the performance of the two versions.
>>>
>>> Does this make sense as the right way to proceed?
>>
>> Yes, that's definitely the right thing to do. I was thinking that
>> since the pfds library isn't part of the main distribution, if we can
>> fix TR to do better here, even if not before the release, then adding
>> this workaround wouldn't be necessary. But of course that's wrong --
>> anyone using 6.3 or 6.4 would still see the awful performance that
>> John noticed. So we should fix pfds now using the technique you
>> suggest.
>>
>> Sorry being confused here,
>> Sam
>>
>>>
>>> Robby
>>>
>>>
>>>
>>> On Fri, Jan 8, 2016 at 8:49 AM, Sam Tobin-Hochstadt
>>>  wrote:
 My suggestion did involve changing TR. I think your suggestion was to
 change the trie library, which doesn't have to worry about the Racket
 release schedule.

 Sam

 On Fri, Jan 8, 2016 at 9:48 AM, Robby Findler
  wrote:
> I thought your suggestion involved a change to TR.
>
> But whatever. Do what you want.
>
> Robby
>
> On Fri, Jan 8, 2016 at 8:45 AM, Sam Tobin-Hochstadt
>  wrote:
>> This library isn't part of the Racket distribution, so the release 
>> schedule
>> doesn't really matter here.
>>
>> Sam
>>
>> On Fri, Jan 8, 2016 at 9:42 AM Robby Findler 
>> 
>> wrote:
>>>
>>> We can do the simpler thing for this release, tho. And changing TR
>>> won't happen for months. The simple suggestion is an easy, immediate
>>> fix, and it will also give us goalposts to shoot for.
>>>
>>> Robby
>>>
>>> On Fri, Jan 8, 2016 at 8:19 AM, Sam Tobin-Hochstadt
>>>  wrote:
>>> > I think a better solution is just to add immutable hash tables to TR,
>>> > and then use them in the trie modules. That would allow TR to generate
>>> > exactly the contracts that we could write by hand.
>>> >
>>> > Sam
>>> >
>>> > On Fri, Jan 8, 2016 at 9:06 AM, Robby Findler
>>> >  wrote:
>>> >> We know there is a much more efficient set of contracts than what TR
>>> >> generates right? How about an unsafe export of TR functions to a
>>> >> wrapper
>>> >> module that implements the safe checks by hand (by macro?)? Maybe 
>>> >> that
>>> >> exercise will even feed back into an improvement to TR?
>>> >>
>>> >> Robby
>>> >>
>>> >>
>>> >> On Tuesday, January 5, 2016, Asumu Takikawa  
>>> >> wrote:
>>> >>>
>>> >>> On 2016-01-05 14:39:17 -0500, 'John Clements' via Racket Users 
>>> >>> wrote:
>>> >>> > Asumu, does this make sense to you? Note that in particular, I 
>>> >>> > think
>>> >>> > that a
>>> >>> > warning at the top of the pfds package wouldn’t have helped me; I
>>> >>> > think
>>> >>> > a
>>> >>> > warning at the top of each pfds page would make a lot more sense.
>>> >>>
>>> >>> I'd be happy to take a pull request for this. Though I'd also prefer
>>> >>> that
>>> >>> the
>>> >>> library just worked well.
>>> >>>
>>> >>> The pfds could 

Re: [racket-users] Re: upload file with http post an Content-Type is multipart/form

[Neil Van Dyke]

George Neuner wrote on 01/10/2016 02:22 AM:

Why would they break anything? Section 5.1.1 of RFC-2046 says:


By "boundary string" I meant what that RFC section calls "boundary 
parameter value".  Putting leading "-" in there is just asking for 
trouble, for no reason.


Not asking for trouble for no good reason is good IETF-style protocol 
implementation practice, part of "be conservative in what you send", IMHO.


Neil V.

--
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] Re: upload file with http post an Content-Type is multipart/form

[George Neuner]

On Fri, 8 Jan 2016 21:32:19 -0500, Neil Van Dyke
 wrote:

>Also, I would not put leading "-" characters in the part boundary 
>string, even if it doesn't break any servers you test against.  I would 
>use only alphanumeric ASCII characters. 

Why would they break anything?   Section 5.1.1 of RFC-2046 says:

  The Content-Type field for multipart entities requires one 
  parameter,  "boundary". The boundary delimiter line is then defined
  as a line  consisting entirely of two hyphen characters ("-",
  decimal value 45) followed by the boundary parameter value from
  the Content-Type header field, optional linear whitespace, and a
  terminating CRLF.


I know the leading hypens are for backward compatibility with RFC-934,
and should not be necessary for any server now ... but they are
compatible with RFC-2045 boundary syntax and, in fact, the examples
shown in RFC-2046 and RFC-2049 use them.

I have never run into any server that balks at leading (or trailing)
hyphens in a boundary tag.

Did I miss something?  
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.