Greetings racketeers, does anyone here have a good familiarity with using subprocess under Windows? I’m experimenting with it but it doesn’t seem to operate the way I’m expecting. Even my simplest example doesn’t seem to work so I’m trying to understand where I’m going wrong.

(define-values (sp in out err) (subprocess #f #f #f "dir"))

when I execute that in a REPL on my Windows machine, I expect to receive the current working directory’s listing in the output port in the in variable but when I do (read-line in) I only get #<eof> (subprocess-status sp) gives me 0 so seems nothing is amiss, except I’m not getting the output of the dir command. Even when I subprocess a command that I expect to take several seconds to run, as verified by directly executing it on the command-line, the subprocess returns immediately with a status of 0 and nothing given on the output port.

Would appreciate any examples for using subprocess under Windows. Interestingly when I create a batch script file containing the desired command and call that directly via subprocess, it works so does that mean it only works with executable files as opposed to command strings?

I’ve discovered process binding in racket/system and it does the job

Reading process source code has told me the proper way to use subprocess to handle command-line execution. have to explicitly call cmd.exe first before passing to it additional command strings. I had been assuming that subprocess automatically called the default OS shell which in fact is not the case at all.

@abmclin the ‘system’ function does that

@samth indeed it does but its behavior is synchronous which is not what I want

the commands I’m executing has the potential to fail to complete so don’t want to block my Racket app on a command that may not return

You might want to put it in a thread

oh that’s a good idea then I’d just sync/timeout on a channel between the main and the inferior thread

that should do the trick

Hey @mflatt, I’m trying to make a completely new (base) namespace inside of a macro. According to the macro stepper the scopes seem to be in the right phase, but it still complains about app not being bound.

So far, my code is:

#lang racket
(define-syntax (f stx)
  (current-namespace (make-base-namespace))
  (define stx (datum->syntax #f '(+ 1 2)))
  (syntax-shift-phase-level (namespace-syntax-introduce stx) -1))

(f)

The error is:

+: unbound identifier;
 also, no #%top syntax transformer is bound in: +

And a screenshot of the stepper is:

Bleh, stupid slack, the screenshot is at the top.

Anyway, @michael.ballantyne and I have been trying to figure it out.

Oh, also @lexi.lambda IIRC, you were trying to do something similar with hackett, yes?

I guess using module->namespace instead of make-base-namespace, solves the problem. But I don’t know why.

#lang racket
(define-syntax (f stx)
  (current-namespace (module->namespace 'racket/base))
  (define stx (datum->syntax #f '(+ 1 2)))
  (syntax-shift-phase-level (namespace-syntax-introduce stx) -1))

(f)

@leif I don’t think I do anything quite like that in Hackett. I don’t try and mix runtime namespaces with expander-time scopes.

Ah, okay. Well thanks anyway. :slightly_smiling_face:

Is there a way to override inferred package name which is based on directory name and provide a canonical name in info.rkt? For example, if I have a directory called a-directory performing raco pkg install in that directory will cause raco to install a pkg called a-directory I would prefer to use a canonical name fancy-pkg that doesn’t bear any relation to what the directory happens to be called such so raco pkg install will instead install fancy-pkg. I was hoping that putting (define name "fancy-pkg") in the info.rkt within the directory would do the trick, but alas seems not.

@abmclin no, packages installed with --link but not --name will always attempt to infer the name

but, on the other hand, as long as you specify the collection in the info.rkt file, the package name is largely irrelevant

hmm I’ll experiment with using —name. The package name may be largely irrelevant but due to combination of how things are organized in terms of git repository/packages, the actual directory naming and desired package names are unfortunately not syncing up in a nice way

so I was hoping to get around that by using info.rkt metadata to enforce preferred package names in spite of what the directory organization happens to be

in any event, not a huge deal, it can be solved by changing directory naming scheme

ok raco pkg install --name fancy-pkg does what I wanted so I’m happy now

@leif Putting a top-level context on an identifier and then moving the identifier into a module is indeed strange, and it triggers a “fallback” mechanism for dealing with awkward top-level interactions. Also, it turns out that the first example works in plain Racket, but not with errortrace’s re-expansion (as used by DrRacket). A module->namespace namespace is more module-like and gives the expander more of a sure footing. I haven’t worked out exactly how hopeless the variant with the top-level namespace is. Is the application interesting and something that should be supported better?

@mflatt Ah, okay. I hadn’t realized that make-base-namespace was top-level like. module->namespace seems to be working.

I guess if I really wanted to dynamically create a module like namespace, I could use make-base-namespace to create a module, and then use that module’s namespae.

namespace*

But if using the namespace returned by (module->namespace 'racket/base) isn’t bad, I can just use that.

Thanks. :slightly_smiling_face:

@leif: I think what was top-level like was namespace-syntax-introduce, not make-base-namespace

Wait no I was wrong; didn’t read the entire conversation

FWIW, my completely uninformed intuition was that namespaces were essentially a reflective mechanism, and that namespace-syntax-introduce would not necessarily make sense outside the scope of a piece of syntax passed to eval, but in retrospect, that assumption might have been wrong. Just when I think I understand Racket’s syntax model, I find out something new…

I thought that the namespace scope introduced by namespace-syntax-introduce is the same regardless of where the namespace come from, but > Except for namespaces generated by a module (see module->namespace), every namespace uses the same scope as the one added to all phase levels, … and > [module->namespace] Returns a namespace that corresponds to the body of an instantiated module …

So it could be that the ‘namespace scope’ for module->namespace namespaces is module scope. I don’t know if we can describe this with `reflexive operations inmodule->namespace` namespaces starts in module context while reflexive operations in other namespaces starts in top-level context’’.