#clojure log - Jan 01 2009

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

0:29 Puzzler_: clojure

0:38 Chouser: indeed

0:43 hiredman: clojurebot: clojure?

0:43 clojurebot: clojure is a very attractive hammer with a nice heft to it

1:26 inertia-: what is the equivalent for clojure agents, in scheme?

2:26 durka: (set! *year* (inc 2008))

2:51 can clojure iterate over Enumerations?

2:51 * durka discovers enumeration-seq

4:13 Lau_of_DK: Top of the morning gents, and a happy new year

4:13 craigmarshall9: happy new year from England

4:16 Lau_of_DK: thanks :)

4:20 hoeck: happy new year from germany

4:20 craigmarshall9: Guten tag! (that's all I speak)

4:21 Lau_of_DK: I know a little: Achtung! hoeck ist mein liebling

4:21 auf berlin...

4:21 hoeck: haha :)

4:22 craigmarshall9: "Attention, hoeck is my darling in Berlin" ?!

4:23 Lau_of_DK: Close, from berlin

4:24 I really love it when Germens say "Achtung!", Ive experienced it in a swimming pool once on holiday, where a German woman wanted to claim some lanes and she swam around say "Achtung!" :)

4:33 Puzzler: happy new year

4:38 Lau_of_DK: you too

7:35 (defn x [] (.trim "bla bla ")) (defmacro y [] (.trim "bla bla ")), y will fail is .trim is not in the namespace from where I am calling, where x will succeed if its defined in a namespace that has .trim. Have can I have my macro remember where its coming from ?

8:50 Chouser: .trim is a Java method, so it's not "in" any namespace.

8:51 Lau_of_DK: .trim was just an example, it could have been anything

8:51 In the current example, its methods from java.sql

8:51 Mr. Chouser

8:51 (happy newyears)

8:51 Chouser: :-) Happy new year to you.

8:52 Lau_of_DK: Looking forward to your 30 lines or less fireworks simulation on your blog

8:52 :)

8:53 Chouser: Method names are resolved very differently from other names, which is why it matters.

9:07 Lau_of_DK: Chouser: You gotta fill me in tonight

10:25 knapr: is it possible to add Hindley-Milner type inference to Clojure?

10:34 RSchulz: knapr: Deep thought for the early hours of a new year! Anyway, I don't think so, since Clojure currently has no static type system within which a type inference could operate.

10:36 Chouser: RSchulz: is that true? The Clojure compiler knows the Java class types of much the code it works with.

10:36 ...and uses that info to produce non-reflective bytecode.

10:36 RSchulz: I knows only whether methods and fields named in Clojure code exist, right?

10:37 It still has to use reflection at run-time to pick an overloaded method, e.g.

10:37 knapr: but it could still parse a text-file and check the validity of the operations inside clojure right?

10:37 partial hindley-milner or something

10:37 RSchulz: Rich was talking a few days ago about possibly integrating another piece of software (whose name escapes me) that does type inference as a kind of orthogonal / adjuct type checker for Clojure programs.

10:38 knapr: where all java-methods are annotated as evil stuff

10:38 RSchulz: What sort of validity could it check? Or, more to the point, what sort of invalidity could it detect?

10:38 Chouser: I think he mentioned sequent notation, Qi-style.

10:38 RSchulz: Yes. That was it.

10:41 Lau_of_DK: Qi-style, sounds awful

10:41 Mr. Schulz, happy new years :)

10:42 kotarak: optional type checking would be nice.

10:43 RSchulz: Lau! Happy New Year to you and yours!

10:44 When you say "Qi=style sounds awful" do you mean you don't like the Qi concept, or that the words themselves are dysphonic to your ear?

10:44 kotarak: I think he left

10:46 RSchulz: "People come and go so quickly here!"

11:52 Chouser: I wonder if it'd be worth the effort to disallow non-keywords in the ns macro.

11:53 kotarak: you mean (ns :foo.bar (:use :clojure.conrib.def))?

11:55 RSchulz: Why?

12:20 Chouser: no, I mean disallow (ns foo.bar (import ...) (require ...))

12:21 RSchulz: I still don't see why you'd want to do that?

12:21 Chouser: because it works (sorta) but isn't supported. It's an easy mistake to make and it mostly works ok.

13:17 kotarak: (doc read-string)

13:17 clojurebot: Reads one object from the string s; arglists ([s])

