Index

Show enters and exits. Hide enters and exits.

05:02:15evantarcieri: poke?
05:03:30slavahi evan
05:03:38evanhi slava!
05:03:44evanyou still in portland?
05:03:48slavanope, in boston now
05:04:29jakedouglas1sup
05:04:52evanhi jake!
05:05:06jakedouglas1did i do the fiber thing right this time?
05:05:26evanlets see..
05:06:38evanjakedouglas1: yep! looks good.
05:06:43jakedouglas1cool.
05:07:11jakedouglas1there are still 3 specs that fail but i think they probably need to be fixed in the compiler
05:08:15evanoh?
05:08:17evanseems unlikely.
05:08:26evanI don't see why Fiber would need compiler changes
05:08:29jakedouglas1well, maybe 2 of them. or 1 of them. i duno
05:08:31jakedouglas1ok well
05:08:33evanI assume you mean the bytecode compiler
05:08:35jakedouglas1one of them just seems to be an issue with Proc
05:08:35evanwhich ones?
05:08:47jakedouglas1and i dont think theres a rubyspec for it
05:09:03jakedouglas1but Proc.new { break }.call should raise LocalJumpError
05:09:06jakedouglas1that doesnt happen on rbx
05:09:50tarcierievan: ohai, walking home from the bar there heh
05:09:57evanaah.
05:10:11tarcierievan: yeah to get to the point, you can't do multicore programming in Rubinius without creating multiple VM instances, so long as the GIL exists :/
05:10:13evanjakedouglas1: really? did you check that?
05:10:29evanoh weird.
05:10:33evanso it does.
05:10:40evanfucking proc/lambda/Proc.new interactions.
05:10:45jakedouglas1yea.
05:10:48evanignore it.
05:11:05evanthat kind of crap is stuff i'm fine doing the very, very last.
05:11:15evantarcieri: thats wrong
05:11:21tarcieriit is?
05:11:22evanyou certainly can do multicore programming
05:11:25evansure
05:11:26tarcieriin Ruby?
05:11:33evanone thread can be stopped in IO while another runs
05:11:44tarcieriyeah, as I was saying... for the I/O case sure
05:11:51tarcierifor multicore computation, no
05:12:08evanyour point, and I think it's valid, is that true concurrent execution is required to make this kind of thing fast
05:12:15jakedouglas1evan: the other two failing specs are
05:12:21tarcierihow would you scatter/gather an embarrisingly parallel problem across multiple cores in Rubinius today?
05:12:27jakedouglas1"Fiber.new raises a SyntaxError when the block contains a retry statement"
05:12:28evanjakedouglas1: please point out which ones
05:12:29jakedouglas1and "Fiber#resume executes the ensure clause"
05:12:37evanok
05:12:43evanthe Fiber.new one we won't support.
05:12:47evanpretty plainly
05:12:52evanthats probably a bad spec
05:12:53evani'll check.
05:12:57jakedouglas1ok.
05:13:02evanthe ensure one is definitely something we should be doing
05:13:04evani'll take a look.
05:13:09jakedouglas1well
05:13:15evano/~ and read a book, it's reading rainbow! o/~
05:13:17jakedouglas1i think the ensure one isnt even fixed in MRI yet
05:13:19jakedouglas1its still an open bug
05:13:22evanaaah
05:13:22evanok
05:13:30tarcierievan: granted the fact you can even do concurrent I/O is a miracle compared to 1.8 :)
05:13:32jakedouglas1but…what would need to change to fix it?
05:13:39tarcieribut 1.9 gives you the same thing
05:13:48evanjakedouglas1: i'll have to look at the spec to see what the behavior is.
05:14:08evantarcieri: you can certainly do lazy computations with even MRI
05:14:35evanbut I'll agree, they're not really lazy unless you've got true concurrency.
05:14:47evansince to run them, they must suck down GIL timeslices.
05:14:48tarcieriohai MenTaLguY!
05:14:51MenTaLguYhello
05:14:52evanwhich starve other things.
05:14:57MenTaLguYI heard somebody say "thread"
05:14:58tarcieriyou seem like a good participant for this conversation
05:15:00evanMenTaLguY: evening sir
05:15:01evanMenTaLguY: hahah
05:15:03evanyou're awesome.
05:15:20tarcieriMenTaLguY: I was just talking to evan about dataflow
05:15:21evantarcieri: I do agree with you
05:15:24evanbtw
05:15:34evanI don't know excatly what dataflow does
05:15:35tarcierievan: most Rubyists don't even thinking about using Ruby like that, FWIW
05:15:45jakedouglas1evan: basically the desired behavior is that your ensure clause runs before transferring execution to another fiber.
05:15:50evanso I was trying to get a picture for what things it wanted to do concurrently
05:15:56MenTaLguYfor the most part, dataflow just means expressing your data dependencies explicitly
05:15:56tarciericoncurrent I/O is what everyone needs... concurrent computation? most people assume it's unpossible
05:16:19tarcieriMenTaLguY: it just provides a less error-prone mechanism for the synchronization of concurrent computation than threads...
05:16:19evantarcieri: well, Rubinius has concurrent I/O
05:16:27MenTaLguYit's sort of a declarative way of managing data dependencies, really, less explicit focus on synchronization, more focus on what depends on what else, and the scheduler takes care of the rest
05:16:27tarcierievan: yeah fosho
05:16:53evanMenTaLguY: right, and allowing things to collapse to values from expressions when needed
05:16:55MenTaLguYfutures are basically dataflow
05:17:00evanright
05:17:02tarcieriyeah totally
05:17:02evani was about to say that.
05:17:03MenTaLguYI really need to finish revisiting lazy.rb soon
05:17:15tarcieriMenTaLguY: you should like... bust some Omnibus yo :)
05:17:27MenTaLguYyeah ... it's hard, juggling everything I'm doing
05:17:29evantarcieri: well, don't worry your pretty little head
05:17:40evanthe major feature of Rubinius 2.0 is the GIL removal.
05:17:44tarcierievan: this is all pie in the sky theoretical shit even I don't have much of a use case for :/
05:17:51MenTaLguYanyway, lazy.rb doesn't need omnibus per se, but I need to address the same major issues as with omnibus
05:18:01MenTaLguYso it's a good micro-project
05:18:26evanMenTaLguY: the GIL removal for 2.0 is what sparked my question to you the other day
05:18:30evanabout locking primitives
05:18:33MenTaLguYnods
05:18:49slavayou're already working on 2.0?
05:18:59tarcieriohai slava
05:18:59evanslava: no
05:19:17evanslava: but i've already decided that true concurrency is the big 2.0 feature.
05:19:30evansimilar to the way SMP was the big feature of linux 2.0
05:19:35tarcieriheh
05:20:28tarcierievan: I used to be all skeptical about true library level solutions to concurrency in Ruby, but now I'm not, thanks largely in part to JRuby and MenTaL's work on that
05:20:43tarcieridataflow is a nifty one, so is Omnibus, if MenTaLguY ever finishes it :)
05:20:53evantarcieri: well, library level support needs good locking prims
05:21:21tarcieriyeah it's obviously heavily dependent on VM-level support and fine grained locking at that level
05:21:53evanthat JRuby's Mutex uses Java's locking support was the source of some of my thoughts on this subject
05:22:11evanie, what VM-level mechanism should be provided to build on.
05:22:14MenTaLguYwell, it kind of uses the Java stuff badly
05:22:16tarcieriCOW in JRuby is pretty dopesaice
05:22:22tarcierierr, dopesauce
05:22:23tarcierifor Ruby :)
05:22:27evanCOW?
05:22:30evanlike in String?
05:22:31tarciericopy on write
05:22:39evan.... and how is that related?
05:22:42tarcieriuhh, MenTaLguY, you wanna chime in here?
05:22:50MenTaLguYtarcieri: refresh my memory?
05:22:53tarcierilol
05:22:55tarcierinever mind
05:23:03evanlocking in terms of making sure the shared buffer is properly managed
05:23:04MenTaLguYthere are a bunch of COW conversations I've had, different things...
05:23:05tarcieriI need to be full of less booze for this conversation
05:23:06evani'd assume.
05:23:20MenTaLguYso, the one really interesting (but hard to implement) COW idea that we had at some point
05:23:32MenTaLguYwas a shared-nothing thread model, that basically did a COW fork per thread
05:23:55MenTaLguYwith a few Ruby types like Queue etc. being shared
05:24:09evanthis is in JRuby?
05:24:18MenTaLguYas I said, not implemented, but discussed
05:24:34tarcieriMenTaLguY: I was thinking specifically relating to ivar mutations
05:24:38evansounds need.
05:24:46evanneat
05:24:47evanrather.
05:25:54MenTaLguYyeah, there are a lot of gotchas, but I think it's potentially a much nicer idea than shared-by-default threads
05:26:22evanMenTaLguY: seems like no ruby code would run though
05:26:23tarcieriso that was all pie in the sky never got implemented stuff then?
05:26:34evanall ivar mutation would cause copying versions into threads
05:26:42evanand there would be no communication
05:26:45MenTaLguYevan: a surprising amount of stuff would work, out of what I looked at
05:27:07evansure, but everything that didn't work would have no way of working
05:27:10MenTaLguYcommunication would indeed be limited to objects specifically designed for it, like instances of Queue etc.
05:27:15evanunless a Reference type was introduced
05:27:20MenTaLguYkind of
05:27:21evanand used to explicitly shared data.
05:27:26MenTaLguYyes
05:27:44evanthen we can add some ('s and clojure!
05:27:47evanwaves his magic wand
05:27:47tarcierilol
05:27:57tarcieriheadius seems all about STM
05:28:04MenTaLguYwe are looking at exposing Clojure's persistent data structures and STM in JRuby actually
05:28:51tarcieriSTM seems like by far the coolest use case of true concurrent native threads
05:30:13tarcieribut dataflow or thread-backed preemptive actors are other ones as well
05:30:32MenTaLguYor just data-parallel library stuff
05:30:38tarcieriyeah totally
05:30:41MenTaLguYif you want to do your computation in Ruby rather than dropping into C at least
05:30:48tarcieriyeah heh
05:31:14MenTaLguYbut actually even if you want to do it in C and need to consult Ruby objects for part of it
05:31:33evanMenTaLguY: if you'd not mind, would you explain the difference between an STM library like clojure and just having datastructures that are threadsafe?
05:32:09evanto me, looking at clojure, seems to me that STM is just datastructures that participate in a scoped lock
05:32:20MenTaLguYnot really
05:32:22evanwhich doesn't sound very radical at all.
05:32:32MenTaLguYthinking of it in terms of a lock is not a good mental model
05:32:40evanwell
05:32:50evani've got the mental model for it fine
05:32:53evanat the usage level
05:32:59evani'm an implementation man though.
05:33:16MenTaLguYthe big things about locks is that they imply blocking/exclusivity
05:33:19evanthe story has to also be told with no makeup on.
05:33:27MenTaLguYSTM (and transactions generally) represent an attempt to avoid/limit that
05:33:49evancertainly, by queueing writes and executing them atomicly
05:34:04evanthe atomicness must be a blocking/exclusive operation though
05:34:17evanso it still is one, you've simply delayed it
05:34:28MenTaLguYnot really
05:34:42evanoh?
05:35:17MenTaLguYsome STM implementations really push a lockfree/optimistic model
05:35:48MenTaLguYyou still end up having to back off/retry if there's a conflict
05:35:56MenTaLguYbut in the no-conflict case nobody blocks on anything
05:36:23MenTaLguYlocks are a way to get consistent updates, but not the only way
05:36:44evanso you'd check for a conflict before writing out the transation, and run unlocked if there isn't one
05:37:08MenTaLguYnot really
05:37:14MenTaLguYmaybe you should read the Haskell STM paper
05:37:18evani'm getting a lot of not really's tonight.
05:37:26evanok
05:38:29MenTaLguYin principle, the only thing you should ever have to block on is IO or a data dependency
05:39:00MenTaLguYconcurrent updates of data structures don't need blocking at all -- at least in theory
05:39:10MenTaLguYin practice designing lockfree data structures is something of rocket science
05:39:42evani'm not much of a theory man
05:40:01evanthe in practice is the thing that interests me.
05:40:28MenTaLguYthere are a lot of tradeoffs either way
05:40:36evanin theory we can fly to mars. It's the in practice that's a lot more interesting.
05:41:20tarcieriMenTaLguY: like debugging difficulty for the end-user?
05:41:45MenTaLguYtarcieri: not so much, but predictable performance characteristics at least
05:41:56MenTaLguYlike, for example
05:42:02MenTaLguYmost people want "fair" primitives
05:42:11MenTaLguYbut those are subject to convoying and generally have lower throughput
05:42:33MenTaLguY(we get bugs filed against JRuby that certain things aren't fair on a fairly regular basis)
05:43:45tarcieriMenTaLguY: I found Clojure confusing :/
05:43:54MenTaLguYhowso?
05:44:09tarcieriI just couldn't wrap my brain around it in the same way as shared-nothing approaches to concurrency
05:44:31MenTaLguYto which aspect of clojure are you referring in this case?
05:44:39tarcieritransactions and STM
05:44:55tarcieriCSP is just so much easier to think about
05:45:05evanI hear that large parts of clojure are being rewritten in clojure itself. It will be interesting to see if they can implement the STM system in clojure itself.
05:45:20MenTaLguYI think so
05:45:26MenTaLguYI can't think of anything which would prevent it
05:46:53evanwell, would the same apply to ruby?
05:47:12MenTaLguYI've implemented STM in Ruby before
05:48:00MenTaLguYthe main disadvantage in Ruby versus Clojure is that in Clojure you can more or less close the performance gap with Java, which isn't really possible in Ruby
05:48:55evanbut that's STM in the form of special classes, I'm assuming.
05:49:06evanI guess I was thinking systematic STM
05:49:17MenTaLguYI woudln't ever recommend systematic STM
05:49:21evanivar writes participate in STM, for example
05:49:22evanoh?
05:49:27evanisn't clojure that?
05:49:31MenTaLguYHaskell doesn't do it, Clojure doesn't do it...
05:49:39MenTaLguYno
05:49:51MenTaLguYOne of the reasons has to do with a basic principle of transactions
05:50:22evanso just a special set of data structures perform STM
05:50:24MenTaLguYnamely, transactions work badly if your transactions are large
05:50:46MenTaLguYyes
05:50:50evanand, in the case of clojure, it just so happens that the default datastructures use STM
05:51:04MenTaLguYHaskell has TVars, Clojure has Refs
05:51:06MenTaLguYno
05:51:16evanaren't clojures lists and maps STM?
05:51:19MenTaLguYthe default data structures in Clojure are pure functional/persistent data structures
05:51:20MenTaLguYno
05:51:35evanah ok
05:51:49evanlooks like I've just had an incorrect view of the existing work
05:52:08evanis Ref the only STM construct in clojure?
05:52:14MenTaLguYyes
05:52:22MenTaLguYTVars are the only STM thing in Haskell
05:52:31MenTaLguYSTM::Variable was the only thing in my last Ruby STM implementation
05:52:36evanso, multiple Ref writes are queued and performed atomicly in the transation
05:52:43evanah!
05:53:01evanI always thought SMT was systemic
05:53:04evanSTM, rather.
05:53:17evanis HTM systemic? not that it's been really implemented.
05:53:52MenTaLguYhm, usually not
05:54:20evanso a big part of STM is programmer education
05:54:24evanuse X, not Y
05:54:29MenTaLguYbasically it's not worth the overhead to make everything transaction-safe, just like it's not worth the overhead to make everything "thread-safe"
05:54:44MenTaLguYwhich gets back to an issue I keep having to try to drive home to people
05:54:58evangotcha!
05:55:05evanok, cool.
05:55:19MenTaLguY*most* of your data structures/types/etc shoudln't be used for communicating between concurrent processes (threads, etc.)
05:55:42MenTaLguYconsidering that everyone's so hung up on performance, there's a performance tradeoff in making something safe to be used as a communication channel in the first place
05:55:47evanright, pushing and poping from a bare Array isn't a good idea.
05:56:54MenTaLguYgenerally speaking I think computation and communication are kind of separate domains, or should be
05:57:29evanah ok
05:57:44evanI'd agree there.
05:58:52MenTaLguYso the thing about STM is that it's a communication mechanism which has semantics which mimic local storage
05:59:14evanlocal storage is an local variables?
05:59:24MenTaLguYif you like
05:59:38MenTaLguYnot syntactically, but semantically a bit I guess
06:00:34evanyes, semantically
06:00:39evana place to call your own
06:00:41evanif you will.
06:01:27MenTaLguYlocks are kind of a different approach, you basically use real local variables and then synchronize them around via the lock
06:01:39evanMenTaLguY: so i guess we'd say that Ruby could really use a goto STM toolkit
06:01:44evango to, rather.
06:02:04evanto begin the programmer education
06:02:17MenTaLguYponders
06:02:57MenTaLguYreally I think for the most part we need CSP/PI-calc channels, atomic locations, and persistent data structures
06:03:15MenTaLguYalso good data-parallel libraries
06:04:12MenTaLguYSTM is kind of a dead-end crutch
06:04:26evanoh? seems like a building block
06:04:43MenTaLguYit's like corn ethanol as a petrolum substitute
06:05:54evanso you'd prefer to make cross thread mutications entirely a communication game
06:05:56evanusing channels
06:06:10MenTaLguYideally yes, for a sufficiently broad idea of channels
06:06:26evanseems good
06:06:55evanit's been years now since you introduce Channels to rubinius
06:07:04MenTaLguYI won't say STM is never an appropriate solution, but I've written roughly three STM implementations so far and the things I learned about tradeoffs kind of put me off them
06:07:05evanperhaps it's time to rediscuss and see how they can be improved on
06:07:15MenTaLguYyeah
06:07:33MenTaLguYmy intention was always that we'd have specializations of the channel idea which were optimized for particular use cases
06:08:10evanwhat are some of the varitions you could see among different kinds of channels?
06:08:19tarcieriMenTaLguY: what do you think about STM not being particularly applicable to shared state problems like Chameneos
06:08:26evanmore than just async/sync receiving, I'd assume.
06:08:34tarcierishared state concurrency problems, that is
06:10:07MenTaLguYwell, (as I reacall) the fastest Chameneos implementations didn't use STM
06:10:13tarcieriindeed
06:10:37MenTaLguYevan: well, things like bounded size, also things like the semaphore optimization (though that one seems easy enough to do automatically)
06:10:50evanMenTaLguY: yeah, i'm planning to add that this week
06:10:58evanthe semaphore optimization
06:11:04MenTaLguYnods
06:11:21evanor, should I say, readd.
06:11:21evan:)
06:12:09evanthere is a very fine art to lock ownership
06:12:16evanwhich I've not yet mastered
06:12:17evanlock/channel
06:12:26MenTaLguYah?
06:12:48evanmeaning, carrying around one lock per data structure is a pain
06:13:03evanbut use a application level lock means sucking down performance
06:13:34evanwhich is, imho, one reason why the JVM object-as-monitor approach is nice
06:13:41MenTaLguYwell, that's actually a more general issue
06:13:47evanmakes introduces locks at different levels easier
06:13:52MenTaLguYwhich touches on all sorts of things like performance, architecture, etc
06:14:01evancourse, then you have the problem of going "eek! which object do I lock again?"
06:14:06MenTaLguYi.e. what granularity of communication do you want between concurrent tasks?
06:14:26evanthe syncronize keyword at least makes locking part of the interface
06:14:35evanMenTaLguY: yep yep
06:16:05MenTaLguYone question that I think you may need to step back and ask as far as the Rubinius core goes, is where are your major communication points?
06:16:54evanis constant tables one of the answers?
06:16:58evanie, that level
06:17:04MenTaLguYelaborate?
06:17:21evanactually, no
06:17:27evanlets use my example from earlier
06:17:31evanclass creation
06:17:59evanmaking sure that to threads running 'class Blah; end' get a consistent view
06:18:06evanand that there aren't 2 classes named Blah created
06:18:15evanis that the level you were thinking?
06:18:44evanplaces where the shared memory must be written to
06:19:08MenTaLguYsort of
06:19:21MenTaLguYnotionally, Ruby has this tree of classes/modules related by constant assignments
06:19:46evansure
06:20:14MenTaLguYcertain operations, like creating and naming a non-anonymous class, might need to happen atomically
06:20:18MenTaLguYthough, I still wonder
06:20:33MenTaLguYif you wrote: Blah = Class.new do; end
06:20:43MenTaLguYdoes that really need to be different?
06:21:12MenTaLguYif you've got two threads each doing class Blah at the same time... part of me says you get to keep both pieces
06:21:52MenTaLguYI know the idea there is that the threads can independently extend the class, whoever wins the race, but often it matters when you're adding features to a class what order they are added in, overall
06:21:57evanone thread should raise "constant already defined"
06:22:03evani'd assume.
06:22:18MenTaLguYI think it's a warning rather than an exception in practice
06:22:27evanit's not
06:22:29evanit's an exception.
06:22:50evanoh me
06:22:51evanno
06:22:53evanit's a warning
06:22:54evan:/
06:23:03evanat any rate
06:23:40evanmy thinking is that in the case of 'class Blah' because Blah is created lazily, there shouldn't be 2 of them.
06:24:15evanso yes, I'd think it should be different
06:24:24evanbecause 'class Blah;' is not 'Blah = Class.new'
06:25:09MenTaLguYwell, I probably should have compared to (Blah ||= Class.new).class_eval do; end really
06:26:23evansure
06:26:34evanwhich asks the same question of ||=
06:26:56evanif the answer is "user is dumb, shooting themself"
06:27:06evanthen it's easy.
06:27:38evanbut if we want to say that we try produce a sane result, it's not.
06:27:50evanagain, perhaps it's your definition of sane that's being tested.
06:29:44evanwell, these are all good questions
06:29:49evanthat I have no solid answers to
06:29:57evanI'll think about them in the shower tomorrow.
06:33:56MenTaLguYnods
06:38:38evansadly
06:39:09evansome of these questions are answered by saying "well, autoload is valid semantics and it's fucking broken, so this can be the same as autoload"
06:39:10evananyway
06:39:11evannite!
06:39:16evanthanks the chat
06:39:20MenTaLguY'night
06:39:22MenTaLguYyou're welcome
07:03:21dbussinkmorning :)
11:48:25boyscoutFile#ungetc specs didn't require fixtures explicitly - fd655bb - Dirkjan Bussink
11:57:05boyscoutCI: rubinius: fd655bb successful: 3498 files, 14416 examples, 42216 expectations, 0 failures, 0 errors
15:31:55jakedouglasmorning
15:35:04sbryantMorning
15:59:29evanmorning.
16:00:07cremesmornin'
16:35:06brixenmorning
16:38:58evanbrixen: hey there busy boy
16:39:11brixen:)
16:39:14brixenthis is awesome http://news.yahoo.com/s/ap/20100726/ap_on_hi_te/us_tec_digital_copyright
16:39:18brixenthanks Defiler
16:39:22Defilero7
16:39:39evannice.
16:39:57brixennow we just need a successful class action suit against att for their prices vs shit ass service
16:40:10evanyeah, the gov't is finally getting tech savey enough to realize the DMCA was wool being pulled over their eyes
16:40:18brixenyeah
16:40:20evanonly took them 12 years!
16:40:22evanO_o
16:40:28brixencutting edge
16:41:30brixenlet's see, where did I put these boxes... I need to do some (un)packing :)
16:41:46evan:D
16:41:51evanhow did the talk go?
16:42:13brixengood, I had way too much to talk about
16:42:28evanyeah, that happens.
16:42:34brixenand realized that it's actually a bit more complicated than I expected to talk about the bytecode compiler
16:42:42brixenI want to do a series of screencasts actually
16:43:02brixenI have a few edits to my slides and I'll put them up
16:43:45brixenpegarus is coming along pretty good
16:43:55evanwhich part is that?
16:43:56brixenbut I need to add optimization passes
16:44:01brixenthe peg
16:44:04evanrad
16:44:09evani was looking at pegs last night
16:44:37brixenthey are fun
16:44:40brixenbut slava hates them
16:44:43brixen:)
16:45:13DefilerSuddenly I am more interested in PEGs ;)
16:45:14evanso, is that the port of lpeg?
16:46:10brixenhttp://gist.github.com/490818
16:46:28brixenthis is using the SNOBOL first-class object method
16:46:41evanyep, looks like it
16:46:50evani read the lpeg stuff yesterday actually
16:46:52brixenit's rather verbose, but the LPEG paper suggests that most people use that facility to do major grammars
16:46:53evanthe description, not the code.
16:47:10evanit seems a bit clunky is my worry
16:47:16evancompared to a dedicated grammar syntax
16:47:20brixenwell, there is also a peg grammar to
16:47:21brixener too
16:47:30brixenthat's in the re module in lua
16:48:03evanyeah, i saw
16:48:08brixenoek
16:48:10brixen-e
16:48:11evanthe lua paper was a little hard for me
16:48:21evanbecause lua syntax was getting in the way
16:48:23evancrap like
16:48:26brixendid you read the long one? the one that was published in a book?
16:48:31brixenwww.inf.puc-rio.br/~roberto/docs/peg.pdf
16:48:32evanlpeg.P"b"^0
16:48:46evani'm like "really guys? really?"
16:48:49brixenoh god, yeah lua is O_o
16:48:53brixenhaha
16:48:55brixenexactly
16:49:42evani'm fixing melbourne's syntax error reporting
16:49:45brixenpeg = Pegarus.grammar :grammar
16:49:45brixenpeg.grammar = (peg.nonterminal + Pegarus.pattern("<-") + :sp + :pattern) * 1
16:49:45brixenpeg.pattern = peg.alternative + (Pegarus.pattern("/") + :sp + :alternative)
16:49:45brixenpeg.alternative = (Pegarus.pattern(["!", "&"]) * -1 + :sp + :suffix) * 1
16:49:45evanbtw
16:49:50brixener misfire
16:49:51brixensorry :/
16:49:54evanhah
16:49:55evannp.
16:49:58brixenbut that's defining a grammar
16:50:07brixenthe peg grammar actually
16:50:13evani was checking out the ruby ometa on github
16:50:18evanthat seems to be abandoned
16:50:22brixenyeah, fun stuff
16:50:34brixenI think I got it to do something
16:50:38brixenbut not sure what
16:50:44brixenso I gave up
16:51:03evanI was also thinking about forking treetop
16:51:14evanand making the syntax a bit more terse
16:51:20evanand fixing some of the pain points.
16:51:50brixenyeah, that's what this is :)
16:51:54brixenthis == pegarus
16:52:08evanwell, this looks MORE verbose that treetop
16:52:09evan:D
16:52:16brixenno no no :P
16:52:27evanalso, i don't see how you run code as actions
16:52:40evanlpeg just talks about capturing elements
16:52:53brixengrammar <- (nonterminal '<-' sp pattern)+
16:52:58brixenthat's not verbose
16:53:01evanoh!
16:53:05evansee
16:53:08brixenso, lpeg has a shitton of capture types
16:53:09evani thought it was just the ruby API above
16:53:16brixenthat is the ruby above
16:53:21brixenbut there is a module that parses that
16:53:27brixenbecause the peg grammar is just a peg
16:54:10brixenI'm going for: grammar = (nonterminal '=' sp pattern)+ -> { <capture here> }
16:54:12brixenprobably
16:54:12evanok, so you use the ruby API to parse a terse syntax
16:54:16evanbootstrap style
16:54:17brixenyep
16:54:21evangotcha.
16:54:34evanis it doing memoization?
16:54:41brixenit does, yes
16:54:45evansweet
16:54:52brixenthere is an insn to push a choice obj onto the stack
16:54:56evanis it up anywhere?
16:55:14brixenchoice is not implemented yet
16:55:29brixenhttp://github.com/brixen/pegarus
16:55:57brixenjust pushed some stuff
16:56:16brixenhmm, I should put my slides up, there is a gentle intro in them
16:56:19brixengentle for you :)
16:56:32evan:D
16:57:28brixenevan: check my elle home dir for oscon10.pdf
16:57:34evank
16:57:53brixenI'll post those once I do a few edits, but you can have a look at how the codegen is done right now
16:58:15brixenso, starting on slide 37
16:58:23evanhah
16:58:24evanslide 4
16:58:28brixen:)
16:58:54brixenyou are in all my rubinius talks, as that picture
16:59:51jakedouglasevan: having trouble using your json gem
16:59:57evanok
16:59:59evanwassup with it
17:01:32jakedouglashttp://gist.github.com/490840
17:01:37evanbrixen: oh man! I guess I didn't realize you were at the stage of generating bytecode
17:01:38evanthats awesome.
17:01:44jakedouglassome kind of path confusing?..
17:01:51jakedouglass/confusing/confusion
17:01:54evanjakedouglas: um
17:01:58evandon't you just require 'json'
17:01:58evan?
17:02:04evanrequiring a subpart probably won't work
17:02:34jakedouglasi don't know. i've always seen the json/ext been used
17:02:43evanI dunno then
17:02:48evanthats all inside the json gem
17:02:51evani've used it before
17:03:00evani can try doing require 'json/ext' here though
17:03:38Defileryou're supposed to just require 'json'
17:03:45Defilerand it decides if the native extension is there
17:03:58Defilerbut the docs for that gem are horrible so many people do the json/ext thing
17:04:03jakedouglasok well
17:04:20jakedouglasit's not able to load the extension even just when require 'json'
17:04:37jakedouglasit tries to load the extension and falls back
17:04:41jakedouglasbut the extension is there and it's not loading it
17:04:50evanjakedouglas: hm, ok
17:04:52evanlet me try here.
17:04:53evanone sec.
17:07:42evanbrixen: how many people came to your talk?
17:07:58evanwith so many things all at once at oscon, seems like a crap shoot for people showing up
17:08:28brixenabout 15
17:08:42evanok
17:08:46brixenyeah, the conf is so broad, there are like 12 talks at any one time
17:09:09brixenI did get some spill for the last 10 minutes because state of the onion was in my room following my talk
17:09:48evanaah.
17:10:05brixenevan: so what I'm pondering is whether to do optimization pass as tree manipulation or operate on a stream of insns for the parsing machine
17:10:29evanoperate on the stream for optimizations, you mean?
17:10:30brixenin the bytecode() methods I call the machine "insns" (ruby methods that emit bytecode)
17:10:33brixenyeah
17:10:47brixeneg any(1) + any(2) => any(3)
17:10:52evanwell
17:10:52brixenas a super simplistic one
17:10:58evanyou'd do a combo probably
17:11:11evana tree transform for that seems easy
17:11:23brixenbut there are some serious opts possible, like a (b c) emits much better code as (a b) c
17:11:37brixener a / (b / c) rather
17:11:39evannice
17:11:50evanmy worry about doing it at the bytecode level is atm it appears you're loosing info
17:12:01brixenthe LPEG paper discusses a bunch of the opts
17:12:07evanbecause you lower stuff to stuff like 'if str.size >= 1' ...
17:12:12brixenright
17:12:25brixenI need to abstract eg advancing the subject index
17:12:26evanif you optimize that bytecode stream, it's going to be more difficult
17:12:32brixento make &patt or !patt work
17:12:54brixenoh! I don't mean rbx bytecode stream
17:12:58evanoh?
17:13:04evannow i'm confused.
17:13:04brixenI mean a stream of the parsing machine insns
17:13:09brixenlike any(), char()
17:13:18evan...
17:13:20evani don't follow.
17:13:26brixensee slide 50, 51
17:13:31brixensee the bytecode method?
17:13:50brixenit calls one of the parsing machine "insns", which emits rbx bytecode
17:14:08evanah ok
17:14:11brixenthe semantics of the AST are essentially expressed in a series of machine instructions
17:14:18brixenthat the LPEG paper discusses
17:14:22evanok, i was going to suggest that also
17:14:34evanyou've got another representation between tree and rbx bytecode
17:14:39brixenyeah
17:14:41evanwhich is a linearization of the tree
17:14:49evanthat would be easy to do opts on
17:14:55evanbecause it doesn't loose info
17:14:59brixenright, simple pattern matching works
17:15:00evanand you can do peephole opts
17:15:04brixenyeah
17:15:06evanlose info, rather.
17:15:18evanie
17:15:21evanany g, 1
17:15:23evanany g, 2
17:15:30evanturns into 'any g, 3'
17:15:34brixenright
17:15:39evani'd do it at that level
17:15:40evanthats easy.
17:15:51evaner. easier :D
17:15:55brixenI'm concerned about losing some info actually
17:16:07brixenthe tree represents associativity naturally
17:16:08evanwhich info?
17:16:16evanyes, thats true
17:16:23brixena / (b / c) eg
17:16:35brixenbut I'm not sure that's a problem yet
17:16:38brixenjust pondering
17:16:48evanno reason to restrict yourself to one strategy
17:16:53brixentrue
17:17:01evanpeephole on the linearization is nice for a class of optimizations
17:17:05evantree transform is nice for another
17:17:18brixenwait, I want a one-size fits all! :)
17:18:30evanthen you get a floppy hat that everyone hates
17:18:31evan:D
17:18:37brixenhah
17:19:09brixenso, most of the structure is in place with pegarus, I just need to finish codegen and add captures
17:19:34brixenthis page has docs on lpeg http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
17:19:38brixensee the captures section
17:20:03brixenunfortunately, I don't really know lua so this is rather <waves hands>
17:21:39brixenalso, I think I'll follow ruby semantics with #match (returns matches or capture data structure) and #=~ returns the index past the match
17:22:21brixenalso, match() is lua only matches a prefix of a string, while find() is implicitly: S / . S
17:22:21evanhm
17:22:21evank
17:22:27brixenie, it searches for the start of the pattern
17:25:44brixensay it ain't so: http://bit.ly/c8SpvZ
17:27:06brixen"the rig's safety alarm had been habitually switched to a bypass mode to avoid waking up the crew with middle-of-the-night warnings."
17:27:10brixenbrilliant
17:27:42jakedouglasevan: any idea about why the json extension doesn't get loaded?
17:29:19evanjakedouglas: sorry, about to look.
17:29:26jakedouglasnp
17:30:48evanbrixen: geez.
17:30:58evanwhy the fuck are things like that dependent on windows
17:31:02evanthats fucking scary.
17:32:18DefilerEverything runs on Windows
17:33:07DefilerWhat happens is somebody makes a fancy $$$$ GUI app for Windows because that's what they use
17:33:13Defilerand then it gets integrated into the workflow of something big
17:33:24Defilerand now some poor bastard is stuck making a Windows system into something production-quality
17:33:31brixenevan: well technically we don't know it was windows, but seriously, disabling an alarm on a rig like that?
17:33:33Defilerbut they don't want to get fired so they don't just laugh and run away
17:33:50evan:|
17:33:51brixenDefiler: yeah, pretty sad
17:34:02Defilerhere's a sample from back when I worked with the big $$$
17:34:04Defilerhttp://hellninjacommando.com/temp/awesome_sql.png
17:34:19evanjakedouglas: works fine here
17:34:20DefilerI'll let that sink in for a second, and then tell you that that was as simple and reliable as I could make it, given the tools at hand.
17:34:26evandid you install the json-1.4.3 gem?
17:34:30evannot just json_pure
17:34:58evanDefiler: oh man.
17:35:12DefilerFive previous teams had failed at, basically, writing that query
17:35:13jakedouglasevan: is the extension loading?
17:35:13evanDefiler: I was hoping there was going to be a nested insert in there or something
17:35:13Defilerso they gave it to me
17:35:18Defileron the final escalation team
17:35:36jakedouglasevan: i ran 'rake gem' in the json repository and that's what i got out
17:35:37evanjakedouglas: "json/ext/parser.bundle" is in $"
17:35:38evanso yes.
17:35:51evanwhats what you got out?
17:36:04evanif you only got json_pure out
17:36:07evanthen thats why
17:36:08DefilerAlso, thank you for existing, gvim-on-windows
17:36:16evanyou need to install just json to get the extension
17:36:59jakedouglasokay. any idea how i just get 'json'?
17:37:18evani ran 'rake gem'
17:37:27evanand it was built into pkg/
17:37:57evanoh you know
17:38:02evani ran 'rake gem' with MRI
17:38:03evannot rbx
17:38:13evani wonder if the json rakefile has some crap to detect MRI explicitly
17:38:27jakedouglasi did it with my system ruby too.
17:38:31jakedouglassame result.
17:39:09evandid it make pkg/json-1.4.3.gem?
17:39:14jakedouglasno.
17:39:20jakedouglaspkg/json_pure-1.4.3.gem
17:39:55evani don't know why that is.
17:40:50evando you maybe have an old version of rake?
17:41:51jakedouglask
17:41:52evanlooks like it depends on having Rake::ExtensionTask
17:42:42evanoh, install rake-compiler
17:42:54jakedouglasyea just noticed that. installing.
17:42:55jakedouglasthanks
17:43:15evanthe warning it printed out was something you needed to heed :D
17:43:36jakedouglas:p
17:46:08jakedouglasyou'll be happy to know that after disabling libxml-ruby and a few minor tweaks, our other codebase (not the huge one) passes it's whole test suite on rbx
17:46:25brixenwoot!
17:46:26evansweet!
17:47:20jakedouglasthere's an issue with some gem called 'templater' that rspec and some other things seem to depend on
17:47:41evanrspec depends on it?
17:47:51evani've run rspec before...
17:48:05jakedouglasit defines some version of 'instance_exec' (not sure if you're familiar with it) that really messes something up
17:48:23evanyes, i know instance_exec
17:48:33evanand I know the version in question
17:48:36evanit's insane.
17:48:39jakedouglasheh
17:48:44evanwe should support it, but I almost don't want ti
17:48:48evanit has 1000 problems
17:48:58jakedouglasif I open up the templater gem and make it so it doesn't define that, everything works fine.
17:50:18jakedouglasi don't even really understand how instance_exec is supposed to work, so i didn't bother trying to understand what it was doing.
17:51:40evani'm betting it defines the fucked up instance_exec that showed up in rails at one point
17:51:43evanit's beyond terrible.
17:52:09jakedouglasuh oh. installing your new json gem is making everything blow up again. we were using an older version before (1.2.4).
17:52:24jakedouglasStackError
17:52:32evanfun
17:52:33evan:/
17:52:56jakedouglasdarn.
17:53:09jakedouglasanyway, the gem needs a patch
17:53:40jakedouglas(i wonder if the patch just broke it. hmm.)
17:53:59jakedouglasbrb.
17:58:24dbussinkjakedouglas: json 1.4.3 is broken is my experience
17:58:38dbussinkalso had stackerrors all over the place with that one
17:59:14brixencode samples that cause stack errors?
17:59:42brixenwe should be fixing those issues in rbx
17:59:49brixenor is this happening in mri too?
18:00:36boyscoutTrack all syntax errors and raise the first one - d2c3afb - Evan Phoenix
18:00:36boyscoutHave mspec --spec-debug use the rbx reference debugger - 57405cc - Evan Phoenix
18:00:36boyscoutA bunch of debugger improvements - 7cf1601 - Evan Phoenix
18:01:40brixenxmas!
18:01:54evan:D
18:01:58slavabrixen: I'm working on the slides for my talk later today :)
18:02:00Defilerzmas!
18:02:18brixenslava: fun!
18:02:19evanso, yeah, you can now debug specs very easily
18:02:27evanit's nice.
18:02:35brixenevan: woot!
18:02:36evanguys, please take a spin around the debugger
18:02:39evanand tell me what sucks
18:02:41evanso I can fix it.
18:02:46evanstep isn't there yet still
18:02:50evanthats what i'm doing next
18:02:54sbryantneat-o
18:03:02brixenevan: do we have some docs on that?
18:03:05sbryantI'll see if I have time to put our app on it.
18:03:06evanno
18:03:10brixencode samples I can make docs from?
18:03:14evanbrixen: i'm working on that this week too
18:03:18brixenok
18:04:22jakedouglasok, so json 1.4.3 is just hosed?
18:08:55dbussinkjakedouglas: i've thrown it out and went back to using 1.4.2 in our app
18:08:59jakedouglasok.
18:09:30dbussinkjakedouglas: i think it was something like this: http://github.com/flori/json/issues/issue/34
18:09:54jakedouglasright.
18:10:04dbussinkjakedouglas: and also http://github.com/flori/json/issues#issue/21
18:10:14dbussinkbut flori doesn't seem to respond to anything
18:10:22dbussinkevan: did you get in contact with him?
18:10:28evannope
18:10:30evanno one has.
18:10:41dbussinkjakedouglas: btw, did you talk to evan about that initialization issue you saw in json?
18:11:05dbussinkevan: i saw the rubygems.org guys gave the jruby people access to put a gem up there
18:11:40evanyes
18:11:41evani saw.
18:13:47jakedouglasevan: mind applying this to your json fork? http://gist.github.com/490955
18:13:54jakedouglas(cc dbussink)
18:14:06evansure
18:14:19jakedouglasthanks. it was blowing up rbx occasionally.
18:15:09evanok, just pushed it.
18:15:10dbussinkjakedouglas: does it allocate rbx management memory then?
18:15:24jakedouglasdbussink: sorry?
18:15:41dbussinkjakedouglas: well, i was wondering about the rationale exactly behind it
18:15:45dbussinkwhy it's needed
18:15:55jakedouglasi thought you were here when i explained it
18:16:04jakedouglasno>
18:16:04jakedouglas?
18:16:07dbussinkbecause there are plenty of other c gems that probably allocate memory
18:16:30dbussinki'd have to look it up again, don't remember the exact details anymore
18:16:33brixenhmm, 9 of 10 kernel panics occur while rbx is running specs, wish I knew enough to post mortem debug this
18:16:56evanbrixen: O_o
18:18:05jakedouglasok. the problem is that it's mark function calls rb_gc_mark_maybe with a bunch of it's struct fields. if the fields aren't zeroed out, and haven't been set to anything yet, the garbage memory sometimes appears as a CAPI handle to the gc and it tries to mark it and blows up
18:18:22evanah
18:18:30evanMRI probably happily continues on
18:18:37jakedouglasspecifically, it happens during it's initialize function
18:18:38evanjust an edge case for rb_gc_mark_maybe
18:18:40dbussinkjakedouglas: ah, wait, it wraps it in a Data_Wrap_struct
18:18:53jakedouglasit tries to allocate a new ruby object to assign to one of the fields, that triggers gc.
18:20:51dbussinkjakedouglas: i was just wondering how that allocated memory was seen by the gc, so hence the question
18:21:10jakedouglasoh, yea sorry.
18:21:59dbussinkevan: is this a fixable issue? i can imagine it happening with more gems
18:22:10evanno.
18:22:19evanif there is uninitailized memory
18:22:24evanthen there is uninitialized memory.
18:23:18evanlet me check the impl of mark_maybe
18:23:29evanok yeah
18:23:33evani was wrong
18:23:41evanwe can be doing a fuckload better
18:23:47evanwe never implemented mark_maybe properly
18:23:50evanit's just calls mark
18:23:53evanthere is no condition.
18:23:59jakedouglasuh
18:24:07jakedouglasi thought i saw that it checks CAPI_REFERENCE_P()
18:24:14evanin mark, yes.
18:24:19jakedouglasoh.
18:24:22evanbut that just checks the low bits
18:24:27evanto see if they're zeros
18:24:37evannot if the whole bit pattern points to a valid CAPI handle
18:24:43jakedouglasi see
18:24:46evanbasically, we need to be looping through all handles
18:24:57evanand seeing if the the value passed in is a handle
18:25:07evanwithout deref'ing the passed in value
18:26:51Defilerbrixen: it gets better: http://caselaw.findlaw.com/us-5th-circuit/1532338.html
18:27:18Defilersummary: DMCA just got curbstomped
18:28:44jakedouglasevan: where are the handles stored?
18:29:18evanjakedouglas: look in capi/handle.cpp and builtin/nativemethod.cpp
18:29:21evanfor when handles are created.
18:32:29dbussinkevan: any reason why Kernel.debugger isn't an alias for Debugger.here (if i look at that mspec commit)
18:33:37evanbecause i'm not ready for that.
18:33:59evandebugger is used by ruby-debug and such
18:34:06evanwe need to figure out if we want to also use it
18:34:15evanand it's already missing some features
18:34:27jakedouglasevan: state->shared.global_handles() ?
18:34:48evanjakedouglas: yes.
18:34:55jakedouglask.
18:34:57evaniterate over that and look for ptr
18:35:02jakedouglask.
18:35:20jakedouglasshould i do this in mark_maybe? or just mark?
18:35:29evanmark_maybe
18:35:31jakedouglask.
18:35:43evanthe best would be to abstract the question
18:36:03evanie, add capi::Handle::valid_handle_p(STATE, capi::Handle* ptr)
18:36:08evanand then use it in mark_maybe
18:36:19jakedouglasok
18:38:11dbussinkevan: would that result in a significant performance impact for capi handles?
18:38:15dbussinkduring gc?
18:38:38evanyes
18:38:42evanthats why it only goes in mark_maybe
18:38:45evanwhich is rarely used.
18:39:58dbussinkevan: hehe, first feature request for the debugger, a help command ;)
18:40:11evanthere is one
18:40:19evantype help.
18:40:28evanoh me
18:40:30evani thought there was...
18:40:40dbussinkhehe, i can vaguely remember something too :)
18:40:44dbussinkwhich is why i was surprised
18:40:45evanweird.
18:40:51evan...
18:40:54evanwhere did that go?
18:40:58evananyway
18:40:59evanyes.
18:41:23evanI need to reorganize it a little bit
18:48:27boyscoutPass the current block into an sclass. Fixes #425. - cad251e - Evan Phoenix
18:52:38brixenawesome, I did not realize that was possible
18:52:47evanno did I
18:52:47brixenevan: where is the code that used that?
18:52:50evanand i think it's stu.pid.
18:52:51evanstupid.
18:52:53brixenyeah
18:53:00evanbecause sclass is closed for locals
18:53:07evani guess if you do a return in an sclass
18:53:17evanit's supposed to make the outer method return
18:53:23brixenhuh
18:53:26evanso it's like a block
18:53:35evanagain
18:53:36evanstupid.
19:19:48boyscoutValidate StatiScopes in constant caches. Fixes #426. - 8afb7b4 - Evan Phoenix
19:22:20jakedouglasevan: how do i do the comparison? do i need to cast to intptr_t or something?
19:23:10evanyou can do capi::Handle::from(ptr)
19:23:23evanwhich does a cast, it doesn't deref if
19:23:25evanso it's safe.
19:28:29evanok, lunch time.
19:32:39jakedouglasi don't understand how to get a handle from an iterator
19:35:36jakedouglasok maybe i do
19:36:02jakedouglashow do i compare the two handles? error: no match for ‘operator==’ in ‘i == ptr’
19:49:53JamesKiltontrying to understand the why of Issue 428... that's just weird
20:45:43evanjakedouglas: if(*i == capi::Handle::from(ptr))
20:46:10evani is an iterator, so operator* returns a reference to the current value
20:49:07jakedouglashttp://gist.github.com/491217
20:49:09jakedouglaswhat am i doing wrong there
20:49:17jakedouglaserror: no match for ‘operator*’ in ‘*i’
20:50:04evanoh oh
20:50:05evanack.
20:50:06evansorry.
20:50:38jakedouglasi grabbed that for loop out of nativemethod.cpp
20:50:49evank
20:51:16jakedouglaswhat am i doing wrong? :(
20:51:18evanuse i.current()
20:51:27evani forgot that that code uses my own iterator
20:51:27jakedouglasok
20:51:32evannot a STL iterator
20:51:50jakedouglasah i see
20:51:54jakedouglasok seems to build. thanks
21:14:08jakedouglasevan: can you tell me if this is OK? http://gist.github.com/491260
21:14:53evanjakedouglas: yeah, looks good
21:15:00jakedouglask
21:16:07evanjakedouglas: oh
21:16:13evanyou need to check cached_handles also
21:16:28bakkdoorhey evan, i'm in OC now ;)
21:16:31evanglobals_handles and cached_handles
21:16:32jakedouglasokay. can you explain the difference?
21:17:06evanjakedouglas: cached_handles are walked every transititon between capi code and normal code
21:17:20evanbecause they are handles for data that is cached and must be flushed
21:17:36evanwe have the 2 lists because we don't want to have to check all handles each time
21:17:47jakedouglashmm. i guess i dont understand enough about the handle system to really get it. thanks anyway :)
21:18:06evanfor you, it's easy
21:18:11evanadd another loop in valid_handle_p
21:18:14jakedouglasyea i know
21:18:15evanto check cached_handles also.
21:18:16evank
21:18:21jakedouglasi just wanted to understand what they were
21:18:25jakedouglasthat's all
21:18:51evani gotcha.
21:19:15jakedouglasis it safe to use the same variable name 'i' for the iterator in the second loop?
21:19:20evanyep
21:19:47jakedouglasok. should i check one of global_handles or cached_handles before the other because it would be more likely to reside in one of them/
21:20:00evannope
21:20:09evandoesn't matter
21:20:14jakedouglask
21:23:01brixenum... http://lisp.dive2ent.com/
21:23:30brixenmatz tweeted that btw
21:24:26brixenI wish ragel had a REPL :)
21:25:28evanbakkdoor: hah
21:25:29evaner.
21:25:30evanbrixen: hah
21:25:58evanbakkdoor: when you going to come up to LA?
21:26:48bakkdoorevan: whenever you have time ;)
21:26:57bakkdoorI'm pretty flexible
21:27:42evani've got a normal week this week
21:27:45evanso pretty much anytime
21:27:49bakkdoorok cool
21:27:57tarcierilol brixen
21:29:24jakedouglasjvm langs is much less 'lang' oriented this year it seems.
21:29:39evanjakedouglas: are you there?
21:29:44jakedouglasyea.
21:29:47evannice!
21:30:03evanthey mainly discussing VM stuff?
21:30:11jakedouglasalmost feeling guilty now for getting work to send me under the premise of learning about new languages
21:30:11brixenjakedouglas: are you our rbx proxy? :)
21:30:11evani saw there was a presentation on register allocators
21:30:13evanO_o
21:30:34brixenjakedouglas: assembly is a language too :)
21:30:59jakedouglasyea. there was nutter with mirah, some java thing, some other java thing, the register allocator thing
21:31:11jakedouglasthen there was a jvm coroutines talk which made me feel less dumb
21:31:56jakedouglasbrixen: the current talk is the first one showing assembly. which i actually understand, unlike the java stuff :p
21:32:55evanjakedouglas: no scala or clojure talks?
21:33:01boyscoutCheck the handle against our known set of handles before marking in rb_gc_mark_maybe() - 22c4325 - Jake Douglas
21:33:12jakedouglasit looks like most of the actual talks about languages are on day 3
21:34:46jakedouglasi see groovy, scala, kawa, scala, fortress, erjang
21:35:08evanoh nice, kresten is there
21:35:22evanare they taping it?
21:35:28jakedouglasyea and yea
21:37:02jakedouglasthere was an interesting time-traveling debugger too
21:37:27evannice.
21:37:43jakedouglasi guess its 'workshops' for the rest of the day
21:38:02jakedouglaswhere i lay low and dont let on that im clueless about all this stuff
21:38:29jakedouglasthese guys are another breed, for sure.
21:38:39jakedouglas:p
21:38:47brixenjakedouglas: hah, just consider it a wonderful opportunity to find out how much there is to learn :)
21:38:58jakedouglasthat's why i'm here :)
21:39:13brixenevan: I'm going to a hack session on thurs where we are supposed to play with Rakudo * Perl compiler
21:39:26evansounds fun!
21:39:36brixenI'm trying to get someone who knows perl to pair with me on getting it to emit rbx bytecode for a simple perl snippet :)
21:39:48evan:D
21:40:23brixensounds like the Parrot rewrite might be pretty interesting
21:40:41brixenbut perhaps rbx is Perl6's best shot at usability in the near term :)
21:40:46evanhah
21:40:56evanI saw it's wiki pages
21:40:57slavabrixen: the last 5 parrot rewrites were pretty interesteing too
21:41:03brixenslava: heh
21:41:08evanwhat worries me most is the lack of pragmatism, i guess.
21:41:24evanthey talk a lot about basically, "getting it right" before they start
21:41:42brixenyeah, that's pretty hard to do
21:41:50brixenas they have demonstrated :D
21:41:58evanhey, so have we!
21:42:19brixenI don't think we try to "get it right" before we start
21:42:36evanmy natural pessimism/pragmatism seems to have done us well
21:42:40brixenyep
21:42:48evanoh, I don't mean we tried
21:42:54brixenright
21:43:01evani mean that it's wrong and we've gotten it wrong a few times
21:43:03evaner.
21:43:04evanit's hard.
21:43:06brixenyep
21:48:35evanwell, I wish them well
21:49:18evanthe "lets rewrite everything in a new language on top of our new VM set" sounds like a great time suck.
21:49:27slavaworked for me :)
21:49:35evan:D
21:50:50BrianRice-workI don't know if the perl6 rewrite news shocks me more or the reasons stated why they're doing the rewrite
21:51:03BrianRice-works/perl6/parrot/
21:51:25evanwhich reasons?
21:51:34BrianRice-worksomething about too many opcodes, for one
21:51:58BrianRice-work(hit and run, bbiab)
21:52:10blowmageBrianRice-work: url?
21:52:35evanwell, thats true from what I understand
21:52:40evanparrot has thousands of opcodes
21:52:46evanwhich doesn't seem wise to me.
22:04:18dbussinkevan: this was that parrot rewrite: http://trac.parrot.org/parrot/wiki/Lorito
22:04:26evanyep
22:13:03dbussinkjakedouglas: is your app still showing issue #411?
22:13:16dbussinkbecause i've repro'd it too, no idea where it comes from though
22:14:51jakedouglasyea, last time i was trying to run that codebase against rbx it happened every single time.
22:15:00jakedouglasi never made any progress on it though, beyond what's in the ticket.
22:16:34dbussinkjakedouglas: yeah, i tried to extract the snipped where the error occurs, but stand alone it worked
22:17:28dbussinkevan: could it be that your fixes also fixed #428? because that works for me now
22:17:51evanlets see..
22:18:18evan428 happens to work
22:18:22evanbut not in the proper way
22:18:34evanif you put a 'return 2' after the 'end' of 'class <<'
22:18:36evanyou'll get 2
22:18:37evaninstead of 1
22:18:49evanas for 411
22:18:53evani don't know how it would be related.
22:19:44dbussinkevan: 411 isn't related to this, just wanted to know if jakedouglas still sees it
22:19:55evanah.
22:20:20evanirc needs <hr>
22:21:17dbussinkgoogle wave can do threaded chats :P
22:21:46dbussinkbut anyway, night time!
22:22:13evannite!
22:23:16jakedouglasnite nite
22:23:28dbussinkevan: added a comment to 428 so it's not forgotten
22:24:44brixendbussink: sleep tight! I might have bm results for you on chunky_png when you awake :)
22:24:58evandbussink: why would it be forgotten?
22:26:25dbussinkevan: well, you're the one always talking about writing things down in issues ;)
22:26:33evanok
22:26:33evan:)
22:26:43evani thought you meant the whole issue would be forgotten
22:26:44dbussinkevan: because the code in the issue currently works and maybe otherwise i'd close it in some cleanup spree :)
22:27:00dbussinkbrixen: ah ok, cool, curious to see them :)
22:28:28dbussinkbut anyway, sleep time!
23:58:51evanthe thing I like least about debuggers is that when they show the current line and you hit "step"
23:59:00evanat some point, you return to that same line
23:59:16evanwith barely a clue that you're past the first method call on that line, able to step to the next