Fork me on GitHub
#beginners
<
2016-01-08
>
noisesmith00:01:48

@akiva: some-> instead of -> at least stops if it hits nil - which isn't error checking per-se but sometimes it is all you need

akiva00:01:48

That’s a good short circuit, you bet.

noisesmith00:01:53

hoopes: also, instead of checking explicitly for errors, we typically have exceptions and exception handlers when runtime errors are an issue

noisesmith00:01:31

so the whole let block can be in a try/catch and then you could potentially throw at each step if there is a problem

noisesmith00:01:05

hoopes: in practice having to opt-out of short circuiting on errors (via try) leads to better reliability than having to opt-in to checking for errors

hoopes02:01:30

@noisesmith: thanks - i'll see what i can work up with that strategy

victorbjelkholm13:01:19

Hey, new to clojure and the whole thing, probably a stupid question but I want to require a package only for the repl to try it out, how can I achieve that?

donaldball13:01:39

People often recommend lein try for that sort of thing

victorbjelkholm13:01:14

@donaldball: yeah, I am using lein but I can’t figure out the command with lein to do it even...

victorbjelkholm13:01:28

@donaldball: yeah, just found out for that

victorbjelkholm13:01:09

oooh, now I get what you meant. I didn’t understand you mentioned a plugin called “lein try”, thought you meant that "people use lein for that, try it"

donaldball14:01:35

Heh, sorry for the ambiguity, should’ve linked

victorbjelkholm14:01:39

haha, don’t worry, thanks for trying to help @donaldball! Sorry for not understanding you correctly

jcomplex15:01:04

Has anyone dealt with this error? SQLException No suitable driver found for jdbc:sqlserver:

jcomplex15:01:58

And if you have can you please help me get around it? I have been fighting it for a day and I can't afford more time but it is stopping my progress.

jcomplex15:01:11

I have added the jar to my classpath and when I try (. System getProperty "java.library.path") C:\\Program Files\\Java\\JDBC\\sqljdbc_4.1\\enu\\sqljdbc4.jar; is part of the path

jcomplex15:01:29

So now I am completely lost

donaldball15:01:07

Perhaps the class isn’t loaded

donaldball15:01:29

Looks like com.microsoft.sqlserver.jdbc.SQLServerDriver

donaldball15:01:52

When you type that at the repl, does it return the class?

jcomplex15:01:25

CompilerException java.lang.ClassNotFoundException: com.microsoft.sqlserver.jdbc.SQLServerDriver

jcomplex15:01:45

So how do I load the class?

donaldball15:01:41

In java, you’d do Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver”);

donaldball15:01:27

tbqh I think clojure does that automatically when it tries to resolve a class, but you could try (Class/forName “com.microsoft…”)

donaldball15:01:45

Are you sure the path to that jar is correct?

jcomplex15:01:15

Yea it is followed to the jar

donaldball15:01:17

I’m afraid I’m not of much help then 😞

donaldball15:01:24

Are you using leiningen by chance?

donaldball15:01:30

Though curses, that’s not much help because maven doesn’t have an artifact for sqljdbc

donaldball15:01:10

If you don’t require the microsoft driver, you could try jtds

donaldball15:01:41

Leiningen value would be e.g. [net.sourceforge.jtds/jtds "1.3.1"]

donaldball15:01:20

That might at least let you make some progress until you can sort out your classpath issue with the Microsoft driver

donaldball15:01:19

Clojure.java.jdbc has some instructions for installing the Microsoft driver in your local maven repository: https://github.com/clojure/java.jdbc#releases-and-dependency-information

seancorfield19:01:27

Re: MS SQL Server driver — it’s free to download and you can install it into your local Maven repo cache with lein-localrepo.

seancorfield19:01:13

That’s how I test clojure.java.jdbc against SQL Server. I have the Microsoft driver installed locally (on my Mac) and then just depend on it in project.clj like all the other drivers I test against.

jcomplex19:01:07

@seancorfield: @donaldball thanks for all your help

donaldball19:01:34

Hopefully you are now unstuck?

jcomplex20:01:25

@donaldball: I am now dealing with this: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006f577797, pid=12708, tid=20412 # # JRE version: Java(TM) SE Runtime Environment (8.0_66-b18) (build 1.8.0_66-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b18 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x67797] # # Failed to write core dump. Minidumps are not enabled by default on client vers ions of Windows

donaldball21:01:06

That is not good. Core dump tends to indicate a JVM bug or something wrong in native code.

donaldball21:01:21

Do you know what’s triggering it?

donaldball21:01:02

I’d immediately be suspicious of the sqlserver driver, but @seancorfield has pretty good test in clojure.java.jdbc iirc

jcomplex21:01:43

ok here we go I have a new error: Jan 08, 2016 4:11:52 PM com.microsoft.sqlserver.jdbc.AuthenticationJNI <clinit> WARNING: Failed to load the sqljdbc_auth.dll cause :- no sqljdbc_auth in java.library.path

jonahbenton21:01:26

that's likely the reason for the JNI failure. When you pulled down the sqlserver jdbc driver it should have also come with that sqljdbc_auth.dll file (a native Windows DLL). stick that file into your windows/system32 directory.

jcomplex21:01:58

so that is what was causing my error from before

jcomplex21:01:44

placed it in system32

jonahbenton21:01:02

if you run the app again it should progress beyond the failure to load the underlying native code.

jonahbenton21:01:39

though a "type 4" jdbc driver- what microsoft reports you are downloading from that url- is supposed to be 100% java and not have native code dependencies.

donaldball21:01:00

I think that’s among the reasons folks tend to prefer the tds driver

seancorfield23:01:44

Yeah the driver I test with is pure Java (since I deliberately test connecting to SQL Server from a non-Windows machine).

jonahbenton23:01:08

we determined that the reason the type4 driver was pulling in native code was because of the "integratedSecurity" configuration- which uses native windows authentication and authorization mechanisms between the app and the database rather than name/password credentials

jonahbenton23:01:56

with integratedSecurity=truthy the driver expects to find an appropriate sqljdbc_auth.dll

jonahbenton23:01:29

what's likely happening is that the jdbc and native driver versions were different

jonahbenton23:01:20

leading to jvm death

seancorfield23:01:41

Ah, interesting. Never run into that. Aside from testing, I generally avoid Microsoft anything :)

jonahbenton23:01:21

yeah, absolutely. striking though that for beginners, having clojure be a "hosted" language in this particular case leads to this perfect storm of nasty platform dependencies- the java/maven ecosystem, java's funky native platform integration, and the dependency nightmare that is windows

shaun-mahood23:01:37

There are definitely some added issues using Windows, but I've actually run into way less problems with Windows dependencies on when developing Clojure than .NET.

shaun-mahood23:01:03

Main problem I've run into is closing files - seems like things that work elsewhere don't actually close files properly on Windows.

shaun-mahood23:01:52

And so far the jtds SQL driver with clojure.java.jdbc has been super solid

jonahbenton23:01:45

interesting. does it support that native authentication stuff? or only conventional username/password?

shaun-mahood23:01:57

I've never tried, but according to http://stackoverflow.com/a/801113 it looks like it supports native auth as well

shaun-mahood23:01:59

Though it mentions having a single sign on library installed, so may be some added complexity there