13:44 Lau_of_DK: Good evenings gents

14:28 durka: now why would there by recursive symlinks in my classpath

14:36 RSchulz: durka: Are you referring to /etc/alternatives?

14:36 Or actual cycles?

14:38 durka: cycles

14:39 RSchulz: Did you set them up yourself? Or did some installer or some other software create them?

14:39 I take it you're using Linux?

14:39 I'm pretty sure the Linux kernel will detect cycles and given an error when attempting to resolve them.

14:40 lisppaste8: durka pasted "classpath" at http://paste.lisp.org/display/72911

14:40 durka: i'm not sure who set those up

14:40 because i'm not sure where i installed java from

14:41 but i would think making a symlink to the parent directory is a general bad idea

14:41 esp. when you expect something like a classloader to be walking this directory

14:42 RSchulz: I take it the symlinks are to directories, not indiviudal files, yes?

14:43 Anyway, just clean them up. I doubt anything will break if you get rid of cyclic symlinks.

14:43 durka: i hope not

14:45 RSchulz: Actually, I guess that's kind of nonsensical. The cyclic links are not to anything real, just other links...

14:45 durka: well, it's not a cyclic link per se

14:45 it's a link to a directory

14:46 in that directory are a few directories, one of which includes the link

14:46 RSchulz: Oh. Well, there's nothing wrong with that. It's very common, actually.

14:46 durka: :( but it confuses my simple-minded recursive directory walker

14:46 RSchulz: Why not use the "find" command?

14:48 pd: I've a struct 'board' that represents a sudoku grid, and I've written a board-to-str function to build a string representation

14:48 But I'd prefer being able to simply do (str some-board); is this feasible somehow?

14:49 durka: RSchulz: you mean the unix find?

14:49 or is there a java/clj native one

14:49 RSchulz: Yes.

14:49 It's very fancy and completely symlink-aware, as are most Linux commands.

14:49 durka: i'd rather this program be portable to windows, though

14:50 RSchulz: I guess I don't understand what you're trying to do. Can't java.io.File distinguish symbolic links?

14:52 I guess not.

14:52 But I think the getCanonical... methods will resolve symbolic links, if that helps.

14:53 durka: basically i'm trying to walk the classpath looking for things

14:53 RSchulz: Just run them through java.io.File#getCanonicalPath first.

14:53 durka: but that symlink is putting the code into an infinite recursion

14:53 so don't follow symlinks?

14:54 RSchulz: No, so you don't _see_ the symlinks.

14:54 You might need to also verify isReadable() first to filterout dangling symlinks.

14:55 durka: oh, i see

14:55 RSchulz: If the link structures are cyclic, the kernel will tell you that. Otherwise, sliding through the symlinks should work.

14:57 durka: right, ok

14:58 RSchulz: Also, I think Stuart's Programming In Clojure book has some sample file system traversal code you might want to look at as an example.

15:00 durka: i should buy that book

15:01 RSchulz: I'd certainly recommend it.

15:01 You can choose the PDF-only, if you rpefer, though I like books I can hold.

15:02 But if you get both or just the PDF, you can get the current betas as he writes new chapters.

15:02 Otherwise, naturally, you have to wait for the final press edition to see anything at all.

15:04 durka: right

15:16 sooth: Stupid question: How do I add the jars in /usr/share/java to the classpath in slime? I've tried add the directory to swank-clojure-extra-classpaths but it doesn't seem to work. Do I need to add the jars individually/

15:16 ?

15:21 pd: sooth: yes, I think so. Adding a directory to the java classpath doesn't mean it searches for jars within the directory (AFAIK).

15:22 Chousuke: there is some support for wildcards though.

15:22 sooth: pd: java man page says it can be a directory, I must be doing something wrong.

15:23 pd: sooth: given a directory, it searches for .class files within it

15:23 sooth: (sun java 6)

15:23 Chousuke: sooth: that means the *directory* not the .jar, is added to the classpath.

15:23 sooth: pd: Ah, okay. Thanks

15:23 Chousuke: Thanks, I will use wildcards.

15:24 Chousuke: I can't remember if it was * or something else, though.

15:24 sooth: Chousuke: It's *

15:24 which adds all the .jar or .JAR, according to the man page

15:29 dreish: ,(#())

15:30 clojurebot: clojure.lang.PersistentList$EmptyList@85b670

15:30 cmiles74: Is there a function that will return true if a var has been set?

15:31 Chouser: cmiles74: defined, bound, or non-nil?

15:31 :-)

15:32 I mean, you want to know if (def foo) has happened or not?

15:32 or you know it has but you want to know if it has been re-def'ed to have a value?

15:32 cmiles74: I think I am testing to see if a var has been bound...

15:33 I'm imagining that someone might already have a logger instance (like a Log4J instance) in a var called *logger*...

15:33 If they don't, then I want to create a logger.

15:34 The nomenclature around this is always a problem for me. I think what I am askings is, "Is there a var called *logger* with a non-nil value?"

15:37 Chouser: cmiles74: there's a defonce that either does what you want or provides example code that might be useful.

15:37 cmiles74: Okay, thank you Chouser. :) I will look at that right now.

