Hi Tom, 2009/7/2 Tom Faulhaber <tomfaulha...@gmail.com>: > > > >> Are you suggesting that "clojure reader parsed code" could be first >> translated back to String and reinjected to the "source code reader" ? >> Indeed that could simplify final implementation. I don't know what the >> impact on performance would be, though. > > No, that wouldn't work because the clojure reader is lossy. > > What I have in mind is simply not having a clojure reader version, but > only your own "enhanced" version. > > One thing that I was thinking is that this might be identical to the > Clojure-produced version but with extra metadata attached to the > structure to indicate "source extras" (like comments and metadata > annotations) and syntax variations (unclosed parens and the like). > This would be nice for you if you're using the reader produced data > for other stuff. > > On the other hand, it might be more useful to wrap the structure the > you read in a container (or set of containers) that annotates it. A > simple transform could then "extract" reader compatible version if you > needed it. > > >> > One experiment I've been doing is to build an "Object Explorer" based >> > on pprint. The thing I added (but that's not totally integrated back >> > into pprint yet), is callbacks to let you map structure to output >> > location. I use it there for allowing the user to click on parts of >> > the object displayed to expand and contract its subobjects. >> >> I must look at the code, but is this some sort of implementation of >> the Builder design pattern ? > > Not really. > > What you have is a Clojure object that you want to explore, but it's > huge, so you don't just want to print it and look at it. > > Instead you use the control variables *print-length* and *print-level* > to only print a high-level view of it (into a text control in a swing > app). > > Then when you want to go deeper into some part of the structure, you > just click on it and it expands (i.e., *print-level* is incremented, > but only for that part of the structure). Clicking again contracts it. > > This is accomplished via callbacks in the pretty printer that allow us > to track where on the screen each part of the logical structure is. > (Simplistically, remember where I enter a particular level of list and > where I exit it.) > >> Wow, you gave me a lot of homework ;-) > > Just trying to keep you busy :-)
I don't know if it's me, but while doing my homework reading the X stuff pdf, I almost fell asleep ... :-$ (ok, it's generally late by night when I can start work on the eclipse plugin, this can also explain things :-) But seriously, it seems that the reading assumes from me a basic knowledge I don't have ... it goes very quickly into detail I don't understand, while leaving me alone to try understanding a little textual graphic abstractly representing the notions of logical blocks, etc. Do you know of something more understandable (for a dopey like me ! :-) that I could read first ? > >> Well, honestly, 300 to 400 lines per second does not seem very >> performant. > > Agreed. Which is why I mentioned the incremental thing. > >> This implies that the reformating of clojure.core would >> take 10 seconds .... I indeed expected something around "very fast" >> for a medium size file (300 - 400 lines), and 1 to 2 seconds for >> something big as clojure.core (but maybe I'm just dreaming). Do you >> already know where to look for better perf ? > > Those speeds may be achievable, but even 1-2 seconds will seem slow if > you're doing it all the time. I believe that most systems that do this > use incremental algorithms so as to be O(1) and not O(n) on the file > size. > > I do have some places to look for more performance, but I have no idea > how much faster I can make it go before I have to make hard choices. > It seems like every few weeks I take a whack at performance and know > it up an order of magnitude, but who knows how many of those rabbits > (if any) are left in the hat :-). > > If you really think about all the cases, pretty printing is reasonably > complex. Add to that my desire to have a pretty printer with flexible > dispatch (which is what would make it work at all for apps like this) > and there's more overhead still. But you can assume that I'll get you > a bunch more performance over time. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
