Re: [racket-users] Historical note.

2020-11-09 Thread jackh...@gmail.com
I'm glad, I didn't expect my comment to be so helpful :)

For those curious, I have several examples of this pattern in Rebellion. 
The following constructs are all just structs of functions:

   - Comparators 
   - Converters 
   - Equivalence relations 
   
   - Reducers 
   - Transducers 

On Monday, November 9, 2020 at 2:03:52 AM UTC-8 unlimitedscolobb wrote:

> On Monday, November 9, 2020 at 1:51:05 AM UTC+1 Kieron Hardy wrote:
>
>>
>> > On Nov 8, 2020, at 2:58 PM, Hendrik Boom  
>> wrote: 
>> > 
>> >> On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote: 
>> >> The idea of having structs whose fields contain functions has never 
>> occurred to me ... 
>> > 
>> > Historical note: 
>> > 
>> > I first encountered structures containing function in the source code 
>> for 
>> > OS/360 way back in the late 60's. In assembler. 
>> > 
>>
> Structures with fields containing functions has never occurred to me 
>> before, either, at least not in those terms. 
>>
>> However isn’t that exactly one of the key design principles behind how 
>> device-drivers are implemented and installed into an OS? And also how 
>> classes and objects were initially added to C as some pretty hairy #define 
>> macros and function pointers? 
>>
>> This design pattern insight would have been beneficial to me sooner - 
>> doh! 
>>
>>  
> I completely share your feelings Kieron.  In fact, I have already defined 
> structures with functions in the fields multiple times and in many 
> programming languages, but I have never thought how this pattern could be 
> used to implement generic-like functionality :D
>
> Thank you Hendrik for the historical note!
>
> -
> Sergiu
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/15dc0d41-dbd2-488a-9113-31c284443ce4n%40googlegroups.com.


[racket-users] Re: Generics vs. Classes?

2020-11-08 Thread jackh...@gmail.com
The typical use case for classes in Racket is writing GUIs, and that's 
mostly because the GUI framework is class based.

For most other use cases, generics are a better choice than classes. 
They're simpler and have a less intrusive effect on your API surface. If 
you don't need to support arbitrary user implementations, you can avoid 
generics and classes altogether and use structs whose fields contain 
functions.

On Sunday, November 8, 2020 at 6:12:37 AM UTC-8 unlimitedscolobb wrote:

> Hi,
>
> A general knowledge question: what would be the typical use cases of 
> Racket generics vs. the typical use cases of Racket classes?
>
> Am I correct in assuming that I can do everything with classes what I 
> could do with generics, and that generics have made their way into the 
> language before the classes?
>
> -
> Sergiu
>
> P.S. I'm reading the section on classes in the updated Typed Racket 
> reference, and I'm very happy to see this new functionality!  Very good job 
> the Typed Racket Team!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/dc76fceb-9829-4356-a2fe-0d340fef9c43n%40googlegroups.com.


[racket-users] Re: Help implementing an early return macro

2020-11-04 Thread jackh...@gmail.com
A brief update on this: I went with Ryan's approach and used an 
implementation of guarded-block throughout Rebellion's codebase. You can 
see the diff here: https://github.com/jackfirth/rebellion/pull/466. A 
couple of things to note:

- I added a define/guard form that's like define, but with the function 
body implicitly wrapped with guarded-block.
- I tweaked the syntax of guard to allow either (guard  else 
 ...) or (guard  then  ...). If else is used, the 
guard is taken if the condition is false. If then is used, the guard is 
taken if the condition is true. This made it easier to organize my code 
such that the short-circuiting precondition checks came before what I 
considered to be the main branch of the function. With just the else case, 
sometimes I had to awkwardly negate things.

There's a few problems related to robustness I'd like to figure out 
eventually, before documenting this macro and publicly exposing it:

- It allows shadowing. If a variable is defined both before and after a 
guard statement, the definition after shadows the one before it, instead of 
raising a duplicate definition error.
- If any definitions raise syntax errors, the error is reported in terms of 
the expanded define-values form instead of the definition the user actually 
wrote.
- The last body form of a guarded block shouldn't be allowed to be a guard 
statement, and a good error message should be raised if a user does that. 
The current implementation doesn't check for that.