15:38 rhickey: Clojure mailing list activity: http://chart.apis.google.com/chart?chs=500x200&cht=bvs&chtt=Clojure%20Mailing%20List%20Activity&chd=s:DBHGIROJQOSOjv9&chxl=0:|oct|nov|dec|jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec|&chxt=x

15:39 drewr: Yep, that pretty much tracks with my ability to keep up with it.

15:39 rhickey: from: http://hughw.blogspot.com/2009/01/clojure-uptick.html

15:39 Chouser: drewr: heh, no kidding.

15:40 rhickey: drewr: you have an ever increasing ability to keep up with it?

15:40 :)

15:40 Lau_of_DK: Seriously, you guys can keep up?

15:41 drewr: OK, "inversely tracks." :-)

15:53 rhickey: svn 1193 - Added uniform metadata handling for atoms/refs/agents/vars/namespaces

15:55 Chouser: wow, giant diff.

15:55 rhickey: refactoring

15:56 * Chouser nods

15:56 rhickey: so now all references and namespaces can have metadata

15:57 next up is uniform watches for references

15:57 will need to move from synchronous model to watch is agent+action

15:58 change will trigger (send-off agt action reference)

15:58 Chouser: ah, I see atom moved to .java

15:59 rhickey: yeah, I think I might want to be able to use it earlier in the bootstrap, difficult when a proxy

15:59 Chouser: excellent news re: watches

16:00 RSchulz: What's the state of the abstract stream processing you worked on a while back. I see the classes in the diagram, but is there new API to go with it?

16:01 rhickey: RSchulz: it's substantially done, but I'm quite reluctant to deploy it. There is so much potential for misuse, I don't want to compromise Clojure. So, still working on LFE alternatives

16:01 RSchulz: I know you already answered this one, but... LFE?

16:02 Chouser: left fold enumerator

16:02 RSchulz: Right. Thanks. Again.

16:02 rhickey: RSchulz: http://clojure-log.n01se.net/date/2008-11-06.html#20:41

16:02 * Chouser attaches metadata to (find-ns 'user), just for fun.

16:03 Chouser: whee

16:03 rhickey: what's nice is that the metadata updating is MT safe

16:05 Chouser: the alter* and upate* functions are becoming quite natural to me to use.

16:06 rhickey: It's definitely a model, but not one you see often

16:06 Chouser: oh, I guess it's just update-in. Should that not be named alter-in?

16:06 rhickey: I like it, plus something about it being relatively universal feels right

16:06 Lau_of_DK: What was the misuse concerns regarding ASP ?

16:07 rhickey: Chouser: all alters are destructive, update isn't

16:07 Chouser: Lau_of_DK: ASP? LFE?

16:07 rhickey: ah!

16:07 Lau_of_DK: Chouser: The abstract stream processing which was almost done, but not yet deployed

16:07 Chouser: Lau_of_DK: oh, ok.

16:08 rhickey: Lau_of_DK: streams are inherently stateful. It would take extraordinary discipline to avoid having them pollute a design

16:09 Lau_of_DK: oh I see

16:09 rhickey: Most of Clojure removes the need for extraordinary discipline

16:09 At least that's the goal

16:09 Lau_of_DK: Discipline is good, just not very common :)

16:10 But yea, its nice when everything defaults to immutability

16:10 (1 year ago I would have slapped somebody for saying what I just said)

16:11 Chouser: 1 year ago I wouldn't have understood what you meant.

16:16 I can't create an object with a custom toString without gen-interface or gen-class, can I?

16:20 rhickey: (str (proxy [Object] [] (toString [] "foo")))

