#clojure log - Jun 03 2008

The Joy of Clojure
Main Clojure site
Google Group
List of all logged dates

11:35 Chouser: Is there any more convient way of building an Object[][] from a vector of vectors of various constants, other than to walk the vectors and build up the array using (to-array)?

11:36 rhickey: no

11:41 Chouser: (to-array (map to-array data)) isn't too bad I guess.

11:41 but that's an Object[] of Object[], which isn't the same as Object[][], is it?

11:41 rhickey: yes it is

11:41 Chouser: Here I'm running into my Java ignorance.

11:41 hm. ok.

11:42 rhickey: no real multidimensional arrays in Java

11:42 just arrays of arrays

11:43 Chouser: ok. So my "No matching ctor" is something else... ;-)

11:49 Any relationship between PersistentVector and java.util.Vector?

11:50 rhickey: no

11:50 I guess they are both java.util.Collections

11:57 lisppaste8: Chouser pasted "ctor confusion" at http://paste.lisp.org/display/61639

11:57 Chouser: I missing something, but I don't know what.

12:07 rhickey: you should be using into-array

12:08 to build the dataArray

12:09 btw such names as dataArray are ugly for Clojure, should only be used for Java names

12:10 in any case to-array always yields an Object array, into array yields an array of the type of the first element

12:10 into-array

12:10 (def dataArray (into-array (map to-array data)))

12:11 user=> (class dataArray)

12:11 class [[Ljava.lang.Object;

12:12 misunderstood what you were trying to imply by "Object[] of Object[]" before

12:14 Chouser: ah, cool. works perfectly!

12:15 I should be using - between words instead of camelcase?

12:15 rhickey: yes please :)

13:26 Chouser: have people's opinions about (new Foo) vs. (Foo.) consolidated at all?

13:31 jgracin: I don't like the new new syntax. I find (new Foo) more consistent, logical and Lispy.

13:32 jteo: agreed.

13:37 cgrand: idem

13:40 Chouser: ok

13:45 even though it makes this a lot longer?

13:45 (-> urlstr URL. .openConnection .getContent InputStreamReader. BufferedReader.)

13:46 And you'd have to do that backwards too, right? (new BufferedReader (new Input... (new URL urlstr)...))

13:50 rhickey: I think (Foo. args) is more lispy - makes for a named function vs generic new. You wouldn't want to have to say (call fname args) every time would you?

13:51 also, nested ctors look more declarative that way

13:52 -> is not very lispy but very convenient

15:09 fyuryu: I prefer (Foo. ...) over (new Foo ...) - looks better, especially when you pass args to the constructor

16:19 Chouser: so ... the opinions haven't consolicated much at all. ;-)

16:21 cgrand: I'll try to force me to use Foo. instead of new -- maybe I need to overcome a bias induced by familiarity :-)

16:21 rhickey: There was one benefit of CL's make-instance vs the defstruct generated make-x, and that was that the type truly was a parameter of the function - it was a symbol and could have a dynamic value. That's not the case for new, where it is syntax.

16:58 Chouser: Will a PersistentVectors handle sparseness efficiently, or should I use a Hash for that?

17:20 any way to "initialize a class" without calling (. Class forName "Foo")

17:20 [note: I don't really know what I'm talking about]

17:21 rhickey: Chouser: maps for sparse

17:21 Foo

17:21 Chouser: thanks re: sparse

17:22 I thought Foo would do it, but I'm trying to use java.sql.DriverManager, and unless I call forName first, it doesn't recognize the url I give it.

17:23 rhickey: name the specific driver you are using?

17:24 lisppaste8: Chouser pasted "org.postgresql.Driver" at http://paste.lisp.org/display/61660

17:31 drewr: Chouser: Did you (sql/register-driver "org.postgresql.Driver") ?

17:31 Sorry, that's based on the sql.clj from webjure.

17:31 But you can see how he does it in there.

17:32 * Chouser looks

17:33 Chouser: He calls (. Class forName "Foo")

17:34 Nothing terribly wrong with that, other than having a class name in a string.

17:34 I was hoping for something like (. Foo init)

17:50 gah. more annoyingness -- I have to include the postgresql jdbc .jar in my commandline classpath. Adding it with add-classpath doesn't work.

17:51 If I use add-classpath, (prn org.postgresql.Driver) works, but (. Class forName "org.postgresql.Driver") fails.

17:52 rhickey: you can't use add-classpath to expose things to classes loaded above Clojure in the classloader hierarchy, like the sql library

17:52 Chouser: yeah, I see that.

17:53 It seems to be to be a failing in the DriverManager API. I should be able to pass it a class to use.

17:53 ooh!

17:53 rhickey: I bet org.postgresql.Driver works now

17:53 without classForName

17:55 Chouser: now? you checked in changes?

17:55 rhickey: no, with the jar in the commandline classpath

17:56 Chouser: oh. no, that's what I was doing originally.

17:56 I double-check.

17:57 nope. java.sql.SQLException: No suitable driver found for jdbc:postgresql:ivytech

17:57 I need the jar on the command-line and forClass in the code.

18:03 it looks like org.postgresql.Driver has a anonymous class-static function (??) and perhaps it's not getting called without forName?

18:04 http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/Driver.java.in?rev=1.73

18:07 Instead of forClass I can use: (. java.sql.DriverManager registerDriver (org.postgresql.Driver.))

18:07 but I still need the .jar on the command-line.

18:09 rhickey: jar on the top level classpath is mandatory in this case, a child classloader can't provide classes to its parent

18:10 Chouser: I guess I don't really understand classloaders. I figured if I was passing the class directly that that would work.

18:11 that nasty old classpath-add function I posted a while ago works, though, since it adds the classpath directly to the system classloader.

18:12 rhickey: right, but don't expect to do that on a server

18:13 Chouser: can I not cause the child classloader to handle java.sql.DriverManager as well, so that it can see classes I load later?

18:13 rhickey: add-classpath is a utility to allow you to grab a lib and start using it without restarting. If you end up using it, it should end up in tha classpath

18:14 Chouser: the reason I'm attracted to it in this case is that it would allow my app to dig around in the filesystem looking for an appropriate .jar.

18:14 rhickey: correct classloaders delegate to their parents first, and mine do too, so the system classloader will load java.sql.DriverManager

18:15 Chouser: Hmph.

18:16 rhickey: a database driver is not something to find at random on your filesystem :)

