@philip.mcgrath Yes, agreed on that the delay until GC can be too long when using many files. For me, it’s only one file for now.

Regarding my use case, http://pasterack.org/pastes/40341 , I have a calculation and want to write some results to a file (second version in the paste; of course later the displayln would go to the file). This gets ever more convoluted, and I hoped I could get rid of the with-output-to-file , use a plain open-output-file and close the file implicitly later.

At the moment, I’m instead considering storing the data in a list (even if that means that I temporarily use “a lot of” memory) and at some later point write the data to a file in one go, i. e. not mixing file I/O with the solver code.

For this, I need to check whether it’s feasible to keep the data in memory instead of writing it as it becomes available.

After experimenting with (current-memory-use), it seems for “reasonable” cases it should be able to fit the data in memory, especially if I use a byte vector for each list item. (Each list item contains three non-negative integers below 90.)

@mflatt @robby ^ Crashes are usually something you two are interested in.

Yes, thanks! I was able to replicate the crash, and I’ll investigate more.

Some ideas:

You could accept an optional caller-provided port: (define (solve-board board [out (open-output-nowhere)]) (parameterize ([current-output-port out]) ...)) Then you can use all the I/O functions as normal.

You could use a logger, in the sense of log-message. A particularly nice convenience is that there are macros to avoid doing the I/O if no one’s listening.

For maximum flexibility, you could do something custom with the synchronizable event system and send values rather than do I/O per se. For example, you could accept an optional asynchronous channel. Some ways of starting the Racket webserver do that, reporting either an exception or the port number, or neither if the caller didn’t provide a #:confirmation-channel: https://docs.racket-lang.org/web-server-internal/web-server.html#(def._((lib._web-server%2Fweb-server..rkt)._serve))

Repair pushed as 6d30ff78c14072ce5388a659a9d3415d2249d222

@gregor.kiczales@greg406 I watched <https://www.youtube.com/watch?v=hjg5pHw33rY&list=PLi6VoEKYdlE39FKNE-oz0Z6LYqdmymTss&index=11|Gregory Kiczales’s lecture in RacketFest 2021 Amateur Night> and it seems that he might have taken the <https://docs.racket-lang.org/handin-server|handin package> and expanded on it. Or maybe he developed something from scratch? I don’t know. I’d love to know more about it and try it out too. Does anybody know if his work is open source or whether I could try it myself somehow? (By the way, it’s been at least various days I watched the video. I hope I didn’t miss any link presented in the lecture. I don’t think there is, though.)

My impression is that they did start with the handin server, but they’re not yet ready to publish and maintain those changes/improvements.

