Fork me on GitHub
#off-topic
<
2022-05-12
>
Martynas Maciulevičius06:05:26

Does R515 belong to the same numbering scheme as 510.60.02 (this is my current installed driver version)?

pavlosmelissinos08:05:03

Is this connected to the recent ransomware incident? Wasn't opensourcing the drivers one of the demands? :thinking_face:

😮 1
Martynas Maciulevičius09:05:02

Woah. What? Can you add a link?

lilactown16:05:42

from what i've seen of insiders on twitter, it has nothing to do with the security breach, and the security breach actually made this harder

lilactown16:05:41

from what i've heard, this was a long effort and has a lot to do with the fact that nvidia has moved a lot of functionality to firmware on the chip itself rather than have it live inside kernel modules

👀 1
seancorfield14:05:45

Nice summary of where things are and where they're heading. Thanks @UK0810AQ2 The next LTS is still 18 months away so it'll be interesting to see what gets completely baked in by that point (I can see us using the Loom features quite a bit but I'm not sure yet whether that alone will tempt us to migrate to a non-LTS version for production).

👍 1
Ben Sless14:05:37

I'm just excited to see what people will build with loom

Ben Sless14:05:02

Everything pertaining to Clojure's core wrt Valhalla is far off

didibus17:05:58

I'm looking forward to core.async having a fiber function on top of thread and go. That just runs over an unbounded green thread pool.

didibus17:05:17

And in standard Clojure you can just use that for everything

didibus17:05:47

Also a loom backed future and all that

Ben Sless17:05:27

Would you even need channels at this point? Won't blocking queues be enough? The only question mark I have here is regarding alts

seancorfield17:05:53

The channel-as-synchronization-point model seems useful for coordination, in and of itself. Perhaps the real Q is: would you even need core.async at that point? Wouldn't you just write code in a different style? What would coordination/synchronization between fibers look like though?

Ben Sless17:05:16

That's what I meant, you could use queues instead of channels and get all the synchronization between fibers you need The model is still good, I just wonder if you'll need all the associated implementation overhead

phronmophobic18:05:55

Do you queues offer equivalents for all the core.async channel operations: take!, put!, offer!, poll!, and especially, alts!?

Ben Sless18:05:08

Alts is the missing bit, I think, still, implementing it could be much simpler. Ron Pressler mentioned they want to implement channels down the line

phronmophobic18:05:07

alts! is usually the hard part and one of the reasons I think core.async better supports difficult async code.

phronmophobic18:05:30

Since core.async is based on CSP, I'm not sure loom makes it less relevant. My intuition is that it it just provides more options for core.async to take advantage of since it can bridge OS threads, loom threads, and go threads.

phronmophobic18:05:23

Lots of really cool stuff happening in jvm land though!

didibus18:05:23

If you find core.async useful with thread today over using threads directly, or using future, or blocking queues, than you'll find it useful with fibers as well

didibus18:05:29

Personally, I just think core.async offers really nice ergonomics for moving data between threads and coordinating their use of it. Transducers on channels for example, alts, mix, mults, pipeline, etc.

didibus18:05:32

Maybe someone builds an even nicer API over fibers, but I think the change to support fibers to core.async is minimal, and lots of people already know how to use core.async which is nice.

didibus18:05:19

I would also find it more portable arguably, since core.async can also work where you don't have fibers, or you don't have threads, etc.

didibus18:05:06

Valhalla and the promise of more performance and less memory that maybe it could bring to Clojure is the one I'm most excited though. The others all have satisfiable workarounds for me right now, but no way to workaround Valhalla.

Martynas Maciulevičius15:05:20

Somebody just posted SO survey's link (adding link to reddit so that it'd get more upvotes): https://www.reddit.com/r/Clojure/comments/uo22cg/stack_overflow_survey_is_open_lets_make_our/

respatialized19:05:38

The malloc/ free stuff is all over my head, but the programming model described here to basically memoize awk "for free" and transparently add persistence to scripts written without consideration for storage seems super appealing. https://queue.acm.org/detail.cfm?id=3534855 It seems like it might be even easier to implement this idea in the context of the JVM?

Cora (she/her)21:05:34

can anyone recommend a non-terminal irc client for macos?

Cora (she/her)21:05:05

historically I've used xchat aqua and limechat

seancorfield00:05:30

I used Colloquy for years and always liked that. Used to be free, now it seems to be $1.99 (still cheap). I also used Adium for a long time. But I gave up on IRC a few years back so I don't know how those are, feature-wise, these days...

nivekuil04:05:10

I use a matrix client (element) for irc and this slack. Free ZNC too

Ben Sless05:05:16

If you're using Emacs, there's always ERC

Cora (she/her)01:05:50

I completely forgot that I have irccloud that I can use and just avoid the whole client issue

Drew Verlee23:05:51

Google io videos are posted. Lots of new browser features. Anyone see anything that really jumped out to them?