18:18 Chouser: I guess I just don't "get" Java.

18:19 With python, perl, ruby, etc. when a support library is installed on a system, it's installed in such a way that a program can simply ask for it and start using it.

18:20 Java requires this extra manual step of setting the classpath.

18:20 On systems I've used, the classpath provided by default includes no support libraries, just the core Java stuff.

18:21 So what's an application provider to do? One option would be to look at standard places where .jars might be installed, load them, and use them. But apparently I can't even do that.

18:21 rhickey: ship the jars you use

18:22 Chouser: Jars can include native binary code, can't they?

18:22 rhickey: jars are just packaging, but normally, no, just bytecode

18:24 Chouser: Is that really the "normal" answer? It looks like there's a different postgres driver for each major version of postgres, even though they have the same Java API.

18:25 should I include all of them and hope one of them matches the db server installed on the target system?

18:25 rhickey: This is a hypothetical situation, in reality people test pretty extensively on their exact target platform/version

18:27 If you were shipping JDBC-based software you'd have nothing to do with the driver setup - an admin would do it and configure it and pass you a connection string and it would work

18:27 Chouser: well, I'm sorry to vent here. I'm not really trying to make you defend Java. But this isn't hypothetical -- I'm providing a small app to be run by our developers. We support a couple versions of postgres and mysql, and I'd like my app to work out of the box for them.

18:28 rhickey: SQL drivers are an admin function - have your app take a connection URL

18:31 if there's no server and no admin, at least take that logic out of your app

18:34 Chouser: I guess. It seem unfortunate that installing the driver isn't enough, you also have to configure the classpath. Is there some reason the default Java classpath isn't set up to include every .jar installed on the system by default?

18:34 rhickey: versioning, security

18:43 dudleyf: rhickey: So you're not in favor of having a Clojure "library path"?

