I believe it is up?

hm, clicking “save changes” saves the version exception but the website eventually 502’s

Hi. Would it be possible to match against a hash (hash “a” 1 “b” 2 …) with syntax-parse?

My aim is to create a macro that rewrites (hash “a” 1 “b” 2 “c” 3 …) to [a 1] [b 2] [c 3] …

@redwynskaja yes, you’d want a pattern like (hash (~seq key val) ...)

hmm i feel like i already tried that.

This just gives a very unspecific syntax error: unpack-hash: bad syntax in: (unpack-hash pars) #(476 18)

that’s because pars isn’t that

And for testing i am just doing #’’key …

pars is an identifier

i defined (define pars (hash …))

what does (unpack-hash (hash ...)) do?

macros don’t look at what you defined it to be

they match the syntax of the arguments

which here is just an identifier

it does what i expect …

That works :_( so i was confused.

so a macro can not access anything i defined as described?

right

because the pars only exist at runtimeß

?

Thanks for clearing my understanding and the issue up :grinning:

yes, that’s correct

How can I wait on an input port until there are bytes to consume? I see the eof-evt but that’s the opposite of what I need… I want to basically do a blocking read on an input port.

Blocking read? But read, read-bytes etc block as standard.

you might also be interested in read-bytes-evt

@soegaard2 doesn’t look like it, read is returning eof when there’s nothing in the fileport.

that surprises me

“A port can be used as a synchronizable event. An input port is ready for synchronization when read-byte would not block…” (from http://docs.racket-lang.org/reference/ports.html)

@samth but you need to set a certain number of bytes to read. i use fasl->s-exp to read from the port.

is it a standard file or a file-stream-port ?

@ryanc thanks, interestingly that seems to imply read blocks but not the way I am seeing it…

@soegaard2 that’s a file-stream-port from a subprocess.

hmm

it won’t (or at least shouldn’t) return eof unless the other end of the port is genuinely closed.

ok, let me do some further experimentation to see what’s happening…

@lexi.lambda oh… good one, it might be closed in my specific example since the process died.

yes, if the process is dead, and you’ve read everything that was in the port, then it would return #<eof>.

I’m seeing a behavior with local Racket installations I don’t understand why is happening.

To give a brief overview, I’m seeing this on a Windows machine, I have an existing test suite for an application. When I use a local Racket installation extracted from a current minimal release tar file downloaded from http://racket-lang.org\|racket-lang.org to run the suite, the test suite runs much slower compared to when the system Racket installed via standard Window installer is used to run the test suite; consistently an average of 5 mins versus 46 seconds test suite runtime when using local versus system Racket. I figure it’s probably an issue with zo files not being used even though the the tar file is bundled with zo files. When I run raco setup over the local racket installation, the test suite runs much faster, achieving parity with the system Racket times.

This has been the case for a while, across several Racket versions now. It was a nonissue, I had other things to worry about. Recently I copied the local Racket installation and the test suite to another location, when I reran the test suite, it ran much slower which surprised me. All of the source and zo files in the copied local Racket installation are identical to the original one yet the copied test suite is taking multiple minutes to complete instead of less than one minute as I had been expecting.

If I run raco setup again over the copy, the test suite runs quickly again. I find this puzzling, are zo files sensitive to their filesystem locations? Is there a reason why copying a Racket tree to another location would result in a behavior that suggests zo files are no longer being loaded?

@abmclin my initial guess is that the timestamps are off somewhere

Racket won’t use .zo files that are out of date

so if the .rkt file is newer than the .zo file, then it won’t use the .zo file

ok so maybe the copying process is copying zo files before rkt files which could account for that. It’s odd though, why would Windows copy zo files first before rkt files?

I don’t know

but that’s what I would look for if this happens again

I guess it shows that I cannot depend on the static relationship of files and their timestamps to be preserved across copies

again, I don’t actually know if this is what happened to you

but it’s a theory

I’m going to see if I can prove or disprove the theory

@samth ok if I make arrangements for the original timestamps to be preserved when copying the original local Racket installation and the test suite files, the runtime does not suffer, so this would be evidence in support of your theory. My additional supplemental guess is that unless sufficient care is taken, the order of which zo and rkt files are copied may be nondeterministic.

so it’s something for me to be aware of for the future

Or unless it is the current-read-interaction of certain #langs, which delimit expressions with eof :grin:

But that’s not a port, so yeah.