has anyone had an attempt at registering URI handlers with OSX for an application? siminar to how mailto: links open the mail app.

just to post research in case anyone else is interested… https://github.com/Grayson/defaultapp/blob/master/defaultapp.m

https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

@soegaard2 i’m getting No key in either environment or home. Using default. decrypt: contract violation expected: bytes? given: #<void> in: the 2nd argument of (->* ((or/c cipher-spec? cipher-impl?) bytes? (or/c bytes? #f) input/c) (#:aad input/c #:auth-size (or/c natural? #f) #:pad boolean?) bytes?) contract from: <pkgs>/crypto-lib/main.rkt blaming: /app/app-racket-stories/secret.rkt the default looks fine?

@spdegabrielle Read the comments here: https://github.com/soegaard/racket-stories/blob/4c405a0702472a8295a77d0d53da5e879f147148/app-racket-stories/secret.rkt#L64

Thank you all for your help with this I got disk usage for racket-stories on glitch down to 134gb @mflatt @samth @samdphillips @notjack @soegaard2 (in no particular order) I appreciate and thank you for the time you take out of your busy day to help me.:heart:

@spdegabrielle I am surprised by the error though - it says that the second argument (the key) is void, but the default key is #"A secret key!!!!"

@soegaard2 I read that and assumed #"A secret key!!!!"] woudl be my key (assuming that is valid)

However use (new-key) to generate a new key, and then store it either in the environment or in ~/.racket-stories/rskey

I wonder whether it helps to move the definition of aes-decrypt and aes-decrypt-bytes below the definition of key?

thanks for the (new-key) tip. I moved the aes- functions - but I didn’t stop to check the impact.

@soegaard2 I’ve got it running ! https://spdegabrielle-racket-stories.glitch.me/ thanks for your help. The only other thing I needed to do was comment out #;(list 'key-size 64) in authentication.rkt because I was getting the error; pwhash: unsupported option for PBKDF2 option: 'key-size value: 64 Thanks again!

racket-minimal-linux-cs, <https://download.racket-lang.org/releases/7.5/installers/racket-minimal-7.5-x86_64-linux-cs.sh> is reporting as requiring 134mb <https://download.racket-lang.org/releases/7.5/installers/racket-minimal-7.5-x86_64-linux.sh> only requires 41mb. Is that right/expected?

I’m building the rantstack app on https://glitch.com/~rantstack-pol (original is v7.2 at https://glitch.com/~rantstack )

I think that’s because machine code (cs) takes up more space than bytecode @spdegabrielle

thansk @popa.bogdanp I didnt expect that :astonished:

Is there a monotonic time source in the standard lib? I imagine current-seconds and current-inexact-milliseconds report system time so they can (and do!) go backwards every now and then, but this isn’t explicitly called out in the documentation. Is current-process-milliseconds what I’m looking for?

@spdegabrielle Great to hear it worked.

Seems like current-process-milliseconds isn’t guaranteed to be monotonic either:

https://github.com/racket/racket/blob/5bb837661c12a9752c6a99f952c0e1b267645b33/racket/src/rktio/rktio_time.c#L110-L146

I want this too

https://github.com/racket/racket/issues/1826

Getting started with emacs can certainly be daunting, but in my case, I viewed it as a long term investment, and I feel it’s paid off extremely well. While some of my friends/colleagues have switched editors a few times over the last number of years, I’ve been able to continue to capitalize on what I’ve learned about emacs and have developed a large number of macros that make life so much easier :slightly_smiling_face:

I use both emacs and DrRacket - emacs for most of my day to day editing of Racket code, but I’ll pop into DrRacket sometimes to use it as a REPL and some other features such as the macro expander, debugger, etc.

I don’t know much about this subject but my first reaction is probably there are multiple, orthogonal use cases people imagine for “monotonic time”. And it might be better/safer to provide (in some package or in Racket) a distinct solution for each?

Like, measuring performance, the system clock not being monotonic seems like the least of your problems.

