[racket-users] [ANN] Rebellion collection libraries: multisets, multidicts, and association lists, oh my!

[Jack Firth]

The rebellion  package 
recently acquired a few new collection libraries:

   - rebellion/collection/multiset 
    - A library for 
   *multisets*, which are like sets that can contain duplicate values
   - rebellion/collection/multidict 
    - A library for 
   *multidicts,* which are like hashes from keys to sets of values
   - rebellion/collection/association-list 
    - A 
   library for *association lists*, which are like hashes from keys to 
   lists of values
   - rebellion/collection/entry 
    - A small 
   supporting library that defines an (entry key value) struct, in order to 
   make it clearer when a pair is being used as a key-value mapping rather 
   than as an arbitrary pair

All of the new collection types are immutable, but they don't (yet) support 
efficient persistent updates (e.g. there's no multiset-add function yet). 
These libraries are currently in early alpha versions, so not much beyond 
the basics is implemented and their APIs might change without warning. Let 
me know what you think and please feel free to file feature requests and 
bugs in the rebellion github repository 
!

-- 
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/f954d1a4-fc88-4fc6-9103-58837bc02c26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] managing competing access to filesystem within places

[Matthew Butterick]

> On 06 22 19, at 6:14 AM, Robby Findler  wrote:
> 
> One thing you can do, when the place-specific communication takes
> multiple steps is to, like you did in the first example, put the
> channels into a hash, but then on each iteration of the loop, pull all
> of them out and put them into a giant select that takes the relevant
> step forward for that specific piece of the communication

Not sure what you mean by "giant select" — ought that be "giant sync"? But as 
for "sequential access to some shared state" — In this toy example, maybe more 
along the lines of your suggestion, the server makes a random sequence of 
workers and triggers the workers in turn, so none of them are ever working at 
the same time. (So they could, in principle, all be writing to a single file.) 

I can imagine a more nuanced version involving each worker chekcing out sets of 
files, and the server permitting progress by more than one worker at a time, so 
long as the file sets didn't overlap.


#lang racket
(require racket/place racket/dict)
(provide main)

(define (main)
  (define server-p
(place sch
   (define wp-dict (place-channel-get sch))
   (let loop ()
 (define wp-dict-shuffled (shuffle wp-dict))
 (displayln (format "order: ~a" (dict-keys wp-dict-shuffled)))
 (for ([(widx wp) (in-dict wp-dict-shuffled)])
   (displayln (format "server: start ~a" widx))
   (place-channel-put wp widx)
   (apply sync (dict-values wp-dict)))
 (loop
 
  (define worker-ps
(for/list ([i (in-range (processor-count))])
  (place wch
 (let loop ()
   (define widx (place-channel-get wch))
   (sleep 0.2)
   (displayln (format "worker ~a: done" widx))
   (place-channel-put wch 'done)
   (loop)

  (place-channel-put server-p (for/list ([(wp widx) (in-indexed worker-ps)])
(cons widx wp)))
  
  (for-each place-wait worker-ps))

-- 
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/54475D15-78B1-4F3A-A06C-35739DFCBC57%40mbtype.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Request for Feedback (SQL, Plisqin)

[Ben Greenman]

I don't know if I understood the "Aggregates are self-contained" section. The
SQL looks self-contained, as long as you read the whole query. And one has to
read the whole query in the Plisquin version too (but definitions come first).

In the last section, I'm not sure what a "scalar" or "plural join" are.

-- 
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/CAFUu9R7K79i5dghC%3DG2aT1AepKBuc2CHnsKNUeGdanHRwXn47w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Relative Pathname problem

[Ben Greenman]

I tried to reproduce this problem, but wasn't able to.

Which version of Racket are you using? How did you run the program?

On 6/20/19, Amir Teymuri  wrote:
> I have the following situation:
>
> mylibrary:
>
>-src
>   - font.rkt
>   - gui.rkt
>- scratch.rkt
>
>
> So the src/ directory and the scratch.rkt file live in the same directory
> mylibrary/. According to the documentation of Modules
> (https://docs.racket-lang.org/guide/module-basics.html):
>
> The "sort.rkt" module uses the relative paths "db/lookup.rkt" and
> "machine/control.rkt" to import from the database and machine-control
> libraries...
>
> So i put these lines in my scratch.rkt:
>
> #lang racket
>
> (require "src/font.rkt"
>  "src/gui.rkt")
>
> but upon requiring the modules i get the error:
>
>
>
> (require "src/font.rkt"
>  "src/gui.rkt")
>
> Error: struct:exn:get-module-code
>
> get-module-code: no such file: #
>
> Why is Racket putting another src/ before the actual src/ directory?
>
> Thanks,
> Amir
>
> --
> 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/ed560f1e-93df-4835-ad62-0d8b76cd8ed6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAFUu9R7bg%3DO3jLJwSK%3D37pO%3D8NbdVBbET%2Bn0LFMDKvtopLti2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] managing competing access to filesystem within places

[Robby Findler]

Thanks!

One thing you can do, when the place-specific communication takes
multiple steps is to, like you did in the first example, put the
channels into a hash, but then on each iteration of the loop, pull all
of them out and put them into a giant select that takes the relevant
step forward for that specific piece of the communication (you use
handle-evt to wrap the successful communication with the state update
and then the call to `loop` back for some other step or of
(potentially) some other communication).

The advantage to this kind of setup is that you have sequential access
to some shared state that is kept entirely on the server side. So  you
completely avoid the conventional pitfalls of mutable state combined
with concurrency.

For example, if your main loop was the one that was parcelling out,
say, files to compile, you could keep a list of the pending files to
compile on the server and when each worker finished with a file or
encountered a new file, it would let the server know and the server
would tell it what to do, eg "oh, wait, someone else is compiling that
file" or "go ahead, I've noted that you're the one that's compiling
that file and I'll tell others who also need it to wait for you to
finish". And the latter case, the worker that was waiting would also
get an evt that would become ready when the file was finish compiling
(which would also be mediated through the server).

Robby


On Fri, Jun 21, 2019 at 11:02 PM Matthew Butterick  wrote:
>
>
>
> On 06 15 19, at 8:31 AM, Robby Findler  wrote:
>
> A standard way to work with this is to send a channel over in the
> first communication and then the communication that's specific to that
> initial request happens on that channel. The precise way you set this
> up depends on what invariants of the communication you want. Like, you
> can create a new thread and just do all the communication there
>
>
>
> And here's a threaded version, which I agree is neater, because by closing 
> over each worker channel, the threads make other channel-tracking 
> housekeeping unnecessary.
>
> #lang racket
> (require racket/place)
> (provide main)
>
> (define (main)
>   (define loopback-p
> (place lch
>(let loop ()
>  (define wp (place-channel-get lch))
>  (thread (λ () (let loop ()
>  (place-channel-put wp (place-channel-get wp))
>  (loop
>  (loop
>
>   (define worker-ps
> (for/list ([i (in-range (processor-count))])
>   (place wch
>  (let make-request ([count 1])
>(define countout (place-channel-put/get wch count))
>(displayln (format "worker request ~a:~a got response ~a:~a ~a"
>   0 count 0 countout
>   (if (eq? count countout) "" "### fail")))
>(make-request (add1 count))
>
>   (for ([worker-p (in-list worker-ps)])
> (place-channel-put loopback-p worker-p))
>
>   (map place-wait worker-ps))
>
> --
> 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/A5055051-898C-46F9-82C6-BD0A50AC4D20%40mbtype.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOMxQpQWTiCgvirzy9_gAvUxdbSxTdxurMwnuSGHTThQfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.