User:Zero Linden/Office Hours/2008 Mar 25

[13:02] HELLO Roberson: ***youyouyouyouyouyouyouyou...***
[13:02] HELLO Roberson: ***youyouyouyouyouyouyouiiiiiii...***
[13:02] Teleport completed: from [1]
[13:02] Rex Cronon: r u going to hold he office hour in his place rob?
[13:02] Rob Linden: oh, nevermind
[13:03] Rob Linden: there he is
[13:03] Morgaine Dinova: 'Morning Zero
[13:04] Rex Cronon: i don't see zero
[13:04] Zero Linden: I'z here
[13:04] Morgaine Dinova: To my right
[13:04] Rex Cronon: hi zero
[13:04] Saijanai Kuhn: He's sitting where Zha usually sits and Rob is sitting where Zero usually sits
[13:04] Zero Linden: Sorry all, I'm a little disheveled today - up all night with a sick kid, and
[13:04] Saijanai Kuhn: They're trying to confuse me
[13:05] Rex Cronon: greeting everybody
[13:05] Saijanai Kuhn: Sorry to hear that Zero
[13:05] Kooky Jetaime: oh
[13:05] Zero Linden: sitting here with him (home from school), and he's watching Finding Nemo as I type
[13:05] Morgaine Dinova: No worries Zero
[13:05] Alessandra Pinklady: oh boy
[13:05] Zero Linden: I'll type choice quotes as the come up
[13:05] Gareth Ellison: greetings
[13:05] Morgaine Dinova: chuckles
[13:06] Morgaine Dinova: Hi Gareth
[13:06] Gareth Ellison: "choice quotes"?
[13:06] Gareth Ellison: should i ask?
[13:06] Gareth Ellison: and excuse my wonderfully professional title
[13:07] Tree Kyomoon: love it!
[13:07] Morgaine Dinova: Tree doesn't need any such disclaimer. Everyone knows that he's a skeleton in RL too.
[13:08] Gareth Ellison: but one surrounded by muscle and flesh i presume
[13:08] Rex Cronon: u the bone man:)
[13:08] Tree Kyomoon: shouldnt have poured so much chlorine into the pool that day
[13:08] Zero Linden: Welllllllllll
[13:08] Gareth Ellison: so, err - teh serious talk now?
[13:08] Morgaine Dinova: Hehe
[13:08] Morgaine Dinova: Zero's busy with his kid, it might be on/off today
[13:08] Zero Linden: Welcome to my office hours - which are obstensibly about the architecture, past, present and future, of SL
[13:09] Zero Linden: Dicussion transcript is put in the wiki - thanks Tree! - so speak openly
[13:09] Zero Linden: Last Thursday we talked about alternative transports and those issues
[13:10] Rex Cronon: are the properties to sell, mode, edit part of the architecture?
[13:10] Zero Linden: of XMPP and AMQP
[13:10] Gareth Ellison: what was the general outcome of those talks for those of us who are lazy?
[13:10] Nuku Nemeth: waoh now im blind......
[13:10] Zero Linden: Uhm, Tree?
[13:10] Gareth Ellison: tree - detach please?
[13:10] Morgaine Dinova: Get rid of the red thing
[13:10] Tree Kyomoon: oops sorrry bout that...
[13:11] Arawn Spitteler: Tree doesn't seem to see his arow
[13:11] Tree Kyomoon: got some rezzing issues on my machine...lag o lichious
[13:11] Saijanai Kuhn: Tree was channeling Squirrel Wood for a sec
[13:11] Gareth Ellison: so, zero - general outcome of the transport talks?
[13:11] Tree Kyomoon: apologizes profusely for the squishings
[13:11] Gareth Ellison: in one sentence
[13:12] Zero Linden: Hehe - XMPP's addressing doesn't really work well for us, AMQP is probably far too special purpose to work (as far as I can see)
[13:13] Morgaine Dinova: The general outcome was sort of "None of those schemes are really tailored to SL, we would have to shoehorn our reqs into them, and TCP+HTML really gives us pretty much everything we need anyway."
[13:13] Gareth Ellison: XMPP for IM but not local chat would work - general protocol transport you'd be nuts
[13:13] Zero Linden: The second half was - we can work out the wording so that Event Queues expected usage is clear
[13:13] Zero Linden: XMPP doesn't work well for IM because of the asumption that your IM client will always connect to the same domain name
[13:13] Zero Linden: that is tied to your identity
[13:14] Zero Linden: rather, for avtar IM
[13:14] Morgaine Dinova: Zero: excellent re the wording. And hopefully avoid anyone going to COMET for explanations :-)
[13:14] Saijanai Kuhn: The current version is trivial. Still not quite sure what "path" refers to in the future version of Event Queues
[13:14] Gareth Ellison: @agentdomain.com if you make agent domains literal domains
[13:14] Gareth Ellison: @slagents.companyxyz.com
[13:14] Rex Cronon: i wonder how can somebody know what was talked at last office hours, since the transcript for it is not available:(
[13:14] Gareth Ellison: etc
[13:14] Morgaine Dinova: The posting of transcripts does seem to be hit or miss. Pity.
[13:15] Zero Linden: Rex - where in the spec do you see that?
[13:15] Rex Cronon: i was asking
[13:15] Tree Kyomoon: /sorry I cant make all the meetings to transcribe...but you know Im not the only one capable of it ;)
[13:15] Gareth Ellison: heh, zero could read the sim logs
[13:16] Morgaine Dinova: Really we need an automated system, so that just before leaving Zero can click on the "Post Log" box here and up she goes.
[13:16] Gareth Ellison: probably could be done with an LSL hack
[13:17] Saijanai Kuhn: There are several out there I believe
[13:17] Gareth Ellison: there you go
[13:17] Zero Linden: sadly I don't have last Thursday's transcript
[13:17] Gareth Ellison: get an LSL listener and dump logs to an email or outside web service
[13:17] Tree Kyomoon: contemplates parsing a sims log file...mmmm
[13:17] Gareth Ellison: i wonder if it could even POST direct to mediawiki
[13:17] Gareth Ellison: Tree - similar format to the viewer log
[13:17] Zero Linden: no - I'm not going to go log forensics.....
[13:17] Rex Cronon: wouldn't be that hard to make an scripted object that sends chat to a php server
[13:17] Kooky Jetaime: the LSL Listener dumping to an external source would be a good idea
[13:18] Tree Kyomoon: sure, that wouldnt be too tough
[13:18] Kooky Jetaime: plus then its a neutral point
[13:18] Gareth Ellison: llcommon and llmessage modules are the same
[13:18] Zero Linden: Gee Rex, might have to use llHTTPRequest... which I wouldn't know anything about... :-)
[13:18] Alessandra Pinklady: I actually ave a question I was wondering about the other day.
[13:18] Rex Cronon: :)
[13:18] Tree Kyomoon: plus its not like llHTTPRequest supports cookies or anything :)
[13:18] Gareth Ellison: i love how much server-side code has been released in the viewer source
[13:19] Zero Linden: Anyhoot - Rex, you just mentioned, as did some others, about a path in EventQueues -
[13:19] Zero Linden: I don't know what path you are refereing to.
[13:19] Gareth Ellison: the URL to the queue?
[13:19] Gareth Ellison: i presume it's HTTP delivery of course, as the specs suggest
[13:20] Zero Linden: [2]
[13:21] Zero Linden: I believe that Tess was talking about various ideas for extending
[13:21] Rex Cronon: i did? i am a littly fuzzy? what path? u mean the object properties(to sell, mod, edit)?
[13:21] Zero Linden: event queues for resources that return values
[13:22] Zero Linden: my bad - it was Saijaini: Saijanai Kuhn: The current version is trivial. Still not quite sure what "path" refers to in the future version of Event Queues
[13:22] Morgaine Dinova: Zero: I wonder why so few people are posting discussions there on that document. It's a bit of a ghost town currently.
[13:22] Zero Linden: (oy, I can never type your name, Saijanai, )
[13:23] Gareth Ellison: zero - a quick query about the current server code
[13:23] Zero Linden: Well, Morgain - I think that it covers territory that we've mostly hashed out and agree on
[13:23] Gareth Ellison: say a simulator or some other system component wants to send a message to an agent
[13:23] Gareth Ellison: and it can be sent via old-fashioned UDP or the newer HTTP-based delivery
[13:24] Gareth Ellison: does the main simulator/whatever code need to care about the difference or does the message system abstract that all away?
[13:24] Gareth Ellison: such that it can do something like message_system.send(message,agent_id)
[13:24] Morgaine Dinova: Zero: True enough, it's early days. But even stuff that hasn't been hashed out, like event queues, hasn't raised discussion, Odd.
[13:24] Gareth Ellison: if it can be abstracted like that, can everything be configured to run over HTTP?
[13:25] Zero Linden: Gareth - In the current "message liberated" state - for the most part, the message system abstracts that away -
[13:25] Zero Linden: however, we constantly find that higher level code has made assumptions about the fundimental nature of the lower level transport
[13:25] Gareth Ellison: i saw the powerpoints, but that wasn't made clear, heh
[13:25] Zero Linden: while in general this is a bad idea
[13:26] Saijanai Kuhn: Here tis: untitled text:348: [2008/03/25 10:51
[13:26] Gareth Ellison: would it be possible (regardless of sheer insanity) to run everything UDP-free with the current codebase?
[13:26] Zero Linden: when it comes to something as fundimental as UDp vs. TCP - it is hard to imagine that the upper levels wouldn't be affected
[13:26] Gareth Ellison: or with minimal changes?
[13:26] Zero Linden: In general, we've actually tested small set up s with all messages going TCP - and it works - it is just that the mangement under load often fails
[13:27] Zero Linden: because th e base assumptions of UDP vs.TCP transport are different
[13:27] Gareth Ellison: ah yeah, i remember you saying you've tested it
[13:27] Morgaine Dinova: Which aspect of management? Congestion etc?
[13:27] Gareth Ellison: so it is feasible then?
[13:27] Zero Linden: this is to be expected, becuase based on UDP, you manage more of this sort of thing in the application layer
[13:27] Saijanai Kuhn: Zero, Tess has several times suggested that event queue events would be different under the new setup
[13:27] Zero Linden: For example, expectations of how much latency you can tollerate
[13:27] Saijanai Kuhn: [ array of messages
[13:28] Gareth Ellison: path to handler?
[13:28] Saijanai Kuhn: thats what I don't understand...
[13:28] Gareth Ellison: thought message handlers were just functions that were added as callbacks
[13:28] Morgaine Dinova: Maybe we should prototype several alternative implementations of event queue transport, see which works best.
[13:28] Zero Linden: Okay, I can explain Tess' comment ... in a minute
[13:29] Zero Linden: Other things that are diffeerent are that under UDP you must be mindful of the message size
[13:29] Zero Linden: whereas under TCP, you generally shouldn't (or at least to a much larger point)
[13:29] Zero Linden: Recognize, that the event queue, as currently spec'd is running
[13:29] Zero Linden: right now on all of your viewers
[13:30] Zero Linden: As for the path
[13:30] Zero Linden: this is what she meant
[13:30] Zero Linden: in the LL implemetnation of event queues
[13:30] Morgaine Dinova: This is a worrying area, because it's an "implementation detail" which will actually have a major impact on the ability to interoperate, since downstream event message transport is so central and yet could differ widely.
[13:31] Gareth Ellison: here's an idea
[13:31] Gareth Ellison: redo the UDP system to just cut up larger messages
[13:31] Morgaine Dinova: lol
[13:31] Gareth Ellison: but then you're just edging closer to TCP
[13:31] Zero Linden: Gareth - UDP doesn't support that
[13:31] Zero Linden: realistically
[13:31] Gareth Ellison: why not?
[13:31] Gareth Ellison: clue - RequestImage
[13:31] dibbs Dovgal: Think of teh overhead.
[13:31] Gareth Ellison: the responses
[13:31] Zero Linden: since routers are free to drop UDP packets bigger then the segment size
[13:31] Gareth Ellison: yeah, overhead
[13:32] Gareth Ellison: make each segment of the bigger packet reliable
[13:32] Zero Linden: Er - back to the path
[13:32] Rex Cronon: routers can do that with tcp too
[13:32] Gareth Ellison: i know performance would suck but it'd make it possible to have completely free choice between HTTP and UDP delivery
[13:32] Zero Linden: so the "message" name is treated as a path fragment in the LL implementation
[13:33] Zero Linden: and appended onto something like "/from-simulator/messages/"
[13:33] Zero Linden: so when the viewer gets an event queue request "TeleportComplete"
[13:33] Zero Linden: it turns that into a HTTP style request on the viewer's own intenral HTTP server on the path "/from-simulator/messages/TeleportComplete"
[13:33] Gareth Ellison: ah, LLHTTPNode on the client - paths into it's children?
[13:34] Zero Linden: then if there is an HTTP handler at that node in the tree, it gets the request delivered and handles the event
[13:34] Zero Linden: Gareth - Exactly!
[13:34] Gareth Ellison: seems an overly complex system rather than just mapping message names to functions
[13:34] Zero Linden: And just so you see why that is so nice is that there is a wildcard node at "/from-simulator/messages/*"
[13:34] Saijanai Kuhn: also extremely LLspecific
[13:34] Gareth Ellison: NIH \_/
[13:35] Zero Linden: that handles everything without a handler and just reflects them back into the old binary message system
[13:35] Morgaine Dinova: That's the worry I mentioned earlier. Everything else we're doing seems to be generic, whereas this is pretty hardwired.
[13:35] Gareth Ellison: ah
[13:35] Zero Linden: Saijanai - in the spec'd version
[13:35] Gareth Ellison: the wild card is cool
[13:35] Zero Linden: we don't say that it*is* a path
[13:35] Gareth Ellison: i'm sold
[13:35] Zero Linden: but you'll see that names of resources have been defined in such a way
[13:35] Zero Linden: that they *could* be paths fragments if you choose to look them up that way
[13:36] Zero Linden: also, we don't call it "path", we call it "name", since it is the name of the resource that is trying to be invoked
[13:37] Saijanai Kuhn: thats what was throwing me I guess. ALl the current messages are "named" with single words. No path-like strings at this point
[13:37] Gareth Ellison: what is the advantage in seperate HTTP handlers vs binary handlers? could one not just have 2 sets of traditional message:callbacks mappings?
[13:37] Zero Linden: Now - you have to be a bit careful for security reasons when you do what I said : You have to make sure the name doesn't have stuff like "../../sooper/seekret/trusted/path/thing"
[13:38] Saijanai Kuhn: I think its so they can resuse all the UDP message handling
[13:38] Gareth Ellison: do you really need to have a hierarchy of messages?
[13:38] Gareth Ellison: let new callbacks specify "i only want to handle HTTP stuff"
[13:38] Zero Linden: Gareth - the HTTP handlers are very easy to write in C++ - mesage handlers a little less so - and the old binary method isn't that extensible
[13:38] dibbs Dovgal: I klike the potential flexibility this implies.
[13:38] Saijanai Kuhn: the current viewer uses the same handlers for both udp and TCP I believe
[13:39] Gareth Ellison: can the message system only do server>client?
[13:39] Gareth Ellison: sorry
[13:39] Gareth Ellison: i meant server>client POST
[13:39] Zero Linden: Well - again, the spec, like the HTTP spec, mostly says that the path as a whole is just a long - name
[13:39] Gareth Ellison: can it only send POST server>client with the HTTP stuff?
[13:39] Zero Linden: that it has any heirarchal structure is soley up to the server
[13:39] Gareth Ellison: could it possibly do GETs to the client?
[13:39] Zero Linden: Gareth - well, that is the extension that Tess and Icehouse are contemplating
[13:39] Gareth Ellison: and then wrap the whole thing up into a neat little HTTP client abstraction
[13:40] Saijanai Kuhn: now understands why Donovan (which?) suggested that message passing between parts of the modular client be done using http
[13:40] Zero Linden: a way to encode both the method (GET, POST, PUT, DELTE) in the request block, and a way to get a response
[13:40] Gareth Ellison: donovan would put BGP routing data over HTTP if he could
[13:41] Gareth Ellison: it'd fail from lack of connectivity, at which point he'd invent a new kind of HTTP for layer 2 stuff
[13:41] Gareth Ellison: heh
[13:41] Gareth Ellison: so, can we call it a safe presumption that the client will in future have essentially it's own httpd (regardless of the crazy hacks used to interface with it)?
[13:42] Zero Linden: contemplates HTTP semantics in a layer 2 protocol.....
[13:42] Gareth Ellison: lol
[13:42] Morgaine Dinova: You don't have to implement the path as a real filestore path, and open yourself to filestore walking. Just hash the whole string and lookup the service in one operation. Filestore-walking hacks simply fail to find a valid hash.
[13:42] Zero Linden: Gareth - I think that is a reasonable implemetnation strategy
[13:42] Leem Hua: mutters HTTP-ARP request...
[13:42] Zero Linden: though is by no means required
[13:43] Zero Linden: of course, the current viewer does...
[13:43] Gareth Ellison: oh god, please never ever ever put a real httpd WITH LOCAL FILESYSTEM ACCESS in the viewer
[13:43] Gareth Ellison: that's asking for mass ownings
[13:43] Zero Linden: oh NO
[13:43] Zero Linden: Indeed, the current HTTPD framekwork in C++ doesn't even have file system access coded anywhere
[13:43] Gareth Ellison: GET [3]
[13:43] Gareth Ellison: POST [4]
[13:43] Gareth Ellison: shudders
[13:43] Zero Linden: er, PUT
[13:44] Zero Linden: :-)
[13:44] Morgaine Dinova: Aye. You can have apparent structure to make the paths understandable, a la REST, but they shouldn't use filestore walking.
[13:44] Gareth Ellison: POST if it already exists ;)
[13:44] Zero Linden: Well, on the other hand, one could almost imagine a PHP implementation..... (remember, Apache, has plenty of configuration directives to keep people out of your file system)
[13:45] Tree Kyomoon: can someone pass me the chatlog up to now? Ive had some internet connectiveity issues so I missed the last 15 minutes or so
[13:45] Saijanai Kuhn: I can do it in Python no problem. You can grab the POST data from within the BASEhttp class if you know where to look
[13:45] Zero Linden: Gareth - actually - that is a subtle point - but I put in the spec that in that sort of case, we take the multiple PUT interpretation
[13:45] Zero Linden: of REST
[13:45] Morgaine Dinova: Maybe the term separators should be dots instead of slashes, just to highlight that filestore walking isn't the idea in mind.
[13:45] Gareth Ellison: if we get it so that any message can be put over UDP or HTTP then it should become possible to do crazy slow hacks of "a sim in PHP"
[13:46] Zero Linden: Morgain - URL spec does put semantics on the slash
[13:46] Saijanai Kuhn: my goal with the python scripts is to get as much of the non-graphical cliant working in scripts as possible. iPhone viewer, anyone?
[13:46] Zero Linden: so - I say we keep them because most infrastructure support is designed around partitioning at slashes.
[13:46] Saijanai Kuhn: though apparenlty you can use ObjC with iPHones so that isn't a problem anyway
[13:47] Gareth Ellison: python can do anything
[13:47] Morgaine Dinova: Heh, well hopefully we'll ignore that semantic, since it gives nothing of value anyway and just raises security problems. Resource paths are virtual anyway.
[13:47] Zero Linden: well, so can macros in vi... but....
[13:47] Gareth Ellison: i have a stupidly efficient sim running based on ironpython+libsl
[13:48] Saijanai Kuhn: Gaeth do you have IM working?
[13:49] Saijanai Kuhn: has group IM on the brain...
[13:49] Rex Cronon: gave you 2008-03-25 13:47:32, zero office hours, partial.
[13:49] Gareth Ellison: Saijanai - right now i'm fiddling with physics
[13:49] Gareth Ellison: i consider IM an easy problem
[13:50] Saijanai Kuhn: Zero, Zha and I were kicking around ideas for diagramming the procols and she conducted a brief discussion of the UML diagramming in this morning's Groupies meeting
[13:50] Gareth Ellison: i wonder if i just insulted all present lindens
[13:50] Morgaine Dinova: Well IM is an important subject, since it binds people together. It's had little air time in AWG so far, but that must change.
[13:50] Tree Kyomoon: /thanks rex
[13:50] Saijanai Kuhn: Gareth, do you have Group IM working or no? If you do, its trivial, if not...
[13:50] Rex Cronon: np
[13:50] Gareth Ellison: no
[13:50] Gareth Ellison: i haven't started on it
[13:51] Gareth Ellison: it is indeed a trivial thing - i've implemented it in the opensim codebase in a crazy way before
[13:51] Morgaine Dinova: Group IM is trivial for trivial population numbers. The problem is scaling :-)
[13:51] Zero Linden: No, Gareth - you didn't - just shows that you've not started on it! ;-)
[13:51] Morgaine Dinova: chuckles
[13:51] Gareth Ellison: Zero - didn't say i committed patches :)
[13:51] Zero Linden: Did folks come to some conclusion about diagramming?
[13:52] Zha Ewry: UML sequence
[13:52] Zha Ewry: Tooling to be determined for the sequenc stuff
[13:52] Zha Ewry: The rest.. up for grabs
[13:52] Zero Linden: Zha - have you been here the whole time?
[13:52] Zha Ewry: /no
[13:52] Zero Linden: wonders if there is an XML langauge for UML - whcih can then be XSLT'd into SVG
[13:52] Zha Ewry: was trapped in a RL meeting
[13:52] Zha Ewry: mutters rude things and refers people to her flickr
[13:52] Morgaine Dinova: Zero: goodo idea
[13:52] Zero Linden's: hatred of acronyms wells up
[13:52] Saijanai Kuhn: for me, the confusion is in the nuts and bolts of the current implementation. Design issues aren't even a consideration
[13:53] Zha Ewry: and her twitter
[13:53] Gareth Ellison: lies! she was talking in IM a few minutes before hand
[13:53] Zha Ewry: In world yes
[13:53] Zha Ewry: not here, or able to focus
[13:53] Zha Ewry: hard to type while standing in front of a whiteboard
[13:53] Zha Ewry: and scribbling
[13:53] Gareth Ellison: gimme URL
[13:54] Saijanai Kuhn: so anyway, for high-level interaction, UML sequencing diagrams seemed to be acceptable to everyone
[13:54] Zha Ewry: What I'm looking to see. is the core interactoin patterns, including the long poll, in a sert of UML diagrams which we could in time
[13:54] Zero Linden: I suppose it is time to call in a favor with Grady Booch...
[13:54] Zha Ewry: imagine using at standards bodies, and such
[13:54] Zha Ewry: grins
[13:54] Zero Linden: Ask him to consult on diagramming techniques for this
[13:54] Gareth Ellison: IETF Zha?
[13:54] Zha Ewry: We can
[13:55] Zha Ewry: Grady's keen on the space
[13:55] Saijanai Kuhn: the harder part is the nuts and bolts level of what mesage does what where when
[13:55] Zero Linden: He owes me one....
[13:55] Zha Ewry: Cool
[13:55] Zha Ewry: We can tag team him
[13:55] Gareth Ellison: saijanai - not much of that needs to change
[13:55] Saijanai Kuhn: wants in on that in some small way
[13:55] Gareth Ellison: so i refer you to the comments in the message template
[13:56] Saijanai Kuhn: Gareth, what do you do with the info you get from the various IM-related EventQueueuGet messages?
[13:56] Gareth Ellison: Zero - i've noticed that SL uses port numbers in the dynamic range
[13:56] Gareth Ellison: any possibility of getting real IANA allocations?
[13:56] Zero Linden: Gareth - that is soemthing Cisco has pushed on too!
[13:56] Saijanai Kuhn: and John Hurliman and I created the table thats on the wiki for the Improved Instant Message, so I'm aware of at least some of the details in IIM packets
[13:56] Gareth Ellison: hmm, cisco are pushing LL to get IANA allocations?
[13:56] Zero Linden: Gareth - that is soemthing Cisco has pushed on too!
[13:56] Saijanai Kuhn: and John Hurliman and I created the table thats on the wiki for the Improved Instant Message, so I'm aware of at least some of the details in IIM packets
[13:56] Gareth Ellison: hmm, cisco are pushing LL to get IANA allocations?
[13:57] Zero Linden: Well - I think the only advantage of that is that with defined IANA ranges, routes would have checkboxes for letting them out
[13:57] Morgaine Dinova: Zero: once we're done XSLT'ing the UML into SVG, the next step is to XSLT it into C++. Programmers can then retire ;-)))
[13:57] Zero Linden: Is there another advantage to the port allocation?
[13:57] Zha Ewry: Hah. Morgaine
[13:57] Gareth Ellison: i'm thinking defined IANA ranges are a path towards RFCs getting more easily accepted
[13:57] Zha Ewry: I've heard that one from the tools vendors from about 1959 forward
[13:57] Zha Ewry: Well, Ok, rea dit in old papers
[13:58] Gareth Ellison: Zha - you're an old fool, C++ wasn't around back then ;)
[13:58] Zero Linden: Morgaine.... It is a holy grail to have literate-artistic-programming --- just describe in a mixture of prose, graphics and code --- hopefully never duplicating a detail
[13:58] Zero Linden: at least - I'd be in programmer heaven...
[13:58] Gareth Ellison: PLT DrScheme
[13:58] Gareth Ellison: \_/
[13:58] Gareth Ellison: i love the pictboxes
[13:58] Saijanai Kuhn: Squeak eToys
[13:58] Morgaine Dinova: Zero: don't forget the comic strip section, that's a key input ;-)
[13:58] Gareth Ellison: (def somevar (AN ACTUAL PICTURE HERE))
[13:59] Zha Ewry: But. in practice, I'll settle for some good ties bwteen UML and high level design
[13:59] Tree Kyomoon: eeek theres programming in heaven too? Cant a guy catch a break??
[13:59] Zha Ewry: Good programming is in heaven
[13:59] Gareth Ellison: somevar gets assigned the value of an actual image
[13:59] Zha Ewry: Bad programming is on earht
[13:59] Gareth Ellison: i know python
[13:59] Gareth Ellison: err, heaven
[13:59] Zero Linden: [5]
[13:59] Gareth Ellison: i know heaven - a python CLI
[13:59] Gareth Ellison: Zero - trust me it's slow and fun
[14:00] Gareth Ellison: a classic interpreted language
[14:00] Cracker Hax: Does that mean SL is hell then?
[14:00] Cracker Hax: Heh jk
[14:00] Zha Ewry: grins at Scheme conitinuations
[14:00] Zha Ewry: I see Lambdas!
[14:00] Arawn Spitteler: Object Reality = Creation.New()
[14:00] Gareth Ellison: i point you all to to paul graham
[14:00] Zero Linden: wonders how you graphically display a continuation? with elipses?
[14:00] Zha Ewry: But. here, in RL..
[14:00] Morgaine Dinova: Heh, xkcd had a great strip on languages ..... God officially programmed the universe in LISP, but .... "Well, actually we hacked it together in Perl".
[14:00] Zha Ewry: We kind of are likely to doc in prose, and formal doc and
[14:00] Zero Linden: and paul graham points at a cons cell
[14:00] Zha Ewry: UML like stuff
[14:01] Zha Ewry: and.. code it up in python and C__
[14:01] Zha Ewry: C++
[14:01] Zero Linden: well all - I've got to run
[14:01] Zero Linden: it is 2pm
[14:01] Zha Ewry: So.. capturing it in UML like formalisms would rock
[14:01] Gareth Ellison: heh
[14:01] dibbs Dovgal: take care
[14:01] Zero Linden: (or 1401 - my favorite IBM computer)
[14:01] Zha Ewry: prefers 30:81
[14:01] Morgaine Dinova: Cya Zero
[14:01] Tree Kyomoon: I will post log, thanks for the help , Rex!
[14:01] Rob Linden: heads out as well
[14:01] Gareth Ellison: i wonder if we should all get a few different lightweight libsl's out
[14:01] Zero Linden: thanks for coming - see you Thursday
[14:01] Morgaine Dinova: Cya Rob
[14:01] Gareth Ellison: in different languages
[14:02] Rex Cronon: np tree
[14:02] Gareth Ellison: i could dig up my old gawk libsl
[14:02] Gareth Ellison: heh
[14:02] Rob Linden: bye all
[14:02] Rex Cronon: bye

User:Zero Linden/Office Hours/2008 Mar 25

Navigation menu

Search