Whereas if you need some local monotonic counter, and feel it would be convenient not to persist it in storage between program runs, a monotonic system clock seems like a handy way to do that. But you really want a counter not a timer, and that shapes the available solutions.

idk

I am using break-thread off the main thread. Related: https://github.com/zyrolasting/kinda-ferpy/blob/master/main.rkt#L68

This an implementation of the spreadsheet metaphor for async tasks. In this context a cell’s value is a thread, and if a dependency changes it breaks the thread it already has and replaces it with a new thread to restart the task.

What caused me to post here was that when it does so, checking for exn:break on the main thread did not stop the program from spamming user break

But I have not yet tried various permutations of with-handlers* inside and outside of a created thread. I’ll be getting to that sometime today or tomorrow.

Oh cool idea.

https://github.com/zyrolasting/kinda-ferpy/blob/master/main.rkt#L332-L333 the endless loop can use a lot of resources I think? Better might be simply (sync never-evt). That will cause the thread to block forever.

Speaking of sync, you might consider using thread messages — thread-send and thread-receive? These workers could thread-receive a value that is either some work to do, or, a value like say 'quit that means they should do nothing more, just return, which causes the thread to end. Instead of using break-thread or kill-thread, you could (thread-send some-thread 'quit). I’m not saying that would be better, I don’t fully understand your problem domain. Just pointing out it’s maybe an option. Racket’s synchronizable events including channels — or simply using thread messages — make concurrency really nice to deal with. But maybe it would be a distraction from what you’re trying to focus on right now. If so — sorry!

Hmm I guess break-thread does let you interrupt a thread that is stuck running something. And unlike kill-thread, it does allow the thread to do some cleanup if necessary. Probably that’s what you were thinking. If so, never mind I guess. :smile:

Yes, that’s the thinking. And I did forget about never-evt at the time, so thanks for the reminder there. The test resolves quickly enough for it not to be a big problem at least.

Re: use of async channels, I did think about that since I wasn’t sure how I wanted to handle a large proliferation of threads. One use case I’m working on now is crawling an HTML document and building the resources it references using href, src, and srcset attributes. It doesn’t always make sense for one build to wait on the others since they all entail disk or network activity, and async cells help with that. But many such attributes means many threads, and I figured I could either coordinate a global thread pool of ~8 threads, or figure out a way of managing thread groups such that the resources with the fewest dependents get a larger share of CPU time. In any case I don’t really like that the threads are all in the same thread group anyway.

How would you do it?

@notjack https://github.com/Bogdanp/racket-monotonic :stuck_out_tongue:

@popa.bogdanp ooooo shiny

@greg my particular use case has to do with tracking the duration of certain bits of code, but it isn’t quite what people normally think of as measuring performance. I just need to be sure the measurement is never negative. When you say measuring performance this way is the least of one’s problems, do you mean because whatever you’re measuring could be de-scheduled and b/c of the JIT and GC interference or something else?

@jeapostrophe You might be able to answer this: https://stackoverflow.com/questions/60094572/form-validation-in-racket

Racket threads are “green threads” not OS threads. The bad news is you won’t get any parallelism. The good news is that they still help when things might block for I/O (disk or network); other threads can progress. (They also help when it’s just easier to think about a problem concurrently.) The other good news is that they are cheap. You could have dozens or hundreds and it should be fine.

So I’d say create as many threads as you want. Don’t worry about how many. And definitely don’t worry about things like thread pools, at least for the reasons you would for OS threads.

As one small example, the “More: systems” introduction — https://docs.racket-lang.org/more/index.html — creates a thread to handle each request. And for each of those, it creates another thread, whose only job is to maybe kill the first thread if it takes too long.

Here I think: https://docs.racket-lang.org/more/index.html#%28part._.Terminating_.Connections%29

Threads are cheap, it’s fine to use them for little jobs like this.

In fact instead of using break-thread, you could use a similar pattern. Two threads per cell. One thread does the work. Another thread does a thread-receive waiting for a 'kill message, and if it gets it, kills the worker thread.

