Index

Show enters and exits. Hide enters and exits.

00:13:10headiusevan: just thought of something else that will probably be next-to-impossible for macruby to support
00:13:29headiusnon-native-thread fibers and fiber-related Enumerator stuff
00:13:33headiuswe're all in the same boat now
00:14:37headiusthough...I suppose you guys could both play setjmp tricks, but that doesn't seem like it would be compatible with your memory models
00:15:02evanwell, don't even need setjmp
00:15:08evanwe can play the same tricks 1.9 does
00:15:23headiuswhat tricks are those?
00:15:29evanin the case of Rubinius, it's a matter of copying the C stack AND the CallFrame chain thats layer on top of it
00:15:39headiusahh right you still have bytecode
00:15:45headiusso you could freeze execution
00:15:53evanin 1.9, it's just a memcpy of the C stack
00:15:59evanbytecode or not, it doesn't matter
00:16:20headiussure it does...unless you can add in the ability to freeze execution in jitted code too
00:16:22evanit's all about rewinding the stack
00:16:33evanfreeze how?
00:16:39headiusfibers need to be resumable
00:16:45headiusso you need to return to them too
00:17:09headiusso yeah, you have to save off the whole stack and then replay it to continue
00:18:04evanyeah
00:18:09evanit's a big copy of data
00:18:12evanno way around that
00:18:39evanand it's still ridiculous that they mandate continuation support now
00:24:33headiusit is
00:24:59headiusI'll have to add project #276 to my list to try to implement continuation support atop MLVM continuations
00:25:17evanheh
01:16:34dgtizedhow is it that scheme efficiently implements continuations?
01:17:14dgtizedis it just easier for it to capture the correct extent of scope?
01:18:37tarcieriCPS vs SSA?
01:18:52boyscoutAdded roadmap. - ef8c0c0 - Brian Ford (gh-pages)
01:18:57tarcieriloves making totally laymen guesses
01:28:01dgtizedtarcieri: perhaps I'm simplifying, but it seems like SSA and CPS form should both reduce the amount you need to save on the stack
01:28:51dgtizedin terms of being aware of what contexts should be saved
01:29:07tarcieridoesn't know
01:29:18tarcieriI wish I implemented my own calls and stuff
01:32:31brixenthere's a very good paper on the topic
01:32:45brixenimplementation strategies for first-class continuations
01:33:16brixenand of course, there are open-source scheme implementations
01:33:27brixenother than that, I wouldn't know off-hand
01:37:13tarcieridoesn't understand why people <3 continuations so much
01:37:25tarcieriI'd rather have... a decent strategy for concurrency
01:37:35tarcieriwhich affords practically the same thing without confusing control flows
01:38:52brixenyeah, I'd rather have screaming fast and comprehensible concurrency
01:42:28brixentarcieri: have you played with Fortress?
01:42:39tarcierinope, although I've seen several people referencing it
01:42:51tarcieriI should really have a lookeroo
01:42:57brixenme neither, thought you might have
01:43:09brixenI should play with scala a bit too
01:43:47brixenjust, you know, to see what they're all missing :)
01:43:52tarcieriheh
01:43:58tarcierimetaprogramming/class bodies/dsls
01:44:03brixenheh
01:44:17tarcierijust like Groovy
01:44:45tarcieriexcept Scala's design goal wasn't "Let's make a Ruby-like language for the JVM!"
01:47:10tarcieriI've had people keep telling me if I keep pressing forward with Scala I'll see how its design is actually coherent in some manner
01:47:22tarcierieverything really does play nicely together!
01:47:40tarcieribut my gut reaction to it is it has a hodge podge of features which are somewhat poorly crammed together into a single language
01:47:56brixenhm, that was my very naive impression too
01:48:05brixenmaybe I'll keep pushing a bit
01:48:05tarcierithe replies I get to that argument are so strange too
01:48:15tarcieri"Scala isn't an actor language, it has an actor library, therefore it's ok!"
01:48:24tarcieriooooookay
01:48:28brixenheh
01:48:45brixenyou want your coffee in a cup *and* hot, c'mon
01:48:45tarcieri"The !? operator isn't an operator, it's a method name, Scala fooled you!"
01:48:46brixen:)
01:49:04tarcieriokay great maybe !? isn't the world's greatest method name
01:49:23tarcierijust semantic bullshit like that
01:49:28tarcierinobody ever addresses the meat of my argument
01:50:21tarcieri"Your argument is wrong because it was not phrased in the exact terminology we expect it to be phrased in!"
01:50:38tarcierigets that out of the Erlang crowd too
01:50:44brixenwell, I'm gonna go hang with some haskell/ocaml snobs :)
01:50:46brixenbbl...
01:50:48tarcierilol
01:50:50tarcierihave fun!
03:20:46boyscoutAdd support for push_self and send_stack - 0ac6ad6 - Evan Phoenix (llvm-jit)
07:24:02boyscout1.8.7: Enumerable#min_by, #max_by, #minmax, #minmax_by - 18a399b - Marc-Andre Lafortune
07:24:02boyscout1.8.7: Enumerable#take_while (new) - b5bb4dd - Marc-Andre Lafortune
07:24:02boyscout1.8.7: Fixnum#fdiv (and Float) - 8f10203 - Marc-Andre Lafortune
07:24:02boyscout1.8.7: Hash#delete_if, #each, #each_key, #each_pair, #each_value, #reject!, #select (optional block) - 4e7e661 - Marc-Andre Lafortune
07:24:02boyscout1.8.7: Hash.[], .try_convert - f2234a1 - Marc-Andre Lafortune
07:24:03boyscout1.9: Hash#default=, #key (new) - 8d042db - Marc-Andre Lafortune
07:55:44brixenhm, I'm not a fan of the TARGET_IS stuff
07:58:31slavahowdy brixen
07:59:40brixenhey slava
08:01:10brixenslava: saw a talk by the author of this book tonight http://tinyurl.com/automated-reasoning
08:01:30brixentold him I was thinking about doing the code examples in Factor :)
08:01:44evanbrixen: TARGET_IS?
08:01:54brixenevan: yeah, grep for it in kernel
08:02:21brixenthe 1.8.7 stuff needs to be in their own files completely
08:02:30evannothing here
08:02:56brixenhttp://gist.github.com/110359
08:03:08evanhuh.
08:03:11evanwhy don't i see that.
08:03:31evanthat absolutely must all go though
08:03:35brixendunno, but I think it's pretty gross
08:03:38brixenyeah
08:03:47evanwhy don't I see it...
08:04:08evangr.
08:04:34evanug
08:04:36evanok, i see it now
08:04:41evanmarcandre: we need to talk
08:04:43evanpronto
08:04:48marcandrehi!
08:04:57evanwhats all this TARGET_IS stuff in the kernel?
08:05:03marcandreah ah!
08:05:09evani really don't like it.
08:05:18marcandreYeah, I'm not surprised.
08:05:21marcandreHere's the deal
08:05:35marcandreThere are about 60 methods with optional enumerator in 1.8.7
08:06:03marcandreEither I copy paste all of them, or else I add 1 line to each with a test for block_given?
08:06:18marcandrefollowed by the || Target stuff.
08:06:20evani'd rather you cut and paste them.
08:06:39marcandreYou realize that any change to any of them will have to be duplicated
08:06:40evanthan clutter 2 implementations in the same method
08:06:46evani do realize.
08:07:00evanTARGET_IS is not a solution i'm comfortable with
08:07:33marcandreIs there anything that would be RUBY_VERSION dependant you would be comfortable with?
08:07:46evannot much no
08:08:01evanbecause thats not at all how 1.8.7 will be supported
08:08:05evanyou've got it backwards
08:08:14marcandreHow will 1.8.7 be supported?
08:08:15evan1.8.7 support provides RUBY_VERSION
08:08:18evannot the other way around
08:08:35slavaevan: have you thoguht of doing visitors using templates instead of virtual methods?
08:08:46evanslava: one sec
08:08:57marcandreSorry, I don't follow you
08:09:34evanno code in kernel should depend on the contents of RUBY_VERSION
08:10:15marcandreOK. Can they depend on anything internal, like my Rubinius.target_is ?
08:10:31evanthats pretty much the same problem
08:11:06evanhm
08:11:12evanthere are 2 problems
08:11:18evan1) MASSIVE DRY violation
08:11:21evanin my eyes
08:11:37marcandreJust to be clear: only methods that have trivial modifications between 1.8.6 and .7 are done with the TARGET_IS thing
08:11:45marcandreAll the others are in /lib/1.8.7
08:12:17brixenthey are not trivial in sum
08:12:28brixenthe 1.8.7 stuff should live in the 1.8.7 lib
08:12:32brixensame with 1.9
08:12:32evanyes 60 of them scattered around is non-trivial
08:12:36brixenand 1.8.6
08:12:39marcandre? You mean that doing what I'm doing is DRY, right? Coz duplicating 100s of lines of code instead of allowing a couple of TARGET is not very dry
08:13:30evanmarcandre: loading up all these long conditionals all over the code base smells bad
08:13:41evani'll agreed, having duplicate versions has another smell
08:13:53evanbut i'm just not satisified with the current usage of TARGET_IS
08:14:09marcandreyeah, I don't _love_ the TARGET_IS, but I believe it's better than duplicating all that code.
08:14:22marcandreI've kept the conditions simple so if we want to change them it'll be trivial
08:14:39evanit's not trivial for anyone else
08:14:43evanwhich is the problem
08:15:02marcandreI mean if you'd rather have a method, that's not a problem, etc.
08:15:58evanhm.
08:16:26evansomething like
08:16:37evanRubinius.require_block <name> unless block_given?
08:16:40evanwould be a lot better
08:16:57evanbecause in 1.8.6, the version of require_block would raise an exception
08:16:59brixenmarcandre: side note, if you use to_enum, define to_enum and alias enum_for
08:17:11evanand in 1.8.7, could call to_enum
08:17:13brixenmarcandre: that way you can easily grep for the def of the use
08:17:21ddubfinds he is unable to jump into the conversation halfway through, so he just starts to knod his head approvingly
08:17:27evanthat cleans it up a bunch
08:17:58evanthat makes me less uneasy about there being version dependencies layer in methods
08:17:58marcandreYeah, something like that would be nice.
08:18:08evanrather, one method now is switched out in different versions
08:18:42marcandreWould it be ok to use Rubinius.return_enumerator instead?
08:18:48evannope
08:18:59evanbecause thats not what it does in 1.8.6
08:19:04marcandreI know you guys think in 1.8.6, but really, isn't the ultimate target to go with 1.8.7 and up?
08:19:11evanno
08:19:13marcandreAlright, require_block it'll be
08:19:19evanrather, it might be
08:19:27evanbut i can't hit 3 targets at once
08:19:42evanand I don't want the code suddenly misbehaving because brian and I are trying to hit 1.8.6
08:19:42marcandrehe he, I know, that's why I'm handling one all by myself! ;-)
08:20:02evanthats why I was so serious about isolating the changes
08:20:45marcandreOK. I'll clean things up tomorrow (it's 3 am here...)
08:21:17evanok
08:21:25evansounds like we need to have a longer conversation about this too
08:21:29evanbut this is a step in the right direction
08:21:47marcandreOK. What else is up?
08:22:19evanwell, it would be better to not have that code in the 1.8.6 versions at all
08:22:31evanso i'd like to see if we can come up with a solution for that
08:22:43marcandreYou mean the require_block thing?
08:22:50evanthat doesn't require having full reimplementations in the 1.8.7 code if we don't need to
08:22:55evanyeah, the require_block thing.
08:24:12marcandreWell, if you have a way to dynamically recompile methods, the require_block could be prepended where needed/
08:24:28evanno reason we can't add one
08:25:38marcandreWell, it's really up to you!
08:26:13evanthen i'd like them removed entirely for now
08:26:23evanuntil we can come up with a better solution
08:26:30brixenmarcandre: out of curiosity, where is code that uses the to_enum "feature"?
08:26:58brixenI really don't get the use case
08:27:07marcandrebrixen: you want an example? There are a couple in Array and Enumerable, in particular
08:27:12brixen(but then, I don't get the use case of 1.8.7 period)
08:27:14marcandreOh, like in real code?
08:27:18brixenyeah
08:27:29marcandreWell, I personally love enumerators.
08:27:40evanso you're writing
08:27:41marcandreAn example I've used is to implement the Array#product method
08:27:45evane = [1,2].map
08:27:46brixenand... there is #to_enum
08:27:54evanwhile i = e.next
08:27:55evan ...
08:27:55evanend
08:27:59evan?
08:28:33marcandreMore like you have an enumerator and you want to do a "map_with_index".
08:28:50marcandreenum.each_with_index.map{ |elem, index| ... }
08:29:06brixenso for composition
08:29:16marcandreyeah
08:29:25brixenfair enough
08:29:29marcandreIf you implement an enumerable, it's quite nice.
08:29:57marcandreMy tool to analyse FLVs uses that. Each "processor" is an enumerator, and you can pipe them.
08:30:00brixenwe should write a compiler plugin for enumerables then
08:30:10marcandreYou use them only when you need them.
08:30:35slavaI must be a blub programmer because I don't really get the use case either :)
08:31:10marcandreI think that once you start using them you'll get to use them more and more.
08:31:42brixenthere's just not that many iterators though
08:31:52evanmarcandre: part of the reason I don't like the current code is that my brain just can not easily do unless and || in the same expression
08:31:53brixenwhy not map_with_index
08:32:24marcandrewe don't need map_with_index, inject_with_index, etc..., when we have enumerators!
08:32:39evanwe don't need inject, period.
08:33:14brixenslava: you have nice enumerables, what do you do?
08:33:37slavabrixen: factor doesn't have any kind of iterator/enumerator/cursor abstraction
08:33:52brixenit accomplishes it though, yes?
08:33:56slavabrixen: there's a sequence abstraction (O(1) random access) and lazy lists
08:34:03scooprit's stacks all the way down? ;)
08:34:04brixenahh
08:34:07marcandreevan: I agree these conditions are ugly.
08:34:55slavabrixen: there isn't much polymorphism over collections other than amongst sequences and associative mappings
08:35:17marcandreThe problem is that block_given? can't be called from a method (since it's not the same scope)
08:35:32evanthats why I proposed
08:35:41slavabrixen: so for sequences I have each-index and map-index for the specific case mentioned
08:35:43evanreturn Rubinius.require_block(:delete_if) unless block_given?
08:35:50evanI can at least read that
08:36:00marcandreYeah that looks better, I agree
08:36:07brixenslava: I see
08:36:12slavabrixen: but they're defined in terms of 2each and 2map, which iterate over two sequences at once
08:36:21evanmarcandre: so your choise is 1) remove them all together
08:36:27evan2) use the require_block style
08:36:32evanchoice
08:36:46marcandreThe kind of choice my father gave me when I was a kid! ;-)
08:36:52slavabrixen: the use-case for 2map is something like { 1 2 3 } { 4 5 6 } [ + ] 2map
08:36:57marcandreEasy, I pick 2 :-)
08:37:01slavabrixen: does ruby have anything similar?
08:37:06slavabrixen: its like zip followed by map
08:37:17evanmarcandre: ok, do that
08:37:18brixenyeah, zip followed by map
08:37:24brixenslava: ^^^
08:37:26brixen:)
08:37:27evanmarcandre: but we might remove them all together soon
08:37:39evanbrixen and I are going to discuss a better way to handle this case
08:37:44evantomorrow
08:37:48slavabrixen: each-index calls 2each with one of the sequences being an integer range
08:37:57marcandreWell, then, I'll wait for your decision...
08:37:58slavabrixen: the integer range gets unboxed at compile time :)
08:38:03evanmarcandre: ok
08:38:03slavabrixen: so its a lot better than zip + map
08:38:14brixenslava: makes sense
08:38:23slavabrixen: at least simulating map-index using zip + map
08:38:31brixenslava: I remember some of this from browsing, seems elegant
08:39:00slavaI built the whole thing around a sequence abstraction with random access, so length nth set-nth because I hate linked lists
08:39:22slavaand all operations boil down to relatively efficient integer loops even if the type of the sequence is not known at compile time
08:40:01slavathe problem with cursors and enumerables is that you need fancy analysis to eliminate the unnecessary allocation and indirection. my escape analysis pass is a bit too simplistic to handle the enumerators case
09:18:11boyscoutImplement meta_send_op_plus (yay for LLVM overflow instrinsics!) - 12a2cc6 - Evan Phoenix (llvm-jit)
17:32:17marcandrebrixen: I've been wondering if there was a way to have a magic "require_block" method that would be nicer.
17:32:21marcandreI see how I can access the block of the sender, its method name. Is there a way to access the arguments and to "return" as from the sender's scope?
17:32:26marcandreI thought MethodContext would give me the answer about the arguments passed but it's not defined;
17:32:29marcandreas for the return, I tried to change the scope of a block but got a bus error. I feel like a clue less alchemist playing with fire :-)
17:35:20brixenmarcandre: generally, I think that monkeying is a losing proposition
17:35:32brixenI think 1.8.7 should be totally separate at the file level
17:35:46brixenfirst of all, it has nothing to do with dry
17:36:06brixenyou are not factoring out common functionality in a single application space
17:36:22brixen1.8.6 is absolutely separate from 1.8.7 at run time
17:36:46brixenit's a fabrication that they share anything
17:37:45marcandreI must be misreading... Don't they share exactly everything except a small bunch of new methods and another bunch of slightly modified methods?
17:38:09brixenwell, in my mind, that's the fabrication
17:38:17brixenthey look like they share that
17:38:23brixenand at the file level they do
17:38:39brixenbut in terms of execution, they are completely separate
17:38:47brixenthe conditional always has one value
17:39:10brixenit's never sometimes 1.8.6 and sometimes 1.8.7
17:39:22marcandreoh, you mean that the modified methods don't really share anything.
17:39:28brixenof course
17:39:33marcandrek.
17:39:46brixentrying to handle this with execution level conditions is madness :)
17:39:52brixenit's an scm problem
17:39:53marcandreYeah, sure.
17:40:30brixensince 1.8.7 is progressing fairly well, we probably need to rethink our 1.8.6 mentality
17:40:30marcandreIsn't that why a 'require_block' method that gets overridden in 1.8.7 is a better solution?
17:40:40brixennot in my mind
17:40:54brixenit requires too much dispersion of what is 1.8.7
17:41:15brixenI should look at a single file for eg Hash
17:41:20brixennot multiple
17:41:33marcandreyeah, that's definitely true
17:41:57marcandrebut if you want to do that, then there has to be some kind of conditional define, no?
17:41:59brixenthese versions don't coexist, they replace one another
17:42:15brixenI don't think so
17:42:25brixenonce you load 1.8.7, that's the version
17:42:30brixenthere's nothing conditional about it
17:42:40marcandrebecause I think we agree we don't want to have two hash.rb files, one for 1.8.6 and one for 1.8.7, no?
17:42:55brixenI prefer 2, managed with git
17:43:21marcandre...processing...
17:43:22brixenI don't see multiple ruby versions coexisting for long
17:43:45brixenif we move forward with 1.8 line, we aren't going to support 1.8.6 indefinitely
17:43:56brixenI don't think
17:44:16marcandrethat's your choice entirely. But I see 1.8.6, 1.8.7 and 1.9 as 3 different targets.
17:44:20marcandreSaddly.
17:44:33brixenwell, 1.8.7 is not stationary
17:44:41brixen1.8.6 is in maintenance
17:44:55brixenand some sort of haphazard MRI end-of-life process
17:45:11brixen1.9 is volatile
17:45:15marcandrewhat does that mean, "1.8.7 is not stationary"
17:45:40brixenit's moving to 1.8.8 and beyond
17:46:03brixenwith haphazard adoptions from 1.9
17:46:11marcandreUrgh.
17:46:31marcandreI somehow thought they wouldn't add anymore methods to the 1.8 line.
17:46:41brixen1.8 head already has 1.8.8 version number
17:46:54brixenruby 1.8.8dev (2009-04-29 revision 23306) [i386-darwin9.6.0]
17:47:21marcandreHave they added stuff to it?
17:47:42brixenI'd have to read the changelog
17:47:53brixenfor some reason they've changed the version to 1.8.8 :)
17:48:48marcandreI sincerely hope it's just a bug fix release. I disagree with adding many features in a 0.0.1 release, personally.
17:49:27brixenin terms of managing this as simply as possible, I'd have the canonical 1.8.6 library, with 1.8.6+ methods segregated, and completely copied/modified versions in 1.8.7 files
17:49:59brixenwell, MRI has changed features in a patchlevel release, so that discussion is totally moot
17:50:10brixenthere is no hope of consistency with MRI versioning
17:50:19marcandreYeah :-(
17:50:20brixen1.8.7 was a 0.0.1 release
17:50:25brixenit's insane :)
17:51:02marcandreI know, and I agree. I blogged about how I didn't quite get it, at least as to how it's been done...
17:51:39brixenyeah, it's really a pain
17:51:45marcandreMy git-fu is nowhere need good enough to have an idea of how to duplicate the files and keep track of changes.
17:52:30brixenwell, we could start by segregating 1.8.6 methods and copy that file to modify for 1.8.7
17:52:52brixenI'm not saying git will always handle the merge if we need to mod the 1.8.6 file
17:53:05brixenbut in those cases, it would be easier to handle manually
17:53:10brixenand pretty easy to diff
17:53:26brixenand then the files are completely one version or the other
17:54:23marcandreAnyways, I'll let you guys decide on the way to go. I'm just overly eager to fix things. Evan seemed kind of upset and I'm a bit ashamed of the current state of affairs...
17:54:41brixenwell, it's really a complicated thing
17:54:51brixenlots of moving parts, so we're all learning
17:54:57erikhhey, maybe someone in here will know; is 1.8.7's flock broken?
17:55:07erikhI knwo this isn't a support channel, so I won't pester further.
17:55:16brixenerikh: no idea off hand
17:55:20erikhok, thanks.
17:55:21brixendo we have specs for it?
17:55:47erikhI imagine it'd be troublesome to test.
17:55:59brixenheh, probably
17:57:01brixenmarcandre: I'm trying to think of this in terms of supporing ruby users
17:57:27brixenmarcandre: if we have a maintained 1.8.6 mri, then users who have to migrate slowly are somewhat secure
17:57:53marcandreSure. I think it is a great goal to support 1.8.6
17:57:56brixenif rails etc are working well with 1.8.7+, then there is a clear (simple?) upgrade path
17:58:13brixenand we may need to change our focus
17:58:24marcandreOh, I know they are. Major hosting places have already upgraded to 1.8.7
17:58:25brixenin which case we'd have 1.8.7+ and 1.9 to deal with
17:58:33brixenright
17:58:40brixenso, this is something for us to discuss
17:58:52brixenwhen we started, there was no 1.8.7
17:58:58evanenters the room
17:59:02marcandreOf course
17:59:07evanwhen we started, 1.8.2 was out.
17:59:11brixenheh
17:59:17evanwell, when *I* started
17:59:22brixenevan: you might have a read back
17:59:29brixenwe'll wait for you to catch up :)
18:00:03evanok
18:00:06evangive me a sec
18:00:11brixenyeah, rubyspec started at 1.8.4 with some folks still using 1.8.2 iirc
18:00:42marcandreThe thing is, the api differences between 1.8.4 to 1.8.6 were minuscule.
18:00:56marcandre1.8.7 is a different target altogether.
18:01:29marcandreI do think that supporting 1.8.6 is the way to go, but I think the focus should be switch to 1.8.7, personally, because it's what most rubyist are going to use, if that's not already the case.
18:02:52brixenright
18:03:30brixenwhat I'm thinking is that if EY is maintaining the 1.8.6 mri sources, then ruby users who are really stuck on 1.8.6 have some security
18:04:06marcandreSure. By stuck you mean their codebase won't work on 1.8.7, or they don't want to install 1.8.7?
18:04:12brixenand if the 1.8 line is for the vast part forward compatible, then maybe we should support 1.8 stable (currently 1.8.7)
18:04:21brixeneither of those
18:04:24evanok, catched up
18:04:35evanwell, staying with 1.8.6 is a security thing too
18:04:46evanthe changeset between 1.8.7 and 1.8.6 is unknown
18:04:52brixenright
18:04:53marcandreCoz afaik, there is basically no backward incompatibility between 1.8.7 and 1.8.6
18:04:54evanso that makes people itchy to upgrade
18:05:02evanbecause they've got no clue what will break suddenly
18:05:21evanmarcandre: i'm not upset with ya btw
18:05:43evani'm super happy you're willing to travail on 1.8.7
18:05:50marcandreevan: :-) I'm still not proud of my "solution"
18:05:51evan(vocab word of the day!)
18:06:10marcandreThe only "major" thing I heard that broke was some gem that checked the arity of a method that had changed.
18:06:27evanbroken in rubinius or in MRI?
18:06:37marcandreIn production for some people.
18:06:47evanah ah
18:07:03marcandreBecause some hosting companies just switched from 1.8.6 to 1.8.7 and a couple of rails app stopped working because of it.
18:07:25evanwell, it's this one of those things thats almost competely about people
18:07:32evanif 1.8.7 gives them no benefits
18:07:36evanand only stress
18:07:38evanthey're not going to upgrade
18:07:40evanperiod.
18:08:14marcandrePersonally, I see a huge benefit to 1.8.7. So much so I took time to write my backports gem.
18:08:47marcandreBut I realize that many people don't use the api for all it's worth. I even blogged about that!
18:09:07marcandreAnyways... I'm eager to fix things :-)
18:09:25evanwhether or not the features are useful sadly doesn't factor in
18:09:27marcandreMaybe we can find an intermediate solution today, awaiting for a better one later.
18:09:32evanit was just the wrong place to make major API changes
18:09:45evananyway, yes, back to rubinius
18:10:52marcandreI was trying to do some alchemy this morning with Rubinius::VariableScope.of_sender and stuff, just to see if my ugly line could become "Rubinius.require_block"
18:11:18evanright.
18:11:31evanplaying those tricks is fine for prototyping
18:11:37evanbut they won't pay off in the end
18:12:10marcandrek. So I'll go the "return require_block :method, *args unless block_given?" route, then?
18:12:16evanbrixen: so, we'd prefer for the 1.8.6 kernel to have no trace of 1.8.7, yes?
18:12:24evanmarcandre: well, let brixen and I discuss
18:12:32evanmarcandre: i'm just getting to my morning coffee :D
18:12:38marcandreOr else "return Rubinius.require_block(self, :method, *args) unless block_given?
18:12:50marcandreOK, just let me know then :-)
18:13:00marcandreI'll try to be patient...
18:13:09evan:D
18:13:14evanwe'll try to be quick
18:13:22evanpokes brixen
18:13:23malumalumh, in the roadmap you stated, arrays and strings would need better algorithms. now i would like to know what you specificly thought about?
18:13:53marcandreWell, there's not much competition! Just got a "yes" from Matz after more than 3 weeks... ;-)
18:14:08evanmarcandre: a yes to do what?
18:14:15evanmalumalu: it's wide sweeping
18:14:38evanmalumalu: everything from better algorithms in specific methods (thing a better way of doing Array#compact)
18:14:44brixenevan: yeah, I'd prefer to segregate 1.8.6 methods that are overridden in 1.8.6+ and have separate versions of them
18:14:50marcandreevan: A yes to the question "is the feature Hash[[[1, 2], [3,4]]] that is not documented _anywhere_ an official feature"
18:14:52evanto a completely different overlaying datastructure (VList for Array, for instance)
18:15:04evanmarcandre: ah heheh
18:15:06marcandrehttp://redmine.ruby-lang.org/issues/show/1385
18:15:21evanbrixen: so, duplicate the whole method
18:15:30brixenI would, yes
18:15:33evanand leave it up to the future editors to fix it both places
18:15:40evancomplete quarantine
18:15:40brixenin a way that is easier to diff with git
18:16:20brixenso, maybe even hash-1.8.6.rb in kernel, and a cooresponding file in 1.8.7 dir
18:16:25evanso, in order to diff
18:16:41evanshould we move the methods that changed in 1.8.6 into their own file
18:16:45evancopy that file to the 1.8.7 dir
18:16:45brixenyeah
18:16:47evanedit it
18:17:02evanso, in the case of array, we'de have kernel/common/array-186.rb
18:17:11brixenright
18:17:29evanwe'd be using straight up diff for this then
18:17:31brixenif you have to patch 1.8.6, git may be able to merge that for you in 1.8.7.
18:17:38brixenif not, then the manual apply is not so hard
18:18:00evanat the very least, it would be possible to edit one and ask the question "what changes to I need to port to the other"
18:18:08brixenright
18:18:17brixenand to run the specs against both versions
18:18:26brixenwhich is ultimately what we should be leaning on
18:18:38evanyeah, it better be
18:19:02evanok, this solution is not invasive and keeps a clear seperate
18:19:06evanseparation
18:19:13evanat the expense of multiple versions of the same code
18:19:31evancomputer science being simply the study of infinite tradeoffs
18:19:34evani'm happy with it
18:19:34brixenyeah
18:19:54evanmarcandre: come back into the room
18:19:58brixenit's multiple versions at the scm level, which is where multiple versions belong
18:20:09marcandreI'm here
18:20:31brixenheh
18:20:46evanmarcandre: do ya follow that?
18:21:13evanbasicly, any methods that need to be changed are moved into a file that contains just that set of methods
18:21:25evanthat file is copied to 1.8.7 and editted
18:21:27marcandreNot sure. We'd have /common/array.rb for common stuff, and divergences would be /common/array186.rb and /common/array187.rb
18:21:39evanmarcandre: yes
18:21:47evanwell, no
18:21:58evanwe'd have kernel/common/array-186.rb
18:22:13evanand lib/1.8.7/array-187.rb
18:22:15evanor something
18:22:43evandealing with conditional loads of files in common isn't a realm I want to enter atm
18:23:09evangit has a lowlevel command called "git merge-file" which takes 2 files and a common base
18:23:11marcandreeven for the methods that differ only because they return an enumerator instead of raising a LocalJumpError?
18:23:26evanso I could wipe up a rake task to extract the base and run merge-file
18:23:30evanto show the differences
18:23:40evanmarcandre: yep
18:23:41evaneven for that
18:23:53evanthe idea is 2 fold
18:24:15evanby having the methods in a specific file in kernel, the editor knows that they need to edit the 1.8.7 version too
18:24:22evanand we have write a quick tool to show the differences
18:25:00evani know it seems pretty unDRY
18:25:03evanbut it's a trade off
18:25:03marcandreit might be the 1.9 version they need to modify.
18:25:17marcandreSeems quite wet from where I stand! :-)
18:25:43evanwe're just pretty risk averse in having all these version dependent things in kernel
18:25:47evanas you can tell
18:25:54marcandreI understand.
18:26:02evansince this doesn't impact kernel much, it's good in my eyes
18:26:17evanand if in 2 weeks we decide it totally sucks
18:26:18evanwe'll change it
18:26:19marcandreThe fact that 1.8.6 needs to do one thing (always the same thing) and 1.8.7 needs to do another thing (always the same thing)
18:26:31evanyou know how many times we're rearchitectured stuff around here?
18:26:36evanwe're practically experts at it now
18:27:00marcandreand that for about ~50 methods, I just feel there would be a good case for a method there, and only that methods gets overridden by 1.8.7
18:27:25headiusyou could just wait until after 1.0 too :)
18:27:46evanheadius: i'm trying to allow us to do so :)
18:27:49headiusbut I'm glad this is shaking loose some 1.8.7 specs...we may switch 1.8 mode to 1.8.7 soon
18:27:59headiusmaybe in 1.5
18:27:59evanmarcandre: i know, again it's a trade off.
18:28:00headiuser
18:28:02headius1.4
18:28:07evanmarcandre: it's just a sticky problem
18:28:14evanand i'm trying to keep the mess in one room of the house
18:29:02marcandreFrom a PR perspective, having 1.8.7 compatibility seems like a good thing. I mean saying you're getting close to a version that's not the current one (although that's 99.5% of the work!) is not as good as emulating the last one...
18:30:00marcandreevan: I'm just wondering how much it's going to hurt my brain and fingers. I'm so adverse to copy pasting stuff around like this... My blood is dry :-)
18:30:14evanthats not good!
18:30:20evanyou should get that looked at!
18:30:21evan:D
18:30:59headiusmarcandre: how are you planning to handle things like Enumerator#next?
18:31:08headiusin MRI they're either green-threaded or fibers
18:31:15evanmarcandre: well, this is one place where you're pain is my eased worry
18:31:24evanand you're eased worry is my pain
18:31:26evanyour
18:31:41evansince it's a tradeoff
18:31:59marcandreheadius: I'm using /lib/generator... and that calls continuations that are not implemented...
18:32:09evanEEW
18:33:10marcandreWell, there is no magic. Unless rubinius implements fibers/continuations, there is no 'next'
18:33:31marcandreOr else I'm missing something.
18:33:35evanfucking #next
18:33:41evancurses the sky
18:34:00evanit's so fucking wrong to implement #next on top of #each
18:34:01lopexSky#next
18:34:02marcandreHe he. I think people know that it's a "use only if you absolutely need to"
18:34:03evanit's completely backwards
18:34:16marcandreagrees
18:34:53evanheadius: how about this
18:35:02evanlets backdoor a new API
18:35:48evanfor Enumerators, the method __for_next__ is called on the object
18:35:58evanand is required to return an object that has #next
18:36:11evanto use for this
18:36:19evanArray and such can use this API
18:36:24evanand we'll just forget to close the gate
18:36:25evanso anyone can
18:36:37lopexheh
18:37:17evani'd probably end up doing this anyway to support #next on Array, Hash, etc
18:37:26lopexsure
18:37:33lopexfirst thing to do
18:39:49marcandreevan: Alright. So it's official, there is no way I can convince you to not duplicate the code of the ~50 methods that return an enumerator?
18:40:19evannot right now, no.
18:40:20evansorry.
18:40:23marcandreNaming convention: /common/array.rb, /common/array_186.rb, /lib/1.8.7/array.rb, /lib/1.9/array.rb?
18:40:41evanyeah, thats fine
18:41:10marcandrek. Thanks
18:42:57brixenevan: you changed the dns for rubini.us?
18:43:12evanno
18:43:16brixenhm
18:43:16evani need to talk to the GH guys
18:43:22evanI can't set a CNAME for a toplevel domain
18:43:26evanonly a subdomain
18:43:28brixenahh
18:43:46brixenok, I'm getting this for rubini.us: http://guide.opendns.com/?url=rubini.us&servfail
18:43:51evan:?
18:44:02evani fucked it up last night
18:44:04evanit should have recovered
18:44:27brixencould be my dns then
18:44:39macournoyerI get it too
18:44:54evanblah.
18:44:55evanok
18:45:27evanwhat about other parts of rubini.us?
18:45:29evangh.
18:45:30evanetc
18:45:35brixengh works for me
18:45:39evank
18:52:28evanok, i've updated the DNS
18:52:35evanit should recover here once the caches time out
19:12:11boyscoutHandle all of push_literal and string_dup - 535ba09 - Evan Phoenix (llvm-jit)
19:46:41rueReading backlog still, but could we do a bytecode substitution from the 1.8.7 libraries?
19:46:48rueOr -insertion.
19:48:39evanperhaps
19:52:05boyscoutAdd send_method - 822d4db - Evan Phoenix (llvm-jit)
19:52:06boyscoutFix resetting allow_private_ - b7d7405 - Evan Phoenix (llvm-jit)
19:52:06boyscoutAdd create_block and send_stack_with_block - eb19e18 - Evan Phoenix (llvm-jit)
20:20:05boyscoutUpdated CI frozen specs to RubySpec 6bfa11f6. - 8fa8c14 - Brian Ford
20:20:05boyscoutUpdated CI tags for merged specs. - eaea59c - Brian Ford
20:22:51boyscoutCI: eaea59c success. 2679 files, 10335 examples, 32880 expectations, 0 failures, 0 errors
20:27:02boyscoutDo full VariableScope setup via a function - 1e527b1 - Evan Phoenix (llvm-jit)
20:33:40rueevan: Method#patch ?
20:35:31rue`Enumerable.instance_method(:each_with_index).patch "return" => "return unless block_given?; yield"`
20:36:03rueGenerate an AST/bytecode to 'grep' it and replace it
20:36:57evanwhere do we patch it?
20:37:00evaner.
20:37:00evanwhen
20:37:52rueWhen loading whichever file contains the instruction, ie in this case lib/1.8.7/enumerable.rb (or whatever)
20:38:13rueCould make it Rubinius.patch or something, of course
20:39:13evanso every VM load
20:39:14evanhm.
20:39:38rueYeah, unless we do some sort of copyover support
20:40:00rue(The existence of .patch opens up some more neat macroish options too, obviously)
20:43:09rueevan: Also, wrt. Github, set it up for www. and then CNAME that
20:44:11evanalready got it figured out
20:44:15evanyou can use an A rec
20:44:34rueAha, goodies
20:44:49evanlunch time!
20:51:53boyscout1.8.7: IO#each, each_byte, each_line (optional block) - e867f23 - Marc-Andre Lafortune
20:51:53boyscout1.8.7: Segregated methods that get overriden in array_186, etc... - 8a9a010 - Marc-Andre Lafortune
20:52:26marcandreclean up done :-)
20:52:54brixensweet :)
20:53:00marcandreOnly thing I haven't thought about is how to deal with changed lib, i.e. "require 'io_string'"
20:53:11marcandrestringio I mean
20:54:29brixenwhile you think about that, I'm grabbing some lunch :)
20:54:54ruemarcandre: Changed?
20:55:13marcandrerue: ?
20:55:56rueWhat do you mean by "changed lib"?
20:56:31marcandreWell, stringio is changed in 1.8.7. So require 'stringio' must load an additional file '1.8.7/stringio'.
20:56:38marcandreI think autoload might do the trick
20:56:49boyscoutCI: 8a9a010 success. 2679 files, 10335 examples, 32880 expectations, 1 failure, 0 errors
20:57:04marcandreOups, 1 failure?
20:57:25marcandreIs there a way to know which one, coz on my machine I have no failure...
20:59:06ruemarcandre: No, just put lib/1.8.7 *first* in the load path :)
20:59:43rueThink Mr. CI is busted again. It should give an URL for failures
21:00:09marcandreloading path: cute
21:00:35rueThe newer version knows it will have to load the old one, so it works simpler
21:13:13brixenmarcandre: http://ci.rubini.us/rubinius
21:13:28brixenmight be a spurious failure
21:13:56brixenah, it does use enumerable... maybe not spurious
21:14:38brixenhm, that's probably mspec though
21:19:16marcandreHe he, it look like the system clock changed of second between two calls, which is why it's complaining.
21:21:21marcandreI fixed the specs to allow for a 1 second difference.
21:40:25evanmarcandre: autoload isn't allow in kernel or any code produced by us
21:46:59marcandreevan: don't worry, rue found the perfect solution.
21:47:08marcandrewithout autoload
22:06:28brixenevan: now rubini.us is landing on github.com, should I update the CNAME file?
22:07:24evanyes
22:07:33brixenk
22:09:18boyscoutChange CNAME to rubini.us. - 48f3a35 - Brian Ford (gh-pages)
22:09:30evani love that website changes show up in here
22:09:37brixenyeah :)
22:09:52brixenthe branch reporting is sweet
22:10:19brixenwhat's the plan for merging in the jit branch?
22:10:43brixenI was thinking of doing Tap after Hash, but I could do Tap first
22:10:58dgtizedrubini.us just goes to the github homepage for me now, not our files
22:11:07dgtizedis that just cause it hasn't propegated the change yet?
22:11:36evandgtized: it might take a sec
22:12:04evanbrixen: well, once i've got coverage for it to compile all methods i'm going to merge it in
22:12:13brixenok
22:12:24evani'm going at a pretty good pace now
22:12:33brixenyeah
22:12:47brixenI was just thinking how to coordinate the Tap change
22:12:53evandon't worry about it
22:12:54boyscoutAdd send_stack_with_splat - 2722fac - Evan Phoenix (llvm-jit)
22:12:54brixenI'll just make a parallel process
22:12:59evani'm on a side branch
22:13:03evanso i'll manage the merge
22:13:04brixenyeah
22:13:08evanthats the cost of using a branch
22:13:16evanif you want to do it on a branch too
22:13:24evanthen we'll just coordinate to figure out who should merge in first
22:13:35brixenI shouldn't need a branch
22:13:39evanok
22:13:39brixenI'll leave rake in place
22:13:42evango for it
22:13:46brixenk
22:13:48evanfull steam ahead!
22:14:06brixenyeah :)
22:14:25brixenlooks like rubini.us is working
22:14:57evanrad
22:15:10evanmaybe a little later i'll work on redoing it with jekyll
22:15:23brixenyou should work on the jit :)
22:15:26evan:D
22:15:31evanmy brain needs a break sometimes
22:15:37brixenah true
22:15:44brixenjekyll is sweet
22:15:52brixenit will be easy to incrementally fix it up
22:15:56evanyep
22:16:11brixenI just wget'd the old site and fixed links
22:16:45evanwell, the old site is what's in gh-pages now, yes?
22:16:50brixenyeah
22:17:06brixenso, I would start converting to markdown
22:17:10brixenand using templates
22:17:14evanyep
22:17:24evani figured i'd convert it to layouts first
22:17:29brixenyeah
22:17:32evanthen each page one at a time
22:17:43brixencool
22:17:51rueJekyll is a bit iffy, but then so are all the other statics.
22:18:15evanrue: it's better than straight static though
22:18:38rueCertainly, for anything with more than two pages
22:30:46rueJekyll is pretty blog-centric, insofar as I know. Nanoc and Webby are a bit more versatile albeit with the corresponding additional complexity/configurability
22:39:34brixenrue: you had me at Jekyll is pretty
22:44:28rueI was biased in favour of it, courtesy of my Barbarian/Rogue (Assassin) Halfling character "Yeahkill An' Hide", but it is not quite all that one might hope for.
23:08:10boyscoutAdd send_super_*, push_block - bebbbb9 - Evan Phoenix (llvm-jit)
23:08:19evanthats a weird SHA1
23:08:27slavaheh
23:08:27evanSHA1's are like a roullete game
23:08:37evanroulette
23:08:57evanand when you win, it's 1 to 100 trillion odds
23:09:26dgtizedanyone see the contest to find the MD5 key where MD5(key) = key?
23:09:54slavahaha
23:10:18slavaevan: so can the jit run any code yet?
23:10:38rueIt can push a block ;)
23:11:44dgtizedso is llvm going to be in a submodule in the repo now?
23:12:40rueLLVM on git now?
23:12:48evandgtized: not sure yet, but not a submodule
23:12:51evanrue: no
23:13:01rueWell, then no.. :P
23:13:04dgtizedso what is the problem with submodules out of curiosity?
23:13:07rueCould make it a subtree
23:13:10evanthey're a pain.
23:13:18dgtizedeven if we don't pull them ever?
23:13:23evanslava: yeah, it has been running code for days
23:13:23rueSubmodules are just fine
23:13:26evanslava: just not all code :)
23:14:12rueIf you are both modifying the submodule AND have the ability to use rsync or some similar mechanism instead, then submodules are not necessarily ideal.
23:14:58rueModifying the submodule from within the supermodule, that is to say.