18:43 Chouser: perl, python, ruby, and even linux runtime linking for native binaries have all solved those problems satisfactorily. I guess I can provide a shell script and .bat file that bootstrap my app, just like every other Java app has had to do.

18:45 rhickey: your kidding, right? none of them have security, Ruby and Python have no multithreaded story, Java torches them all for performance etc etc

18:45 you're

18:47 I'll admit Java is less carefree, but when you have serious work to do, it's a serious tool

18:48 http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html

18:49 http://docs.python.org/api/threads.html

18:50 there's no free lunch

18:50 Chouser: this issue has nothing to do with support for threads. I'll read that ruby link.

18:51 rhickey: It has to do with comparing platforms based on one dimension - if you switch to Python for its carefree lib distribution, you get GIL with it

18:53 No one likes the classpath, but everyone gets over it

18:53 Ycros: but does that really matter if you have like the python processing package?

18:53 rhickey: Look, I didn't start comparing langs/platforms...

18:53 Ycros: there's a lot of argument against threading in general

18:54 I see your point though

18:54 Chouser: I'm not talking about switching to Python. I'm talking about fixing Java and/or using clojure to work around Java weaknesses.

18:54 rhickey: Ok, so the best route is not to fight Java but to understand it

18:55 Chouser: The only reason I brought up other platforms is to demonstrate that this particular problem (convenient library distribution) has been solved many times.

18:55 rhickey: What you now consider a weakness you might not when you are building a different kind of app

18:56 Ycros: you can set the classpath through an environment variable. If your machines have one configured, then conceivably you could install your dependencies in the same place across all your machines

18:57 rhickey: Part of the classpath/jar story has to do with application isolation - to the extent apps are self contained they can run in isolation and there aren't the - "please install this lib on the server' aspects

18:58 there are plenty of admins who won't install the Ruby runtime, never mind its libraries

18:58 Ycros: I've certainly distributed python apps with my own versions of libraries bundled with them, and I've done that with ruby apps as well

18:58 dudleyf: rhickey: Will there ever be a "clojure" executable, or will Clojure applications always need a shell script launcher like Java?

18:58 Ycros: for something like rails, you _do not_ want to run against system installed versions of rails and most of your deps

18:59 rhickey: dudleyf: executables are not portable, so not my thing, but nothing is stopping someone from making a bundler for each platform

19:01 Lau_of_DK: What is the recommended "main loop" to prevent instant exit when running clojures from the commandline?

19:01 dudleyf: rhickey: "executable" should have been in quotes, a shell script would work

19:01 but a standard mechanism for executing Clojure code

19:02 So that you don't have to bundle a launcher script with every Clojure application you want to share

19:02 Ycros: couldn't you package them up as jars? then you'd be running java -jar <your jar>

19:03 not sure if you'd need a bootstrapper class of some sort

19:05 Lau_of_DK: What is the recommended "main loop" to prevent instant exit when running clojures from the commandline? Just to keep the main messagepump running for the GUI.

19:11 rhickey: Lau_of_DK: does the latest clojure.lang.Script not work for that?

19:12 Lau_of_DK: Sure, .Script executes that file, but if the file loads a frame or such, without a loop that must be broken by the GUIs exit signal, then the frame just loads and disappears, which is should. Im just wondering how you would do something similar to C's while (true) { } in Clojure

19:14 rhickey: If you write an app that mimics this, it should work the same:

19:14 http://java.sun.com/docs/books/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start//HelloWorldSwing.java

19:16 Lau_of_DK: Alright, exactly what I needed to see, thanks

19:19 drewr: http://reddit.com/r/programming/info/6lv71/comments/

19:37 dudleyf: rhickey: Sorry to keep harping on this, but are you saying you wouldn't ever include a "clojure" script that runs clojure.lang.Script or .Repl as appropriate into the distribution?

19:37 Just trying to clarify, not annoy, I promise ;-)

19:38 rhickey: If someone wants to make a set of scripts for all platforms, then maybe. It's not something I personally am going to work on.

19:40 dudleyf: That's cool. I just wanted to know if you were philosophically opposed, or just uninterested.

