This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-10
Channels
- # beginners (140)
- # boot (18)
- # cider (4)
- # cljs-dev (28)
- # clojure (191)
- # clojure-greece (51)
- # clojure-russia (1)
- # clojure-spec (13)
- # clojure-uk (2)
- # clojurescript (38)
- # community-development (26)
- # core-logic (16)
- # cursive (6)
- # datomic (3)
- # defnpodcast (9)
- # editors (1)
- # emacs (1)
- # fulcro (10)
- # immutant (3)
- # jobs-discuss (2)
- # leiningen (17)
- # lumo (24)
- # off-topic (30)
- # quil (12)
- # re-frame (11)
- # reagent (103)
- # remote-jobs (2)
- # shadow-cljs (157)
- # spacemacs (4)
- # unrepl (18)
- # yada (2)
Anyone looked at implementing a scheme using Graalvm ? or maybe porting clojure to it?
@metacritical You can search through the Clojure Google group for "graal" and find a very few mentions of it in messages there, mostly from 3+ years ago. I don't know any more than that, but if you haven't done that, it may give you a lead or two (perhaps to a cold trail)
@andy.fingerhut Ohh, it would be interesting to see clojure run on graal, atleast the startup characteristic would improve.
http://epub.jku.at/obvulihs/content/pageview/508383 looks like what I meant to link to
Does it make sense to talk about a JVM that "runs on a cluster, presenting the entire cluster as a single machine", or is this smoething that does not exist for tech_reason_xyz ?
In particular, I have a local network of four machines, I want to control them all via my clojure program, and am wondering if I could somehow treat them as one JVM (they're all on local network, connected by 1Gbit ethernet), or I have to treat them as four separate JVMs
It definitely makes sense if you have multiple CPUs physically connected to the same CPU<->memory interconnect, like PCI express
And all running a common OS that manages those multiple CPU cores, with common memory address space between them.
I have heard of PCI express-over-Ethernet tunneling, but I do not know if that can be used to make 4 CPUs run a common OS, though. I think that is more commonly used to access PCI slave devices like a GPU over an Ethernet from a CPU.
I have never heard of a single JVM running across CPUs connected via Ethernet.
Well, going back a few years there were commodity Linux clusters like Beowulf for supercomputing type problems. But you said Clojure and JVM... take a look at Onyx, Apache Ignite, or even Apache Mesos? Three different approaches to interacting with a cluster.
It is the "single JVM process" part that sounds difficult. Running separate JVMs on each CPU+OS instance is straightforward.
cliff click was working with a startup that was modeling a jvm on top of a cluster a few years ago
I ran about half the dev team at Terracotta. I first used Clojure trying to help Paul fix some bugs he found building that. :)
https://github.com/pjstadig/tim-clojure-1.0.0 is likely out of date
Current mindset: * four separate machines ==> have to use four separate JVMs * maybe one nrepl, maybe four nrepls * how to control all this via cider ?
Not sure if it's overkill, but you could use something like redis to coordinate between instances. So when you enter something in the repl on one, the other read the value from redis, and give the output back. You could also use RMI, or a shared disk or something.
I don't use cider, and you would want to ask in a cider-specific channel if there is one, but several Github issues for cider mention the ability to (and sometimes issues with) creating multiple nrepl sessions from cider, e.g.: https://github.com/clojure-emacs/cider/issues/1122
The discussion there makes it look like it should normally work to create multiple nrepl sessions.
nrepl typically uses TCP for transport, which is point-to-point communication, so you would need multiple separate TCP connections from your dev machine to each JVM process.
https://github.com/hiredman/crepl/blob/master/src/com/manigfeald/crepl.clj is an unfinished thing I was working on a while ago. it does something not entirely unlikely swim to do gossip based cluster membership, and adds the ability to proxy your nrepl session to another nrepl session
I failed to explain my problem: the problem is NOT how do I get cider to connect to 4 different repls; the issue is how it breks my work flow, if things ilke C-x C-e now becomes C-x C-e {1, 2, 3, 4} and I have to keep track of which repl to send each command
on one hand, it's very weird, on the othedr hand, if I have four different repls, it's not clear how I can get around specifying which nrepl to talk to
(and this issue isn't cider specific -- if I have 4 nrepls, regarldess of what editoride I use, I have to specify which nrepl it talks to)
https://www.research.ibm.com/haifa/projects/systems/cjvm/index.html <-- inactive since 2000, how wonderful:-)
just got a full-stack clj/cljs project set up with clj
and deps.edn
(and figwheel-sidecar). really impressed - fully running nrepl and figwheel service running in about 15 seconds! (i have datomic and jetty on the classpath, which likely contributes to a chunk of that time)
ahh, the ole monolith π
Hi, I startet an app with luminus. Until now I did everything server side. Now I want to add cljs and something reactive. I added figwheel and sidecar to :project/dev in project.clj ` :project/dev {:dependencies [[prone "1.5.0"] [ring/ring-mock "0.3.2"] [ring/ring-devel "1.6.3"] [pjstadig/humane-test-output "0.8.3"] [figwheel-sidecar "0.5.14"] [com.cemerick/piggieback "0.2.2"]] :plugins [[com.jakemccrary/lein-test-refresh "0.19.0"]] :source-paths ["env/dev/clj"] :resource-paths ["env/dev/resources"] :repl-options {:init-ns user :nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]} :injections [(require 'pjstadig.humane-test-output) (pjstadig.humane-test-output/activate!)]}` Now I get this error: Error loading cemerick.piggieback: java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V, compiling:(closure.clj:100:1) Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: cemerick.piggieback/wrap-cljs-repl in this context, compiling:(/tmp/form-init6908219750721856608.clj:1:8532) at clojure.lang.Compiler.analyzeSeq(Compiler.java:7010) How do I go about hunting that down?
the only limit is memory, see, https://stackoverflow.com/questions/11082916/clojure-map-limits-and-consistency
but if my understanding is correct, the tree that backs the map never gets deeper than 7 levels, right?
@nikki: I am reading https://clojurians-log.clojureverse.org/clojure/2016-10-18.html -- do you have regl + cljs bindings for live coding ?
I would absolutely love it if folks could kick the tires and see if it works in their terminal of choice.
that looks amazing!
I'm going to try it today
this is great, so far
(just using lein trampoline run for now)
I guess expecting it to respect my readline config that asks for vi mode keys would have been too much haha
(this is gnome-terminal, with tmux)
@noisesmith that might be something that is already in JLine3. I haven't explored it yet.
cool - with any luck it might just be something you can plug in
I'll be sure to stress test it if I can figure out how to turn it on haha
oh this works great
so the only thing left is respecting inputrc I guess?
Seems pretty neat - but what is the expected use case for this?
Also, I tried setting the color to dark screen but nothing happened - no error, no change. On gnome terminal on ubuntu
Well, if the color changed for you, that is different from what happened for me. No change, no error.
cool! vi mode, d% will actually delete a multi line balanced form, as expected
@bhauman for the themes, that should be changing colors of foreground colors for things typed after that input, and not previous output, right?
because if so, it works - @jsa-aerial just making sure that you are testing the right thing - it shouldn't change the scrollback
@jsa-aerial I am also in gnome-terminal in ubuntu, but inside tmux
How "heavy" is creating a watch on a ref type (atom, ref, etc) in terms of time/space? Is anyone aware of a benchmark for this?
@noisesmith also there is an issue here https://github.com/bhauman/rebel-readline/issues/70 where I tried to provide visual feedback for vi modes, but its super sensitive to terminal control chars in insert mode
real working multi line text objects in a repl is awesome btw
nice!
Yeah, for whatever reason, after I set to dark screen nothing changes - input is still same color, known tokens (map, range, etc), same color, scroll back lines are same color. Β―\(γ)/Β―
it starts as dark, and then light is the alternative
type :repl/set-color-theme :light-screen-theme
and the type :repl/set-color-theme :dark-screen-theme
repeatedly
looks fine from here
OK - some of the vi text objects (eg. %) work very nicely, others act weird or don't work at all
It starts as dark? For me it doesn't actually change my background color (terminal) which is lighter (kind of beige like). OK, setting to light does change things. I think the issue was misreading the meaning of 'light' and 'dark' in this context. I was taking it as 'set the color to dark/light' not 'set colors according to having a light/dark terminal background
it never changes the background
the themes change foregrounds
Exactly - it changes foreground to fit a light or dark terminal
Wow, that color change helps a lot!
@noisesmith if you audit the vi stuff please takes notes in an issue, I can at least disable some of the wonky features until someone implements them properly
nothing is outright terrible compared to other vi bindings - just "oh that thing isn't really there"
I'm going to start making some compatibility notes - biggest one so far is that d only destroys, it doesn't put the destroyed thing into the paste buffer as I'd expect (but y / p do copy / paste)
In the help output, might be nice to indicate the defaults
this looks like it's going to make the frontend person on my team (who spends a lot of time in her figwheel repl) quite happy
Did my first short screencast about (yet another) tiny spy macro: https://youtu.be/38BTviEdi64
clojure.lang.IFn -- applyTo (clojure.lang.ISeq arglist) <-- how do I convert this arg to an Object [] ?
probably object-array
context: I'm writing, in JVM bytecode, a function that implements interface cllojure.lang.IFn
https://clojuredocs.org/clojure.core/object-array should work; thanks;
if you are already working on a bytecode level, going up to call something like object-array from in there seems a bit odd - maybe I don't understand your task though
I donβt know what @qqq has been up to over the last few weeks, but whatever it is, it seems very interesting
i keep waiting for him to start asking about rocket telemetry or genome encoding using the jvm on a cluster π
"leinencoin ICO"
Let me rephrase the problem:
I want to define a macro asm-fn
so I can write things like:
((asm-fn [a :float, x :float-array, y :float-array]
.. insn bytecode that does ...
.. pertend this next section is written using insn bytecode ...
(doseq [i (range n)]
(aset y i (+ (aget y i) (* a (aget x i)))))
...) 2.0 (float-array [1 2 3]) (float-array [2 3 4])))
so right now, I have to do:
(.go (asm-fn ....) 2.0 (float-array [1 2 3]) (float-array [2 3 4])))
and I want to extend clojure.lang.Ifn to get rid of the .go
depending on why you are in the asm-fn level, you might want to do a more streamlined ISeq -> array of object transform - but maybe the calling overhead is negligible compared to the work inside the function itself so you don't care
it's a bunch of numerical / computer vision algorithms, for which type hinting in Clojure has not worked well for me, so it's reached the 'fuck it, I'll write this in asm' level
(defn my-wrap [c]
(fn [& args]
(.go c (object-array args))))
I guess I could do that, and then all my functions can take an Object [] as the args.(defn bc->obj [ret code]
(let [co (ic/visit {:name "my.dyn.TestClass"
:fields []
:methods [{:name "go", :desc [[Object] ret] , :emit code,
:flags #{:public }}]})
obj (ic/new-instance co)]
(fn [& args]
(.go obj (object-array args)))))
((bc->obj Object
[[:aload 1]
[:ldc 0]
[:aaload]
(comment
;; how do I cast this to an integer?
;; already tried [:chekcast Integer]
[:ldc 22]
[:iadd] ;; then we can add 22
[:ireturn])
[:areturn]])
20)
this is almost working; I can return the object, but I can't cast it to an integer yet((bc->obj int
[[:aload 1]
[:ldc 0]
[:aaload]
[:checkcast int]
[:ireturn]])
(int 20))
(class (int 20)) ;; java.lang.Integer
is not working yetI suggest you read a bit more on the jvm data types before attempting to write bytecode
or I can learn to swim by jumping into the ocean, and ask here for help when I see sharks
((bc->obj int
[[:aload 1]
[:ldc 0]
[:aaload]
[:checkcast Integer]
[:invokevirtual Integer "intValue" [:int]]
[:ldc 22]
[:iadd]
[:ireturn]])
(int 20))
woot, it works!@bronsa: I acknowledge I may be in te wrong here, but in practice, I find dry documentation much easier to digest after I get a few working examples. Until I get a few working examples, there's no "skeleton" to attach the knowledge to, and everything just goes over my head.
Here's my full code (with bc->obj
serving as a function to test out all future isntrs); how would you optimzie stuff away
(defn bc->obj [ret code]
(let [co (ic/visit {:name "my.dyn.TestClass"
:fields []
:methods [{:name "go", :desc [[Object] ret] , :emit code,
:flags #{:public }}]})
obj (ic/new-instance co)]
(fn [& args]
(.go obj (object-array args)))))
((bc->obj int
[[:aload 1]
[:ldc 0]
[:aaload]
[:checkcast Integer]
[:invokevirtual Integer "intValue" [:int]]
[:ldc 22]
[:iadd]
[:ireturn]])
(int 20))
Are you suggesting:
((bc->obj int
[[:aload 1]
[:ldc 0]
[:aaload]
[:checkcast Long]
[:invokevirtual Long "intValue" [:int]]
[:ldc 22]
[:iadd]
[:ireturn]])
20)
?insn = all the raw performance of jvm bytecode + as a "macro language", all the power of clojure ... it's just not clear what Java has to offer over this
clarity
and C's __asm
has all the power of raw assembly + all the power of the C preprocessor so why would you use C over __asm
qqq is having fun with this and java is not fun at all
that's not what I was saying, I was pointing out how using a low level language + a macro system doesn't make much sense when you can achieve the same in a higher level language which is just a dsl for the lower level one
In fact, @bronsa, I think it was you who suggested insn when I first wanted to do "clojure dsl -> *.java -> load class" π
I never said I'd write jvm bytecode directly if I had the choice of writing java instead
@joelsanchez sure and he can have all the fun he wants, but if his goal is being productive, this is just not the way to go
there's good use cases for reaching for writing jvm bytecode, writing performant arithmetic in clojure is not one I'd consider such
@qqq java is essentialy a stupid dsl over jvm bytecode, there's no way that you can write faster jvm bytecode than what javac would emit for an equivalent java program
yeah it seems like its gonna be great. wanted to buy you a beer/tea/coffee if you were gonna be in town
I honestly don't think I'll be to the US for a conference if I'm not speaking (I could make an exception for strangeloop), we'll see tho
@bronsa: suppose you were writing num-clj, the clj equiv of numpy, would you write the primitives in java instead of having clj gen bytecode ? the later seems like it would be lower barrier to add new 'primitives'
I don't undertsand what people have against writing class Util { static int add (int a, int b) { return a + b} }
if all they want is integer addition
@bronsa: but I want to do more than addition; I want to implement things ilke J-style loopless code: http://www.jsoftware.com/help/jforc/loopless_code_i_verbs_have_r.htm#_Toc191734331
insn gives me the power to build my own abstractions on top of jvm bytecode, using the full flexibility of Clojure -- why would I want the pre-defined language 'Java' instead ?
@qqq I can't make a decision for your hypotetical scenario, I don't know what you are trynig to do or why you need this -- all I'm saying is that writing bytecode is not pleasant and it's easy to get wrong, while writing java is trivial. if you can do something in either way, I'd pick java over writing bytecode every day
there's a reason why people prefer higher level languages over lower level ones, they're easier to reason about and to write non-trivial code in
@qqq you can still use clojure and write the bits that you can't write in clojure in java