Is there any way to perform structural matching for elements in a sequence. For example, for an assoc list: for ([(k . v) alist]) ...

?

@pocmatos if you’re not really concerned about performance, in-dict might meet your needs

if you’re looking at something that doesn’t have all the associated overhead that comes with the generic dict operations, I’ve thrown together an in-assoc that seems to work well for us in TR:

https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/utils/utils.rkt#L413

I think I assumed you were specifically talking about association lists for some reason… I’m not aware of a “generic” way to match on the lhs of a for-loop iteration clause

You may find in-value in a for* variant a useful way to bind things before entering the body of the loop

@pnwamk I will take a look at in-dict. that would be fine since these is unit test code. but yes, I am interested in this specific case in alists.

Why is in-assoc not available in normal racket?

no one has added it?

I don’t know

perhaps it has been intentionally not added because of the existence of primitive hash tables and the available (and efficient) in-hash functions? (I’m totally speculating! It could just be as simple as no one has bothered to ask/submit a PR)

@pnwamk ok, thanks

I want to call an executable in a synchronous subprocess and control its standard ports (stdio, stdout and stderr). Here’s what I got:

(define in (open-input-string "<my-input>"))
(define out (open-output-string))
(parameterize ([current-input-port in]
               [current-output-port out]
               [current-error-port out])
  (system* "<command>" "<arguments>" "..."))
(begin0
  (get-output-string out)
  (close-input-port in)
  (close-output-port out))

Is there a form that encapsulates this pattern? I searched among the with-* forms from racket/port to no success. Thanks in advance.

process?

http://docs.racket-lang.org/reference/subprocess.html?q=system

Or some other form in the racket/system section perhaps?

(unless you’re talking about that very specific pattern, and I’m just pointing you to the functions you’re already aware of — if so sorry! =)

Thanks for the answer, but those aren’t what I’m looking for. I want something that allows me to treat an executable more or less like a string → string function.

I built my abstraction for what I want:

(define ((system*→λ command . arg) input/string)
  (define in (open-input-string input/string))
  (define out (open-output-string))
  (parameterize ([current-input-port in]
                 [current-output-port out]
                 [current-error-port out])
    (apply system* command arg))
  (begin0
    (get-output-string out)
    (close-input-port in)
    (close-output-port out)))

> ((system*→λ "/bin/cat") "abc")
"abc"

Please let me know if there’s a better way to achieve this or if there are reasons why I shouldn’t be doing it at all :stuck_out_tongue:

@leafac I like that abstraction! Though often its easier to work with system*’s boolean result which tells you if the command exited successfully or not instead of trying to analyze what was emitted to output. In that case it could be string -> boolean string if you want multiple values or could be string -> Listof boolean string

Another thing, there’s always the possibility that the command won’t complete so system*->λ won’t return. Not sure if you’re thinking of using it with another mechanism like sync/timeout or will you be handling that within system*->λ itself?

by won’t complete, I meant the command doesn’t exit at all, instead it diverges

My purpose is to use the result of system*->λ in the REPL, so I don’t have to worry about divergence :slightly_smiling_face:

indeed, in that case, no need to worry about that

Thank you for bringing up these issues, though.

no problem, I often use system and its cousins in my scripts for automating building artifacts so I might borrow your new abstraction, it’s easier to reason about

I’m glad it might help you.

@mflatt question about define-runtime-path — my understanding was that it should prevent absolute paths from occurring in zo files, but there are some where it does, such as scriblib/book-index.rkt

the issue seems to be this call: (path->collects-relative "/home/samth/sw/plt/racket/share/pkgs/scribble-lib/scriblib/unknown")

which just produces that path again

That does seem wrong. Possibly, the path should be preserved as a path (insteda of a byte string) so that it gets made relative in the usual way for paths in bytecode.

I don’t actually understand why we’re in that case, though, since it should only happen if (syntax-source stx) doesn’t give us a path, which shouldn’t happen there

I’m not sure how you arrived at that conclusion, but from a quick look, it seems like line 44 of “collects/racket/private/this-expresson-source-directory.rkt” may be the place to change. (I didn’t try it.)

@samth just peeking out of curiosity… on line 187 of runtime-path.rkt, it appears to copy lexical context but not source location information.

@lexi.lambda aha, that would explain it

that fixes that problem