Is anyone able to estimate how many person-week would be required to have a much more user friendly package server? I think it’s lacking a lot of validation and user feedback mostly.

@jbclements This happened to me many times when I tried to enter my packages. :disappointed: A workaround for me was to leave tags and description empty and add them after the package was in the database. Don’t ask me why it worked then.

I entered a ticket at https://github.com/racket/racket-pkg-website/issues/76

Thanks so much! This workaround worked for me. I added a bump to your issue, many thanks.

Just wanted to note I had the exact same thing happen to me when adding the canvas-list package last week, First time the fields just reset, no messages, and I couldn’t find it after 15 (or so) minutes. So I tried again and the second time worked. If I happened to do something different, I have no idea what it was.

The following code crashes with some(most) JPEGs I try to load, but I’ve never seen it crash with a PNG of GIF. It almost seems like the jpeg insert is spawning a thread and it crashes when I try to close the input port. (define img (make-object image-snip% (gopher-response-data-port resp) 'unknown)) (send page-text erase) (send page-text insert img) (send page-text set-position 0) (close-input-port (gopher-response-data-port resp)) Here’s the error: ; internal error: attempt to deschedule the current thread in atomic mode ; Context (plain; to see better errortrace context, re-run with C-u prefix): ; /usr/local/racket/collects/racket/private/port.rkt:113:0 copy-port ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/unsafe/callback.rkt:75:0 sanitize-input-port ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/unsafe/jpeg.rkt:630:3 ; /usr/local/racket/collects/ffi/unsafe/alloc.rkt:80:14 ; /usr/local/racket/collects/ffi/unsafe/atomic.rkt:73:13 ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/private/bitmap.rkt:455:4 do-load-bitmap/dispatch/known method in bitmap% ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/private/bitmap.rkt:424:4 do-load-bitmap/port method in bitmap% ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/private/syntax.rkt:234:25 ; /usr/local/racket/share/pkgs/draw-lib/racket/draw/private/bitmap.rkt:170:2 ; /usr/local/racket/collects/racket/private/class-internal.rkt:3590:0 continue-make-object ; /usr/local/racket/collects/racket/private/class-internal.rkt:3590:0 continue-make-object ; /usr/local/racket/collects/racket/private/class-internal.rkt:3565:0 do-make-object/real-class ; /usr/local/racket/share/pkgs/snip-lib/racket/snip/private/snip.rkt:1099:2 load-file method in image-snip% ; /usr/local/racket/collects/racket/private/class-internal.rkt:3590:0 continue-make-object ; /usr/local/racket/collects/racket/private/class-internal.rkt:3590:0 continue-make-object ; /usr/local/racket/collects/racket/private/class-internal.rkt:3565:0 do-make-object/real-class

Well, I tested removing the close-input-port call and that didn’t solve the crash. This crash wasn’t happening in an earlier version, but this code is now running in its own thread and I may have changed some other things as well since then.

Perhaps ‘make-object image-snip%’ is spawning a thread? It seems like a low-level problem, but please let me know if there are any gotchas with regard to using image-snips.

It looks like the JPEG reader is broken. It’s attempting to use sanitize-input-port to read all the data from the port — so it can use that data in a context that has to run in atomic mode. But the function that does that is itself put in atomic mode by an allocator wrapper. So, it runs into exactly the problem that it’s trying to avoid.

I may have been running 8.0cs when I initially tested the jpeg code. I’m on 8.1cs now, so potentially this was introduced then.

It’s CS-specific, but I don’t know whether v8.1 made it worse than v8.0 somehow.

I mean that it may have been introduced in 8.1cs, because I think it was working in 8.0cs. Or else something else about my program changed to exacerbate the issue.

Either way, it looks like you have a handle on it. I can file a bug if you’d like me to.

Is it a particular jpeg or all?

If you need a workaround meanwhile, I think you can copy the input port to a pipe, and use the new read of the pipe instead of the original port. (Don’t forget to close the write end of the pipe.)

Most of them. It seems like really small jpegs load at least some of the time.

Really small is about 20KB in this case.

I’ve pushed a repair. Thanks for the report!

Great. Thanks!

hopefully simple question: how can I use string-split to split on (the regex of any repeats of whitespace \s or the null zero character \u0000)?

(i.e., I want to write #rx"\\s+\|\\u0000", but it doesn’t seem to be working)

I think you want #px"\\s+\|\u0000" — p instead of r, and no extra \ before \u.

thanks! I think the docs for this are a bit unhelpful: the only bit I could find regarding null zero was at https://docs.racket-lang.org/reference/regexp.html?q=regexp#%28part._regexp-syntax%29, which shows

which seems to be an incomplete expression…

"\u0000" or just "\0" is a string with a nul character, and regexps are encoded with string literals. So, #px"\u0000" matches a nul character in the same way that #px"a" matches the letter “a”.

right; I think I’d tried \0 with two slashes, and got a backreference, or something like that. But regardless, in the screenshot of the docs above, it shows a bare backslash with nothing whatsoever after it — is that correct?

I had definitely forgotten that #px"\\" matches a nul character. That must have been grandfathered in due to a bug somewhere.

Keep in mind that all the gray-background stuff in the regexp description shows literal characters, not the way those characters have to be encoded as a string.

You’re right that "\\0" would be a (useless) backreference in #px mode, and it’s a literal 0 in #rx mode. There’s no end of ways to be confused with this syntax and variant.

Ooh, sounds like a good time to ask: is there any interest in supporting Olin Shivers’ SRE regexp syntax or something vaguely similar? I did just add Alex Shinn’s irregex package to the package server, so there’s at least some way to get the job done, but it did seem strange to me that there’s no way to construct regexps in Racket that doesn’t involve string hygiene challenges.