Da
Show enters and exits. Hide enters and exits.
| 00:27:18 | boyscout | Updates specs for method#arity and proc#arity - 0b35b16 - Ivan Samsonov |
| 00:27:18 | boyscout | Fix some cases for method#arity and proc#arity - b1f731d - Ivan Samsonov |
| 00:33:54 | boyscout | CI: rubinius: b1f731d successful: 3041 files, 11851 examples, 36146 expectations, 0 failures, 0 errors |
| 00:50:08 | boyscout | Spec for checking that defined_method is private - eb47a10 - Ivan Samsonov |
| 00:50:09 | boyscout | defined_method should be private - 38145d6 - Ivan Samsonov |
| 00:55:27 | boyscout | CI: rubinius: 38145d6 successful: 3041 files, 11852 examples, 36147 expectations, 0 failures, 0 errors |
| 02:11:47 | tarcieri | boyscout is an awesome name for a CI bot |
| 02:12:01 | tarcieri | irccat |
| 02:12:29 | brixen | yeah |
| 02:12:49 | tarcieri | sup brixen |
| 02:13:05 | brixen | werkin on specs |
| 02:13:08 | brixen | sup with you? |
| 02:13:52 | tarcieri | trying to compute unsafe variables in case expressions, yay |
| 02:14:36 | tarcieri | or rather, recycle overcomplicated code that already did that |
| 02:15:09 | brixen | sounds fun |
| 02:15:17 | tarcieri | yes "fun" |
| 02:15:20 | brixen | heh |
| 02:15:37 | tarcieri | I linked this to a friend fo mine who just started learning Sceme as his first functional language and is taking a class on compilers |
| 02:15:47 | tarcieri | like "look at how much fun pure functional is" stab me in the eye with a fork |
| 02:15:56 | tarcieri | err, Scheme... |
| 02:15:57 | tarcieri | wtf? |
| 02:17:06 | brixen | heh |
| 02:17:12 | brixen | too many forks in the eye |
| 02:17:26 | tarcieri | apparently hascaml++ is the new hotness |
| 02:17:30 | tarcieri | I am told by #erlang |
| 02:17:37 | brixen | oh? |
| 02:18:23 | brixen | google only has one reference on that heh |
| 02:18:29 | brixen | http://tunes.org/~nef//logs/haskell/10.01.16 |
| 02:18:43 | tarcieri | <orbitz> I'm working on Hascaml++, should be out in early 2034 |
| 02:18:45 | tarcieri | yes |
| 02:19:11 | brixen | hah, bing only has one too |
| 02:19:17 | brixen | but it's different |
| 02:19:42 | brixen | http://ortdotlove.net/oort-factoids.html |
| 02:20:21 | tarcieri | heh, uhh |
| 02:20:33 | tarcieri | hascaml++ is the new hot pure total functional object orientated language |
| 02:20:36 | tarcieri | sounds like the same thing! |
| 02:20:40 | brixen | heh |
| 02:21:12 | brixen | my own language getafuckinglifefpers should be out as soon as it can do IO |
| 02:21:28 | brixen | until then, it's just computing |
| 02:21:29 | tarcieri | IO is important and stuff |
| 02:21:31 | brixen | purely |
| 02:21:32 | brixen | :) |
| 02:21:39 | tarcieri | seems like a lot of languages forget that |
| 02:21:41 | tarcieri | RUBY!!!!!!!!! |
| 02:21:46 | brixen | heh |
| 02:22:44 | tarcieri | on the bus ride home today I was thinking about trying to do a pure JRuby Rev implementation on top of NIO2 |
| 02:23:00 | tarcieri | and ugh Rev has all these API warts I want to fix but I'm afraid of touching the C code |
| 02:26:31 | brixen | tarcieri: seems like that would be pretty doable, no? |
| 02:26:52 | brixen | does jruby get in your way accessing the NIO2 api at all? |
| 02:27:01 | tarcieri | I've never tried |
| 02:27:05 | tarcieri | and yeah it should be totally doable |
| 02:28:07 | evan | i've almost finished tearing up Time |
| 02:28:12 | brixen | sweet |
| 02:28:16 | evan | seems like someone started implementing some stuff |
| 02:28:18 | evan | and never finished. |
| 02:28:22 | evan | but left a bunch of half written code. |
| 02:28:46 | wayneeseguin | Half written is not written, greenfield! |
| 02:28:48 | wayneeseguin | :) |
| 02:28:57 | evan | also found http://2038bug.com/pivotal_gmtime_r.c.html |
| 02:29:05 | wayneeseguin | well 'Half written by someone else is not written' |
| 02:29:09 | evan | which i'm going to incorporate after I finish here |
| 02:29:41 | tarcieri | Time is all riddled with C or what? |
| 02:30:36 | evan | it was just totally weird |
| 02:30:45 | evan | they took something that is largely immutable |
| 02:30:53 | evan | and implemented it in a totally weird way |
| 02:31:00 | evan | to create a new Time object, it would do |
| 02:31:03 | tarcieri | oh awesome Time is somehow mutable? |
| 02:31:07 | evan | Time.allocate.make_time() |
| 02:31:18 | evan | where make_time just mutates the receiver |
| 02:31:24 | tarcieri | lol |
| 02:31:26 | evan | rather, than, say Time.make_time(). |
| 02:31:46 | brixen | Time.make_time(:in_your_day_for_fun) |
| 02:31:48 | tarcieri | Matz seems to almost have it right with immutability |
| 02:31:49 | evan | yes, mostly immutable |
| 02:31:53 | evan | for some fucking reason |
| 02:31:58 | evan | there is Time#localtime |
| 02:32:00 | tarcieri | totally by accident, as far as I can tell |
| 02:32:04 | tarcieri | Python certainly fails balls |
| 02:32:05 | evan | which flips the "is this Time object for gmt or not" flag |
| 02:32:25 | tarcieri | I can't figure out what Matz's deal is |
| 02:32:47 | tarcieri | I guess it's that he continues to think about all these problems but can't exactly do anything about them in Ruby |
| 02:33:14 | brixen | in Ruby or in MRI? |
| 02:33:19 | tarcieri | his keynotes are all "here's a bunch of random shit you should probably pay attention to and oh by the way ruby" |
| 02:33:22 | tarcieri | in Ruby |
| 02:33:36 | tarcieri | Ruby and its mutable state up the wazoo |
| 02:34:23 | tarcieri | Matz talks about all this stuff like the multicore future and concurrency, then it's "oh by the way Ruby..." |
| 02:37:32 | tarcieri | like I assume you saw this: http://www.infoq.com/interviews/yukihiro-matz-language-design |
| 02:38:31 | evan | yesum. |
| 02:39:22 | tarcieri | it's really interesting to hear him talk about what kind of language he would design today |
| 02:41:00 | tarcieri | yeah, talking about laziness, "the yield keyword in other languages" heh |
| 02:41:03 | tarcieri | generators |
| 02:43:22 | tarcieri | I guess I should go say hi to Matz at some future Ruby conference |
| 02:43:33 | tarcieri | "I like mixing Actors and Ruby-like ideas!" |
| 02:44:29 | tarcieri | but yeah, he thinks you can solve concurrency issues at the library level, not the language... |
| 17:50:12 | evan | mornings gents! |
| 17:50:41 | kronos_vano | hi |
| 17:51:21 | evan | kronos_vano: how are you this morning? |
| 17:51:27 | evan | i guess it's evening for you |
| 17:51:30 | evan | did you have a good friday? |
| 17:55:28 | kronos_vano | My timezone is utc +3, so yep, here is evening. Friday is good because i'm already at home and ready for rubinius! |
| 17:55:47 | evan | woo! |
| 17:55:51 | brixen | heh |
| 17:56:09 | evan | my new Time nearly almost passes all the specs |
| 17:57:20 | brixen | woohoo '1489 files, 9829 examples, 101842 expectations, 4 failures, 0 errors' |
| 17:57:26 | brixen | that's 1.9 head on rubyspec |
| 17:57:39 | brixen | for language/ and core/ |
| 17:57:41 | evan | you're awesome. |
| 17:57:48 | brixen | not me |
| 17:58:06 | brixen | I'm just facilitating |
| 17:58:08 | evan | :D |
| 18:01:14 | dbussink | evan: i still have some time specs failing here atm, due to tz differences |
| 18:01:26 | dbussink | evan: you should running the specs with another tz too :) |
| 18:01:54 | evan | ok, no prob. |
| 18:02:15 | dbussink | evan: let me gist you an example of the difference between rbx and ruby |
| 18:02:23 | evan | 10-4 |
| 18:02:26 | brixen | dbussink: that would be nice |
| 18:02:38 | maharg | timezones *shudder* |
| 18:02:44 | dbussink | https://gist.github.com/5603b057b1140626d890 |
| 18:02:55 | dbussink | basically this is because the netherlands didn't have the same tz in the past |
| 18:03:01 | evan | oh man. |
| 18:03:02 | evan | ok |
| 18:03:04 | evan | yeah |
| 18:03:12 | evan | tz's in the past o/~ suuuuuuuck o/~ |
| 18:03:24 | dbussink | we have been +0:19, +0:20 and +1:00 |
| 18:03:36 | evan | wtf is that |
| 18:03:38 | dbussink | we have the germans to thank for the last move :P |
| 18:03:42 | evan | seriously ntherlands? |
| 18:03:50 | evan | 19 minutes off gmt? |
| 18:03:51 | maharg | +:19 wat |
| 18:03:53 | dbussink | yeah |
| 18:03:54 | evan | what are you |
| 18:03:57 | evan | mt everest? |
| 18:04:06 | evan | (which is 45 minutes off the next zone) |
| 18:04:14 | dbussink | well, that was the time the sun was at the highest point in amsterdam |
| 18:04:45 | dbussink | which was later standardized to +0:20 to unify it across the netherlands (when trains were introduced, there were different times in each town before that) |
| 18:04:48 | evan | when did it change to 20? |
| 18:04:56 | evan | i'm assuming the change to 1hr was in the 30s |
| 18:04:59 | dbussink | and when ww2 broke out the germans changed everything to berlin time |
| 18:05:15 | evan | fun |
| 18:05:36 | dbussink | which is +1:00 and it has been like that ever since |
| 18:05:45 | dbussink | so far for a short history lesson :P |
| 18:05:52 | maharg | newfoundland is -3:30 |
| 18:06:33 | evan | and thats dumb too! |
| 18:06:41 | dbussink | evan: the easy part of being a new country ;) |
| 18:06:46 | evan | mt everest is 45 minutes off only because it's an extreme climate |
| 18:07:03 | evan | and they wanted noon to sync to the sun directly overhead |
| 18:08:04 | maharg | the real problem with timezones isn't weird increments. It's the fact that they change over the course of the year. Goddamn daylight savings time |
| 18:09:12 | evan | true |
| 18:09:30 | evan | rue|W: well in the US it has the effect of changing |
| 18:09:42 | evan | because Arizona, who doesn't observe DST, has the effect of moving TZs |
| 18:09:55 | evan | in fact, thats how it's referenced |
| 18:10:05 | evan | "is Arizona in Mountain or Pacific time right now?" |
| 18:10:15 | dbussink | rue|W: that's actually true for whole europe :) |
| 18:11:01 | dbussink | evan: i've had that yeah, we travelled from pacific to arizona and were like "wtf, time doesn't change", then the dst switch happened when in arizona and we got back in pacific and then it did change |
| 18:11:05 | dbussink | pretty confusng |
| 18:11:17 | evan | yep! |
| 18:11:24 | evan | DST is a pain |
| 18:11:25 | maharg | also that the rules change over time and you have to keep your rule table up to date |
| 18:11:32 | evan | but I guess it saves a shitton of energy per year |
| 18:11:39 | evan | so *shrug* |
| 18:11:47 | dbussink | it actually doesn't do really much |
| 18:11:55 | dbussink | but i like the extra hour of light in the evening in the summer |
| 18:12:12 | dbussink | when drinking a beer and enjoying the evening |
| 18:12:16 | maharg | I live far enough north that it only really helps in that sense for like 3 weeks a year |
| 18:12:40 | dbussink | maharg: where is that? |
| 18:13:03 | dbussink | evan: but i assume that mri refers to posix stuff to do this computation |
| 18:13:08 | maharg | shortest day is from about 10am to 4:30pm |
| 18:13:31 | dbussink | rue|W: nah, that would make it dark even earlier in winter, i don't like that either :P |
| 18:13:57 | dbussink | maharg: where do you live? |
| 18:14:28 | maharg | http://maps.google.ca/maps?q=edmonton&ie=UTF8&hq=&hnear=Edmonton,+Division+No.+11,+Alb erta&gl=ca&ei=wkh0S_z7GI2inQfLnPi-CQ&ved=0CA4Q8gEwAA&ll=53.540307,-113.203125&sp n=118.117204,313.59375&t=h&z=2 |
| 18:14:57 | dbussink | maharg: that's pretty far north for canadian standards i assume |
| 18:15:20 | evan | dbussink: i'll check shortly |
| 18:15:59 | evan | i always forget how far north edmonton is |
| 18:15:59 | maharg | it's the furthest north you can get and still be in a 'large' metropolitan city in NA. |
| 18:16:12 | evan | no wonder the mall is huge. |
| 18:16:17 | maharg | heh |
| 18:16:19 | dbussink | maharg: yeah, it looked like that on the map |
| 18:16:38 | maharg | north of this there's just anchorage, which is like 300k people |
| 18:18:16 | maharg | on the other hand, we get 18 hour days in summer |
| 18:18:19 | maharg | which are glorious |
| 18:18:49 | maharg | whenever I travel south in summer it's shocking how early the sun sets |
| 18:18:54 | dbussink | maharg: it's actually not much further north than the northern part of the netherlands |
| 18:19:47 | dbussink | rue|W: yeah, i know that the us / canada is much further south than i imagine, but it still surprises me |
| 18:19:49 | evan | man, i can't imagine how cold europe would be without the north atlantic current |
| 18:19:56 | dbussink | evan: pretty chilly :) |
| 18:20:26 | evan | americans are so used to thinking about europe as straight east |
| 18:20:45 | dbussink | evan: same here actually |
| 18:20:56 | dbussink | evan: it's works reasonably well weather wise though :) |
| 18:21:00 | evan | true |
| 18:22:04 | dbussink | evan: there are other things americans think that make me cringe ;) |
| 18:22:58 | evan | oh me too my friend |
| 18:22:59 | evan | me too. |
| 18:23:09 | maharg | no benefit of ocean air here. Rockies are in the way :/ |
| 18:23:22 | dbussink | although i feel ashamed about geert wilders these days |
| 18:23:36 | dbussink | if that name doesn't ring a bell, i'm happy :P |
| 18:24:23 | evan | it does not. |
| 18:24:26 | evan | and i shall not google it. |
| 18:24:55 | maharg | that's an impressive display of restraint |
| 18:25:21 | evan | i've got a constitution of steel. |
| 18:25:28 | evan | if only I had the stomach to match. |
| 18:26:37 | jvoorhis | i love llvm! |
| 18:26:43 | evan | me too! |
| 18:26:49 | evan | lets make a club! |
| 18:26:52 | dbussink | let us all sing praise! |
| 18:26:59 | jvoorhis | last night, i implemented common subexpression elimination for my compiler |
| 18:27:05 | evan | nice! |
| 18:27:08 | dbussink | hallelujah! |
| 18:27:12 | jvoorhis | and then i found the equivalent passes, and deleted my code |
| 18:27:14 | jvoorhis | :) |
| 18:27:30 | evan | hah |
| 18:27:57 | evan | i was going to ask "was the implementation pass_manager << createSEL()" |
| 18:27:58 | evan | :D |
| 18:28:12 | jvoorhis | yeah, something like that |
| 18:28:21 | jvoorhis | hm, that's not a bad syntax |
| 18:28:34 | jvoorhis | i support pass_manager.add(:sel, ...) |
| 18:29:01 | evan | making the weird LLVM names for the passes to something easier to remember would be good |
| 18:29:07 | evan | mapping, rather. |
| 18:29:08 | jvoorhis | yeah |
| 18:29:20 | jvoorhis | i was thinking about that |
| 18:29:28 | evan | i'd probably even make methods on pass_manager for the most common ones |
| 18:29:34 | evan | pass_manager.sel! |
| 18:29:36 | jvoorhis | i have them |
| 18:29:53 | jvoorhis | pass_manager.add_aggressive_dce_pass is equivalent to pass_manager.add(:aggressive_dce) |
| 18:29:59 | evan | there is a black art to picking the passes and their order in LLVM though |
| 18:30:13 | jvoorhis | they have to be methods because llvm-c has no data representation for passes |
| 18:30:20 | evan | esp. when you getting into trying to add custome AliasAnalysis passes |
| 18:30:26 | jvoorhis | so pass_manager << someObject won't really work, unless it was a symbol |
| 18:30:33 | evan | jvoorhis: so make it a symbol |
| 18:30:41 | jvoorhis | yeah, that would be fine |
| 18:31:53 | jvoorhis | i was thinking of mapping the names onto their option names at http://llvm.org/docs/Passes.html |
| 18:32:26 | jvoorhis | so :aggressive_dce would become :adce, and i could refer to that page in ruby-llvm's docs |
| 18:33:05 | jvoorhis | evan: you're right about black magic – it took me a bit of trial and error to find a pretty good set |
| 18:34:31 | evan | yeah |
| 18:34:41 | evan | the AA passes are even harder |
| 18:34:52 | evan | because you have to insert them right before you want use them |
| 18:34:55 | evan | or they disappear |
| 18:35:20 | jvoorhis | not all of the passes are in llvm-c |
| 18:35:54 | jvoorhis | none of the analysis stuff is, for example |
| 18:36:05 | jvoorhis | just scalar opts and ipo |
| 18:36:10 | evan | yeah |
| 18:36:13 | evan | if you want stuff added |
| 18:36:15 | evan | let me know |
| 18:36:19 | evan | i've got LLVM commit rights |
| 18:36:25 | jvoorhis | cool, i may send a patch since the wrappers are really straightforward |
| 18:36:31 | evan | k |
| 18:36:52 | jvoorhis | is the pass manager code in rbx pretty centralized? |
| 18:37:02 | jvoorhis | i'd like to see some examples of how more experienced people are using it |
| 18:37:13 | evan | sure, let me show ya |
| 18:38:03 | evan | http://github.com/evanphx/rubinius/blob/master/vm/llvm/jit.cpp#L466 |
| 18:38:06 | jvoorhis | cool, the docs allude to certain analysis passes creating transformation opportunities, but everything is still really vague |
| 18:38:10 | evan | that list was original extracted from opt |
| 18:38:22 | evan | and then i've slowly added/removed/reordered |
| 18:38:26 | jvoorhis | cool |
| 18:38:45 | evan | you should use createInstructionCombiningPass often |
| 18:39:04 | jvoorhis | wow |
| 18:39:08 | jvoorhis | yeah, i used it once, early |
| 18:39:13 | evan | oooh |
| 18:39:17 | evan | it's a cleanup pass |
| 18:39:19 | jvoorhis | yeah |
| 18:39:31 | evan | use it after you have passes that do a lot stuff |
| 18:39:40 | jvoorhis | hm, no cond or const propagation? |
| 18:39:55 | evan | GVNPass does that |
| 18:39:57 | jvoorhis | i also found gvn and licm to be pretty useful |
| 18:39:58 | jvoorhis | oh |
| 18:40:01 | jvoorhis | so that's redundant? |
| 18:40:12 | evan | yeah |
| 18:40:25 | evan | a lot of them do similar things, using different algorithms |
| 18:40:35 | jvoorhis | does gvn do licm? |
| 18:40:44 | jvoorhis | llvm really needs a pass tutorial |
| 18:40:49 | evan | yeah it does |
| 18:41:01 | evan | i believe that gvn and licm do similar things, yes. |
| 18:41:07 | jvoorhis | what's overflow folding? |
| 18:41:22 | evan | a pass I wrote |
| 18:41:37 | jvoorhis | what does it do? |
| 18:41:39 | evan | that does constant folding of the llvm overflow math intrinsics |
| 18:41:44 | jvoorhis | neat |
| 18:42:13 | evan | those are in passes.cpp |
| 18:43:27 | jvoorhis | hm, and CFG is used three times |
| 18:43:40 | evan | yeah |
| 18:43:51 | evan | it cleans up the control flow |
| 18:43:56 | jvoorhis | right |
| 18:44:04 | evan | making other passes more likely to do better work |
| 18:44:08 | jvoorhis | i've seen it delete blocks in my code and such |
| 18:44:18 | evan | since not all passes are super smart about control flo |
| 18:44:19 | evan | flow |
| 18:44:27 | jvoorhis | yeah |
| 18:45:20 | jvoorhis | thanks, some good ideas here that i can play wtih |
| 18:46:06 | evan | no prob. |
| 18:46:09 | jvoorhis | my process has mainly been dumping my code, making a change, dumping again, and diffing the IR |
| 18:46:13 | jvoorhis | it gets tedious |
| 18:46:21 | evan | yeah |
| 18:46:28 | evan | i did it trial and error too |
| 18:46:46 | evan | basically looking at the IR and saying "it should be able to remove this" |
| 18:46:56 | evan | and figuring out what passes I needed for that to happen |
| 18:47:03 | jvoorhis | and your code is much more complex than mine |
| 18:47:10 | evan | :) |
| 18:48:00 | jvoorhis | especially since i'm shooting for optimized numeric code :) |
| 18:49:13 | evan | :) |
| 18:49:16 | jvoorhis | rewriting the api many times helps a lot |
| 18:49:35 | jvoorhis | here's an example of what i've come up with so far |
| 18:49:38 | jvoorhis | DSP.new { |dsp| dsp.out[0] = dsp.in[0] * oscil(hz: 1.0, amp: 1.0) } |
| 18:49:51 | jvoorhis | that would be a tremolo effect that acts on realtime input |
| 18:51:07 | jvoorhis | (indexes select channels, so that's a mono signal, and there's some 1.9 hash syntax there) |
| 18:54:00 | evan | nice |
| 18:55:23 | jvoorhis | yeah, i feel like i'm learning to negotiate between my FP tricks and idiomatic ruby |
| 18:56:06 | jvoorhis | there's still a little first-order, referentially transparent language in there represented by an algebraic data type |
| 18:56:23 | jvoorhis | but i compile it with visitors, and assign it to things, and allow a little bit of state in the right parts |
| 18:57:06 | jvoorhis | so it looks like ruby again :) |
| 18:57:17 | evan | cool |
| 18:57:30 | evan | so, are you using LLVM's JIT then? |
| 18:57:33 | jvoorhis | yes |
| 18:57:56 | evan | what are you doing with the void* you get back? |
| 18:59:03 | jvoorhis | PortAudio::Stream.new(..., :callback => execution_engine.pointer_to_global(cback)) |
| 18:59:24 | jvoorhis | FFI glues everything together :) |
| 19:00:01 | evan | so you invoke the JIT'd method as an FFI callback? |
| 19:00:06 | jvoorhis | no |
| 19:00:21 | jvoorhis | well, callback yes, but not an FFI callback |
| 19:00:41 | evan | you have a little bit of C code that you use to invoke it then? |
| 19:00:48 | jvoorhis | portaudio spawns a thread whose mainloop is driven by the audio hardware, and it invokes the callback |
| 19:01:21 | evan | ah |
| 19:01:33 | evan | it's the portaudio stuff then that invokes it |
| 19:01:34 | evan | gotcha. |
| 19:01:37 | jvoorhis | exactly |
| 19:01:38 | evan | i forgot about that part |
| 19:01:58 | jvoorhis | the callback is invoked with some timing information, input and output buffers, and a pointer to whatever state i need |
| 19:03:03 | jvoorhis | so my dsl's dsp expressions are embedded inside of a loop that sets a few state variables like the current time, and uses the generated code to fill the buffer |
| 19:03:38 | jvoorhis | i also implemented the blocking api for portaudio, so it's possible to generate sound without using callbacks JIT'd or otherwise |
| 19:03:51 | jvoorhis | but that's a lot slower / intensive |
| 19:04:12 | jvoorhis | http://github.com/jvoorhis/ruby-portaudio/blob/master/lib/portaudio.rb#L511 <-- fun toy |
| 19:06:18 | jvoorhis | but if you push it too hard, the audio gets crackly and drops out |
| 19:06:31 | evan | right |
| 19:08:08 | jvoorhis | my JIT'd callbacks use doubles for representing samples, run at 96000 hz (or whatever my hardware supports), and use about 12% cpu |
| 19:10:33 | jvoorhis | so with the right features and a bit more experience, this could become something not unlike a modern Csound |
| 19:16:05 | evan | nice |
| 19:18:05 | jvoorhis | yeah, compiled dsls are really cool |
| 19:18:28 | jvoorhis | the hornet's eye rubyconf talk was really impressive |
| 19:19:01 | jvoorhis | was really validating to find out someone else was doing the same thing in ruby, and pushing it pretty hard |
| 19:19:04 | jvoorhis | he uses libjit though |
| 19:19:57 | jvoorhis | and my original inspiration is at http://conal.net/papers/jfp-saig/ |
| 19:20:54 | jvoorhis | but that language compiles to C and has lots of painstakingly crafted optimization code |
| 19:20:59 | jvoorhis | LLVM makes me feel like i'm cheating :D |
| 19:21:15 | brixen | you are |
| 19:21:17 | brixen | :) |
| 19:22:13 | jvoorhis | i'm ok with that :) |
| 19:22:26 | brixen | indeed |
| 19:22:40 | brixen | cheat and steal whenever you can |
| 19:23:36 | jvoorhis | on the other hand, i have a couple thousand lines of FFI code |
| 19:23:42 | brixen | is there an os x cmd line utility that will tell you the encoding of a filename? |
| 19:23:47 | dbussink | lazyness is a programmers virtue |
| 19:25:03 | jvoorhis | brixen: not that i've heard of |
| 19:25:15 | brixen | hrm |
| 19:25:24 | brixen | I wonder if this is even possible to spec... |
| 19:28:09 | dbussink | brixen: hfs+ filenames are utf-16 encoded |
| 19:28:54 | brixen | dbussink: well I'm getting utf-8 back from File#to_path string |
| 19:28:56 | brixen | so dunno |
| 19:29:09 | brixen | I encode the string as euc-jp before creating the file |
| 19:29:22 | dbussink | brixen: how does it determine in mri what kind of encoding you get back? |
| 19:29:29 | jvoorhis | brixen: maybe you could knock it together with this thing: http://github.com/blackwinter/cmess/blob/master/lib/cmess/guess_encoding.rb |
| 19:29:36 | brixen | since this spec is passing for one of the ruby-core devs, I'm not sure what's up |
| 19:30:08 | brixen | dbussink: see my comments in #rubyspec and that commit |
| 19:30:30 | brixen | jvoorhis: interesting, thanks |
| 19:31:03 | jvoorhis | i know cocoa has some code for deriving encoding from strings too |
| 19:31:11 | jvoorhis | a command line tool is probably fairly straightforward |
| 19:31:19 | evan | woo |
| 19:31:22 | evan | Time passes the time specs again. |
| 19:31:41 | brixen | nice! |
| 19:33:01 | evan | huh |
| 19:33:03 | evan | MRI is weird. |
| 19:33:17 | brixen | heh |
| 19:33:22 | evan | t = Time.at(100) |
| 19:33:47 | evan | p (t + 1.3).usec # => 300000 |
| 19:33:59 | evan | p (t + -1.3).usec # => 0 |
| 19:34:43 | evan | p (t - 1.3).usec # => 700000 |
| 19:34:43 | dbussink | evan: did you try my suggestions? :) |
| 19:35:12 | dbussink | evan: probably warrants a spec / bug report then |
| 19:35:27 | evan | p (t - -1.3) # => 300000 |
| 19:37:57 | evan | it must be a bug |
| 19:38:01 | evan | they changed it in 1.9 |
| 19:38:06 | evan | course, in 1.9, i get |
| 19:38:13 | evan | 699999 instead of 700000 |
| 19:38:17 | evan | *eyeroll* |
| 19:43:07 | evan | woit. |
| 19:43:08 | evan | wait |
| 19:43:09 | evan | wtf |
| 19:43:17 | evan | i must have screwed it up |
| 19:43:22 | evan | nevermind. |
| 19:49:14 | evan | dbussink: ok |
| 19:49:18 | evan | what TZ should I set it to? |
| 19:49:28 | dbussink | evan: i have Europe/Amsterdam here |
| 19:49:32 | evan | k |
| 19:50:28 | evan | hm. |
| 19:50:35 | evan | TZ=Europe/Amsterdam bin/mspec spec/ruby/core/time |
| 19:50:37 | evan | is clean |
| 19:50:42 | evan | what spec fails for you |
| 19:50:43 | evan | specificly |
| 19:53:08 | dbussink | evan: https://gist.github.com/fab876ef70bb265f7d60 |
| 19:53:17 | dbussink | maybe your changes already fixed it |
| 19:53:28 | dbussink | evan: did you try the things in my previous gist? |
| 19:53:38 | dbussink | evan: https://gist.github.com/5603b057b1140626d890 |
| 19:54:07 | evan | ok, one sec. |
| 19:59:34 | evan | ok, i've added your case |
| 19:59:36 | evan | now i'll fix it. |
| 20:14:17 | dbussink | evan: tricky case? |
| 20:14:33 | evan | more interesting |
| 20:14:43 | evan | trying to figure out which system is getting the TZ wrong |
| 20:14:49 | evan | it appears that mktime() is doing fine |
| 20:15:02 | evan | i'm getting the right seconds (-1893457172 to be exact) |
| 20:15:48 | evan | oh ho. |
| 20:15:51 | evan | look at this. |
| 20:16:09 | evan | MRI's Time#inspect does not trust strftime |
| 20:16:25 | evan | it creates it's own offset |
| 20:16:32 | evan | which is the thing we're looking at. |
| 20:18:04 | dbussink | ah, Time.local(1930, 1, 1).strftime("%z") also prints +01:00 |
| 20:18:09 | evan | yeah |
| 20:18:11 | evan | AWESOME. |
| 20:18:12 | dbussink | in irb |
| 20:18:14 | evan | i was about to test that. |
| 20:18:19 | evan | so one place it's right |
| 20:18:21 | evan | another it's wrong. |
| 20:21:13 | dbussink | 1.9 has it fixed |
| 20:21:27 | dbussink | Time.local(1930, 1, 1).strftime("%z") => "+0020" |
| 20:21:56 | evan | ok, checking it now. |
| 20:22:17 | evan | MEGAWIN |
| 20:22:23 | evan | i'm doing this |
| 20:22:32 | evan | 1.9 includes it's own public domain strftime |
| 20:25:47 | evan | i love code that includes in a comment an email from 1991 |
| 20:26:03 | evan | esp. when it includes stuff like: |
| 20:26:14 | evan | in a process of fixing of strftime() in libraries on Atari ST I grabbed |
| 20:26:14 | evan | some pieces of code from your own strftime. |
| 20:26:21 | evan | Atari ST! |
| 20:26:28 | brixen | heh |
| 20:37:56 | dbussink | evan: you're going to include it? |
| 20:38:51 | evan | pondering |
| 20:39:01 | evan | I think I might just handle %z specially |
| 20:47:16 | dbussink | evan: this one is also fun: Time.utc(1930, 1, 1).localtime => Wed Jan 01 00:19:32 +0019 1930 |
| 20:50:18 | evan | yeah |
| 20:50:21 | evan | thats fun |
| 20:50:23 | evan | though it's the same |
| 20:50:33 | evan | #localtime just twiddles the internal "is this for gmt or not" flag |
| 21:09:09 | dbussink | brixen: where does that huge amount of expectations come from? auto generated specs for encodings? |
| 21:10:08 | brixen | yes |
| 21:16:21 | dbussink | brixen: is there an easy way to run rubyspec with rvm 1.9 installs/ |
| 21:16:22 | dbussink | ? |
| 21:17:24 | dbussink | brixen: since -tr19 looks for a ruby1.9 executable |
| 21:18:05 | brixen | -t 'path/to/exe' or 'exe' if it's in the path |
| 21:19:04 | brixen | or rvm <whatever> mspec-run |
| 21:19:31 | brixen | is getting lunch |
| 21:45:45 | brixen | dbussink: did you get it working? |
| 21:46:07 | dbussink | brixen: yeah, did get a spurious segfault though with latest trunk |
| 21:46:27 | brixen | spurious == not repeatable? |
| 21:46:28 | dbussink | brixen: and can't seem to run latest rubyspec, since it needs mspec 1.5.16 which isn't released yet |
| 21:46:39 | brixen | oh oops |
| 21:46:40 | dbussink | brixen: yeah |
| 21:46:42 | brixen | did I not push that |
| 21:47:21 | brixen | dbussink: you should have it now (mspec 1.5.16) |
| 21:48:12 | dbussink | brixen: ah, it crashed again |
| 21:48:41 | brixen | dbussink: consider filing a ticket |
| 21:48:53 | brixen | if it's repeatable and you have 1.9 head and rubyspec head |
| 21:49:15 | brixen | can you repro it with -fs? |
| 21:49:19 | brixen | so we can see which spec it is |
| 23:06:09 | evan | hey! |
| 23:06:15 | evan | that public domain strftime worked! |
| 23:06:24 | evan | it was easier that doing %z myself |
| 23:06:32 | evan | i just modernized it a bit and threw it in. |
| 23:07:54 | benschwarz | brixen: ... |
| 23:08:10 | benschwarz | Whats with all the 1.9 testing? |
| 23:09:17 | rue | Neat |
| 23:11:12 | evan | rad |
| 23:11:15 | evan | kendall :: git/rbx » bin/rbx |
| 23:11:15 | evan | >> ENV['TZ'] = "Europe/Amsterdam" |
| 23:11:16 | evan | => "Europe/Amsterdam" |
| 23:11:18 | evan | >> t = Time.local(1910, 1, 1) |
| 23:11:20 | evan | => Sat Jan 01 00:00:00 +0019 1910 |
| 23:11:22 | evan | >> t.strftime("%z") |
| 23:11:24 | evan | => "+0019" |