Index

Show enters and exits. Hide enters and exits.

02:45:43krainboltgreeneWoooo. Installing rbx.
06:24:06robgleesonhey, can anyone confirm that FFI(0.6.3 from gemcutter.org) is working on rbx 1.0.1?
07:08:33dbussinkrobgleeson: no, ffi can't work
07:08:41dbussinkand never will, since rbx has it's own ffi
07:08:50dbussinkwhich needs to be updated to match the ffi gem's api
07:08:54dbussinkbut that hasn't been done yet
07:09:20robgleesondbussink: yup, thanks, i had filed a ticket in the tracker since i posted my first message ;)
07:09:26robgleesonthat's fine, I'll just need to wait :)
07:10:40dbussinkrobgleeson: we welcome any work to get it up to date though ;)
07:13:03dbussinkrobgleeson: ah, i see evan already replied to the issue too
07:13:39robgleesonyep :)
17:44:32stockholmhi
17:45:20evanhello.
17:45:31stockholmi saw this: http://blog.bitfluent.com/post/27983389/git-utilities-you-cant-live-without
17:45:44stockholmand am especially interested in the rake part
17:45:58evanstockholm: mmhmm?
17:45:59BrianRice-workhg-git is the best thing you can do if git doesn't make sense to you
17:46:14BrianRice-workthere is no way to fix the git UI other than to reject it
17:46:22stockholmBrianRice-work: i think i am on a good way to get what git is about
17:46:26stockholmbut i am not there yet
17:46:30BrianRice-workand yes, I'm bitter at git
17:46:42stockholmand i think the git task for rake is a great help
17:46:45BrianRice-workand also, I grok how git works
17:46:52stockholmthat i would like to use for non-rake things
17:46:55BrianRice-workand it's a load of tosh
17:47:00stockholmtosh?
17:47:02BrianRice-work</rant>
17:47:04stockholmnew word for me
17:47:27BrianRice-work"nonsense"
17:47:38stockholmi was wondering how i could use the rake task without my project using rake
17:47:48stockholmi have a puppet project that is in git
17:48:15brixenstockholm: we made the rake tasks quite a long time ago
17:48:15stockholmrake goes up in the directory tree if it does not find a rakefile
17:48:28brixenstockholm: honestly, most people just use the git commands
17:48:41stockholmi can learn those, too
17:48:49stockholmi liked the push part
17:48:54stockholmit seems to save some time
17:49:08brixenstockholm: I found just making some git aliases helped a lot
17:49:21stockholmok
17:49:25brixenI generally use about 4 commands
17:49:56stockholmi need to find my workflow, still
17:50:03evansomeday I'll pimp git-update more
17:50:05brixenstockholm: here is my ~/.gitconfig http://gist.github.com/549962
17:50:42brixenstockholm: I use git com, git purr, git co <branch>, git rem mostly
17:51:14brixenie, checkout master, pull --rebase, checkout my topic, rebase master, edit, edit, edit
17:51:33stockholmsee, you have stuff like git-update.rb
17:51:35brixeneventually merge back to master and push
17:51:57stockholmpurr is cute
17:52:03brixen:)
17:52:24brixenthe aliases can be super useful for managing your workflow
17:52:34stockholmthanks :-)
17:52:38brixenn/p
17:52:43evanstockholm: well, i'm the only one that uses git-update.rb
17:52:47evanthat I know of
17:52:50evanmaybe others use it...
17:52:51brixenalso, evan is a great person to ask about git stuff
17:52:59evanbut i love it.
17:53:17stockholmlove makes everything easy. :-)
17:53:40evanauto stashing, interactive conflict resolver, etc.
17:53:59brixenevan: yeah, you need to pimp it more
17:54:07brixenlike, write a fancy man page for it :)
17:54:16evan:D
17:59:08sbryantI just use magit, and write bindings for custom stuffs
17:59:16sbryantbut that's because I'm a dirty emacs user
17:59:36sbryantit also means I can hide the entire git front end from myself and write around it.
18:00:15brixenthe only pain I ever suffered from git, or it's commands, was my own ignorance
18:00:27brixenthe time spent learning the commands is well spent
18:00:35brixens/it's/its/
18:00:41sbryantstockholm: have you seen the git parable?
18:01:00sbryantIt can help you get your head around how git works.
18:01:33brixenwhat's funny to me, I never saw a furor about svn commands, and they are certainly no more intuitive than git's
18:02:06brixenthat said, I did not know a bunch of cvs users when I was learning svn
18:02:11sbryantI think it's case of work flow prevalence.
18:02:20sbryantSo, it makes learning new work flows difficult.
18:02:39brixenlearning is difficult, not a reason to eschew it :)
18:02:48sbryanthah, tell that to most people.
18:02:52brixenI am
18:02:53brixen:)
18:02:57sbryant:)
18:03:16sbryantWe just instituted my personal work flow here at the company. Seems to be working out so far.
18:04:00sbryantWhich basically boils down to: don't develop on public branches.
18:04:43brixenpublic branches can be great for collaborating
18:05:04sbryantSure.
18:05:10brixena "public" branch is just where stuff gets integrated when you have a canonical repo
18:05:17sbryantCorrect.
18:05:25sbryantBut real development happens on local branch
18:05:41brixenfor some values of real and local :)
18:05:53brixenpoint is, use what works and let the rest go by
18:06:13brixenhat tips ken kesey
18:06:39sbryantSure, sure. It's not set in stone, just an easy sane default
18:07:32evani warn people of the "you must never work on master ever" hardline philosophy.
18:08:21evani think it's a silly philosophy
18:08:33sbryantI generally like to stay away from ideological stances, as there's almost always some exception that falls outside the ideological philosophy.
18:08:47sbryantstays flexible
18:11:03brixenthis is pretty interesting http://www.caiso.com/outlook/outlook.html
18:11:28brixenphiltor: how's rbx going? any issues, feedback?
18:12:29evanbrixen: that is cool
18:19:31sbryantYou Californians and your power forecasts.
18:21:12stockholmsbryant: no, i havent
18:21:20stockholmsbryant: do you have a uri?
18:21:25stockholmor url :-)
18:22:11sbryantya, let me get it
18:22:18sbryanthttp://tom.preston-werner.com/2009/05/19/the-git-parable.html
18:22:31stockholmthis seems to be a friendly channel.
18:22:49brixenstockholm: we try to be! :)
18:22:53stockholmits funny how different they are :-)
18:22:56sbryantDoes not actually teach you to use git, will teach you how to think in terms of git.
18:23:09stockholmbrixen: i am especially sensitive as a debian developer. :-)
18:23:49stockholmwow, this is long
18:23:57stockholmi will put it on my ebook :-)
18:30:46sbryantstockholm: debian developer, I know a former release engineer. I think it was debian she worked for
18:59:55dbussinkevan: what would be a sane way to check whether something is a string in capi?
19:00:40evana handle or an object?
19:02:24dbussinkevan: it's a VALUE
19:02:34evank
19:02:39evanthere should be plenty of examples
19:02:56dbussinkyeah, i know, but just wondering what would be the best approach
19:02:57evanwhat do you want to do?
19:03:01brixendbussink: in c-api or in c-api implementation?
19:03:09dbussinkbrixen: just using it
19:03:09brixenwe have c_as<>
19:03:15dbussinknot implementation
19:03:24evanStringValue() is the usual way.
19:03:30brixenthat converts a string
19:03:40evanright, but thats still the usual way :D
19:04:23brixendbussink: grep TYPE in spec/ruby/optional/capi
19:04:35brixenif you really need to conditionalize on type
19:04:44brixenbut like evan said, you should probably just be getting a String
19:05:20dbussinktrue, but i don't want it to raise if it's not a string :)
19:05:31brixenyeah, that's what TYPE is for
19:05:50evanor rb_obj_kind_of
19:05:56evannot that people use that enough.
19:06:19brixentrue, that's safer for duck-type code
19:06:45brixenit's the same deal as with Ruby code, don't conditionalize on type except as a last resort
19:07:01brixenthat tends to expose implementation details in a bad way
19:08:13brixendbussink: there are also conversion protocols that return nil rather than raise
19:08:17brixenat least for integer
19:08:23brixenlet's see if there are for string
19:10:10brixendbussink: check out rb_check_convert_type
19:10:19dbussinkbrixen: i couldn't find it, so maybe thought you guys knew
19:10:24dbussinkah ok, will look at that :)
19:10:34dbussinkdon't be bothered too much by my question :P
19:10:55brixenthat's a protocol for converting and conditionally raising
19:11:41brixenactually, it uses convert_type which has the conditional
19:12:02brixenrb_convert_type will raise, rb_check_convert_type will return nil
19:18:14brixenevan: I thought a lot about the 1.8/1.9 stuff after our discussion
19:18:28brixenevan: I'm going to try to spike and push a union branch this weekend
19:18:41evanunion being what?
19:18:57brixena 1.8/1.9 union :)
19:19:06brixenI was going to name the branch "union"
19:19:09evanyou didn't use the word union yesterday
19:19:17brixenyeah, just thought of it
19:19:18evanso i'm asking what strategy union is
19:19:32evan1.8/kernel and 1.9/kernel
19:19:32evan?
19:19:54brixenmastly what we talked about, but I want to try a single kernel that has some conditional logic in the build
19:20:28brixeneg we could have different load_order files that build separate runtime dirs
19:21:14brixenI'm going to try to maximize the shared files and minimize the separate files
19:21:29brixenwhile still loading one or the other environment on boot
19:21:37evan....
19:21:41evanthat sounds more confusing
19:21:43evanbut go for it.
19:21:50brixenyeah, that's why I'm trying it
19:21:54brixenso we can see
19:21:57evansure
19:22:20brixenI'm going to try to doc the tradeoffs and the group they affect
19:22:31brixeneg, devs, users, packagers, documentation, etc
19:22:46evanok
19:23:02evanI can't complain with a documented approach
19:23:02evan:D
19:23:08brixenheh
19:23:25brixenat least it gives us a point to react to
19:24:05brixenmy goal as always is to make it as simple as possible
19:24:29brixenwhich is probably as least complex as possible :)
19:24:56evan:D
19:24:57evani know.
19:25:01evanwell, i'm going to get some lunch
19:25:07evanworking on the new GIL strategy
19:25:16brixensweet
19:34:44dbussinkevan: ah, to fix that issue in hydra?
20:12:52duncanmvevan: just tested, with my rb_hash patch, ruby-rpm gem also builds and pass all tests :-)
20:13:24brixenduncanmv: sweet!
20:13:37evanduncanmv: great!
20:13:49evandbussink: no, unrelated to hydra entirely.
20:14:14dbussinkevan: ah ok, what's the strategy for then?
20:14:37evanmaking it so that threads aren't starved
20:14:44dbussinkah ok, so for 1.1?
20:15:06evanwyhaines found that in some linux's, our code that unlocks the gil, tries to yield, and then relocks, starves the system
20:15:09evanditto with 1.9
20:15:26evanso i'm coming up with a better strategy for yielding control from one thread to the next
20:15:29dbussinkah ok, so a problem with pthreads on those systems
20:15:31evandbussink: yeah, for 1.1
20:15:38evanwell, no
20:15:46evanpthreads is doing what it says it does.
20:16:02dbussinkwell, fairness is usually not really something guaranteed yeah
20:16:03evanthere is no promises or expectations about this behavior
20:20:59duncanmvmmmm, ruby-rpm tests should not be very good. I see rb_new_struct is still missing. Will try to do that one
20:29:45pyonpyonhi, i'm trying to get rubinius vm running on the iphone, and currently having problems with ffi
20:29:48pyonpyoni've seen that ffi utility is limited on the iphone due to mprotect() not working. is this needed by the vm?
20:30:43pyonpyon(i'm currently getting errors such as "Unable to find 'ffi_environ'" at startup)
20:31:15brixenpyonpyon: oh cool re iphone!
20:31:26brixenyes, we use FFI for some pretty fundamental stuff
20:31:50pyonpyonso you think it's hopeless then?
20:31:50evanlibffi probably uses mprotect
20:32:02evani'll bet you could comment out that line in libffi
20:32:04evanand it would work
20:32:23evanthe iphone likely doesn't care about executable bits on pages
20:33:13pyonpyonalright, if you think it can be done i'll keep looking
20:33:47brixenpyonpyon: you might try to find other projects using libffi on iphone
20:33:54brixenfor insight
20:34:23pyonpyonyes there's libffi-iphone port at http://github.com/parmanoir/libffi-iphone and its readme warns about mprotect(), that closures won't work
20:34:45evanthe same things apply to rubinius then.
20:35:41pyonpyonthey suggest using own function pool as a workaround
20:36:53evanthat seems reasonable.
20:44:06pyonpyonthis is a bit over my head, have never used ffi and such before, but i'll see if i can figure it out
20:44:09pyonpyoncool project guys, i've been using yarv on the iphone and embedding it has some limitations due to their use of globals and such - e.g. can't (or difficult to) restart the vm, not to mention run multiple instances...
20:45:45pyonpyonbtw when i run bin/rbx on a .rbc file (both in 1.0.1 and on head) it fails at parsing (probably trying to parse it as a ruby source?); is it supported?
20:46:06evannope
20:46:10evanit's not supported.
21:43:13evanbrixen: playing hooky shortly, but i've been reading the new python GIL impl.
21:43:21evani'm thinking about trying it instead of having our scheduler
21:43:26evanbecause it's simplier
21:43:42evani've already hit some deadlock snags that worry me with the scheduler bit
21:45:24brixenok
21:45:46evantheir new gil also deals with timing inline
21:45:54evanie, no extra timer pthread
21:45:56evanwhich is ince.
21:45:57evannice.
21:46:46brixenah indeed
21:47:01brixenI'm looking at the slides by david beazley
21:47:30evanby making the GIL be 2 mutex+condvar pairs
21:47:36evanit's possible to force switching
21:48:03brixencool
21:48:06evanbecause when you yield, you broadcast on cv1 and then wait on cv2
21:48:24evanthe person who gets control has been waiting on cv1, and they then broadcast on cv2
21:48:40evanso that the yielder slips into the normal wait loop
21:48:59brixengotcha
21:49:02evanbasically, it's a handshake
21:49:09brixenyeah
21:49:10evanrather than just throwing snowballs at the other thread
21:49:13brixenheh
21:49:29evanYOU GO YOU GO GO GO GO GOG FINE I'M GOING
21:49:48evanok, i'm going to work on this a bit later.
21:49:51brixenok
21:50:24duncanmvnotices for the capi specs of methods with va_args, you wrap the spec method into a sa_foo which haves fixed params, enough to test