This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-05
Channels
- # announcements (1)
- # beginners (72)
- # boot (4)
- # calva (35)
- # cider (8)
- # clara (13)
- # cljdoc (31)
- # cljs-dev (34)
- # clojure (64)
- # clojure-europe (1)
- # clojure-finland (3)
- # clojure-italy (23)
- # clojure-losangeles (3)
- # clojure-nl (35)
- # clojure-uk (19)
- # clojurescript (26)
- # cursive (19)
- # datomic (12)
- # duct (5)
- # editors (7)
- # emacs (25)
- # fulcro (40)
- # funcool (5)
- # jobs (2)
- # leiningen (3)
- # luminus (2)
- # lumo (3)
- # off-topic (19)
- # pathom (3)
- # planck (2)
- # reagent (6)
- # remote-jobs (4)
- # rum (1)
- # shadow-cljs (23)
- # spacemacs (6)
- # tools-deps (12)
Thanks @manutter51, I notice that cmd + shift + L doesn't seem to work
It's listed as a command but nothing happens when I do it. And regarding a context menu, can't seem to find anything about REPL stuff, if by that you mean right click
@kamuela I think alt + shift + L on Windows/Linux would be opt + shift + L on Mac (not cmd) -- but I'm not a Cursive user so... Also, there's a #cursive channel where I believe folks are pretty active in help other Cursive users.
Looks like I'm wrong -- https://www.cheatography.com/pupeno/cheat-sheets/cursive-on-mac-os-x/ -- that surprises me, based on my experience in other editors, but there you go.
I was wrong -- https://www.cheatography.com/pupeno/cheat-sheets/cursive-on-mac-os-x/ -- just shows that different editors behave very differently across platforms @kamuela đ
Trying to follow the instructions for tools.deps to use a local dependency: https://clojure.org/guides/deps_and_cli#_using_local_libraries
but it fails with the error
Error building classpath. Manifest type not detected when finding deps for clojure2d/clojure2d in coordinate #:local{:root "/Users/yuhan/Github/clojure2d"}
must the dependency also be required to use a deps.edn config? This one happens to be using Lein with a project.clj
Yeah, thatâs not supported
Thanks - I got it to work by running lein uberjar
and pointing to the local jar instead.
I'm trying to print the result of (verse i)
as I go from start to 0, is this even the right approach?
it seems that you want dorun
or doall
.
for
is a âlist comprehensionâ, a kind of combination of map, flatmap, filter in a more straightforward way.
In Clojure there are 2 main ways to iterate: doseq
and for
. for
returns a lazy seq, which means the iteration doesnât happen until you ârealizeâ the result in some way. The REPL always realizes the result, so you wonât notice the difference at the REPL, but as soon as you use for
in some actual code, you may be saying, âWhy isnât it printing anything?â
The main purpose of for
is to take a list, and return a modified list. doseq
on the other hand, takes a list and does something to each item in the list, like printing.
(doseq [i (range 4)]
(println i))
0
1
2
3
nil
app:cljs.user=>
The numbers 0 thru 3 are the side effect of using doseq
, and the nil
at the end is the result of doseq
. Every function in Clojure returns something, and so doseq
returns nil
.
and the semantics of def
are significantly different than let
, so from a philosophical point of view destructuring in def
doesn't make as much sense as in let
i want to write a defmulti
that validates different kinds of âcomponentsâ of my application. the definition is: (defmulti validate-definition (fn [definition user-id] (:component/type definition)))
.
i saw that multi-spec can be used to return a different spec for a different return of the dispatch function, but in my case my validation function performs more validation than would be possible only with spec (e.g. call an external service to check if a resource exists).
is there a way to combine my defmulti
with multi-spec
or other thing that would allow me to perform basic validation of input data with spec and more specific validation on code?
I do really need some help here. I am getting a segmentation fault: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000010e54ef9a, pid=64230, tid=16643 # # JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.dylib+0x14ef9a]RUNNING Have anyone out there faced this kind of error? What situations might trigger a segmentation fault in Clojure or in Java/Clojure interoperability?
@rodrigo759 It's possible that you've hit a bug in the JVM -- it does happen -- Do you get this every single time you run your program? Do it happen when you do something specific in your project?
That's what is driving me crazy. It happens on the second time my routine is called via webserver. It does NOT happen if I put a breakpoint there and run it step by step. It makes no sense.
What sort of project is this? Java calling (compiled) Clojure? Pure Clojure? How are you running it? Is there a project.clj
file you can share?
I have a grails server that call my routine. First time runs OK. Second time breaks. If I put a breakpoint and stop on the call and run it step by step, it does not throw segmentation fault.
Ah, so Java calling (compiled) Clojure?
It is a huge project written in Grails/Groovy, Java and Clojure. Yes... A Groovy service calls Java/Clojure routines.
That's going to be really hard to debug I suspect đ
I've been trying for more than 2 days.
I tryied to write integration tests to reproduce the error but I failed. I call my routine hundreds of times and it works. It only breaks when It is called from the front-end using a Grails service. Then I suspect that it has something to do with threads.
When I realized that I does NOT break when I run step-by-step after a breakpoint, it blew my mind.
Can you share the full segfault output in a Gist? Just in case there's something in there that might trigger an idea from someone...
It writes a log file. I will attach it. Hold on.
Full segmentation fault log file
Can you try running it with this JVM option removed: -Xverify:none
You mean to include -Xverify:none ? Or to remove from the current call?
Remove it.
It prevent bytecode from being verified so you could be trying to run invalid bytecode. Without that option, you might get a validation error from a compiled class which would get you closer to the root cause.
It seems it is not there already. Have you seen something that make you think that it is there?
It's shown in the JVM dump. Along with lots of Grails-related options
jvm_args: -Dendpoints.shutdown.enabled=true -Denv=development -Dfull.stacktrace=false -Dgrails.env=development -Dgrails.full.stacktrace=false -Dinfo.app.grailsVersion=3.3.9 -Dinfo.app.name=server -Dinfo.app.version=0.1 -Djdk.reflect.allowGetCallerClass=true -Drun.active=true -Dspring.output.ansi.enabled=always -Dspring.profiles.active -Dspringloaded=inclusions=grails.plugins..*;synchronize=true;allowSplitPackages=true;cacheDir=/Users/rodrigo/Nitryx/Technical/Projects/braskem/brkm_app/server/build/springloaded -Dverbose=false -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:CICompilerCount=3 -agentlib:jdwp=transport=dt_socket,address=56606,suspend=n,server=y -javaagent:/Users/rodrigo/Library/Caches/IntelliJIdea2018.3/captureAgent/debugger-agent.jar -javaagent:/Users/rodrigo/.gradle/caches/modules-2/files-2.1/org.springframework/springloaded/1.2.8.RELEASE/b60bac05b0451cdc1863bfec617f39aa0dcaaa43/springloaded-1.2.8.RELEASE.jar -Xverify:none -Xms768m -Xmx768m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant
java_command: brkm_app.Application
Whatever you're using to run your program is adding it in.
and what is this class
Current CompileTask:
C1: 509202 15348 1 com.nitryx.brkmopt.util.ClojureHandler::k (123 bytes)
This is a helper class I wrote. I can share it:
I am looking for where to remove -Xverify:none
It looks like it's failing try to compile or do something with the com.nitryx.brkmopt.opt.utils/k
function but I'm not sure what the code in the stacktrace relates to...
V [libjvm.dylib+0x14ef9a] ValueStack::pop_arguments(int)+0x6c
V [libjvm.dylib+0xf4941] GraphBuilder::invoke(Bytecodes::Code)+0xae5
V [libjvm.dylib+0xf6f61] GraphBuilder::iterate_bytecodes_for_block(int)+0x2449
V [libjvm.dylib+0xf382d] GraphBuilder::iterate_all_blocks(bool)+0x6f
V [libjvm.dylib+0xf7d21] GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x2cd
V [libjvm.dylib+0xfd1f6] IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x154
V [libjvm.dylib+0xfd2a7] IR::IR(Compilation*, ciMethod*, int)+0x85
V [libjvm.dylib+0xe849f] Compilation::build_hir()+0xa7
V [libjvm.dylib+0xe862e] Compilation::compile_java_method()+0x58
V [libjvm.dylib+0xe8857] Compilation::compile_method()+0x6d
V [libjvm.dylib+0xe8a6c] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*)+0x1a2
V [libjvm.dylib+0xe91ee] Compiler::compile_method(ciEnv*, ciMethod*, int)+0x90
V [libjvm.dylib+0x1b55e6] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5b2
V [libjvm.dylib+0x1b7b2d] CompileBroker::compiler_thread_loop()+0x291
I wrote this method k() to convert java objects in clojure Keywords. It is used millions of time before breaking. And why it just works when I run in debug mode, step by step? đ°đ±
You're using a pretty old JVM 1.8.0_60-b27), built on Aug 4 2015
-- this may be a JVM bug that has been fixed since then. I would definitely try updating your JVM as a first line of debugging.
It also breaks on the Tester's machine running a newer version. I will upgrade! anyway
(I Bing'd irscope graphbuilder
and got a bunch of segfault results pointing to bugs in the JDK)
I wrote this method k() to convert java objects in clojure Keywords. It is used millions of time before breaking. And why it just works when I run in debug mode, step by step? đ°đ±
It also breaks on the Tester's machine running a newer version. I will upgrade! anyway
You mean to include -Xverify:none ? Or to remove from the current call?
@seancorfield running with -client (disabling server hotspot strategies) and -XX:CompileCommandFile=.hotspot_compiler excluding my ClojureHandler class, works. But runs super slooooow.
It must be a JDK1.8 bug. I will try to find another workaround without using the -client option because it dramactically decreases the performance. I am stuck to 1.8 due to Grails 3.
Are you still hitting the bug with the most recent JDK 1.8? Have you tried both Oracle JDK and OpenJDK versions?
I upgraded to the most 1.8 version and the bug still there.
I must use Oracle JDK... I found a combination of methods exclude from Hotspot that worked with Server Hotspot. Some methods not related to Clojure at all. @seancorfield Thank you very much for your assistance.
@rodrigo759 So you got it all working? Excellent!
Edge case stuff like this in the JVM can be really frustrating. In the roughly nine years I've been at my current work place I think we've run into maybe three or four JVM bugs and had to switch up versions or vendors of stuff in our stack... đ
hi! was trying to improve my repl workflow with alembic... after adding [alembic "0.3.2"]
to profiles.clj, emacs is able to autocomplete alembic.still
while in the user
namespace, but when i do (alembic.still/load-project)
, i get classnotfoundexception ... alembic.still
is there a way to set it up so that i don't have to require alembic each time?
you can add a require of alembic.still to your user.clj or your project.clj injections
i see, thanks!