19:40 What are "all platforms", BTW?

19:40 rhickey: It's a ripe area for contributions :)

19:41 OS X, Windows, Linux

19:42 albino: Chouser: python has PYTHONPATH like java's CLASSPATH, just not as crippled (you can point it to directories)

19:42 rhickey: Sorry all if I seemed a bit cranky on the library thing, but I don't think these scripting languages have solved problems the Java ecosystem hasn't. They haven't even been applied to a tiny fraction of the problem domains Java has, from phones to CERN. I think it's easy to make simple things simple, but much harder to make hard things possible. Perhaps in making hard things possible Java has made easier things less simple. But I'm pret

19:43 albino: Chouser: although python does have site-packages which is fairly nice for being a place to drop 3rd party libraries

19:45 that seems like a fun project, creating a native binary for clojure for different platforms

19:47 Lau_of_DK: Yea, it would be a great plus

19:47 That - and a boatload of tutorials to attract more developers :)

19:48 albino: That last one is probably on us, the community hanging out in the IRC channel

19:49 Lau_of_DK: Yea. Would be good to set up some sort of website for it, where we could all contribute, and then the tutorials could be looked through, optimized, whatever, and posted on some website or something. I think that would be good

19:49 But I'm not sure how many people are attracted to Clojure that dont have a strong background in Lisp?

19:50 dudleyf: Lau_of_DK: I'm one.

19:50 Lau_of_DK: k.. so there's 1 :)

19:50 albino: That doesn't seem like much of a reason to stop writing tutorials

19:50 who cares where they come from

19:50 Lau_of_DK: hehe, albino, it was a different point

19:50 It was not related to the tutorials

19:50 albino: oh

19:50 Lau_of_DK: I was more along the thought-train of attracting people to the language

19:50 albino: The "But" got me

19:51 dudleyf: rhickey: You're exactly right. But just because Java has made easy things complicated doesn't mean that Clojure needs to follow suit ;-)

19:51 Lau_of_DK: albino, the but ?

19:52 rhickey: I personally don't find the classpath all that complicated - classloaders are a bit tricky

19:52 I would love for the more experienced here to contribute to the Wiki...

19:52 dudleyf: I'm still mostly talking about just running a single small bit of code

19:54 The library thing is a problem that I don't think anybody's gotten right yet

19:55 But it's better to stay out of the game than to bake a bad idea into the language

19:56 albino: Lau_of_DK: you started your setnence following the one about writing tutorials with "But", that made me think the two statements were connected.

19:57 dudleyf: bbl

19:59 Lau_of_DK: Sure, I can see I wasn't quite clear :)

20:00 rhickey: dudleyf: point taken about small bits of code. I guess I have a certain bias as I mostly write pretty complex apps like broadcast automation systems, schedulers, election projection systems, etc. So all the input re: scripting-level app issues is informative...

20:06 poll: coming to Clojure, primary prior exposure to: Java/Lisp/Python/Ruby/Haskell/Other?

20:07 Lau_of_DK: Lisp

20:08 albino: Python + (tiny bit of Java)

20:09 rhickey: but I don't count I've only written like 15 lines of clojure

20:16 Ycros: I primarily use python, ruby, php, javascript, I did C# for 2.5 years but I haven't touched it in a few months, I've been dabbling in common-lisp, erlang and OCaml

20:16 now I'm dabbling in Clojure :)

20:19 actually, before doing C#, I was doing Java for about 2 years

20:20 Lau_of_DK: I think the step from another Lisp to Clojure is a natural one. I was happy to see that although Ive never touched Java, that my C# experiences translated almost directly, with no surprises. I think it takes a little more eye-opening for traditional Java/C# programmers to make the switch though

20:21 rhickey: It'll be interesting - I'm speaking to a Java group this Thursday and it will be the first time I'll really be explaining the Lisp aspect of Clojure from scratch

20:22 Lau_of_DK: Whoa - I think you should really consider doing a screencast of that - If for no other reason, then I really wanna hear how you go about it

20:22 :)

20:24 Chouser: significant work in: perl, python, ruby, C, C++, JavaScript, and quite a while ago some Pascal and TCL/TK. some exposure to: Java, Scala, lisp/scheme, Visual Basic.

