Re: [racket-users] Cycle in loading. Units, (sub)modules, files...

[Jonas Winje]

Thanks. And like, that sounds a lot more sensible than what I'm trying to
do :)

And what I'm trying to do doesn't strike me as generally a good idea, but...

Initially I was playing around with language-stuff. Was making a language
and wanted a file written in that language to define a signature and a unit
exporting it. And I wanted to make it possible to have a file written in
that language "require" another file written in the language, only it'd
mean something like: B requires the signature-part of A, and it's only
required in the unit-part of B.

Very possibly bad idea though :)

On Wed, Jan 6, 2016 at 4:29 PM, Daniel Feltey  wrote:

> This doesn't quite answer your question, but another possibility that
> would allow you to separate the a@ and b@ unit implementations in
> separate files is to put all of your signature definitions in a single file
> that will be required by both "a.rkt" and "b.rkt". In my experience, this
> strategy is fairly common in uses of units in the Racket codebase (for
> example see https://github.com/racket/games/blob/master/gobblet/sig.rkt).
>
> Dan
>
> On Wed, Jan 6, 2016 at 8:16 AM, Jonas Winje  wrote:
>
>> Hello people,
>>
>> I've been fumbling around with cyclic dependencies and such and have
>> started looking at signatures and units. I manage to make the cycles work
>> out in a couple different ways, but I'm running into trouble when I try to
>> put different parts in different files the way I want them. As far as I can
>> tell it has to do with how much of a file/module is "loaded" if I really
>> just want to require one of its submodules. Not particularly certain.
>>
>> It's pretty possible that I'm just doing everything wrong and backwards,
>> or should really not be trying to do this to begin with, or something :)
>>
>> So: Does anyone know if it is possible to do something along the lines of
>>
>> - a.rkt with two submodules:
>> - a-sig: provides signature a^
>> - a-impl:
>> - requires a-sig
>> - requires b-sig from b.rkt
>> - provides unit a@ (which imports b^ and exports a^)
>> - b.rkt with two submodules:
>> - b-sig: provides signature b^
>> - b-impl:
>> - requires b-sig
>> - requires a-sig from a.rkt
>> - provides unit b@ (which imports a^ and exports b^)
>>
>> without getting
>>
>> standard-module-name-resolver: cycle in loading
>>   at path: ...\dep\b.rkt
>>   paths:
>>...\b.rkt
>>...\a.rkt
>>
>> ?
>>
>> I get it to work by putting all 4 modules in the same file. And I get it
>> to work by putting them in 4 different files. But if I want one file for
>> both the a-things and one for both the b-things I get the error above.
>> Presumably because (a submodule in) "a.rkt" requires (a submodule from)
>> "b.rkt", and other way around. (Even though the "b.rkt"-submodule required
>> in "a.rkt" does *not* require anything from "b.rkt", and other way around.)
>>
>> Examples:
>>  * seems to work: https://gist.github.com/Glorp/c36bcb3af0d8586ec733
>>  * doesn't seem to work:
>> https://gist.github.com/Glorp/86e59ced2bd838d2161c
>>
>> --
>> 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 question on begin and call-by-value

[Eduardo Bonelli]

Dear William,

 You are quite right.
 Sorry for the silly question and thanks for the quick reply.
 E.

On Friday, January 8, 2016 at 6:05:35 PM UTC-3, William J. Bowman wrote:
> ((lambda x x) (void)) returns a list containing the void object. Perhaps you 
> meant (lambda (x) (begin x))?
> 
> --
> William J. Bowman

-- 
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] Counterintuitive performance results

[Andrew Kent]

Any guesses why adding more indirection speeds up the code here?

#lang racket

(define (set-members? s . xs)
  (for/and ([x (in-list xs)])
(set-member? xs x)))


(define s (set-add
   (for/set ([i (in-range 1000)])
 (random 1))
   333))

(collect-garbage)
(time (for ([i (in-range 100)])
(set-member? s 333))) ;; slower

(collect-garbage)
(time (for ([i (in-range 100)])
(set-members? s 333))) ;; faster

Best,
Andrew

-- 
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 question on begin and call-by-value

['William J. Bowman' via Racket Users]

On Fri, Jan 08, 2016 at 12:58:14PM -0800, Eduardo Bonelli wrote:
> Hello,
> 
>  Why do the values of these two expressions differ?
> 
> > (begin (void))
> > ((lambda x (begin x)) (void))
> '(#)
> 
>  In the second case, I understand that CBV would evaluate the argument 
> "(void)" to obtain the (untyped) value "#". It then passes this on to 
> the function "((lambda x (begin x))", resulting in "(begin #)". So why 
> does this not evaluate to #?
((lambda x x) (void)) returns a list containing the void object. Perhaps you 
meant (lambda (x) (begin x))?