I’m not sure if that’s better than using break-thread, but it might be? idk

Yeah I just mean the “real time” portion of the output is subject to all sorts of noise and interference, IIUC, including other things running on your computer.

I agree it’s sad if once or twice a year, a “leap” or “smear” system clock adjustment makes one timing wrong. But they’re all a little bit wrong. And outliers should be looked at skeptically, regardless.

The “cpu time” part is more interesting. And for Racket, often the main thing that will matter is the “gc time” portion.

So for some purposes I feel like the best improvement to time would be not to show the “real time” stats at all. I’m kind of exaggerating, but not totally.

@popa.bogdanp Having said all that, I probably don’t really know what I’m talking about, and, racket-monotonic looks great!

Thanks! What you said makes sense, though my experience has been that, when taken in aggregate, wall time measurements can be extremely helpful.

For example, at $dayjob we use http://honeycomb.io\|honeycomb.io to observe all sorts of operations our code makes. Some things take on the order of seconds and most, milliseconds. At the millisecond level, we don’t tend to see much disruption from other processes (because, generally, there aren’t any others apart from the kernel on these servers) or from scheduling or GC because we tend to allocate things up-front so something like a leap second would actually disrupt a whole lot of observations, albeit for a very short time. Then there’s also that whole thing about governments changing timezones on a whim, though I’m not 100% sure how that affects system time (if at all).

(I am building something like honeycomb in Racket, for funsies, hence this whole thread :P)

Huge +1 to the point that monotonic time is designed for measuring latency, not performance. It’s great for timing code that does I/O

I knew about the green threads bit and I’m glad to know that they are cheap.

The reason I’m still thinking about the CPU is because I don’t want to tell Racket’s scheduler that all of these threads are created equal. Case in point, I have a server that starts an async cell’s task as a side-effect of a request. I noticed that creating a bunch of threads causes a noticeable lag, even though there is nothing technically blocking the server from creating a response to send to the user. Isn’t that a matter of the thread preparing a response being in the same thread group?

I’d expect the response to be more or less instant if nothing is blocking.

Actual comment I just wrote in a test: ;; This test succeeds on all Racket versions before and after 6.10. ;; I spent an hour installing 6.10 locally and exploring the problem ;; but so far have no clue. As neither 6.10 nor I are getting any ;; younger, I am choosing to ignore this, for now. (It’s about fetch-blueboxes-strs from scribble/blueboxes returning #f even for basic things like list.)

I try hard to keep Racket Mode supporting older versions of Racket, but I don’t try this hard. :smile:

@greg Maybe it was this bug? https://github.com/racket/drracket/issues/118

@soegaard2 Aha that sounds like it; thanks! I was looking at the commit history for scribble/blueboxes.rkt and it’s like, “nope, nothing changed since 2015” and 6.10 is c. 2017. I never would have tracked it down to a bug in cons/dc. :eyes:

My curiosity is satisfied but there’s nothing I can do about this so the test will remain excluded.

Mainly I’m just happy that a benefit of getting older is I can use “I’m not getting any younger” as a more-convincing rationalization in comments. :smile:

Interesting to hear from a man, who uses “omg” :wink:

My main pleasure in life is a bowl of soup with saltine crackers. I am that old.

I suddenly got a craving.

:smile:

@soegaard2 You’re up late for .dk ?!

> a bowl of soup with saltine crackers. I am that old. If that’s a sign of old age, I’m f’d.

My general test for old age is this… how many times in the shower do you find yourself asking “did I shampoo?” and end up probably doing it multiple times.

I do that sometimes but it’s more a function of how distracted my brain is by some programming problem I’ve been working on. For me it’s a “step away from the computer” signal.

> My general test for old age is this… how many times in the shower do you find yourself asking “did I shampoo?” and end up probably doing it multiple times. If that’s a sign of old age, I’m f’d.

I’m pretty sure I’m at least 140 years old by that metric