Fork me on GitHub
#beginners
<
2023-04-22
>
spacebat02:04:17

Hi, I've started using clojure a bit more lately and have run into this sort of thing in a few places while following tutorials: $ clojure -Ttools install com.github.seancorfield/clj-new -T is no longer supported, use -A with repl, -M for main, or -X for exec So I try substituting A, M or X and none of them work either

Alex Miller (Clojure team)02:04:49

You need to update to the current version of the Clojure CLI

Alex Miller (Clojure team)02:04:17

You’re running something several years old

spacebat02:04:06

Thanks, yes it was 1.10.2 - the "no longer supported" made me think that it was the tutorial that was old.

Alex Miller (Clojure team)02:04:27

Yeah there was an old -T, then it was deprecated, then it was added again for different use

quan xing15:04:22

I run clojure code show warring message:

WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-keys already refers to: #'clojure.core/update-keys in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/update-keys
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-keys already refers to: #'clojure.core/update-keys in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/update-keys
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.passes, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.passes.uniquify, being replaced by: #'clojure.tools.analyzer.utils/update-vals
How can I turn it off

Bob B16:04:05

iirc, there isn't an option to turn it off altogether, but an option would be excluding the conflicting functions from the require from which they're not wanted (assuming you control the ns that is making the conflicting requires)

Alex Miller (Clojure team)16:04:41

That’s already been done (long ago) in newer versions of tools.analyzer so likely updating your deps would fix it

quan xing16:04:51

Why does my clojure program get garbled Chinese from the database after compiling it into a jar file? But using clj-M :run directly is fine clj -X:project/uberjar :main-class app.main

hiredman17:04:07

I would start by checking your locale settings for the different ways your running the program

hiredman17:04:58

Like are you running clj and java (for running the uberjar) in the same shell session and getting different results, or is the environment where they are being run different and potentially contributing to different results

hiredman17:04:22

Same pc doesn't mean the environment is the same, how are you running clj vs how are you running the uberjar

quan xing17:04:17

I am running clj -M:run and java-jar uber.jar-Dfile in powsershell and there is no extra environment variable configuration information. Running java -jar uber.jar -Dfile.encoding=utf-8 The encoding printed in the command window is fine, but the access interface does return garble, and running with clj -M:run is fine

quan xing18:04:54

I use java -jar uber.jar -Dfile.encoding=UTF-8 return garble. use java -Dfile.encoding=UTF-8 -jar uber.jar is right!

seancorfield20:04:57

In the first form, the -D option is being passed as an argument to the main program, because it appears after -jar and the jar file. In the second, it is an argument to Java itself. In case you were looking for an explanation.

quan xing18:04:30

I use pgsql execute sql show error:

(jdbc/execute! conn
                 ["select * from sd_project where prjname like concat('%',?,'%') " "project001"])
Error: Data type of parameter $1 could not be determined
["select * from sd_project where prjname like ? " "%project001%"]
This is right

teodorlu19:04:52

Perhaps post in #C1Q164V29, that channel is specifically for jdbc, jdbc.next and related questions!

anovick20:04:51

Hello friends, :hugging_face: I am considering a move for a desktop GUI application of mine that is programmed using Electron(JS)/Node/Sqlite stack to move towards becoming an Electron(CLJS)/JVM(CLJ)/Sqlite stack which is more in line with my programming preference (also trying to challenge myself with more ambitious goals via more features with it in the future). I am very much a JVM newbie, but from the brief research I've done, it seems like I can communicate with the Sqlite binary that I bundle with the Electron GUI app with, using a JVM process that would be using the common JDBC database driver. This sounds alright to you? communicating between the Electron and the JVM process is the one thing that I have yet to explore yet. Currently, the Electron's renderer thread communicates with Node's process in quite a straightforward mechanism called an https://www.electronjs.org/docs/latest/tutorial/ipc#ipc-channels, where messages are sent and received through an API that manages this communication, globally defined in the Renderer thread and likewise in the Node thread. Do you have a recommendation how to perform this communication in the case of the Electron GUI with a running JVM process? (mainly to send queries and receive data from the database)

rolt09:04:00

your best bet is probably websocket between the renderer and the JVM, with transit format

anovick11:04:19

Thanks @U02F0C62TC1, it seems like WebSocket is the go-to communication channel for this scenario just as you say! I read some about another Electron application doing something similar here: https://matthiasnehlsen.com/blog/2019/02/28/meins-intro/

rolt11:04:13

for really high troughput maybe electron's IPC is better, and in that case something like renderer <- IPC channel -> nodejs <- capt'n proto (or something zero copy) -> JVM will be better. But it's probably not worth the additional effort