Conversation with #inferno at Thu Jul 30 16:49:41 2009 on powerman-asdf@irc.freenode.net (irc)
(17:23:21) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(17:27:18) j123m left the room (quit: Read error: 104 (Connection reset by peer)).
(17:36:06) soul9: ∠yone try compiling latest tip?
(17:36:25) soul9: s/∠/an
(17:36:28) soul9: $ hg tip |head -1
(17:36:28) soul9: changeset:   341:d261817d4b73
(17:36:50) soul9: i had to comment spree in appl/mkfile to get it to compile
(17:36:52) soul9: http://friendpaste.com/2jEdhr5VUpVXtlOroTinmW
(17:40:54) vsrinivas: mjl-: no...
(17:41:05) vsrinivas: i even tried as far as mounting p9p's factotum inside inferno
(17:41:23) vsrinivas: no dice
(17:41:36) soul9: er, you trying to mount authed plan9 stuff?
(17:42:01) vsrinivas: yep
(17:42:04) vsrinivas: sources, in fact
(17:43:47) soul9: how are you trying it?
(17:43:59) ***soul9 doesn't have a plan9 auth to test with :-(
(17:44:19) vsrinivas: mount 9 tcp!sources.cs.bell-labs.com!9fs /n/s
(17:44:23) vsrinivas: *i meant -9
(17:44:35) soul9: is this plan9 hosted inferno?
(17:44:38) vsrinivas: auth/feedkey is even asking me for the key from the right domain
(17:44:42) vsrinivas: no, linux-hosted
(17:44:46) soul9: -9 is for plan9 hosted inferno
(17:44:54) vsrinivas: but iirc mount -9 works on linux-hosted too now, i thought
(17:45:02) vsrinivas: (because there is a factotum on inferno)
(17:45:26) soul9: from mount manual: -9 For mount only, and only when hosted on Plan9.
(17:45:38) soul9: bind(1)
(17:45:49) soul9: though tha manpage may definitely be out of date :D
(17:46:03) vsrinivas: right, iirc that was because there was no factotum in inferno at all, it had to use the one from p9
(17:46:19) vsrinivas: i've certainly gotten it to work in the past (~nov 08)
(17:46:21) soul9: theer is factotum tho
(17:46:27) soul9: i did it too, yeah
(17:47:21) j123m [n=j1m@unas-228.rsity.ru] entered the room.
(17:48:46) soul9: vsrinivas: this may help: http://man.cat-v.org/inferno/4/import
(17:49:23) soul9: so you guys tried to compile tip?
(17:49:25) vsrinivas: so sources doesn't allow exportfs, so won't work for that
(17:49:37) vsrinivas: yes, this is from hg two days ago
(17:49:46) vsrinivas: i am using import w/ another cpu server
(17:50:27) soul9: you don't need exportfs, or?
(17:50:32) soul9: i don't exactly understand
(17:50:50) soul9: but if you have factotum it sounds like import should work?
(17:50:52) vsrinivas: no, sources serves 9p, not exportfs 
(17:50:57) vsrinivas: different protocols
(17:51:25) vsrinivas: exportfs is vaguely bizarre, has the ability for client to request filters, requires rc4
(17:51:30) vsrinivas: (iirc)
(17:52:17) soul9: er, i thought it was all just 9p :(
(17:57:33) mjl-: vsrinivas: perhaps you have chars in your password that don't come through right?  i've just authenticated to plan 9...
(17:57:39) mjl-: to sources
(17:57:44) mjl-: with latest inferno sources
(17:57:55) soul9: mjl-: how did you do it?
(17:58:01) mjl-: exportfs' rc4 isn't too strange, is it?
(17:58:09) mjl-: connect to sources you mean?
(17:58:12) soul9: yeah
(17:58:19) soul9: start factotum i guess
(17:58:23) mjl-: soul9: i just did a "mk install" in appl/, and no problems
(17:58:36) soul9: then mount -flag? 'tcp!sources..!9fs' /n/sources?
(17:58:45) mjl-: jups, my lib/wmsetup runs auth/factotum and auth/feedkey
(17:59:06) mjl-: and then it's:  mount -9 net!sources.....!9fs /n/sources
(17:59:23) mjl-: and wait for the feedkey to ask for the pass, enter it, don't hit return but press "done" instead
(17:59:24) mjl-: and i'm done
(17:59:42) soul9: mjl-: why did you decide to use /n/irc/network/n/name instead of /n/irc/network/name/..?
(17:59:44) soul9: ok, cool
(18:00:02) vsrinivas: okay; i'll try again with a fresh inferno tree
(18:00:07) vsrinivas: mine has lots of local patching
(18:00:58) vsrinivas: mjl-: hah, no rc4 isn't strange
(18:01:16) vsrinivas: just that exportfs doesn't allow for negotiation of it iirc; its rc4 or nothing
(18:01:26) mjl-: yeah, well...
(18:02:01) mjl-: i just recently "read" pike's presentation on the good the ugly and whatever (about unix), where he says ssh is stupid for doing encryption algo negotiation
(18:02:27) mjl-: so perhaps that's the mindset behind it
(18:02:37) mjl-: i think that negotiation is good
(18:03:10) vsrinivas: fair. i've wished people would do more neat things with its ability to slam filters in the way
(18:03:22) vsrinivas: the only one p9 can do is aan
(18:03:28) mjl-: soul9: i think it was originally because i thought files couldn't have #'s in them.  but that's not a valid argument (they can, though it might still be confusing with kernel devices)
(18:03:35) vsrinivas: but something like a draw-specific compressor would be cool...
(18:03:38) soul9: hmm
(18:04:08) mjl-: soul9: another reason is that you'ld have to be smart about the files you allow walking too, since irc names are case insensitive...
(18:04:40) mjl-: soul9: btw, the root ctl file now accepts "msg nick|channel the message here" commands too
(18:05:01) soul9: o?
(18:05:11) mjl-: so hopefully the case of wanting to do "echo blah >somenick/data" is covered
(18:05:39) soul9: testing /msg ;)
(18:05:42) soul9: ok
(18:05:46) soul9: yeah, it does :D
(18:05:54) soul9: it'd be nice if it worked from any ctl?
(18:06:20) mjl-: vsrinivas: wouldn't a draw compressor be a bit too application-specific?  eg aan is a relatively generic thing.
(18:06:26) mjl-: i think it works from any ctl
(18:06:47) mjl-: hmm, perhaps it doesn't
(18:06:52) soul9: hey, /msg from #plan9
(18:06:57) soul9: yeah it does
(18:07:07) soul9: at least looks like
(18:07:15) mjl-: sucky, i must have been too lazy to restart ircfs after that change :)
(18:07:24) soul9: i'll do some testing of /msg then, i was doing /join nick for privmsgs
(18:07:28) soul9: hehe
(18:08:10) soul9: mjl-: would it be difficult to make ircfs make a root at /n/irc instead of /n/irc/network (being able to connect to other networks dynamically)
(18:08:19) mjl-: yeah, i don't know why i didn't add /msg earlier.  probably because i was thinking stupid purist thoughts or something...
(18:08:36) ***soul9 thinks that would be a nice project to start learning limbo
(18:08:48) mjl-: soul9: wouldn't a mntgen on /mnt/irc do?
(18:09:16) soul9: no because the exportfs's namespace wouldn't be modified if you mount it afterwards
(18:09:34) soul9: at least that's how i see it
(18:09:38) vsrinivas: mjl-: i was thinking for 9cpu connections to stuff
(18:12:22) mjl-: ok
(18:13:04) mjl-: soul9: btw, your error message for spree, looks like it cannot find your inferno tree.  i'm wondering now how limbo the compiler knows where it is
(18:13:34) mjl-: without ROOT or EMU it works here too.  perhaps it uses the absolute path of the binary and moves up a few dirs for the root?
(18:15:15) mjl-: ok, it's set at compile time it seems
(18:15:34) mjl-: so perhaps you moved your inferno dir and didn't recompile and hadn't set EMU and ROOT?
(18:15:50) mjl-: vsrinivas: i'm wondering what kind of lots of local patching your inferno has :)
(18:17:17) vsrinivas: um, my windows resize like rio...
(18:17:27) vsrinivas: 8i is linked into my native kernels...
(18:17:55) vsrinivas: i don't remember the rest actually
(18:18:27) vsrinivas: oh, it has devtrace
(18:18:43) vsrinivas: and my reed-solomon disk device....
(18:19:06) vsrinivas: and... power64 and sparc64 compilers
(18:19:23) mjl-: ohhh, that's quite a lot
(18:19:27) mjl-: where did 8i come from?
(18:19:38) vsrinivas: rsc's contrib
(18:19:53) vsrinivas: there are lots of other little things all over, more debugging out from stuff
(18:19:53) mjl-: does it work well enough to compile native kernels?
(18:19:56) mjl-: or other native binaries?
(18:19:58) vsrinivas: no
(18:20:09) mjl-: what can 8i do then?
(18:20:11) vsrinivas: i wanted to use it to do vesa's realmode bits
(18:20:18) vsrinivas: without going back to realmode
(18:20:57) mjl-: vesa would be nice
(18:21:14) mjl-: i don't know how hard all that realmode/vesa stuff is.  probably over my head atm :)
(18:21:36) mjl-: and are you using the power64 and sparc64 compilers for anything?
(18:21:49) vsrinivas: no, just they were on google code
(18:21:58) vsrinivas: someday i'd like to do a sparc64 port
(18:22:17) vsrinivas: if i can get some old sun h/w running
(18:22:39) mjl-: would be fun, though probably not terribly useful?
(18:22:48) mjl-: i've got an ultrasparc 5, i think
(18:22:49) vsrinivas: haha, probably. 
(18:23:09) mjl-: if it wouldn't eat too much power, i wouldn't mind having it on.  but i bet it does...
(18:23:29) mjl-: though i'm starting to get interested into these architecture things
(18:23:34) vsrinivas: most of the pieces for a sparc32 port are available
(18:23:41) mjl-: i've read some arm, intel, mips docs recently
(18:23:45) vsrinivas: cforsyth's lx port code has most drivers
(18:23:55) vsrinivas: and the sun4's drew no power
(18:24:05) vsrinivas: and came in tasty lunchbox shapes
(18:24:59) eno [n=eno@nslu2-linux/eno] entered the room.
(18:25:06) mjl-: hah, mine is definately not that.  it's big and heavy instead
(18:25:27) vsrinivas: oh, i was thinking of the lx or ipx
(18:25:58) eno__ left the room (quit: Read error: 104 (Connection reset by peer)).
(18:27:07) mjl-: i'm googling
(18:27:20) mjl-: the boxes are funky
(18:27:51) mjl-: looks like undersized laserprinter
(18:36:16) vsrinivas: way underpowered though
(18:40:47) npe left the room (quit: ).
(19:03:59) soul9: mjl-: noper
(19:04:09) soul9: my inferno tree has been here for a while
(19:04:16) soul9: though there is something queer going on
(19:04:42) soul9: no, actually i seem to have fixed that
(19:05:02) soul9: (one needs to log out of X for env variables to take effect, even in new shells...)
(19:06:18) soul9: (what do you think about ircfs managing multiple networks?)
(19:07:01) mjl-: soul9: the X env vars thing is fixed by putting "*xterm*loginShell: true" in your .Xdefaults
(19:07:04) mjl-: the default is annoying
(19:07:34) mjl-: and for multiple networks, couldn't you just make sure to run mntgen before calling exportfs?
(19:08:09) mjl-: it feels like adding multiple network support in a single ircfs instance is not too useful
(19:08:16) mjl-: well, perhaps a bit useful, but not worth the code
(19:08:39) mjl-: hmm, i think i did change the namespace after having exported
(19:08:46) soul9: er. mntgen doesn't matter here, maybe if you had a process listening in the exportfs namespace or something?
(19:09:04) soul9: listening to connect network or something
(19:09:09) soul9: and starting an ircfs instance
(19:11:51) anothy [i=none@cpe-76-189-197-62.neo.res.rr.com] entered the room.
(19:12:45) mjl-: well, i can modify the namespace at the ircfs side, and the mount-side sees the change
(19:13:00) mjl-: so i can just start another ircfs on the server, and use it on the client with wm/irc
(19:13:01) mjl-: right?
(19:13:08) soul9: oh?
(19:13:31) soul9: ok, i thought the listener forked, but ok, it looks like the exportfs is just run in the main namespace?
(19:13:55) soul9: ok, then you are right, just mkdir /mnt/irc/whatever and start an ircfs instance and restart wm/irc
(19:14:00) mjl-: yes.  but i bet you can change that
(19:14:25) soul9: okey
(19:14:43) soul9: there is an irritating problem with cut/paste :(
(19:14:55) soul9: i don't know, it looks quite non-deterministic :-/
(20:41:44) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(21:24:43) j123m left the room (quit: "Leaving.").
(21:32:16) visof [n=visof@41.238.235.25] entered the room.
(21:36:15) j123m [n=jim@unas-228.rsity.ru] entered the room.
(21:53:58) mjl-: mennis: some time ago you asked about a dis disassembler.  i mentioned disdump, but mdb is more useful
(21:54:19) mjl-: disdump only prints instructions, mdb can dump the other dis file sections too, just like wm/rt
(21:54:41) mjl-: hope you found that despite the pointer to disdump...
(22:00:59) andguent: a dumb question from a inferno noob. why can i resize the main window in acme sac but not on a regular inferno distro? what am i doing wrong?
(22:03:38) mjl-: that's not your fault... that code isn't in inferno-os (yet)
(22:04:39) mjl-: i don't know why it isn't in inferno-os.  seems to be a very useful & desired feature.  and there is code.  perhaps the code isn't polished enough yet or something.
(22:09:10) andguent: ah. okay
(22:09:11) andguent: thanks
(22:10:34) soul9: yeah, there is a bug though, and as i saw he is taking care of merging interesting changes back from acme-sac
(22:15:42) visof left the room (quit: Remote closed the connection).
(22:21:05) mennis: mjl: thanks
(23:11:58) vsrinivas: iirc the acme-sac way resize worked was to allocate a giant screen and expose/deexpose parts of that?
(23:12:10) vsrinivas: (maybe that was drawterm...)
(23:20:14) xjrn: does an ida-pro dialect exist for dis?
(23:21:54) ***xjrn spoiled for disassembly
(23:34:49) uriel: 19:00 < andguent> a dumb question from a inferno noob. why can i resize the main window in acme sac but not on a regular inferno distro? 
(23:34:52) ***uriel cries
(23:35:34) uriel: mjl-: the question is more like: why the hell that was not implemented fifteen fucking years ago?
(23:35:37) mennis: xjrn: you might wan to check out wmdeb
(00:34:55) ***xjrn checks out inferno-os
(00:36:00) xjrn: what i'd love to do is subsitute llvm-gcc on the mac and submit a potential patch, so i can look at the llvm IR 
(00:36:30) xjrn: i remember attempting this for plan9 from userspace but i don't recall the specifics of what happened
(00:40:39) mjl-: xjrn: i recommend you get the snapshot from vitanuova.  that will make life a bit easier:  more (licensed) fonts, it has empty dirs added that got lost in the recent transition to mercurial for vcs
(00:41:01) xjrn: mjl link?
(00:41:28) mjl-: http://www.vitanuova.com/inferno/downloads.html
(00:41:43) mjl-: inferno-20090630.tgz is what you want
(00:42:06) xjrn: hg seems like a distraction.  
(00:42:12) mjl-: it comes with a hg repo in it, so it's a bit big
(00:42:30) mjl-: svn was more of a distraction :)
(00:43:00) mjl-: if you run into problems, have a look at http://www.xs4all.nl/~mechiel/inferno/getting-started.html#installing
(00:43:04) xjrn: google must be so anti-perl that git would've changed too many google assumptions
(00:43:17) mjl-: (you can skip the "file tree" section when in a hurry)
(00:43:53) mjl-: how is perl & git related?
(00:44:04) mjl-: i've been wondering about why they chose mercurial though
(00:44:07) mjl-: i guess they are more of a python shop
(00:44:09) mjl-: at google
(01:00:45) npe left the room (quit: ).
(01:01:21) uriel: 21:43 < mjl-> how is perl & git related?
(01:01:24) uriel: they really aren't
(01:01:59) uriel: some bits of git were / are in perl, but then some are in bash, it is totally irrelevant to the system as a whole, which is written in C
(01:02:38) mjl-: yeah, last time i checked i counted ~100k lines of c
(01:02:48) mjl-: i hadn't considered there might be perl in there as well 
(01:03:14) uriel: still much smaller than svn (and that not counting svn's huge list of retarded dependencies)
(01:03:40) uriel: I'm not sure there is any perl / sh left, they were replacing those bits...
(01:04:17) uriel: the perl / sh stuff was mostly to glue the other bits together, which is surprisingly reasonable
(01:05:03) uriel: (of course, rc would be a much better choice there, but again, it is a rather peripherial issue at best)
(01:05:19) xjrn: linus loves perl, there's a lot of cpan around the edges when you bring it in via source
(01:05:49) xjrn: but guido is a full-timer at google iirc
(01:05:54) uriel: xjrn: linus loves perl? oh dear, your disinformation reaches new levels?
(01:06:35) uriel: guido's work at google has nothing to do with it, python has been one of the three google languages for ages, long before guido was hired (ie., you got cause -> effect backwards)
(01:07:02) soul9: looks like git-1.6.3.1 only depends on perl as optional feature
(01:07:09) uriel: linus loves C, and thank god for it, it is one of the few redeeming aspects of linux
(01:07:13) soul9: (just checked the ebuild)
(01:08:11) uriel: (there are plenty of morons that would like linux to add c++ code into the kernel, linus would rather die than allow it, thank god)
(01:09:02) uriel: linus also *in principle* (but certainly not in practice) advocates rather sane C practices: avoid the preprocessor, gotos are considered acceptable and useful, etc..
(01:09:22) uriel: of course, they fail miserably to follow their own advice
(01:09:44) te left the room (quit: "leaving").
(01:10:01) te [i=tao@gateway/shell/blinkenshell.org/session] entered the room.
(01:13:47) xjrn: yeah i use darwinports and gentoo alot, anything useful brings in cpan
(01:14:13) uriel: cpan, talk about diseases...
(01:15:15) uriel: perl at least is funny, when a project starts pulling from cpan you know the thread will end in pain and missery
(01:17:03) soul9: oh yeah, you really need to package cpan stuff separately, cpan is a huge fail in itself, not even talking about perl
(01:18:01) xjrn: on gentoo it creeps in with the +svn USE flag, which in turn kicks off a brand spanking new APR dependancy chain which will set you back a half hour building apache and avoiding stomapge
(01:18:53) xjrn: i think gentoo portage tries to take credit for cpan and java jar files and other such brittle silliness, svn must die.
(01:22:16) soul9: oh, svn is a bitch!
(01:22:31) soul9: i disabled most of the irritating dependencies though, that was a huge win
(01:25:20) xjrn: it's really dissapointing when you have a box that's been running for 3 years, and you attempt a small svn fix and find out you can't access a 1.5 repo 
(01:26:12) xjrn: is there by chance a working es port in inferno/plan9 right now?
(01:26:15) xjrn: i miss it so
(01:26:49) xjrn: i see rc syntax i haven't seen in  adecade or more in this build faq
(01:30:20) xjrn: so these instructions specify to use ARCH but its niether in my env nor in mkconfig.  is it implicit?
(01:34:13) xjrn: found it
(01:35:59) uriel: 22:18 < xjrn> i think gentoo portage tries to take credit for cpan and java jar files and other such brittle silliness, svn must die.
(01:36:02) uriel: 22:21 < soul9> oh, svn is a bitch!
(01:36:06) uriel: wow, something we all three agree on?
(01:36:08) uriel: this can't be!
(01:36:31) ***uriel hate for svn is visceral
(01:37:17) uriel: almost quit a job because they insisted on using svn (ended up quiting for other reasons, but the people pushing to switch to svn were driving me fucking nuts)
(01:57:30) xjrn: this PATH=$(dirname $CC):/usr/local/inferno/MacOSX/386/bin/:/usr/local/inferno/utils/iyacc/:$PATH mk nuke all
(01:57:40) xjrn: begets sr/local/inferno/libinterp/runt.h:4215: warning: missing '(' after '#pragma pack' - ignored
(01:57:42) xjrn:  /bin/sh ../port/mkdevc emu > emu.c
(01:57:43) xjrn: (cd /usr/local/inferno/libinterp.a /usr/local/inferno/MacOSX/386/lib/libtk.a /usr/local/inferno/MacOSX/386/lib/libfreetype.a /usr/local/inferno/MacOSX/386/lib/libmath.a /usr/local/inferno/MacOSX/386/lib/libdraw.a /usr/local/inferno/MacOSX/386/lib/libmemlayer.a /usr/local/inferno/MacOSX/386/lib/libmemdraw.a /usr/local/inferno/MacOSX/386/lib/libkeyring.a /usr/local/inferno/MacOSX/386/lib/libsec.a /u
(01:57:45) xjrn: sr/local/inferno/MacOSX/386/lib/libmp.a /usr/local/inferno/MacOSX/386/lib/lib9 ; mk SHELLTYPE=sh SYSTARG=MacOSX OBJTYPE=386 install)
(01:57:46) xjrn: sh: line 2: cd: /usr/local/inferno/libinterp.a: No such file or directory
(01:57:48) xjrn: mk:  echo "(cd ...  : exit status=exit(1)
(01:57:49) xjrn: mk:  for i ...  : exit status=exit(1)
(01:57:51) xjrn: mk: echo "(cd $SYSTARG; ...  : exit status=exit(1)
(01:57:53) xjrn: mk: for j in ...  : exit status=exit(1)
(01:57:54) xjrn: #516$16 Thu 09073015:56:38 jim@bframe4:/usr/local/inferno
(02:01:20) xjrn: ahh mk nuke install was the trick
(02:05:15) xjrn: where do i find the make/mk vars that control $CC ?
(02:09:14) xjrn: found ./mkfiles/mkfile-MacOSX-386.  let's see if we can jit this thing..
(02:12:57) mennis left the room (quit: Client Quit).
(02:47:40) mennis [n=mennis@adsl-223-61-173.aep.bellsouth.net] entered the room.
(02:54:03) mennis left the room (quit: Client Quit).
(03:04:39) mennis [n=mennis@adsl-223-61-173.aep.bellsouth.net] entered the room.
(03:07:31) mennis left the room (quit: Client Quit).
(03:51:46) eno__ [n=eno@adsl-70-137-148-131.dsl.snfc21.sbcglobal.net] entered the room.
(03:52:48) eno left the room (quit: Read error: 104 (Connection reset by peer)).
(04:47:32) vsrinivas: uriel: 'avoid the preprocessor'? 
(04:47:43) vsrinivas: seen container_of or list_for_each_safe?
(04:48:09) vsrinivas: (they're actually kinda nice, to be fair)
(04:58:12) anothy: xjrn: no es for plan9 or inferno. it'd be fun to play with; i eagerly await your results. ☺
(05:16:29) xjrn: anothy: i gave up es and took to bash when i didn't wish to deal with job control 
(05:16:29) anothy: oh, lord. any sentence of the form "i gave up <something less bad than genital mutilation> for bash" makes me cry.
(05:22:22) xjrn: well, here's a little secret, bash is an es ripoff.  
(05:24:18) mennis [n=mennis@adsl-223-61-173.aep.bellsouth.net] entered the room.
(05:30:06) xjrn: i can't demonstrate a working jit'd 'mk',   best i can accpomlish with llvm-gcc for now would be to benchmark the llvm-gcc -O9 binaries vs. 'cc' binaries
(05:30:06) xjrn: jit binaries take the form of a shell script (mk) and .bc (mk.bc) 
(05:31:40) mennis left the room (quit: Client Quit).
(06:16:52) underspecified left the room (quit: ).
(06:51:13) visof [n=visof@41.238.233.57] entered the room.
(07:37:22) eno__ left the room (quit: Read error: 104 (Connection reset by peer)).
(07:42:20) eno [n=eno@nslu2-linux/eno] entered the room.
(07:54:37) visof left the room (quit: Remote closed the connection).
(08:01:17) xjrn: here's where the llvm build ends -- main()  is not found.  i went in once already and changed main to retur int, but no luck that way either. http://pastebin.ca/1513237
(08:02:04) xjrn:  it's even less verbose failure when running the llvm native binaries, i dont think i've had a successful native build of mk thus far.
(08:02:17) xjrn: with gcc it all works, naturally.
(08:24:00) underspecified [n=eric@walnut.naist.jp] entered the room.
(08:37:49) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(09:09:11) xjrn: pparently someone int he llvm world has noticed plan 9 C as some distinctive entity, but im not sure that means i don't have the results of the frequently hosed apple installations that dont serve XCode speciically
(09:10:22) xjrn: if the llvmdev newsleeter has some pointers maybe i'll come back to this.
(09:11:11) xjrn: im too not paid to slog through a clang install at this moment.  
(09:13:35) j123m left the room.
(10:05:04) npe left the room (quit: ).
(10:11:05) j123m [n=j1m@unas-228.rsity.ru] entered the room.
(10:31:21) mjl-: xjrn: and llvm does something different on "plan 9" code even if just compiled with gcc?
(10:31:47) mjl-: i would expect that inferno just makes it all look like unix c, so it can compiler on unix'es
(10:33:57) xjrn: no its more of a matter of having 2 or 3 different competing versions of llvm woven into mac development. XCode, and the IPhone dev kit deliver a sort of chopchop llvm that's used to build the OS, but has no jit facilities.  the only linker that is reliable is the linker from this toolkit.  then, you have to go and buildyour own llvm-gcc tree and llvm toolchain, with 2-3 years newer sources,...
(10:33:59) xjrn: ...and rely on the system linker which is not open source.   blah, too many permutations to wrry about for one night.  
(10:34:04) mjl-: xjrn: you could try the simplest of programs built with the inferno infrastructure, utils/cat/cat.c
(10:34:38) xjrn: and because clang is in active development, llvm-gcc-4.2 is more or less in dont-fix ticket mode
(10:34:47) npe [n=npe@195.207.5.2] entered the room.
(10:35:02) mjl-: ok, sounds like lots of things to go wrong :)
(10:35:36) xjrn: wheni do jit copmilation on linux, i get stuck inodes which wait until reboot, and any process that puts a lock on it also blocks til reboot.  i have no idea how
(10:36:05) xjrn: does it help if i say everything worked swimmingly 2 years ago?
(10:36:43) xjrn: that small feature took oiut my reiser4fs ricer system :)
(10:39:17) xjrn: what's probably not a conceptual leap is to backend limbo on hlvm which is a ... AST kit.  can Dis boil down to an AST at any level?
(10:41:09) xjrn: i asked in #llvm, the model of ir generation is also one of 'infinite registers', so it seems like either by AST or instruction-set, if not by C copmilation, it's doable a number of ways
(10:41:33) xjrn: (it is btw)
(10:44:44) xjrn: i presume there's a Dis "as" syntax 
(10:45:33) mjl-: there is such a thing yes
(10:45:45) mjl-: try disdump
(10:46:52) mjl-: that only gives the dis instructions.  a dis file also contains other sections, link, modules, exception handling, descriptors.  they can be dumped using mdb.  e.g. mdb /dis/ls.dis '$l' with l for link.  mdb(1) lists the other commands
(10:47:19) xjrn: so the AST of Dis would be about 2 levels, deep tops ?
(10:47:22) mjl-: i don't know if you can put dis into some kind of ast thing that you need.  wish i knew enough about that
(10:47:53) mjl-: would that be related to the levels of indirection?  then yes
(10:48:07) xjrn: any syntax that represents the instructions once parsed is feasable as an AST
(10:48:17) uriel: 01:47 < vsrinivas> uriel: 'avoid the preprocessor'?
(10:48:17) uriel: 01:47 < vsrinivas> seen container_of or list_for_each_safe?
(10:48:26) uriel: vsrinivas: as I said, they don't really follow their own advice
(10:49:54) xjrn: llvm is good, for instance, there's rumor that python implemented on hlvm for GSOC was faster than native... but for political reasons it was dismantled 
(10:52:48) mjl-: hah
(10:52:50) xjrn: but i can't recall anything besides the iPhone that is significantly benefitting from it -- most projects that endorse llvm seems to unendorse it 
(10:53:03) mjl-: google is quite busy making pythong faster, right?
(10:53:13) mjl-: that unladen-swallow project
(10:53:17) mjl-: (what does that name mean!?)
(10:53:33) mjl-: xjrn: do you know how it's used in the iphone?
(10:53:49) mjl-: i thought llvm was also used by apple to speed up opengl implementations with partial hardware support?
(10:54:15) xjrn: it is the ARM copmiler, period.  llvm got inducted into apple as its driver layer for opengl bindings, as i understand, and was the gcc ARM port with apple extensions 
(10:55:49) mjl-: ah, one more reason to one day look into llvm :)
(10:57:08) xjrn: ah right, i guess unladen swallow is the python thing
(10:57:54) xjrn: I don't know if google V8 was creditted to hlvm but i am pretty sure i remember the google folks working on javascript a while before chrome was released.
(10:58:05) uriel: xjrn: I have no clue what 'political reasons' you are talking about, the google people (I would expect with guido's blessing) are working on using llvm to jit pyton
(10:58:14) uriel: (whatever this a good or a bad thing, is questionable)
(11:03:43) xjrn: looks like V8 makes no mention of llvm.  
(11:05:44) xjrn: === nlewycky: member of +#llvm  
(11:05:50) xjrn: member of the V8 team
(11:33:17) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(11:54:01) underspecified left the room (quit: ).
(12:04:20) underspecified [n=eric@walnut.naist.jp] entered the room.
(13:01:43) eno left the room (quit: Read error: 104 (Connection reset by peer)).
(13:05:59) eno [n=eno@nslu2-linux/eno] entered the room.
(13:27:53) underspecified left the room (quit: ).
(13:29:14) underspecified [n=eric@walnut.naist.jp] entered the room.
(13:45:30) j123m left the room (quit: "Leaving.").