I looks like setting bin-dir is the part that disables launcher creation, because the launcher creator doesn’t find any rackets to create launchers for. Also, setting lib-dir prevents raco setup from finding other pieces that it will need to create launchers (i.e., it doesn’t use lib-search-dirs as it probably should).

The solution may be to (1) add bin-search-dirs and use it when looking for racket for launchers (2) use lib-search-dirs to find other launcher components; (3) only create launchers and move launchers into place when they don’t exist in the search path or do exist in bin-dir or lib-dir.

I’m not yet clear on what find-exe should do. I see that it currently finds an untethered racket. (Contrary to my experiment earlier, I’m finding that racket -G etc -l- raco setup does create a tethered racket as long as bin-dir and lib-dir are not set.) Probably it should find the tethered one, instead.

Is sequence-length always O(N) regardless of the underlying sequence type?

(define xs (make-vector 1000)) (time (for ([i (range 1000000)]) (vector-length xs))) ;=> CPU time: 2ms (time (for ([i (range 1000000)]) (sequence-length xs))) ;=> CPU time: 15ms I’m building a few sequence-able types which are vector-based underneath and would very much like it if I could use sequence-length on my data type w/o it being O(N) to count every element. And without having to implement versions of mytype-length for each of these if possible.

If you change the length of xs, you get the same timings. So sequence-length is still O(1) wrt to the length of vectors.

https://github.com/racket/racket/blob/master/racket/collects/racket/sequence.rkt#L44

Just calls vector-length.

Okay. Thanks for the code link, but that code shows how custom it is. Which means for my own types that have:

#:property prop:sequence (λ (s) ...) It’s going to be O(N), because it’ll iterate over the stream generated. And there doesn’t appear to be a nice way to “hook” in for me to provide my own function.

I’m just hoping there’s another property I’m unaware of like prop:length or similar.

Maybe https://docs.racket-lang.org/data/gvector.html\|gvector can be faster, I don’t know. @ryanc, what’s the time complexity of gvector-add!? Of course, a difference to vector-append would be that gvector-add! mutates the original gvector that is appended to.

There’s also https://docs.racket-lang.org/data/Imperative_Queues.html\|queue , which mentions that https://docs.racket-lang.org/data/Imperative_Queues.html?q=dequeue#%28def._%28%28lib._data%2Fqueue..rkt%29._enqueue%21%29%29\|enqueue! takes constant time with respect to the number of already-present queue elements. Again, this changes the queue in-place.

> It’s going to be O(N), because it’ll iterate over the stream generated. Would it make sense to cache the length of the values of your types?

Just gave this another try with lib-dir and bin-dir pointing to the original installation. I got many errors like: 1. trying to delete raco in the original bin directory; 2. trying to write to launchers.rktd and mans.rktd in the original lib directory; 3. trying to copy starter-sh from the original lib directory to the original bin directory to create a launcher not present in the original installation. I don’t understand the first error, but it seems like the difference in all the other cases is that my (attempted) config-tethered installation includes packages with launchers etc. not present in the original installation. I’ve put my whole working tree in a git repository here: https://github.com/LiberalArtist/racket-config-tethered-experiment > setting bin-dir is the part that disables launcher creation, because the launcher creator doesn’t find any rackets to create launchers for I was confused by this: is the purpose to support a config-tethered installation including launchers for multiple suffixed Racket variants, like drracket3m? Could (available-racket-variants), (available-gracket-variants), and (current-launcher-variant) be used instead? > (3) only create launchers and move launchers into place when they don’t exist in the search path or do exist in bin-dir or lib-dir. I don’t think I understand this. If, say, plt-help exists in the original bin-dir, I think I would want a tethered version in config-tethered-console-bin-dir. I’ve been imagining that the original bin-dir would not end up on the PATH. > I’m not yet clear on what find-exe should do. I see that it currently finds an untethered racket. … Probably it should find the tethered one, instead. This sounds right, and I see that the docs for find-exe say that “if untethered? is true” (it is #f by default): > then the original executable is found, instead of an executable that is tethered to a configuration or addon directory via (find-addon-tethered-console-bin-dir) and related functions.

That’s the thing. I don’t need to. They are already vectors. For example:

(struct my-type [data info]) In this case data is a vector and I want to be able to do simple things like iterate over it, get the length easily, etc. So, I define:

(struct my-type [data info] #:property prop:sequence (lambda (x) (sequence->stream (my-type-data x)))) Now I can use for over my type, sequence-map, etc. However, sequence-length has no way of knowing that what is really being iterated over is a vector since all I can give it is a stream or a gen:sequence with first/rest.

Obviously I can just define my-type-length and have it return (vector-length (my-type-data x)), but when I’m using the sequence functions for everything else, it’d be kind of nice to be able to to use the length one as well. :wink:

As far as I remember, we said at the end of the meeting that the next meeting should be on 2021–05–29 (to have more meetings :smile:), but <https://racket-news.com/2021/05/racket-news-issue–49.html#meetups|Racket News> says 2021–06–05. If we still want to stick to 2021–05–29, we should tell @pocmatos before the next issue of the Racket News comes out. :slightly_smiling_face:

As I said, although personally I like more meetings :slightly_smiling_face: , a rule like “first Saturday in a month” would be easier to remember, and hence in my opinion would be slightly more preferable.

Along the same lines, it’d be nice (as in maybe it’s there and I don’t know) if functions like sequence-map could return the same type back. Otherwise, I end up with things like:

(define (my-type-map proc mt) (struct-copy my-type mt [data (vector-map ...)]))

Just noting the above is a simple, contrived example of what I’m working on. For something really simple like the above, I wouldn’t care about going through all this and just access the data directly instead. :slightly_smiling_face:

I ended up coming up with an algorithm that doesn’t require vector-append at all for the particular thing I was doing, but thanks regardless

Just a heads-up: The standard plan trial for this Slack instance expires on 2021–06–06. If I understand the <https://slack.com/intl/en-de/help/articles/115002422943-Message-file-and-app-limits-on-the-free-version-of-Slack|information on the Slack website> correctly, this means that only the latest 10000 messages (over all channels and direct messages) will be kept. So if you want to keep older messages, you should store them elsewhere soon. (Honestly, I don’t have the faintest idea how many messages we have and how soon / to which extent private messages would vanish.)

Sorry - I didn’t know about that date. I relayed info from @spdegabrielle. Let me know what you wish to be published tomorrow.

available-racket-variants, etc., are being used, but those functions look in bin-dir to decide what is available. So, they need to be able to look in more places, and I’m adding search paths.

The changes I’m working on won’t affect the executables that are created as tethered, only the non-tethered ones.

The find-exe implementation was meant to deal with tethering, as you note, but it turns out that it wasn’t implemented right.

A Racket module written in #lang beeswax/template always implicitly defines and provides a function called template-apply that has a particular signature. I’m trying to document that function in Scribble (with defproc). But nothing in my package explicitly provides a binding by that name, so Scribble doesn’t connect references to template-apply elsewhere in my docs to the site of its defproc. How best to make this work? Should I just provide a dummy binding for it from somewhere?

I’ll document things better this time to explain how it’s supposed to work, too. I think I must have gotten about half-way through last time (and worked more on making addon-level tethering work), but probably stopped because no one was ready to try using it.

Does #:link-target? #f do the right thing in this case?

I’m not sure? From the docs I would expect that the “right thing” for #:link-target? #f within defproc would be to prevent indexing/hyperlinking, which is the behavior I’m getting now. At any rate I did try it just now with no difference…

I think I understand better that you do want some linking. I’m pretty sure I used the dummy-binding approach before, although I can’t remember the example.

That makes sense, thanks!

Is there a point in typed racket expansion where I could derive ->jsexpr and jsexpr-> for structs? that would be quite nice.

If context is useful, I’m aiming to use this in packaging Racket for Guix. To start with, I’m trying to have Guix’s racket package chain to its racket-minimal, rather than duplicate work. Eventually, I hope to have Guix provide the same kind of support for Racket that it does for other languages by building up a Racket installation additively, with many layers of chaining.

Let’s do both! @sschwarzer @samdphillips @pocmatos I’ll set my alarm to attend both! (I’ve missed the last few) And I’ll ask the attendees if first Saturday each month is ok?

I will announce both in RN

I’d be surprised if the archive contained direct messages. :smile:

Great. May 29 works better for me! We’re going on short holiday in June so I can’t make that day

@ben.knoble do you need me to do another export?

At whatever frequency you want to do, Sam; I’ll have to figure out how to merge the data correctly, but maybe racket can help :)

Well I should export it before June 6

What date did you do the previous one?

You dm’d me about it on the 14th of March, so maybe let’s get some overlap with that to avoid losing anything?

Here’s what I have so far: https://github.com/mflatt/racket/commit/07c8a3a0faa5386771cbc4088e82ff642cfe1b96

(That might be ready to merge, or it might not. I plan to pick it back up tomorrow.)