2008-08-12
| 08: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 | Chouser | 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 | rhickey | you could use your {:keys [iname extends methods} destructuring |
| 10:47 | rhickey | should be a helper for specs, so key names don't get repeated |
| 10:47 | rhickey | seems a shame to gen the bytecode twice in gen-interface |
| 10:47 | rhickey | 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 | Chouser | as for genning the bytecode twice, that's re-deriving dependant state, so I'm doing it Right, aren't I? ;-) |
| 10:50 | Chouser | 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 | rhickey | 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 | rhickey | 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 | rhickey | 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 | arohner | 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 | arohner | I would like to learn this stuff well enough to contribute |
| 11:01 | arohner | 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 | Chouser | 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 | Chouser | well, net.n01se.Foo is recognized, and reflection indicates it's an interface. |
| 12:25 | Chouser | 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 | rhickey | 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 | Chouser | http://www.ibm.com/developerworks/java/library/i-signalhandling/ |
| 12:29 | Chouser | ^^^ 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 | Chouser | what's the right way to organize files/namespaces when I have one that's sort of subsidiary to another. |
| 17:06 | Chouser | I've got zip-filter and zip-filter-xml (which is dependant on zip-filter) -- both are currently in zip-filter.clj |
| 17:07 | Chouser | 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 | Chouser | zip-filter-xml uses zip-filter for xml-specific zip trees |
| 17:12 | Chouser | 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 | rhickey | 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 | Chouser | 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 | Chouser | a second problem is that zip-filter.xml needs zip-filter |
| 17:57 | Chouser | I guess I can check for the zip-filter namespace and use loadResourceFile if it's not there. |
| 18:39 | Chouser | loadResourceScript |