<RagingDave>
I mean the part about racket executable for the "regular" variant and lgpl
<bremner>
what license do you want to distribute your standalone executable under?
<RagingDave>
let's say i want to commercially sell a software made with racket and bundled up as standalone executable. I would not want to open the source code. is that scenario even possible?
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<RagingDave>
and i wondered if this (rather cumbersome) way of handling releases is still necessary
<bremner>
I'm not sure what you mean
orivej has joined #racket
<bremner>
but I also have zero influence on the racket release process, so...
<RagingDave>
the licensing is confusing me. so lgpl means that my proprietary racket application must provide a way (for the customer) to re-link with another racket runtime
<RagingDave>
i guess my question is if that is still necessary or if the newer licensing with MIT allows me to "skip" that part
<RagingDave>
however my suspicion is that it is still lgpl because the runtime may still be licensed that way
<RagingDave>
maybe it boils down to what is the "regular" variant of racket executable
<bremner>
I'm guessing non-racket-CS
<bremner>
I don't know if the notion of "linkable object files" really makes sense for racket. I suspect .zo bytecode files are not really suitable
jellie has quit [Ping timeout: 258 seconds]
<RagingDave>
one could also interpret this: "Any program written in Racket that does not distribute the "Regular" variant racket binary itself is not affected by the license of that binary" as the unaltered binary. so maybe packaging it with your own code changes that?!
jellie has joined #racket
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
<bremner>
I suggest writing the racket-dev list. irc is too ephemeral for some things
<RagingDave>
I also just started a chat on the racket discord. There is a guy who seems to know what's up. He says that the MIT license should apply here. So I guess then everything is fine.
<RagingDave>
Thanks for your help too bremner !
<bremner>
I didn't even know there was a racket discord.
<bremner>
what next, racket instagram?
<RagingDave>
haha
<RagingDave>
these days irc is the exception..
jellie has quit [Ping timeout: 246 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
catonano has quit [Quit: catonano]
catonano has joined #racket
<und-l-t-d[m]>
Is it posible to patch / substititute a function used by third-party code in Racket? Let's say I'd like to mock http requests performed by 3rd-party code during testing?
<und-l-t-d[m]>
I'm testing my code using the 3rd-party code
<und-l-t-d[m]>
I'd like to substitute get-impure-port from net/URL with a mock
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #racket
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #racket
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
DGASAU has quit [Ping timeout: 256 seconds]
orivej_ has joined #racket
orivej has quit [Ping timeout: 272 seconds]
DGASAU has joined #racket
RagingDave has quit [Quit: quit]
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #racket
Sgeo has joined #racket
<dzoe>
lexi-lambda: I am working on different approach than you suggest with stronger constrains - lock-free enqueue and fast spinlock dequeue (regarding your second email)
<dzoe>
But the idea that the RTT does not need to lock the structure for the enqueue operations and the futures cannot block it is really what must be done to make it work without any assumptions about futures scheduling.
<lexi-lambda>
dzoe: I don’t understand
<dzoe>
During the afternoon I updated my approach to ensure that enqueue touches only tail and dequeue only head - though differently than you did.
<dzoe>
And the problem Matthew has pointed out is mainly about the possibility that the future thread acquires the lock and suddenly stops executing.
<dzoe>
That way the RTT gets stuck indefinitely.
<dzoe>
Which is something I must avoid.
<lexi-lambda>
Why do you want to use a spinlock at all, then?
<lexi-lambda>
The lock-free dequeue should be no slower than a spinlocking dequeue, surely?
<dzoe>
lexi-lambda: what happens in your do-dequeue! if there is only last element in the queue and two futures claim it?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<dzoe>
Hmhm... thinking again, it would probably end up being in the right state.
<lexi-lambda>
Ah, you are talking about the semaphore? Well, sure—my original implementation didn’t have a semaphore at all, it just errored on an empty queue.
<dzoe>
Because the racing threads would be for the last two values of the semaphore.
orivej has joined #racket
<dzoe>
So it is just a matter of ordering which is irrelevant here.
<dzoe>
I wanted to stick to mutable pairs, because I am inherently lazy :)
<lexi-lambda>
What you describe is indeed incorrect behavior; if you call dequeue!, the semaphore can be decremented without the value being dequeued, and that can happen arbitrarily many times
<lexi-lambda>
But that’s always fundamentally going to be true if you can’t guarantee future execution
<dzoe>
Now I see the difference - I am aiming at consumers being (possibly) inside futures.
<lexi-lambda>
The only other option is to not block on dequeue on an empty queue, but instead to spin on an empty queue, but I suspect that will make things worse, because the future scheduler may be reluctant to unschedule a spinning future
<dzoe>
But my workload will always have one producer in the RTT.
<dzoe>
Well, this is one of the reasons I might end up with using the busy-wait spinlock-like mechanism, because I _want_ to keep the future running.
<dzoe>
And empirical data supports this approach (slightly to my surprise)
<lexi-lambda>
I see, it’s okay in your case because the producer is always guaranteed to be scheduled (since it’s on the main thread)
<dzoe>
Yep, it is.
<dzoe>
Let's see if I can get to >790% CPU utilization with this :)
<lexi-lambda>
That is somewhat gross but I cannot find any fault in your logic
<dzoe>
That is not gross at all - you haven't seen the rest of those hacks in this code :)
<lexi-lambda>
I am somewhat unclear why you can’t just arrange for the futures to be demanded, though
<dzoe>
I am really curious about people's reactions when I release it and finally publish the articles ...
<dzoe>
They will be - after RTT finishes filing the work queue.
<lexi-lambda>
But then it should be fine to use the fsemaphore, right?
<dzoe>
Yes, but it really does not perform well at all.
<dzoe>
And judging from the sources, it cannot.
<dzoe>
Once you hit fsemaphore-post/wait, you end up with possible rescheduling.
<dzoe>
And that messes things up.
<dzoe>
(Terribly)
<dzoe>
With the busy-wait loop on dequeue, the work is almost perfectly evenly distributed.
<lexi-lambda>
Yes, that’s true—in my experiments I found that futures that block on dequeue would sometimes be rapidly rescheduled
<dzoe>
Each triangle is dissected into scanlines and the scanlines are drawn in futures.
<lexi-lambda>
Ah, you need soft realtime guarantees!
<dzoe>
Current implementation splits the screen into (processor-count) scanlines and processes relevant parts in parallel (possibly, speculatively).
<dzoe>
And as the pre-processing of triangles became more complicated, the time CPU spends with preparing the workload is about 50%.
<lexi-lambda>
That is certainly a bold approach
<dzoe>
But there are already scanlines ready to be rendered.
<dzoe>
It works :)
<dzoe>
Before I added the shading, it ran 50fps on 2560x1440 and 90fps on 1920x1080
<dzoe>
Now it is 1/3-1/2 of that.
<lexi-lambda>
I suppose I have to ask why
<dzoe>
Why it is slower or why implement a full 3D rasterizer pipeline in pure Racket without any external libraries?
<dzoe>
(It renders to cairo_surface_t or mmap'ed fbdev)
<lexi-lambda>
The latter
<dzoe>
Do you remember Denthor's Asphyxia VGA Trainers from 1994-1996?
<lexi-lambda>
No, I was born in ’97 :p
<dzoe>
No worries :)
<dzoe>
It was about demo and graphics programming using direct access to VGA hardware and some tricks to make it really perform on 80286/386/486-class computers.
<lexi-lambda>
That makes sense
<dzoe>
I've spent most of the late 90's programming 3D engines (you know, high school years).
<dzoe>
And about two months ago I got really tired of my work and decided to look into something I really like.
<lexi-lambda>
I can respect that!
<dzoe>
And my work is mainly in Racket and during the last year, I've been creating algorithms that heavily use futures for my customers.
<dzoe>
So basically last 12 months I get paid for futures :)
<dzoe>
And I was curious if I can replicate those 21 tutorials using Racket.
<lexi-lambda>
I’m impressed you’ve managed to do anything at all useful with them, to be honest
<dzoe>
My question was: What can I do with Racket and a ARGB framebuffer?
<lexi-lambda>
When I used them I found the allocation requirements extremely stringent
<dzoe>
As I mentioned - last 12 months is mostly about futures for me and I learned quite some tricks.
<dzoe>
And apparently I've discovered and helped fixing a 3rd futures-related bug in 3 weeks :)
<dzoe>
Of course I had to update the tutorials to match current year :)
<lexi-lambda>
I would not be surprised if you are their only real user
<dzoe>
Playing with palette does not make any sense :)
<dzoe>
Yeah, my impression from Sam's and Matthew's reaction is the same ...
<dzoe>
So I finished re-doing those 21 tutorials in pure racket and during the time the queue of things I want to try with this project slightly grew.
<dzoe>
Current target is 25.
<dzoe>
And right now I can do real time triangle rasterization with perspective correct texturing, goraud shading and z-buffering.
<lexi-lambda>
Well, I certainly wish you the best of luck—it sounds like a fun project, albeit perhaps a highly artificially challenging one
<dzoe>
All of that on Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz in my x280 ThinkPad ...
<lexi-lambda>
(but that is not necessarily a bad thing)
<dzoe>
That is the interesting part.
<dzoe>
It is absolutely artificial - I agree.
<dzoe>
But 2 of those 3 bugs affected the software I produce for my customers and now it runs more reliably.
<lexi-lambda>
Yes, that is definitely nice
<dzoe>
Also one of those bugs lurked in Racket tests for more than 3 years ...
<lexi-lambda>
because nobody uses futures :)
<dzoe>
But really, I am just curious how far can I go with this.
<dzoe>
Yes :)
<dzoe>
I've noticed.
<dzoe>
So that's about the answer to your question ;)
<und-l-t-d[m]>
what are the tutorials?
<lexi-lambda>
They are difficult to use—frankly I am curious why you would choose to write Racket if you have to think at such a low level and restrict yourself so much, anyway
<lexi-lambda>
while I was working on the lock-free queue impl, I was thinking about how I could probably cut down on enqueue allocation significantly by pooling the list nodes
<dzoe>
I am a schemer since 2003 and I am writing new project solely in Racket since 2016 I guess.
<lexi-lambda>
but I didn’t really want to do that :)
<dzoe>
To be honest, I think that enqueue in futures is a NO GO
<dzoe>
Anything that triggers the allocator ruins it.
<lexi-lambda>
another option is to use a flatter representation, like a ring buffer
<lexi-lambda>
but obviously that isn’t always viable
<dzoe>
Right now I am using a preallocated vector of vectors ... anything will be better.
<dzoe>
The futures part is just one of the challenges there.
<lexi-lambda>
I respect your conscious choices to do this in the most difficult way possible :)
<dzoe>
und-l-t-d[m]: trying to find the right link
<bremner>
samth: how do you interpret this as applying to the output of "raco exe" ?
<samth>
bremner: `raco exe` creates a new executable which embeds the racket executable
nebunez has joined #racket
<bremner>
well, I certainly agree with "it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket" ;)
<bremner>
I guess liblightning must be one of the LGPL libraries in question
<samth>
lightning and gmp
<bremner>
ah right. What does chez use in lieu of gmp?
<samth>
bremner: i think kent wrote it all
<bremner>
yikes ;)
<bremner>
I hope not _just_ for licensing reasons.
<bremner>
presumably it's more in scheme
<samth>
no, i don't think that was his primary reason
dddddd has joined #racket
<dzoe>
Hm... my assumption that preparing futures before I start filling the work queue might speed things up about 2x was overly-optimistic. Without any adjustments it makes everything about 15% slower - pretty consistently.
orivej has quit [Read error: Connection reset by peer]
orivej has joined #racket
orivej has quit [Quit: No Ping reply in 180 seconds.]
ArneBab_ has quit [Ping timeout: 260 seconds]
ArneBab has joined #racket
orivej has joined #racket
ArneBab has quit [Remote host closed the connection]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej_ has joined #racket
orivej_ has quit [Ping timeout: 272 seconds]
orivej has joined #racket
TCZ has joined #racket
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #racket
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #racket
real-grue has quit [Read error: Connection reset by peer]
corpix has joined #racket
catonano has quit [Quit: catonano]
catonano has joined #racket
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
aeth_ has joined #racket
aeth has quit [Disconnected by services]
aeth_ is now known as aeth
andrei-n has quit [Quit: Leaving]
corpix has quit [Ping timeout: 240 seconds]
TCZ has quit [Quit: Leaving]
corpix has joined #racket
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #racket
orivej_ has quit [Quit: No Ping reply in 180 seconds.]