--
William J. Bowman

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


signature.asc
Description: PGP signature

Re: [racket-users] Counterintuitive performance results

[Pierpaolo Bernardi]

I tried swapping the two expressions. The result is that the one
executing first is always slower than the one executing second.

So, probably the timing is dominated by some memory/GC/locality effect
rather than the difference between set-member? and set-members?


On Fri, Jan 8, 2016 at 10:29 PM, Andrew Kent  wrote:
> Any guesses why adding more indirection speeds up the code here?
>
> #lang racket
>
> (define (set-members? s . xs)
>   (for/and ([x (in-list xs)])
> (set-member? xs x)))
>
>
> (define s (set-add
>(for/set ([i (in-range 1000)])
>  (random 1))
>333))
>
> (collect-garbage)
> (time (for ([i (in-range 100)])
> (set-member? s 333))) ;; slower
>
> (collect-garbage)
> (time (for ([i (in-range 100)])
> (set-members? s 333))) ;; faster
>
> Best,
> Andrew
>
> --
> 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] Simple question on begin and call-by-value

[Eduardo Bonelli]

Hello,

 Why do the values of these two expressions differ?

> (begin (void))
> ((lambda x (begin x)) (void))
'(#)

 In the second case, I understand that CBV would evaluate the argument 
"(void)" to obtain the (untyped) value "#". It then passes this on to the 
function "((lambda x (begin x))", resulting in "(begin #)". So why does 
this not evaluate to #?

 E.

-- 
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] Can I cross-compile racket code?

[DonRyuDragoni]

My major problem is Mac, actually. We do have a Windows machine, I just prefer 
to code on Linux.

 And, of course, it would make things easier if I could run one command and 
wait until all executables are created.

-- 
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] Counterintuitive performance results

[Alex Knauth]

I tried doing stuff, but then I realized that there's a typo that messes this 
up.

> On Jan 8, 2016, at 4:29 PM, Andrew Kent  wrote:
> 
> Any guesses why adding more indirection speeds up the code here?
> 
> #lang racket
> 
> (define (set-members? s . xs)
>  (for/and ([x (in-list xs)])
>(set-member? xs x)))

This should have been (set-member? s x), right?

> 
> (define s (set-add
>   (for/set ([i (in-range 1000)])
> (random 1))
>   333))
> 
> (collect-garbage)
> (time (for ([i (in-range 100)])
>(set-member? s 333))) ;; slower
> 
> (collect-garbage)
> (time (for ([i (in-range 100)])
>(set-members? s 333))) ;; faster
> 
> Best,
> Andrew
> 
> -- 
> 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] Counterintuitive performance results

[Andrew Kent]

On Friday, January 8, 2016 at 4:40:05 PM UTC-5, Alex Knauth wrote:
> I tried doing stuff, but then I realized that there's a typo that messes this 
> up.
> 
> > On Jan 8, 2016, at 4:29 PM, Andrew Kent  wrote:
> > 
> > Any guesses why adding more indirection speeds up the code here?
> > 
> > #lang racket
> > 
> > (define (set-members? s . xs)
> >  (for/and ([x (in-list xs)])
> >(set-member? xs x)))
> 
> This should have been (set-member? s x), right?
> 
> > 
> > (define s (set-add
> >   (for/set ([i (in-range 1000)])
> > (random 1))
> >   333))
> > 
> > (collect-garbage)
> > (time (for ([i (in-range 100)])
> >(set-member? s 333))) ;; slower
> > 
> > (collect-garbage)
> > (time (for ([i (in-range 100)])
> >(set-members? s 333))) ;; faster
> > 
> > Best,
> > Andrew
> > 
> > -- 
> > 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.

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

[David Storrs]

I'm having some trouble with the syntax for regexen, and the docs are a bit
opaque on this point.

Given this:

