@jcoo092 I am attempting to run the Racket benchmark, but am getting an error. Any ideas? (macOS).

@joe Yes.

apparently not all make rules are created =

:slightly_smiling_face:

FWIW my make is GNU make:

@jcoo092 I am looking at linalg.rkt . The expression (matrix-row (matrix* (matrix-transpose v1) v2) 0) computes the dot product of the two vectors. Is it on purpose, you didn’t use matrix-dot ?

Nope, definitely not on purpose! This sort of thing is exactly why I asked for feedback :slightly_smiling_face:

I am rewriting the test to use flmatrix instead - just to see which is faster.

My local GNU Make is on version 4.2.1. I think that the problem is likely that I am using the ::= form of simply-expanded variable assignment. I chose that because it is apparently the version that is now in the POSIX standard, but it is apparently relatively recent. If you change all the instances of ::= to := or = , does it make a difference? (I don’t think I use any of the simply-expanded variables in a way that would cause a recursive expansion, so either form should be safe)

Then it simply says: make: Nothing to be done for `all’.

(still running it from within the Racket folder)

Ummm :thinking_face: I just realised that I forgot to include something that ensures the subfolders I use actually exist… I’m not sure if them not existing could be the issue or not

If ensuring that the directories exist (executables, compiled and benchmarks) doesn’t help, then the only other thing I can think of is that there’s some weird thing going on where it thinks output files are newer than the input files, in which case doing touch x (where x is the name of the source file that you want to build) is the only other thing I can think of.

Actually, I suppose it might be that your version of Make doesn’t like the static rules that I use in it. If that’s the case, then replacing $(rkt_zo_names) : $(compiled_dir)/%_rkt.zo : %.rkt $(racket_make) with $(compiled_dir)/commstime_rkt.zo: commstime.rkt $(racket_make) (and substituting commstime for whichever file name you want to work with), as well as $(exe_names) : $(exes_dir)/% : $(compiled_dir)/%_rkt.zo $(racket_compile) with $(exes_dir)/commstime: $(compiled_dir)/commstime_rkt.zo $(racket_compile) again making the commstime substitution, should work.

Also, GNU Make demands the indented lines all start with a tab, rather than spaces - I don’t know if that could possibly be an issue.

If it’s none of those, then I’m really stumped. Oh, I should mention that the benchmarking stuff in the Makefile relies on the existence of hyperfine on the command line - just in case you don’t have it installed and get some weird error.

I gotta go for the day, but please do keep posting with any comments or recommendations you may have! I’ll definitely check them first thing tomorrow. Thanks for taking a look :slightly_smiling_face:

@jcoo092 Is rem-all-by–256 allowed to mutate overwrite the previous matrix - or does it have to allocate a new one?

@jcoo092 I have made a PR with a linear algebra benchmark that uses flmatrix instead of math/matrix. It is much faster. https://github.com/jcoo092/CML_benchmarks/pull/5

@greg I currently have my racket-mode in a broken state, which is behaving poorly. perhaps now would be a good time to investigate the problem? I think a synchronous discussion might make more sense since we’ve had trouble replicating.

@samth I have a little time now, if you still do.

Any chance it might be this? https://github.com/greghendershott/racket-mode/issues/473

More specifically https://github.com/greghendershott/racket-mode/issues/473

No, it’s a “can’t launch racket mode so it flails” sort of error

OK. Maybe a continuation of this which we didn’t close: https://github.com/greghendershott/racket-mode/issues/457

currently, when I have a Racket buffer open, racket-run does nothing, and every 10 seconds or so, the racket-stderr buffer appears in a second window in emacs with an error message

What’s the error message?

the message is instantiate-linklet: mismatch; reference to a variable that is not exported; possibly, bytecode file needs re-compile because dependencies changed name: check-unpack-path7.1 exporting instance: "/home/samth/sw/plt/racket/collects/file/private/check-path.rkt" importing instance: "/home/samth/sw/plt/racket/collects/file/unzip.rkt" context...: raise-arguments-error body of "/home/samth/sw/plt/racket/collects/file/unzip.rkt"

which is certainly not your fault

but racket-mode’s response is not great

The part where the buffer appears showing the error, is recent. That is intended to be a “good” change — surface errors. But the error itself isn’t good.

Are you saying that 1 attempt to racket-run results in “infinite” every–10-second errors?

Thereafter?

yes

although I also have racket-xp-mode on

OK so I’m trying to organize thoughts here. 1. I can try to repro by introducing some error or stale bytecode in (say) the file collection, and figure out why Racket Mode behaves badly, and fix that.

1. Meanwhile re you moving forward, I think if you fix that stale bytecode error, then M-x racket-start-back-end, all should be fine.

I mostly wanted to ping you because I can try to investigate locally

since you have had trouble reproducing these errors

(Because that will cause the back end Racket process to start again, with the now-fixed stuff) ?

whereas if I just fix things, then it may be hard to find the bug a second time

10–4

The every–10-seconds stderr buffer thing — does it keep happening if you just sit there not touching the keyboard? Or are you interacting with the racket-mode buffer?

when I interact with the buffer it appears

I’m guessing if you just navigate around, it does not happen? But if you edit/make changes, it does happen?

yes, that’s right

OK I introduced a syntax error into file/private/check-path.rkt and now I’m getting similar behavior. Not bytecode mismatch but AFAICT sufficiently similar (and simpler for me to create) to play with it and see things.

ok, great

and I can try to recreate the TR error later

My first dumb reaction is, “The Racket Mode back end needs various Racket collections to work, so it will be difficult for it to work if they do not.” :slightly_smiling_face: But I’ll live with this awhile and try to think of ways to make the failure modes less-unpleasant and more-clear?

yes, I don’t expect racket-mode to work in that state, but the every–10-seconds buffer reappearing was quite annoying

One quick idea: If the back end fails to start, would it make sense to for racket-xp-mode to disable itself automatically, with some message?

if possible, I’d like “racket-run” to work in the sense of running racket on my file in that state, but I understand if that’s hard

that could be good

“still racket-run somehow” sounds like the highest priority — gotcha

my highest priority would be the buffer appearing

but i’m happy with whatever prioritization you have

the addition of racket-xp-mode has been really great

You mean “I’m still broken” continuously is annoying? :slightly_smiling_face:

I’m using emacs (and thus racket-mode) a lot more these days, because I’m mostly working remotely on a machine in my office, and it’s been very nice

I’m trying to get canvas coords from screen coords - but I’m out by the height of my scrollbar on the y-axis, Does anyone know how to convert to canvas (dc%) coords? ;; get mouse position (define-values (ms l) (get-current-mouse-state)) (define mouse-sx (round (send ms get-x))) ; screen coords (define mouse-sy (round (send ms get-y))) (define-values (mcx mcy) (send this screen->client mouse-sx mouse-sy)) in the case of screen->client the result is the window coords not the canvas itself.

What does (send _a-window_ client->screen _0_ _0_) give?

@samth So playing with this for awhile, I have a proposal:

That buffer will still display automatically — until you disable it doing so.

After each stderr output it will also print something like "To stop displaying this buffer automatically, do M-x racket-toggle-stderr-auto-display" and maybe some shortcut key for that.

Once you toggle it off, that will be remembered for the duration of your Emacs session. (Someone hacking on Racket or Racket Mode could use this. However normal users probably won’t.)

Justification: I’m concerned if normal people are trying steps to fix an error, then don’t see more messages (because the buffer didn’t auto-display), and think a step “fixed” something because no error — resulting in confusion. Ergo require a user to choose a command to disable it.

What do you think?

[[ This whole show-the-buffer thing was a recent addition, after a confusing bug https://github.com/greghendershott/racket-mode/issues/468 that left me wanting to surface the errors. :slightly_smiling_face: So I’m leery of “un-surfacing” them in a default way. ]]

That seems reasonable, I suppose. I would prefer if there was a way to notify that wasn’t “split my window in half”

I like how you think. BRB

It would only happen the first time, in your Emacs session. Also, the command would toggle some var that you could setq in your init.el if you really really never wanted to ever see this even once. ?

nope: inside on-paint I get the frames topleft, not the canvas

(define-values (csx csy) (send this client->screen 0 0)) (define-values (fsx fsy) (send f client->screen 0 0)) (define osx (- csx fsx)) (define osy (- csy fsy)) osy is zero

calling from outside it gives nonsensical numbers; (send frame show #t) (send c client->screen 0 0) (send frame client->screen 0 0) 341 269 341 45

http://pasterack.org/pastes/58746

If have the frame top-left, I think there must be a way to find out where the canvas is placed relative to the frame.

@spdegabrielle The canvas has an get-x and and get-y which returns coordinates relative to the parent:

If you add the coordinates of the top-left of the frame, I hope, you get the coordinates of the canvas.

tried that - get-y gives me the window top - not the canvas even when I explicitly send to canvas (send canvas get-y)

Hmm.

troubling.

Does the client->screen method on window<%> help?

I tried that https://racket.slack.com/archives/C06V96CKX/p1590163745337900\|https://racket.slack.com/archives/C06V96CKX/p1590163745337900

At this stage I think I have to add a magic number (24?) to my mouse y to get the canvas y.

Sorry that I missed the earlier part of the thread. But I don’t understand why is would be wrong that osy is zero; the client area of the frame and canvas are the same when a canvas has no border and is the only thing in the frame. I’m not sure about checking client->screen just after show, but sometimes some events need to be handled for a frame and its content to settle in. (The racket/gui library tries to minimize that asynchronicity, but it doesn’t always succeed.) As for the magic number, the difference between get-current-mouse-state and client->screen may be get-display-left-top-inset.

God point about having to wait. I’ll try your suggestion ;; get mouse position (define-values (ms l) (get-current-mouse-state)) (define mouse-sx (round (send ms get-x))) ; screen coords (define mouse-sy (round (send ms get-y))) (define-values (mcx mcy) (send this screen->client mouse-sx mouse-sy)); client coords

could the new buffer be shown smaller?

(ie, split the window in not-the-middle)

@samth Not yet merged to master but WIP: https://github.com/greghendershott/racket-mode/commit/482f10a15d919e5eff76a926734dec88268556cb

nice

In my experience it’s usually wise in Emacs to call display-buffer and let various layers of customization do whatever the user has asked. Every time I’ve tried to be “clever” I usually end up backtracking.

This is probably an issue where people who have lots of customization have a very different experience than someone like me with not so much

Yes. But also, I should have said user customization, plus all the logic Emacs already has by default, for things like multiple frames, is the screen portrait or landscape aspect orientation, what are the existing windows, MRU windows, yada yada.

I’ve just learned if I pull that thread I better be ready to knit a whole new sweater. :slightly_smiling_face:

And have some spare yak hair yarn, too. :wink:

@samth I merged to master. Might be some hours before MELPA refreshes to show version 20200522.xxxx. https://melpa.org/#/racket-mode

Nice

Could the Racket package manager track number of downloads?

Good for your ego, but also to figure out which packages are “standard” for a certain thing

@pavpanchekha you should do it

its a good idea

Yeah, mutation would definitely be allowed - I probably just didn’t figure out/realise how to do it.

Also, does that mean that you managed to get the Makefile to work? Or did you just go with the manual approach?

@pavpanchekha note that it could track requests for the various metadata files, but since it doesn’t host the code it can’t track downloads

What sort of meta data? What we really want to track are installs of a package, though installs and upgrades are also good

It looks like it’s possible to use the github API to get the number of clones in the past two weeks. See https://developer.github.com/v3/repos/traffic/#clones. edit: never mind, it looks like you need push access to get this information.

Huh interesting

But it should be possible to send a request to a Racket pkg server for each raco pkg install, no?

I mean, it probably does that already to lookup for where the repo is

What’s left is actually logging the request

Another number, other than “number of downloads”, might be the number of other packages that depend (transitively) on the package.

hi. I’m making a chat server/client for my girlfriend so she can move her RPG group away from Facebook. The Universe module in Racket looks nice for making a chat room that could have a nice user interface and interactivity. Already found working example or a chatroom with it, but I’m wondering how hard it would be to make a web interface rather than using Racket draw. Would universe model place nice with designing web interface? I know there is Whalesong that can convert Racket app to javascript, but I’m not sure if it is getting any updates anymore.

play* nice

oh and I see there is RacketScript as well, but it is still experimental.

> Of course, the macro expander itself must be able to disarm a taint on a syntax object, so that it can further expand an expression or its sub-expressions. Should this instead be “must be able to disarm a dye pack”?

As I understand, taint is a bad thing. Once it occurs, macroexpander won’t accept it.

OTOH, dye pack is like a bomb, which could be deactivated by the macroexpander

As another alternative, I would recommend considering some combination of Discord and/or Roll20. My group has been using a combo of the two while we can’t meet in person, and so far it is working quite well.

Of course, that isn’t quite as special as you making something for her.