Index

Show enters and exits. Hide enters and exits.

00:00:25brixenvm/oop.hpp rather
00:04:03wycatsevan: any ideas?
00:05:42ruewycats: Needs a guard...can you check if there is an ifndef on top of functional_hash.h?
00:06:17wycatsI don't see a functional_hash.h
00:06:30rueSorry, this one /usr/include/c++/4.2.1/tr1/functional_hash.h
00:06:51wycatsI see:
00:06:52wycats#ifndef _TR1_FUNCTIONAL_HASH_H
00:06:52wycats#define _TR1_FUNCTIONAL_HASH_H 1
00:09:30rueActually, there probably is a top-level TR1 somewhere, but at least that define can be used in the profiler.hpp guard
00:11:04rueYay, apparently there is no standard way to detect TR1.
00:11:25rue4.3 has #define __GXX_EXPERIMENTAL_CXX0X__ 1
00:11:31rue(Apparently)
00:13:33ruewycats: So, if you change the guard in profiler.hpp:26 to `ifndef _TR1_FUNCTIONAL_HASH_H`, it should get past that...obviously the mechanism could be slightly improved
00:14:51rueyakischloba: Does it build if you add brixen's definition? If not, pastie up what you get
00:16:17yakischlobajust a se
00:16:20yakischlobac
00:16:22yakischlobawas away
00:16:25wycatsI'll try #if (__GNUC__ <= 4 && __GNUC_MINOR__ <= 2 && __GNUC_PATCHLEVEL__ < 1) again
00:16:34wycatsI recloned
00:24:36wycatsit built
00:24:43wycatscan I push that change?
00:25:56evansure
00:27:25boyscoutUpdate conditional to match Snow Leopard's g++ correctly - edcf921 - Yehuda Katz
00:27:47brixensnow leopard in da haus, yo
00:29:07rueThe TR1 files may not be present at all 4.2.1+, but the problem needs a wider solution anyway
00:31:02boyscoutCI: edcf921 success. 2723 files, 10829 examples, 33851 expectations, 0 failures, 0 errors
00:31:03yakischlobai get this now
00:31:04yakischlobavm/marshal.cpp:80:6: error: missing binary operator before token "("
00:31:51evanodd.
00:32:04evanah
00:32:08evanthat damn WORDSIZE
00:32:23yakischloba:)
00:33:57evani wasn't following before
00:34:03evani guess you don't have __WORDSIZE ?
00:34:06yakischlobacorrect
00:34:29evanremove that code
00:34:31evanand put in
00:34:41evanif(sizeof(long) > sizeof(int))
00:34:46evanas a normal C condition
00:34:53evanor
00:34:59evanif(sizeof(long) == 8)
00:35:08evanthats more accurate anyway
00:35:45yakischlobaok
00:35:55yakischlobaheh
00:35:58yakischlobait is in other places too
00:36:06evanjust do that everywheres
00:36:12yakischlobaok.
00:39:07yakischlobavm/marshal.cpp:84: warning: right shift count >= width of type
00:39:31evanumm
00:39:38evanyour condition is wrong
00:39:49evanit's running when you're on a 32bit machine
00:39:53evanit should not
00:40:34yakischlobathis is something the compiler would notice?
00:50:09rueYes
00:55:15yakischlobaok. i copied and pasted the condition
01:02:49rueCopied where?
01:03:23yakischlobato where evan instructed me to, replacing the original #if (__WORDSIZE != 64)/#endif
01:04:07yakischlobaerr
01:05:03rueYeah, the compiler might complain since it sees it now
01:05:12yakischlobayeah
01:05:14rueThe code should never get executed on your system, though
01:07:23yakischlobahow can i build without warnings then
01:07:28yakischlobawithout warn=fail
01:16:07rueYeah, good question, the better option would be to use a #define
01:18:13rueYou can suppress the particular warning, too. Temporarily, to see if it builds otherwise you might just drop the -Werror from rakelib/vm.rake
01:18:50rueFor former, google for warning suppression for shift, or bit ops, or ints etc.
01:22:05yakischlobaok well
01:22:27yakischlobai can get it to build. it would be sweet if a 'solution' was found though. i cant be the first person that has tried to build on tiger
01:22:51evanyou're the first one in a while
01:22:55evanwhats your diff look like?
01:23:00yakischlobawell
01:23:03yakischlobaim building with -Werror
01:23:10yakischlobawithout rather
01:23:13evanoh
01:23:19evanthats not a solution
01:23:30yakischlobacorrect
01:23:36evanthat code is probably not working right for you then
01:24:23yakischlobawhy? the compiler complains about it but it should never take that path
01:24:28yakischlobaunless i dont understand how it works
01:24:50evanah
01:24:50evani see
01:33:23rueevan: It is just the compiler seeing it insofar as estimate
01:33:58rueWith a #define it is 'not there' at all, so that is definitely the better way to go
01:34:15rueI could swear that we had a bit of C for wordsize detection
01:35:51evanright
01:35:53evanyeah, so did I
01:36:46rueShotgun might have it, it was a config script
01:37:12evanyeah
01:46:08yakischlobachecking _LP64 has been suggested
03:10:42evanhuzzah!
03:10:46evangeneric method inlining!
03:13:19lstollsweet!
03:40:29slavanice evan
03:46:26evantotal = 100000000
03:46:33evanhot loop: 9.1s
03:46:55evandef bar; 1 + 1; end; def foo(a) a + bar; end
03:47:03evaninterpreter: 21s
03:47:18evanjit, no inlining: 18.4s
03:47:37evanjit, inlining: 15.2s
03:47:53evanmaking good progress!
03:48:06evanthe runtime frame info in the inlined methods is giant
03:48:11evanneed to figure out how to reduce it
03:50:58slavagangsta
03:59:36slavaevan: does 1 + 1 get folded into a constant?
04:20:36rueevan: What is left in the frame?
04:49:33yakischlobaseems commit by wycats earlier breaks my build http://pastie.org/private/uxpnyy8yztenjxjij2q
05:10:52yakischlobabrixen: so this ""bin/mspec tag --list fails core" you gave me earlier, this shows all the things that need to be worked on?
05:36:39evanslava: yes, 1 + 1 is folded into 2
05:38:14evanrue: a CallFrame and StackVariables
05:38:21evanLLVM already folds it away, when it can
06:10:03brixenyakischloba: that show rubyspec failures in the core specs
06:10:10brixener shows*
06:10:34brixenevan: awesome on the generic inlining!
06:10:57evanyeah! still debugging it a bit
06:13:34yakischlobaok
07:46:40brixenwycats: what's the gcc version on snow leopard?
07:46:53brixensnl should be the abbr for snow leopard
07:47:52wycatsbrixen: 4.2.1
07:48:05brixenhmm
07:48:17brixenyour patch breaks for 4.0.1
07:48:27brixenbreaks the build for* rather
07:49:56brixenI think __GNUC_MINOR__ < 2 should be ok
07:50:23brixenleave the PL part off
07:50:38brixenwycats: could you try that
07:50:40brixen?
07:51:01brixenIOW #if (__GNUC__ <= 4 && __GNUC_MINOR__ < 2)
07:56:00wycatsbrixen: /me checks
07:56:08wycatsbrixen: I followed evan's instructions
07:56:13wycatsdo I rake clean?
07:56:16wycatsrake distclean?
07:56:27brixenum..
07:56:35brixenjust touch vm/primitives.cpp
07:56:38brixenand rake build
07:56:39wycatsah
07:56:40wycatscool
07:57:52wycatschecks
07:59:24dbussinkbrixen: it's almost the same gcc as the 4.2.1 that is provided on leopard
07:59:38wycatsit seems to have worked
07:59:40dbussinkbrixen: they just switched the default on snow leopard, it also still has 4.0.1
07:59:56brixendbussink: cool
08:00:05brixenwycats: could you push that, please
08:01:27dbussinkbrixen: evan could also reproduce that issue on show leopard with gcc 4.2 on leopard, so that makes life a bit easier
08:02:09brixendbussink: you mean the stack issue?
08:02:20dbussinkbrixen: yeah, with the rotate instruction
08:02:34brixenI thought he fixed that?
08:02:34dbussinkbrixen: that gcc 4.2.1 probably wrongly optimized
08:02:48dbussinkbrixen: yeah, by using 4.2 on leopard, the issue was the same on snow leopard
08:02:54brixenok
08:03:17brixenthis is just about tr1/unordered_map
08:03:20brixenand version #s
08:03:54wycatsbrixen: yep
08:04:07brixenif someone is using 4.2.0 and it doesn't have a default hash, we'll revisit the guard
08:04:10brixenwycats: thanks
08:04:18dbussinki wonder if it shouldn't just be GNUC_MINOR < 2, dunno if 4.2.0 is still commonly used / etc
08:04:20dbussinkbrixen: hehe :)
08:04:34brixendbussink: yeah, that's what wycats just checked
08:04:43brixendbussink: great minds :)
08:05:51dbussinkbrixen: btw, that original stack issue evan fixed didn't appear to happen with other gcc 4.2 releases, so it was probably a bug they already fixed but apple didn't backport
08:06:23brixeninteresting
08:06:29wycatsweird... not pushing
08:06:37wycatsit claims to be up to date but hasn't pushed
08:06:49brixenhmm
08:07:34dbussinkwycats: i have the commit here
08:07:56dbussinkwycats: be9e1e641
08:08:14brixenyep, me too
08:08:19wycatsyep
08:08:23wycatsbut it doesn't seem to be on github
08:08:29wycatshttp://github.com/evanphx/rubinius/commits/master
08:08:38wycatsand it didn't pop in here
08:08:41dbussinkwycats: i've seen the web interface being slow lately more often
08:08:46wycatsweird
08:08:46brixengh is probably just behind
08:08:49wycatsseems good :)
08:25:50dbussinkbrixen: how can i do a ci run with the jit enabled?
08:30:57brixendbussink: bin/mspec ci -T -Xjit.enabled
08:31:04brixenadd -B full if you want the full CI
08:31:16dbussinkbrixen: ah ok, thnx
08:31:22brixennp
08:37:04dbussinkbrixen: hmm, i'm getting consistently longer runs for jit.enabled than without
08:37:40dbussinkbrixen: around 72 with jit enabled for full mspec, around 55 when disabled
08:41:58brixendbussink: on linux or os x?
08:42:07dbussinkbrixen: os x leopard
08:42:29brixenodd
11:16:04morris2hi. do you think phusion passenger might be able to run with rubinius?
12:16:46morris1http://www.infoq.com/news/2008/01/rubinius-multi-vm should this still work?
12:27:44morris1or how is Rubinius::VM.new to be used?
12:46:00morris1because i get this: http://pastie.org/533069
12:46:11morris1it seems that machine_new is not defined in the vm source
12:46:46morris1grep could find it ONLY in kernel/bootstrap/vm.rb
12:47:03morris1so the error message makes sense
12:48:54morris1same with join, get/send_message
12:49:43morris1maybe it has been removed from rubinius... the news is early 2008 after all... but why?
12:49:52morris1evan: can you help me out on this?
13:13:25morris1anybody :/?
15:10:10morris1can anybody give me info about the current state of development of multi-VMs in rubinius?
15:10:18morris1or sub-VMs
16:47:05ruemorris1: He is PDT, so probably just getting up now-ish.
16:47:47morris1thought so
16:47:59ruemorris1: And no, MVM does not currently work; I do not think there have been any attempts, even.
16:48:21morris1so it once worked and was abandoned... or later?
16:48:25morris1*for
16:48:56rueNot so much abandoned, just not "ported" over to the new infra
16:49:16morris1hm okay
16:49:18rueThere is a fairly significant amount of rework needed from the earlier scheme
16:49:19morris1thanks!
16:49:23rueSure
16:49:29rueDid you have a particular use case?
16:50:07ruedbussink: Yes, the past month or so the interpreter has been distinctly faster
16:50:48ruedbussink: I think the most recent stuff may have changed that, I have not tried...the specs are just not a good fit for JIT
16:50:57morris1rue: web app... different scripts... different "namespaces"... sandboxing... etc.
16:51:05morris1i can go on for hours :D
16:51:32morris1e.g. multiple merb apps in one rubinius/rack instance
16:52:08morris1user written ruby code that doesnt modify the running environment
16:52:19morris1without starting a new ruby/rbx instance of course
16:53:33morris1i wouldn't necessarily need an own native thread, only the sandboxing and seperation of code spaces is important for me
16:56:04morris1it seems that rubinius is closer to achieving this kind of thing than 1.9 with yarv is... plus the rubinius internals are WAY more accessible for other devs than 1.9's
16:56:24rueYes, it is definitely easier to get around
16:56:49rueThe MVM stuff we had did not really address sandboxing at all, it is sort of an orthogonal concern
17:01:29morris1by sandboxing i essentially mean seperation of code spaces.. like this: http://pastie.org/533350
17:03:03rueMm, there are several approaches to that
17:03:34morris1i couldnt find any that worked
17:03:38rueBut, yes, a VM that maintains its own runtime is not affected
17:04:40morris1can you give an example of an approach that could solve this?
17:05:30rueTo me, sandboxing has distinctly the connotation of security concerns, but it can be used more widely to indicate independent execution units with possibly limited access to the outside world
17:05:56ruemorris1: Currently in Ruby? You would have to hack around it
17:06:08rueSelector namespaces is one of the more common suggestions
17:08:14morris1then sandboxing is quite the wrong word, i just picked it up from why's freaky sandbox which does the very thing i need... but it doesnt work for 1.9 so i cant use it
17:09:09morris1i couldnt find a way to hack around that with only ruby... i mean, there's a lot of stuff that has to be secured
17:09:17morris1classes, modules, methods, globals, constants
17:09:39morris1and then hiding that properly is tedious, i suppose
17:13:31morris1i mean it is probably tractable... since ruby provides all you need for full reflection
17:14:06morris1but it's a massive hack and MVMs would take care of this quite nicely
17:17:41rue_why's sandbox does protect the process, too.
17:19:39morris1yeah sure, sandbox is wrong in my case
17:27:49morris1still that hack is going to be tough
17:27:59morris1i'll try and report back
17:28:52wycatsI'm getting a segfault when I try to run rails -h
17:29:04wycatshttp://gist.github.com/140210
17:30:10ruewycats: I knew Rails was a memory hog... ;)
17:30:41wycatshehe
17:32:13rueThat is 2**64
17:33:09ruewycats: You are running 64-bit, I assume?
17:36:08rueWhat does GDB say, is that from libffi?
17:39:55rueAh, `int system_size_` :/
18:07:39rueYeah, that fix from yesterday fails on my 4.2.1
18:08:02wycatsrue: I am
18:08:08wycatsrunning 64 bit that is
18:10:41ruewycats: You able to hit it with GDB? Just set the malloc_error_break bp and get the backtrace
18:11:31rueThe incorrect type for system_size_ in immix is suspicious, but it has to be overstepping if that is the case, so it could be from somewhere else too
18:40:45wycatsrue: not really proficient in gdb :(
19:13:33ruewycats: Do `$ gdb bin/rbx`, then in the gdb shell: `b malloc_error_break`, then `r -S rails -h`
19:14:10rueWhen it tells you it has hit the breakpoint, typing `bt` will print out the backtrace
19:40:14wycatsbin/rbx works
19:40:19wycatsI think
19:40:27wycatsit's bin/rbx -S rails -h
19:40:34wycatsah
19:40:36wycatsI follow now
19:40:55wycatsrue: still here?
19:50:34ruewycats: Yeah
19:50:42rueFighting JS
19:50:45wycatsha
19:50:56wycatsI got a breakpoint
19:50:58rueYes, the r is to run the binary, with the supplied options
19:51:10wycatsso now I got it
19:51:11wycatswhat now?
19:51:13wycatsbt?
19:51:33wycatswhoa it took a while to generate the bt
19:52:15wycatshttp://gist.github.com/140260
19:52:23wycatsrue: what js problem are you having
19:52:28wycatsI know a thing or two about that :P
19:53:03ddubwycats: you know javascript?
19:53:19ddub:)
19:54:02ddubthats a lot of bytes
19:54:48ruewycats: Trying to see if I can run my dashboard widget
19:54:54rueOn the web, that is
19:55:26wycatsddub: I do
19:55:37wycatsddub: I'm on the jQuery team :)
19:58:45ddubwycats: developing a love for ruby has helped me cope with my distaste for javascript
19:59:12ddubI worked at a company in a past life where we had a 30k+ line javascript IM client
19:59:15wycatsddub: I like JS :)
19:59:22wycatsddub: I would dislike that as well
19:59:44wycatsthat sounds bizarre at best
19:59:44ddubnothing like finding typos in code reviews, hidden by lack of coverage in the test suite :)
20:00:12ddubI didn't maintain it, just got brought in for reviews
20:01:25ddubjquery is quite smart though
20:01:30ddubI'm a fan
20:02:19ddubI have a tendancy to do backend work, so I haven't had a chance to really work on my JS skills
20:02:56ddubI made a google gadget about four months ago, and that was about it. And that was mighty painful, but I blame google for that
20:03:05rueHehe
20:03:07rue // HM. This is pretty dangerous. Should we figure out how to
20:03:32ddubend of comment?
20:04:03rueI think the writer died
20:04:14ruewycats: Do you still have the GDB session up?
20:06:09ddubis wondering how to script a massive flac -> apple lossless conversion
20:07:39rueApplescript!
20:08:26ddubI think I would need some applescripty way to load the flac data
20:09:50ddubwycats: anything going on around your comments on 'gem' packaging/invokation?
20:14:52wycatsrue: I do
20:18:34ruewycats: Try `f 14` (to move to the problematic frame), then `p a0`
20:18:52rueCould also try to p call_frame and msg
20:20:25ddubgah, I found a nice drag and drop tool to convert things, but for some reason when itunes imports the file it does not detect the metadata
20:20:34ddub(finder get info and quicktime both do)
20:22:57wycats$1 = <value temporarily unavailable, due to optimizations>
20:23:12wycats(gdb) p call_frame
20:23:13wycats$2 = (class rubinius::CallFrame *) 0x7fff5fbed350
20:23:17wycats(gdb) msg
20:23:24wycatsUndefined command: "msg". Try "help".
20:24:29ruewycats: `p *call_frame`, `p msg`
20:26:50wycatshttp://gist.github.com/140275
20:32:00rueWow, this was exceptionally stupid of me
20:32:04radarekhttp://pastie.org/533555
20:32:11radarekI have many failing tests
20:34:39wycatsrue: any further ideas?
20:34:41ruewycats: So p lets you inspect the C(++) side...you can try to get a bit deeper; first, `p __printbt__(call_frame)`
20:35:18ruewycats: You can try to poke at individual objects with __show__(), too, e.g. `p __show__(msg.name)`
20:36:05rueYou might end up needing to cast etc., and looks like you have a "release" build so it will probably cut you short at that point
20:36:36wycats:(
20:36:41wycatsnoob wycats
20:43:04rueHeh
20:43:47rueSee if you get anywhere; the problem often is that there is corrupt data in the stack somewhere, crashing GDB when it tries to execute whatever it is
20:43:53rueIn this case, might get lucky
20:45:32radarekrue: if I build rubinius with llvm support then do I have to use some options to enable it or it is enabled all the time?
20:45:45radarekI remembed something like -Xjit...
20:45:52radarek*remember
20:45:55wycatsrue: can you possibly reproduce?
20:49:19ruewycats: Nothing running 64 right now
20:49:48rueIt should be solvable, got a decent gauge on the issue
20:49:53rueradarek: -Xjit.enabled
20:50:06rueAnd build with RBX_LLVM=1 still, yes
20:50:17radarekrue: ok, thank you
20:50:43rueradarek: Try -Xconfig.show (or .print maybe?) too
20:50:57radarekrue: it was quick ball: Segmentation fault
20:50:58radarek:)
20:51:10rueEwp
20:51:43wycatsrue: :(
20:51:49wycatsI'll figure this out tomorrow
20:52:48ruewycats: Well, if it makes you feel better, I spent *entirely* too long on this: http://journal.kittensoft.org/decimaltime.html
21:05:05evanwycats: if you can
21:05:12evango to a frame with the call_frame in it
21:05:13evanand do
21:05:18evanp call_frame->print_backtrace(state)
21:05:28evani doubt that will give us much new info
21:05:38evanbut it's worth a try
21:07:52rueevan: Think that failed (__printbt__)
21:08:17evanoh? hm.
21:08:37evanwell, clearly 18billiontrillion bytes isn't the correct size
21:08:54rueNo, it is very likely that it is not
21:09:39evanI see my // Hm.
21:09:41rueevan: Does fixing system_size_ to a size_t in util/immix.hpp cascade problems?
21:09:42evanhas come to pass!
21:10:07evanno
21:10:26rueOkaydoke
21:10:26evansystem_size_ is never more than about 4k
21:10:37evanthats just the number of bytes in a chunk
21:10:55evaner, not 4k
21:11:02evan1M
21:11:04evanbut still
21:11:13evanthat size is there because it wiggles
21:11:16rue32k + 1024^2
21:11:28evanso that the start is properly aligned
21:11:30evanwhere do you get that?
21:11:41evancChunkSize is 1024 * 1024
21:12:03ruecBlockSize
21:13:06rueIt _is_ unlikely to cause issues, but there are no explicit checks that it remains positive, I think
21:13:16rueI did not look terribly closely
21:13:47evanthe largest it could be is cChunkSize + cBlockSize
21:13:54evanso it's fine
21:14:24rueIs it ever validly negative?
21:14:42wycatshey evan
21:14:49wycatsI'm having a segfault running rails -h
21:14:58wycatsfrom rue: http://gist.github.com/140275
21:15:16rue'S no point keeping it int if mmap wants a size_t and it should never go below 0 anyway
21:15:18wycatshttp://gist.github.com/140260
21:15:39rueI can fixeroo, but I have to muster the motivation to figure out a good fix to this TR1 crap
21:16:09evanwycats: yes, i looked back
21:16:11evani'm aware
21:16:19evanrue: how could it be negative?
21:16:43wycatsevan: any thoughts?
21:16:52wycatsI'm not good enough with gdb to investigate this myself :(
21:16:53evanchanging to size_t simply means that a bug that would result in a negative number now results in a giant number
21:16:56evanboth of which are wrong.
21:17:30evanrue: it's fine the way it is.
21:17:32ruewycats: If you still have GDB running where you left it, try `p __printbt__(call_frame)`
21:17:34evanthats not the source of this bug.
21:17:44rueevan: Obviously not
21:18:02rueevan: But my point, exactly, is that "how could it be negative?" -- why is it a signed type?
21:18:35evanbecause i didn't make it unsigned
21:18:39evanno other reason
21:18:55evanso sure, from the code communication perspective, it should be a size_t
21:19:01evanbut it's got no barring on running code
21:19:08evanzilch
21:19:24rueThat we foresee, no, nor this particular issue
21:19:44evani can see 100% of the places it's set
21:19:56evanand 100% of them result in 1 of 2 values
21:20:01evanboth are simple, positive values
21:20:03rueI merely asked because I cannot run to find out if changing it would cause other problems, since I had run into it looking for mmap usage.
21:20:13evanoh?
21:20:19evanyou had an mmap issue?
21:20:28evanmaybe i'm missing details on this
21:20:46ruewycats' original segfault is from the mmap for the thrillierbillier bytes
21:21:04evanright
21:21:06rueSo I was looking at mmap usage 'til he got a bt
21:21:10evanbut these are 2 entirely unrelated issues, yes?
21:21:45rueYes. The only reason I asked is because there may have been some reason for it to be signed that I was overlooking
21:22:04evannope
21:22:11wycatsrue: when I did what you asked I got a lot of output
21:22:14wycatsis that expected?
21:22:14evanlets put this on the back burner
21:22:19evanand see if we can assist wycats.
21:22:29evanwycats: yes
21:22:32ruewycats: Yep, pastie up
21:22:33evanwycats: we need the ruby backtrace
21:22:35wycatshttp://gist.github.com/140290
21:22:45wycatsthere you go
21:23:10wycatsevan: I don't mean to be a pain... just figure that if I'm getting a segfault it's not just me
21:23:18wycatsI recloned and rebuilt from scratch last night
21:23:59rueIt is 84.990 hours, so I am having tea
21:24:06evanyep.
21:24:16evanthis is getting my mood down
21:24:19evanand it's a vacation day
21:24:24evanso i think i'm going to not work on it now
21:24:27evanwycats: i'll take a look later.
21:24:36evanit's likely a 64bit issue related to use iconv over FFI
21:24:49rueHaha.
21:25:00rue`module Failure; attr_reader :success`
21:25:05wycatsevan: that's fine
21:25:10wycatsI didn't mean to ruin your day
21:25:16evanyou didn't
21:25:28evandebugging over IRC is just about the most frusterating activity in my life though
21:25:30wycatsI just figured vacation was a good time to mess with rbx, exactly because of things like this ;)
21:25:35wycatsevan: 100%
21:25:35evanand abby is her and trying to have a conversation
21:25:38evanit's not helping.
21:25:45wycatswe need screen over IRC
21:25:55wycatsyou type something and it prints the output
21:25:57evanwycats: go back to working on 32bit darwin
21:25:57wycats;)
21:26:00evanthats the known quantity
21:26:18evanor, you can try and fix using iconv
21:26:32evanthe debugging process for this is
21:26:39evan1) me read the code, tell you a thing to try
21:26:41evan2) me wait
21:26:45evan3) you try and say it doesn't work
21:26:51evan4) we spend 10 minutes trying to get more info
21:26:53evan5) repeat
21:27:05evanthats too hard on my patience right now.
21:27:52rueevan: Try hypnotism: http://journal.kittensoft.org/decimaltime.html
21:28:09rue(For extra fun, hold up a digital watch next to it.)
21:28:15evanhow come it's not a daliclock
21:28:35rueDali's so flaccid
21:29:29wycatsevan: I don't even know if you can use 32 bit darwin on snow leopard
21:30:14ruewycats: /usr/bin/arch -i386 programz0or.exe
21:35:42wycatsrue: so I compile with /usr/bin/arch?
21:37:33rueMm, no, you would compile it universal or using the i386 arch
21:39:22rueErm
21:39:32rue elsif "foo" != (Inflector.transliterate("föö") rescue nil)
22:08:19ddubhmm. 18 billion billion bytes
22:08:24ddubisn't that 2**64 ?
22:10:55ddubthat size sure looks like a special value
22:11:11ddub0xffffffff00000028
22:11:35ddub(from wycats' bt earlier)
22:27:43wycatshmm