2008-09-16
| 08:08 | jamii_ | Can clojure arithmetic be overloaded eg (+ (QPoint. 0 0) (QPoint. 10 10)) |
| 08:08 | rhickey | jamii_: no |
| 08:14 | jamii_ | Thats annoying. Is this just something noone has got around to or is intentionally like that? |
| 08:14 | rhickey | slow math is annoying too |
| 06:06 | Chouser | rhickey: congrats on the release. |
| 06:07 | Chouser | not 1.0 yet? :-) |
| 06:12 | rhickey | Chouser: thanks |
| 06:13 | rhickey | still on the fence about what 1.0 means |
| 12:57 | abrooks | rhickey: I poked around a bit but wasn't able to see in the logs or your recent post what Subversion revision the 20080916 release was based on. |
| 12:57 | cemerick | rhickey: Congrats. :-) With which svn rev does the new release correspond? |
| 12:57 | cemerick | wow, spooky |
| 12:59 | rhickey | release is based on the latest - rev 1029 |
| 13:00 | Chouser | the blog post lists the checkin comments |
| 13:00 | rhickey | I should put the rev somewhere... |
| 13:05 | abrooks | Chouser: Ah, that should have clued me in. |
| 13:06 | abrooks | rhickey: BTW, I meant to express thanks and congratulations about the release. |
| 13:07 | rhickey | abrooks: you're welcome! |
| 14:58 | jgracin | this "no-tco" in jvm problem... is there a solution for this in JVM at all? I mean, is it just a matter of taking time to do it, or are there fundamental issues with adding that to JVM? |
| 15:01 | rhickey | jgracin: I think there are some issues having to do with security, but deemed possible: http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm |
| 15:13 | jgracin | rhickey: thanks for the link, interesting read. The only problem I see in the article is disallowing calls to java.lang.Class.* and others. |
| 15:14 | jgracin | how does one do that? |
| 15:15 | Chouser | Ah! A function's 0th local is always for itself! |
| 15:16 | rhickey | jgracin: it doesn't disallow all calls to those, just doesn't TCO them, which you won't care about in those cases because they don't mutually recurse to your code |
| 15:16 | rhickey | Chouser: yes, implicit this |
| 15:17 | Chouser | oh. huh. |
| 15:17 | Chouser | well anyway, that simplifies things... |
| 15:20 | jgracin | rhickey: I see. But how is JVM going to know that my "tailcall" call is calling one of the forbidden methods? Should such methods have some kind of marker so that JVM knows it shouldn't discard the stack... I guess so... |
| 15:34 | Chouser | Is there something already like s: ((fn s [r] (if r (lazy-cons r (s (rest r))))) (range 5)) |
| 15:39 | rhickey | #(take-while identity (iterate rest %)) |
| 15:45 | rhickey | Better: #(take-while seq (iterate rest %)) |
| 15:50 | Chouser | nice |
| 15:52 | Chouser | There's no need it emit thisfn if it's not given a name, right? Since there's no other way to refer to it. |
| 15:52 | rhickey | Chouser: right |
| 17:01 | Chouser | vars are set up sufficiently during analyze that they can be resolved (no eval or special code needed) |
| 17:02 | rhickey | Chouser: I thought you might need to do something for require/use |
| 17:04 | Chouser | ah, I haven't gotten that far. I'm eval'ing ns for now. |
| 17:04 | Chouser | If we want to use ns to describe dependencies on other cljs files... well, I haven't thought about that at all. |
| 17:06 | Chouser | so for now the only thing that seems to fall back to runtime resolution are browser-supplied globals (window, document, etc.) |
| 17:06 | Chouser | which seems about right to me. |
| 17:06 | rhickey | sounds good |
| 17:07 | Chouser | It does work to provide a window/window.clj that defs a bunch of those, and then in the cljs you can say (ns foo (:use window)) and get the browser globals to resolve |
| 17:07 | Chouser | but I can't tell if that's a good idea or not. :-) |
| 17:08 | Chouser | Anyway, I'm going to work on stacking vars next. |
| 17:09 | rhickey | is there any notions of threads? |
| 17:09 | Chouser | no, none at all. |
| 17:10 | Chouser | There is a bug in some versions of IE that will interrupt your one JS thread with some asynchronous event handling. |
| 17:10 | rhickey | take note of the counter trick in vars to avoid a map lookup every reference |
| 17:11 | rhickey | the basic idea is each var has a counter. if it is zero, it's not thread/stack bound, so use the root binding, if not zero look up in map |
| 17:11 | rhickey | push bindings increments the counter for all bound vars, pop decrements |
| 17:11 | Chouser | Because of no threads, I was thinking the current value of the var could reside in myns.foo, and the stack would be kept elsewhere (myns._foo_stack?) |
| 17:11 | rhickey | on the JVM, this avoids a thread-local lookup followed by a map lookup |
| 17:12 | rhickey | single threaded that could work |
| 18:41 | lisppaste8 | Apologies for the trouble today. The bot should stop bouncing in and out of your channel now. |