20:25 rhickey: Chouser: yay - you're back! (afraid I'd driven you off) :)

20:25 Chouser: oh, not at all. I'm hope I didn't annoy you too much.

20:26 I was eating dinner, putting kids to bed, etc. ;-)

20:26 In my attempts with OCaml, haskell, and erlang, I always came out the loser. Actually, maybe Java's in that category too.

20:27 Lau_of_DK: rhickey, seriously, would you consider doing a screencast of that talk ?

20:28 rhickey: I intend to try - last time the screencast software crashed my machine during the presentation - I guess I'll have to pause every hour or so :)

20:28 Lau_of_DK: Come on, how long would it take to write new sc software in clojure? :)

20:29 * rhickey is busy writing Clojure and hoping to get back to his machine listening project...

20:30 albino: Chouser: Quite a laundry list there

20:30 Lau_of_DK: But I think that kind of talk could really draw in alot of Java/C# programmers, because going from that background to Lisp can be a pretty unsatisfying feat if you dont get proper guidance.

20:30 rhickey: yes, it's a gap in the Clojure materials right now

20:30 Chouser: albino: I used to think so, but recently I've been noticing that most of those languages have a *lot* in common, compared to some others.

20:31 rhickey: and referring people to other Lisp tutorials is a mixed bag as they don't quite match up with Clojure

20:31 albino: The other screencast seemed to get some questions I would expect from non-lispers

20:31 Chouser: I would fail at trying to do significant amounts in that many languages, my brain is too small

20:32 Chouser: I'm on a quest to find the "best" language. Of course my definition of best changes with each language I learn...

20:32 ...and each project I work on.

20:33 albino: Chouser: Ahh, aren't we all on that quest

20:33 Lau_of_DK: rhickey, true. But I think as a principle, if you don't know Lisp then the combination of 1 Paul Graham article on the success of viaWeb, Practical Common Lisp and the SICP videos can be a good way to get going.

20:33 Chouser: Clojure's the best yet. :-)

20:33 albino: Wow, a viaweb believer

20:34 I keep trying to get time to go through factor, common-lisp, or clojure. I haven't yet made the time work.

20:34 rhickey: I do think Clojure is substantively different from other Lisps, and much more approachable - I'm biased of course :)

20:34 Ycros: Chouser: I've come to the conclusion that there is no best language

20:34 albino: Chouser: any smalltalk?

20:34 Ycros: Chouser: I've happily settled on Python as being my all-round best language for most things though

20:35 Lau_of_DK: rhickey, I dont deny it, but its still a valuable background. When you really get the sense of how much you can do with the core elements of a Lisp, and youre all set, you've got your macros ready, emacs is fired up, and then somebody says "AND, you can use every Java library in the book" - well, then you know the rest, its a pretty motivating thing :)

20:35 Ycros: rhickey: you get to use all the Java libraries, AND you're ditching legacy apis - one thing that I disliked about common lisp

20:36 Chouser: Ycros: no best language *yet* :-)

20:38 Ycros: Chouser: I'm not sure how to define a best language

20:38 like, I don't think I could put together a list of features, and say "the best language has these features"

20:40 Chouser: Can't a language have every feature? Or at least, allow you to build any feature you need?

20:40 albino: PG likes to think in terms of the 100 year language

20:41 rhickey: Lau_of_DK: I'm not sure - most Lisp tutorials have pictures of cons cells early on - that's totally not relevant for Clojure

20:41 Chouser: And Yegge likes to think of the Next Big Language. *shrug*

20:43 Ycros: Chouser: I'd love static typing with type inference by default, but dynamism where you need it

20:43 Lau_of_DK: rhickey, alright, maybe you're right, we'll wait and see :)

20:43 Chouser: I think most programmer have heard of lisp and already formed an opinion. I would guess most who are happy to use Java probably have unfavorable opinions of lisp.

20:44 whether it's the parens, the libraries, or the lack of static types. I don't know if presenting Clojure as a lisp is the best way to win them.