16:23 Chouser: oh! I guess I should have specified map rather than object, which wouldn't survive any assoc or dissoc. ...but in this case I don't need to support either.

16:23 ...so it's perfect, thanks!

16:25 rhickey: sure

16:26 Lau_of_DK: Guys, is it possible/sensible, to build an object-model around concept of immutability, so as to include some type of OOP in Clojure?

16:28 kotarak: In how far is this necessary? We have Java underneath...

16:28 Lau_of_DK: Maybe it's just my old habits popping up, but occasionally Im sitting with a design where it would just seem obvious to define a few objects.

16:29 Chouser: Lau_of_DK: in a context where maps + fns (+ perhaps multimethods) is insufficient?

16:30 Lau_of_DK: Not insufficient, just not optimal. Do me the current usage of multimetods can seem a bit messy

16:30 Chouser: it seems to me a good way to support string (or at least print) overloading in clojure proper would be for print-method to check for metadata like :custom-print, and call that if present.

16:31 kotarak: I'm still struggling on what to dispatch.

16:31 So I end up with a :type tag in the map.

16:31 Is there some better way?

16:31 Chouser: that'd allow you to make struct-maps that by default print in some special way.

16:32 kotarak: I'm no expert, but I think if they :type has a natural value for all the types you're working with, you're probably doing it right.

16:33 rhickey: there's nothing wrong with a type tag. What's nice is that when you need another characterization, you're not limited to a hardwired single-type-per-object system

16:33 Chouser: kotarak: as a (weak) counter-example, consider vehicles. What is the vehicle's :type? is it car/truck/suv? or is it GM/Ford/Toyota?

16:35 rhickey: watch/watcher/observer/listener/other?

16:35 Chouser: kotarak: so in that case, you'd have :make, :model, maybe :configuration (or some actually good name for car/truck/suv), :drive-wheels (2, 4, etc.) ...and for a given multimethod dispatch on the relevent one(s)

16:36 rhickey: for agent registered to be informed of a reference change

16:36 kotarak: Chouser: the :type is Vehicle. Is has a manufacturer (GM/Ford/Toyota). And has a list of other properties, like car, truck, seven-seater... In my opinion (at the moment, that may change by the hour), that sticky notes put on a thing is a better way to categorise stuff than a tree.

16:37 Chouser: rhickey: only one such agent per reference?

16:38 kotarak: Chouser: yes. that's the nice thing about multimethods: dispatch on whatever you need.

16:38 rhickey: no, either a map of agent->action or set of [agent action]

16:38 kotarak: Maybe I just have a bad feeling, without reason. Just have to get used to it.

16:38 rhickey: probably the former

16:39 Chouser: kotarak: that's fine too, but in classic OOP, I'd expect Vehicle to be a class, and perhaps Truck to inherit from it. ..but if you have functionality attached to manufacturer, things get complicated quickly.

16:39 rhickey: so no agent can be registered more than once

16:40 Chouser: rhickey: no more than once on the same reference. nice. though perhaps on more than one reference, perhaps with different actions.

16:40 rhickey: Chouser: oh yes, definitely one agent can watch many refs

16:41 Chouser: I think I like "watcher". The brevity of "watch" is nice, but it seems a bit innaccurate.

16:42 "listener" is even longer with no obvious benefit, plus is already used in Java-land.

16:42 rhickey: right, Java use invites confusion

16:46 Chouser: reactor? feeler?

16:50 responder?

16:51 arbscht_: potential request/response confusion

16:52 Chouser: yeah, responder has an innappropriate suggestion of the response going back to the thing that triggered it.

16:52 oh, "trigger"

16:55 rhickey: trigger is usually the cause, maybe reactor

16:56 Chouser: yeah, you might say the thing "is triggered" to be to say it "is a trigger" isn't quite right. Though RDBs seem to use it that way.

16:57 rhickey: reagent has a chemistry connotation that doesn't quite fit

16:57 arbscht_: sensor?

16:58 rhickey: reaction is kind of correct, as it is more than just an agent but agent+action

17:00 Chouser: sensor's not bad at all.

17:01 rhickey: sensor makes me thing of something that detects change - here the change is detected by the reference itself, this is just an interested party

17:02 Chouser: reaction suggests to me one particular triggering of the thing.

17:03 after the agent has completed the action, that reaction is done. That agent and action might react again later.