Hi all, we (@alexharsanyi) are trying to track down an issue related to screen coordinates on multi-display systems (https://github.com/alex-hhh/gui-widget-mixins/issues/3) and wondered if anyone here is running with multiple monitors who could run the following code so we can see what get-display-left-top-inset returns on those systems). In particular we need coverage for macos and anyone running weird linux setups perhaps with the nvidia proprietary driver (to see if I’m the only one that has negative offsets on the first monitor). Thanks! (begin (require racket/gui) (define (get-display-info) (append (list (system-type 'os*) (system-type 'gc) (version) (get-display-count)) (for/list ([monitor (in-range (get-display-count))]) (let-values ([(x y) (get-display-size #:monitor monitor)] [(dx dy) (get-display-left-top-inset #:monitor monitor)]) (list monitor x y dx dy))))) (get-display-info))

'(linux cs "8.0.0.11" 2 (0 1920 1080 -1200 -370) (1 1200 1920 0 0))

I have airplay connecting to a TV. Does that work?

Welcome to DrRacket, version 8.0 [cs]. Language: racket, with debugging; memory limit: 512 MB. '(macosx cs "8.0" 3 (0 1920 1057 0 22) (1 1440 877 1440 -158) (2 1920 1057 -1920 22))

Are the last numbers related to the screen arrangement?

Yes, they are the dimensions and offsets.

Welcome to DrRacket, version 8.0.0.11--2021-03-08(e45cd87/a) [3m]. '(windows 3m "8.0.0.11" 2 (0 1920 1080 0 0) (1 1920 1080 0 1080))

and it looks like macos does have different behavior from the other systems

'(macosx cs "8.0" 2 (0 1440 799 0 24) (1 1920 1055 1920 204))

'(linux cs "8.0" 2 (0 1920 1080 0 0) (1 1366 768 -1920 -113))

But if I change the arrangement, I get this instead

'(macosx cs "8.0" 2 (0 1440 799 0 24) (1 1920 1055 -1440 163))

@sorawee can you see what happens if you change the primary monitor?

Does the placment of the white bar affect the numbers?

:slightly_smiling_face:

@soegaard2 it seems so, and that is what we were trying to understand

I assume that the 22 for your system is a 22 pixel wide bar at the top

Sorry, I just turned off the TV and the WIFI, and it will take a while to get everything back up again, and I want to go to bed. It looks like @soegaard2 has a Mac too, so maybe he can help? But if not, I will be able to help again tomorrow.

Have you found the documentation at http://develeoper.apple.com\|develeoper.apple.com ?

@sorawee no hurry!

'(macosx cs "8.0" 3 (0 1920 1057 0 22) (1 1440 877 1440 -158) (2 1920 1057 -1920 22)) '(macosx cs "8.0" 3 (0 1440 877 0 22) (1 1920 1057 -3360 202) (2 1920 1057 -1440 202)) '(macosx cs "8.0" 3 (0 1920 1057 0 22) (1 1440 877 3360 -158) (2 1920 1057 1920 22)) Same arrangement – 3 different primary screens.

@soegaard2 it is mentioned in <https://docs.racket-lang.org/gui/window__.html?q=client-%3Escreen#%28meth.%28%28%28lib._mred%2Fmain..rkt%29._window~3c~25~3e%29._client-~3escreen%29%29|the racket docs>, I’m trying to figure out whether/how to determine whether those offsets are relevant if the gui window is on a separate head, also thanks, very helpful

Thanks for the suggestions, although I have the impression that the latter is far too much complexity for this use case. :slightly_smiling_face: But of course it may be interesting for future projects. It seems there’s a lot to discover.

@tgbugs https://developer.apple.com/documentation/coregraphics/1456599-cgdisplayscreensize

I don’t know if this is relevant - but I am surprised millimeters are mentioned here.

@soegaard2 probably not, given the racket implementation here https://github.com/racket/gui/blob/d1fef7a43a482c0fdd5672be9a6e713f16d8be5c/gui-lib/mred/private/wx/cocoa/procs.rkt#L105-L128, which does suggest that the menubar offset is already handled (if I’m reading that right)

One more suggestion: You could write to a string port (open-output-string) from your program, and then copy the output to a file at the very end. That may reduce your memory use significantly compared to keeping lots of objects live until the end.

@tgbugs Btw the “visible frame” doesn’t include the dock either.

Or likewise a pipe (as in make-pipe, not the OS version), avoiding the intermediate string.

My current (“updated”, i. e. until I update it further :wink:) plan: Store triplets, u8vectors, in a gvector ( https://docs.racket-lang.org/data/gvector.html ), so I can append new values at the end in constant time. (Lists only support adding items in constant time at the front, right?) According to my estimates, the memory consumption should be ok with this approach. (If not, it will have been a nice exercise. :wink:) Something else I’m thinking of: Eventually I want to feed this data (but only with the guesses that allowed a continuation of the chain) to Graphviz, and Graphviz, as far as I know, also needs to read everything into memory. So there’s little point in using a stream-style interface for the data generation (unless I’d run Graphviz on a different computer with much more memory, but that’s not planned). I try to find a balance between being flexible for “largish” amounts of data on the one hand and over-engineering on the other hand. :slightly_smiling_face:

> but only with the guesses that allowed a continuation of the chain I also think I will store only these in the gvector to begin with. So although I can’t calculate the number of guesses (successful or not) from the collected data, I can, for example, calculate the distribution that I currently store in recursion-stats.

So my Solver-Result will contain a Progress-Data instance instead of the current recursion-stats and I’ll provide a function to calculate the recursion stats from the progress data. (But that’s only tangential to the discussion so far.)

Using the handin-server, I’m getting [-\|2021-04-15T16:50:38] ERROR: ssl-accept/enable-break: accept failed (error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca) I guess this means my certificate is self-signed? This used to work, but this time I’m trying it out with DrRacket 8.0, so maybe that’s not possible anymore. The handin button in DrRacket has the [hostname] http://active.thriveim.com\|active.thriveim.com hardcoded. I’m using my Windows hosts file to point this hostname to localhost. I wonder if this could be the problem too. I see the connections taking place but as soon a connection arrive I see that error above and the connection fails in DrRacket. Just wondering if anyone knows of anything that could save the day here.

Win10 machine at work: (windows cs "8.0" 3 (0 1620 1040 0 0) (1 1920 1080 -7080 -627) (2 3072 1728 -3240 0))

The log that you posted has the line “Verification error: self signed certificate”, but s_client ignores verification errors by default. See the manpage for s_client, specifically the paragraph in NOTES about the -verify_return_error option. Also, -cert and -key are not the right options for testing the server certificate; they are for client certificates instead, which are rarely used. Try using -CAfile server-cert.pem instead.

Hi @tgbugs,it seems that there is a bug in the way get-display-left-top-inset works on Linux with NVidia TwinView — in particular, your system should only have one virtual monitor (according to the TwinView docs anyway), so get-display-left-top-inset #:monitor 1) should return #f, not 0.

As far as I can see, on other systems the function works as documented….

@alexharsanyi I don’t think that TwinView is capable of hiding the actual display devices and creating a single virtual device, it operates at the level of a single X screen instead of something like xinerama

I have access to a macos box now so I am working on a test to see whether the offsets are actually needed, since on all operating systems except for macos they are zero, except in my weird case where they produce unexpected behavior, likely because that is already compensated for at another level of the racket system

Does anyone know if native edge webview plugin exists for windows? like the webkit one does for macos from racket?

… since the get-display-left-top-inset documentation is also explicit about these offsets being 0 for monitor 0, except for the MacOS, at least the documentation might need update.

Also, I am fairly sure the tooltip-mixin was used on MacOS, where the offset was applied, and it was positioned correctly — the Racket documentation is also explicit on this matter (see the client->screen documentation)

… also, not sure about NVidia TwinView, but, many years ago, I worked with NVidia Quadro cards and these also had a mode to create a single virtual screen — e.g. for two full HD monitors, Windows Control Panel would detect one display of 3840x1080 (two 1920 width displays), and since the monitors were connected via the graphics card, the driver would simply report one monitor to Windows…

Ah I see the issue with the disparity between top level window move and the coordinates for macos in the client->screen docs, bit it seems that in all other cases that and the other offset will always be zero. So my conclusion is that I have found a bug in the behavior of get-display-left-top-inset since I have a monitor 0 that returns negative offsets. For the tooltip mixins we could add a test to only apply the offsets on macos, but I think the underlying bug is in get-display-left-top-inset so I will close the original issue and submit one to racket/gui. Thanks!

If macro definition was not allowed would that make the toplevel not hopeless?

https://github.com/racket/gui/issues/223 thanks all for the help!

I wonder if a type system that includes types for macros could save the toplevel.

Pretty sure that the top level is hopeless problem has more to do with fundamental differences in semantics between module scope and top level scope than with the presence or absense of types. This is because (I think) many of the problems are related to exactly what kinds of forward declaration are allowed in modules but not in the top level.

More directly an undeclared variable has both all types and no types.

Is there a package that allows you to query the current user running the program?

Do you want something more than (getenv “USER”)?

I wasn’t sure if there was a more portable way than that.

I think ruling out macro definitions would definitely make it less hopeless

Is there an official list of mirrors for https://mirror.racket-lang.org/installers/ ? Guix is using exactly one additional mirror, http://mirror.informatik.uni-tuebingen.de/mirror/racket/, but it seems to have broken TLS.

I don’t know what the functions would be off hand, but the only thing I can think of otherwise would be to get the owner of the current process id.

Something based on (find-system-path 'home-dir) might help: https://docs.racket-lang.org/reference/Filesystem.html#(def._((quote._~23~25kernel)._find-system-path))