0:09 spacebat_: so, I'd like to ask what environments people use, plain REPL, netbeans+enlojure, emacs+ilisp, emacs+slime, or something else?
0:11 hi craigoz, whereabouts in .au? I'm in adelaide
4:21 fanda_: hello!
4:22 just trying IRC
5:03 spacebat_: hi fanda_
5:03 fanda_: hello spacebat_
5:04 spacebat_: new to clojure?
5:04 I am
5:04 fanda_: yes, me too
5:04 just starting with it
5:04 i used newLISP before
5:04 but I know little about Java
5:05 spacebat_: knowing very little lisp and no functional programming, its a steep curve
5:05 but I can see the reasons to keep on with it
5:05 I used to work for a java shop, but that was years ago
5:06 my day job is perl
5:06 fanda_: yes, i love functional programming and LISP especially
5:06 spacebat_: newLISP, I haven't heard of that one
5:06 fanda_: i used it for explorative programming
5:06 it is a small dialect of Scheme (LISP)
5:06 spacebat_: open or proprietary?
5:06 I tend to think that common lisp is a bit on the hulking side
5:07 fanda_: yes, common lips is too big
5:07 spacebat_: but it does seem to be the most widely implemented standard
5:07 fanda_: clojure is more symetrical and more well thought in my eyes
5:07 spacebat_: I've liked that common lisp has been easy to start with
5:07 because it lets me code imperatively
5:08 fanda_: yes, exactly
5:08 spacebat_: but that doesn't fly here
5:08 fanda_: newlisp is similar
5:08 (setq x 5) or (set! x 5) ;-)
5:08 clojure is more pure
5:08 spacebat_: I saw an excellent post on the newsgroup today that spelled it out
5:09 if you make a new value, either give it a new variable, or pass it directly into a function
5:10 fanda_: yes, I also have problems with immutability
5:10 i am thinking about creating some "cook book"
5:10 spacebat_: I've had similar ideas
5:10 fanda_: how to mutate or "looks-like-mutate" ;-)
5:11 spacebat_: gradually accumulating code snippets in a library, a modest general purpose collection at the moment
5:11 fanda_: i have been reading some code from contributions
5:11 now i am trying to create my first useful something :-)
5:12 spacebat_: I haven't even looked into contrib yet
5:13 fanda_: here
5:13 and here
5:13 spacebat_: I see yes I checked that out of svn but its just sitting on disk so far
5:14 looking at complete programs has been a bit confusing, trying to get the gist from gradually larger chunks of code
5:15 clojure just might be my gateway back to java
5:15 using an IDE to get past the static verbosity of java repulses me these days
5:16 I've been ruined and made anew by dynamic languages
5:17 rhickey was saying that there is a guy in sun who really gets lisp
5:17 and wants to put tail recursion and more functional support in the JVM
5:19 ok newlisp, I have seen that page before, like a year ago
5:19 I've been learning lisp about 3 weeks now
5:20 does it have threads?
5:21 fanda_: what do you mean - if newlisp has threads? no, it doesn't
5:21 spacebat_: ok
5:21 yes that's what I meant sorry
5:21 fanda_: newlisp is written in C
5:21 runs on many platforms
5:21 spacebat_: what brings you from there to here?
5:21 yes portable threading isn't trivial
5:22 fanda_: but it has everything on its own - runtime - garbage collector, etc.
5:22 libraries for one
5:22 you can import only C libraries or write your own lisp libraries - so much time spent there
5:22 kotarak: did anyone encounter issues with agents and clojure.lang.Script?
5:22 fanda_: i have no idea about this one
5:23 spacebat_: me neither sorry
5:23 fanda_: don't be sorry
5:23 spacebat_: heh
5:23 fanda_: :)
5:23 if you have any lisp questions, i might answer
5:23 map, apply, filter...
5:23 lambda (meaning fn) functions
5:24 spacebat_: is there something you don't like about newlisp?
5:24 not asking you to trash it or anything
5:24 kotarak: No. It's more about using agents for concurrency. In the REPL I see the agent output, calling the script "hangs". I'm not sure where or why.
5:24 fanda_: hi kotarak :-)
5:25 kotarak: hello fanda_
5:25 spacebat_: sounds like something a tad advanced
5:25 kotarak: ok. never mind
5:25 spacebat_: maybe the REPL is doing some sync that's needed and not in Script
5:26 fanda_: don't know why he left...
5:26 spacebat_: hunting rather than gathering
5:26 fanda_: hm
5:27 spacebat_: newlisp looks like it has potential
5:27 fanda_: yes, its cool in its own terms
5:27 spacebat_: if its fast, then with the right libs for coordinating processes it could be a real workhorse
5:28 fanda_: here are my creations:
5:28 just click on the left for code, code-tk, ...
5:28 spacebat_: does it generate binaries?
5:28 fanda_: no, it does not
5:28 its only interpreted
5:28 spacebat_: what tipped lisp over the interest threshold recently was seeing Language::Lisp::ECL on the cpan
5:28 fanda_: but you can make wrappers - wrap newlisp.exe with your script
5:28 spacebat_: ok
5:29 ECL uses gcc as a backend and can compile standalone exes
5:30 fanda_: can be interesting
5:30 spacebat_: a small naive fibonacci program compiled to 24k on disk
5:30 its common lisp, so I guess it leaves out all the stuff that isn't being called
5:30 fanda_: ok, that's interesting!
5:30 spacebat_: it also makes it easy to embed, all common lisp functions are callable from C
5:31 the fib program ran about 10 times slower than a C program with the same gcc, for fib(39)
5:32 but it was still about 6 times faster than the fastest interpreter I tried, which was python
5:32 fanda_: quite interesting
5:33 spacebat_: time to give my boy a bath
5:33 nice chatting fanda_
5:34 fanda_: wait
5:34 spacebat_: yupo
5:34 fanda_: save this link
5:34 spacebat_: will do
5:34 fanda_: comparison CL - Clojure ;-)
5:34 might use it
5:34 spacebat_: thanks, bye
5:34 fanda_: nice chatting!
5:40 kotarak: sorry, got disconnected. maybe the output of the agent goes somewhere else in the Script compared to the REPL.
6:22 spacebat_: possibly, you said it hangs though
6:22 whereas it returns in the REPL?
8:31 Chouser: kotarak: you might just try adding (flush) after your print or prn
8:33 kotarak: Chouser: no, doesn't help.... Everything worked before, until a packed the output into an agent (since I have to some sync here). Then it stopped working. In the Script. In REPL it still works.
8:34 rhickey: kotarak: your script may be ending before your agent is done?
8:36 kotarak: huh? It can? Ok.... Hmmm... I (await) the agent, but let me add some sleep there.
8:37 rhickey: if you await in the same thread you sent, then it's done. Who flushes - - the agent or main?
8:37 kotarak: the agent
8:39 also tried a (flush) in the main thread, didn't help
8:40 rhickey: can you paste a small case?
8:41 kotarak: I'll try to strip it done. Just noticed, that the hitting ctrl-c gives me the output. Maybe a have to issue an explicit exit?
8:44 Ahh. Got the problem!!! When using agents, the script doesn't terminate, when reaching the end. You have to explicit call a (. java.lang.System (exit 0)).
8:44 rhickey: heh, I used to do that for you, but GUI app devs complained...
8:46 kotarak: rhickey: well, I'm mostly a non-GUI guy, so I expect a script to exit, when it is end is reached. But that also comes from things like C or sh. There you also have a non-returning function for GUIs. So maybe I just have a differnt point of view.
8:47 rhickey: btw. good job with clojure. It brought me back to the lispy side of life. :)
8:47 rhickey: thanks, glad you worked it out
9:11 Chouser: calls to the "rest" part of a lazy-cons are synchronized, but I suppose I still need to wrap them in sync if I want to use set! on a ref, right?
9:13 rhickey: you mean your rest expression manipulates a ref?
9:13 Chouser: right
9:13 rhickey: Clojure will force you to be in a transaction, else throws
9:14 Chouser: well, reads a ref, but yeah. Ok, that's what I thought.
9:14 rhickey: I though you said set
9:15 Chouser: I did! I'm sorry, I mis-typed.
9:15 actually, I mis-thought.
9:16 sorry, still sketching this out in my head. the rest expr will only need to read the ref (and perhaps block on something). so no sync there! cool.
9:16 rhickey: You can do non-transactional reads of refs
9:17 as long as you don't require a relationship between that read and another
9:18 Chouser: I don't think so. I'm going to try to build a vector in a background thread, while providing a lazy-seq as access to it in the main thread.
9:20 rhickey: Don't ignore things like java.util.concurrent.ArrayBlockingQueue
9:25 Chouser: hard not to ignore things I've never heard of
9:25 * Chouser reads up
9:26 rhickey: Clojure doesn't duplicate the workflow tools of java.util.concurrent because they are really good
9:27 queues/barriers/latches/exchangers etc
9:29 meredydd: rhickey: Ahh...so, that's really the answer to my question a few days ago
9:29 rhickey: meredydd: which question?
9:30 meredydd: about thread pools in Clojure...but java.util.concurrent does one, so Clojure doesn't have its own
9:30 kotarak: that's my main problem with clojure: when you have to fallback to some java stuff, I pretty lost.... (I have no clue about java whatsoever)
9:30 meredydd: (so you just have to do the magic proxy fiddle to turn a (fn) into a Runnable)
9:30 rhickey: actually Clojure does abstract thread pools with agents
9:30 fns are Runnable
9:30 and Callable
9:31 meredydd: They are now? Oh, great!
9:31 (Must have been looking at an old discussion...could have sworn I'd seen you saying that there was a good behind-the-scenes reason (fn)s weren't Runnable)
9:32 rhickey: there is some casting required now to disambiguate for the executor methods which are overloaded on both Callable and Runnable
9:33 that hassle was the only reason, but the tradeoff is worth it since half the java library uses one, and half the other
9:33 meredydd: Ah, excellent.
9:34 Thank-you, then.
9:34 And, by the way, did you do any more thinking about the relational algebra stuff in set.clj?
9:34 Because I've been thinking a little about that
9:35 rhickey: no, what are your thoughts?
9:35 meredydd: and how, of course, the nil-for-empty convention is fine, provided one uses seqs rather than sets
9:36 rhickey: you mean seqs of maps as rels?
9:36 meredydd: yeah
9:36 rhickey: but won't they have to keep being made into sets anyway?
9:36 meredydd: Just thinking that, if you were willing to forgo the mathematical warm-and-fuzzies of exact correspondence to the un-augmented relational algebra
9:36 Well, for what purpose?
9:36 rhickey: efficiency
9:37 meredydd: Of which operations? (Sorry, haven't poked around enough in set.clj to see how you do this stuff)
9:37 Joins, I suppose.
9:37 rhickey: right
9:37 meredydd: Ah, bugger. The man has a point.
9:37 Damn it - it's just that I was thinking
9:37 rhickey: also I like the rel is a set of maps rule, i.e. no dupes
9:38 meredydd: yep. As I say, nice mathematical warm-and-fuzzies with the exact correspondence to the RA
9:38 rhickey: with the twist of a non-fixed set of columns
9:39 meredydd: yeah, well...it's that, or a set of vectors, which wouldn't be as nice to work with.
9:39 rhickey: that's the special sauce of Clojure rels - non rectangular/sparse
9:39 meredydd: indeed.
9:40 Anyway - I was just musing that if you were to work with seqs, you could create a nice hack to use a proper SQL back-end for these things
9:40 and, because the seqs are lazy, you could have ops like joins, pi, sigma, etc fold themselves into the SQL statement
9:40 rhickey: seq->set once on load seem not too bad
9:41 meredydd: which is only actually executed when (first) is actually called on the seq
9:41 which would, neatly, allow you to keep all the relational operations Clojure-idiomatic.
9:42 (at the cost of some "Is it a bird? Is it a plane? Is it a seq, or an SQL wrapper?" hackery in the back-end.)
9:44 kotarak: Hmmm... Is there something in using agents, which turns off flushing? Suddenly I have to add (flush)es all over the place.
9:44 Or is java.lang.System.exit discarding unflushed stuff?
9:45 meredydd: kotarak: I think java.lang.System.exit is just killing the VM before the agents get a chance to run what you've sent them
9:45 rhickey: If you have multiple thread writing to the same stream you're likely to get a mess at some point. Maybe confine your I/O to a single place and have the agents just create the to-be-output values?
9:47 kotarak: I have one agent, which does the output stuff. So this is in sync. It's also (await)ed by the main thread. So there should be no problem here. I think exit just kills the VM, with flushing. Give me a second.
9:48 Yep. It's java.lang.System.exit. Is there some way of a sane shutdown? (Ie. doing things like flushing output.)
9:48 rhickey: await/flush/exit doesn't work?
9:49 kotarak: it does.
9:49 The flush is a bit anoying
9:49 But maybe this is again my different background. Just have to get used to it.
9:50 rhickey: there have been requests that the pr* fns flush
9:52 kotarak: I'm used to "newlines flush" and also exit() flushes. So flush is somehow the default for me. Now java.lang.System.exit does not flush. *poof* I have problem. But that's simply the wrong default on my side.
12:19 Chouser: tomhickey_: on clojure.org's left-hand menu, the clickable area for each link extends the full width of the menu. Top notch!
15:40 abrooks_: Chouser: Good observation regarding tomhickey_ 's good UI. Nicely done tomhickey_!
16:20 scgilardi: pjb3: I liked the picture of Rich you posted the other day captioned "State: You're doing it Wrong"
16:26 I have a thought about the flushing issue: it's often a good thing to flush on newline, but sometimes the inefficiency matters. How about a var *flush-on-newline* whose global binding is to "true" which is used to control whether or not some subset of the "pr*" functions flush on newline (or flush with each call).
16:28 I also like the idea I saw for "dbg*" functions that auto-flush as debugging is often a case where flushing matters
16:46 rhickey: scgilardi: *flush-on-newline* whose global binding is to "true" works for me
16:51 scgilardi: cool, thanks.
17:39 rhickey: user=> *flush-on-newline*
18:17 Chouser: hmph. can't properly store nulls in an ArrayBlockingQueue
18:18 rhickey: aargh
18:31 Chouser: but false works fine, so using that as an end sentinel, this does what I want:
18:31 (for [e (repeatedly #(.take q)) :while e] e)
19:40 rhickey: gotta love repeatedly