20:44 Ycros: yeah, me too. But I don't know enough to accurately describe that, let alone build such a beast. I'll be curious to see where JavaScript ends up there.

20:45 Rhino with PersistentHashes underneath? ;-)

20:45 rhickey: Chouser, that's true, but I don't know a more concise way of implying code-as-data/syntactic abstraction/dynamic etc etc

20:47 but the biggest pushback I've gotten from devs is on the practicality issues, at least when trying to sell them on Common Lisp. Those same guys are crazy about Clojure

20:47 libraries, interop with existing systems

20:47 Chouser: rhickey: yeah, I'm sure that last point is true. That's why Yegge is on the JVM, because that's all Google will let him do.

20:48 but for those first two features (code-as-data, syntactic abstration), if you understand those and really think they're important, you're already a lisp fan whether you know it or not.

20:48 rhickey: Google/Amazon/Yahoo are on the JVM because it works

20:49 Chouser: Google also uses a lot of Python. But I'm not arguing that point. ;-)

20:49 I've been trying to think of how to highlight the similarity between clojure and non-lisps"

20:49 literal vector and hash syntax.

20:49 rhickey: Chouser: right tool for each job, until something more general comes up

20:50 Chouser: yes, I'm starting with the data structure literals, then - surprise! that's the syntax too!

20:50 Chouser: most languages use basically a prefix notation, lisp is only different on where the first paren goes (func a b) vs. func(a, b)

20:50 rhickey: yeah, that's good.

20:51 rhickey: interactively playing with Java libs is something they can't do in Java

20:51 Chouser: I think if I can avoid examples that include math, maybe they'll stop noticing the prefix notation early.

20:52 rhickey: heh

20:52 Chouser: rhickey: yeah, the REPL is good. There are people who like python and ruby almost entirely because of that.

20:52 and there's something almost magical about building a GUI interactively at the REPL (like the ant demo)

20:53 rhickey: yeah

20:53 Lau_of_DK: Its a unique feature, thats for sure

20:53 Chouser: TCL/TK was my first experience with that, and it almost made up for the terrible language.

20:53 bbl

20:54 rhickey: also, if they do any multithreading Clojure is like complete magic

20:55 * rhickey has many scars/nightmares from MT in C++/C#/Java

20:56 Lau_of_DK: Yea its no joke - Still - genious as it is - this immutable persistance takes a little getting used to

21:05 Question: Do I need to call close to my open i/o streams, or does Clojure handle that?

21:06 Chouser: right. So that was my thought -- hilite the similarities between clojure and other language (Java, C, Python) syntax, and then move on to clojure's more unique features: REPL, persistent structures, convenient functional apis, ... not sure how much more time there would be.

21:06 Lau_of_DK: (doc with-open)

21:07 rhickey: I've got 2 hours this time

21:08 albino: rhickey: you don't happen to be streaming live, do you?

21:08 Lau_of_DK: Chouser, exactly what I needed, thanks

21:11 rhickey: I do think Clojure, like Lisp/Haskell/Erlang, demands a certain intellectual curiosity, it's hard to make an instantly appreciable argument for its practicality

21:11 for a lot of people programming is just a job

21:19 Lau_of_DK: Im not sure. I think any Lisp offers a whole new dimension to the term, reuseable code, and thats pretty practical

21:20 rhickey: when I first started ranting about Lisp all my friends thought I was crazy

21:21 Lau_of_DK: Sure, but we're they saying that based on Lisp or your personality?

21:21 (joke - dont kill me)

21:22 rhickey: I wrote a new programming language, which proves I AM crazy

21:22 Lau_of_DK: hehe, you have it in writing

21:27 I'm wondering, what technique would you use to loop over the lines of a file using BufferedReader, collecting the lines when reaching null/nil ?

21:28 rhickey: (doc line-seq)

21:33 Lau_of_DK: (defn get-txt-file

21:33 [in]

21:33 (let [reader (new BufferedReader (new FileReader in))]

21:33 (with-open reader

21:33 (line-seq reader))))

21:33 This throws an exception: No matching method found: close

21:33 but reader has a .close method

21:34 Chouser: (with-open reader (new ...) (line-seq ...))

21:34 skip the let

