Show enters and exits. Hide enters and exits.
| 00:00:03 | sandal | evan, headius I'd really appreciate it if you could check my notes on my talk when I have them together, if you are interested |
| 00:00:03 | evan | like they've got incompatible syntax |
| 00:00:08 | evan | sure |
| 00:00:12 | headius | no problem |
| 00:00:29 | sandal | It's not planned to be super technical, it's just trying to give people a survey of the options and a snapshot of where things are |
| 00:00:51 | sandal | while I really love the various talks you guys have given, I feel like they're geared towards language geeks (completely understandably) |
| 00:01:23 | luislavena | ok guys, time to go home, thank you for everything. |
| 00:01:30 | evan | luislavena: see ya |
| 00:01:37 | luislavena | need to get some gems working on 1.9 :P |
| 00:01:40 | evan | sandal: certainly |
| 00:01:45 | sandal | I was hoping to offer the newb perspective without the fanboy vibes :) |
| 00:02:06 | headius | we tried to do a user talk at rubyconf this year |
| 00:02:12 | headius | didn't talk about implementation at all |
| 00:02:18 | sandal | but yeah, I'll send along my notes because it's hard to keep up with this velocity |
| 00:03:04 | sandal | headius: examples run perfect on edge |
| 00:03:08 | headius | cool |
| 00:03:40 | sandal | checking tests now... |
| 00:06:15 | sandal | headius: tests all green |
| 00:06:26 | headius | solid! |
| 00:06:31 | sandal | evan: this means that JRuby just stole the #1 spot in the Prawntest :) |
| 00:06:41 | headius | btw, do you have a CI run set up somewhere for JRuby? cuz we could set one up otherwise |
| 00:06:48 | headius | I've been wanting to get more CI runs for various gems |
| 00:06:54 | evan | NOOO |
| 00:06:55 | sandal | oh, please do so |
| 00:06:55 | headius | keep us both honest |
| 00:06:55 | evan | :D |
| 00:07:18 | evan | sandal: anything you need rubinius to fix? |
| 00:07:24 | evan | the test/spec thing? |
| 00:07:42 | sandal | Though still pretty solid. I'm going to fix that test/spec issue because I'm pretty sure Rubinius will pass the tests too |
| 00:07:45 | sandal | yeah, that's the only issue |
| 00:08:12 | sandal | It does make Rubinius an outlier, given that JRuby, MacRuby, k01's vm, and MRI all work |
| 00:08:14 | jarib | i found some cases where UnboundMethod#compiled_method returns an AccessVariable instance |
| 00:08:20 | jarib | should that ever happen? |
| 00:08:47 | jarib | it makes UnboundMethod#inspect blow up since it calls @compiled_method.name |
| 00:08:48 | sandal | oh whoops, - macruby |
| 00:09:00 | sandal | it didn't run test/spec at all, couldn't find it |
| 00:09:12 | sandal | (will be looking into it) |
| 00:09:12 | headius | yeah, I don't think rspec works on macruby yet |
| 00:09:21 | sandal | test/spec. |
| 00:09:29 | headius | oh, ok |
| 00:09:35 | headius | I read "tests/specs" |
| 00:09:40 | sandal | It seemed like a rubygems issue |
| 00:09:56 | sandal | it just couldn't find it |
| 00:10:26 | evan | jarib: that can happen, yes. |
| 00:10:35 | evan | jarib: UnboundMethod needs to be aware of AccessVariables |
| 00:10:50 | evan | and/or AccessVariables needs a #name method |
| 00:10:52 | evan | probably the later |
| 00:11:30 | jarib | i see |
| 00:12:38 | headius | whenever I read prawn I think pr0n |
| 00:12:53 | headius | sometimes type it too |
| 00:12:57 | headius | gem install pron |
| 00:13:27 | evan | wishful thinking perhaps. |
| 00:14:41 | sandal | Sometimes when I read pr0n I think of Prawn |
| 00:17:10 | rue | Tehee |
| 00:19:04 | headius | sandal: CI build set up |
| 00:20:14 | headius | sandal: I'm just having it update master/HEAD every night |
| 00:22:39 | headius | wow, what the hell is in prawn repo that takes this long to clone? |
| 00:22:53 | headius | maybe github is slow right now or something |
| 00:24:10 | sandal | headius: actually, no. |
| 00:24:27 | sandal | I accidentally checked in the PDF spec |
| 00:24:32 | headius | ack |
| 00:24:33 | sandal | which is like 17mb |
| 00:24:38 | headius | yeah, that would do it |
| 00:24:43 | sandal | Prawn was my first experience using git :) |
| 00:24:48 | headius | you should wipe out that commit |
| 00:24:53 | headius | I think you can do that |
| 00:25:11 | sandal | I did that but I need to re-write it on every tag I think |
| 00:25:18 | headius | ick |
| 00:25:19 | sandal | or something nasty |
| 00:25:26 | sandal | this has come up though before |
| 00:25:34 | headius | well I'm doing clone --depth 1 for the initial pull, so hopefully it won't re-fetch that |
| 00:25:36 | sandal | even without it, the repos will be big because of some CJK fonts |
| 00:25:38 | headius | but it takes a long time to process |
| 00:25:44 | headius | ok |
| 00:25:52 | headius | slow connection at this location anyway |
| 00:25:53 | headius | I'm sure it's fine |
| 00:25:54 | sandal | (for testing) |
| 00:27:24 | sandal | anyway, off for now. Thanks evan and headius for the help. |
| 00:27:38 | headius | yup yup |
| 00:27:50 | jarib | evan: adding AccessVariable#name, it ends up looking like this: [].method(:length) #=> #<Method: Array#@total (defined in Array)> |
| 00:29:08 | jarib | at least it's an improvement :) |
| 00:32:34 | jarib | hmm, perhaps Method#inspect should just use it's own @name instead of @compiled_method.name if it's an AccessVariable |
| 00:32:36 | brixen | hm, what about #<AccessVariable: Array @total> |
| 00:33:44 | jarib | for Method#inspect ? |
| 00:33:52 | brixen | for that case |
| 00:34:03 | brixen | I dislike Array#@total |
| 00:34:08 | jarib | yeah |
| 00:35:25 | jarib | but it seems wrong if the inspect string for Method doesn't have #<Method ...something...>, no? |
| 00:35:46 | brixen | hmm |
| 00:36:16 | brixen | I see you're point, but.. |
| 00:36:46 | brixen | AccessVariable < Executable |
| 00:37:02 | brixen | anyway, evan can decide |
| 00:37:12 | brixen | I vote for my #inspect string :) |
| 00:37:45 | jarib | #<Method: Array#length (@total, defined in Array)> |
| 00:37:54 | jarib | i have no idea |
| 00:37:58 | brixen | ugly imo |
| 00:38:21 | brixen | I don't think it has to have #<Method ..> in it |
| 00:38:39 | jarib | no, you're probably right |
| 00:39:04 | brixen | my string just has the relevant bits of info |
| 00:39:07 | jarib | #method can return UnboundMethod as well |
| 00:39:53 | brixen | sure |
| 00:40:04 | brixen | does AccessVariable not have #inspect? |
| 00:41:01 | jarib | it does, but Method#inspect will use @compiled_method.name |
| 00:42:11 | jarib | which blows up when @compiled_method.is_a? AccessVariable |
| 00:43:06 | brixen | so, the issue is in Method#inspect? |
| 00:43:12 | jarib | yes |
| 00:43:37 | brixen | and you can't return the alternative string when @compiled_method.is_a? AccessVariable? |
| 00:43:58 | jarib | no, that should be fine |
| 00:44:50 | jarib | it just feels weird that Method#inspect essentially returns the inspect string of one of its ivars |
| 00:45:30 | brixen | yeah, it feels a little weird |
| 00:45:48 | brixen | I don't think it would be a problem though |
| 00:46:05 | brixen | more of the insides of rbx show, since more of it is first-class classes |
| 00:51:49 | rue | Muhaa. Put up LLVM |
| 03:28:15 | tarcieri | umm, weird |
| 03:28:34 | tarcieri | ^C doesn't seem to stop the tests that run after rake |
| 03:28:40 | brixen | yeah, that's rake |
| 03:28:48 | brixen | it swallows the ^C |
| 03:28:50 | tarcieri | orly |
| 03:28:51 | tarcieri | wtf |
| 03:28:57 | brixen | or does something with it |
| 03:29:00 | brixen | rbx doesn't get it |
| 03:29:07 | tarcieri | bizzarre |
| 03:29:19 | brixen | rake is a tool |
| 03:29:24 | brixen | heh |
| 03:29:29 | tarcieri | haha |
| 03:29:31 | tarcieri | I ^Zed it |
| 03:29:36 | tarcieri | and it kept running in the background |
| 03:29:37 | tarcieri | weeeird |
| 03:29:38 | brixen | yeah |
| 03:44:09 | slava | hi tarcieri |
| 03:46:18 | slava | brixen: have you guys thought of doing something like tuple arrays in rubinius, even if only for internal use? |
| 03:47:55 | brixen | I think evan has |
| 03:48:41 | brixen | I don't have empirical data on how common homo arrays are |
| 03:48:47 | brixen | might make everything slower |
| 03:49:09 | slava | I haven't actually used them for anything yet |
| 03:49:27 | slava | the guy who did unicode support wanted to use them for some unicode data tables, but he's busy with school these days |
| 03:49:36 | brixen | ahh |
| 03:50:02 | slava | "homo" arrays for numeric types are a lot more useful I think |
| 03:50:07 | brixen | yeah, we've talked about a vector of immediates for unicode |
| 03:50:25 | slava | float-arrays being the most useful of those, we use those all over the place, since it saves a ton of overhead on boxing |
| 03:50:33 | brixen | right |
| 03:50:40 | brixen | that's a great use case |
| 03:51:48 | slava | once you eliminate as much runtime dispatch as possible the next perf wall you hit with dynamic languages is heap layout |
| 03:51:58 | slava | so I've been thinking about that a bit lately |
| 03:53:26 | brixen | what are you thinking? |
| 03:54:23 | slava | I don't have any concrete ideas really |
| 03:57:51 | headius | so do you just represent homogeneous arrays as their own types? |
| 03:57:55 | headius | FloatArray.new(size)? |
| 03:58:03 | headius | I didn't read through your whole post |
| 03:58:15 | slava | yes |
| 03:58:41 | headius | we could probably provide that now backed with Java arrays |
| 03:59:08 | slava | what about homogeneous arrays of objects? java doesn't really allow that |
| 03:59:10 | headius | keeping values unboxed when passing them around would take a little doing though |
| 03:59:13 | slava | where the objects are stored directly in the array |
| 03:59:25 | headius | as values? no, no support for that |
| 03:59:29 | slava | although you could generate bytecode to do it |
| 03:59:47 | headius | not really |
| 04:00:17 | headius | you could have an array of type Object[] and use chunks of it for object state, but everything would be boxed and untyped throughout |
| 04:00:36 | slava | yeah, but ruby ivars are Object anyway right? |
| 04:00:39 | headius | you can't have an array hold both primitive values and references |
| 04:00:55 | headius | yes, and jruby's ivar tables are already an array |
| 04:01:14 | headius | but it's a separate array referenced by containing object |
| 04:53:46 | brixen | cuckoo hash is extremely sensitive to load factor > 0.5 |
| 05:30:37 | ddub | brixen: don't let it get that high :) |
| 05:32:03 | brixen | ddub: no kidding ;) |
| 05:32:50 | brixen | ddub: it's interesting how badly it drops off |
| 05:33:41 | ddub | the difference between taking a seat and playing musical chairs |
| 05:34:13 | brixen | well, the difference between taking a seat and the whole circle playing musical chairs |
| 05:34:22 | brixen | and rehashing |
| 06:51:04 | tarcieri | lol |
| 06:51:20 | tarcieri | is this in bad form: http://www.nabble.com/Pythonic-indentation-(or%3A-beating-a-dead-horse)-td23624907i60.html#a236647 57 |
| 06:52:24 | slava | Pythonic |
| 06:52:27 | slava | what the fuck does that even mean |
| 06:52:43 | tarcieri | heh |
| 06:52:43 | slava | my cock is pythonic |
| 06:52:52 | tarcieri | serpentine? |
| 06:57:46 | tarcieri | I'm surprised a 100 line link covered all the edge cases I came up with |
| 07:01:11 | ddub | so someone wants ruby to have whitespace indentation to define blocks like python does? |
| 07:01:24 | ddub | thats like, one of my least-liked features of python |
| 07:02:21 | tarcieri | I should take that script and find a bunch of edge cases it doesn't cover |
| 07:05:25 | evan | tarcieri: nah, you're fine. |
| 07:05:40 | evan | i personally would have pulled back before "right cunt" |
| 07:05:45 | evan | but hey, thats my style yo. |
| 07:05:52 | tarcieri | heh |
| 07:06:02 | tarcieri | yeah that might've been a bit far |
| 07:07:07 | evan | I think you ended it fine by saying, basically, "cool you got a regex to work on a few cases. good luck getting rubyists to use it." |
| 07:07:34 | evan | personally, looking at that code he got to run made me go "ug, this is ugly." |
| 07:07:45 | tarcieri | yes |
| 07:09:48 | ddub | I usually solve these sorts of disputes by outright ignoring the person |
| 07:10:03 | evan | personally on this discussion, i take the tack |
| 07:10:10 | ddub | nothing deflates their hopes of victory and superiority like nothing |
| 07:10:15 | evan | "go for it, let me know when we can play with it." |
| 07:10:32 | evan | i'm not going to say it sucks or is impossible or whatever, i don't need to waste my breath |
| 07:10:45 | evan | if they've got the drive, let them try it. |
| 07:10:55 | evan | you can't save them from themselves. |
| 07:11:30 | tarcieri | was trying to go over the edge cases he ran into actually trying to implement this with a Python-style lexer |
| 07:11:37 | ddub | I recommend you call your python + ruby hybrid "pubey" |
| 07:11:45 | tarcieri | lol |
| 07:12:23 | evan | tarcieri: yep, you were trying to help |
| 07:12:29 | evan | but i don't think he wanted help |
| 07:12:34 | evan | he wanted to hear it was a great idea |
| 07:12:37 | rue | Stupid Nabble |
| 07:13:14 | tarcieri | I think he wanted validation that anyone who opposed the idea is a retard |
| 07:13:35 | evan | right |
| 07:13:35 | tarcieri | props to the guy who wrote this script though |
| 07:13:43 | evan | i don't think it was an invite to have a discussion |
| 07:13:43 | tarcieri | it's handling all the edge cases I throw at it |
| 07:15:24 | tarcieri | oh wait |
| 07:15:26 | tarcieri | spoke too soon |
| 07:16:27 | evan | is it just running regexp transforms on the source? |
| 07:16:49 | tarcieri | yes |
| 07:17:06 | tarcieri | symbols are totally broken |
| 07:17:13 | evan | as they would be |
| 07:17:17 | evan | using the ambigious : |
| 07:17:17 | tarcieri | not sure how you're supposed to do them |
| 07:17:24 | evan | thats a great band name |
| 07:17:26 | evan | ambigious colon |
| 07:17:28 | tarcieri | lol |
| 07:17:34 | evan | whats it mean? it's ambigious! |
| 07:17:40 | tarcieri | expressions Python would do implicit line joining on don't work |
| 07:17:51 | tarcieri | it just barfs |
| 07:18:17 | evan | like? |
| 07:18:18 | evan | i'm curious |
| 07:18:22 | tarcieri | [ |
| 07:18:24 | tarcieri | 1, |
| 07:18:25 | tarcieri | 2, |
| 07:18:26 | tarcieri | 3 |
| 07:18:26 | ddub | I'll have to run that by my doctor next time I go in |
| 07:18:27 | tarcieri | ] |
| 07:18:36 | ddub | "doc, I was thinking I might have ambiguous colon" |
| 07:18:37 | tarcieri | call a method with a block on that |
| 07:18:50 | tarcieri | it just doesn't detect whatever it's trying to detect |
| 07:19:08 | ddub | tarcieri: problem is, now after calling him a cunt you probably shouldn't share :) |
| 07:19:17 | tarcieri | heh |
| 07:19:25 | tarcieri | yeah I'm done arguing I think |
| 07:19:40 | tarcieri | someone emailed me a "Bravo" email for calling him out on being a troll |
| 07:19:44 | tarcieri | I think it's time for DNFT |
| 07:19:47 | ddub | maybe someone else here can explain that he has a case of ambiguous colon |
| 07:19:50 | ddub | and recommend more fiber |
| 07:19:57 | tarcieri | heh |
| 07:20:18 | evan | ddub: or a better keyboard? who knows, it's ambigious! |
| 07:21:12 | ddub | all I ask is that if someone posts a failing case around the ambiguous colon, that they try to work in a reference to "colon blow" |
| 07:21:21 | tarcieri | haha |
| 07:21:32 | evan | they might need new super colon blow to debug it! |
| 07:21:40 | evan | 90s SNL ftw |
| 07:23:00 | tarcieri | heh |
| 07:23:29 | rue | Well, for what it is worth, I will take whitespace over Potion's "solution" |
| 07:24:01 | evan | whats that "solution" ? |
| 07:24:09 | tarcieri | when I got rid of the indent sensitive stuff in Reia and it started looking like Ruby with all the niceties that Python does with mandatory parens, I was like "wow, this rules" |
| 07:24:14 | evan | does it send the program via whale sounds to _why for parsing? |
| 07:24:31 | rue | Hm. Should offer a counter-solution of using ASCII pipes to draw boxes around the blocks |
| 07:24:35 | tarcieri | it's a language I think any Ruby programmer could learn without too much hassle |
| 07:24:45 | evan | tarcieri: sweet! |
| 07:24:51 | evan | how's it going btw? |
| 07:25:01 | tarcieri | pretty well |
| 07:25:05 | tarcieri | Chad Fowler seemed to like it |
| 07:25:24 | tarcieri | I've been working on a new compiled form sort of loosely based off .rbc |
| 07:25:31 | evan | ah cool! |
| 07:25:48 | rue | evan: Something weird like _say terminates previous say (regardless of intervening nesting) |
| 07:26:24 | manveru | tarcieri: i wonder, would you accept a patch that adds Main::p ? |
| 07:26:42 | tarcieri | manveru: sure, although I really need to fix Main |
| 07:27:01 | tarcieri | at Erlang Factory I learned of the perfect way to implement Main in an Erlang system |
| 07:27:10 | evan | rue: huh. |
| 07:27:13 | evan | strange. |
| 07:27:22 | evan | strugs at potion |
| 07:27:26 | evan | shrugs. |
| 07:27:28 | manveru | tarcieri: a gen-server that responds to different methods? |
| 07:27:38 | manveru | hides |
| 07:27:42 | tarcieri | manveru: each process in Erlang has an associated "error handler" |
| 07:27:50 | tarcieri | that's how Erlang does automatic code loading |
| 07:28:03 | manveru | so kinda like method-missing that searches for updates? |
| 07:28:26 | tarcieri | yeah, but for me "method missing" is part of the message processing |
| 07:28:44 | tarcieri | this would be for unrecognized function calls |
| 07:29:06 | tarcieri | so if a "local" function call doesn't work, it can retry it on main |
| 07:29:12 | tarcieri | and if that fails, then the function really doesn't exist |
| 07:29:19 | tarcieri | I would like people to be able to define methods on main |
| 07:29:26 | manveru | nods |
| 07:29:29 | evan | ok, time to teach the jit about splat! |
| 07:29:37 | manveru | i don't care so much about other modules, but Main would be very useful |
| 07:29:37 | tarcieri | so "def" is a true expression you can use anywhere |
| 07:30:10 | tarcieri | Ruby is beautiful that way |
| 07:30:22 | evan | i was giving a friend a crash course it ruby |
| 07:30:26 | tarcieri | everything is an expressions and all expressions have meanings in all scopes |
| 07:30:29 | evan | about how class bodies are just code |
| 07:30:45 | evan | it's really something people struggle with at first |
| 07:30:51 | evan | but eventually realize the power. |
| 07:31:03 | rue | evan: Didja make it over, by the by? |
| 07:31:04 | manveru | heh, yeah :) |
| 07:31:25 | manveru | tarcieri: my eventual goal would be implementing something like attr_accessor |
| 07:31:44 | evan | rue: no, ended up going to dinner with a couple of guys that had been doing work there |
| 07:31:44 | tarcieri | manveru: yeah for sure... something that needs class bodies, metaclasses, and metaprogramming |
| 07:31:46 | manveru | with a somewhat nicer name... |
| 07:31:48 | evan | that were in from out of town |
| 07:31:51 | tarcieri | which I'd like to get to |
| 07:32:00 | evan | we were all hungry, so we headed to dinner directly. |
| 07:32:06 | rue | Heh |
| 07:32:15 | evan | rue: hopefully next month i'll have more notice |
| 07:32:24 | evan | driving up there is fun |
| 07:32:32 | evan | i get to drive the bizarre, california highway #2 |
| 07:32:36 | manveru | tarcieri: what's your reason for working on reia? |
| 07:32:38 | evan | which is like a fucking race track |
| 07:32:45 | evan | it's 5 lanes in both directions |
| 07:32:56 | evan | and is only about 10 miles long |
| 07:33:14 | evan | i kept looking down and going "oops! over 90, better slow down." |
| 07:33:31 | rue | Significant whitespace would be ideal, I think, provided that 1. the whole tab/space thing got sorted out somehow and 2. the language would not have to crutch on statements rather than expressions |
| 07:33:35 | tarcieri | manveru: frustrations with Erlang, frustrations with Ruby |
| 07:33:52 | manveru | :) |
| 07:33:55 | tarcieri | Erlang has a crappy syntax, it's full of boilerplate, and doing anything with strings is a nightmare |
| 07:34:00 | tarcieri | Concurrency and I/O suck balls in Ruby |
| 07:34:17 | rue | evan: Haha, yeah, "just going with the flow of traffic, officer" |
| 07:34:19 | manveru | ok... and fixing syntax is easier than fixing ruby :) |
| 07:34:29 | tarcieri | yes |
| 07:34:43 | tarcieri | hard to say where Reia falls semantically between Ruby and Erlang |
| 07:34:49 | tarcieri | it's closer to Erlang |
| 07:34:51 | manveru | i'm quite interested since i heard word that erlang finally added unicode handling |
| 07:34:53 | tarcieri | but with a Ruby-like syntax |
| 07:35:01 | evan | what the... |
| 07:35:09 | evan | it seems |
| 07:35:09 | evan | if(vmm->total_args == 0 and args.total() == 0) { |
| 07:35:12 | evan | is valid C++ |
| 07:35:22 | evan | and i wrote it... |
| 07:35:25 | rue | Well* |
| 07:35:27 | tarcieri | manveru: and we can talk in #reia if you want... don't want to interrupt the rbx debugging here |
| 07:35:30 | tarcieri | heh |
| 07:35:33 | manveru | k |
| 07:35:55 | evan | i... don't even know what it does! |
| 07:36:42 | rue | It is exactly equivalent to && |
| 07:36:50 | evan | wtf |
| 07:36:53 | evan | really? |
| 07:37:00 | evan | i can't even find anyone that lists and as a keyword |
| 07:37:16 | rue | 'Es. There is 'bitand', 'bitor' and all the others you would expect |
| 07:37:25 | evan | really... interesting. |
| 07:37:30 | evan | where do you see any info on these? |
| 07:37:41 | rue | So we should totally s/&&/and/g |
| 07:38:06 | evan | oh, the wikipedia page lists them! |
| 07:38:08 | rue | Um, recesses of my mind somewhere |
| 07:38:32 | rue | I thought it was neat at some point |
| 07:38:40 | evan | rad! |
| 07:38:51 | evan | it's certainly easier to read |
| 07:38:53 | rue | Combined it with inheritance simulated through template metaprogramming...go figure |
| 07:39:18 | evan | c++ is crazy yo. |
| 07:39:53 | scoopr | http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html |
| 07:40:01 | scoopr | you can have them in c too! |
| 07:40:01 | rue | Haha |
| 07:40:19 | evan | cute! |
| 07:40:42 | rue | `int* yay = bitand my_int;` |
| 07:40:54 | scoopr | eesch =) |
| 07:41:54 | scoopr | of the unforseen keywords in c++, I hated that I couldn't use 'far' and 'near' as variable name in msvc .. |
| 07:42:46 | rue | Yeah, MS had some other weirdness in there too |
| 07:43:39 | rue | `void foo(std::string bitand wee) { ... }` |
| 07:44:04 | scoopr | you might want to const that! |
| 07:44:17 | scoopr | ;) |
| 07:44:56 | rue | Heh |
| 07:45:49 | evan | me thinks that taking a weeeee bit too far. |
| 07:45:50 | evan | :D |
| 07:46:34 | slava | heh |
| 07:46:41 | slava | having fun with C++ guys? |
| 07:46:47 | evan | yes |
| 07:46:59 | tarcieri | slava: you are too there eh? |
| 07:47:09 | evan | how come they didn't add an alias for ( or ) |
| 07:47:10 | scoopr | std::string bitfar wee |
| 07:47:46 | evan | void bitor func open_paren std::string bitand name close_paren curly_brace_left |
| 07:47:50 | rue | Eeexcellent |
| 07:47:57 | slava | evan: so much more readable! |
| 07:48:03 | slava | no confusing punctuation |
| 07:48:03 | tarcieri | hehe |
| 07:48:15 | evan | :D |
| 07:48:55 | rue | std nerd string |
| 07:49:09 | evan | 4 eyes? |
| 07:49:18 | rue | ;;) |
| 07:49:25 | evan | :) |
| 07:49:37 | slava | evan: how's the jit going |
| 07:49:43 | evan | pretty good |
| 07:49:54 | evan | i've missed a few things related to argument handling |
| 07:49:58 | evan | that i'm fixing now |
| 07:50:11 | evan | i'm experementing with a call counter here |
| 07:50:26 | slava | I started working on a new codegen but got sidetracked by getting rid of GNU extension usage in the VM |
| 07:50:31 | rue | Adding stuff at a decent pace, certainly |
| 07:50:33 | evan | now that LLVM will just say "sorry, this function is invalid" if the jit constructs bad IR |
| 07:50:59 | rue | Yes, GNU/C++ is bad...we still have typeof in there? |
| 07:51:14 | slava | I was using register variables |
| 07:51:18 | slava | its a fair bit of work getting rid of those |
| 07:51:19 | evan | is typeof a GNU extension? |
| 07:51:24 | slava | no, typeof is RTTI |
| 07:51:24 | evan | slava: you got rid of those? |
| 07:51:29 | slava | evan: in the process of |
| 07:51:42 | slava | evan: still have a bunch of asm to redo |
| 07:51:50 | evan | interesting. |
| 07:52:00 | slava | my goal is to compile with MSVC on windows |
| 07:53:07 | rue | slava: No, type_info is RTTI |
| 07:53:27 | evan | typeof is C i think |
| 07:53:31 | evan | we used it in normal C |
| 07:53:37 | evan | for some macros |
| 07:54:01 | slava | oh |
| 07:54:01 | rue | Just a GCC (and others') extension |
| 07:54:12 | rue | I think they have it in 0x |
| 07:55:50 | rue | slava: Ha, double-take...you mean register variable as in with the register name? |
| 07:55:58 | evan | slava: haha |
| 07:55:59 | evan | er |
| 07:56:00 | evan | rue: hah |
| 07:56:05 | evan | i just imagined you doing a spit take |
| 07:56:11 | evan | wa WA! |
| 07:56:20 | rue | Heeey |
| 07:56:32 | slava | rue: eg, register int foo asm("%eax"); |
| 07:56:48 | rue | Yeah |
| 07:57:24 | tarcieri | evan: so when you create a CompiledMethod to do eval (that's what you do, right?) do you effectively decorate the code so as to return the resulting binding? Or how does that work? |
| 07:58:12 | evan | tarcieri: we create a CompiledMethod, yes |
| 07:58:15 | evan | but no decoration |
| 07:58:18 | evan | it's a normal method |
| 07:58:29 | evan | what we do is piggy back on BlockEnvironment |
| 07:58:31 | tarcieri | how do you get the resulting binding then? |
| 07:58:36 | evan | we don't |
| 07:58:42 | scoopr | hm, apparently |
| 07:58:43 | scoopr | adfg |
| 07:58:50 | tarcieri | orly... does Ruby's eval just accept a binding as input? |
| 07:58:54 | evan | when you do an eval, it's like synthesing a block from a string |
| 07:58:58 | scoopr | hm, apparently 'typeid' is an 'operator' .. I wonder, can you overload it :P |
| 07:59:03 | evan | tarcieri: yeah, just on input |
| 07:59:09 | tarcieri | i c |
| 07:59:11 | evan | tarcieri: our BlockEnvironment could easily be returned |
| 07:59:24 | tarcieri | yeah ok |
| 07:59:27 | tarcieri | you and your mutable state |
| 07:59:28 | tarcieri | heh |
| 07:59:35 | evan | WEEE |
| 08:00:42 | evan | brb |
| 08:10:22 | brixen | I am finding R to be quite a nice tool |
| 08:11:45 | evan | Arrr |
| 08:11:53 | evan | thar be pirates in ye stats! |
| 08:12:18 | brixen | heh |
| 08:12:26 | rue | Wait, what? "R, also called S" |
| 08:12:52 | brixen | evan: so, I combined the two tables into one with h2() using an offset for a modest gain |
| 08:13:01 | brixen | I'm adding c=1 probing now |
| 08:13:17 | evan | neat! |
| 08:13:48 | brixen | I think that based on the simplicity of the cuckoo code all together that it should jit better |
| 08:14:02 | brixen | ie, the iterator is just a walk down a vector |
| 08:14:06 | brixen | etc |
| 08:14:24 | evan | nice |
| 08:14:26 | brixen | instead of going over links in the chained buckets |
| 08:15:40 | evan | sure |
| 08:16:14 | rue | Was there a particular reason why hash insertion order was preserved? |
| 08:16:25 | evan | eh? |
| 08:16:37 | rue | The MRI change |
| 08:16:42 | evan | oh |
| 08:16:50 | evan | it made it more friendly i think |
| 08:17:05 | evan | not that i really agree |
| 08:17:16 | brixen | I think it's ridiculous |
| 08:20:34 | manveru | rue: i think it's faster |
| 08:20:45 | manveru | for iteration |
| 08:21:10 | evan | manveru: very very minorly maybe |
| 08:21:15 | manveru | nobody could really bench it |
| 08:21:17 | evan | because iteration now walks a linked list |
| 08:22:19 | manveru | well, it would be nice to turn that behaviour off :) |
| 08:22:47 | manveru | or randomize somehow |
| 08:23:02 | manveru | just so my specs fail when i rely on order |
| 08:23:30 | brixen | manveru: run them under 1.8.6 :) |
| 08:23:49 | manveru | the lowest ruby i have is 1.8.8dev |
| 08:24:22 | manveru | and i'm running all my stuff in 1.9 since a while |
| 08:24:22 | brixen | how's that working for you? |
| 08:24:23 | brixen | I still have no idea what 1.8.8 is |
| 08:24:38 | manveru | dunno... doesn't seem any different |
| 08:24:46 | brixen | than which? |
| 08:24:53 | manveru | 1.8.7 |
| 08:24:55 | brixen | ah |
| 08:25:14 | brixen | I wonder why it's .8 then |
| 08:25:26 | manveru | because it's what's going to be .8 |
| 08:25:47 | brixen | that's a bit circular :) |
| 08:25:53 | manveru | lol |
| 08:26:02 | manveru | well, it is 1.8.8dev, not 1.8.8 proper |
| 08:26:24 | manveru | the version in svn is bumped right after the release |
| 08:27:22 | manveru | rubygems complained a bit because it couldn't parse my RUBY_VERSION though |
| 08:27:49 | manveru | but i'm running on the svn version since years now... no reason to change that |
| 08:29:18 | evan | manveru: have you run into problems with ramaze using 1.8.7+ features that people using it under 1.8.6 didn't have? |
| 08:30:05 | manveru | there's one problem, yeah |
| 08:30:15 | manveru | but i've been too lazy to change it, since it's in a little-used method |
| 08:30:40 | manveru | apart from that i try to keep my library code compatible |
| 08:30:54 | evan | gotcha |
| 08:31:42 | manveru | though any new libraries i make will target 1.9 |
| 08:32:13 | manveru | ah, there it is: obfuscated = email.to_s.each_byte.map{|c| "&#%03d" % c}.join |
| 08:32:32 | evan | so you're leaving 1.8 behind soon? |
| 08:32:39 | manveru | i guess i could use gsub with //n instead |
| 08:32:48 | manveru | yes |
| 08:33:09 | manveru | most people picking up ramaze these days ask for 1.9 support (at least the ones i talk with) |
| 08:33:18 | manveru | and a lot are running 1.9 already |
| 08:33:59 | evan | interesting. |
| 08:34:21 | manveru | it seems like new people usually go for the highest version |
| 08:34:47 | manveru | although there are still some libs that need a little manual nudging to work |
| 08:35:06 | evan | well, ruby-lang.org only lets them download 1.9 |
| 08:35:12 | evan | so i guess i'm not surprised. |
| 08:35:19 | manveru | and god knows when the vim guys decide to add support |
| 08:35:42 | manveru | that was ugly to patch... |
| 08:36:50 | manveru | well, i see the only reason to stick with 1.8 these days is that some libs won't work out-of-the-box |
| 08:37:11 | manveru | like mongrel having silly 'when :' in one place, but being compatible otherwise |
| 08:37:30 | manveru | most of those could be made compatible with a small maintenance release |
| 08:37:56 | manveru | that's probably where github will have an edge |
| 08:38:38 | evan | yeah |
| 08:38:49 | evan | makes we worried that we should think more about 1.9 support. |
| 08:39:17 | rue | Hm, does the Hash implementation maintain two data structures, then? |
| 08:39:22 | evan | no |
| 08:39:32 | evan | the entry structs themselves are nodes in a linked list |
| 08:39:37 | evan | so it's 2 data structures in one |
| 08:39:59 | evan | each bucket now has next_bucket, next, prev |
| 08:40:09 | evan | next/prev for the list, next_bucket for the chaining |
| 08:40:32 | evan | so an extra 2 words per entry in the hash table |
| 08:41:09 | rue | Right, yes, it just has the hash indexing in front |
| 08:41:30 | evan | yes |
| 08:41:46 | rue | It does somewhat limit implementation options, assuming performance is a concern |
| 08:41:55 | manveru | just waits for people to ask for Hash#reverse! |
| 08:42:38 | manveru | rue: the core devs pointed out that the ordering is an implementation-detail that might not be ported to other impls. |
| 08:43:00 | rue | Oh, yeah, no-one will be relying on it |
| 08:43:16 | evan | *eyeroll* |
| 08:43:28 | manveru | :P |
| 08:43:31 | manveru | exactly... |
| 08:45:09 | rue | I think a guarantee that the iteration order is always the *same* might have been appropriate...but just one more vessel clogging up the waterways |
| 08:46:25 | evan | it's a bloody hash table |
| 08:46:35 | evan | if order matters, you're using the wrong data structure! |
| 08:46:38 | manveru | i remember how hard it was for me to switch from phps all-in-one array/hash bastard to the separate structures in ruby |
| 08:47:07 | manveru | now people will be a lot more tempted to use a hash for everything... |
| 08:47:13 | rue | There is a SortedSet somewhere |
| 08:47:22 | manveru | in set.rb |
| 08:48:44 | evan | imho, insertion order of a Hash makes no sense. |
| 08:48:49 | evan | but what do I know. |
| 08:51:52 | rue | Should rebel. If for nothing else, to show that it is _not_ an implementation detail :) |
| 08:52:06 | evan | heh |
| 08:52:42 | manveru | the fun part starts when replicating set-during-iterate behaviour :) |
| 08:53:26 | evan | eeh gads. |
| 08:53:49 | rue | Next year, we should propose a GSoC project to implement undefined behaviour |
| 08:55:15 | rue | Cross-platform filesystem corruption support |
| 08:56:16 | evan | hehe |
| 09:05:12 | rue | * Maybe. void* where C. |
| 09:06:25 | rue | That pyrb script is not terrible, actually. Obviously nothing like an actually workable solution, but maybe it makes Mr. Haas happy |
| 09:08:06 | rue | At any rate, Python does not suck because of the indentation, but because it is Python |
| 09:09:21 | rue | Hm. Is there a better way to express the ", but" above? I guess just repeating the statement |
| 09:09:28 | rue | Oh, English. |
| 09:09:39 | boyscout | Teach JIT properly about all manner of argument passing - 0805854 - Evan Phoenix |
| 09:10:08 | evan | you could say "At any rate, Python does not suck because of the indenation, but rather because it is Python." |
| 09:10:36 | evan | ", but rather" being the backtracking reason changer of English |
| 09:11:48 | rue | Ah, yes |
| 09:12:16 | rue | I think I am objecting to the repetition of "because", now that I think of it |
| 09:13:39 | rue | There is a clear need for a because-but construct akin to if-else :P |
| 09:13:47 | evan | hehe |
| 09:13:51 | evan | i tried to rewrite it |
| 09:13:58 | evan | the 2 becauses is still the clearest |
| 09:14:11 | evan | because you can imagine the ", but rather" reversing to right after suck |
| 09:14:23 | evan | so what would be the standalone sentence there? |
| 09:14:39 | evan | Python sucks since it is Python |
| 09:14:41 | evan | thats clunky. |
| 09:14:45 | rue | `cause Suck; Python; else; Indentation; end` |
| 09:14:53 | evan | hah |
| 09:15:33 | rue | From which, I guess, comes "The cause of Python's suck is Python, not indentation" |
| 09:16:12 | evan | recursive definition is clunky by nature |
| 09:16:34 | evan | in english |
| 09:16:37 | evan | and probably most languages. |
| 09:17:03 | rue | Except Esperanto |
| 09:17:19 | boyscout | CI: 0805854 success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 09:17:25 | rue | Well, maybe. Perhaps I should pick that up as a hobby |
| 09:18:18 | brixen | the set of reasons python sucks intersect the set of all reasons to suck = { python } |
| 09:18:21 | evan | I had a friend that picked it up at one point |
| 09:18:26 | rue | Although I was looking for something that involves more people, not less |
| 09:18:47 | evan | rue: perhaps an esperanto book club! |
| 09:19:18 | evan | brixen: hehe |
| 09:19:18 | rue | I am pretty sure they only socially shun Esperanto speakers rather than actually beating them up nowadays |
| 09:19:34 | evan | brixen: getting close to rbx -v running with the LLVM JIT in call counter mode |
| 09:19:58 | rue | Karate and Esperanto would be a synergistic hobby combo, though. |
| 09:20:19 | rue | Mm, wait, method call counter? |
| 09:20:30 | evan | yeah |
| 09:20:35 | evan | primitive hot spot detection |
| 09:20:43 | evan | based on the number of times a method has been called |
| 09:20:50 | rue | Trigger at N, sure |
| 09:20:55 | evan | yep |
| 09:21:25 | brixen | evan: awesome! |
| 09:21:51 | rue | The upfront loading option is good to have, too, for server purposes |
| 09:22:17 | evan | rue: yep |
| 09:22:27 | rue | Are all the rbx. config options processed from -X switches now? |
| 09:22:30 | evan | though, it will still do better if it run in a hotspot mode |
| 09:22:39 | evan | so it can make use of the info the interpreter gathers |
| 09:22:58 | evan | rue: they're all available that way |
| 09:23:20 | rue | Goodie |
| 09:23:38 | evan | vm/configuration.hpp |
| 09:23:43 | evan | is the ones that the VM itself checks and uses |
| 09:24:04 | evan | but anything with -X shows up in RUBY_CONFIG |
| 09:24:13 | rue | OK |
| 09:24:29 | brixen | we should probably try to standardize them a bit |
| 09:24:40 | brixen | I litter them wherever I find a need :) |
| 09:24:46 | evan | heh |
| 09:24:54 | evan | well, i've started to pull them together well |
| 09:24:58 | rue | Yeah...this is a good step in the right direction, though, it was much worse |
| 09:25:05 | evan | brixen: i changed all the ones you used |
| 09:25:18 | brixen | in the vm, yes |
| 09:25:30 | brixen | I mean in ruby code using RUBY_CONFIG |
| 09:25:47 | evan | ah. |
| 09:25:56 | evan | well, we should decide if the rbx. prefix is needed |
| 09:26:12 | brixen | yeah, probably could do without that |
| 09:26:28 | brixen | <main subsystem>.<option> |
| 09:26:36 | brixen | -Xprofiler.graph |
| 09:26:47 | evan | sure |
| 09:26:48 | evan | yeah |
| 09:26:58 | brixen | it would be nice to get a list of all the ones used, like you can for the vm ones |
| 09:27:08 | brixen | but we don't register them anywhere for ruby code atm |
| 09:27:11 | rue | The -X part pretty much takes care of the "namespace" |
| 09:27:13 | evan | would it be -Xvm.gil.debug |
| 09:27:14 | evan | then? |
| 09:27:19 | brixen | yeah |
| 09:27:22 | evan | k |
| 09:27:51 | rue | Could always use a 'real' option parser...just need to split it out from the loader though |
| 09:27:57 | evan | brixen: we'll need a play to show them all |
| 09:28:03 | brixen | yeah |
| 09:28:14 | evan | rue: to do what with them? |
| 09:28:26 | evan | configuration.hpp takes care of importing them into values the VM can easily use |
| 09:28:51 | rue | Constructing --help and such |
| 09:29:38 | evan | for things that -X takes? |
| 09:29:56 | rue | Well, all options |
| 09:30:16 | evan | -X isn't an option thats seen by loader.rb |
| 09:30:38 | evan | the driver spys on it |
| 09:30:41 | brixen | the parsing isn't the issue for displaying held, it's somehow registering which -X options do what |
| 09:30:46 | evan | so that the values are available to the VM on startup |
| 09:30:53 | brixen | s/held/help/ |
| 09:31:06 | brixen | when they are used in ruby code |
| 09:31:25 | evan | brixen: yeah, we'll need a list of all -X options available |
| 09:31:34 | brixen | yep |
| 09:31:59 | rue | Right, or more generally, concentrating the option definition and details to as few different locations as possible |
| 09:32:25 | evan | thats what configuration.hpp is for, VM side |
| 09:32:33 | evan | it's one place that all -X options are imported |
| 09:33:43 | evan | it would be easy for me to add a const char* description |
| 09:33:47 | evan | to the configuration items |
| 09:33:48 | rue | 'Es |
| 09:33:58 | evan | so that you could have it print out it's names, values, and what they mean |
| 09:34:04 | evan | if you do |
| 09:34:13 | evan | -Xconfig.print |
| 09:34:17 | evan | it already prints out the names and values |
| 09:34:35 | brixen | yeah, the parsing is good |
| 09:34:57 | brixen | but atm, it's got no way to report that -Xprofiler.graph is/does anything |
| 09:35:04 | brixen | you can make up any -X option |
| 09:35:09 | evan | yep |
| 09:35:17 | brixen | which is good |
| 09:35:19 | brixen | in a way |
| 09:35:30 | brixen | but the downside is no way to inform the user |
| 09:35:42 | evan | it's definitely 'agile' :D |
| 09:35:44 | rue | adds another GSoC project for making up inscrutable options |
| 09:35:49 | brixen | heh, yeah |
| 09:35:54 | evan | how about this |
| 09:36:10 | evan | ad a singleton object at Rubinius::Options |
| 09:36:21 | evan | and, in the class body of the code that uses RUBY_CONFIG |
| 09:36:22 | evan | you do |
| 09:36:40 | evan | Rubinius::Options.add "profiler.graph", "Tells the profile to display call graph output" |
| 09:36:47 | evan | so it's simple to register |
| 09:36:49 | brixen | yeah, I like that |
| 09:36:54 | evan | and Rubinius::Options.add is super easy to grep for |
| 09:36:56 | evan | if need be |
| 09:37:43 | rue | 'Es |
| 09:38:02 | rue | 'Course, still have to slightly improve the loader.rb option parsing too :) |
| 09:38:25 | evan | yes |
| 09:38:33 | brixen | rewriting loader.rb completely is in the roadmap |
| 09:38:35 | evan | loader needs love too |
| 09:39:25 | rue | That is mainly where I figured, say, optparse would be usable |
| 09:39:47 | brixen | I'm thinking of using mspec's option parsing |
| 09:40:15 | rue | Or that, certainly. A bit less weighty |
| 09:40:42 | evan | i'd really prefer something simple and light |
| 09:40:43 | brixen | either way, loader definitely needs proper parsing |
| 09:40:45 | evan | optparse is way too big. |
| 09:40:50 | evan | remember how early on this is. |
| 09:40:52 | brixen | and now we have cmd line specs too |
| 09:40:53 | rue | getopt() |
| 09:41:36 | scoopr | so that -e'puts "Hello!"' would finally work (like it does int MRI)? ;) (currently you need to put space in between, -e 'puts "Hello!"') |
| 09:41:51 | brixen | mspec's parsing works well, is easy to define, and runs on immature impl |
| 09:42:03 | brixen | scoopr: yeah, that :) |
| 09:42:20 | evan | scoopr: it doesn't work? |
| 09:42:24 | evan | oh, the space |
| 09:42:26 | evan | GAH |
| 09:42:39 | scoopr | trips me every time ;) |
| 09:44:19 | evan | hey look! |
| 09:44:21 | evan | matz on a book! |
| 09:44:22 | evan | http://www.amazon.co.jp/o/ASIN/4822234312/amz_ranking-22/ref=nosim |
| 09:44:27 | evan | i wonder what the book is about |
| 09:44:28 | brixen | heh yeah |
| 09:44:31 | brixen | me too |
| 09:44:37 | brixen | matz keeps tweeting that |
| 09:45:02 | evan | ok boys and rue |
| 09:45:05 | evan | i need to get to bed. |
| 09:45:12 | evan | mother-in-law arrives tomorrow morning. |
| 09:45:14 | rue | Something like "living and breathing code", I venture |
| 09:45:26 | manveru | the title is "world of code" |
| 09:45:29 | rue | Yep yep, nites |
| 09:45:48 | rue | I need to go wake up the alternate-reality me that went to bed |
| 09:45:52 | manveru | subtitle is something like "how to become a super-programmer" |
| 09:45:59 | rue | Man, my eyes suck |
| 09:46:23 | rue | manveru: How is your Japanese nowadays? |
| 09:46:28 | manveru | err, "the 14 laws of becoming a super-programmer" :) |
| 09:46:45 | manveru | not so bad anymore |
| 09:46:51 | rue | Hehee, sounds like a diet book |
| 09:47:20 | manveru | i dunno... doesn't sound like a title he'd choose |
| 09:47:50 | rue | It could be a cultural thing too, I suppose? |
| 09:48:00 | manveru | maybe, yeah |
| 09:48:06 | rue | Also, it would be awesome if there actually _were_ laws |
| 09:48:27 | rue | 3 Python strikes and you are out |
| 09:48:42 | manveru | lol |
| 09:50:07 | manveru | sleep well |
| 09:50:16 | rue | Department of Awesome Code |
| 09:50:21 | rue | Special Agent |
| 14:58:01 | jarib | anyone know what's with these failures from `bin/mspec ci` http://gist.github.com/116140 ? |
| 16:28:14 | rue | Looks like weird localisation stuff.. reproducible? |
| 16:28:25 | rue | DST or something maybe |
| 17:05:01 | jarib | rue: hmm, that's possible |
| 17:05:27 | rue | Ar is specific to us, too, so it may have escaped scrutiny |
| 17:05:39 | rue | The top one seems weird...lemme check |
| 17:06:31 | rue | Hm, quite possibly just a poor choice |
| 17:06:48 | rue | jarib_: Are you able to reproduce the egid one? (And verify that the number is correct?) |
| 17:08:58 | jarib | rue: it returns a Bignum, not sure how to verify the number? |
| 17:09:14 | rue | Just print it or something |
| 17:10:03 | jarib | $ bin/rbx -e 'p [Process.egid, Process.egid.class]' |
| 17:10:03 | jarib | [1503010931, Bignum] |
| 17:12:17 | jarib | huh |
| 17:12:45 | evan | morning. |
| 17:12:53 | evan | jarib_: eh? |
| 17:12:57 | rue | Mm, it is evening now.. |
| 17:13:05 | evan | rue: crap! my clock is STILL wrong! |
| 17:13:13 | evan | (btw, I think something is wrong with the sun too...) |
| 17:13:33 | evan | searches "sun repair" in the yellowpages |
| 17:13:58 | jarib | evan: weird, http://gist.github.com/116222 |
| 17:14:11 | brixen | yes, the sun needs repair, it is actually shining in pdx |
| 17:14:14 | rue | jarib_: It does seem somewhat unlikely that that is a valid gid? |
| 17:14:33 | jarib | rue: i wouldn't know |
| 17:14:33 | evan | jarib_: thats an MRI bug |
| 17:14:35 | evan | imho. |
| 17:14:44 | evan | thats fixed in 1.9 |
| 17:14:50 | evan | and jruby has full 32bit Fixnums |
| 17:15:03 | evan | where as we only have 31bit ones (30 bits of data, 1 of sign) |
| 17:15:16 | jarib | evan: there's a spec that says it should be a Fixnum http://gist.github.com/116140 |
| 17:15:20 | jarib | (top one) |
| 17:15:25 | evan | thats spec is wrong. |
| 17:15:34 | evan | yes |
| 17:15:36 | rue | The spec is basically 'the egid is some number' |
| 17:15:36 | evan | the spec is wrong. |
| 17:15:42 | evan | that should be |
| 17:15:45 | jarib | so, change it to Integer |
| 17:15:45 | jarib | ? |
| 17:15:50 | evan | Process.epid returns an Integer |
| 17:15:51 | rue | Integer, yes |
| 17:15:51 | evan | yes |
| 17:16:00 | jarib | aha |
| 17:16:08 | rue | No, that is eGid |
| 17:16:22 | evan | er er. |
| 17:16:23 | evan | yes. |
| 17:16:30 | evan | btw, just for reference: |
| 17:16:30 | evan | irb(main):003:0> 1503010931 > Fixnum::MAX |
| 17:16:30 | evan | => true |
| 17:17:00 | rue | Mm, yeah, so it is the syscall boundary |
| 17:17:31 | evan | what is? |
| 17:17:46 | evan | this, btw is a boundary case for a lot of code |
| 17:17:55 | evan | since that Bignum can still fit in an int |
| 17:19:17 | jarib | evan: any idea about the Ar failures? |
| 17:20:35 | evan | hm. |
| 17:20:49 | jarib | and, should I do a patch to rubyspec or rubinius? |
| 17:21:19 | evan | in this case, rubyspec would be best |
| 17:21:24 | jarib | ok |
| 17:24:43 | evan | oh, I wonder.. |
| 17:25:09 | evan | oh. |
| 17:25:37 | evan | well |
| 17:25:42 | evan | i'm not sure this can be made to work |
| 17:25:50 | evan | Ar is incompatible with numbers that big. |
| 17:26:01 | evan | it has 6 bytes to store the number as ASCII only. |
| 17:27:18 | evan | plus, the Ar isn't clamping the output to only 6 bytes |
| 17:27:30 | evan | so there are 2 bugs |
| 17:28:06 | evan | 1) the ar format just doesn't support uid/gid that large |
| 17:28:18 | evan | 2) Ar, the class, isn't doing the wring thing when they are that large |
| 17:31:36 | jarib | why does it happen only on my machine? it's not that special :) |
| 17:32:44 | evan | it is actually |
| 17:32:51 | evan | you have huge egid results |
| 17:33:38 | jarib | i have no idea what would cause that |
| 17:33:48 | jarib | it's a regular MBP |
| 17:33:49 | evan | what OS are you using? |
| 17:33:52 | evan | ah. |
| 17:33:53 | evan | hm... |
| 17:34:06 | evan | thats weird, because |
| 17:34:06 | evan | irb(main):002:0> Process.egid |
| 17:34:06 | evan | => 20 |
| 17:34:13 | jarib | hmm |
| 17:36:51 | jarib | perhaps it's something that would grow over time? |
| 17:37:04 | jarib | heh, guess not |
| 17:37:16 | jarib | i have another question though |
| 17:38:49 | jarib | evan: what would you like Method#inspect to look like when it's backed by an AccessVariable? |
| 17:39:21 | jarib | atm, it blows up. adding AccessVariable#name will give #<Method: Array#@total (defined in Array)> |
| 17:39:33 | jarib | brixen suggested #<AccessVariable Array @total> |
| 17:39:35 | evan | hm. |
| 17:39:41 | evan | well easiest is to just fix #name |
| 17:39:45 | evan | to return it without the @ |
| 17:40:12 | jarib | so [].method(:length) #=> #<Method: Array#total (defined in Array)> |
| 17:40:17 | evan | but returning what brixn said is ok |
| 17:40:24 | evan | or even |
| 17:40:50 | evan | #<Method: AccessVariable of @total on Array> |
| 17:41:25 | jarib | i like the last one |
| 17:41:41 | evan | go for it |
| 17:41:47 | jarib | will do :) |
| 17:41:56 | evan | ya just need to make Method and UnboundMethod aware of AccessVariable |
| 17:42:06 | jarib | yep |
| 17:44:11 | rue | That is what I was saying, that large a gid seems unlikely to be correct |
| 17:44:25 | rue | Unless it is a signedness issue or something, maybe? |
| 17:44:40 | jarib | i'm on intel |
| 17:45:19 | evan | rue: well, if it were signedness, i'd expect to just see a wrong high bit |
| 17:45:25 | evan | this has even bit distribution throughout |
| 17:45:32 | evan | so i guess it could be garbage |
| 17:45:46 | evan | jarib_: do you always get that value when you call Process.egid |
| 17:45:47 | evan | ? |
| 17:46:06 | evan | jarib_: are you on 10.5? |
| 17:46:14 | jarib | yes to both |
| 17:46:26 | jarib | oh |
| 17:46:27 | brixen | jarib_: what's your github user? |
| 17:46:30 | evan | hm. |
| 17:46:33 | jarib | brixen: jarib |
| 17:47:12 | brixen | jarib_: ok, added you to rubyspec |
| 17:47:21 | jarib | cool, thanks! |
| 17:47:30 | brixen | thanks for helping! |
| 17:47:35 | jarib | i made a ticket |
| 17:48:10 | brixen | already committed |
| 17:48:23 | jarib | nice :) |
| 17:48:27 | evan | bada bing bada boom |
| 17:48:29 | brixen | I'll update rbx's frozen in a bit |
| 17:48:29 | evan | thats how we roll. |
| 17:48:57 | evan | ok, i gotta head to the airport to pick up my mother-in-law |
| 17:49:04 | evan | i'll be back a little later |
| 17:49:14 | evan | i'm pushing through getting -v running with the JIT |
| 17:49:16 | evan | making good progress |
| 17:49:25 | rue | Cool |
| 17:49:37 | sandal | Anyone have a moment to verify a Ruby 1.9 rubyspec patch for Observable? |
| 17:50:13 | sandal | I haven't put it into patch form yet, but: |
| 17:50:14 | sandal | http://pastie.org/private/hbxu6cf3g5wlt224ui0zw |
| 17:50:55 | sandal | Basically, looking over the code in 1.8.6 vs. 1.9.1 it's pretty clear. The latter uses a hash as its underlying structure |
| 17:52:41 | sandal | if it looks right, let me know and I'll submit. |
| 18:01:38 | brixen | sandal: looks ok to me |
| 18:01:46 | rue | Seems OK, I might be partial to something like `it "returns the number of unique observers"` for the verbal part but that is a matter of taste |
| 18:02:25 | sandal | rue: maybe that is better |
| 18:02:36 | rue | sandal: Will both versions still notify both duplicate observers? |
| 18:02:48 | sandal | rue: actually, no |
| 18:03:05 | sandal | that's why it's a bit of a flawed verbiage in either case |
| 18:03:19 | sandal | basically, @observers = [] in Ruby 1.8.6 |
| 18:03:23 | sandal | and {} in Ruby 1.9.1 |
| 18:03:35 | rue | Well, it probably belongs in a different spec |
| 18:03:45 | brixen | sandal: you should perhal spec that under #add_observers |
| 18:03:50 | brixen | er perhaps |
| 18:04:04 | rue | Right, or wherever the actual notification spec is. Or both :P |
| 18:04:18 | sandal | brixen: that seems like a good idea, and then I could just make a count spec that is neutral |
| 18:04:25 | sandal | by not re-using the same observer |
| 18:04:30 | brixen | yeah, probably better |
| 18:04:34 | rue | Yep |
| 18:04:42 | sandal | okay, will do. |
| 18:05:23 | sandal | rue: probably not in notify observers. |
| 18:05:35 | sandal | It does notify 'all observers' in either case |
| 18:05:46 | sandal | it's the add that has the significant difference |
| 18:05:57 | sandal | because on 1.9, a duplicate replaces the original |
| 18:06:59 | rue | Sure |
| 18:08:01 | rue | The way I was thinking is that, in fact, both 1.8 and 1.9 allow giving the same observer multiple times |
| 18:08:17 | rue | The difference is that 1.9 will only dispatch to one |
| 18:08:37 | rue | s/one/once/ |
| 18:08:50 | rue | Erm. You get the point |
| 18:08:58 | sandal | hmm... I think that's too handwavey though |
| 18:09:20 | sandal | there is a significant difference between replacing and duplicating them in my mind |
| 18:09:25 | sandal | and it happens at insertion |
| 18:10:12 | sandal | I guess I see your point that the behavior is noticeable at notification time |
| 18:10:29 | rue | Well, how do you specify that only one 'copy' is stored? It seems to border on implementation detail |
| 18:10:53 | sandal | I just think that if I had an API for add_observer() |
| 18:11:11 | sandal | I would specify explictly that duplicates would be ignored |
| 18:11:32 | rue | Sure, but how do you find out if that is the case? :) |
| 18:11:32 | sandal | whereas I think this would be out of place and after the fact on notify observers |
| 18:11:41 | brixen | yeah, spec'ing via the notification received is more about observing (no pun intended) vs looking at how it's generating the observed behavior (ie using {} ) |
| 18:12:11 | brixen | but, it puts the spec in an odd place for implementers |
| 18:12:21 | brixen | who would probably look at the spec for adding observers |
| 18:12:45 | sandal | brixen: yeah, I think the point is that if you put it on notify, it doesn't implictly cover count at all |
| 18:12:48 | rue | Technically, 1.8 could store all in an Array and just weed out duplicates at dispatch time |
| 18:13:07 | sandal | rue: sure, but it doesn't. The count is seen immediately |
| 18:13:11 | sandal | before any dispatch |
| 18:13:31 | sandal | and that's not an implementation detail, it's a behavior |
| 18:13:53 | brixen | sandal: I would probably put the spec on adding the observer, but use the dispatch to observers instead of count |
| 18:14:16 | brixen | because, conceivably, you could keep a unique count, but dispatch the # of times the observer was added |
| 18:14:46 | brixen | in the count spec, you can show that count is different if you add the same observer |
| 18:14:50 | rue | Right, the interface for 1.8 is that it will dispatch multiple times to the same observer, and that the count is the number of notifications that will be generated |
| 18:14:55 | brixen | different or the same, based on version |
| 18:19:59 | sandal | Alright, let me see what I can whip up here. |
| 18:24:58 | sandal | brixen: here is my reworked count spec. http://pastie.org/private/es97gbpegmsnlprfgyiia |
| 18:25:18 | sandal | I need to add something on add_observer (that works by dispatch) |
| 18:29:42 | brixen | heh, ok kinda nitpicky, but I would say it "returns the number of observers", it "returns the number of unique observers", it "returns the number of observers including duplicates" |
| 18:30:03 | sandal | okay, sure. |
| 18:30:08 | sandal | I appreciate the feedback |
| 18:31:54 | sandal | I think this looks better than before though, since it draws clearer attention to what's actually expected |
| 18:31:55 | brixen | sandal: if you want to put that in a ticket, I'll get you a commit bit and you can commit the others when you finish them |
| 18:32:06 | brixen | yeah, I think it's improved |
| 18:32:19 | sandal | that'd be great. |
| 18:32:32 | sandal | do you want a git formatted patch, or just a link to pastie? |
| 18:32:42 | brixen | fp is the best, you get credit :) |
| 18:35:12 | sandal | where is the tracker? |
| 18:35:42 | sandal | tried http://rubyspec.org/projects/rubyspec/issues/new but it asked me for username pass |
| 18:37:07 | sandal | I see it. I need to register I guess? |
| 18:41:29 | brixen | yeah, you'd need to register, but I'm moving to github issues shortly |
| 18:41:33 | brixen | you could pastie me the fp |
| 18:43:12 | sandal | brixen: http://rubyspec.org/projects/rubyspec/issues/show?id=115 |
| 18:48:08 | brixen | sandal: ok, committed and added you to rubyspec |
| 18:48:17 | sandal | brixen: excellent, thanks. |
| 18:48:18 | brixen | feel free to hang in #rubyspec too |
| 18:48:31 | brixen | we have a bot that reports commits there and helpful people :) |
| 18:48:49 | sandal | I'm really excited about this stuff. |
| 18:48:57 | brixen | cool! |
| 18:49:14 | sandal | This is my first dip into what you guys have been doing, and I'm really impressed with the level of support and general awesomeness |
| 18:49:26 | brixen | well that makes my day! |
| 18:50:13 | sandal | Anyway, I'll do what I can to get a spec in to cover the rest of this problem soon, I'll post on #rubyspec for review when I have it. |
| 18:50:27 | sandal | Right now I need to go back to solve my first problem, writing a blog post about code reading |
| 18:50:48 | sandal | But now it'll include a bit more about RubySpec than I initially intended. :) |
| 18:51:18 | brixen | heh, sweet |
| 18:54:26 | rue | All helpful people are reported |
| 20:00:25 | ddub | you are reporting helpful people? |
| 20:00:31 | ddub | are they in trouble? |
| 20:00:35 | ddub | is glad he is so unhelpful |
| 20:02:42 | brixen | the reporting is done |
| 20:02:51 | brixen | passive, there is no agent |
| 20:10:29 | rue | The Department of Awesome Code can neither confirm nor deny anything that was or was not just said. |
| 20:12:52 | brixen | fooooooooooood |
| 21:10:52 | sandal | evan: here's that tiny doc patch I recommended yesterday |
| 21:10:53 | sandal | http://pastie.org/486823 |
| 21:11:08 | sandal | I can file a ticket if you want, but it's hardly a patch at all :) |
| 21:18:54 | brixen | sandal: I'll commit it |
| 21:19:15 | brixen | between that and your rubyspec patch, you could likely twist evan's arm for a bit :) |
| 21:19:32 | sandal | brixen: thanks. It's so tiny, but yet google failed me yesterday and I only figured it out by accident. :) |
| 21:19:45 | brixen | heh, cool |
| 21:21:08 | sandal | brixen, did you catch the discussion yesterday on this: |
| 21:21:09 | sandal | https://rubinius.lighthouseapp.com/projects/5089/tickets/773-bug-using-attr_accessor-name-at-class-l evel |
| 21:21:28 | sandal | Basically, evan suggested that it's weird that MRI allows for this (and I agree) |
| 21:21:34 | sandal | but JRuby also does |
| 21:22:03 | sandal | brixen: not sure if you wanted a RubySpec patch for that or not |
| 21:23:19 | brixen | well, I think we will have to change the name we use |
| 21:23:28 | brixen | because we can't really get in the way of code |
| 21:23:34 | brixen | even if it's rather dumb code |
| 21:24:14 | sandal | It's just sort of accidental code |
| 21:24:21 | brixen | yeah |
| 21:24:26 | sandal | test/spec does something like this |
| 21:24:31 | brixen | by dumb I mean not really descriptive |
| 21:24:49 | sandal | my_test_class = Class.new(Test::Unit::TestCase) |
| 21:24:51 | brixen | what test/spec does |
| 21:24:55 | brixen | yeah |
| 21:24:57 | sandal | my_test_class.name = "Blah" |
| 21:25:01 | sandal | err |
| 21:25:06 | sandal | yeah |
| 21:25:48 | sandal | Well, if you guys do patch that, then it makes my GoRuCo presentation a lot easier. Because I'm pretty sure that Rubinius will pass all of Prawn's tests if not for this. |
| 21:25:56 | brixen | classes have names and it's silly for test/spec to call what it's assigning a 'name' |
| 21:25:57 | sandal | Since it renders all the examples |
| 21:26:05 | brixen | like evan said, it's more a description |
| 21:26:20 | brixen | but that aside, we probably will need to change what we use |
| 21:26:25 | sandal | yeah, I can push back there. |
| 21:26:26 | brixen | because 'name' is so common |
| 21:26:42 | sandal | just on the principle you just mentioned |
| 21:27:31 | sandal | But name is so common that I can see how this clash happens by accident |
| 21:28:16 | brixen | we could make a special setter that #to_sym's the string :) |
| 21:28:46 | sandal | Heh, but then you're going to have someone doing |
| 21:28:58 | sandal | klass.name = Label.new |
| 21:29:06 | brixen | if you tried to assign a non-sym-able type, it barfs |
| 21:29:16 | brixen | as long as you can #to_s |
| 21:29:22 | brixen | and #to_sym it |
| 21:29:24 | brixen | should be ok |
| 21:30:06 | sandal | I wonder though, how about when people read it back? |
| 21:30:21 | sandal | Potentially same problem on the other side |
| 21:31:42 | brixen | well, the getter could #to_s it |
| 21:32:21 | brixen | but of course, you'd have someone do: c.name = "my *really*\0dumb name" |
| 21:32:22 | brixen | :P |
| 21:32:36 | brixen | and #to_sym would barf |
| 21:34:06 | sandal | it sounds like the fix should either make Rubinius consistent with other implementations, or just be left as is and not supported |
| 21:34:11 | boyscout | Add note about interactive prompt to docs - fb6b228 - Gregory Brown |
| 21:34:36 | sandal | I think either are okay, but a middle of the road approach would just make things kinda-sorta-work which is confusing |
| 21:34:45 | brixen | heh, true |
| 21:36:11 | brixen | since Module#name already exists, I think user code that redefines it does so at their own peril |
| 21:36:25 | brixen | ruby is open, but that is not the same as totally permissive |
| 21:36:36 | brixen | ruby might be easy, but it's not free |
| 21:36:37 | boyscout | CI: fb6b228 success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 21:36:43 | brixen | you pay in exceptions :) |
| 21:36:54 | sandal | Yeah, if that's the feeling, I'm fine with just patching test/spec |
| 21:37:07 | sandal | It may well just be an undefined behavior |
| 21:37:17 | brixen | right |
| 21:37:31 | brixen | changing existing methods should probably be undefined |
| 21:37:36 | sandal | I seriously doubt if you asked Matz he'd have a strong opinion about what should happen when you do something dangerous like that |
| 21:37:50 | sandal | though I sort of wish that name was something a little more descriptive |
| 21:38:03 | brixen | it's like, the impl gets first dibs, if the app overrides it and it still works, lucky you |
| 21:38:14 | sandal | heh, good way to put it |
| 21:38:32 | sandal | no different than overriding library code |
| 21:38:50 | brixen | the other point is that rbx has real typed code in the VM |
| 21:39:06 | brixen | very different from MRI, which just has VALUE everywhere |
| 21:39:14 | sandal | right, I learned about that the other day. |
| 21:39:29 | sandal | I really haven't studied the internals much at all, but now I'm taking an interest |
| 21:39:48 | brixen | some cool stuff, if I do say so myself :) |
| 21:52:09 | jarib | does rubinius use a different readline lib from MRI? seems different |
| 21:52:43 | brixen | it uses the C ext imported from some version of mri |
| 21:52:55 | brixen | lib/ext/readline |
| 21:52:55 | jptix | hmm |
| 21:53:10 | brixen | it may have some stuff disabled, iirc |
| 21:53:16 | jptix | ah, so it will probbly use libedit on os x |
| 21:53:22 | brixen | yeah |
| 21:53:27 | jarib | ah, right |
| 21:53:31 | brixen | which is broken on some versions |
| 21:53:37 | jarib | that's why :) |
| 21:54:05 | brixen | we may be using the rb-readline that luislavena bountied |
| 21:54:15 | brixen | should ask evan about that again |
| 23:25:17 | evan | yay new chair! |
| 23:25:20 | evan | free at that! |
| 23:25:23 | brixen | yay! |
| 23:25:27 | brixen | no better price |
| 23:29:55 | evan | well, they could have paid me to take it. |
| 23:29:55 | evan | :D |
| 23:31:31 | brixen | that wouldn't be a price, that'd be a prize |
| 23:31:33 | brixen | :) |
| 23:37:27 | brixen | evan: sweet, this hash is behaving very predictably now |
| 23:37:35 | brixen | take a look at the spreadsheet |
| 23:37:55 | brixen | adding probing predictably helps on insert, but slows fetch down |
| 23:38:30 | brixen | I'm going to do one more variation based on http://crpit.com/confpapers/CRPITV91Askitis.pdf (2009 paper) |
| 23:38:46 | brixen | a bucketized cuckoo hash |
| 23:39:03 | rue | Interesting |
| 23:41:43 | evan | that doc on bin/rbx running irb should say that it is irb |
| 23:41:45 | evan | not that it's similar. |
| 23:41:59 | brixen | the biggest increase for probing was on a lot of get/sets in small hashes |
| 23:42:18 | brixen | ~10% over existing chained bucket hash |
| 23:42:44 | brixen | ah, yeah it should |
| 23:44:03 | evan | interesting |
| 23:44:07 | evan | i'm happy we've got a nice testbed |
| 23:44:11 | evan | to experiment |
| 23:44:28 | brixen | yeah |
| 23:45:32 | brixen | on pure inserts to 5-10 elt hashes, the improvement over chained buckets is 9-14% |
| 23:45:53 | slava | small changes in the load factor can make a huge difference for probing too |
| 23:46:09 | brixen | based on the hash spy, that's the vast majority of sizes |
| 23:46:26 | brixen | slava: yeah, I saw that last night with plain cuckoo |
| 23:46:43 | brixen | it's extremely sensitive at ~0.5 |
| 23:47:15 | rue | So it turns out that decimal time is quite a mindbender |
| 23:48:34 | brixen | in fact, it is a figment of our imaginations |
| 23:48:56 | brixen | unless you imagine in color, then it may be a pigment |
| 23:55:30 | jarib | any comments on https://rubinius.lighthouseapp.com/attachments/125545/0001-Fix-Method-inspect-arity-when-it-s-backed -by-an-Ac.patch ? |
| 23:56:04 | jarib | i could add AccessVariable#arity instead of doing the checks in Method |
| 23:56:22 | evan | you should |
| 23:56:23 | jarib | also curious if you want specs for stuff like this |
| 23:56:30 | evan | because the code you have isn't right |
| 23:56:40 | evan | the arity is 0 if it's a read, 1 if it's a write |
| 23:56:44 | jarib | ah |
| 23:56:49 | jarib | ok |
| 23:56:51 | evan | WOOP. |
| 23:57:00 | evan | -v just run with the JIT on |
| 23:57:16 | brixen | sweet |
| 23:57:56 | rue | Extremely dandelion, dude |
| 23:58:09 | evan | i need to add a couple of extra counters |
| 23:58:15 | evan | for some JIT stats |
| 23:58:22 | evan | because this is one interesting artifact |
| 23:58:48 | evan | it appears that -v finishes running before 80% of the background compilations complete :D |
| 23:58:55 | evan | background JIT ftw |
| 23:59:19 | evan | this is in full DEV mode |
| 23:59:24 | evan | atm. |