17:04 RSchulz: "Custodian" (Latin for watcher, yes?)

17:04 kotarak: beholder?

17:04 RSchulz: Or maybe "voyeur"...

17:05 arbscht_: another overused term: monitor

17:05 kotarak: hook?, but "hooker" .....

17:06 drewr: liaison

17:07 Chouser: follower

17:07 kotarak: observer

17:07 Chouser: alarm

17:07 arbscht_: spy

17:08 rhickey: reactor best so far

17:08 Chouser: special-agent

17:09 drewr: :-)

17:12 arbscht_: reactor will take some getting used to. my first thought is of nuclear reactors and the like

17:13 Chouser: watchdog

17:15 subscriber

17:16 kotarak: watchdog is something different. It checks that a given process still runs and takes appropriate measures otherwise

17:16 arbscht_: subscriber resonates

17:16 rhickey: subscriber overlaps with message queues

17:18 Chouser: these will be run via 'send' always, not 'send-off', I assume?

17:19 rhickey: send-off

17:19 Chouser: oh

17:22 I guess if I don't want to thrash the CPU too much I can just 'send' from inside my reactor agent.

17:23 rhickey: Chouser: all sends, even send-offs, to the same agent serialize

17:23 so topology can constrain things too

17:30 Chouser: I don't know what you mean by "agent serialize" or "topology" here, but I don't need to right now.

17:33 rhickey: Chouser: if you only have 4 watchers, you'll never use more than 4 threads, even with send-off

17:33 sooth: Does NO_SOURCE_FILE have any special significance in a ClassNotFoundException?

17:37 Chouser: rhickey: if the agents acting as watches themselves have watchers, couldn't the number of threads baloon?

17:39 rhickey: Chouser: yes, but that's where topology comes into play - you'll tend to have fewer watchers than watchees

17:40 Chouser: ok. it's not worth associating a send vs. send-off preference with each action?

17:41 rhickey: Chouser: that's possible, people seem to be pretty confused about the difference

17:42 I've also been wondering, as I consider a la carte pools, whether an agent will ever need both send and send-off - that could become a property of its pool

17:43 drewr: sooth: Did you eval from the REPL?

17:44 sooth: drewr: slime-eval-buffer

17:46 drewr: It for a Java package. I added "/usr/share/java/*" (Java library path) to swank-clojure-extra-classpaths.

17:47 Chouser: So far I've hardly ever used more than one action per agent, so it's a bit hard to say. But it seems like blocking vs. non-blocking has more to do with the action than the agent.

17:48 rhickey: Chouser: yes it does, and that's why it is the way it is, but in practice I think agents are either computational or I/O oriented.

17:49 as we get more cores, it might be useful for computational agents to work from pools restricted to a few cores

17:50 and everything else use variable queues

17:54 drewr: sooth: slime-eval-buffer is just going to send your code via swank to the REPL.

17:54 sooth: drewr: Okay so I guess my answer is "yes'

17:57 I'm trying to run the third example at http://paste.lisp.org/display/70171 and getting the error for tagsoup (whose jar is installed in /usr/share/java/)

18:06 Raynes: Hey guys, check this out if you haven't already.

18:06 http://lambda-the-ultimate.org/node/3144

18:07 Lau_of_DK: Cool

18:07 Raynes: A good few people repping clojure :>

18:08 Lau_of_DK: Yea

18:08 But one guy says "C++" *giggle*

18:10 rzezeski: Amazing how many people claim Java is about to "die." So much hate.

18:11 Raynes: Java will rule the buisness world for the next 10 years at least imo.

18:11 Then languages like Clojure and Scala will begin to take over.

18:11 rzezeski: Wouldn't surprise me (java ruling for 10 years that is). I'm not saying I love Java, but people that claim it's "dead" confuse me.

18:12 I guess they work in .Net shops :)

18:14 Raynes: I'd like to see Haskell gain popularity.

18:15 rzezeski: I'd say it already has over the last couple of years. Especially now that RWH is out.

18:16 Isn't F# heavily influenced by Haskell as well? It's type system at least?

18:16 Raynes: No.

18:16 F# is OCaml for the .NET pretty much.

18:16 F# is a mess.

18:17 rzezeski: Oh, ok. Gotcha. I thought I remember Neil Mitchell comparing Haskell with F# recently

18:17 He seemed to give it a pretty decent review, but most of his commenters kinda ragged him for it if I remember correctly.

