Conversation with #inferno at Sun Dec  9 22:41:06 2012 on powerman@irc.freenode.net (irc)
(02:16:24) powerman: is anyone here know yacc? I don't understand something in limbo.y…
(02:17:51) powerman: I suppose terms assoc definition with %left, %right and %nonassoc also define precedence
(02:19:16) powerman: there are 4 blocks:
(02:19:58) powerman: 1) %left/%right, operators =, …, +, -, …, <-
(02:20:32) powerman: 2) %left/%right, operators (), [], ++, --, ->, .
(02:21:00) powerman: 3) not interesting, "or" and "to"
(02:21:39) powerman: 4) %nonassoc, everything else including !, ~, len, hd, …
(02:23:02) powerman: problem is, most of things in 4th block is just syntax terms and can't be easily checked for precedence, BUT !, ~, len and hd can be checked
(02:23:36) powerman: and it looks like their precedence is between 1st and 2nd blocks, not after 2nd block!
(02:25:20) powerman: this mean either order of %left/%right/%nonassoc definitions doesn't define precedence (when where and how it defined?) or this is some yacc magic
(02:35:08) leetspete left the room (quit: Ping timeout: 245 seconds).
(02:35:30) jbrhee left the room (quit: Ping timeout: 252 seconds).
(02:56:26) jbrhee [~jess@76.91.33.110] entered the room.
(02:58:20) leetspete [~pete@76.91.33.110] entered the room.
(04:03:10) powerman: also I wonder why Lref (i.e. "ref") is %left - isn't it should be %nonassoc?
(04:04:19) leetspete: powerman: You've been prolific it looks like!  :)
(04:04:43) leetspete: Can't say that I know yacc well enough to be able to speak intelligently about limbo's .y, though.
(04:05:41) leetspete: I've actually spent a chunk of the weekend learning yacc.
(04:07:41) powerman: I'd like to avoid this, if possible. :)
(04:08:51) powerman: I just wanna update limbo syntax highlight with up-to-date limbo syntax, plus probably find and document all differences between current limbo syntax and syntax described in "The Limbo Programming Language. Dennis M. Ritchie (Revised 2005 by Vita Nuova)"
(04:09:16) powerman: and limbo.y is only authoritative source of this information
(04:10:30) leetspete: I was doing it for awk.  I got about as far as I could get with a little VM before needing to actually start on the parser.  yacc looked much simpler the last time I tried it, but what I tried was "calculator tutorial".  :)
(04:11:03) leetspete: That's cool!
(04:11:07) powerman: that doc doesn't describe **= operator, `multiline strings`, polymorphism, fixed type and who knows what else
(04:11:27) doublec: I didn't know there was a difference
(04:11:28) leetspete: Yeah, there are a few undocumented features that actually are features.  :)
(04:11:34) doublec: is it described anywhere other than soufce?
(04:11:43) leetspete: Like (some, tuple, of, things).t0.
(04:12:05) leetspete: doublec: In the book, but unfortunately it's a bit out of date.
(04:12:15) powerman: leetspete: .tn is documented http://powerman.name/doc/Inferno/limbo.html#8.1.3
(04:12:39) powerman: at least in this (Revised 2005 by Vita Nuova) version
(04:13:01) doublec: ok thanks
(04:13:40) powerman: doublec: some things like fixed type documented in /doc/limbo/addendum.pdf
(04:13:44) leetspete: Ah, I guess I didn't see it.  I remember hearing that it was undocumented.
(04:14:23) leetspete: The best documentation for the polymorphism seems to be /appl/lib/lists.b :)
(04:15:26) leetspete: "Documentation" used in the loosest sense possible, of course.
(04:15:33) powerman: yeah :) but AFAIK there some bugs in polymorphism, which triggered by basic enough usage similar to one in lists.b
(04:18:53) doublec: is powerman.name runing on a limbo server?
(04:19:30) powerman: no. :) 
(04:19:47) powerman: i didn't tried to do web/cgi development in limbo yet
(04:20:06) powerman: mjl has some libs for this
(04:20:25) doublec: yes, I saw those which is what made me wonder
(04:20:44) doublec: I'm interested in trying it out
(04:21:12) leetspete: I ran siege against svc/httpd/httpd; it actually performs better than lighttpd/nginx, to my surprise.
(04:21:15) doublec: does inferno use epoll or other high performance event handling?
(04:21:21) doublec: or is it socket/select based?
(04:21:26) doublec: s/inferno/hosted inferno/
(04:23:15) powerman: I'm planning to try it too. We've full stack of perl modules to ease cgi development, and most likely I'll rewrite these modules in limbo instead of using mjl's libs (if I recall correctly they are too basic compared to our perl modules, so at most I'll use mjl libs for lowlevel tasks only). But I've more urgent tasks for now, so I've no idea when this happens.
(04:24:40) powerman: Inferno doesn't use epoll, it use blocking i/o in separate host os threads instead. But I've compared inferno performance to perl's epoll-based script, and speed was nearly same.
(04:25:14) powerman: http://osdir.com/ml/os.inferno.general/2007-02/msg00109.html
(04:25:31) leetspete: doublec: I believe it uses select() to stay away from getting too OS-specific, although select() performs better with a small number of FDs, which is the case for the threading model Inferno uses.
(04:26:00) leetspete: In particular, I think alt{} is implemented with select.
(04:26:09) doublec: leetspete, powerman: thanks I'll do some digging
(04:26:16) doublec: the problem with select is the limit on 1024 fd's
(04:26:19) doublec: on linux 
(04:26:38) doublec: I hit this when I wrote a busy network server in the mozart/oz programming language (I wrote a bitcoin mining pool)
(04:26:46) powerman: problem with select is it's too slow
(04:27:06) powerman: and I don't think inferno uses it, neither for i/o in threads nor for alt, but I'm not sure
(04:27:53) powerman: I think alt/channels are implemented without using file descriptors at all.
(04:28:11) powerman: it's just shared memory and locks
(04:28:35) leetspete: doublec: You're all but guaranteed to not hit over 1024 FDs in a single select() in Inferno.
(04:29:16) leetspete: powerman: Oh, right.
(04:30:32) powerman: leetspete: select( in *.c files used only in: emu/Nt/ipif{6,}.c and tools/libstyx/{Nt,Posix}.c
(04:30:44) leetspete: powerman: You beat me to it.  :)
(04:31:00) leetspete: No more than 8 FDs passed into select.
(04:32:06) leetspete: powerman: But I seem to recall select() beating epoll() when there's a very small number of FDs in question.
(04:33:05) powerman: maybe. but in such use case speed of epoll/select probably doesn't matter at all
(04:33:31) leetspete: Yeah.
(04:33:41) doublec: so I see lots of osenter/osleave calls around blocking api's. I guess this is where the switching is handled by the threads, etc.
(04:37:26) leetspete: I had done some benchmarking of 1 proc per CPU + 1 thread per request a while back when I worked for ATTi.  It does beat select()/epoll(), but when you're memory-constrained (we weren't; they were all 16GB machines) you can end up running out of stack for the threads if enough simultaneous reqs come in.
(04:37:56) leetspete: As I recall we had to do some ulimit() stuff, but that was all my coworker's doing.
(04:38:52) leetspete: These were green threads, but we got roughly similar numbers (unnoticable extra latency) for OS threads.
(04:39:14) doublec: limbo uses green threads backed by a pool of os threads I assume?
(04:41:02) powerman: yes
(04:42:32) powerman: except it's not limbo, but dis
(04:42:54) doublec: right
(04:43:37) powerman: anyway, i/o performance isn't an issue for inferno/limbo at all
(04:43:39) doublec: I wonder how viable a C->dis compiler would be
(04:44:00) doublec: similar to how enscripten does it (via llvm->javascript)
(04:44:32) powerman: it may be a little slower or not, but that doesn't matter. it fast enough, and if it doesn't fast enough for your task then you'll need to scale it to cluster anyway
(04:45:23) doublec: I might try porting my mining pool to inferno and see how it goes
(04:45:26) powerman: there are c->limbo converter, at least I hear about it several times. not sure is it up-to-date and working right now, but suppose it is
(04:46:49) leetspete: powerman: I tried it last time I tried a port of awk.  :)  It works, but needs nearly endless tweaking for anything with strings or raw memory, which is...most of C.
(04:47:08) doublec: I'm torn between doing that, or making the inferno port for android phones more usable :)
(04:48:07) powerman: doublec: toss the coin and do both one-by-one :)
(04:48:26) doublec: or run the pool on my inferno phone ;)
(04:54:10) leetspete: Speaking of clusters, the little map/reduce thing I'm doing gave unsatisfying results for the trivial math/factor.  Took very little CPU to factor numbers up to the limit, so I did a small port of math/factor to use IPints to make it a bit more CPU-intensive.  :)  http://static.debu.gs/ipfactor.b
(04:55:58) leetspete: GNU's factor was still faster, looks like they're using Pollard's Rho.
(04:56:22) leetspete: I was trying to get something to be slow, though, so I didn't bother reworking it.  :)
(04:57:53) leetspete: It's still pretty damned speedy, though.  Had to go pretty high to make it take more than a second to factor numbers.
(04:58:44) anth_r: <leetspete> I ran siege against svc/httpd/httpd; it actually performs better than lighttpd/nginx, to my surprise.
(04:58:57) anth_r: that's *really* surprising to me. did you write this up anywhere?
(05:00:14) anth_r: also: what's ATTi?
(05:00:37) raphaelsc left the room (quit: Remote host closed the connection).
(05:01:26) leetspete: anth_r: I didn't write it up; these were highly nonscientific benchmarks, and I'm terrified of contributing noise to the already poor S:N ratio for HTTP benchmarking.  :)
(05:01:51) doublec: I can imagine the reddit comments over such an article already :)
(05:02:05) anth_r: understandable, but it's surprising enough that i'd love to poke at it.
(05:02:19) leetspete: ATTi is AT&T Interactive, one of the many names that yellowpages.com went through after AT&T bought them.
(05:02:29) anth_r: ah
(05:02:54) leetspete: Where "AT&T" is "SBC after buying the AT&T trademark", rather than actual AT&T.  But we did interact with Labs once in a while.
(05:03:27) anth_r: but by that time, of course, "Labs" at AT&T (sorry, at&t) wasn't Bell Labs, which is now owned by the french.
(05:04:10) leetspete: Yeah.
(05:05:00) anth_r: you guys are a pain in my butt, by the way.
(05:05:23) anth_r: i have this medium-sized body of limbo code. i need the functionality for a project i've been putting off for a while, but am now getting seriously back into.
(05:05:39) anth_r: i'd more-or-less decided to rewrite the thing in go.
(05:05:42) leetspete: Most of the interesting bits went to Lucent.  Some of them stayed in the splinter, though, like David Korn.
(05:06:08) anth_r: but i've made this decision before. and pretty much every time i get ready to start, it psychiclyt triggers bouts of activity in here.
(05:06:30) leetspete: anth_r: Ha, sorry for the pain.  :)
(05:06:40) anth_r: leetspete: yeah, tom duff, too (although he didn't stick around)
(05:07:17) anth_r: most of my (then) Bell Labs colleagues have ended up at at&t labs.
(05:07:35) leetspete: A friend of mine has been on my back about doing some Go.  The language was nice but it was overall very upsetting to have to go back to Linux-ing things.  I've been spoiled by all the niceness in Inferno.
(05:07:45) anth_r: (or at&t business units; i'm not sure if at&t has the same ambiguity over who's in "labs" as they did in the pre-split days)
(05:07:51) leetspete: anth_r: You worked at Bell Labs?  Pretty cool!
(05:08:14) anth_r: leetspete: well, i'd be doing it for go on plan 9, which seems to alleviate at least most of that mess.
(05:08:22) anth_r: but i still like the inferno model.
(05:08:51) anth_r: and yes. i actually started out in the Inferno BU, which explains part of my strong atachment and why i'm so reluctant to move anything away from it.
(05:08:59) leetspete: anth_r: Oh, that's much nicer.  :)
(05:09:20) leetspete: anth_r: I'm not quite certain, either.  We did get a visit from Larry Rose to talk about some interesting database.
(05:09:26) anth_r: i was on loan to research for a while, then moved to another BU officially when the research lab i was working with moved.
(05:09:44) anth_r: yeah, i remember Larry. good guy. shame about the java. :-)
(05:10:45) powerman: go on plan9 sounds much better than go on linux. I'm stick to limbo mostly because of inferno's runtime simplicity, which I can't have in go/linux.
(05:11:18) powerman: but I can't run native plan9, our servers are in linux and this can't be changes
(05:11:25) anth_r: i'm still a huge fan of the "whole system" philosophy behind inferno+limbo, which go mostly dumps.
(05:11:30) leetspete: Ha, luckily we didn't have to deal with Java.  It was some database used for distributed processing, pretty nice overall but strange, and aside from that we couldn't get the source; when we wanted a build we emailed Larry and he'd wander over to the office of the guy that owned the DB and tell him what to compile it for.
(05:12:07) powerman: is it possible, say, use plan9port to run go in environment which is more like inferno/plan9 than linux?
(05:12:26) anth_r: leetspete: weird. when was this? i thought he went straight from the BU to Savaje. or is he back?
(05:12:50) leetspete: It was 2008-ish?  2009?  Let me check some timestamps.  :)
(05:13:10) anth_r: powerman: p9p would give you the saner user space tools, but i'm not sure that would solve most of the problems you'd face as a coder in a linux environment.
(05:14:21) anth_r: leetspete: probably post-Savaje, then. i can't remember exactly, but i think they'd been bought by then.
(05:14:26) leetspete: anth_r: I tend to agree about the environment thing.  Inferno kind of "clicked" for me after I did some hairy Erlang project and realized that nearly all these languages were doing a "buggy version of half of Plan 9".
(05:14:34) anth_r: rembember what the database was called? i knew folks on two at&t db projects, and i'm just curious.
(05:16:25) leetspete: anth_r: Daytona!  Just found the files.  May 2008.
(05:16:46) anth_r: i keep threatening to update the public pq port with some work i've done (inlcuding a simple inferno/styx query fs for it).
(05:17:56) anth_r: i remember Daytona, but only barely. i think it had a previous name - something with memory or ram or something explicitly in the name.
(05:22:46) leetspete: anth_r: Yeah, the guy who did it was made a Fellow.  Larry said there was no way we'd get the source until that guy retired.  He had some interesting perspectives on why Plan 9 didn't get adopted internally to the extent that Unix did; allegedly it was due to politics and some personality conflicts with someone.
(05:23:45) anth_r: plan 9 or inferno?
(05:53:14) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.