Clojurians Log v2
off-topic
For those of you who came from OO languages (especially Ruby) I’m sure you’ve heard of POODR (Practical Object Oriented Design in Ruby). What would be a Clojure/functional equivalent?
Not sure what your looking for exactly, but the component library helps with stateful things, and ordering. https://github.com/stuartsierra/component
Sorry, I think I wan’t clear, POODR is a book that teaches OO design with Ruby, I was wondering if there was a similar book in Clojure
But for OO or functional? Because in general you want to prevent creating objects/keeping state with ‘idiomatic’ Clojure as much as possible?
For functional programming
I don’t know about one such book, but you may want to look at: Programming Clojure (The Pragmatic Programmers), Elements of Clojure and The Joy of Clojure.
Generally OO is used very sparingly in Clojure code. The core idioms are: data driven/oriented, functional, macros, REPL driven development.
@hewrin I think "Eelements of Clojure" by Zach Tellman might be what you want, it has general advice for clojure program design (which isn't quite OO)
Thanks for the suggestions @denis.baudinot and @noisesmith! I’ll check them out
I remember seeing a talk given by stu halloway about cognitect.anomalies, anyone happen to know if that video is out there somewhere? Can't seem to find it on google
@jjttjj I think this is the one you're looking for: https://youtu.be/oOON--g1PyU?t=1181
that's it, thanks!
I'm consuming a websocket api from clojure that receives hundreds of messages per second. I've tried out a few clojure websocket clients (backed by jetty or java9 websocket client) as well as trying minimal wrappers on these java libraries, and would experience frequent disconnections, every 5-10 minutes. Then I tried out aleph, which is backed by netty, which almost never disconnects. Is there some reason aleph or netty might be inherently more robust here? or might there be some better way to configure the other libraries?
@jakub.zika-extern I would expect a lot of code builds the connection strings dynamically at runtime, so I'm not sure what you'd be able to regex for...?
@seancorfield I accidentally deleted the message. For anybody interested: I asked about parsing out connection string from compiled class files… Thank you Sean. I thought that. I am just trying to analyze bunch of running jars and I am not sure where to beggin.
If they were literal strings in the Java or Clojure source code, though, they are likely to appear that way in the .class files inside of a JAR file. That would be true even if the Clojure code was AOT compiled into .class files. If it wasn't, then the Clojure source files themselves typically appear directly in the JAR files.
JAR files are zip files, and you can use a utility like 'unzip' to expand their contents into a whole directory structure of files that are packed up inside them.
Also commands like jar xvf foo.jar if I recall correctly.
for fast hacks, see good old unix strings
Curious how Clojure will install and run on the new M1 macs. Any experience reports so far?
ARM jvm is pretty dismal
it works, but it's much worse than x86
Even Amazon’s?
(this is generally, eg. on my pinebook pro)
I haven't tried Amazon's JVM - is it somehow ARM optimized in a way others aren't?
I think the work to support it well is still ongoing isn't it?
I hope so - it's just not up to par in my experience...
https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos
new EA build
It would make perfect sense if the number of person-years put into JVM JIT for x86 is an order of magnitude greater than for any other CPU instruction set
yeah, I don't think anybody's hyper-optimized JIT is as good on ARM as x86, because everyone that wants power uses x86
interesting how the mac stuff is primarily building on work done by microsoft to support windows
the other big platform where people don't just recompile everything for new architectures :D
Which part of the mac stuff is building on microsoft stuff? I haven't looked into the details yet, other than to see that of course Apple has Rosetta 2 for binary compatibility of applications that haven't been recompiled yet.
I'm a huge ARM fan, I think it's great in the big picture for the x86 monopoly to fall (in every space, not just low power / mobile)
Wrt DSP plenty of ARM SOCs come with proprietary DSP modules which perform well enough as external accelerators. I doubt even low end smartphones do any DSP today in their CPU cores.
@ben.sless I'm thinking of dedicated devices, like the Eventide H9000, which contains 4 separate multi core ARM boards
and all it does is DSP
From looking at its spec, the DSP engines are mentioned separately. My guess is that the ARM CPUs are just ancillary to the DSP cores. (i.e. 4 CPU cores and 4 DSP cores on a single SOC). You still need a CPU to read from memory and stream data to the DSP cores themselves.
I don't see DSP coprocessors (I might be looking at the wrong spec), link?
I also see things like ", as new, more powerful ARM chips become available, the H9000’s DSP modules can be upgraded" which strongly implies the ARM chip is doing the work
there are IO modules but those are just for connection to other devices
They don't write it down anywhere, it's more of a semi-educated guess based on my past experience as an electrical engineer, including working on ARM SOCs with DSP and ML accelerator modules.
if you see that jep above it depends on the windows jep. and that macos release above is a microsoft build
I even started learning Aarch64 assembly, in the hopes I could contribute to some JIT project(s), but that came with a bunch of CS and practical experience I have to backfill before I'm proficient
I had to step out for a second but was asking about Amazon’s as they’ve done work on the graviton2 arm platform and it’s supposed to be great
x86 has had so near 0% market share in smartphone space, and smartphone sales have increased so dramatically in the last decade relative to platforms where x86 is dominant, that its overall percentage of CPU sales has shrunk due to those facts alone.
Understood that you are wishing for x86 market share to shrink in server space as well, which of course might still happen.
I'm grey enough to have lived through both the 680x0 -> RISC transition and the RISC -> x86 transition with Apple and they managed both of those surprisingly well, but quite a few software vendors dropped Mac OS as a supported platform during those transitions each time so it'll be interesting to see what happens with x86 -> ARM.
(At this point tho', I'm kinda "done" with Apple -- although my main dev box is a 2012 iMac, my last two laptops have both been Windows and my next main dev box will be as well, and I switched to Android this year after years of iPhones)
it will be interesting to see how the native aarch64 jdk performs vs. the x86 jdk using their translation layer
right - ARM software is currently well optimized for power usage (what you'd want on mobile), but less often for raw throughput (what you'd want for a server or a DSP device for example...)
i saw an interesting tweet that stated apple's arm chip could be faster with x86 emulation than native x86 due to being able to manipulate when memory barriers were enforced. gonna try to find it
like, if the aarch64 jit is so terrible, and the x86 one is so good, could translating x86 to aarch64 smoke the native aarch64
I am still waiting for a mill though
https://twitter.com/never_released/status/1288658469827104769
my main clojure-related inconvenience after several months of using aarch64 on windows/wsl has been javafx support. Hoping that will change with Apple and MS taking more interest.
so openjavafx doesn't work? or works but is buggy/slow? or something else?
openjfx on aarch64 doesn't include swing components
or web/media
thx, good to know
practical implication being I haven't figured out a way I can use REBL, but x64 emulation is supposed to be coming soon for Win10 so that should give me more options
that's why I was asking :)
What I really wonder about the new macs if they will even support OpenGL
Apple has been pushing Metal, and consider OpenGL deprecated
https://clojurians.slack.com/archives/C03RZGPG3/p1605202669403000
AWS Graviton2 is a huge motivation now ^
will push openjdk perf more than apple silicon macs
There's some mention of it on the JEP ticket for Windows: https://bugs.openjdk.java.net/browse/JDK-8248238?focusedCommentId=14356900&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14356900 and then I think this is promising news from Gluon: https://gluonhq.com/javafx-on-embedded-an-update/ but the current early access that appears to include the UI components is still only arm32 😕
OpenGL and Vulkan are definitely on the bucket list of tech-I’d-like-to-play-with
But, macs are pretty abysmal for that it seems 😞
https://twitter.com/hendrikEbbers/status/1326939633595404289