The last one is pretty easy to fix, but the other two I'm not sure how to 
fix.

On Sunday, November 1, 2020 at 1:04:15 PM UTC-8 gneuner2 wrote:

> On Sat, 31 Oct 2020 03:25:32 -0700 (PDT),
> "jackh...@gmail.com"
>  wrote:
>
> >Wow, these are a lot of great responses. First of all, *awesome* job 
> Ryan. 
> >That implementation is exactly what I needed to figure out. I'm 
> definitely 
> >starting there first.
> >
> >> Are you looking for `let/ec`?
> >
> >I'd forgotten about that one. That has the *syntax* I want. However my 
> >issue with continuation-based approaches isn't the syntax, or even the 
> >performance. It's the semantics. What if someone writes code like this?
> >
> >(guarded-block
> > (define x (random 10))
> > (thread
> > (lambda ()
> > (guard (even? x) else #false)
> > ...)))
> >
> >If I implemented guarded-block in terms of let/ec, then what does this 
> code 
> >even *do*? I honestly don't know. It would probably run without error and 
> >do... something. 
>
> (let/ec return
> (thread
> (lambda ()
> (return -1)
> 42)))
>
> throws an error: "continuation application: attempt to jump into an
> escape continuation"
>
> There is a continuation barrier between the threads.
>
>
> However, let/cc works: e.g.,
>
> (let/cc return
> (thread
> (lambda ()
> (return -1)
> 42)))
>
> returns -1.
>
>
> >I am extremely sure that regardless of what it did, it 
> >would be confusing and it wouldn't solve any problem I had. 
>
> I am sure it would solve *some* problems.
>
>
> >I just flat out don't want to allow this or any related nonsense, 
> >such as:
> >
> >; Aliasing
> >(define return guard)
> >
> >; Higher-order usage
> >(map guard (some-list ...))
> >
> >; Capturing via closure
> >(guarded-block
> > (define (check-foo x) (guard (foo? x) else #false))
> > (check-foo ...)
> > ...)
> >
> >; Capturing via mutation
> >(set! previous-guard guard)
> >
> >; Oh great, now I have to think about even more continuation jumps
> >(dynamic-wind
> > (lambda () (guard ...))
> > (lambda () ...)
> > (lambda () ...))
> >
> >There might be valid use cases for some of these, but I certainly don't 
> >understand those use cases well enough to commit to a semantics for them.
>
> It always is safe to jump upwards OUT of a lower level computation.
> The sticky issues [and mental gyrations] with continuations all have
> to do with jumping downwards or sideways.
>
> I'm not sure what problems you might have with continuation barriers:
> the example of the thread shows that (upward-only) "escape"
> continuations don't work across threads ... but "full" continations do
> work, and would still work even if the threads were siblings rather
> than in a parent/child relationship.
>
> The issue for your purpose would be making sure the continuation is
> called from a position that is guaranteed to terminate the errant
> thread: you might need to recognize a thread as a special case, wrap
> it and (like an exception) catch/rethrow the continuation.
>
>
> Or, if you don't care about sibling threads, just use exceptions which
> always can be thrown upward out of child threads.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/d7714f66-d791-4ec8-a1c1-da8a9c761caen%40googlegroups.com.


[racket-users] Re: large hash/dc errors (was: Contracts for (partially) specifying dictionary key -> value-predicates)

2020-10-31 Thread jackh...@gmail.com
I have the same issue for ->i contracts. I'll write multiple #:pre/desc 
checks with nice messages, which are promptly rendered useless by the fact 
that ->i prints out the whole contract instead of just the precondition 
check that failed.
On Friday, October 30, 2020 at 7:16:59 PM UTC-7 Ben Greenman wrote:

> > Ben: if you have an example of the bad hash/dc error message I'd be
> > interested to see it.
> >
> > Robby
>
> Here's the kind of message that turned me off:
>
> ```
> ctc.rkt:34:0: broke its own contract
> promised: (hash/dc (k (or/c (quote a) (quote b) (quote c))) (v (k)
> (config-value/c k)) #:immutable #t #:kind (quote flat))
> produced: '#hash((a . 1) (b . #t) (c . #))
> in: (hash/dc
> (k (or/c 'a 'b 'c))
> (v (k) (config-value/c k))
> #:immutable
> #t
> #:kind
> 'flat)
> contract from: +
> blaming: +
> (assuming the contract is correct)
> ```
>
> It prints the whole hash and contract, leaving me to figure out the
> two key parts: (1) what piece of the hash failed, and (2) what the
> contract expected for that piece.
>
> Now that I think of it ->* is bad in the same way --- especially for
> `plot` functions.
>
>
> Here's the code that made that error message. The #;(lambda )
> comment is the contract that I ended up using instead of hash/dc (it
> still doesn't explain bad values well).
>
> ```
> #lang racket/base
>
> (require racket/contract)
>
> (provide config/c)
>
> (define config-key/c
> (or/c 'a 'b 'c))
>
> (define (config-value/c k)
> (case k
> ((a)
> string?)
> ((b)
> boolean?)
> ((c)
> void?)))
>
> (define config/c
> #;(lambda (h)
> (for ((k (in-list (list 'a 'b 'c
> (unless (hash-has-key? h k)
> (raise-arguments-error 'config/c "missing key" "key" k "hash" h))
> (define v (hash-ref h k))
> (unless ((config-value/c k) v)
> (raise-arguments-error 'config/c "bad value for key" "key" k
> "value" v "hash" h))
> (void)))
> (hash/dc
> [k config-key/c]
> [v (k) (config-value/c k)]
> #:immutable #true
> #:kind 'flat))
>
> (contract
> config/c
> (hash 'a 1 'b #true 'c (void))
> '+
> '-)
> ```
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3b0ed32b-4875-4cfa-9b2b-e4398e4318d1n%40googlegroups.com.


Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates

2020-10-31 Thread jackh...@gmail.com
I'm not sure, but I have a feeling Ben's suggestion to make them functions 
instead of macros wasn't about the performance implications of macros. I 
think it was about this particular symmetry:

- A (list 1 'apple "banana") is a (list/c number? symbol? string?)
- A (hash 'a 1 'b "foo") is a (dictof 'a number? 'b string?)

That is, when the keys are known statically, all the functions for creating 
dictionaries and hashes typically go with a flat and alternating sequence 
of key-value arguments. I think a contract combinator for dicts where the 
keys are known should have the same shape.

One other point: dictof is a confusing name. We would have list/c and 
listof, vector/c and vectorof, and hash/c and dictof. And the first two 
pairs would make the exact opposite decision as the third pair about which 
name is for the heterogeneous known-size case and which is for homogeneous 
collections.

Honestly I'd suggest naming it heterogeneous-dict/c. The contract will 
almost always span multiple lines no matter how long a name you pick, and 
I'm sick and tired of guessing which one of list/c, listof, *list/c, and 
list*of is the one I actually want. Words are underrated.
On Friday, October 30, 2020 at 12:43:02 PM UTC-7 William J. Bowman wrote:

> Thanks for the feedback! Some of these were not concerns for my use case, 
> so I’ll do a bit more design before submitting something.
>
> -- 
> Sent from my phoneamajig
>
> > On Oct 30, 2020, at 12:36, George Neuner  wrote:
> > 
> > 
> >> On 10/30/2020 3:08 PM, William J. Bowman wrote:
> >> Let me aid this discussion by copying in the ~10 lintes of code in 
> question:
> >> 
> >> > (define-syntax (dictof syn)
> >> > (syntax-parse syn
> >> > [(_ (k:id pred?) ...)
> >> > (quasisyntax/loc syn
> >> > (dictof/proc `((k . ,pred?) ...)))]))
> >> > > (define ((dictof/proc spec) h)
> >> > (and (eq? (dict-keys h) (dict-keys spec))
> >> > (for/and ([(k pred?) (in-dict spec)])
> >> > (pred? (dict-ref h k)
> >> 
> >> The macro is merely a syntactic transformation to 1 line of code that 
> implements
> >> the functionality of the contract at run-time.
> >> Is there some reason to avoid macros in this particular case?
> > 
> > There's rarely any problem with macros that only provide syntactic sugar.
> > 
> > The issues wrt contracts are how heavy are the dictionary functions. The 
> FOR loop is concerning because the check time is proportional to the size 
> of the dictionary [again recalling that contracts live on in release code].
> > 
> > For performance it would be better to enforce the predicate on values as 
> they are entered, and then assume anything already in the dictionary is 
> correct. It is sensible to provide a function that validates the whole 
> dictionary, but I would make it something the programmer has to invoke 
> deliberately rather than a contract to be enforced at (even just 1st in 
> module) mention of the dictionary.
> > 
> > YMMV,
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/95997336-33d4-5c5b-b329-9ea691fe59ef%40comcast.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3de9c8ac-fa4f-44c3-8ce1-dcf041ecb8c1n%40googlegroups.com.


Re: [racket-users] Re: Help implementing an early return macro

2020-10-31 Thread jackh...@gmail.com
Wow, these are a lot of great responses. First of all, *awesome* job Ryan. 
That implementation is exactly what I needed to figure out. I'm definitely 
starting there first.

> Are you looking for `let/ec`?

I'd forgotten about that one. That has the *syntax* I want. However my 
issue with continuation-based approaches isn't the syntax, or even the 
performance. It's the semantics. What if someone writes code like this?

(guarded-block
  (define x (random 10))
  (thread
(lambda ()
  (guard (even? x) else #false)
  ...)))

If I implemented guarded-block in terms of let/ec, then what does this code 
even *do*? I honestly don't know. It would probably run without error and 
do... something. I am extremely sure that regardless of what it did, it 
would be confusing and it wouldn't solve any problem I had. I just flat out 
don't want to allow this or any related nonsense, such as:

; Aliasing
(define return guard)

; Higher-order usage
(map guard (some-list ...))

; Capturing via closure
(guarded-block
  (define (check-foo x) (guard (foo? x) else #false))
  (check-foo ...)
  ...)

; Capturing via mutation
(set! previous-guard guard)

; Oh great, now I have to think about even more continuation jumps
(dynamic-wind
  (lambda () (guard ...))
  (lambda () ...)
  (lambda () ...))

There might be valid use cases for some of these, but I certainly don't 
understand those use cases well enough to commit to a semantics for them.

As for why not use condd, cond/else, or parendown: because they don't look 
right. Specifically, I often write code like this:

(define (f x y z)
  ... a few lines of checking preconditions ...
  ... a dozen or two lines of actual useful logic ...)

I don't want to indent the useful logic a bunch. That's the most important 
part of the function - the preconditions are minor things that you should 
be able to skim over and forget about. If my functions without 
preconditions look wildly different from my functions with preconditions, 
it becomes difficult to tell what the main focus of a function is. Not to 
mention that going from zero preconditions to one (and from one to zero) 
now introduces a bunch of busywork.

On naming: I like the symmetry between return-when / return-unless and when 
/ unless, but the problem is the word "return". If I call it a return 
statement, people will naturally expect this to work:

(define (first-owl animals)
  (for ([animal animals])
(return-when (owl? animal) animal)))

I don't want to have to explain why that doesn't work forty times.

The names guard-when and guard-unless are kind of ambiguous; does 
"guard-when" mean "when this condition is true, enter this guard block and 
escape" or does it mean "guard the function with this condition, if it 
fails enter the block and escape". Does "guard" mean "prevent this 
condition" or "ensure this condition"? Having two forms means you have to 
remember which one means which and figure out a way to keep them straight. 
I'd rather just have one form so there's only one way to do it, and you can 
teach yourself that "ah yes, guard always means 'make sure this is true'".

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3607a1a0-e303-4d9d-a62e-c958712aa2c8n%40googlegroups.com.


[racket-users] Re: hash-filter: PR or not PR

2020-10-31 Thread jackh...@gmail.com
This is definitely a useful thing to have and I've wanted it myself before. 
However I'm generally of the opinion that we should avoid making more 
collection manipulation functions that are unnecessarily specialized to one 
type of collection. I'd like to see functions that operate on all sequences 
rather than on hash tables alone. Here are some usages of hash-filter 
compared with some existing alternatives:

(hash-filter ht #:predicate pred)
==
; Sequence composition
(make-immutable-hash
 (sequence->list
  (sequence-filter (lambda (pair) (pred (cdr pair)))
   (sequence-map cons ht
==
; For macros
(for/hash ([(k v) (in-hash ht)] #:when (pred v)) (values k v))

The for macro is probably what I'd reach for in standard racket code. It 
has some drawbacks: the first time I tried to write it I forgot to write 
(values k v) and instead just wrote v. Keeping track of pulling apart the 
key and value, naming them with variables, and putting them back together 
is a little annoying.

The sequence composition approach is, in my humble opinion, completely 
unreadable and difficult to write to boot. The sequence-map function works 
totally fine on multivalued sequences but sequence-filter only works on 
single-value sequences, so we have to do a dance with cons car and cdr to 
turn the multivalued sequence of keys and values into a single-valued 
sequence of key-value cons pairs. Furthermore, the only built-in function 
for building a hash table from a sequence is overly specialized to lists, 
so you have to copy the sequence into a list solely so you can turn that 
list into a hash table with make-immutable-hash.

Instead of adding hash-filter to racket/hash, I think there's a few 
improvements we could make to the sequence composition side of things:

- Make sequence-filter allow multivalued sequences, provided the arity of 
the predicate is consistent with the arity of the sequence.
- Add a sequence->hash function that accepts a multivalued sequence of keys 
and values (exactly like what in-hash produces) and copies them into a hash 
table.

For the filter-by-value, filter-by-key, and filter-by-key-and-value cases, 
this lets us write:

(sequence->hash (sequence-filter (lambda (k v) (pred v)) ht)) ; Filter 
values
(sequence->hash (sequence-filter (lambda (k v) (pred k)) ht)) ; Filter keys
(sequence->hash (sequence-filter pred ht)) ; Filter key-value pairs

Which is close enough to hash-filter to satisfy my desire for conciseness, 
while still being general enough to work with other kinds of key-value 
sequences.

Shameless self plug: you might be interested in Rebellion 
's take on this, which 
uses transducers  and key-value structs called entries 
:

(transduce (in-hash-entries ht) (filtering-values pred) #:into into-hash) ; 
Filter values
(transduce (in-hash-entries ht) (filtering-keys pred) #:into into-hash) ; 
Filter keys
(transduce (in-hash-entries ht) (filtering (lambda (e) (pred (entry-key e) 
(entry-value e #:into into-hash) ; Filter key-value entries
On Friday, October 30, 2020 at 4:35:31 PM UTC-7 unlimitedscolobb wrote:

> Hi,
>
> I am currently using hash tables a lot, so inevitably I end up writing 
> general functions.  I wrote the following `hash-filter`:
>
> ```
> (define (hash-filter
>  ht
>  #:predicate [predicate #f]
>  #:predicate/key [predicate/key
>   (if predicate
>   (λ (_ v) (predicate v))
>   (error 'hash-filter))])
>   (for/fold ([filtered-pairs (hash-clear ht)])
> ([(k v) (in-hash ht)])
> (if (predicate/key k v)
> (hash-set filtered-pairs k v)
> filtered-pairs)))
> ```
>
> Before I submit a pull request to the Racket repository, I would like to 
> know whether adding this function to `racket/hash` is a good idea, or 
> whether I should create a separate package with extra functions for hash 
> tables.
>
> -
> Sergiu
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/98498f48-9d02-4f4e-91fd-ab85bf6d765an%40googlegroups.com.


Re: [racket-users] Re: Memory usage of (port->lines ...) is extreamly high

2020-09-29 Thread jackh...@gmail.com
I'm also guessing the jump from 600MB to 3GB is related to encodings. The 
file is probably UTF8/ASCII, and racket strings are a different encoding. I 
think they're one of the 32-bit encodings? So for ASCII text that alone 
would be a factor of four increase in memory usage.

On Thursday, September 24, 2020 at 5:55:48 AM UTC-7 Sam Tobin-Hochstadt 
wrote:

> port->lines produces a list with all the lines in it. That list is what 
> uses all the memory. Using in-lines avoids producing the whole list at 
> once. 
>
> Sam
>
> On Thu, Sep 24, 2020, 8:53 AM Hong Yang  wrote:
>
>> Thanks Laurent, I tried (in-lines...), and yes, it's memory-efficient, 
>> but I still curious and concern why (port->lines ...) takes so many memory.
>>
>> Best regards
>> Hong
>>
>> On Thursday, September 24, 2020 at 6:55:10 PM UTC+8 laurent...@gmail.com 
>> wrote:
>>
>>> Quick comment: of you don't need to load the whole file but want to 
>>> parse it line by line, use `in-lines` which is memory-efficient.
>>>
>>> On Thu, Sep 24, 2020, 11:46 Hong Yang  wrote:
>>>
 Update with memory dump log attached.

 1. With out (set! input empty), call (collect-garbage) doesn't help
 2. Call (set! input empty) and (collect-garbage), memory reduce 
 dramaticly.

 ; 214M(VIRT)/101M(RSS) without open any file
 (let loop()
   (sleep 5)  ; Waiting here so that I can check it via top/ps
   (dump-memory-stats)
   (collect-garbage)
   (set! input empty)  ; Even not help with this line, it works after 
 called (collect-garbage) explicity.
   (loop))

 On Thursday, September 24, 2020 at 6:14:55 PM UTC+8 Hong Yang wrote:

> Hi Racketer
>
> I'm trying to load a log file which size is 600MB, then I found the 
> program exhausted 3 GB resident memory just for load all the content of 
> it 
> via (port->lines...). I do have enough RAM but it looks like some thing 
> went wrong here, and I do need to load them all into RAM for my use case 
> so 
> (read-line ...) doesn't help me.
>
> Any comment would be preciated.
>
> Here is may programe:
>
> #!/usr/bin/racket
> #lang racket
>
> ; Load input as list of lines
> (define (input-load-lines file-name)
>   (if (file-exists? file-name)
>   (let* ([input (open-input-file file-name)]
>  [lines (port->lines input)])
> (close-input-port input)
> lines)
>   empty))
>
> ; Racket 7.8, compile from source code, (none cs mode)
> ; 100M of log requires 0.5G runtime memory
> ; 300M of log requires 1.5G runtime memory
> ; 600M of log requires 3.0G runtime memory
> ;
> ; Reference
> ;   racket/collects/racket/port.rkt :106
> ;   racket/collects/racket/private/portlines.rkt :11
>
> (define input (input-load-lines "main.log"))
>
> ; 214M(VIRT)/101M(RSS) without open any file
> (let loop()
>   (sleep 5) ; Waiting here so that I can check it via top/ps
>   (set! input empty) ; event not help with this line
>   (loop))
>
> Thanks
> Hong
>
 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/racket-users/07c41b96-87ba-473a-ad0e-0cec71dc4024n%40googlegroups.com
  
 
 .

>>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/f761c588-da7e-43d4-9b05-b917f64f4b52n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/4b11510f-fb14-496b-b7be-b52abfa37982n%40googlegroups.com.


Re: [racket-users] Why is get-impure-port* slower than a system call to curl?

2020-09-15 Thread jackh...@gmail.com
Curl supports http/2 (and even has experimental support for http/3 which is 
orders of magnitude faster than http/1.1. Depending on what protocols the 
server you're talking to supports, that could be part of it.

On Monday, September 14, 2020 at 3:42:37 PM UTC-7 samdph...@gmail.com wrote:

> Hi Stephen,
>
> I ran this small benchmark against a remote web server, and was
> definitely getting better response using the http-easy module.
>
> https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778
>
> $ racket -e '(require (submod "http-perf.rkt" curl))'
> cpu time: 768 real time: 35299 gc time: 0
>
> $ racket -e '(require (submod "http-perf.rkt" http-easy))'
> cpu time: 1810 real time: 17316 gc time: 70
>
> On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster  
> wrote:
> >
> > Finally circling back to this issue. I've disabled debugging in DrRacket 
> and also done a test outside of DrRacket. It's still slow. :(
> >
> > I also tried the newer HTTP client: 
> https://docs.racket-lang.org/http-easy/index.html. Like the others, it is 
> also slow.
> >
> > I'll do some more digging. I'm currently trying to figure out if this is 
> a "just me" / "just my system" problem. So... I'd be grateful if anyone who 
> has written code that sends HTTP requests from Racket could chime in with: 
> 1) I can confirm that sending HTTP requests from Racket has always been 
> fast for me, or 2) I too have noticed Racket HTTP requests are slow.
> >
> > (Note that by "slow", I mean: takes noticeably longer than curl.)
> >
> >
> >
> > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri  wrote:
> >>
> >> Hi Stephen,
> >>
> >> Your video shows you running this code in DrRacket with debugging
> >> enabled. That usually affects performance. Have you made measurements
> >> when running this code outside of DrRacket?
> >>
> >> - Jon
> >>
> >>
> >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster  
> wrote:
> >> >
> >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm 
> using http requests to have Unreal Engine and Racket talk to each other.
> >> >
> >> > When I use the http/request library, Racket fires off its GET request 
> much slower than if it were to do a system call to curl. (Same is true if I 
> use simple-http, which makes me think the problem might be a deep one.)
> >> >
> >> > Here's a video to demo the issue. Notice how, with curl, the 
> experience is playable, whereas with the Racket function, there's way too 
> much time between the spell landing and the effect occurring:
> >> >
> >> > https://youtu.be/jTqUFVlfBFA
> >> >
> >> > Obviously, I'd like to do things in a Rackety way. But I'm not above 
> doing things the silly way. I'd just be grumpy about it.
> >> >
> >> > Any ideas?
> >> >
> >> >
> >> >
> >> > --
> >> > 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...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com
> .
> >
> >
> >
> > --
> >
> >
> > Stephen Foster
> > ThoughtSTEM Co-Founder
> > 318-792-2035 <(318)%20792-2035>
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/1c8664fa-e8f2-49c8-8417-101dd7186231n%40googlegroups.com.


Re: [racket-users] package manager woes on Windows 10?

2020-09-12 Thread jackh...@gmail.com
Could we make the "do what I mean" box just automatically strip any 
newlines pasted into it? It seems sensible to me to require that it only be 
a single line input.

On Friday, September 11, 2020 at 6:22:59 AM UTC-7 hen...@topoi.pooq.com 
wrote:

> On Thu, Sep 10, 2020 at 10:27:39AM -0400, George Neuner wrote:
> > 
> > 
> > On 9/10/2020 10:06 AM, Philip McGrath wrote:
> > > Also, this is happening over encrypted HTTPS: no one is sniffing the
> > > User-Agent header.
> > 
> > While it may not be the issue here, you need to understand that appliance
> > firewalls CAN and routinely DO examine data inside encrypted connections.
>
> Using man-in-the-middle attacks?
>
> -- hendrik
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/84b16cf0-7837-4d54-9423-c1286f5e2b7an%40googlegroups.com.


[racket-users] Re: hashcons

2020-09-12 Thread jackh...@gmail.com
Not automatically, but you can make your own wrapper function around cons 
that interns them using a weak hash table and then you can use that wrapper 
function everywhere.

On Thursday, September 10, 2020 at 7:34:37 PM UTC-7 hen...@topoi.pooq.com 
wrote:

> Is there a way to run Racket so that every immuable cons is made with 
> a hashcons operation; i.e. it makes a new cons scel only if there 
> isn't already one in memory somewhere with the same car and cdr 
> values?
>
> -- hendrik
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/7ed721c9-4ed2-47eb-b8bb-a30a1ed9125fn%40googlegroups.com.


[racket-users] Re: Pretty Printing for ASTs represented as structs

2020-08-16 Thread jackh...@gmail.com
I recommend using make-constructor-style-printer 
,
 
which automates a lot of the fiddly indentation-handling you'd have to do 
otherwise.
On Sunday, August 16, 2020 at 1:48:50 PM UTC-7 jerem...@gmail.com wrote:

>
> Hi All,
>
> I'm looking into using Racket structs to represent abstract syntax trees.
> I've gotten as far as defining gen:custom-write properties, but have not
> yet figured out how to control indenting. Also, I'm not sure I'm just 
> calling
> write-string, write, and newline in my gen:custom-write methods, which I
> suspect is not exactly correct.
>
> Are there some good up-to-date examples of this that I could look at?
>
> Thanks,
> Jeremy
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f11193f4-9fb5-43fd-a54e-f5ebb5c9bb69n%40googlegroups.com.