Show enters and exits. Hide enters and exits.
| 05:02:17 | giancarlo84 | Hi, is there a curses library for rubinius compatible with the one in ruby 1.9 |
| 05:19:52 | matthewd | evan: Sorry, I didn't get a chance to do anything last night; I'll push tonight. |
| 13:23:42 | boyscout | method_defined? shouldn't search Object/Kernel. - fc14d35 - Matthew Draper |
| 13:23:42 | boyscout | Kernel is a module too, and so should search Object. - 221cc80 - Matthew Draper |
| 13:23:42 | boyscout | Spec that method_defined? doesn't search Object/Kernel. - 9c4aa8f - Matthew Draper |
| 13:23:42 | boyscout | Spec that some Module methods search Object too. - 77f8d1d - Matthew Draper |
| 13:31:45 | boyscout | CI: rubinius: 77f8d1d successful: 3463 files, 13870 examples, 41532 expectations, 0 failures, 0 errors |
| 14:03:17 | goyox86 | JOIN gentoo-ve |
| 14:03:24 | goyox86 | JOIN #gentoo-ve |
| 14:04:09 | cremes | goyox86: you need a forward slash in front of join |
| 15:25:13 | matthewd | evan: http://gist.github.com/415926 okay? Everything passes. |
| 16:01:00 | brixen | morning |
| 16:01:04 | brixen | matthewd: looks ok to me |
| 16:03:37 | boyscout | Remove redundant method lookup functions. - 6b20492 - Matthew Draper |
| 16:04:03 | matthewd | brixen: Thanks; just wanted a sanity check before playing with stuff.. even though I know that's really what the specs are for :) |
| 16:06:32 | brixen | heh, yes, a review never hurts :) |
| 16:06:47 | brixen | thanks for working on that! |
| 16:07:07 | brixen | also, it's still possible to write very broken stuff even with the specs |
| 16:07:15 | brixen | and evan is a good broken detector |
| 16:07:36 | evan | morning lads. |
| 16:07:44 | brixen | morning |
| 16:08:36 | evan | i'll give it a once over. |
| 16:08:50 | matthewd | brixen: It was a fun twisty little passage... started out with method_defined?(:id), found the check-Object-too stuff, tried just removing that (per evan's suggestion)... and ended up working out that far less things failed than should have :P |
| 16:09:22 | brixen | heh |
| 16:09:27 | brixen | that's always fun |
| 16:10:37 | brixen | for me, that usually leads to a file that hase one: it "needs to be review for spec completeness" |
| 16:11:27 | evan | matthewd: :/ |
| 16:11:29 | evan | matthewd: in the future |
| 16:11:37 | evan | please do the fix in one commit |
| 16:11:45 | evan | then the commit that removes the redundent methods in another |
| 16:11:48 | boyscout | CI: rubinius: 6b20492 successful: 3463 files, 13870 examples, 41532 expectations, 0 failures, 0 errors |
| 16:11:52 | evan | it's hard for me to tell which is which. |
| 16:11:58 | matthewd | evan: I did? |
| 16:12:06 | evan | you did what? |
| 16:12:14 | evan | you put both bodies of work in one commit |
| 16:12:15 | matthewd | I thought I did separate them |
| 16:13:04 | evan | nope. |
| 16:13:07 | matthewd | Erm, well, the removing redundant methods meant merging two functions (adding a param, changing callers to use the other function and handle the different return) |
| 16:13:42 | evan | oh, hrm, is see. |
| 16:13:46 | evan | it's just a little confusing. |
| 16:14:10 | evan | ok |
| 16:14:11 | matthewd | But the fixing of the identified issues was in fc14d35 and 221cc80 |
| 16:14:13 | evan | it's cool, i gotcha. |
| 16:14:22 | evan | though, i worry about http://github.com/evanphx/rubinius/commit/6b204921badcd210a063d7e87a73d186bc30ecc9#L0L120 |
| 16:14:35 | evan | you deleted 3 lines at the bottom of a method |
| 16:14:48 | evan | that seem important |
| 16:15:29 | evan | aren't those lines where you're supposed to be using check_object_too? |
| 16:15:37 | matthewd | That's just the diff being confusing |
| 16:15:50 | matthewd | It uses the last lines of the otherwise-deleted following function |
| 16:16:11 | evan | oh weird. |
| 16:16:13 | evan | oh oh. |
| 16:16:14 | matthewd | Though I apparently managed to end up with the less accurate comment :/ |
| 16:16:17 | evan | le sigh. |
| 16:16:27 | evan | my fault. |
| 16:16:32 | matthewd | fixes comment |
| 16:16:41 | evan | yeah, that comment needs to be fixed |
| 16:16:45 | evan | i'm looking at module.rb without the diff |
| 16:16:47 | evan | it's clear |
| 16:16:53 | evan | what you did. |
| 16:17:08 | evan | putting it together from the diff is, i guess, something i shouldn't attempt without more morning coffee. |
| 16:17:34 | matthewd | heh :) |
| 16:18:34 | brixen | I really wish I at least read/wrote japanese |
| 16:18:42 | brixen | so much discussion happens on ruby-dev |
| 16:18:59 | brixen | thankfully, mame is curating specs now it seems |
| 16:19:15 | brixen | that's Yusuke Endoh |
| 16:19:24 | evan | :) |
| 16:19:25 | evan | good! |
| 16:19:51 | brixen | I wish he'd hang out in #rubyspec |
| 16:20:23 | boyscout | Fix a now-inaccurate comment; the flag means "always" is a lie. - 40e02ed - Matthew Draper |
| 16:20:39 | evan | heheh |
| 16:20:42 | evan | the flag is a lie! |
| 16:21:20 | matthewd | has his flag and eats it too |
| 16:21:40 | evan | is there frosting on it? |
| 16:22:58 | matthewd | That depends... it's Modular, you see |
| 16:23:15 | matthewd | Some people like frosting, others would Object |
| 16:25:45 | brixen | hah |
| 16:27:18 | evan | matthewd: ZING. |
| 16:32:42 | evan | AWESOME |
| 16:32:51 | evan | they had a successful test of a ramjet engine |
| 16:33:02 | evan | Mach 4.5 for 200 seconds. |
| 16:33:16 | brixen | wowsers |
| 16:33:21 | BrianRice-work | thus burning more fuel than my motorcycle does in a year |
| 16:33:44 | brixen | BrianRice-work: I'm guessing more than your motorcycle would use in a century |
| 16:33:48 | brixen | or 5 |
| 16:34:02 | brixen | if you drove it constantly :) |
| 16:34:09 | BrianRice-work | oh it's not that bad |
| 16:34:12 | evan | BrianRice-work: you're bike runs on liquid oxygen? cool! |
| 16:34:21 | BrianRice-work | oh, I wish |
| 16:34:31 | BrianRice-work | turbine-power would be awesome |
| 16:34:43 | evan | ramjet has no turbine. |
| 16:34:48 | evan | it has no moving parts in fact. |
| 16:34:59 | evan | it's a pure air compression engine |
| 16:35:01 | BrianRice-work | yes, I'm aware. I did study aerospace engineering for a bit |
| 16:35:06 | evan | oh oh ok! |
| 16:35:36 | BrianRice-work | and worked on nuclear reactors. I mostly know the gas figure because of the F-15 zoom climbs by the air national guard in PDX |
| 16:35:50 | matthewd | Oh, easy win I noticed in passing: `Bignum.new`. I'm up far too late again, but I promise I'll ticket it (and probably just fix it, if no-one else has) tomorrow morning. :/ |
| 16:36:01 | BrianRice-work | which, yeah, consume enough gas to push my bike 20,000 miles :P |
| 16:36:11 | BrianRice-work | digresses, goes back to perl code |
| 16:36:16 | evan | BrianRice-work: :) |
| 16:36:41 | evan | perl code, nuclear reactors, it's about the same |
| 16:36:42 | evan | :) |
| 16:36:50 | BrianRice-work | reactors are cleaner |
| 16:37:52 | evan | oh, I wonder if it's a scramjet engine that uses oxygen from the atmosphere as fuel |
| 16:37:57 | boyscout | CI: Commit 40e02ed failed. http://github.com/evanphx/rubinius/commit/40e02eda89ff80a45e25fd7aa36d66cab32cbd9d |
| 16:38:14 | evan | wtf |
| 16:38:19 | evan | a weakref_alive? error... |
| 16:38:29 | evan | oh dear |
| 16:38:30 | evan | a lot. |
| 16:38:45 | evan | geez |
| 16:38:52 | evan | it's totally destabalized. |
| 16:40:39 | brixen | hah, that's what I saw |
| 16:40:42 | brixen | interesting |
| 16:41:06 | evan | i'm pulling on elle into my copy and trying. |
| 16:42:09 | brixen | hmm yeah, this is exactly what I saw on ubuntu 9.10 the other day |
| 16:42:16 | brixen | but I just ran it again with no issue |
| 16:42:30 | BrianRice-work | evan: yes, it was a scramjet |
| 16:42:37 | brixen | the segfault here is interesting |
| 16:42:38 | evan | rad. |
| 16:42:57 | evan | BrianRice-work: so it didn't use as much fuel as your bike! |
| 16:43:02 | evan | unless you count the rocket to get up to speed. |
| 16:43:05 | BrianRice-work | heh |
| 16:43:32 | evan | your bike breaths air, the scramjet is just more clever about how it uses the air. :) |
| 16:43:40 | BrianRice-work | agreed about that |
| 16:43:58 | evan | but don't worry. |
| 16:44:20 | evan | air breathing life is still the most clever. |
| 16:49:03 | evan | youdonotexist: I do exist. |
| 16:49:05 | evan | i can prove it. |
| 16:49:53 | youdonotexist | Whoopdie doo. A non-existent being trying to prove he exists. Like I haven't seen that before. |
| 16:50:23 | evan | hah |
| 16:51:01 | BrianRice-work | On the internet, no one knows you're not. |
| 16:52:06 | BrianRice-work | Wow, so I'm really chatty today. Let's just say it's because I'm awaiting news that might make me an involved rubinius user. |
| 16:52:27 | brixen | BrianRice-work: what what what? |
| 16:52:34 | BrianRice-work | brixen: can't say yet |
| 16:52:38 | brixen | hah |
| 16:52:42 | brixen | what a tease |
| 16:52:54 | brixen | thought about a career change to entertainer |
| 16:52:57 | BrianRice-work | well hey the suspense is killing me |
| 16:53:01 | brixen | heh |
| 16:53:14 | evan | I MUST KNOW |
| 16:53:16 | evan | :D |
| 16:53:52 | BrianRice-work | I'll explain soon |
| 16:54:00 | BrianRice-work | or privately |
| 16:54:04 | BrianRice-work | yeah, PM... |
| 16:54:08 | brixen | BrianRice-work: tell them to hurry the hell up |
| 16:57:37 | evan | yeah, weird, i ran it on elle and it's gone... |
| 16:57:49 | evan | hrmzers. |
| 16:57:54 | brixen | so bizarre |
| 16:58:19 | brixen | like something twiddled that MT entry |
| 16:58:26 | brixen | interestingly, it's repeatable! |
| 16:58:30 | evan | it is? |
| 16:58:33 | brixen | just no idea under what circumstances |
| 16:58:36 | brixen | absolutely |
| 16:58:44 | brixen | got the exact same stuff |
| 16:58:56 | evan | oh, it manifests the same way when it appears |
| 16:58:58 | evan | is what you mean |
| 16:59:00 | brixen | yes |
| 16:59:02 | evan | repeatable means YOU can do it on command. |
| 16:59:04 | evan | :) |
| 16:59:21 | brixen | well, for some values of repeatable |
| 16:59:28 | brixen | I usually say reproducible |
| 16:59:28 | evan | hehe |
| 16:59:33 | brixen | it repeats, there |
| 16:59:37 | brixen | :) |
| 17:00:03 | evan | :) |
| 17:00:05 | brixen | it's randomly deterministic |
| 17:00:22 | evan | wow, thats quite a statement. |
| 17:00:25 | brixen | it's nondeterministically nonrandom |
| 17:00:34 | evan | like saying you invented peanut butter marshmallow. |
| 17:00:38 | brixen | heh |
| 17:03:19 | evan | brixen: I wonder if the @threads array in ThreadGroup is getting corrupted in some way... |
| 17:03:41 | brixen | hmm |
| 17:04:04 | evan | I can easy add some code to #prune to deal with this case, so it's a non-issue |
| 17:04:11 | evan | even if it happens. |
| 17:04:29 | evan | the first hickup is because there is a nil in @threads |
| 17:04:30 | brixen | worth a shot |
| 17:04:36 | evan | the rest because there is some unknown Object |
| 17:05:31 | brixen | the fact this has only been observed on ubuntu/deb suggests it could have something to do with underlying thread stuff, yes? |
| 17:05:48 | evan | since it is mildly thread related, yes. |
| 17:08:24 | evan | you know... |
| 17:08:35 | evan | ah! |
| 17:08:35 | evan | yep. |
| 17:08:40 | evan | delete_if is bad news. |
| 17:08:49 | evan | if the block passed to delete_if raises an exception |
| 17:08:58 | evan | the Array is left with random undefined's in it! |
| 17:09:06 | evan | because it puts undefines in as place holders. |
| 17:09:20 | brixen | ahh oops |
| 17:09:30 | evan | so thats the cause of N-1 of those errors |
| 17:09:40 | evan | but patient zero is something else. |
| 17:12:17 | evan | so, it's seems very unlikely that WeakRef.new randomly returned a nil |
| 17:13:12 | evan | which would mean that either @threads was mutated outside the method in some weird way |
| 17:13:23 | evan | or delete_if left it with a nil in there. |
| 17:13:39 | evan | given delete_if's cleanup problem |
| 17:13:42 | evan | that might happen. |
| 17:13:49 | brixen | yeah |
| 17:14:09 | evan | because delete_if also adjusts @total at the end |
| 17:16:19 | evan | i think delete_if also might have a "bug" in the presense of Array mutation done by the block |
| 17:16:26 | evan | but thats in the realm of undefined behavior |
| 17:16:41 | brixen | yeah, we should not allow any such code |
| 17:17:13 | evan | ok, i'll commit this fix for delete_if |
| 17:26:41 | evan | brixen: check out around line 707 in common/array.rb |
| 17:26:50 | evan | the line that is "too_big_for_long = ..." |
| 17:27:23 | evan | similar to your code in shift, we should probably figure out a better way to express this |
| 17:31:30 | brixen | hmm |
| 17:32:40 | brixen | yes, we should |
| 17:33:47 | brixen | my code in shift? |
| 17:35:12 | evan | the stuff you did with Fixnum#<< |
| 17:35:21 | evan | about just not accepting a Bignum |
| 17:36:05 | evan | we have another on of these "block raises" behaviors |
| 17:36:09 | evan | but i'm not going to change it |
| 17:36:24 | evan | namely, Array#sort! appears to leave the array as is in MRI if you raise |
| 17:36:41 | evan | where as we leave it partially sorted. |
| 17:39:12 | brixen | hmm |
| 17:39:59 | brixen | yeah, a general method that says, "you're not a fixnum" |
| 17:40:26 | brixen | rather than the MRI "long" boundary |
| 17:40:57 | brixen | how does MRI leave the array as is in #sort! ? |
| 17:41:01 | brixen | does it not sort in place? |
| 17:41:05 | evan | must not. |
| 17:41:12 | brixen | interesting |
| 17:41:20 | evan | it uses qsort(3) |
| 17:41:36 | evan | which must sort the data into a temp array |
| 17:41:39 | evan | then memcpy it back |
| 17:56:56 | boyscout | Be sure to cleanup any temp modifications during #delete_if - 5e92f15 - Evan Phoenix |
| 17:56:56 | boyscout | Minor style cleanup - 6171613 - Evan Phoenix |
| 17:57:41 | evan | we'll see how that goes. |
| 17:57:49 | evan | should solve at least the N-1 errors. |
| 17:58:50 | brixen | nice |
| 17:59:21 | brixen | man, we have a lot of capi specs |
| 17:59:55 | brixen | I'm just #ifdef HAVE_ wrapping it all |
| 18:00:03 | brixen | no point in doing shit half-assed |
| 18:00:32 | evan | yeah, I thought you meant have to. |
| 18:00:45 | evan | i'll go ahead and write a script to analyze our ruby.h |
| 18:00:52 | evan | and generate a defines.h that has them all |
| 18:01:03 | evan | or you can write it |
| 18:01:06 | evan | but it should be automated. |
| 18:01:14 | brixen | well, hmm |
| 18:01:23 | brixen | I'm going based on what's in the specs |
| 18:01:28 | evan | ok |
| 18:01:41 | brixen | my thought was a single rubyspec.h file that includes all the HAVE_ for the specs |
| 18:01:58 | brixen | and difference files for each impl that explicitly #undef what they do not support |
| 18:02:06 | brixen | since I need this to work with MRI too |
| 18:02:17 | brixen | for symbols that we extend in the c-api |
| 18:02:41 | brixen | so on mri you get rubyspec.h + mri.h |
| 18:02:57 | evan | ah cool |
| 18:03:00 | evan | thats perfect. |
| 18:03:14 | brixen | where mri.h #undef's rb_frozen_p for instance |
| 18:03:50 | brixen | this enables me to write very clear directions for extending the c-api specs |
| 18:04:04 | brixen | and keep things consistent |
| 18:04:14 | brixen | since I'm a consistent bitch :) |
| 18:04:15 | evan | sounds good. |
| 18:04:19 | evan | oh, i know. |
| 18:04:19 | evan | :) |
| 18:04:22 | brixen | heh |
| 18:05:45 | boyscout | CI: rubinius: 6171613 successful: 3463 files, 13870 examples, 41532 expectations, 0 failures, 0 errors |
| 18:06:00 | brixen | atta boyscout |
| 18:08:05 | boyscout | Fix subtle control flow bug - 071f784 - Evan Phoenix |
| 18:16:07 | boyscout | CI: rubinius: 071f784 successful: 3463 files, 13870 examples, 41532 expectations, 0 failures, 0 errors |
| 18:25:49 | cremes | evan: where does ffi fall on your list of priorities post-1.0? |
| 18:26:07 | evan | oh, i'd like to have it fixed for 1.1 |
| 18:26:18 | evan | I need to basically give it a solid week |
| 18:26:19 | cremes | okay, so sometime within the next 3-4 months |
| 18:26:20 | evan | and it will be done |
| 18:26:23 | evan | perhaps next week. |
| 18:26:33 | cremes | sounds good |
| 18:26:44 | cremes | i have some stuff that will put your GIL to the test |
| 19:41:10 | Defiler | ezmobius: where should I go to ask eventmachine questions? It is just crazytown |
| 19:55:08 | ezmobius | /join #eventmachine |
| 19:55:11 | ezmobius | Defiler ^^ |
| 19:55:15 | ezmobius | gotta run |
| 20:14:31 | evan | cremes: oh? |
| 20:14:41 | evan | cremes: what stuff about FFI is missing? |
| 20:14:47 | evan | i can focus on the true usecases first. |
| 20:16:22 | cremes | evan: i'm not certain which functions are missing from rbx yet; haven't gotten past the #ffi_lib call which has changed in the latest jruby & ffi gems |
| 20:16:51 | cremes | i'll look closer now and give you a run down of the features i need |
| 20:17:13 | evan | k |
| 20:23:33 | kronos_vano | evan, What's the difference between proc and Proc.new ? |
| 20:23:43 | evan | read the source. |
| 20:23:44 | kronos_vano | hi everybody |
| 20:23:46 | evan | proc == lambda |
| 20:23:54 | kronos_vano | ah, ok |
| 20:23:55 | evan | Proc.new is the same as a literal block |
| 20:41:18 | cremes | evan: just messing with rbx ffi; trying to use the library.rb spec for guidance on loading libc but getting nowhere |
| 20:41:19 | cremes | http://pastie.org/980749 |
| 20:41:28 | cremes | this is on osx intel |
| 20:41:53 | evan | :/ |
| 20:41:59 | evan | you don't need a library there at all. |
| 20:42:01 | evan | delete that line |
| 20:42:02 | evan | it will work. |
| 20:43:01 | cremes | yes, it did. so that's at least one difference so far; the FFI::Library::LIBC constant doesn't exist... |
| 20:43:25 | evan | if you want to help |
| 20:43:30 | evan | you could send me a patch |
| 20:43:37 | evan | that should take you ~30s to add. |
| 20:43:39 | cremes | yes, of course |
| 20:43:57 | cremes | i do want to help; i'm certainly not expecting you to do it all |
| 20:44:04 | cremes | patches coming this weekend |
| 20:44:09 | cremes | just poking right now |
| 20:44:20 | evan | k |
| 20:45:17 | cremes | just lend me a hand getting to the next step |
| 20:45:59 | cremes | what is the syntax to load a library from /usr/local/lib? i tried "ffi_lib '/usr/local/lib/mylib.dylib' but attach function barfs when i try to map an existing function |
| 20:46:01 | evan | are you on to the next step? |
| 20:46:29 | evan | that should work. |
| 20:48:17 | cremes | nope: http://pastie.org/980749 |
| 20:49:21 | evan | i'll have to look at that then. |
| 20:49:28 | evan | i don't have suggested fix. |
| 20:49:41 | cremes | if i do it without the ffi_lib line, it says it can't find the function in this process (as expected) |
| 20:50:00 | cremes | with the ffi_lib line it says it can't find it in the actual library |
| 20:50:04 | evan | what about just "ffi_lib 'libzmq'" |
| 20:50:12 | cremes | trying... |
| 20:51:10 | cremes | worked; so perhaps it doesn't like it when .dylib is added on; i'll investigate that too |
| 20:51:23 | evan | certainly possible. |
| 20:51:29 | evan | actually, you know |
| 20:51:37 | evan | i'm about to finish up poking with the agent API |
| 20:51:41 | evan | i'll spend some time on FFI today. |
| 20:52:17 | cremes | no worries; if you have other priorities then tackle them |
| 20:52:26 | cremes | i can take a whack at this stuff over the weekend |
| 20:52:26 | evan | i don't actually! |
| 20:52:33 | evan | thats the great part about hitting 1.0 |
| 20:52:37 | cremes | all righty then! |
| 20:52:39 | evan | all these things i had to put off I can do finally! |
| 20:53:38 | evan | cremes: one of the best parts about Rubinius FFI implementation, though, is that it's wired into the JIT |
| 20:53:54 | evan | so if a method that calls out to an FFI attached function is JIT'd |
| 20:54:04 | cremes | i remember that; that's why i'm excited about trying this stuff out! |
| 20:54:06 | evan | the JIT'd method will contain a direct call to the FFI function |
| 20:54:17 | cremes | kick ass |
| 20:54:24 | evan | though, i just realized, i'll bet I need to fix the GIL stuff with that. |
| 20:54:33 | evan | i'll bet the JIT doesn't release the GIL |
| 20:54:37 | evan | thats an easy fi. |
| 20:56:33 | boyscout | Revamp agent API, add a number of variables - d087929 - Evan Phoenix |
| 20:56:39 | boyscout | CI: Commit d087929 failed. http://github.com/evanphx/rubinius/commit/d087929257506fe22c22586dcae36c843e7d9c27 |
| 20:56:49 | evan | that was fast. |
| 20:57:02 | evan | ack, forgot a file. |
| 20:57:04 | evan | thanks CI! |
| 20:57:54 | boyscout | Add missing files - 60ce952 - Evan Phoenix |
| 21:02:49 | boyscout | CI: Commit 60ce952 failed. http://github.com/evanphx/rubinius/commit/60ce95232fcf17618f15e387d3707195c4a002ce |
| 21:03:22 | evan | :/ |
| 21:04:22 | slava | evan: oh, your FFI calls release the GIL now? |
| 21:04:29 | cremes | got my ffi library loading now; it barfs on my use of FFI::Function |
| 21:04:32 | evan | slava: to my surprise, yes. |
| 21:04:34 | cremes | that must not exist yet |
| 21:04:50 | evan | cremes: got a url for that code? |
| 21:04:58 | slava | evan: I recall at some point you moved a few socket operations into the VM because FFI calls didn't release the GIL |
| 21:05:00 | evan | slava: i had it unlock the GIL more than a year ago |
| 21:05:02 | evan | forgot about it. |
| 21:05:07 | cremes | in a sec... |
| 21:05:17 | evan | slava: yeah, those were actually not that the weren't releasing the GIL |
| 21:05:24 | evan | but rather than there was no way to interrupt them. |
| 21:05:29 | slava | ah |
| 21:05:47 | evan | I didn't realize that until last week though. |
| 21:06:14 | cremes | evan: git://github.com/chuckremes/ffi-rzmq.git |
| 21:06:14 | slava | heh |
| 21:06:27 | evan | slava: file and line please |
| 21:06:36 | evan | cremes: also a github http url for the file and line is best. |
| 21:06:38 | cremes | http://github.com/chuckremes/ffi-rzmq/blob/master/lib/ffi-rzmq/wrapper.rb#L48 |
| 21:06:47 | cremes | i was gettin' ya both :) |
| 21:06:48 | evan | wtf is that. |
| 21:06:54 | evan | wtf is FFI::Function :/ |
| 21:07:10 | cremes | it's for a callback |
| 21:07:19 | evan | :( |
| 21:07:34 | evan | ok well, |
| 21:07:38 | evan | you might as well give up now then. |
| 21:07:46 | evan | it's going to take me a while to sort this out. |
| 21:07:54 | cremes | <sigh> |
| 21:08:07 | evan | callback support is hardly trivial. |
| 21:08:11 | cremes | sorry |
| 21:08:18 | evan | i wish it had never been added. |
| 21:09:38 | cremes | i imagine it really complicates things; this code was causing very reproducible mri crashes until i upgraded the ffi gem to master |
| 21:10:00 | evan | thats very unsurprising. |
| 21:10:16 | evan | wait wait |
| 21:10:32 | evan | all that is so you can say free(2) is the message deallocator? |
| 21:11:02 | cremes | yes; the api requires a function pointer for a structure; the library calls your deallocator when it's done with the memory |
| 21:11:14 | cremes | if i had a way to inline a bit of C then i would do that |
| 21:11:42 | cremes | though i can imagine other cases where a callback like that might need to run some ruby or access ruby heap |
| 21:11:58 | boyscout | Add missing includes - dbe6c11 - Evan Phoenix |
| 21:11:59 | slava | evan: you wish callbacks were never added to ruby ffi? |
| 21:12:00 | slava | why? |
| 21:12:06 | slava | callbacks are indispensible |
| 21:12:09 | evan | nah |
| 21:12:11 | evan | i could do without them. |
| 21:12:12 | evan | and have. |
| 21:12:15 | evan | for a very long time. |
| 21:12:32 | slava | a lot of APIs rely on callbacks |
| 21:12:37 | cremes | how do you get along without them when the api requires it? |
| 21:12:40 | slava | yeah |
| 21:12:45 | evan | cremes: i don't use those APIs |
| 21:12:46 | evan | pretty easy. |
| 21:12:51 | slava | that's a cop out |
| 21:12:52 | cremes | :) |
| 21:12:54 | evan | not really |
| 21:13:01 | evan | i haven't needed to use an API that required them. |
| 21:13:06 | slava | what's the technical hurdle to implementing callbacks? |
| 21:13:07 | evan | it's a matter of building what you need. |
| 21:13:34 | evan | slava: i'd prefer to not explain it. |
| 21:13:39 | evan | i have to do the work anyway |
| 21:13:41 | evan | you can see when i'm done. |
| 21:14:37 | slava | cocoa needs callbacks for instance, if you want to be able to subclass objective C classes and provide your own method implementaitons |
| 21:14:46 | cremes | in the short term i could conditionalize that code for rbx and just leave it out; it will leak native memory but i can get further into testing out the FFI implementation |
| 21:14:48 | slava | win32 as well, you supply a function to handle messages |
| 21:15:31 | cremes | slava: was it hard for you to support it in factor? |
| 21:15:39 | cremes | or was it a layup? |
| 21:16:04 | slava | cremes: its one of those things where adding it initially was not too hard, but various changes and features added down the road interacted with callbacks in sometimes non-trivial ways so it requires ongoing thought |
| 21:16:43 | cremes | i understand |
| 21:17:17 | evan | i'm going to add them. |
| 21:17:21 | evan | i've just been avoiding it. |
| 21:17:25 | evan | but i'm a big boy. |
| 21:17:28 | evan | needs to be done. |
| 21:17:33 | slava | because libffi doesn't support them? |
| 21:17:38 | evan | it does. |
| 21:17:41 | slava | oh |
| 21:17:56 | evan | just always had more important things to do. |
| 21:20:04 | slava | evan: are you able to call function pointers? |
| 21:20:14 | evan | at which level? |
| 21:20:26 | slava | suppose a C function called via FFI returns a function pointer |
| 21:20:31 | slava | and you want to invoke the function pointer, via FFI |
| 21:20:32 | slava | from ruby |
| 21:21:34 | cremes | letting two language implementers suss it out |
| 21:22:01 | slava | evan: you might want to add this first if you don't have, it makes callbacks esaier to test :) |
| 21:23:15 | evan | yeah, i'll be doing that at the some time. |
| 21:23:19 | evan | same time, rather. |
| 21:23:59 | slava | it comes up if you want to interface with COM libraries |
| 21:24:06 | slava | DirectX, etc |
| 21:24:09 | cremes | perhaps it's time for a pow-wow with wayne meissner (ffi gem guy) to lock this all down |
| 21:24:18 | evan | cremes: i have many times. |
| 21:25:00 | cremes | ok; i guess the current api reflects a few disagreements then ;) |
| 21:25:25 | cremes | i'll get out of the way and let folks who know what they are talking about tackle it |
| 21:25:39 | evan | cremes: wayne evolved the API without me. |
| 21:25:40 | evan | is the issue. |
| 21:25:42 | cremes | my opinions don't matter much other than to say i'd like callback support |
| 21:25:45 | cremes | right |
| 21:26:23 | BrianRice-work | slate's memory manager implements pinning which we have experimentally used for callbacks but haven't made it fully viable yet. we mostly use it for C-stack-related troubles |
| 21:26:57 | BrianRice-work | and of course, anything pinned is in tenured space |
| 21:27:05 | slava | how does pinning help with callbacks? |
| 21:27:09 | boyscout | CI: rubinius: dbe6c11 successful: 3463 files, 13870 examples, 41532 expectations, 0 failures, 0 errors |
| 21:27:51 | BrianRice-work | slava: so that the memory manager doesn't move something around that the vm has registered externally for asynchronous invocation |
| 21:28:14 | slava | oh, like moving compiled code? |
| 21:29:00 | BrianRice-work | yeah, or stuff that compiled code points to |
| 21:29:39 | slava | I put callbacks in a separate heap where they don't move or get deallocated |
| 21:29:57 | slava | since there's no way to tell if a callback is referenced from C code or not |
| 21:30:10 | BrianRice-work | yeah I sat through a VisualWorks presentation and that's what they do, but their memory manager is really sophisticated |
| 21:30:37 | BrianRice-work | so, maybe that'll get done, but on a timescale I can't commit to. |
| 21:30:55 | slava | if you use LLVM you can generate C functions and C function calls so you get FFI for free pretty much |
| 21:31:53 | BrianRice-work | yeah we need to get that done |
| 21:47:59 | evan | slava: yep |
| 21:48:19 | slava | is this like King of the Hill? yep, yep. yep... yep; yep. |
| 21:48:24 | evan | slava: the bigger thing is not just callbacks (though i've been a whiny bitch about them) it's having to sort through all the incompat FFI changes that were made in ruby-ffi |
| 21:48:59 | evan | i'll have to just put on some NIN and turn it up loud. |
| 21:53:06 | evan | ruby-ffi was wayne's first ruby c extension (and the first he'd written c) |
| 21:53:19 | evan | and, sadly, it shows. |
| 21:53:37 | evan | he did a great job, it's just c written as java. |
| 21:53:49 | slava | are you reusing his code or just the API? |
| 21:53:55 | evan | API. |
| 21:54:14 | evan | I just need to nut up and do it. |
| 21:54:16 | evan | which i'm doing now. |
| 23:32:59 | evan | cremes: i've got a few ideas that should clean up the FFI impl |
| 23:33:03 | evan | i'm working on them now. |
| 23:44:08 | cremes | evan: you are a rock star |
| 23:44:28 | cremes | btw, i stripped out the incompatible code (FFI::Function) and got a little bit further |
| 23:44:35 | evan | ok |
| 23:44:38 | cremes | the Struct stuff is slightly incompatible now |
| 23:44:44 | evan | oh? |
| 23:44:49 | evan | where at? |
| 23:45:17 | cremes | it doesn't like arrays of primitives |
| 23:45:25 | evan | could you show me in the code? |
| 23:45:48 | cremes | http://github.com/chuckremes/ffi-rzmq/blob/master/lib/ffi-rzmq/wrapper.rb#L61 |
| 23:46:02 | cremes | i'm using "screen sharing" to get to my work box so it's a bit pokey |
| 23:46:18 | evan | ok |
| 23:46:42 | evan | I take it thats a uint8_t thing[30]; |
| 23:46:44 | evan | in the C struct |
| 23:46:50 | cremes | yessir |
| 23:47:05 | cremes | i took a look at this ffi code a few weeks back; i believe it is all ruby |
| 23:47:13 | evan | yeah, i just never added that. |
| 23:47:41 | evan | if you wanna try to hack support in, go for it. |
| 23:47:59 | cremes | okay |
| 23:48:07 | cremes | i'll let you tackle the big stuff like callbacks |
| 23:48:13 | evan | k |
| 23:48:25 | evan | i'm working on it so that hopefully I can do more in Ruby |
| 23:48:35 | evan | i'll need to add callback support in the VM |
| 23:48:39 | evan | but hopefully that will be it. |
| 23:49:05 | evan | cremes: I have to ask |
| 23:49:05 | cremes | great |
| 23:49:11 | cremes | yes? |
| 23:49:14 | evan | why do you use the included hook to do a layout |
| 23:49:21 | evan | when you only include that thing one place |
| 23:49:44 | cremes | it's a "pattern" suggested on the ffi wiki to do struct casting |
| 23:49:57 | evan | but you only use it once place, yes? |
| 23:50:00 | evan | one place, rather. |
| 23:50:09 | cremes | so far, yes |
| 23:50:16 | evan | *eyeroll* |
| 23:50:24 | cremes | yeah, YAGNI |
| 23:50:38 | cremes | i *did* use it before so i'm glad i know the technique |
| 23:50:50 | cremes | feel free to send me a patch :-P |
| 23:51:03 | evan | at this stage in my ruby career |
| 23:51:08 | evan | i'm so opposed to using the included hook for stuff |
| 23:51:20 | evan | it's extremely over abused. |
| 23:51:31 | cremes | that's because you see how the sausage is made, mr runtime |
| 23:51:42 | evan | so true. |
| 23:51:47 | cremes | ignorance is bliss |
| 23:51:49 | evan | plus |
| 23:51:55 | evan | I usually have to debug that code |
| 23:52:04 | evan | becuase it might not run properly on rubinius |
| 23:52:16 | evan | so i have to figure out what unecessary magic the developer used |
| 23:52:55 | evan | i think i'll change that in the wiki. |
| 23:53:09 | cremes | i'm going through my library now and building out specs |
| 23:53:20 | cremes | i'm sure i'll simplify that when i get to it; i have no clue how to test it |
| 23:56:38 | toulmean | brixen: let's not compare our days. Ever. You win singlehanded. You win with two fingers even. |
| 23:56:54 | cremes | one more episode of spartacus blood & sand and i'll do some ffi hacking |
| 23:57:01 | evan | cremes: :) |
| 23:57:02 | evan | toulmean: hehe |
| 23:59:56 | brixen | toulmean: so, I am a winner? :) |