Show enters and exits. Hide enters and exits.
| 00:04:06 | rue | evan: I think YOU are jumping ahead into a specific case over a more general case ;) |
| 00:04:18 | evan | i was. |
| 00:04:20 | evan | no doubt |
| 00:04:33 | evan | but that case helps dictate the low level implementation |
| 00:04:36 | evan | thats why I brought it up |
| 00:04:50 | rue | Yes, it can be useful definitely |
| 00:05:32 | rue | Personally, I would like the option that if I am in the debugger, any error raised will break right there regardless of where I am currently |
| 00:05:45 | agardiner | so there are two issues: intercepting the exception at the point it occurs, and following the control flow as the exception unwinds |
| 00:08:44 | evan | rue: sure, thats fine to have |
| 00:08:54 | evan | they're not mutially exclusive |
| 00:09:00 | evan | discussing all the features of a debugger |
| 00:09:00 | evan | at once |
| 00:09:02 | evan | over IRC |
| 00:09:06 | evan | will make us all INSANE. |
| 00:09:13 | agardiner | agreed |
| 00:09:29 | agardiner | i think we've made a good start |
| 00:09:38 | agardiner | but i for one need to get to bed |
| 00:10:12 | agardiner | can we pick this up again tomorrow? |
| 00:10:21 | evan | yep |
| 00:10:22 | rue | No, it is now or NEVER! |
| 00:10:23 | evan | tomorrow it is. |
| 00:10:24 | evan | HAH |
| 00:10:28 | agardiner | :-D |
| 00:10:31 | evan | rue sounds like a james bond villian. |
| 00:10:33 | rue | *wave |
| 00:10:45 | agardiner | night... |
| 02:23:14 | pabloh | where the rubinius' rubyconf2009 presentation can be watched? |
| 02:25:31 | brixen | pabloh: http://rubyconf2009.confreaks.com/ |
| 02:25:33 | evan | http://rubyconf2009.confreaks.com/ |
| 02:26:05 | brixen | pabloh: the video for rubinius isn't up yet it looks like |
| 02:26:10 | brixen | but keep checking that site |
| 02:26:11 | pabloh | i seems it haven't been uploaded yet |
| 02:26:15 | brixen | yeah |
| 02:26:22 | brixen | it'll be there eventually though |
| 02:26:24 | pabloh | ok, i been for a while :) |
| 02:26:29 | brixen | heh |
| 02:26:35 | evan | i think they had some sync issues |
| 02:26:38 | evan | so they pulled them |
| 02:26:40 | evan | while they work on it. |
| 02:26:44 | brixen | I'm sure they are |
| 02:26:52 | brixen | generally they are very cool |
| 02:26:54 | pabloh | ok |
| 02:27:08 | brixen | way better than oreilly not recording the talks at all :/ |
| 02:29:27 | jarib | i wonder how much ad money they make by just putting up a few videos at first :) |
| 02:34:48 | evan | brixen: i'm going to try add a @start to String |
| 02:34:57 | evan | so that String#substring can use CoW |
| 02:46:22 | brixen | damn expose, dashboard whatever |
| 02:46:28 | brixen | twice in one day it hosed up on me |
| 02:46:36 | brixen | evan: how is @start related to CoW? |
| 02:47:59 | brixen | hmm, so it would use the same bytearray but different start and size? |
| 02:48:34 | brixen | I guess that would potentially cover a lot of cases |
| 02:55:55 | evan | right |
| 03:01:48 | evan | brixen: one case i'm thinking is all the data that comes out of a MatchData |
| 03:03:54 | brixen | right |
| 03:03:59 | brixen | that's a good case |
| 03:04:28 | brixen | I should investigate a full persistent (fp-style) DS for string |
| 03:04:33 | brixen | but after dinner :P |
| 03:04:42 | evan | heh |
| 03:04:49 | brixen | and after I finish fixing the rubyspec fuckups |
| 03:04:58 | brixen | I really need to get CI running for rubyspec |
| 03:05:14 | brixen | ppl are commiting shit for 1.9 without even checking 1.8 :( |
| 03:05:22 | brixen | anyway, I'm starving, bbl... |
| 03:06:00 | evan | :/ |
| 11:27:35 | rue | Woo |
| 11:33:30 | khaase | Net::HTTP seems to be extremely slow on rubinius. Gem install takes ages, getting alot of "connection reset after 2 requests, retrying". |
| 11:42:49 | rue | Good spot for improvement! |
| 11:43:20 | rue | There was a problem with it at some point that I fixed, but this was over a year ago...I do not think it has regressed, it is probably just still slow |
| 12:28:48 | dbussink | khaase: it might even help gem installation, dunno if that uses net http though |
| 13:19:25 | rue | dbussink: Slowness might help gem installations? ;) |
| 13:19:38 | dbussink | rue: fixing it :) |
| 13:19:46 | dbussink | rue: didn't you already do that? ;) |
| 16:17:07 | luislavena | hello guys. |
| 16:20:20 | khaase | btw i get an "Kernel(Rubinius::AST::ArrayLiteral)#first (method_missing) at kernel/delta/kernel.rb:49" |
| 16:51:36 | evan | khaase: open an issue |
| 16:51:50 | evan | khaase: include as much repro information as you have |
| 16:52:48 | khaase | evan: I think there was an issue, at least I found one with google, but the issues ajax interface is not my friend today, as it appears |
| 16:52:55 | khaase | will open an issue |
| 16:55:21 | evan | have you upgraded? |
| 16:55:28 | evan | i've fixed a number of gem speed issues |
| 16:55:44 | evan | and a similar bug to the one you have |
| 16:56:39 | khaase | i did a fresh clone this morning |
| 16:57:09 | khaase | like 9 hours ago |
| 16:57:21 | evan | be sure to clean up your .rbc files. |
| 17:02:54 | khaase | evan: just did an update again, works now... strange |
| 17:06:34 | evan | khaase: hm, ok. |
| 17:06:46 | khaase | sorry for bothering |
| 17:12:03 | rue | Likely stale then |
| 17:15:15 | evan | khaase: no problem. |
| 17:15:28 | evan | man, freenode is having some serious IRC splits problems today. |
| 17:28:06 | evan | adding @start to string has diverged into cleaning up null byte assumptions. |
| 17:30:35 | brixen | evan: you mean where String methods don't account for a null byte embedded? |
| 17:30:43 | evan | actually no |
| 17:30:54 | evan | making it so that C code doesn't. |
| 17:31:24 | evan | we had it mostly done actually |
| 17:31:30 | brixen | ahh ok |
| 17:31:32 | evan | we have a c_str() method on String |
| 17:31:38 | evan | but it adds a null byte if there isn't one |
| 17:31:46 | evan | if you do that to a shared string |
| 17:31:52 | evan | you add a null byte in the middle of some other String |
| 17:31:56 | brixen | gotcha |
| 17:32:01 | evan | so you can't call c_str() on a shared string |
| 17:32:10 | evan | so i'm just reducing the uses of c_str() |
| 17:32:15 | evan | using byte_address() + size() |
| 17:33:17 | brixen | hmmm |
| 17:33:26 | brixen | why not copy if you call c_str() |
| 17:33:38 | evan | I added to_chars() that does that. |
| 17:33:49 | evan | i can't just change c_str to copy |
| 17:33:57 | evan | because everywhere that uses that buffer now needs a free() |
| 17:34:27 | brixen | so what does c_str() do? |
| 17:34:48 | brixen | like when do you use c_str() vs byte_address() + size() ? |
| 17:34:59 | evan | c_str() checks for a null byte |
| 17:35:07 | evan | and sets it if it's not there |
| 17:35:59 | evan | c_str() looks like |
| 17:36:21 | evan | if(byte_address()[size()] != 0) byte_address()[size()] = 0; |
| 17:36:24 | evan | return byte_address() |
| 17:36:31 | evan | but that mutation is invalid on shared strings |
| 17:36:50 | brixen | gotcha, but when would we ever use c_str() then? |
| 17:36:56 | evan | rarely |
| 17:36:58 | evan | if ever. |
| 17:37:07 | evan | i've added the assert |
| 17:37:14 | evan | because c_str had this as a subtle bug already |
| 17:37:21 | brixen | ok |
| 17:37:31 | brixen | so, should we not remove it? heh |
| 17:37:57 | evan | oh probably. |
| 17:38:07 | brixen | just to reduce confusion... |
| 17:38:10 | evan | i'll get to that probably :) |
| 17:38:13 | brixen | ok |
| 17:39:02 | evan | another option is to go a more C++y route |
| 17:39:12 | evan | and add our own tiny string class |
| 17:39:23 | evan | but that doesn't really help |
| 17:39:24 | evan | nm. |
| 17:39:49 | khaase | evan: the error is back... unfortunately the project throwing this error (it's a rails project) may not be published atm. so i'll have to do some digging, i guess. a clean rails project did work just fine. |
| 17:40:11 | evan | khaase: you need to track down the file that it's occuring on |
| 17:40:20 | evan | could you gist the backtrace? |
| 17:40:22 | evan | at least |
| 17:40:44 | khaase | evan: http://gist.github.com/251832 |
| 17:42:13 | khaase | i will do some more digging tomorrow and then file an issue. |
| 17:43:05 | evan | ok |
| 17:43:09 | evan | this looks like the same thing |
| 17:43:09 | khaase | wow, also, a rake db:migrate gives me a segfault |
| 17:43:17 | evan | for some reason, it's not going away. |
| 17:43:32 | khaase | http://gist.github.com/251836 |
| 17:43:36 | Zoxc- | doesn't c extensions use c_str alot? |
| 17:43:36 | evan | basically, that looks like the active_record/base.rb parse problem |
| 17:43:40 | evan | that's been fixed. |
| 17:43:42 | evan | Zoxc-: no. |
| 17:44:04 | evan | khaase: *shrug* haven't seen that before |
| 17:44:06 | evan | open an issue. |
| 17:44:07 | Zoxc | please call me Zoxc :) |
| 17:44:22 | khaase | ok, so it's in the rbc files of the gems |
| 17:44:38 | evan | did you install rubinius? |
| 17:45:12 | evan | ie, use --prefix and rake install |
| 18:08:18 | luislavena | evan: hello |
| 18:08:32 | evan | hello! |
| 18:09:11 | luislavena | I'm building a new version of my VMs (Ubuntu) for Ruby testing, wanted to get Rubinius setup there too |
| 18:09:18 | luislavena | evan: any advice? |
| 18:09:37 | luislavena | evan: my mac is stuck at 10.5 so no snow for it yet (is summer here) ;-) |
| 18:10:04 | evan | heh |
| 18:10:06 | evan | nothing special |
| 18:10:13 | evan | just download, configure, rake |
| 18:10:56 | luislavena | evan: ok, will try ;-) |
| 18:17:41 | evan | brixen: so, I added up removing c_str() |
| 18:17:45 | evan | and adding cpp_str() |
| 18:17:52 | evan | that returns a std::string as a value |
| 18:18:01 | evan | which means the ownership lifetime should be fine |
| 18:19:32 | brixen | that sounds good |
| 18:19:46 | brixen | the c_str() was a handy method, but I understand the issues with it |
| 18:19:52 | evan | yep |
| 18:21:21 | evan | using a std::string is a bit more heavy weight |
| 18:21:25 | evan | but it's correct. |
| 18:21:37 | evan | if more performance is needed |
| 18:21:44 | evan | then the code can be converted to use byte_address() + size() |
| 18:22:35 | ddub | c_str on what object? |
| 18:22:55 | evan | rubinius::String* |
| 18:24:02 | ddub | ahh |
| 18:24:49 | ddub | a rubinius string contains a reference to a bytearray object, correct? |
| 18:26:05 | evan | yes |
| 18:29:07 | ddub | I'm trying to think of a way you could treat the bytearray as a string-like object, but deal with GC moves |
| 18:29:12 | brixen | evan: could you look at spec/frozen/language/break_spec.rb line 137 |
| 18:29:26 | brixen | evan: #count is a 1.8.7+ method |
| 18:29:33 | evan | sure |
| 18:29:45 | brixen | why not just ScratchPad.recorded.should == [....] ie, the full array |
| 18:29:51 | evan | did I write that? |
| 18:29:53 | brixen | yeah |
| 18:29:58 | evan | silly me. |
| 18:30:06 | ddub | smart pointers will continue to be evil black magic until c++0a comes out, at which point they will be grey magic |
| 18:30:08 | evan | fix it however ou'd like. |
| 18:30:17 | evan | you'd |
| 18:30:27 | brixen | evan: sure, just checking |
| 18:30:36 | brixen | in case I'm missing something |
| 18:30:47 | evan | nope |
| 18:30:49 | evan | just me being lazy |
| 18:30:50 | brixen | k |
| 18:30:50 | evan | again. |
| 18:31:59 | brixen | man, Readline is such a freakin PITA for specs :( |
| 18:35:06 | Zoxc | you can't preallocate the size of objects in rubinius to get a fast Array#join or things like that? |
| 18:35:34 | Zoxc | exploits it for fast string concatenation on MRI |
| 18:36:19 | evan | yes |
| 18:36:25 | evan | i also fixed string interp |
| 18:36:33 | evan | so it calculates the final size from the parts |
| 18:36:39 | evan | so |
| 18:36:48 | evan | out = "#{a}#{b}" |
| 18:36:50 | evan | is a lot faster than |
| 18:36:54 | evan | out = a + b |
| 18:36:55 | evan | atm. |
| 18:37:06 | Zoxc | excellent :) |
| 18:37:08 | evan | add more items |
| 18:37:12 | evan | it gets faster |
| 18:37:33 | Zoxc | wrote a template engine which stores stuff into arrays :D |
| 18:38:03 | dbussink | evan: couldn't this be relatively easy applied to + too then? |
| 18:38:17 | evan | well, + is a bad example |
| 18:38:22 | evan | because it does already |
| 18:39:10 | Zoxc | should "#{a}#{b}" be *alot* faster than a + b then or just the overhead of a method call? |
| 18:39:43 | evan | we'd have to benchmark it to see |
| 18:41:07 | Zoxc | flatten!.join vs join then? |
| 18:41:57 | evan | why flatten? |
| 18:44:07 | Zoxc | because I might have nested arrays with more strings, which might get turn into tinyer strings and then concatenated to a large string |
| 18:44:41 | evan | i'm not sure what you're point is |
| 18:44:51 | evan | i don't get why this is related to string interp. |
| 18:45:58 | Zoxc | well I (might/will) use array of (array of)* strings as a replacement for ropes =P |
| 18:47:01 | evan | ok.... |
| 18:47:05 | evan | again, unrelated atm. |
| 18:47:12 | evan | i'm not sure what we're talking about now. |
| 18:48:59 | Zoxc | I like how I can lookup how stuff works in the ruby draft spec, except that I don't make much sense of it :( |
| 19:09:54 | rue | A-ha! I mentioned this about c_str() :P |
| 19:14:18 | rue | brixen: Does output_to_fd not have the old should_output functionality? That should avoid problems with Readline |
| 19:17:59 | brixen | rue: problems like certain functions not defined on a platform? |
| 19:22:08 | rue | Oh, you are speccing Readline itself? |
| 19:25:42 | brixen | I'm just looking at all the failures running the specs against 1.8.6p287 |
| 19:29:15 | ddub | I don't see how a + b could be made fast without short-circuiting string logic |
| 19:29:49 | ddub | odd that "#{a}#{b}" is faster until you think about the assumptions that makes |
| 19:31:36 | Defiler | Yeah, you just need to check to make sure everything has #to_s |
| 19:31:47 | Defiler | and boom MAGIC TIME |
| 19:32:59 | ddub | "foo=#{foo}, bar=#{bar}" could be ["foo=", foo, ", bar=", bar].join |
| 19:34:55 | Defiler | That's what it does pretty much, yeah |
| 19:35:08 | evan | sort oh. |
| 19:35:09 | evan | of. |
| 19:35:10 | Defiler | except it uses string append instead of join on the pieces |
| 19:35:19 | evan | nope |
| 19:35:20 | evan | not anymore. |
| 19:35:26 | Defiler | oh, yeah? |
| 19:35:29 | evan | thats what I just changed. |
| 19:35:40 | evan | all the parts are pushed on the stack |
| 19:35:46 | evan | then one opcode, string_build, is called |
| 19:35:55 | Defiler | aha |
| 19:35:56 | evan | it looks at all of them and calculates the final size of the result |
| 19:36:09 | evan | then copies the data into the result |
| 19:36:45 | Defiler | cool |
| 19:37:38 | ddub | I suppose you could do the same for string addition, after you verify the first argument is a String and that + hasn't been overridden |
| 19:38:22 | dbussink | ddub: well, inside + you can push the other argument and call string_build then, right |
| 19:38:23 | dbussink | ? |
| 19:38:40 | ddub | for two, possibly, not three |
| 19:38:47 | dbussink | ddub: true |
| 19:39:10 | ddub | the other option would be an intermediate object, but since strings are mutable there would be a bunch of edge cases that could happen there |
| 19:39:13 | dbussink | ddub: but could be that the 2 strings case already optimizes a great deal |
| 19:45:19 | ddub | in C++ there was a really cool concept of arithmetic templates a while back for matrix math |
| 19:45:39 | ddub | so for those who are unfamiliar with the horrors of c++, string c = a+b; creates two new objects |
| 19:45:55 | ddub | a temporary with the value of a + b, then a copy of that which is set onto c |
| 19:46:09 | ddub | thats why c++0x has rvalue references |
| 19:46:35 | ddub | so that you can actually say things like, build that new string into the c object |
| 19:47:14 | dgtized | evan: with this string build deal, how is the stack allocated again? I mean what if one of the items is an inspect with millions of constituative objects? |
| 19:47:50 | ddub | arithmetic templates would say, a + b returns a StringConcatenation object with references to a and to b, and that value could be assigned to a string, at which point a new string object would be made |
| 19:47:58 | evan | dgtized: i don't get your example |
| 19:48:19 | ddub | shushes |
| 19:51:13 | dgtized | evan: hmm, I was being idiotic, you just store the reference/pointer to the string on the C stack? |
| 19:51:34 | evan | the result you mean? |
| 19:51:45 | dgtized | the intermediates |
| 19:51:46 | dgtized | but yea |
| 19:51:59 | evan | nothing different than what we do with everything else |
| 19:52:03 | evan | for |
| 19:52:07 | evan | "#{a}#{b}" |
| 19:52:24 | evan | A is evaluated, the result is pushed on he stack |
| 19:52:30 | evan | b is eval, result pushed on the stack |
| 19:52:38 | dgtized | right, but it's just the pointer to the result for A and B |
| 19:52:39 | evan | if they're both locals, it looks like |
| 19:52:41 | evan | push_local 0 |
| 19:52:42 | evan | psuh_local 1 |
| 19:52:44 | evan | string_bulid 2 |
| 19:52:46 | dgtized | you are not storing the entire string |
| 19:52:49 | dgtized | on the stack |
| 19:52:53 | evan | after string_build, the top of the stack points to a String object |
| 19:52:59 | dgtized | and that's what I was for some stupid reason thinking |
| 19:53:00 | evan | dgtized: huh? |
| 19:53:02 | evan | of course not |
| 19:53:05 | dgtized | yea I get it, it's fine I was being an idiot |
| 19:53:08 | evan | the stack only contains object references. |
| 19:53:29 | dwaite | and object immediates like fixnums and symbols |
| 19:53:38 | evan | don't confuse the matter |
| 19:53:41 | evan | those are object references. |
| 19:53:53 | evan | nevermind that the value is encoded within the reference itself. |
| 19:53:56 | dgtized | yup, yup, I got it, was just misreading how the optimization worked |
| 19:54:00 | evan | thats an implementation detail. |
| 19:54:06 | dwaite | yeah, they are just very detailed references :) |
| 19:54:37 | evan | it's in fact fine to consider them references to objects |
| 19:54:47 | evan | just that the memory referenced doesn't actually exist. |
| 19:56:31 | dgtized | evan: wait so is this string_build only for the "#{}" substitutions, or also for Array.join? |
| 19:56:44 | evan | only string interp |
| 19:56:51 | evan | it's got nothing to do with Array#join |
| 19:56:51 | evan | zero. |
| 19:57:27 | dgtized | but if you pushed the separators onto the stack after each string element in an Array being joined ... |
| 20:00:45 | dgtized | it's useless for + or << essentially, but Array.join and I guess to an extent Sprintf are the two other occasions where large strings are being allocated from necessarily a sequence of smaller constituative strings that you should know the length of by the time the arguments are processed |
| 20:01:56 | evan | they can certainly use the same technique |
| 20:02:02 | evan | but no need to use the string_build opcode |
| 20:02:11 | evan | there is no way to access it from highlevel code anyway |
| 20:02:18 | evan | accept doing a string interp. |
| 20:02:21 | dgtized | even as Rubinius.asm |
| 20:02:27 | evan | i guess you could do that |
| 20:02:32 | evan | but it's static |
| 20:02:41 | evan | string_build takes an operand |
| 20:02:48 | dgtized | the number of elements? |
| 20:02:49 | evan | how many things on the stack to take |
| 20:02:54 | dgtized | right ... |
| 20:02:57 | evan | so if you have a method like Array#join |
| 20:02:59 | evan | it's useless |
| 20:03:04 | evan | because you don't know how many you'll have. |
| 20:03:14 | evan | again |
| 20:03:18 | evan | Array#join can do the same thing dynamicly |
| 20:03:26 | dgtized | course you do, it's the length of the Array + Length of Array - 1 for each seperator |
| 20:03:27 | evan | calculate the final size |
| 20:03:39 | evan | thats not the size |
| 20:03:40 | evan | at all. |
| 20:03:47 | evan | you iterate the array |
| 20:03:50 | evan | and get the size of ecah element |
| 20:03:58 | evan | add them together |
| 20:04:17 | dgtized | wait but I thought string_build just popped each string reference off the stack? |
| 20:04:19 | dwaite | dgtized: the dquote string build is static though, you know exactly what arguments are needed to be interpreted at compilation time |
| 20:04:28 | dwaite | and the string_build instruction requires a count |
| 20:04:30 | evan | dgtized: course it does |
| 20:04:36 | evan | but it has to know how many to pop |
| 20:04:41 | dwaite | so array.join would have to generate code to handle that :) |
| 20:04:43 | evan | and it's told staticly. |
| 20:04:51 | evan | push_local 0 |
| 20:04:52 | evan | push_local 1 |
| 20:04:56 | evan | string_build 2 |
| 20:04:57 | evan | see the 2? |
| 20:05:55 | dgtized | but why does the argument to string_build have to be static, why can't it be push_local 0; push_local 1; puch_local 2; # where is the number of elements; and string_build |
| 20:06:10 | evan | it could be |
| 20:06:11 | evan | but it's not. |
| 20:06:23 | evan | nor do I think it should be. |
| 20:06:30 | evan | i assume you mean |
| 20:06:32 | evan | push_local 0 |
| 20:06:34 | evan | push_local 1 |
| 20:06:37 | evan | push_int 2 |
| 20:06:40 | evan | string_build |
| 20:06:46 | evan | actually no |
| 20:06:50 | evan | thats not allowed |
| 20:07:01 | evan | because you can't tell staticly how much stack string_build will use |
| 20:07:05 | evan | and thats a requirement |
| 20:07:19 | evan | no dynamic stack usage is allowed. |
| 20:07:30 | dgtized | ah |
| 20:07:33 | dgtized | ok |
| 20:07:36 | dgtized | I follow |
| 20:09:24 | dbussink | evan: polising it up before unleasing it to the world? :P |
| 20:09:32 | evan | huh? |
| 20:10:36 | dbussink | evan: the string improvements, or is it not finished yet? |
| 20:10:43 | evan | it's in. |
| 20:10:48 | evan | last week. |
| 20:10:56 | evan | well, string_build is |
| 20:11:03 | evan | i'm working on the @start patch now. |
| 20:11:15 | evan | it doesn't work yet. |
| 20:11:32 | dbussink | ah ok, but the cow idea is nice :) |
| 20:11:43 | dbussink | something a lot of vm's do? |
| 20:12:35 | evan | typically yes |
| 20:14:30 | evan | gags on FFI::Platform::File.basenam |
| 20:14:33 | evan | basename |
| 20:14:34 | evan | first |
| 20:14:38 | evan | why the fuck is this code under FFI? |
| 20:14:45 | evan | oh i remember |
| 20:14:50 | evan | someone moved Platform under FFI. |
| 20:14:55 | evan | le sigh. |
| 20:16:28 | dwaite | dbussink: which cow idea? |
| 20:16:35 | dwaite | cow strings? |
| 20:16:40 | dbussink | dwaite: using cow strings |
| 20:16:58 | dbussink | evan: self.expand_path even has a FIXME: this is awful ;) |
| 20:17:12 | dwaite | yeah it depends. gcc moved away from them a while back because they have a ton of lock contention |
| 20:22:43 | dbussink | dwaite: yeah, well, they are in quite a different situation :) |
| 20:27:34 | brixen | evan: do you have any commits to spec/frozen pending? |
| 20:27:45 | evan | hm |
| 20:27:46 | evan | one maybe |
| 20:27:51 | evan | just a whitespace cleanup |
| 20:27:53 | brixen | something you could push |
| 20:28:10 | evan | I think so. |
| 20:28:12 | brixen | ok |
| 20:28:15 | brixen | or even a gist |
| 20:28:22 | brixen | I've got them merged back to rubyspec |
| 20:28:28 | brixen | and I'm trying to fix some stuff and sync rbx |
| 20:28:41 | brixen | major pita this time |
| 20:29:37 | dbussink | brixen: i've committed stuff to both rubyspec and spec/frozen, that's the preferred way right? |
| 20:29:46 | brixen | dbussink: well, depends |
| 20:30:00 | brixen | generally yes, you can do that |
| 20:30:52 | brixen | I'm just going to try to sync weekly |
| 20:31:08 | dbussink | brixen: well, if i can make your life easier, i'd do that, just for you ;) |
| 20:31:10 | evan | brixen: actually, don't worry about this commit |
| 20:31:22 | evan | actually maybe i can test this.. |
| 20:31:23 | evan | one sec. |
| 20:32:09 | brixen | dbussink: appreciated... but there's not really a better way |
| 20:36:21 | boyscout | Whitespace fix - 306c17d - Evan Phoenix |
| 20:36:22 | boyscout | Improve String#split performance - 0e0612e - Evan Phoenix |
| 20:36:22 | boyscout | Abstract all uses of ByteArray::bytes - c4b8ce3 - Evan Phoenix |
| 20:43:04 | boyscout | CI: c4b8ce3 success. 3005 files, 11489 examples, 35634 expectations, 0 failures, 0 errors |
| 20:53:46 | agardiner | evening |
| 21:21:36 | rue | *wave |
| 21:24:33 | dbussink | evan: how are you going to handle reused strings where the original string changes? |
| 21:25:53 | dbussink | evan: or are you using the underlying copy on write principle? |
| 21:32:40 | dwaite | dbussink: actually the situation is very similar - its still a matter of trying to reduce the number of objects in memory. |
| 21:33:47 | dwaite | I'd go as far as to say, toss an object header and encoding bit on the front and the old std::string impl and the rbx impl would be interchangable |
| 21:51:29 | evan | arg. |
| 21:51:43 | evan | adding @start requires a lot of string changes |
| 22:08:26 | dwaite | evan: what is @start? |
| 22:09:44 | evan | making Strings CoW more flexible |
| 22:09:50 | evan | by allowing for a shifted start |
| 22:10:06 | evan | which means that String#substring could reuse the original ByteArray |
| 22:10:17 | evan | and just have @start > 0 with a size |
| 22:22:32 | dbussink | evan: what will happen if the original bytearray is subsequently changed? |
| 22:25:57 | Defiler | copy on write |
| 22:26:33 | dbussink | Defiler: yeah ok, but that could mean a lot more writes too |
| 22:26:40 | dbussink | at least bigger writes |
| 22:26:47 | Defiler | worst case is only as bad as what it does now |
| 22:28:30 | dbussink | Defiler: true yeah, i wasn't really thinking properly :) |
| 22:28:45 | Defiler | yeah, it is ultra wintastic :) |
| 22:28:59 | dbussink | Defiler: although modifying a single char inside a string could be less optimal |
| 22:29:40 | dbussink | Defiler: where you would need to reallocate the bytearray instead of just modyfing a single element |
| 23:03:07 | evan | brixen: poke |
| 23:08:34 | slava | hi evan |
| 23:10:04 | evan | hello slava. |
| 23:11:05 | rue | dbussink: No, you are just doing it at a later time |
| 23:11:22 | rue | sbryant`: Congrats, you have entered Stage 1 of Not Understanding It Either |
| 23:12:05 | evan | sbryant`: what was the most confusing part |
| 23:12:59 | evan | back up |
| 23:13:02 | evan | you mention both rubinius and the ruby-ffi gem |
| 23:13:08 | evan | which one are you talking about |
| 23:13:12 | evan | because they don't share any code atm. |
| 23:14:10 | evan | ok |
| 23:14:34 | evan | which? |
| 23:14:53 | evan | refrain from pronouns until we're discussing a singular thing |
| 23:14:56 | evan | please. |
| 23:17:06 | evan | in which? |
| 23:18:16 | evan | did you read the FFI::Library#attach_function? |
| 23:18:47 | evan | the binding is right there |
| 23:18:52 | evan | on line 97. |
| 23:19:18 | evan | if by binding you mean how a function is hooked up to a method. |
| 23:20:12 | evan | be specific |
| 23:20:19 | evan | i don't know what you mean. |
| 23:20:35 | evan | create_backend is a primitive |
| 23:20:35 | evan | you see that, yes? |
| 23:20:56 | evan | so you need to look at the definition of that primitive. |
| 23:23:00 | rue | <3 ctags |
| 23:23:23 | evan | do you know what primitives are? |
| 23:23:45 | rue | Or just ack :) |
| 23:24:04 | evan | yes, `ack nativefunction_bind vm` will show you it. |
| 23:24:25 | evan | ok |
| 23:24:29 | evan | so you don't know what primitives are. |
| 23:24:39 | evan | thats why you're confused. |
| 23:24:55 | evan | a primitive in a C++ function exported into rubyland as a name |
| 23:25:08 | evan | and a ruby method can bind it's implementation to that name |
| 23:25:18 | evan | so when the method is called, the C++ function is called |
| 23:25:55 | rue | Well, create_backend lives in kernel/ |
| 23:26:22 | Defiler | I'm assuming he found NativeFunction::bind |
| 23:27:00 | evan | / Ruby.primitive :<name> |
| 23:27:00 | evan | syntax in vm declares a C++ function as having that primitive name |
| 23:27:00 | evan | sbryant`: because primitives are not methods. |
| 23:27:00 | evan | Defiler: it would appear not. |
| 23:27:08 | Defiler | aah |
| 23:33:13 | evan | well that was fun. |
| 23:33:17 | evan | got a kernel panic. |
| 23:39:35 | evan | k |
| 23:42:48 | brixen | evan: back... |
| 23:43:40 | evan | i'm trying to figure out how to build the openssl extension |
| 23:43:44 | evan | I think i've got it now. |
| 23:43:47 | brixen | ok |
| 23:43:48 | evan | maybe. |
| 23:44:17 | brixen | which part is problematic, the openssl Rakefile or rakelib/extensions.rake? |
| 23:45:08 | evan | i'm trying to do it without writing an openssl Rakefile |
| 23:45:16 | evan | because the extconf.rb has a whole bunch of logic. |
| 23:45:22 | brixen | oh ugh |
| 23:45:23 | brixen | ok |
| 23:45:46 | brixen | are you using rake-compiler then? |
| 23:46:02 | evan | i could, but i'm just shelling out to the extconf.rb direccly atm |
| 23:46:05 | evan | none the less |
| 23:46:13 | evan | i'm worried that i can't run the extconf.rb under rbx |
| 23:46:18 | evan | because if --prefix is set |
| 23:46:25 | evan | i can't just do "../../bin/rbx extconf.rb" |
| 23:46:29 | brixen | hmm |
| 23:46:45 | evan | well, if i set the RBX_RUNTIME env var |
| 23:46:45 | evan | i should be able to, yes? |
| 23:46:58 | brixen | well, regardless of --prefix being set, the bootstrapping ruby is still used to build |
| 23:47:13 | brixen | rbx is not used to build extensions |
| 23:47:23 | brixen | unless you do rbx -S rake to build |
| 23:47:30 | evan | thats my point |
| 23:47:35 | evan | to use an extconf.rb |
| 23:47:39 | evan | i have to build it under rbx |
| 23:47:48 | brixen | ah yes |
| 23:47:52 | evan | there is no way to use an extconf.rb under MRI but have it build for rbx |
| 23:47:53 | brixen | what a mess |
| 23:48:05 | brixen | well, see Rakefile at the top |
| 23:48:09 | evan | i might just ignore the extconf.rb |
| 23:48:16 | evan | and try and get a Rakefile up |
| 23:48:17 | brixen | I set RBX_RUNTIME and RBX_LIB to run the specs |
| 23:48:24 | evan | which rakefile? |
| 23:48:27 | evan | oh the main one |
| 23:48:28 | brixen | rbx |
| 23:48:58 | brixen | I think taking the time to set up the openssl Rakefile is worth it |
| 23:49:07 | brixen | I *think*... heh |
| 23:49:23 | brixen | le'see |
| 23:50:36 | brixen | man what a mess... |
| 23:50:46 | evan | the crux is that extconf.rb does detection |
| 23:50:51 | evan | and our Rakefiles don't. |
| 23:50:55 | evan | they can |
| 23:50:58 | brixen | sure |
| 23:50:59 | evan | but they don't atm. |
| 23:51:04 | brixen | yeah |
| 23:51:36 | brixen | well, the detection doesn't depend on rbx |
| 23:51:49 | brixen | just the flags to include, link, etc |
| 23:52:01 | brixen | too bad mkmf wasn't actually a library |
| 23:52:52 | evan | ok |
| 23:53:00 | evan | i'm going the "work first, fix later" approach. |
| 23:53:21 | brixen | k |