Index

Show enters and exits. Hide enters and exits.

00:08:00boyscoutRemove tag for failing spec: IO.foreach with nil separator - dbecff8 - Jake Douglas
00:08:00boyscoutFix IO.foreach with a nil separator, it should yield the entire contents at once - 0f62f5e - Jake Douglas
00:16:40boyscoutCI: rubinius: 0f62f5e successful: 3498 files, 14363 examples, 42133 expectations, 0 failures, 0 errors
01:06:12DefilerHey what is that good alternative to 'dircproxy'?
01:06:21DefilerShorter name, can't remember what though.
01:07:04evanI used bip
01:07:09evaner
01:07:10evanuse.
01:07:20Defileraha, right
01:07:21Defilerthanks
01:07:27evanno prob.
01:22:46jakedouglasevan: are there any idiosyncrasies to be aware of with Type.coerce_to and mocks?..
01:29:19evanjakedouglas: not that i'm aware of, no.
01:32:04jakedouglaseh fuck
01:32:12jakedouglasi was just confused about the spec. GOOSE CHASE.
02:11:24jakedouglasevan: around?
02:14:03jakedouglasthe issue is that when IO.select needs to call #to_io on one of the passed objects, it's supposed to return the original object in the result, not what it gets from #to_io
02:14:42jakedouglaswondering if i should make the change in the C++ function or if i should just use the return value of that and do it in the ruby IO.select wrapper
02:16:25jakedouglasi guess to do it in C++ you'd have to push the type coercion stuff down into there, it's currently being done in Ruby
02:17:27boyscoutAdd more description to an IO.select spec - f424655 - Jake Douglas
02:26:06boyscoutCI: rubinius: f424655 successful: 3498 files, 14363 examples, 42133 expectations, 0 failures, 0 errors
02:50:34boyscoutfix for "IO#readpartial discards the existing buffer content upon error" - 91bece4 - Jake Douglas
02:50:34boyscoutRemove some now-passing tags for IO#readpartial - 036ba22 - Jake Douglas
02:59:18boyscoutCI: rubinius: 036ba22 successful: 3498 files, 14366 examples, 42139 expectations, 0 failures, 0 errors
03:47:13jakedouglashas made the mistake of trying to fix a thread spec
03:58:55brixenjakedouglas: the proper way to do coercion is to have the prim fail and coerce in the fallback code, then redispatch
03:59:22jakedouglasdo you have an example?
03:59:30brixenyes, getting you one :)
03:59:34jakedouglasthanks
03:59:41jakedouglasgives up on the thread issue
04:00:00brixensee kernel/common/array.rb:487 def concat
04:01:16jakedouglasso the primitive is able to return out of that method, and the code below the primitive call only gets executed if it doesnt?
04:01:28brixenthe primitive is not a call
04:01:37brixenit tags the method as being a primitive
04:01:52brixenthe vm executes the primitive when that method is called
04:02:00brixenif the primitive fails, the ruby code runs
04:02:05jakedouglasok
04:02:27brixenso, the primitive should fail if eg as<IO>(arg) is used
04:02:50jakedouglasthe IO.select case is a little more complicated
04:02:56jakedouglasis what's being done incorrect?
04:03:03brixensee vm/builtin/array.cpp ::concat
04:03:15brixenyou can see how to force a failure based on a condition
04:03:15jakedouglaskernel/common/io.rb:567 def self.select
04:03:23brixeneg if(is_frozen_p()) return force_as<Array>(Primitives::failure());
04:03:57brixenI don't know about IO.select, I'm just giving you the pieces you probably need
04:04:07jakedouglasthanks
04:04:07brixenand I have to get back to my slides :/
04:04:20jakedouglasok
04:31:53boyscoutfix failure for "Fiber.new raises an ArgumentError if called without a block" - 11f379b - Jake Douglas
04:31:54boyscoutRemove fail tag for "Fiber.new raises an ArgumentError if called without a block" - 8d3e482 - Jake Douglas
04:40:24boyscoutCI: rubinius: 8d3e482 successful: 3498 files, 14367 examples, 42140 expectations, 0 failures, 0 errors
05:00:50jakedouglaswhats the status on fibers? half done?
07:22:54dbussinkbrixen: t-mobile has the iphone in the netherlands and it has been pretty much like the at&t experience in the us here with them...
13:26:22dbussinkgoyox86: ping?
13:27:21goyox86dbussink: here i am
13:27:50dbussinkgoyox86: got a small remark on #424, i see you used tabs in your patch
13:27:52dbussinkand not spaces
13:28:27goyox86dbussink: understood
13:30:09goyox86dbussink: i use textmate, i should configure it to use spaces? or something like that? :s
13:30:30dbussinkgoyox86: yeah, at the bottom you can select what type of tabs it should use
13:30:36dbussinkshould be soft tabs 2 for rbx
13:30:52dbussinkthe soft tabs / spaces is a checkmark at the bottom of the selector
13:39:08goyox86dbussink: should i fix it, and gist another patch?
13:41:55dbussinkgoyox86: you can edit the gist too
13:42:24goyox86dbussink: k
15:34:40jakedouglasmorning
15:56:23jakedouglasalmost has most of the fiber specs passing
15:59:43goyox86jakedouglas: do you now that Fiber is something taht is not implemented in rbx :)
16:00:18jakedouglasthats not quite true. maybe they arent nice and polished, but they exist
16:01:14goyox86jakedouglas: some days ago evan told me that let me look at irc logs :]
16:01:32jakedouglasmaybe im wasting my time working on them, then
16:01:58evanjakedouglas: nah, carry on.
16:02:03jakedouglasoh. ok
16:02:10evannot a waste of time.
16:02:21jakedouglasevan: what's incomplete about them, other than the spec failures?
16:02:23evanFiber is just experimental is all.
16:02:30jakedouglasok
16:02:39evanI didn't flesh out parts of the API
16:02:43evanso probably just spec failures
16:02:57jakedouglascool. well im down to 4 failures :)
16:03:04goyox86dbussink: i've fixed the patch http://gist.github.com/485325
16:03:28goyox86jakedouglas: nice! :]
16:05:01evanok boys
16:05:03evani'm off
16:05:08evani'm in San Diego for Comic-Con
16:05:21evantalk to ya later
16:05:25brixenhi evan!
16:05:27brixenhave fun!
16:05:30evanhi brixen!
16:05:34jakedouglassee ya
16:05:35goyox86evan: have fun!
16:05:40evanok, real fast.
16:05:44evanbrixen: hows the talk coming?
16:05:47brixengood
16:05:56jakedouglasintends to sneak in a bunch of patches while evan is gone
16:06:07brixenjakedouglas: git tells all :)
16:06:42jakedouglasheh
16:07:56evanall right, off to get coffee and see the nerds. :)
16:08:04jakedouglaslater
16:08:04brixenwoot
16:08:34jakedouglasbrixen: yo, compiler dude
16:08:37evanbest part is this year our hotel is next door
16:08:40evananyway
16:08:41evanlater!
16:08:46brixenbye!
16:08:57brixenjakedouglas: sup?
16:09:39goyox86brixen: how was OSCON? :)
16:09:53jakedouglasbrixen: "Fiber.new raises a SyntaxError when the block contains a retry statement"
16:10:05jakedouglasbrixen: is that something that needs to be dealt with in the parser/compiler?
16:11:04brixenjakedouglas: hm, not sure
16:11:16brixenI'd have do dig into in but I need to work on slides still
16:11:21brixensorry :/
16:11:25jakedouglassure
16:11:29jakedouglasnp.
16:11:39brixengoyox86_: it's good, still going, my talk is this afternoon
16:12:02brixenfades
16:12:15goyox86brixen: have fun! with those slides!
16:12:25brixengoyox86_: thanks
16:40:57jakedouglaswhat does try_as and as do
18:54:22dbussinkjakedouglas: try_as will try to cast the object and return NULL if it doesn't succeed
18:54:34dbussinkjakedouglas: as will cast it and blow up if it fails
18:55:11jakedouglasi see
18:59:58dbussinkjakedouglas: you can also see how it's used with that then, try_as is almost always in an if statement
19:00:03dbussinkto check some different types
19:10:59boyscoutModule#class_variable_set now raises a TypeError when self is frozen - 32cb3ca - Jose Narvaez
19:11:00boyscoutRemove tag for passing Module.class_variable_set specs - 8c022b2 - Jose Narvaez
19:11:05dbussinkgoyox86_: there you go
19:11:29goyox86dbussink: :]
19:19:47boyscoutCI: rubinius: 8c022b2 successful: 3498 files, 14368 examples, 42142 expectations, 0 failures, 0 errors
19:28:51jakedouglasdbussink: so if i had an Object that could potentially be an Array, would i want to use try_as?
19:29:18dbussinkjakedouglas: yeah, but if you know it always should be an array, you should use as<>
19:29:26jakedouglasok.
19:30:47jakedouglasdbussink: are u familiar with the fibers stuff?
19:32:43dbussinkjakedouglas: no, not really
19:32:58jakedouglask
19:34:46goyox86jakedouglas: how is it going with Fiber specs?
19:35:01jakedouglasi have 2 faliures left
19:35:21dbussinkjakedouglas: running the 1.9 specs against it?
19:35:23jakedouglasboth of them probably have to be handled in the compiler so i dont know where to start
19:35:48jakedouglasdbussink: i duno, im just running bin/mspec spec/ruby/core/fiber/
19:35:57jakedouglasdbussink: is that it? or is that different
19:36:44dbussinkjakedouglas: yeah, that's correct
19:36:55jakedouglasok
19:37:12jakedouglaswell ya…the last 2 failures are
19:37:19jakedouglas"Fiber.new raises a SyntaxError when the block contains a retry statement"
19:37:24jakedouglas"Fiber#resume executes the ensure clause"
19:37:35jakedouglasthe first one is straight forward
19:37:40jakedouglasthe second one basically says
19:37:54jakedouglasbegin; Fiber.yield; ensure; puts "BLAM"; end
19:38:03jakedouglasshould puts "BLAM" before yielding
19:38:12jakedouglasi dont know where to start for either one
19:38:31dbussinkhmm, both probably require some work in the compiler
19:38:39jakedouglasyea. figured
19:39:16Defilerevery method call should puts BLAM
19:39:55jakedouglasis it different because it's a primitive or something?
19:41:20jakedouglasthe spec is a little more complicated I guess
19:42:32jakedouglasmaybe im not understanding it or the ruby_bug stuff correctly
19:42:56jakedouglasit's in spec/ruby/core/fiber/resume_spec.rb
19:43:23jakedouglascan someone clarify whether i should be trying to make it pass?
19:44:38jakedouglashttp://redmine.ruby-lang.org/issues/show/595 discusses it
19:44:56jakedouglasbut i only speak english
19:45:05dbussinkjakedouglas: ruby_bug means that it's a confirmed bug in ruby
19:45:13dbussinkso that means that rbx should pass it
19:45:22jakedouglasok
19:46:05dbussinkbut it's marked with ruby_bug so a run on mri is clean
19:46:14jakedouglasi dont really understand why fork for the spec
19:46:47dbussinkdunno, maybe it was only occurring then in mri
19:47:14dbussinkif you want to know for sure, you should try creating a spec without fork and run that on 1.9.1 and the 1.9.2-rc
19:47:25dbussinkso you can see whether it indeed fails on 1.9.1 and passes on 1.9.2
19:47:36dbussinkbut i don't know the details of this either
19:48:40jakedouglasit doesnt appear to work on either heh
19:50:15jakedouglasi guess it's still 'open'
19:51:12dbussinkjakedouglas: yeah, looks like it
19:51:39jakedouglasany idea where i would look to fix this in rbx?
19:52:01dbussinknot really
19:52:05dbussinkmaybe Defiler has an idea?
19:52:13dbussinkDefiler: or are you too much out already
19:52:13dbussink?
19:52:17jakedouglasis there something i can grok from some piece of the environment in C++ about whether theres an 'ensure' supposed to be going on?
19:53:01dbussinknah, this is more something you should look up in the compiler
19:53:09dbussinkto see how code for an ensure is emitted
19:53:25DefilerSorry, have to make a phone call right now, but I can look in a minute
19:53:27jakedouglashmm. ok
19:53:33jakedouglasi mean
19:53:39jakedouglasi guess the behavior of ensure is like
19:54:21jakedouglasif the code after begin succeeds, the ensure block is executed after. if it raises, then ensure is run before propogating the raise
19:54:47jakedouglastheres no exception being raised from Fiber.yield and its just pulling the rug out so it has no idea
19:55:05jakedouglasso the compiler would have to know that we're inside a fiber and about to call Fiber.yield and that it should run ensure first i guess
19:55:50jakedouglasbut i dont really know how the compiler works so thats just speculation
19:56:45dbussinkjakedouglas: well, the vm has no knowledge of an ensure concept
19:56:51jakedouglasoh, ok.
19:57:05dbussinkso that's all about what bytecode the compiler outputs
20:02:03dbussinkjakedouglas: you can look at lib/compiler/ast/exceptions.rb to see how an ensure is translated into bytecode
20:02:29dbussinkjakedouglas: it's quite complex already :S
20:03:31jakedouglas:(
20:04:07dbussinkjakedouglas: but since this still seems to be open in 1.9.2 i'd suggest focussing on something else :)
20:04:33jakedouglassure. i mean i think its a similar issue though to the other spec that retry within the fiber fails
20:04:53jakedouglasi assume they both require some contextual awareness that they are about to be executed in a fiber
20:04:58dbussinkyeah, i think there are easier things to persue
20:05:01jakedouglasbut i dont know how that works so ill give up on them
20:05:05dbussinkyeah, they probably do yeah
20:05:20jakedouglassounds like a job for brixen.
20:06:22dbussinkyeah, if it gets too hard i always do that too :p
20:07:12jakedouglas:p
20:07:43jakedouglasi assume that since fibers are 'experimental' i dont need to worry about breaking anyones using them right now
20:07:52jakedouglas(not that i intend to)
20:08:54dbussinkjakedouglas: feel free to push fixes you have up till now :)
20:09:01dbussinkjakedouglas: it's still experimental yeah
20:09:33jakedouglask. i wanted evan to look at my fixes because the whole fiber thing is a little confusing but i guess i cant fuck anything up too bad as long as the specs pass heh
20:09:44goyox86jakedouglas: i've seen a few of File specs tagged a fails, yesterday i saw you fixed some in IO, maybe you can take those down :] (abopout something else dbussink mentioned above)
20:10:24goyox86jakedouglas: did you checked that ones?
20:10:34jakedouglasnot yet..let me clean up this fiber stuff and commit it first
20:10:57dbussinkgoyox86_: hmm, i haven't touched IO, what are you referring too?
20:11:28goyox86dbussink: i mean jakedouglas touched IO yesterday
20:12:07dbussinkgoyox86_: ah ok, but what can be taken down then?
20:12:51goyox86thinks his english sucks :]
20:13:38goyox86dbussink: when i say "take them down", i've tried to say "make them pass"
20:16:38goyox86enjoys dig into rbx code base while listening some Jimi Hendrix tunes
20:24:41jakedouglaswith_feature :fiber_library do
20:24:48jakedouglashow do i specify that rbx has said feature
20:25:05jakedouglasrealized i did not execute this other spec..
20:36:09dbussinkjakedouglas: if you look at spec/default.mspec you see that it should be enabled for rbx
20:37:26jakedouglasi have to add
20:37:26jakedouglasMSpec.enable_feature :fiber_library
20:41:22jakedouglas"// Beware here, because the GC has probably run so GC pointers on the C++ stack can't be accessed."
20:41:26jakedouglaswhat does this mean
20:41:53jakedouglasor what is an example of something i can't do
20:45:57boyscoutFiber fixes: add a FiberError, raise FiberError when attempting to yield from root fiber, raise FiberError when attempting to resume dead fiber, call the fiber block with the arguments given to #resume, return the result of the fiber block to the caller after #resume returns - 8f2c492 - Jake Douglas
20:45:57boyscoutRemove a bunch of failing tags for Fiber specs - c1ba713 - Jake Douglas
20:50:23dbussinkjakedouglas: btw, could you make a multiline commit message from that next time?
20:50:28jakedouglassure. sorry
20:50:57dbussinkjakedouglas: convention is that if it doesn't fit in one line, is to add a one line summary, an empty line and then multiple lines of more explanation
20:51:26dbussinkjakedouglas: something like this: http://github.com/evanphx/rubinius/commit/8c5d7012fefe0ea9358dbb4bd8f633f41bf87582
20:52:35jakedouglasok
20:53:04jakedouglasdbussink: i want to implement Fiber#alive?, so it just needs to check a variable. should i implement a primitive to check it, or should i just make something set an instance variable that i can check that from ruby?
20:53:26dbussinkjakedouglas: well, if a ruby ivar suffices, i'd do with that for now
20:53:36jakedouglasit certainly does
20:53:42dbussinkjakedouglas: or do you need to set / access it from a primitive too?
20:53:46jakedouglasnope
20:53:57jakedouglaswhen the fiber is done executing it can just set an ivar
20:56:37jakedouglas"// GC has run! Don't use stack vars!"
20:56:41jakedouglasi wish i knew what this means :p
20:57:01dbussinkjakedouglas: you should catch even after the weekend for that i guess :)
20:57:13jakedouglasheh
20:57:51boyscoutCI: rubinius: c1ba713 successful: 3498 files, 14379 examples, 42155 expectations, 0 failures, 0 errors
21:12:57jakedouglasyea im definitely doing something wrong, blowing up the gc.
21:17:50brixenjakedouglas: the GC cannot see the C stack
21:17:56brixenit only knows about the shadow stack
21:18:20brixenso if you call back into the interpreter, the GC may run and move a reference
21:18:44brixenwhen the call into the interpreter returns, the value of the reference on the C stack now points to invalid data
21:18:55dbussinkbrixen: hmm, do i remember right that you knew some fix for process.kill / process.wait failures?
21:18:58brixenyou have to use OnStack to protect a reference that is on the C stack
21:19:11brixendbussink: not offhand, no
21:20:10brixenjakedouglas: grep for OnStack in vm and see if it makes sense
21:20:16brixengoes back to slides
21:21:15jakedouglas49 if(obj->zone() != YoungObjectZone) return obj;
21:21:25jakedouglas^ would seg faulting here be a result of that?
21:21:32brixencould be, yes
21:21:49brixenshow me the code you added
21:22:24jakedouglashttp://github.com/evanphx/rubinius/commit/8f2c4928793a9e6fe72aae8bf7db79868869fc68
21:23:28brixenyeah, you have a problem there
21:23:37brixenyou have Object* result
21:23:47brixenthat has to be on OnStack
21:24:10brixenObject* result is just a pointer on the C stack
21:24:21brixenthe GC will move the obj it references
21:24:43jakedouglasi mean
21:24:53jakedouglasit's not pointing to anything before i call send
21:24:59jakedouglasso what's being moved?
21:25:55brixenwhat does dest->run() do?
21:26:08brixenI have not looked through this code
21:26:12jakedouglasit just sets 2 variables on the C++ object
21:26:39brixenbut I can guarantee you 2 things: evan doesn't put spurious comments like this in, and Object* result is a bare reference on the C stack
21:27:27jakedouglasyea, you're saying the the GC will move objects
21:27:42jakedouglasbut Object* result isn't pointing at any object until the call returns, is it?
21:28:05brixenno, but that's not what I'm concerned about
21:28:26brixenI'm concerned about what happens between that assignment and the accessor assignment
21:28:32brixendebug it :)
21:28:35jakedouglasi see.
21:28:50jakedouglasi'm not arguing, i'm just asking for moar info because i don't understand heh
21:28:59brixengotta get back to this, but I think you have the pieces you need
21:29:04jakedouglasthanks
21:29:12brixenyeah, I know, I didn't think you were arguing :)
21:29:32brixenI'm only trying to explain 1. the mechanics, and 2. how to evaluate what you are looking at
21:29:41jakedouglas:)
21:30:24brixenthe GC only looks in certain known locations for references, and the C stack is not one of those locations
21:30:38jakedouglasgot it
21:30:40brixenthe GC can run any time you call into the interpreter (which obj->send() would do)
21:31:04jakedouglasoh. but it's concurrent right, so it could continue running after the obj->send() returns?
21:31:16brixenno, the GC is stop-the-world
21:31:16jakedouglasoh
21:31:26jakedouglasor Object *result might just be nothing when obj->send() returns
21:31:36jakedouglasor points to bogus shit
21:32:07brixenhmm, no
21:32:11brixenlet me look at this code
21:32:22jakedouglasok
21:32:34boyscoutRemove some tags that were marked as critical but run fine now - 8d9382e - Dirkjan Bussink
21:41:03brixenjakedouglas: I don't see a problem with the changes to start_on_stack
21:41:09brixenbut you have a few changes in that commit
21:41:14brixenyou'll have to try to isolate it
21:41:19boyscoutCI: rubinius: 8d9382e successful: 3498 files, 14390 examples, 42168 expectations, 0 failures, 0 errors
21:46:57jakedouglasbrixen: do I have to worry about 'state' changing or will that be OK
21:47:35brixenthat would be fine
21:47:42slavahi brixen
21:47:42brixenjust references to Ruby objects
21:47:45brixenhi slava
21:47:51slavagoing to attend my talk?
21:47:54brixenslava: got your neckbeard grown yet?
21:48:04brixenslava: mm, I'm still in NW
21:48:07slavaworking on it
21:48:10brixenheh
21:48:13brixenme too
21:48:14slavaI haven't shaved since monday
21:48:23brixenme neither!
21:48:33slavawe're practically twins
21:48:39brixenno doubt
21:48:47brixenwant to trade talk slots? :)
21:48:58slavawhy don't you just give my talk?
21:49:08brixenI should!
21:49:14brixeneveryone would be like "that looks a lot like Ruby"
21:49:17brixen:D
21:49:30slavaall the other languages presented so far look a lot like ruby
21:49:34brixenheh
21:49:42brixenwell, you should stand out then
21:50:11slavaat this summit, I have seen the future of programming languages, and it looks a lot like the past of programming languages
21:50:31brixenI need to find a large steel cage on wheels soon to make my way your way
21:50:54brixenyeah, if there's one thing we are *really* good at, it's re-inventing the wheel
21:51:43brixenslava: good luck with the talk!
21:51:47slavathanks
21:51:56slavaonly two hours left!
21:52:10brixenI know!
22:36:38jakedouglasblah
22:52:15jakedouglasi don't see anywhere that i'm trying to access a stack var after evans comments
22:55:07jakedouglaseverything after that gets accessed via Fiber::current(state)
23:03:38matthewdjakedouglas: Without looking closely, I'd guess maybe dest->run() could also GC?
23:04:00jakedouglasno
23:04:45jakedouglasthat's deceiving, it doesn't actually do anything other than set a couple variables in C++
23:10:18jakedouglasthe place it crashes now is actually different than before, i guess i had made another change. the crash for the last commit i pushed is at
23:10:29jakedouglasrubinius::ObjectHeader::zone () at oop.hpp:280
23:10:29jakedouglas280 if(inflated_header_p()) return inflated_header()->flags();
23:59:00jakedouglasuhg
23:59:11jakedouglasinconsistent build :/