Fork me on GitHub
#clojure
<
2016-03-26
>
isaac_cambron06:03:10

I don't quite know how to import types. Why can I do this:

product=> (use 'amalloy.ring-buffer)
nil
product=> (ring-buffer 3)
#amalloy/ring-buffer [3 ()]
but not this:
product=> (import 'amalloy.ring-buffer.RingBuffer)

ClassNotFoundException amalloy.ring-buffer.RingBuffer  java.net.URLClassLoader.findClass (URLClassLoader.java:381)
or:
product=> (import '[amalloy.ring-buffer RingBuffer])

ClassNotFoundException amalloy.ring-buffer.RingBuffer  java.net.URLClassLoader.findClass (URLClassLoader.java:381)

crocket07:03:10

I wonder if statically-typed clojure would be better.

bwstearns07:03:54

My understanding is that you can get speedups from it. I am trying but failing quite miserably to remember where I saw the benchmark, however this post (https://blog.juxt.pro/posts/typed-clojure.html) seems to imply that the speedups aren't as awesome as they could be if the compiler were type-hint aware, so the bulk of improvements might be primarily from the assurances that you're not going to run into type issues at runtime, which is still pretty cool.

crocket08:03:52

It's optional typing. I meant mandatory typing.

crocket08:03:23

But, optional typing may provide a good preview.

hans08:03:44

i think a good statically typed language needs to embody types at a very low level. bolted-on static typing quickly becomes annoying, and with lisps in particular as they usually interfer with interactive, repl-based development.

hans08:03:32

for me it is "lisp" or "statically typed". i can see the merits of both, but i see them as being basically incompatible.

crocket08:03:08

Lisp is incompatible with static typing?

hans08:03:20

@isaac_cambron: try amalloy.ring-buffer$RingBuffer if RingBuffer is a nested class

hans08:03:12

@crocket: yes. all attempts i have seen to retrofit static typing on lisps were basically unsuccessful as they interfered with the "lisp way" of developing too much.

crocket08:03:28

What if a new lisp language was designed with static typing in mind?

crocket08:03:03

Parentheses aren't necessarily incompatible with static typing.

hans08:03:36

@crocket: as i said, i see statically typed development to be basically incompatible with interactive, repl-based development. that does not have anything to do with parentheses.

crocket08:03:04

Haskell has REPL.

hans08:03:18

@crocket: right. i tried to use it once. that kind of repl is basically the same kind that python, perl and ruby have. an interactive evaluator that you can use to try out things, but not your central point of focus while developing actual programs.

crocket08:03:27

I'm still learning haskell, so I don't know how good haskell REPL is, yet.

malcolmsparks10:03:43

@hans that's a really useful insight, never thought about it that way

malcolmsparks10:03:46

I feel there's a general under-appreciation of interactive, repl-based development in many Clojure teams, some even end up using Clojure like Java, Ruby, C++ and it's merely just the 'typing' end of a build pipeline - whether under a fancy name like 'continuous delivery' it's basically swimming against lisp and then you start hearing complaints about the lack of types 😉

malcolmsparks10:03:16

I've always been drawn to the idea that interactive development shouldn't stop when you go into production - but that always provokes a torrent of disagreement I usually keep quiet!

malcolmsparks10:03:04

devops, for me, should be more about ops-becoming-devs, rather than today's devs-becoming-ops

crocket10:03:24

Embedding REPL server into production systems?

mikeb10:03:59

Just curious, how does static typing interfere with repl-based development?

sivakumargsk12:03:10

I am trying to use react-bootstrap components in Clojure script using Cljs-js packages. The problem is I try to convert react component into reagent. React component --------------------------------------------------------------------------------------- const tabsInstance = ( <Tabs defaultActiveKey={2} position="left" tabWidth={3}> <Tab eventKey={1} title="Tab 1">Tab 1 content</Tab> <Tab eventKey={2} title="Tab 2">Tab 2 content</Tab> <Tab eventKey={3} title="Tab 3" disabled>Tab 3 content</Tab> </Tabs> ); ReactDOM.render(tabsInstance, mountNode); Reagent ------------------------------------------------------------------------------------- (def tab (reagent/adapt-react-class (aget js/ReactBootstrap "Tab"))) (def tabs (reagent/adapt-react-class (aget js/ReactBootstrap "Tabs"))) (defn left-tabs [] [:div [tabs {:default-active-key "{2}" :position "left" :tab-width "{3}"} [tab {:event-key "{1}" :title "Tab 1"} "Tab 1 contant"] [tab {:event-key "{2}" :title "Tab 2"} "Tab 2 contant"] [tab {:event-key "{3}" :title "Tab 3"} "Tab 3 contant"]]) how to write this ""eventKey={3}"" in Clojure script

thomas13:03:56

Hi, what is a good place to ask Tower questions? The i18n lib for clojure?

thomas13:03:31

I am trying to figure out how to determine the locale at runtime… the examples all seem to be hardcoded

lumengxi15:03:41

Hi, i have question about clojure.jdbc, i use jdbc/with-db-transaction to stitch a few operations together (insert, update, delete etc), and since autoCommit is set to False in with-db-transaction by default, my delete statements didnt work. What is the best way to overwrite that config within the transaction?

hiredman16:03:36

lumengxi: that behavior is going to depend on the database you use and what transaction isolation level you use

bwstearns17:03:37

@crocket lisp with typing system: Shen

bwstearns17:03:10

@crocket: http://shenlanguage.org/ It has lots of awesome weirdness to it but it seems like there are about 10 people using it.

bhauman18:03:28

So it seems like resources need to be addressed with a normalized path that only has / separators? I.e. (io/resource "mydir/my-file.txt")

bhauman18:03:39

I'm having trouble finding resources on a Windows machine where I've been using local File separators

hiredman18:03:26

resources aren't files, is the thing

hiredman18:03:00

resources are byte streams the classloader gives you, and where the classloader gets them is kind of abstract

hiredman18:03:35

they could come a file on the classpath, they could come from inside a jar file, the classloader could just make them up

bhauman18:03:23

Thank you that was super helpful. This all makes perfect sense I just wanted confirmation as all my systems are / systems anyway. And it's probably a good time for me to read the classloader docs. Thanks again

isaac_cambron22:03:06

I've finally gotten around to upgrading my project from 1.6 to 1.7, but I'm having some issues with protocols. Specifically, when just loading things in the repl, I'm getting "No implementation of method" errors. My project Uberjars fine, so I suspect it's some sort of load order type thing. Before I dig too deep, is there some big thing I need to do differently in 1.7. to get my protocol implementations to work? I looked at the changes file but nothing jumped out.

isaac_cambron22:03:40

(the reify calls in question look fine, fwiw)

hiredman22:03:26

I would rm -rf target

isaac_cambron22:03:49

Oh, right. Always a good idea

isaac_cambron22:03:05

I feel like I jump on IRC every once in a while and ask a very confused question like that, get exactly that answer, and it usually works

hiredman22:03:23

if at all possible, stop aot compiling your projects then

isaac_cambron22:03:50

Not really an option for me, unfortunately

isaac_cambron22:03:02

without it, my startup time is measured in minutes

isaac_cambron22:03:44

that's its own problem i should figure out

isaac_cambron22:03:47

in the meantime...

hiredman22:03:05

sounds like some really badly performing macros

isaac_cambron22:03:43

There's definitely some of that. I have the strong suspicion that I'm in the top 1% of core.async users

hiredman22:03:09

oh, sure, that would be a gnarly macro

isaac_cambron22:03:31

well, good news! rm -r on target fixed my protocol problem. so thanks!

isaac_cambron22:03:23

Yeah, core.async is wonderful, but it isn't very friendly to the compiler

hiredman22:03:37

you should be careful, if rm -rf target fixes you problems, you may also have been running using stale code for a while, so you could end up exposing code paths for the first time that you thought you were exercising for a while

hiredman22:03:18

(I would be experiencing some amount of existential dread)

isaac_cambron22:03:39

Eh, when upgrading major clojure versions, existential dread comes standard