(regex-match*
#px"\[[xX\d]\]"
"[1] foo \n [2] bar \n [x] baz \n [X] baz \n"")

I'm expecting it to return:

( "[1]" "[2]" "[x]" "[X]")

Instead it complains about undefined identifiers.

For that matter, I can't even get it to use a simple \d class.

-> (regexp-match (pregexp "\\d") "2349803")  ;; try with two \\ because
it's a string
(regexp-match (pregexp "\\d") "2349803")
")\n(regexp-match (pregexp "
; |\d|: undefined;
;  cannot reference undefined identifier
; [,bt for context]
") "
2349803
-> (regexp-match (pregexp "\d") "2349803")  ;; try with one \
(regexp-match (pregexp "\d") "2349803")
")\n(regexp-match (pregexp "
; d: undefined;
;  cannot reference undefined identifier
; [,bt for context]
") "
2349803
-> (regexp-match #px"\d" "2349803")   ;; try with a literal, one \
(regexp-match #px"\d" "2349803")
")\n(regexp-match #px"
; d: undefined;
;  cannot reference undefined identifier
; [,bt for context]
" "
2349803
-> (regexp-match #px"\\d" "2349803")  ;; try with a literal, two \\
(regexp-match #px"\\d" "2349803")
")\n(regexp-match #px"
; |\d|: undefined;
;  cannot reference undefined identifier
; [,bt for context]
" "
2349803

What is the correct syntax here?

Related question:  Perl has a capacity to change your delimiters on regexen
in order to avoid having to backwhack everything.  For example, these all
work:

Matching:
m/foo/
m!foo!
m{foo}

Substituting:
s/foo/bar/
s!foo!bar!
s

Is there a way to get Racket to do the same thing?

Thanks for your help, folks; I can't believe I'm having to ask about this,
but I've been hammering on it with no success.

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

[David Storrs]

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?


Thanks again for the help with the syntax stuff.

Dave



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

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

[Alexis King]

> 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”).

When telling someone to avoid something useful, it is nice to also point to a 
superior replacement. I agree that many uses of regular expressions could be 
better served by something more robust, but what does Racket have to offer in 
this department?

The first thing that comes to my mind is Stephen Chang’s parsack[1], a Racket 
implementation of Haskell’s parsec. There’s also Danny Yoo’s ragg[2] for 
parsing grammars described with extended BNF. I’ve also found a GLL[3] 
“implementation” of sorts, which looks very interesting, but isn’t a package 
and seems to present itself mostly as a tutorial. Finally, there’s the old 
parser-tools[4] package, but that’s pretty heavyweight.

For a system with such a powerful ability to extend the language in arbitrary 
ways, it seems odd that Racket would provide so few tools for parsing simple 
text.

[1]: http://pkg-build.racket-lang.org/doc/parsack/index.html
[2]: http://pkg-build.racket-lang.org/doc/ragg/index.html
[3]: https://github.com/epsil/gll
[4]: http://docs.racket-lang.org/parser-tools/index.html

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

[Neil Van Dyke]

David Storrs wrote on 01/09/2016 02:34 AM:



What method would you suggest for that?


Probably regular expression. :)

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.

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

[Neil Van Dyke]

Matthew Flatt wrote on 01/08/2016 10:54 PM:

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


One thing that might need attention, in light of that... 
"https://pkgs.racket-lang.org/; currently makes third-party HTTPS 
requests to "code.jquery.com" and "fonts.googleapis.com", for trusted 
page contents.  Two implications:
* information leak to a third party who is in the business of intimate 
cross-site and cross-media profiling of individuals;
* additional points of vulnerability, such as capturing login 
credentials of package authors, or tricking an interactive user into 
installing a trojan package, if "code.jquery.com" was compromised.


For a security-sensitive site, I would instead:
* eat the additional cost to host needed jQuery and jQuery UI bits 
ourselves; and
* (in the case of Racket site) either forget about downloadable custom 
fonts, or use custom fonts that can be hosted ourselves.



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.


I would only force HTTPS on the more security-sensitive bits, such as 
packages and login-required stuff.  Forced HTTPS everywhere, OTOH, is 
actually anti-privacy, in a way that doesn't matter practically for the 
Racket site, but that is a sneaky practice in industry, and so shouldn't 
be endorsed to impressionable students.


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

[刘海宽]

Hi, I have a problem when upload file through http post method. Here is my code:

#lang racket
(require net/uri-codec)
(require net/url)
(require json)
(require net/http-client)

(define (->string bs)
  (if (bytes? bs)
  (bytes->string/utf-8 bs)
  bs))

(define (->bytes str)
  (cond
[(string? str)
 (string->bytes/utf-8 str)]
[(not str)
 #""]
[else
 str]))

(define post
  (lambda (url data header)
(call/input-url url
(lambda (url header)
  (post-impure-port url data header))
port->string
header)))

(define CRLF "\r\n")
(define boundary "-RacketFormBoundaryf1nfLeDGcfc30oHf")

(define data
  (bytes-append
   (->bytes (string-append
 "--" boundary CRLF
 "Content-Disposition: form-data; name=\"resource_name\"" CRLF
 "And360" CRLF
 "--" boundary CRLF
 "Content-Disposition: form-data; name=\"version_name\"" CRLF
 "1.1.8" CRLF
 "--" boundary CRLF
 "Content-Disposition: form-data; name=\"file\"; 
filename=\"And360.zip\"" CRLF
 "Content-Type: application/zip" CRLF))
   (->bytes (string-append CRLF "--" boundary "--" CRLF CRLF
(define header (list (string-append "Content-Type: multipart/form-data; 
boundary=" boundary)))

(post (string->url "http://www.resource-upload.com/upload; data header))


And server response is

HTTP/1.1 500 Internal Server Error

Server: Apache-Coyote/1.1

X-Application-Context: application:production

Content-Length: 0

Date: Sat, 09 Jan 2016 01:53:29 GMT

Connection: close

Can anyone help me, where is wrong?

Thanks a lot.

LHK

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

[Neil Van Dyke]

One problem is that you should have *two* CR-LF byte sequences to 
terminate the header list in each MIME multipart part.


For example, instead of:

"--" boundary CRLF
"Content-Disposition: form-data; name=\"file\"; 
filename=\"And360.zip\"" CRLF

"Content-Type: application/zip" CRLF))

do:

"--" boundary CRLF
"Content-Disposition: form-data; name=\"file\"; 
filename=\"And360.zip\"" CRLF

"Content-Type: application/zip" CRLF
CRLF))

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.


Also, I assume that you will eventually include the file content for 
your "And360.zip" file part.


Also, consider whether you want the file part to be disposition `file` 
or `attachment` rather than `form-data`.


I think you are close to succeeding, although you might have to solve 
some other small problems as you work through it.  If you get stuck, be 
sure to read both the W3C and IETF/RFC specs, and then try to mimic one 
of their message examples exactly.  After you have one of their examples 
working, you can generalize your code to do what you want.


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

[Matthew Flatt]

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

[Robby Findler]

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

[Robby Findler]

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

[Robby Findler]

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?

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

Re: [racket-users] warning on use trie functions in #lang racket?

[Sam Tobin-Hochstadt]

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

[Sam Tobin-Hochstadt]

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

-- 
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 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 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] Cycle in loading. Units, (sub)modules, files...

[Daniel Feltey]

This doesn't quite answer your question, but another possibility that would
allow you to separate the a@ and b@ unit implementations in separate files
is to put all of your signature definitions in a single file that will be
required by both "a.rkt" and "b.rkt". In my experience, this strategy is
fairly common in uses of units in the Racket codebase (for example see
https://github.com/racket/games/blob/master/gobblet/sig.rkt).

Dan

On Wed, Jan 6, 2016 at 8:16 AM, Jonas Winje  wrote:

> Hello people,
>
> I've been fumbling around with cyclic dependencies and such and have
> started looking at signatures and units. I manage to make the cycles work
> out in a couple different ways, but I'm running into trouble when I try to
> put different parts in different files the way I want them. As far as I can
> tell it has to do with how much of a file/module is "loaded" if I really
> just want to require one of its submodules. Not particularly certain.
>
> It's pretty possible that I'm just doing everything wrong and backwards,
> or should really not be trying to do this to begin with, or something :)
>
> So: Does anyone know if it is possible to do something along the lines of
>
> - a.rkt with two submodules:
> - a-sig: provides signature a^
> - a-impl:
> - requires a-sig
> - requires b-sig from b.rkt
> - provides unit a@ (which imports b^ and exports a^)
> - b.rkt with two submodules:
> - b-sig: provides signature b^
> - b-impl:
> - requires b-sig
> - requires a-sig from a.rkt
> - provides unit b@ (which imports a^ and exports b^)
>
> without getting
>
> standard-module-name-resolver: cycle in loading
>   at path: ...\dep\b.rkt
>   paths:
>...\b.rkt
>...\a.rkt
>
> ?
>
> I get it to work by putting all 4 modules in the same file. And I get it
> to work by putting them in 4 different files. But if I want one file for
> both the a-things and one for both the b-things I get the error above.
> Presumably because (a submodule in) "a.rkt" requires (a submodule from)
> "b.rkt", and other way around. (Even though the "b.rkt"-submodule required
> in "a.rkt" does *not* require anything from "b.rkt", and other way around.)
>
> Examples:
>  * seems to work: https://gist.github.com/Glorp/c36bcb3af0d8586ec733
>  * doesn't seem to work:
> https://gist.github.com/Glorp/86e59ced2bd838d2161c
>
> --
> 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] warning on use trie functions in #lang racket?

[Asumu Takikawa]

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

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

[Sam Tobin-Hochstadt]

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