21:35 this is one of the primary drawbacks of lisp syntax (or non-syntax) -- few hints to differentiate args. Clojure's vector and map syntax helps a bunch, but with-open doesn't use those.

21:36 Lau_of_DK: k

21:36 Chouser: In a python-like language, you might say with-open(reader=foo): body, making it obvious that with-open takes 3 different kinds of args.

21:37 of course then you lose macros, and that's just not worth it.

21:37 Lau_of_DK: Maybe Enclojure can help make that bit, a little easier

21:37 Ycros: in python I'd use the new with statement: "with something() as s:"

21:37 Lau_of_DK: But would you say this is correct Clojure

21:37 (defn get-txt-file

21:37 [in]

21:37 (let [reader (new BufferedReader (new FileReader in))]

21:37 (with-open reader

21:37 (line-seq reader))))

21:37 argh

21:37 2 sec

21:37 (defn get-txt-file

21:37 [in]

21:37 (with-open reader (new BufferedReader (new FileReader in))

21:37 (line-seq reader)))

21:38 Chouser: I do wonder if some of these vaguely let-like macros would benefit from using a vector like let does, even if they only ever take 2 items.

21:38 Lau_of_DK: does it work?

21:38 Lau_of_DK: No, it throws an IO exception

21:38 Chouser: Ycros: sure. and in clojure, you can write your own. ;-)

21:38 Lau_of_DK: And at the bottom it gives some scrambled output from the file

21:39 Chouser: (line-seq reader)))

21:39 oops, sorry.

21:40 Ycros: Chouser: aye

21:41 rhickey: Chouser: maybe so

21:43 Chouser: Lau_of_DK: This has bitten me a couple times.

21:43 Lau_of_DK: the problem is that line-seq is lazy, so with-open is closing your reader before you're done.

21:43 Lau_of_DK: Yea I imagined that was the problem

21:44 Quick solution: Is there a non-lazy reader?

21:44 Or can I force it to produce a string before returning? (preffered)

21:45 Chouser: you could wrap line-seq in doall

21:45 (doall (line-seq reader))

21:45 Lau_of_DK: ok. But I think you guys need to come up with a solution for the problem with (with-open). Its going to come back and bite you if you dont :)

21:45 Chouser: oh, a single string? (apply str (line-seq reader))

21:46 Lau_of_DK: Alright, thanks alot Chouser

21:46 Chouser: np

21:51 Ycros: wait, what was the problem with with-open?

21:51 ambiguity of arguments?

21:51 Lau_of_DK: That it closes before lazy-streams are evaluated

21:52 (unless you evaluate them straight off of course)

21:52 rhickey: Lau_of_DK: what else could it do?

21:53 Lau_of_DK: Im not sure what you be a clever way of solving it.

21:53 If it indeed needs to be "solved"

21:53 rhickey: the whole point of it is that it bounds the open scope, so you have to consume it inside

21:54 Lau_of_DK: Well... when you put it like that

21:54 :)

21:54 Anyway, its 03:19 AM here, so I gotta hit the sack. Sweet Clojure dreams to you guys when you get that far

21:57 rhickey: I've added support for : as a non-repeating, non-terminal constituent character in symbols

21:57 so now you can deal with XML namespaces

21:59 Chouser: non-repeating, eh? Just don't want to give us enough rope...

21:59 rhickey: do you need repeating?

21:59 Chouser: nope

21:59 rhickey: thought not :)

21:59 Chouser: not yet...

21:59 :-)

21:59 dudleyf: non-repeating?

21:59 rhickey: reserving :: as potential syntax

22:00 dudleyf: Ah

22:00 Ycros: so are people leaning towards emacs or towards other IDEs?

22:01 dudleyf: I've switched to emacs

22:01 Ycros: I'm using netbeans at the moment, mainly because I'm using netbeans for other stuff as well (ruby on rails stuff)

22:03 Chouser: I'm trying to get into enclojure, but I'm still far more comfortable with vim and a shell prompt. ...as usual.

22:04 Ycros: wasn't there a slime-like thing for vim somewhere?

22:13 Chouser: dunno.

Logging service provided by n01se.net