18:18 Raynes: Almost any imperative programmer sees Haskells purity as damaging, they just don't understand it.

18:19 But the 577 people in #haskell would surely beg to differ :D

18:23 rzezeski: Don't know if you mean Neil, but I'd say he's Haskell to the bone. I like Haskell's purity, but anytime I had to do IO with Haskell I failed miserably. My programs would turn into big long functions wrapped in the IO monad. So while I love the purity, I didn't apply it too well. I also didn't spend nearly enough time with it either. I think Haskell rocks, but I think I'm starting to like LIsp/Clojure more.

18:24 Raynes: When I think Clojure I think Revenge Of The LISP.

18:25 rzezeski: The first thing that really made me like Lisp was watching some of the SICP lectures and loving how simple and uniform Lisp syntax is. I didn't have to read a 500 page book like I did for Java to learn all the syntactical rules and pitfalls. It amazed me.

19:38 chrisn: stupid question disclaimer...

19:38 First forces evaluation of head, correct?

19:39 rhickey: chrisn: yes

19:40 chrisn: cool. Laziness combined with threads and opengl = bus error and end of repl session...

20:45 replaca: Is the idiomatic way to do (contains? aseq val) on a sequence (some #( = val %) aseq)? Or is there a more precise way?

20:46 gnuvince: I've seen some people using (some #{val} aseq)

20:46 replaca: oh, that might be nice.

20:47 actually I'm doing it between a String and a seq (to trim whitespace)

20:47 so I might just turn aseq into a set and use that

20:47 I always forget about using maps and sets as func

22:00 rhickey: svn 1194 - Added watcher support for agents/atoms/refs/vars

22:15 chrisn: Rich, you language is fun as hell.

22:16 s/you/your

22:17 rhickey: chrisn: thanks, glad you're having fun!

22:23 Raynes: Slime wont compile files for me :|

22:25 As a matter of fact, clojure wont even compile files for me.

22:55 falcon0: is there a way to be notified if a new binding is created in the clojure environment?

23:06 Chouser: falcon0: you can now be notified when a particular var is changed

23:08 rhickey: Chouser: yes, var watchers are triggered only by root binding changes, not thread-local set!s

23:08 Chouser: ah, cool. that's the only one I tested.

23:09 the docs don't mention the extra arg to the watcher action

23:10 and add-watcher docs have a type "afer" instead of "after"

23:12 rhickey: they do mention additional arg, will fix afer

23:12 Chouser: oh. indeed. sorry. :-)

23:12 rhickey: is it unclear?

23:12 Chouser: no, I'm just distracted.

23:14 falcon0: Chouser or rhickey, how can I be notified when I do something like (def xyz 123) ? (this is for a development environment I'd like to write)

23:14 I mean, when I add a binding (def or defn) on the REPL, how can I be notified?

23:15 rhickey: falcon0: no way right now

23:15 docs fixed, thanks

23:16 falcon0: I guess I misunderstood Chouser's comment above...so if I want to watch a specfic variable, I can listen to its changes...but not the global environment as a whole?

23:17 rhickey: falcon0: right

23:17 falcon0: i see...you said "no way right now" ... does that mean you are adding this functionality?

23:18 rhickey: falcon0: not planned

23:19 falcon0: ok...i assumed that global variables would be inside a clojure data structure accessed through agents or refs...doesn't that mean I could listen to that global agent/ref

23:19 and get the info I need?

23:20 Chouser: refs are interned in namespace objects, which don't have watchers

23:20 rhickey: falcon0: no, there is no global data structure through which the environment is changed - each var and namespace are independent

23:21 namespaces could have watchers theoretically, but a redef wouldn't go through the namespace

23:22 falcon0: rhickey: i see, so I know you added watchers to agents, will they be added to other reference variables as well?

23:22 Chouser: you'd have to use the namespace watcher to register the var watcher.

23:22 rhickey: falcon0: watchers now supported for agents/var/atoms/refs

23:24 falcon0: rhickey: cool, i think CELLs or FRP type implementations work work better atomicly, rather than in an async manner

23:24 rhickey: falcon0: well, the notifications are async - agent actions

23:25 falcon0: so if I am watching a ref...will i get notified of a change inside the transaction or after the transaction has 'comitted'?

23:26 rhickey: falcon0: after

Logging service provided by n01se.net