8:18 Chouser: wow, oops. I had (if x (prn :x x) (foo)), and then decided it was too noisy and commented out the prn
10:13 gen-interface is updated -- it's different enough that I'm sure there will be a new set of objections. :-)
10:45 rhickey: Chouser: Thanks! A couple of things ...
10:46 you could use your {:keys [iname extends methods} destructuring
10:47 should be a helper for specs, so key names don't get repeated
10:47 seems a shame to gen the bytecode twice in gen-interface
10:47 that's it! :)
10:48 Chouser: I was using a vector for the spec for a while, but it seemed a bit muddled compared to putting a keyword in front of each part.
10:49 as for genning the bytecode twice, that's re-deriving dependant state, so I'm doing it Right, aren't I? ;-)
10:50 how about an optional bytecode argument for load-interface and save-interface. gen-interface would pass it in, but anyone using them directly wouldn't have to.
10:50 rhickey: should be save and load, no?
10:51 Chouser: yes, that's what I envisioned, or private helpers
10:51 Chouser: what should be save and load?
10:51 rhickey: gen-interface
10:52 Chouser: gen-interface does save and load -- you prefer the longer name?
10:52 rhickey: I don't understand what you mean by dependent state above
10:53 gen-interface name is ok
10:54 Chouser: oh, I was just referring to TarPit terminology. Rather than passing around accidental state (bytecode) I'm re-deriving it as needed.
10:55 rhickey: that's not accidental state, it's a perfectly fine value
10:55 created by one fn and passed to another 2
10:57 arohner: rhickey: did you look at my patch for the reader EOF exception?
10:58 rhickey: arohner: yes, I saw it, I'm not sure it's the right place for that, as not all readers are bound to files
10:58 arohner: ok
10:58 where would be a good place for it?
10:59 rhickey: arohner: haven't had time to decide that, but I ageee something better is in order there
11:00 arohner: ok, I'll look at it more see if I see anything better
11:00 I would like to learn this stuff well enough to contribute
11:01 I threw that together last night just to find which file was breaking
11:35 Chouser: gen-interface updated again.
12:15 rhickey: Chouser: looks good - does it work?
12:21 Chouser: how should I know? ;-) The tests in the comment work, but that's hardly rigorous.
12:22 rhickey: ok - thanks!
12:22 Chouser: it makes .class files, but I have no idea whats in them.
12:22 I can't imagine when I personally would ever use gen-interface. I hope someone else gets to use it at some point.
12:22 rhickey: have you tried to load them in a traditional way, via the classpath?
12:23 Chouser: no, but I can do that quick...
12:24 well, net.n01se.Foo is recognized, and reflection indicates it's an interface.
12:25 net.n01se.Bar throws an exception when I refer to it, because net.n01se.Other isn't defined anywhere, which is what I'd expect.
12:25 rhickey: can you implement it with gen-class?
12:26 Chouser: I didn't know about sun.misc.Signal
12:27 Chouser: oh, really? I've known about sun.misc.Signal ever since I googled it 10 minutes ago.
12:27 rhickey: ah
12:28 Chouser: hm, even after (gen-and-load-class 'net.n01se.Other), net.n01se.Bar fails. I'm probably missing something in my test.
12:28 http://
12:29 ^^^ good info there about which Java versions and platforms do what
12:29 rhickey: thanks
12:32 Chouser: well, if I gen-and-save-class or gen-and-save-interface for 'net.n01se.Other, then on a subsequent run of the JVM I can refer to net.n01se.Bar and net.n01se.Other seems to be found correctly.
17:04 what's the right way to organize files/namespaces when I have one that's sort of subsidiary to another.
17:06 I've got zip-filter and zip-filter-xml (which is dependant on zip-filter) -- both are currently in zip-filter.clj
17:07 I need to change that for the new source layout requirements. Do I really have to have zip-filter/zip-filter.clj and zip-filter-xml/zip-filter-xml.clj?
17:08 rhickey: Chouser: how does the functionality break down? you can have 2 files contributing to the same namespace
17:09 Chouser: I think I want 2 namespaces. zip-filter has some functions generally useful for zip trees
17:10 zip-filter-xml uses zip-filter for xml-specific zip trees
17:12 I think i'm just whining. 2 namespaces means 2 dirs with one file each.
17:12 albino: in python that would probably be done as zipfilter and zipfilter.xml
17:12 rhickey: could be zip-filter and zip-filter/xml, for namespaces zip-filter and zip-filter.xml
17:12 you don't want to do nesting with dashes
17:14 Chouser: oh, I see. zip-filter/zip-filter.clj and zip-filter/xml/xml.clj?
17:14 rhickey: yes
17:14 Chouser: that's a bit better.
17:16 I guess using _ instead of - in filenames is desirable for introp with Java tools?
17:17 rhickey: yes, that's required now, and lib will look for _ when the ns has -
17:17 Chouser: yeah, I know lib is doing that, I was just hoping lib had a good reason for it.
17:57 a second problem is that zip-filter.xml needs zip-filter
17:57 I guess I can check for the zip-filter namespace and use loadResourceFile if it's not there.
18:39 loadResourceScript