Da
Show enters and exits. Hide enters and exits.
| 00:03:44 | brixen | cool |
| 00:04:49 | brixen | hmm |
| 00:05:13 | brixen | that was weird |
| 00:05:30 | brixen | not sure what cmd+r is supposed to do in irssi |
| 00:05:55 | brixen | so, flash player using llvm jit http://lightspark.sourceforge.net/ |
| 00:07:09 | evan | yeah |
| 00:07:15 | evan | i was looking to try and find where they use LLVM |
| 00:07:17 | evan | haven't found it yet. |
| 00:08:59 | brixen | heh |
| 00:09:51 | brixen | ok, early dinner, online later, then tango! |
| 00:10:10 | evan | see ya! |
| 00:10:17 | brixen | later! |
| 00:17:30 | mpanetta | Hay guys :) |
| 00:17:39 | evan | hello |
| 00:19:36 | mpanetta | I keep getting this when trying to run the tests: |
| 00:19:38 | mpanetta | 1) |
| 00:19:38 | mpanetta | UDPSocket.bind receives a hostname and a port FAILED |
| 00:19:39 | mpanetta | Expected "0.0.0.0" to equal "127.0.0.1" |
| 00:19:46 | evan | ah yeah |
| 00:19:50 | evan | i need to look at that. |
| 00:20:08 | evan | that seems to be happened on linux sometimes. |
| 00:20:15 | mpanetta | I just commented out the one compare to make it pass, I assume its not really an issue |
| 00:20:26 | evan | likely not, no. |
| 00:21:26 | mpanetta | Ok cool, thanks. |
| 00:21:30 | boyscout | Minor syntax cleanup - 492b582 - Evan Phoenix |
| 00:21:30 | boyscout | Add defered breakpoints to the debugger - 8532ebe - Evan Phoenix |
| 00:22:57 | mpanetta | Has anyone done any size comparisons on the core? I am wondering if rubinius would be any more portable to small embedded systems then say strait ruby... |
| 00:23:06 | evan | no |
| 00:23:08 | evan | very likely not. |
| 00:23:22 | evan | we have a lot more runtime data/memory used than MRI |
| 00:23:27 | mpanetta | Kind of like how they embed Python in to some phone processors. I would rather use Ruby ;) |
| 00:23:31 | mpanetta | Oh really? Ok |
| 00:23:34 | evan | because we implement so many methods in ruby |
| 00:23:45 | evan | and thusly those methods are in the GC heap |
| 00:23:54 | evan | where as MRI implements it's core in C |
| 00:24:02 | evan | and the methods are in shared code pages |
| 00:24:17 | mpanetta | Hmm, si its because the runtime libs are written in ruby instead of C? |
| 00:24:21 | mpanetta | er so |
| 00:24:26 | evan | thats a big part, yeah. |
| 00:24:30 | mpanetta | Ahh ok |
| 00:24:32 | evan | we have a lot richer data than MRI |
| 00:24:40 | evan | which comes with a higher default memory footprint. |
| 00:24:48 | boyscout | CI: rubinius: 8532ebe successful: bin/rbx [0x8180f51] |
| 00:24:56 | evan | :/ |
| 00:25:08 | mpanetta | I just downloaded it for the first time, so I am still figuring out what it can do. :) |
| 00:25:18 | mpanetta | What do you mean by richer data? |
| 00:25:56 | evan | I mean that a lot more of what happens in the system is implemented in terms of Ruby objects |
| 00:26:07 | evan | say, for instance, a method. |
| 00:26:22 | evan | in MRI, you there is no accessible way to see a method itself. |
| 00:26:27 | evan | it's implementation, etc. |
| 00:26:40 | evan | ParseTree extracts it in a way. |
| 00:26:47 | evan | but in Rubinius, they're CompiledMethod objects |
| 00:26:53 | evan | that you can call methods on and such. |
| 00:27:20 | mpanetta | Ahh! So it has a deeper ability to self inspect? |
| 00:27:29 | evan | much, yes. |
| 00:27:36 | evan | for instance, eval is implemented entirely in ruby. |
| 00:27:50 | evan | well, 95% in ruby. |
| 00:28:00 | evan | the VM runs the actual code. |
| 00:28:53 | mpanetta | oh wow |
| 00:29:57 | mpanetta | Sounds like it makes it easier to instrument your code that way. |
| 00:30:00 | boyscout | Put hook.rbc in the right load place - 32151bb - Evan Phoenix |
| 00:30:05 | evan | mpanetta: it can, yeah. |
| 00:32:40 | mpanetta | Hmm, I should make an RPM of this. |
| 00:32:54 | evan | we're going to be releasing 1.0.1 next week |
| 00:33:03 | evan | if you want to package an official release. |
| 00:34:03 | mpanetta | Ok |
| 00:37:59 | boyscout | CI: rubinius: 32151bb successful: 3462 files, 13795 examples, 41453 expectations, 0 failures, 0 errors |
| 01:37:40 | boyscout | Introduce -Xprofile to be used instead of -P - b69787a - Evan Phoenix |
| 01:46:43 | boyscout | CI: rubinius: b69787a successful: 3462 files, 13795 examples, 41453 expectations, 0 failures, 0 errors |
| 01:53:00 | brixen | that was awesome |
| 01:53:13 | brixen | just ran into a guy I used to hang out with on weekends and hack on rbx |
| 01:53:17 | brixen | in like feb 2007 |
| 01:53:30 | brixen | he hadn't heard we released 1.0 |
| 01:53:51 | brixen | they were on their way to a scala talk :P |
| 01:57:40 | evan | brixen: hehehe |
| 01:57:52 | evan | brixen: so, defered breakpoints are in. |
| 01:58:03 | evan | you can do -Xdebug and it will start the debugger in loader |
| 01:58:13 | evan | defered breakpoints are checked after every method is added |
| 01:58:17 | evan | and after every script is run |
| 01:58:19 | brixen | yeah, just looking at it |
| 01:58:22 | brixen | looks sweet! |
| 01:58:58 | brixen | simplified code loading is paying dividends :) |
| 01:59:11 | brixen | what a joy to work with good code |
| 01:59:33 | evan | yeah. |
| 01:59:58 | evan | Rubinius::Hook is a trivial observer style pattern |
| 02:00:09 | evan | you create one and expose it |
| 02:00:10 | brixen | the guy that was with the guy I knew said, "oh yeah, I installed rbx with rvm and ran our specs, everything passed, so cool" |
| 02:00:12 | evan | for people to add and trigger |
| 02:00:40 | brixen | yeah, Hook is cool |
| 02:07:37 | evan | wowzers. |
| 02:07:38 | evan | in MRI |
| 02:07:46 | evan | Readline.readline stops everything COLD. |
| 02:08:06 | evan | 1.9 too |
| 02:08:07 | evan | geez |
| 02:08:08 | evan | ! |
| 02:09:44 | evan | tehehehe |
| 02:09:54 | evan | i found a use for rb_thread_blocking_region |
| 02:09:55 | evan | :D |
| 02:09:59 | brixen | heh |
| 02:10:06 | evan | works great too. |
| 02:10:10 | brixen | nice |
| 02:11:42 | evan | OH GOD |
| 02:11:44 | evan | LEBRON |
| 02:11:46 | evan | HELP ME. |
| 02:11:56 | evan | in irb: |
| 02:11:59 | evan | unless (class<<@io;self;end).include?(HistorySavingAbility) |
| 02:13:17 | evan | honestly |
| 02:13:23 | evan | i can't believe irb even works. |
| 02:13:53 | brixen | wow |
| 02:15:18 | brixen | here's a good visual for early Ruby: folks in star trek uniforms wandering in an odd-looking foreign planet, phasering stuff, and poking it |
| 02:15:26 | brixen | and, of course, writing codez |
| 02:16:08 | evan | and we're somewhere in voyager times now? |
| 02:16:28 | evan | lib/ext/save-history.rb |
| 02:16:35 | evan | uses a FINALIZER on STDOUT to save the history |
| 02:16:47 | evan | guess what we don't run on shutdown. |
| 02:16:49 | evan | :/ |
| 02:17:08 | brixen | well, you don't want to save history until the last possible second |
| 02:17:16 | brixen | right before the lights go out |
| 02:17:25 | brixen | "last one out, turn off the lights!" |
| 02:17:28 | evan | hah |
| 02:17:31 | brixen | "sure thing, billy bob" |
| 02:17:33 | evan | when is tango? |
| 02:17:36 | brixen | heh |
| 02:17:38 | brixen | 15 min |
| 02:18:18 | evan | why not use at_exit? |
| 02:18:23 | evan | was this code written pre-at_exit? |
| 02:18:29 | brixen | hmm, could be |
| 02:18:32 | evan | redictifies. |
| 02:19:22 | evan | who whould have thought! |
| 02:19:27 | evan | that works better than a random finalizer! |
| 02:19:28 | brixen | but when you think about it, someone could write during an at_exit handler, might as well wait till the end :) |
| 02:19:31 | evan | *eyeroll* |
| 02:19:34 | brixen | hehe |
| 02:40:39 | boyscout | Make readline multithread aware and minor cleanup - 4574376 - Evan Phoenix |
| 02:40:40 | boyscout | Check for async events when returning from a native method - 660dbbf - Evan Phoenix |
| 02:40:40 | boyscout | Cleanup and fix irb's save history feature - 649f691 - Evan Phoenix |
| 02:48:22 | toulmean | evan: so we were discussing a few days ago about rjb |
| 02:48:33 | toulmean | and the problem to compile it as it sounds quite old |
| 02:48:42 | boyscout | CI: rubinius: 649f691 successful: 3462 files, 13795 examples, 41453 expectations, 0 failures, 0 errors |
| 02:48:50 | toulmean | in particular you told me rubinius did not support this construct: RHASH_TBL |
| 02:49:21 | toulmean | it sounds like it is the last problem before we can compile the code. |
| 02:49:29 | toulmean | So it's worth banging against it |
| 02:49:37 | toulmean | I'll google and will look for it around. |
| 02:50:29 | toulmean | evan: would this be a possibility: http://www.mail-archive.com/libxml-devel@rubyforge.org/msg01196.html |
| 02:56:27 | toulmean | ok that doesn't work. Good to keep I guess, in case. |
| 02:58:39 | toulmean | ok got this now : http://jira.mongodb.org/browse/RUBY-109 |
| 02:58:42 | toulmean | evan: ^^ |
| 03:35:29 | toulmean | evan: got the code to compile but it fails when I load the rb with this error: |
| 03:35:44 | toulmean | SystemCallError: dlopen(/usr/local/rubinius/1.0.0/site/x86_64-darwin10.3.0/rjbcore.bundle, 10): Symbol not found: _OBJ_FREEZE |
| 03:35:51 | toulmean | I am committing my changes |
| 03:54:25 | toulmean | cremes: see my discussion above too ^^ |
| 03:54:34 | toulmean | cremes: and the problem I hit now: SystemCallError: dlopen(/usr/local/rubinius/1.0.0/site/x86_64-darwin10.3.0/rjbcore.bundle, 10): Symbol not found: _OBJ_FREEZE |
| 04:07:46 | toulmean | cremes: ^^ if you don't have an insight, that's fine. |
| 04:08:01 | cremes | toulmean: still looking |
| 04:08:12 | toulmean | ah ok thx |
| 04:11:06 | evan | toulmean: that is supported now |
| 04:11:16 | evan | you might have to try on git HEAD though |
| 04:11:26 | toulmean | evan: oh fun stuff ok |
| 04:12:24 | toulmean | evan: will try. |
| 04:12:37 | evan | ok |
| 04:13:42 | cremes | toulmean: i clearly see the code in vm/capi/object.cpp but i'm on the latest master so... |
| 04:13:51 | cremes | follow evan's advice; he da man |
| 04:13:57 | evan | :) |
| 04:13:58 | toulmean | cremes: thx |
| 04:14:05 | toulmean | yeah |
| 04:14:10 | toulmean | oops dinner served |
| 04:14:26 | cremes | do some hacking for dessert! |
| 04:14:41 | cremes | and now, to bed |
| 05:49:32 | toulmean | evan: building trunk |
| 05:52:48 | brixen | sweet |
| 05:52:57 | brixen | toulmean: where do I get the source for rjb? |
| 05:53:15 | toulmean | brixen: github, atoulme, rjb |
| 05:53:45 | toulmean | brixen: http://github.com/atoulme/rjb/ |
| 05:53:59 | toulmean | sorry mac a bit hosed by rake install |
| 05:54:14 | toulmean | brixen: a few more minutes and I will try with rbx |
| 05:57:05 | toulmean | is wondering how long it takes to compile this thing ? |
| 05:57:23 | brixen | wonders if he should try... |
| 05:57:53 | toulmean | I for sure will tell you how it goes. |
| 05:58:40 | brixen | funny, I searched for it on gh and I was like, who's this atoulme? must be some random fork |
| 05:58:44 | brixen | heh |
| 06:02:06 | toulmean | SystemCallError: dlopen(/Users/antoine/w/git/rubinius/lib/site/x86_64-darwin10.3.0/rjbcore.bundle, 10): Symbol not found: _rb_ary_delete |
| 06:02:19 | toulmean | brixen: evan: ^^ got this now |
| 06:02:51 | brixen | toulmean: I read readme.txt but it's not clear how to build this |
| 06:03:02 | toulmean | Brixen: rake install |
| 06:03:07 | toulmean | first ./configure |
| 06:03:16 | toulmean | actually it didn't "install" |
| 06:03:20 | brixen | http://gist.github.com/408529 |
| 06:03:20 | toulmean | but it created a bin dir |
| 06:03:24 | toulmean | and I could use it |
| 06:03:33 | toulmean | oh |
| 06:03:36 | toulmean | JAVA_HOME not set |
| 06:03:56 | brixen | I'm on os x 10.5 |
| 06:03:58 | toulmean | gets me _every_ _time_ |
| 06:04:08 | toulmean | you need to export JAVA_HOME |
| 06:04:27 | brixen | ok, readme said it assumed it was where it's at :/ |
| 06:04:36 | toulmean | ya |
| 06:04:55 | toulmean | I don't know. This code is weird |
| 06:05:18 | brixen | ok, much better, config finished |
| 06:06:32 | toulmean | brixen: then load in irb |
| 06:06:41 | toulmean | brixen: require "rubygems" |
| 06:06:44 | toulmean | require "rjb" |
| 06:06:50 | toulmean | and you will reproduce my problem |
| 06:09:17 | brixen | do I need to install? |
| 06:09:35 | toulmean | Brixen: setup.rb installed for you |
| 06:09:46 | toulmean | you should be all set. |
| 06:10:28 | brixen | cool, got it |
| 06:10:41 | toulmean | brixen: reproducing ? |
| 06:10:45 | toulmean | ok |
| 06:10:53 | toulmean | not sure. Sounds like a standard function. |
| 06:10:58 | brixen | yeah, I just need to add this capi function |
| 06:11:02 | brixen | and some specs for it |
| 06:11:08 | brixen | I'll work on this a bit... |
| 06:11:23 | toulmean | not sure if there's more to it |
| 06:11:28 | toulmean | cool, thx |
| 06:11:48 | toulmean | I need to blog about all this, it's pretty awesome |
| 06:12:14 | brixen | heh, well we should get it running before you do :) |
| 06:13:59 | toulmean | brixen: interesting. My C++ skills are so dusty, I'll try to grab your commit to understand it |
| 06:14:08 | brixen | ok |
| 06:14:45 | toulmean | brixen: do you work for EY ? |
| 06:14:56 | brixen | yes |
| 06:15:33 | toulmean | cool |
| 06:24:12 | toulmean | brixen: so eventually... would it be possible to compile the code of Buildr to make it faster to read for the interpreter ? |
| 06:24:23 | toulmean | brixen: I mean, rubinius should be fast with this ? |
| 06:24:41 | toulmean | Brixen: right now, we rely mainly on MRI |
| 06:24:42 | brixen | um, by compile you mean? |
| 06:24:50 | toulmean | and we default to JRuby |
| 06:25:26 | toulmean | brixen: well, less overhead. The ruby code is interpreted. I tried to understand for example if there were ways to have the ruby code compiled in a jar for jruby |
| 06:25:48 | brixen | I'm actually looking at Buildr right now, I didn't know what it was :) |
| 06:25:55 | brixen | you should just try some benchmarks |
| 06:25:55 | toulmean | :) |
| 06:26:05 | brixen | we generally execute Ruby code much faster than MRI |
| 06:26:05 | toulmean | brixen: yes. That's the next step. |
| 06:26:13 | toulmean | cool |
| 06:26:20 | brixen | but our core library (Array, Hash, String) is all in ruby |
| 06:26:29 | brixen | this means it *may* be slower |
| 06:26:49 | toulmean | as soon as we get rjb running, we can start playing. |
| 06:26:51 | brixen | but, for instance, our Ruby hash with the JIT gets nearly as fast as MRI C code for some Hash ops |
| 06:27:02 | brixen | and the JIT is only going to get better |
| 06:27:36 | brixen | we can inline Ruby core methods directly into your app code |
| 06:28:09 | toulmean | ok, that's awesome. |
| 06:28:15 | brixen | yes, it is :) |
| 06:28:15 | toulmean | simply awesome. |
| 06:28:25 | brixen | and it is only going to get better, honestly |
| 06:28:52 | brixen | whereas MRI is completely hobbled by its choice of technology, our ceiling is very high |
| 06:29:07 | brixen | not to brag or anything :) |
| 06:29:13 | brixen | it's all evan's fault really |
| 06:29:49 | toulmean | blame evan, ok |
| 06:30:01 | brixen | heh |
| 06:30:10 | brixen | well, he gets credit too, so I think it evens out |
| 06:30:12 | toulmean | so rubinius has vaulted ceilings. Nice. |
| 06:30:18 | brixen | indeed |
| 06:30:23 | brixen | nice analogy |
| 06:30:24 | toulmean | ok |
| 06:30:46 | toulmean | so why the trouble of doing it ? To let people extend the core in ruby ? Or for perf ? |
| 06:30:59 | toulmean | what was the reason why ? |
| 06:31:23 | toulmean | is rubinius used in prod with rails somewhere ? |
| 06:31:25 | brixen | trouble of doing what? |
| 06:32:07 | brixen | I have heard there's some rails sites running on rbx, but not serious production sites yet |
| 06:32:18 | brixen | rubinius started as a hobby to write a vm for evan |
| 06:32:26 | brixen | then he opened it up |
| 06:32:43 | brixen | he's made some excellent architecture choices |
| 06:32:50 | toulmean | trouble of doing rubinius I mean |
| 06:32:50 | toulmean | ok |
| 06:32:52 | brixen | and Ruby can just be a hell of a lot better |
| 06:33:05 | toulmean | even 1.9 is hobbled still ? |
| 06:33:13 | brixen | I started working on it because I love writing ruby code and I couldn't get into MRI |
| 06:33:21 | brixen | yes, 1.9 is terribly hobbled |
| 06:33:40 | brixen | 1.9 has tons of C code |
| 06:33:42 | brixen | for one |
| 06:33:54 | brixen | you cannot simply inline that into app code |
| 06:34:13 | brixen | our core being written in Ruby means that it's all just bytecode |
| 06:34:24 | brixen | the jit processes bytecode into machine code |
| 06:34:32 | brixen | along the way, it can inline methods |
| 06:34:38 | brixen | right into your app code |
| 06:34:48 | toulmean | ok |
| 06:34:49 | brixen | inlining means that llvm has much more code to optimize |
| 06:34:55 | brixen | that's where the win is |
| 06:35:08 | brixen | also, rbx has an exact, generational garbage collector |
| 06:35:22 | toulmean | I see. I thought ruby was a mere interpreter, but you guys got a full VM to do the job |
| 06:35:26 | brixen | by exact, that means it can see every object reference precisely |
| 06:35:33 | toulmean | ok. |
| 06:35:40 | brixen | mri 1.8 is an ast walking interpreter |
| 06:35:45 | brixen | 1.9 is a bytecode vm |
| 06:35:51 | brixen | but that is just the start of the story |
| 06:35:57 | toulmean | ok thx for explaining that |
| 06:36:03 | brixen | n/p :) |
| 06:36:03 | toulmean | please go on :D |
| 06:36:07 | brixen | it's really fun stuff |
| 06:36:21 | brixen | well, you can see that 1.9 is already quite a bit faster than 1.8 |
| 06:36:31 | brixen | that's all to do with the switch to a bytecode vm |
| 06:36:37 | brixen | but, what can the vm do? |
| 06:36:41 | brixen | just execute your ruby code |
| 06:36:51 | brixen | all the C code underneath... the vm never sees that |
| 06:37:00 | brixen | for rbx, it does |
| 06:37:10 | brixen | which means that in pure interpreter mode, it runs slower |
| 06:37:18 | brixen | but let the jit operate on that, and voila |
| 06:37:20 | brixen | fast :) |
| 06:37:24 | toulmean | hmm |
| 06:37:26 | toulmean | nice |
| 06:37:33 | brixen | also, our gc is tons better |
| 06:37:40 | brixen | and we're not done with it yet |
| 06:38:48 | toulmean | impressive. |
| 06:38:58 | toulmean | brixen: so my trick question would be the installation story |
| 06:39:21 | toulmean | I have worked with buildr for a while and in my experience all the native code was always the most troubled place |
| 06:39:25 | toulmean | especially RJB |
| 06:39:48 | toulmean | it sucks big time. I hope the changes I made to make it compile with rubinius could help with stability. |
| 06:39:51 | toulmean | It's just a shame |
| 06:40:11 | toulmean | it compiles against the JVM C headers, and against the MRI headers |
| 06:40:31 | brixen | native code is always problematic, sure |
| 06:40:32 | toulmean | and sometimes it gives seg faults |
| 06:40:39 | brixen | platform deps suck, etc |
| 06:40:42 | toulmean | we never were able to find out why or how or when |
| 06:40:48 | brixen | we have better segfault protection |
| 06:41:00 | brixen | first off, our VM is more "type-safe" |
| 06:41:15 | brixen | in that, our primitive ops don't just operate on bit patterns in memory |
| 06:41:26 | brixen | we use types in C++ so that we actually get type errors |
| 06:41:34 | brixen | before you start mucking with some bits |
| 06:41:34 | toulmean | I got builds that stopped running, builds that worked, except when I changed the VM, or builds that always work but sometimes the GC of the JVM crashes |
| 06:41:48 | toulmean | ok. |
| 06:41:52 | brixen | rbx might help flush that out |
| 06:42:01 | toulmean | brixen: what's your coverage of OSes ? |
| 06:42:11 | toulmean | meaning, do you work on Windows 7 64 bits... |
| 06:42:13 | brixen | pretty much *nix atm |
| 06:42:21 | toulmean | and do you need help with supporting those archs ? |
| 06:42:32 | brixen | we have a couple contribs working on Windows, but it's very sporadic |
| 06:42:39 | toulmean | frankly Buildr 1.4 would be out a month ago wouldn't it be for Windows. |
| 06:42:45 | brixen | we should be doing more with that now that 1.0 is out |
| 06:42:51 | toulmean | ok |
| 06:43:10 | toulmean | I can setup a CI build for buildr on xp and one on win7 - maybe. |
| 06:43:18 | toulmean | we'll see. |
| 06:43:51 | brixen | we are making some changes that will make building on Windows easier |
| 06:43:58 | brixen | primarily the build system |
| 06:44:02 | toulmean | oh |
| 06:44:07 | toulmean | rake right ? |
| 06:44:12 | brixen | it uses rake now, yes |
| 06:44:21 | toulmean | ok. What would you change there ? gcc ? |
| 06:44:25 | brixen | but it will be a pure Ruby (no rake) one soon |
| 06:44:37 | brixen | the platform stuff will be specialized |
| 06:44:42 | toulmean | well I like rake, you should keep it :) |
| 06:44:44 | toulmean | ok |
| 06:44:51 | brixen | on Windows it will use whatever tool we need to use |
| 06:44:52 | toulmean | buildr is based on rake |
| 06:44:55 | brixen | rake sucks :) |
| 06:45:01 | brixen | I've battled with rake for years |
| 06:45:04 | brixen | no more |
| 06:45:05 | toulmean | :) |
| 06:45:35 | toulmean | I can tell you, rake and buildr are so much mixed, it's hard to tell what's happening most of the time |
| 06:45:45 | toulmean | Assaf Arkin started buildr as a DSL on top of Rake |
| 06:45:50 | toulmean | I think he did a good job. |
| 06:45:57 | toulmean | I need to try drake btw |
| 06:46:26 | toulmean | so you didn't like the file tasks and ie ? |
| 06:46:50 | brixen | I do not like how rake resolves dependencies |
| 06:46:57 | brixen | rake clean build is impossible |
| 06:47:00 | toulmean | the good thing with buildr is that our code is quite complex but Assaf had set a good practice of doing specs all over the place. |
| 06:47:23 | brixen | because the deps are resolved, then clean runs and deletes them, then build fails because it does not know to build the stuff it needs |
| 06:47:48 | toulmean | brixen: oh ? ok, we don't have that in buildr |
| 06:47:54 | brixen | rules and file/dir tasks are great, but they are not tools to organize code |
| 06:47:55 | toulmean | you can do buildr clean package |
| 06:48:12 | brixen | all rakefiles I've ever seen are horrid |
| 06:48:16 | toulmean | they are not. They are pretty important to check on timestamps, build optionally, etc |
| 06:48:21 | brixen | that is why things like Tap, Thor, and Boson are made |
| 06:48:26 | brixen | and they all suck as build tools |
| 06:48:31 | toulmean | brixen: tarpit ? |
| 06:48:44 | brixen | idk, I'll look at that |
| 06:49:02 | brixen | also, file deps should be digest based, not mtime based |
| 06:49:15 | brixen | finally, rake builds one dependency tree |
| 06:49:34 | brixen | that makes it fundamentally impossible to use effectively in a project as complex as rbx |
| 06:49:50 | toulmean | brixen: http://github.com/intalio/cloud-orbit/blob/master/Buildfile is our latest Buildfile for a huge project |
| 06:49:52 | brixen | right now, we have to shell out to build all the c exts |
| 06:50:08 | toulmean | hmm |
| 06:50:24 | toulmean | brixen: I was seeing someone on rake-devel who did a complex C++ build with it |
| 06:50:33 | toulmean | but no hope to open source the framework he used. |
| 06:51:06 | toulmean | brixen: ok for digest based - we have problems on windows with mtime |
| 06:52:11 | toulmean | anyways. What's the roadmap going forward ? Meaning, if we get buildr on top of rubinius running, will we get an official release of rubinius quickly ? |
| 06:52:17 | toulmean | if we don't that's fine. |
| 06:52:28 | toulmean | but some people around here love MRI so much... |
| 06:52:42 | brixen | we plan on a 1.0.1 release early next week |
| 06:52:49 | brixen | also, our master branch is very sane |
| 06:52:55 | brixen | you could run from it |
| 06:53:01 | toulmean | nice |
| 06:53:05 | toulmean | yes I did that :) |
| 06:53:12 | brixen | but we should be doing feature releases every 3-4 months |
| 06:53:20 | toulmean | I mean, I did try running rjb with it. |
| 06:53:20 | toulmean | ok |
| 06:53:28 | brixen | our dev process is very different than MRI's |
| 06:54:07 | brixen | also, we kinda wrote the book on rubyspec |
| 06:54:17 | brixen | and we'll be improving our assurance testing |
| 06:54:26 | brixen | now that we will have production users |
| 06:54:33 | toulmean | rubyspec |
| 06:54:50 | toulmean | -> http://rubyspec.org/ ? |
| 06:54:54 | brixen | yes |
| 06:55:01 | brixen | that started with rbx |
| 06:55:06 | toulmean | ok |
| 06:55:30 | toulmean | brixen. Ok, would it help if I fool proof your stuff on a xp machine somewhere ? |
| 06:55:53 | toulmean | I mean, if I get rubinius to work on Windows, I can drop MRI, and sleep better at night. |
| 06:56:07 | brixen | well, Windows support is still a bit out |
| 06:56:16 | brixen | but we'll be working on it in the next couple months |
| 06:56:20 | toulmean | brixen: at least you would need what fails. |
| 06:56:26 | toulmean | know |
| 06:56:31 | brixen | folks have it building |
| 06:56:40 | toulmean | great |
| 06:56:45 | brixen | if you want to help with windows, talk to luislavena |
| 06:56:54 | brixen | he's the one-click maintainer for mri |
| 06:57:04 | brixen | and he's helping get rbx to cross-compile |
| 06:57:15 | brixen | but we have to get it to actually run :) |
| 06:57:17 | toulmean | brixen: how about the windows installer ? |
| 06:57:25 | brixen | for rbx? |
| 06:57:32 | toulmean | I see you have an installer for mac |
| 06:57:36 | toulmean | nothing for windows ? |
| 06:57:39 | toulmean | yep |
| 06:58:07 | toulmean | ok I'll open bugs to help with that - nsis could help you out. Low priority at best. |
| 06:58:16 | toulmean | will talk with Luis. |
| 06:58:36 | toulmean | brixen: for the CI build, rake ci is the way to go right ? |
| 06:58:42 | brixen | yeah, no installer for windows yet |
| 06:58:53 | brixen | just rake will run the specs |
| 06:58:57 | brixen | and the vm tests |
| 06:59:07 | brixen | bin/mspec ci to run the specs |
| 06:59:17 | toulmean | If I set up a hudson instance that monitors evan's master, runs a CI job every night and sends an email, would that help ? |
| 06:59:36 | brixen | help with? |
| 06:59:45 | brixen | we have a CI bot reporting here |
| 06:59:49 | brixen | you mean on windows? |
| 06:59:52 | toulmean | brixen: help you. Get better with windows. |
| 06:59:53 | toulmean | ok |
| 06:59:54 | toulmean | yes |
| 07:00:03 | brixen | hmm, probably would be cool |
| 07:00:06 | brixen | once it runs :) |
| 07:00:15 | toulmean | I can config the windows machine to do IRC too |
| 07:00:28 | toulmean | that bad, ok |
| 07:01:02 | toulmean | well. Think a Java dev can help you with supporting Windows ? :) |
| 07:01:04 | toulmean | oh well. |
| 07:01:11 | brixen | heh |
| 07:03:39 | toulmean | allright time to go to bed. |
| 07:03:55 | boyscout | Added rb_ary_delete specs. - 9820e43 - Brian Ford |
| 07:03:55 | boyscout | Added rb_ary_delete. - 18c45d0 - Brian Ford |
| 07:03:58 | brixen | ok |
| 07:04:09 | brixen | you can see what I did there with rb_ary_delete |
| 07:04:17 | brixen | I'll see how far I get now |
| 07:04:21 | brixen | but I should get some sleep too |
| 07:05:40 | brixen | ok, rb_class_inherited |
| 07:06:08 | toulmean | thx |
| 07:13:09 | boyscout | CI: rubinius: 18c45d0 successful: 3462 files, 13797 examples, 41457 expectations, 0 failures, 0 errors |
| 07:28:10 | brixen | toulmean: just fyi, I have the rest of the symbols resolved, need to write specs for everything |
| 07:28:23 | toulmean | thx |
| 07:28:23 | brixen | toulmean: but I get a segfault loading :) |
| 07:28:33 | brixen | tomorrow I'll look at it some more |
| 07:28:36 | toulmean | here we go... |
| 07:28:38 | toulmean | ok |
| 07:28:39 | toulmean | thx |
| 07:28:43 | brixen | n/p |
| 08:17:44 | dbussink | brixen: http://blog.llvm.org/2010/05/clang-builds-boost.html |
| 15:49:28 | marcandre | brixen: ping |
| 16:19:31 | brixen | dbussink: woot |
| 16:19:36 | brixen | marcandre: pong |
| 16:19:49 | evan | morning. |
| 16:19:58 | evan | brixen: so, we should talk releases. |
| 16:20:06 | brixen | evan: I'm working on the last couple symbols to get rjb loading |
| 16:20:08 | brixen | morning |
| 16:20:11 | evan | k |
| 16:20:12 | brixen | ok, release |
| 16:20:16 | brixen | ship it! |
| 16:20:18 | toulmean | brixen: you're my hero |
| 16:20:19 | evan | :) |
| 16:20:26 | brixen | toulmean: :) |
| 16:21:00 | brixen | evan: I thought you wanted to do 1.0.1 next week? |
| 16:21:23 | evan | I do. |
| 16:21:43 | evan | you were remarking about why we should partition changes into bugfix/feature releases |
| 16:21:49 | evan | we should continue that convo. |
| 16:21:51 | brixen | ah yes |
| 16:21:53 | brixen | ok |
| 16:22:00 | brixen | por telefono? |
| 16:22:05 | evan | sure |
| 16:22:11 | brixen | k |
| 16:22:12 | evan | you wanna finish the rjb stuff first? |
| 16:22:19 | brixen | nah whenever |
| 16:22:25 | brixen | I have a mouthful of bagel atm |
| 16:22:26 | brixen | :) |
| 16:22:34 | evan | hah |
| 16:22:34 | brixen | I'm typing with my mouth full |
| 16:22:38 | evan | ok, i'll call in a few minutes. |
| 16:22:41 | brixen | ok |
| 16:33:37 | toulmean | brixen: still hitting a segfault ? |
| 16:33:42 | toulmean | just wondering. |
| 16:35:46 | brixen | yeah, just starting to work on it though |
| 16:42:22 | toulmean | ok |
| 16:53:54 | brixen | hilarious http://www.centos.org/127_story.html?storyid=127 |
| 16:56:13 | brixen | omg google.com folks |
| 16:56:18 | brixen | how did I not see this |
| 17:01:04 | evan | brixen: hah |
| 17:01:09 | evan | yeah, pacman! |
| 17:03:47 | brixen | heh |
| 17:33:30 | dbussink | brixen: so, is rbx more exotic than boost? ;) |
| 17:33:49 | evan | i hope not! |
| 17:33:52 | dbussink | evan: dunno if you saw it: http://blog.llvm.org/2010/05/clang-builds-boost.html |
| 17:33:55 | dbussink | guess so :) |
| 17:33:58 | evan | I did. |
| 17:35:04 | brixen | dbussink: depends what your taste in exotic is :) |
| 17:40:54 | matthewd | brixen: RuntimeError: Don't know how to build C extensions with ruby1.8 |
| 17:41:48 | evan | matthewd: ? |
| 17:42:12 | matthewd | Apparently my MRI's RUBY_NAME is 'ruby1.8', so capi/spec_helper doesn't like me |
| 17:42:25 | matthewd | Obviously not an insurmountable issue :) |
| 17:43:16 | evan | http://vpri.org/pov/ |
| 17:48:45 | brixen | evan: whoa, cool |
| 17:57:10 | boyscout | Accommodate ruby exe naming. - 5715a35 - Brian Ford |
| 17:57:32 | brixen | matthewd: ^^^ |
| 17:59:28 | matthewd | brixen: Thanks :) |
| 17:59:35 | brixen | n/p |
| 17:59:50 | brixen | that all is hopefully getting a rework soon |
| 18:00:22 | brixen | since there is the rsoc jruby c ext project, I'll need to push c-api to rubyspec |
| 18:04:51 | marcandre | brixen: hi! |
| 18:05:03 | marcandre | So, what's up with floats? :-) |
| 18:05:10 | boyscout | CI: rubinius: 5715a35 successful: 3462 files, 13797 examples, 41457 expectations, 0 failures, 0 errors |
| 18:06:09 | brixen | marcandre: you tell me :) |
| 18:06:14 | brixen | marcandre: we use gdtoa lib |
| 18:06:26 | brixen | and your spec fails, as I showed in that gist |
| 18:06:37 | brixen | weird thing is, last I looked, 1.9 used gdtoa too |
| 18:06:39 | marcandre | googles up " |
| 18:06:43 | marcandre | gdtoa" |
| 18:07:42 | brixen | marcandre: just look in vm/external_libs/libgdtoa/README |
| 18:08:28 | marcandre | What's used for Float#to_s? |
| 18:09:43 | marcandre | I see stuff like "to_s_formatted "%#.15g"" |
| 18:10:01 | brixen | marcandre: snprintf |
| 18:10:15 | brixen | is used by the to_s_formatted primitive |
| 18:10:17 | marcandre | The idea is that to accurately and minimally represent a float, you need anywhere between 15 and 17 decimals. |
| 18:10:42 | brixen | I think you need 55 |
| 18:11:10 | brixen | but I'm happy to be shown the error of my ways :) |
| 18:11:32 | brixen | did you look at my gist? |
| 18:11:41 | marcandre | I wrote before that I strongly disagree with the thinking that a float should be thought of as an exact value, I see a float as a small range of real numbers. |
| 18:11:49 | marcandre | But that's not the issue here. |
| 18:12:01 | marcandre | Can you paste the ref again? |
| 18:12:17 | brixen | thinking about a float in any particular way doesn't change IEEE much ;) |
| 18:12:38 | marcandre | That float I put in the specs is such that it needs 17 decimals to distinguish it from the next and previous float. |
| 18:12:54 | brixen | http://gist.github.com/407768 |
| 18:13:15 | marcandre | If #to_s outputs less than that, then #to_f will rightly convert it to some other float |
| 18:13:17 | brixen | marcandre: I would accept that if there were a single canonical binary rep of a float |
| 18:13:21 | brixen | afaik, there is not |
| 18:13:49 | marcandre | Well, there is a single IEEE double rep of a float, no? |
| 18:14:19 | brixen | I'm not an expert |
| 18:14:28 | marcandre | Don't you agree that "any_float.to_s.to_f.should == any_float"? |
| 18:14:35 | brixen | I'm guessing the folks who wrote gdtoa lib are |
| 18:14:46 | brixen | no, I don't necessarily agree |
| 18:15:03 | matthewd | marcandre: But you just said a float is a small range of real numbers ;) |
| 18:15:05 | brixen | I'm completely against roundtripping floats through strings that way |
| 18:15:05 | evan | seems like that can only be true if Float#to_s outputs absolute precision. |
| 18:15:16 | marcandre | Please point me to the gdtoa library function that outputs a minimal string representation of a float. |
| 18:15:20 | brixen | completely against |
| 18:15:46 | brixen | marcandre: point me to where ieee says there must be that property? |
| 18:15:57 | brixen | I didn't write libgdtoa, I'm only a user of it |
| 18:16:15 | marcandre | evan: no, it can be true if #to_s outputs enough decimals for a given float, so that it does round trip. This number varies between 15 and 17 for IEEE doubles, as per the ref I gave on ruby-core |
| 18:16:23 | brixen | also, where does MRI say that Float must have a minimal, exact string rep that can be roundtripped? |
| 18:16:44 | marcandre | I did, and it was accepted by ruby-core. |
| 18:17:10 | marcandre | See page 4 of http://www.eecs.berkeley.edu/~wkahan/ieee754status/ieee754.ps |
| 18:17:34 | brixen | hmm, I'm looking at the ticket, I don't see that ref |
| 18:17:46 | brixen | looks at ieee doc |
| 18:18:08 | marcandre | yeah, dunno why redmine didn't pick up my reply on the mailing list. |
| 18:19:02 | marcandre | You'll see in the table that IEEE double have between 15 and 17 significant decimals |
| 18:19:31 | marcandre | (as well as other formats we don't use) |
| 18:19:38 | evan | not to throw a wrench in this discusion |
| 18:19:40 | brixen | this does assume the float is a ieee double |
| 18:19:48 | evan | but are we discussing Float#to_s behavior on 1.8 or 1.9? |
| 18:19:57 | brixen | both |
| 18:20:07 | evan | was there a change to Float#to_s in 1.8.7L |
| 18:20:08 | evan | ? |
| 18:20:16 | marcandre | evan: ideally both. I don't think a change has been made to the 1.8 line though |
| 18:20:41 | evan | in which case, it's really just 1.9 |
| 18:20:50 | evan | that would have the expectation of that behavior. |
| 18:21:29 | marcandre | evan: you mean you'd like the specs to be "ruby_version" guarded instead of "ruby_bug" guarded? |
| 18:21:42 | matthewd | brixen: If you have a moment, can I borrow an eyeball on [the specs in] http://gist.github.com/409207 ? |
| 18:21:47 | evan | given the state of things, yes. |
| 18:22:16 | evan | if 1.8 has not change in any version |
| 18:22:18 | matthewd | (Incidentally, should CAPI specs still be split from the implementation for commit?) |
| 18:22:27 | evan | then justifying it with ruby_bug is hard |
| 18:22:41 | evan | matthewd: sure |
| 18:22:50 | evan | matthewd: not really necessary, but might as well get in the habit |
| 18:23:13 | marcandre | evan: how about we consider it an open bug? I'll change the redmine issue to an open backport. |
| 18:23:54 | brixen | matthewd: yes, split the specs |
| 18:23:57 | evan | the issue with using ruby_bug in this case is that there is no version to say when it's fixed |
| 18:24:01 | brixen | matthewd: the specs look good |
| 18:24:05 | evan | which is a requirement of ruby_bug |
| 18:24:08 | evan | so until it's backported |
| 18:24:14 | evan | it should probably remain a ruby_version issue |
| 18:24:19 | brixen | it's not really a bug, either |
| 18:24:32 | brixen | unless I missed where MRI said floats must roundtrip |
| 18:24:33 | evan | when it goes into 1.8, it could then be called a ruby_bug |
| 18:24:34 | brixen | did I miss that? |
| 18:24:45 | evan | brixen: no need to be cheeky :) |
| 18:24:51 | brixen | I'm not |
| 18:24:54 | evan | it's not said, we know. |
| 18:24:58 | brixen | I'm being serious |
| 18:25:01 | brixen | no, I do not know |
| 18:25:04 | evan | but if ruby-core would like to clarify in a future release |
| 18:25:06 | evan | they may do so |
| 18:25:11 | evan | but they have not done so in 1.8 |
| 18:25:19 | brixen | there was the whole discussion of Float#to_s and #inspect in 1.9 |
| 18:25:43 | brixen | is it official now that Float must roundtrip through a #to_s or #inspect string? |
| 18:25:54 | evan | yeah, thats why I asked marcandre if that conversation governed 1.8 |
| 18:25:55 | brixen | and are #to_s and #inspect now synonyms? |
| 18:25:59 | evan | he indicated that ruby-core said it should |
| 18:26:04 | brixen | ok |
| 18:26:13 | evan | but ruby-core has not acted on that statement |
| 18:26:16 | evan | so it's empty atm. |
| 18:26:28 | brixen | lovely fun trying to find that explicitly anywhere |
| 18:26:49 | evan | i'm infering from marcandre's statements |
| 18:26:54 | evan | marcandre: do you have that rubymine bug? |
| 18:27:04 | marcandre | Look, all I care about is that Floats' decimal representation (1) round-trip and (2) be minimal. Unless anyone gives me a better definition, that's what should be, and if it's not, I believe it should be considered a bug. In any version. That's me. |
| 18:27:07 | brixen | anyway, libgdtoa behavior is clearly not consistent with this property |
| 18:27:10 | marcandre | Change the specs as you see fit. |
| 18:27:23 | marcandre | brixen: I don't know that for a fact. |
| 18:27:35 | brixen | marcandre: I'm trying the basis of you 1 and 2 |
| 18:27:53 | brixen | marcandre: I see this ieee doc, I've looked at it in the past |
| 18:27:54 | marcandre | brixen: point me to the method that gives a minimal string representation in the lib. I suspect there isn't any. |
| 18:28:08 | brixen | but it doesn't appear to conform to what libgdtoa does |
| 18:28:26 | brixen | and afaik, ieee double is not a CPU requirement |
| 18:28:35 | brixen | ie, vendors are still free to choose their impl |
| 18:28:45 | brixen | which is *crazy*, I know! |
| 18:28:47 | marcandre | evan and brixen: what I'd like to understand is this: why are you not happy that there is a meaningful definition of the string representation of a float in Ruby? What would you like it to be? |
| 18:29:01 | brixen | marcandre: see my last 4 sentences |
| 18:29:20 | matthewd | evan: Was my reading right that in CAPI, I need to `RBX_RTEST(x) ? Qtrue : Qfalse`, because of the differing values? |
| 18:29:26 | evan | marcandre: i honestly have no opinion on it. |
| 18:29:33 | marcandre | brixen: what is your proposal? |
| 18:29:37 | evan | i'm strictly concerned with the behavior of 1.8 |
| 18:29:45 | evan | as it pertains to these properties. |
| 18:30:06 | brixen | marcandre: my simplest proposal is that no guarantee of roundtripping an exact binary rep is for a string is made |
| 18:30:08 | evan | there are a number of things in 1.8 i would like to change |
| 18:30:11 | marcandre | evan: good. Well the behavior will hopefully change, in 1.8.7 or 1.8.8. |
| 18:30:13 | evan | but we don't for a whole host of reasons. |
| 18:30:23 | brixen | marcandre: consider this, I to_s a float to a string on my computer, and you to_f it on yours |
| 18:30:35 | brixen | marcandre: there is no guarantee our computers use the same float binary rep |
| 18:30:42 | brixen | so, why impose this requirement? |
| 18:31:23 | evan | brixen: one additional data point |
| 18:31:33 | evan | MRI runs on platforms with very different float representations |
| 18:31:40 | brixen | evan: that is my point |
| 18:31:45 | brixen | my whole point really |
| 18:31:54 | evan | i mean all the way down to ARM, M68k, etc. |
| 18:31:55 | marcandre | evan: which other float reps does MRI run on? |
| 18:32:29 | evan | marcandre: i oversteped my point, which is that MRI runs on a lot of different platforms |
| 18:32:47 | evan | and, to my knowledge, there has never been any tests or verification that those platforms all use the same binary representation of a double |
| 18:33:02 | evan | i can't speak to which platforms provide which behaviors |
| 18:33:06 | evan | only that it's an unknown |
| 18:33:10 | brixen | afaik, C spec still does not require ieee 754 for double |
| 18:33:21 | evan | and thusly making a statement that it's a known is wrong unless a survey has been done |
| 18:33:25 | brixen | MRI is written in C using double, it therefore uses the libc double |
| 18:33:42 | brixen | that is reason enough not to impose a Float must roundtrip in a String requirement |
| 18:34:28 | marcandre | When I asked for Float::INFINITY, this kind of discussion came up. Not all floating representations have infinities. |
| 18:34:48 | evan | ah! interesting. |
| 18:34:54 | brixen | the error of logic is that if ieee 754 says something, it must be true in all contexts |
| 18:35:04 | brixen | we haven't established that yet |
| 18:35:04 | evan | marcandre: so did they not inclued it because it's not possible to provide on all platforms? |
| 18:35:07 | marcandre | We now have Float::INFINITY, though :-) |
| 18:35:23 | evan | even though some platforms can't provide it? |
| 18:36:03 | marcandre | From what I remember, noone was able to provide examples of supported platforms that weren't IEEE |
| 18:37:37 | evan | ok |
| 18:38:02 | evan | if ruby-core would like to clarify Float as saying that it's only support on platforms that are IEEE 754 compliant |
| 18:38:05 | marcandre | Checking wikipedia, I see that the Cray SV1 doesn't have IEEE floats |
| 18:38:06 | evan | they're always welcome to do so |
| 18:38:28 | evan | but I stand by the fact that 1.8 currently does not |
| 18:38:51 | evan | now, you can make the arguement that this is a terrible bug and should be fixed even if 1.8 has this behavior |
| 18:38:59 | evan | but that is purely a judgement call on your behalf. |
| 18:39:17 | evan | and one that I am not required to follow. |
| 18:40:01 | evan | and, because rubyspec is defined in terms of "is" statements and not "should be" statements |
| 18:40:15 | evan | the specs should be ruby_version guarded, not ruby_bug. |
| 18:40:46 | evan | again, ruby-core is welcome to revise these properties and we'll adjust things |
| 18:41:08 | evan | marcandre: cool? |
| 18:43:01 | brixen | marcandre: also, could you show me Float::EPSILON in a string with 17-19 that roundtrips |
| 18:43:08 | brixen | marcandre: or Float::MAX? |
| 18:43:57 | brixen | scratch Float::MAX |
| 18:44:05 | brixen | thats just equiv to a huge int |
| 18:44:16 | marcandre | Do as you wish. I have this sour taste in my mouth when I argue stuff like this. I just can't see what you guys are fighting for. I'm just trying to improve things. Having to justify things both on ruby-core and here doesn't feel like a great use of my time. |
| 18:44:22 | brixen | but Float::EPSILON concerns me |
| 18:44:29 | marcandre | brixen: rubydev -e "p Float::EPSILON.to_s.to_f == Float::EPSILON" # => true |
| 18:44:34 | evan | marcandre: i'm not agrueing for or against the behaviro at all. |
| 18:44:48 | evan | marcandre: i'm just trying to clarify what rubinius should do to be 1.8.7 compat. |
| 18:45:18 | evan | marcandre: whats the output of #to_s look like? |
| 18:45:37 | marcandre | I say do what's best, which is to use 15-17 decimals. I put the issue as open and backport. But do as you feel is best. |
| 18:45:46 | evan | marcandre: you don't need to justify it to me, I'll go the way that ruby-core does. |
| 18:45:56 | dbussink | marcandre: i think the problem is that there's no point in discussing here, because what rubinius will do is what ruby-core will do |
| 18:46:30 | evan | I wish ruby-core was more responsive about things like this |
| 18:46:33 | dbussink | marcandre: you can ask people here whether they would agree with ruby-core perhaps defining float as ieee, but that doesn't mean rubinius will implement that |
| 18:46:58 | dbussink | marcandre: because what rubinius implements depends completely on what ruby-core does |
| 18:47:25 | brixen | marcandre: I'm still waiting for my 1.9 to rebuild, but do the core/float/constants specs pass for you? |
| 18:48:00 | marcandre | dbussink: I'll repeat that, given any ieee representation system or not, my belief is that the only meaningful decimal string representation is the one that is both minimal and that round trips. |
| 18:48:00 | brixen | rubinius doesn't have a choice about whether the hardware uses ieee or not |
| 18:48:30 | marcandre | I've not heard of any other meaningful proposition, including today. |
| 18:48:47 | brixen | marcandre: I could accept that if there were a single algorithm (or family of them) to guarantee that |
| 18:48:57 | brixen | marcandre: do you think my position is unreasonable? |
| 18:49:22 | brixen | you can't just say X is required, but in a field so obscure, not say how to show X is attainable |
| 18:49:29 | evan | brixen: are the arguments to ruby_bug supposed to say when the bug is fixed? |
| 18:49:54 | brixen | ruby_bug "#bug number", "last version with bug" |
| 18:49:55 | brixen | ie |
| 18:50:08 | brixen | ruby_bug "#1", "1.8.6.23" |
| 18:50:14 | evan | ok |
| 18:50:15 | marcandre | brixen: your proposition is that it doesn't necessarily round trips. I find that a very bad proposition. As for the algorithm, it is easily provable that there exists one. |
| 18:50:17 | brixen | 1.8.6 p23 had the bug |
| 18:50:45 | brixen | marcandre: so, your position is that libgdtoa is implemented wrongly? |
| 18:50:56 | evan | in the case of |
| 18:50:56 | evan | it "outputs the necessary number of digits to represent the float" do |
| 18:50:58 | evan | being guarded as |
| 18:51:05 | evan | ruby_bug "#3273", "1.8.7" do |
| 18:51:07 | evan | that seems wrong |
| 18:51:12 | evan | since the bug is not fixed |
| 18:51:19 | evan | 1.8.7 is not the last version it is present in |
| 18:51:37 | evan | right? |
| 18:51:55 | brixen | ruby_bug guard is questionable period in this caes |
| 18:52:02 | marcandre | brixen: I'm about to lose my temper, so I'll repeat for the third time: unless I'm mistaken, there is no method in libgdtoa which ouputs a minimal round-tripping decimal representation of a float. I suspect that you always have to specify how many decimals you want. |
| 18:52:22 | brixen | marcandre: my gist is based on your spec |
| 18:52:27 | brixen | ugh |
| 18:52:34 | brixen | no further discussion from me now |
| 18:52:40 | marcandre | by "there is no method that outputs", I mean that "there is no method whose contract is to output" |
| 18:52:43 | brixen | lose your temper elsewhere please |
| 18:53:00 | evan | boys boys. |
| 18:53:06 | evan | it's just floats. |
| 18:53:11 | brixen | no kidding |
| 18:53:12 | brixen | man |
| 18:53:30 | marcandre | I definitely do not want to lose my temper. |
| 18:53:43 | evan | marcandre: i think for the time being, we'll have to agree to disagree then. |
| 18:53:52 | evan | once again |
| 18:53:56 | evan | text chat makes people mad. |
| 18:53:59 | evan | DAMN YOU TEXT CHAT |
| 18:54:03 | marcandre | Unless you point to me a function in the lib that states it outputs a minimal representation, then I'll continue claiming the lib is fine, it's the usage of it that isn't |
| 18:54:23 | brixen | marcandre: look at my gist, it's based on your spec, it fails |
| 18:54:36 | brixen | so, either the spec is wrong, or libgdtoa is wrong |
| 18:54:53 | brixen | trying to figure out which is the only question |
| 18:55:10 | marcandre | Oups, LimeChat lost it :-) |
| 18:55:21 | marcandre | And I lost the gist too... |
| 18:56:16 | brixen | http://gist.github.com/407768 |
| 18:56:47 | brixen | marcandre: http://gist.github.com/409270 |
| 18:56:52 | marcandre | 0.21611564636388508.to_s #=> "0.21611564636388508" |
| 18:56:53 | marcandre | "0.21611564636388508".to_f #=> 0.21611564636388508 |
| 18:57:02 | marcandre | What's the #to_s you're getting? |
| 18:57:17 | marcandre | Oh, it has only 15 decimals, right? |
| 18:57:52 | brixen | I am copy-pasting from your spec |
| 18:58:00 | marcandre | It is incorrect, it should use 17 in this case. As your gist shows. Ruby 1.9 does, Ruby 1.8 doesn't yet. |
| 18:59:13 | marcandre | brixen: what's the question? |
| 18:59:53 | brixen | marcandre: so, this spec is wrong? |
| 18:59:59 | brixen | it should use 17 digits? |
| 19:00:56 | marcandre | For 0.21611564636388508, yes, to_s should output 17 digits, because 17 are not enough to distinguish it from the one before it. |
| 19:01:11 | brixen | lost |
| 19:01:23 | evan | did you mean "because 15 are not enough" ? |
| 19:01:25 | brixen | marcandre: is the spec right or wrong? |
| 19:02:04 | marcandre | The spec that "0.21611564636388508.to_s.to_f.should == 0.21611564636388508" ? |
| 19:02:15 | brixen | yes |
| 19:02:29 | brixen | I'm using exactly that and getting a failure |
| 19:02:37 | brixen | I'll remake the gist with each step, sec... |
| 19:02:41 | marcandre | It is valid, although Ruby 1.8 doesn't respect it yet. |
| 19:02:49 | brixen | I'm not in mri, I'm in rbx |
| 19:02:52 | brixen | bear with me... |
| 19:03:58 | marcandre | My ruby_bug guard for 0.56 doesn't make much sense, though. I'll remove it altogether, since that only appeared in 1.9 |
| 19:03:58 | matthewd | Not really relevant, but interesting that my perl 5.10.1 doesn't round-trip that value either |
| 19:04:23 | brixen | marcandre: ohhhkay, ready for this? |
| 19:04:34 | brixen | our #to_s returns 15 digits |
| 19:04:42 | brixen | so it is not libgdto |
| 19:04:45 | brixen | thankfully |
| 19:05:02 | brixen | so this spec should be more explicit |
| 19:05:20 | brixen | it needs to assert on the size of the string returned by #to_s |
| 19:06:04 | brixen | better, it needs to make an expectation with a literal string |
| 19:06:08 | brixen | like all the other specs do |
| 19:06:24 | marcandre | matthewd: interesting. There might be other languages that make that mistake too, I don't know. |
| 19:06:28 | brixen | the #to_f spec should assert that the value is the same |
| 19:06:52 | brixen | marcandre: are you following me? |
| 19:07:25 | marcandre | brixen: As you wish. I believe that spec is valid no matter what float representation is used, and also shows the intent, which is why I wrote it this way |
| 19:09:10 | brixen | you can include the extra expectation on #to_f, but I insist the #to_s is compared to a literal string :) |
| 19:10:04 | marcandre | Sure, you're welcome to change that. |
| 19:10:20 | brixen | of course I am, and you are as well :) |
| 19:10:51 | brixen | in general, the more explicit the spec, the better |
| 19:11:03 | marcandre | Cool. I'll go back to work, then. |
| 19:11:10 | brixen | marcandre: thanks |
| 19:12:43 | cremes | amazed at all the flames in rubinius and jruby channels the last 24 hours |
| 19:13:02 | cremes | checking local water supply for contamination |
| 19:15:56 | brixen | this still does not answer the question of Float::EPSILON |
| 19:19:04 | brixen | hmm |
| 19:19:18 | dbussink | cremes: what were the jruby flames burning? |
| 19:20:06 | cremes | dbussink: it had to do with the nokogiri gem; the gem author and a user "had words" but they made up in the end |
| 19:20:36 | brixen | ok, Float::EPSILON issue is again the number of decimal digits |
| 19:20:43 | cremes | it took place in channel but wasn't really a jruby flame fest :) |
| 19:21:00 | brixen | so, we need a set of specs covering common Float boundaries and their String representations |
| 19:26:41 | matthewd | Hrmmm... is github confused, or did I just manage to do something silly? |
| 19:27:14 | matthewd | In theory, I just pushed to master... but boyscout and the github web interface seem less convinced :/ |
| 19:27:43 | brixen | I will venture that the conjunctive connective is perfectly plausible there :) |
| 19:28:21 | brixen | matthewd: it pushed, I have it |
| 19:28:40 | matthewd | brixen: ;) |
| 19:31:39 | boyscout | Implement rb_is_{const,instance_class}_id() in CAPI. - 149a537 - Matthew Draper |
| 19:31:39 | boyscout | Spec rb_is_{const,instance,class}_id() in CAPI. - 6086ae6 - Matthew Draper |
| 19:35:29 | matthewd | Still in CAPI... we define `VALUE rb_protect(VALUE (*func)(ANYARGS), VALUE data, int* status)`... but MRI says `VALUE rb_protect(VALUE (*func)(VALUE), VALUE data, int* status)` |
| 19:36:53 | matthewd | Is that just because we foolishly assumed that MRI would use the same signature for rb_protect as for rb_protect_inspect (ha ha, yeah right), or deliberate? |
| 19:38:13 | dbussink | matthewd: most likely the former :) |
| 19:40:57 | boyscout | CI: rubinius: 6086ae6 successful: 3463 files, 13809 examples, 41469 expectations, 0 failures, 0 errors |
| 19:44:38 | dbussink | clang error message are so much better :) |
| 19:44:45 | dbussink | they even have shiny colors! |
| 19:45:27 | dbussink | of course rubinius doesn't get very far: https://gist.github.com/b93f162a9e1833bd6f19 |
| 19:46:04 | wayneeseguin | evan / brixen Any idea what causes this? (configure error at the very end) http://gist.github.com/408992 |
| 19:47:21 | brixen | wayneeseguin: configure script has a hash bang for env ruby ? |
| 19:47:31 | brixen | and you have no env ruby |
| 19:47:32 | dbussink | wayneeseguin: looks like it wants ruby in the path |
| 19:48:05 | dbussink | evan: that's what i got when trying to compile with clang (no illusion it would work, but wanted to try anyway) |
| 19:48:06 | wayneeseguin | brixen: odd... it should have selected a 1.8.7... |
| 19:48:17 | brixen | wayneeseguin: hm, weird |
| 19:49:09 | wayneeseguin | I can't replace it locally so I'm trying to figure it out but that does help some |
| 19:50:42 | brixen | I can't wait to add configure.bat :) |
| 19:56:15 | dbussink | brixen: that sounds like fun! |
| 19:57:22 | brixen | dbussink: heh :) |
| 19:57:43 | brixen | ok, I think I have a function in libgdtoa to emit a shortest representation |
| 19:57:51 | brixen | but I need some lunch first... |
| 20:03:27 | evan | wayneeseguin: ./configure is a ruby script |
| 20:03:29 | evan | is there no ruby? |
| 20:03:50 | evan | perhaps you meant to run configure under the ruby that rvm installs? |
| 20:03:55 | evan | rather than via /usr/bin/env ruby |
| 20:04:05 | evan | dbussink: oh, that is a bug! |
| 20:04:11 | evan | i have it declared differently |
| 20:04:13 | evan | oops! |
| 20:04:21 | wayneeseguin | evan: I have rvm installing and selecting 1.8.7 under rvm to install rbx |
| 20:04:25 | wayneeseguin | hence my confusion |
| 20:04:36 | evan | right, but i see it running configure as ./configure |
| 20:04:44 | wayneeseguin | yes |
| 20:04:48 | wayneeseguin | it does that in that selected env |
| 20:04:49 | evan | not explicitly via the 1.8.7 you also build |
| 20:04:57 | wayneeseguin | ohhhh I should do 'ruby configure ...' |
| 20:04:58 | wayneeseguin | ? |
| 20:05:02 | evan | exactly. |
| 20:05:06 | wayneeseguin | aha!!!! |
| 20:05:08 | wayneeseguin | brilliant |
| 20:05:18 | evan | otherwise it uses the sheband |
| 20:05:24 | evan | shebang |
| 20:05:28 | evan | which is #!/usr/bin/env ruby |
| 20:05:38 | evan | and that system doesn't have a ruby in the PATH |
| 20:06:48 | wayneeseguin | well 'rvm use 1.8.7' is supposed to set a ruby in the path though |
| 20:06:49 | evan | brixen: when you get back |
| 20:06:53 | evan | i don't mean to beat a dead horse |
| 20:07:10 | evan | but we don't appear to use libgdtoa for printing for a double |
| 20:07:24 | evan | we use snprintf, passing in .15g |
| 20:07:42 | evan | wayneeseguin: perhaps there is another bug then. |
| 20:09:30 | wayneeseguin | evan: I'm trying with the 'ruby configure ...' now |
| 20:09:40 | evan | k |
| 20:13:11 | brixen | evan: yeah, we use snprintf, but instead of trying to port MRI's fix, i want to see if libgdtoa will do it for us |
| 20:13:34 | brixen | the minimal vs exact repr of a double is quite the important idea |
| 20:13:48 | evan | ok. |
| 20:14:09 | brixen | and hence why that spec was very misleading |
| 20:14:40 | brixen | I was off in the "libgdtoa is not converting binary -> string correctly" weeds |
| 20:14:54 | brixen | when in fact, we were not giving it the right string |
| 20:15:16 | evan | right |
| 20:15:24 | evan | it's a Float#to_s issue. |
| 20:15:28 | evan | not a String#to_f issue. |
| 20:15:28 | brixen | yeah |
| 20:15:33 | brixen | right |
| 20:16:10 | evan | so, I've added rbx console |
| 20:16:18 | evan | which connects to the query agent of another rbx |
| 20:16:25 | brixen | heh, nice! |
| 20:16:32 | evan | and i've got it setup so that when you start the query agent, it writes a file into $TMPDIR |
| 20:16:36 | evan | that says where it's located |
| 20:16:45 | evan | and rbx console can read them to find where to connect to |
| 20:17:03 | evan | if you've only got one rbx running |
| 20:17:08 | evan | 'rbx console' just works |
| 20:17:22 | brixen | sweet |
| 20:17:40 | evan | i'm going to add a backtrace command |
| 20:17:48 | evan | that will gather up the ruby and C backtraces of all the threads |
| 20:17:51 | evan | and ship it across |
| 20:18:01 | brixen | oh happy times! |
| 20:18:04 | brixen | that is excellent |
| 20:18:43 | brixen | say I have 2 rbx running (in specs), how do I say which to connect to? |
| 20:19:05 | dwaite | could you make sigquit dump all the threads and any gc/ffi information to stderr before quitting? :) |
| 20:19:23 | evan | dwaite: if you'd like. |
| 20:19:29 | evan | brixen: it asks you |
| 20:19:34 | brixen | evan: ok cool |
| 20:19:37 | evan | it prints them out and you say which one you want |
| 20:19:47 | evan | the tmp file has the contents of argv |
| 20:19:52 | evan | to help you figure out which you wanted. |
| 20:19:56 | brixen | suspects dwaite is an FBI agent, he shows up as soon as we start talking query agent |
| 20:20:38 | brixen | dwaite: how's LL coming along? |
| 20:20:39 | dwaite | someone once told me that I would make an excellent NARC |
| 20:20:45 | dwaite | LL? |
| 20:20:52 | brixen | dwaite: Learning Lua :) |
| 20:20:57 | dwaite | ohhh |
| 20:21:04 | dwaite | not too good so far |
| 20:21:14 | brixen | get stuck in a table? |
| 20:21:17 | dwaite | I think I might need to quit WoW to become a productive member of society again |
| 20:21:22 | brixen | haha |
| 20:21:39 | dwaite | but my toon is so awesome now :'( |
| 20:21:54 | brixen | heh |
| 20:22:34 | slava | hi brixen |
| 20:22:45 | evan | slava: sup |
| 20:23:19 | brixen | hi slava |
| 20:29:18 | brixen | dbussink: if you are still awake, I want you to know I am enjoying a delicious wafer filled with sweet, creamy caramel at this very moment |
| 20:29:29 | brixen | dbussink: courtesy of Daelmans :) |
| 20:30:53 | rue | Ewww..strawberry jam and (ice)? cream goes with waffles |
| 20:31:34 | evan | rue: yummy! |
| 20:31:44 | brixen | no doubt |
| 20:32:14 | brixen | the thought of that is making my stroopwafel seem paltry |
| 20:35:18 | slava | working on DLS paper |
| 20:41:00 | evan | rad |
| 20:41:11 | evan | the queryagent can halt all the other threads nice and easily |
| 20:41:14 | evan | because of the GIL |
| 20:41:21 | evan | and then gather info safely. |
| 20:44:01 | brixen | slava: DLS? |
| 20:48:17 | slava | dynamic languages symposium |
| 20:48:30 | slava | http://www.dynamic-languages-symposium.org/dls-10/ |
| 20:49:50 | evan | oh my! |
| 20:49:55 | evan | oopsla changed it's named? |
| 20:50:30 | evan | sort of. |
| 20:51:30 | brixen | oh interesting |
| 20:51:49 | evan | hm, i wonder how I can use backtrace() on another thread... |
| 20:52:14 | brixen | odd, this g_dfmt function wants the address of the double |
| 20:52:18 | brixen | I wonder why |
| 20:53:13 | evan | does it change it? |
| 20:53:48 | brixen | heh, I don't know |
| 20:56:09 | brixen | I wouldn't expect it to, but fun code to trace https://gist.github.com/72e2b83303c628356ba5 |
| 20:56:12 | brixen | :) |
| 20:57:00 | evan | brixen: perhaps because it converts it to a ulong* |
| 20:57:08 | evan | so it can read the double's memory directly. |
| 20:57:55 | brixen | hmm |
| 20:58:11 | brixen | you think pass by value to the function could change the bit patter? |
| 20:58:14 | brixen | +n |
| 20:58:26 | brixen | ahh the pitter patter of little bits |
| 20:59:27 | brixen | that was tweet-worthy :) |
| 21:00:40 | evan | brixen: no, but he'd do it for efficience probably. |
| 21:00:50 | brixen | hmm |
| 21:01:01 | brixen | I guess passing an int would be faster, then? |
| 21:01:12 | brixen | it would fit in one reg |
| 21:01:28 | brixen | int == pointer word |
| 21:02:31 | evan | same though |
| 21:02:37 | evan | passing as a double* is the same as passing as an int |
| 21:02:48 | brixen | right, that makes sense |
| 21:03:08 | slava | an int is not a pointer word on 64-bit |
| 21:03:22 | evan | slava: he didn't mean int, the C type directly. |
| 21:03:25 | evan | just an integer. |
| 21:03:30 | slava | ok |
| 21:03:34 | brixen | yeah |
| 21:03:53 | slava | also, don't use long as a synonym for a pointer-size int either |
| 21:03:58 | slava | because on win64, longs are 4 bytes |
| 21:04:01 | brixen | yeah, I know |
| 21:04:04 | brixen | fun stuff |
| 21:04:11 | evan | fucking win64 |
| 21:04:15 | slava | porting factor to win64 ws a bit painful because of that |
| 21:04:23 | slava | also SEH is really complicated |
| 21:05:23 | evan | rad. backtrace in console works. |
| 21:05:27 | brixen | sweet, 0.21611564636388508.to_s_minimal => ".21611564636388508" |
| 21:05:36 | brixen | so hopefully I just need to touch up the repr |
| 21:06:17 | brixen | oh hells yeah, Float::EPSILON.to_s_minimal looks good |
| 21:06:22 | brixen | thank you libgdtoa |
| 21:06:55 | brixen | not that I don't trust MRI C code or anything <wink, wink, smile, wink> |
| 21:09:47 | evan | heh |
| 21:12:50 | toulmean | brixen: remember your thing about rake using mtime and not digest ? |
| 21:13:03 | toulmean | brixen: how more costly would it be to implement digest ? |
| 21:13:18 | toulmean | we have failures on win7 due to mtime |
| 21:13:40 | brixen | toulmean: depends on the digest function to some extent |
| 21:13:52 | toulmean | brixen: depends on the file size too ? |
| 21:13:55 | brixen | toulmean: I guess the cost depends on whether the build is more robust |
| 21:13:58 | brixen | yes |
| 21:14:01 | brixen | that's what I mean |
| 21:14:11 | toulmean | that's unfortunate. |
| 21:14:20 | toulmean | hmmm |
| 21:14:27 | brixen | it's probably not a big deal actually |
| 21:14:36 | toulmean | mtime is O(1), we have a digest O(n) ? |
| 21:14:38 | brixen | do you have megabytes of source? |
| 21:14:54 | evan | sha1 isn't O(n) |
| 21:14:56 | evan | i don't believe. |
| 21:15:19 | brixen | seems like any digest would have to be O(n) |
| 21:15:27 | brixen | it's got to consider every byte |
| 21:15:28 | toulmean | brixen: more like buildr package will only recreate the package if the filetask for the war or jar it creates has a mtime different |
| 21:15:31 | evan | i suppose. |
| 21:15:49 | toulmean | we have artifacts of 350 mb max |
| 21:15:53 | toulmean | let me see |
| 21:16:05 | brixen | 350MB artifacts?? |
| 21:16:15 | evan | yikes. |
| 21:16:21 | brixen | holy cow, are you building OS distros? |
| 21:17:23 | toulmean | brixen: dude, we're building the CLOUD |
| 21:17:31 | toulmean | next thing you know we'll go to space |
| 21:17:38 | brixen | heh |
| 21:17:43 | toulmean | and yes this is EE java. In all its beauty |
| 21:17:46 | brixen | ohh, well when you put it like that... |
| 21:17:51 | toulmean | it's actually very lean |
| 21:17:54 | toulmean | :) |
| 21:17:59 | brixen | sounds like it |
| 21:18:01 | brixen | :) |
| 21:18:09 | toulmean | if you could see the size of an IBM websphere download |
| 21:18:10 | toulmean | 2 Gb |
| 21:18:19 | brixen | wowsers |
| 21:18:27 | toulmean | or the JBoss server, as a .tar.gz, easily 300 mb |
| 21:18:32 | toulmean | without any apps on it |
| 21:18:35 | toulmean | just for fun |
| 21:18:52 | toulmean | ok our zip is 70 mb and md5 needs 3s to consider it |
| 21:19:00 | toulmean | what I can do: fork rake and try it out |
| 21:19:03 | brixen | I like reading how one reason the jvm was stack based is because it requires smaller bytecode, which was important when the bytecode is passed over the internet |
| 21:19:03 | toulmean | will report. |
| 21:19:18 | brixen | then ppl build the most huge projects every with java |
| 21:19:24 | brixen | -y |
| 21:19:30 | toulmean | ya |
| 21:19:40 | toulmean | well I don't send bytecode over the tubes |
| 21:19:42 | toulmean | thx much |
| 21:19:50 | toulmean | I use REST or SOAP... |
| 21:20:43 | brixen | toulmean: so, easy way around this... file tasks take a option to use mtime vs digest |
| 21:20:49 | brixen | and you could set it globally too |
| 21:20:59 | brixen | you could mtime your huge stuff like packages |
| 21:21:10 | brixen | and digest the source for compiling |
| 21:21:21 | brixen | possibly |
| 21:21:31 | brixen | frankly, it's a problem I do not have building rbx |
| 21:22:48 | toulmean | yes |
| 21:22:52 | toulmean | yes for the option I mean |
| 21:22:58 | toulmean | for the rest I am just jealous |
| 21:25:08 | toulmean | finally found a reason to fork rake!! |
| 21:25:10 | dbussink | evan: clang is catching some more type errors :) |
| 21:25:20 | evan | oh? |
| 21:25:24 | evan | gist? |
| 21:26:00 | dbussink | evan: mostly struct / class intermixed |
| 21:26:38 | evan | i saw it complaining about "void* body[]" |
| 21:26:40 | evan | did you fix that? |
| 21:26:49 | dbussink | evan: and a few of those yeah |
| 21:26:50 | toulmean | brixen: did you make headway on the rjb stuff ? Just curious. I guess I should recontact you after the next release or so |
| 21:26:58 | dbussink | evan: walking through it now, will show a gist if i'm through |
| 21:27:03 | evan | what did you to do fix them? |
| 21:27:09 | evan | use 'void* body[0]' ? |
| 21:27:20 | dbussink | evan: void** body |
| 21:27:27 | brixen | toulmean: I'll be back to it in just a bit |
| 21:27:27 | evan | thats wrong. |
| 21:27:32 | evan | dbussink: thats not the same. |
| 21:27:33 | brixen | toulmean: fixing Float issues atm |
| 21:27:47 | dbussink | evan: what's the difference exactly then? |
| 21:27:58 | dbussink | because it wasn't complaining about accessing stuff |
| 21:28:03 | evan | "void* body[]" is "magic" |
| 21:28:19 | dbussink | i didn't know that :) |
| 21:28:24 | dbussink | how's it magic? |
| 21:28:25 | toulmean | brixen: plz, no pressure |
| 21:28:26 | toulmean | :) |
| 21:28:27 | evan | it says that you can access the memory of the enclosing structure directly |
| 21:28:31 | evan | so when you have |
| 21:28:41 | evan | struct A { int a; int blah[]; } |
| 21:29:02 | evan | A* t = ....; |
| 21:29:15 | evan | &t->a == 0x0 |
| 21:29:24 | evan | &t->blah[0] == 0x4 |
| 21:29:28 | evan | &t->blah[1] == 0x8 |
| 21:29:52 | evan | void** says that it stores a pointer that referes to some other memory that contains an array of voids |
| 21:30:17 | dbussink | ah ok, but should void* body[0] be the same? |
| 21:30:20 | evan | the key thing is that 'int blah[]' doesn't actually count toward the size of A |
| 21:30:32 | evan | yeah, void* body[0] should be the same. |
| 21:31:42 | dbussink | evan: sort of dynamically sized structs? |
| 21:32:00 | dbussink | or class instances for that matter when having an ivar? |
| 21:32:15 | evan | yeah, dynamicly sized structs |
| 21:32:31 | evan | it's a common idiom |
| 21:32:35 | dbussink | and that [0] is magic too then i guess? |
| 21:32:40 | evan | where the header is fixed size and the body is dynamic |
| 21:32:41 | dbussink | btw, uint8_t bytes[]; => uint8_t bytes[0]; ? |
| 21:32:51 | evan | and use the data in the header to know how much data is in the body |
| 21:32:56 | dbussink | so you'd always have that one last i guess then? |
| 21:32:59 | evan | yeah, [0] should be the same. |
| 21:33:01 | evan | as [] |
| 21:33:08 | dbussink | can't have multiple of those in one class / struct etc. |
| 21:33:18 | evan | with [0], you just read past the end |
| 21:33:20 | evan | since the end is the start |
| 21:33:36 | evan | the key, again, is that the C compiler doesn't allocate space for the array by default |
| 21:33:41 | evan | because the header could say that there is no body |
| 21:33:46 | evan | so you can't do [1], for instance |
| 21:33:48 | dbussink | that's manually managed then |
| 21:33:58 | evan | yes |
| 21:33:59 | evan | ! |
| 21:34:02 | evan | you can only have one |
| 21:34:07 | evan | and it must be the last struct member |
| 21:34:27 | dbussink | and each allocation has to be allocated with the needed size |
| 21:34:34 | dbussink | which determines how much room there actually is |
| 21:35:45 | dbussink | another fun one: vm/exception.cpp:52:22: error: variable length arrays are not permitted in C++ |
| 21:35:45 | dbussink | void *stack_addrs[max_depth]; |
| 21:35:47 | rue | evan: Going to go watch the race tomorrow? |
| 21:35:47 | evan | right |
| 21:36:03 | evan | you use malloc() to allocate space for the header and the body |
| 21:36:17 | dbussink | i already like clang much better for the error messages :) |
| 21:36:18 | evan | dbussink: ha |
| 21:36:18 | evan | ok |
| 21:36:22 | evan | rue: which? |
| 21:37:43 | dbussink | evan: should i calloc that? |
| 21:37:52 | evan | which? |
| 21:38:05 | dbussink | evan: that variable length array? |
| 21:38:14 | evan | sure |
| 21:38:25 | evan | be sure to free() it at the end of the function |
| 21:38:34 | evan | or, rather, near the other free |
| 21:42:12 | toulmean | brixen: there is a problem with the digest approach, it requires each prerequisite to compute its digest when the application starts. |
| 21:42:27 | dbussink | evan: also with calloc? |
| 21:42:34 | evan | ? |
| 21:42:35 | slava | evan: do you ever use alloca? |
| 21:42:41 | evan | slava: yeah |
| 21:42:44 | toulmean | brixen: rake executes a task when any of the prerequisites of a given task have a stamp higher than the stamp on the current task |
| 21:42:48 | toulmean | see the diff ? |
| 21:43:01 | dbussink | evan: nvm |
| 21:43:10 | rue | evan: Tour of California has an individual time trial in LA tomorrow |
| 21:43:17 | evan | oh right. |
| 21:43:26 | evan | a friend from seattle is going |
| 21:43:30 | evan | i'll see, maybe. |
| 21:43:36 | toulmean | mtime actually serves to unify the system - only run the jar packaging if one or more classes are newer than the jar. |
| 21:43:51 | dbussink | evan: something like this? https://gist.github.com/c1c356f5fa761547819a |
| 21:43:51 | toulmean | you can't keep track of that using digests |
| 21:44:20 | evan | dbussink: thats calloc you're calling |
| 21:44:21 | evan | not malloc |
| 21:44:27 | evan | even though you used the word "malloc" |
| 21:44:30 | dbussink | evan: doh, that's not right no |
| 21:44:44 | evan | it's also wrong. |
| 21:45:05 | evan | return value of calloc should be cast to a void** |
| 21:45:58 | brixen | toulmean: I do not plan to duplicate how rake computes the dependencies |
| 21:46:18 | toulmean | brixen: well I was doing it :) |
| 21:46:23 | dbussink | evan: any preference to calloc or malloc? |
| 21:46:32 | brixen | g_dfmt is such a lovely function, even getting +-Infinity and NaN string right, but has an aversion to 0 |
| 21:46:35 | brixen | :( |
| 21:46:37 | evan | dbussink: calloc |
| 21:54:19 | dbussink | evan: it's slowly getting there :) |
| 21:54:43 | evan | heh |
| 22:38:01 | brixen | arg, this is giving me a case of the frownies |
| 22:38:11 | evan | uhoh! |
| 22:38:14 | evan | you need a brownie! |
| 22:38:14 | brixen | mri starts using e notation when the whole part exceeds 14 digits |
| 22:38:19 | evan | to stave off the frownies! |
| 22:38:23 | brixen | g_dfmt when it exceeds 12 digits |
| 22:38:31 | brixen | I wish I had a brownie dessert |
| 22:38:39 | brixen | and some latte :) |
| 22:41:40 | evan | brixen: almost got it sorted so the console lets you do |
| 22:41:41 | evan | bt --vm |
| 22:41:54 | evan | and it connects to the VM via gdb and gets a backtrace of all the threads |
| 22:42:11 | brixen | awesome |
| 22:42:13 | evan | i've also got a gdb command to drop into gdb |
| 22:42:15 | evan | of course |
| 22:42:16 | evan | :) |
| 22:42:19 | brixen | hah |
| 22:42:22 | brixen | of course! |
| 22:44:53 | dwaite | mmm, latte and browny |
| 22:44:55 | dwaite | brownie |
| 22:45:01 | dwaite | you guys know how to party |
| 22:45:05 | dbussink | evan: w00t, it compiled all cpp files with clang :) |
| 22:45:13 | evan | woop! |
| 22:45:14 | evan | does it run? |
| 22:45:20 | brixen | dbussink: sweet! |
| 22:46:18 | dbussink | it's now some hybrid build though, linked with g++, some c extensions build with gcc, some with clang too |
| 22:46:36 | dbussink | but i can open irb :) |
| 22:46:45 | brixen | dbussink: run the specs! :) |
| 22:46:59 | dbussink | brixen: already on it :) |
| 22:47:03 | brixen | heh |
| 22:47:11 | brixen | fun times ahead |
| 22:47:21 | brixen | thanks all the llvm devs |
| 22:47:22 | dbussink | looking good |
| 22:48:11 | dbussink | sigv... |
| 22:49:09 | evan | dbussink: could you gist your current diff? |
| 22:49:40 | dbussink | evan: https://gist.github.com/c6409fbe016e7e95e797 |
| 22:51:05 | evan | pretty simple |
| 22:51:18 | evan | i'm curious why you moved that public: decl |
| 22:51:33 | dbussink | evan: because stuff is accessing that |
| 22:51:49 | evan | like? |
| 22:51:55 | evan | why would g++ allow it? |
| 22:52:42 | dbussink | evan: vm/llvm/jit_runtime.cpp:32 |
| 22:52:47 | dbussink | evan: i don't know :) |
| 22:57:13 | dbussink | hmm, didn't segfault the second run |
| 22:57:28 | brixen | everything pass? |
| 22:58:26 | dbussink | brixen: yeah |
| 22:58:53 | brixen | very nice |
| 22:59:11 | brixen | dbussink: I see this has really captivated your interest :) |
| 22:59:18 | brixen | up late on a fri night |
| 22:59:24 | dbussink | brixen: i just like trying stuff ou |
| 22:59:34 | brixen | heh, yeah, the clang stuff is awesome |
| 22:59:38 | dbussink | brixen: semi watching tv a bit, it's a lot of waiting ;) |
| 23:00:46 | dbussink | evan: shall i push this stuff? |
| 23:00:48 | brixen | my new apt looks out at a church tower 2 blocks away in which a bell mercilessly tolls the passing of each half hour |
| 23:00:53 | brixen | it's really vicious |
| 23:01:48 | evan | brixen: ug. |
| 23:02:07 | evan | dbussink: sure |
| 23:02:25 | dbussink | brixen: also on sunday morning for a longer period when you're trying to sleep in? |
| 23:02:27 | boyscout | whitespace fix - 4d0a4e2 - Evan Phoenix |
| 23:02:27 | boyscout | Add backtrace and discover ability to QueryAgent - 058bc9f - Evan Phoenix |
| 23:02:27 | boyscout | Started on the console, pulled in our own copy of bert - c60543d - Evan Phoenix |
| 23:02:28 | brixen | I'm trying to modify g_dfmt to output the right format, rather than fixing it up post |
| 23:02:51 | brixen | dbussink: heh, at 10! they have this really long tolling nonsense |
| 23:03:03 | brixen | dbussink: but I'm already up preparing for my training rides |
| 23:04:13 | brixen | I love the comments in this code |
| 23:04:42 | brixen | like /* Infinity or NaN */ right before it copies "NaN" and returns |
| 23:04:55 | brixen | and /*d == 0.*/, right before it returns "0" |
| 23:05:12 | brixen | but um, think there's any comments before the crazy stuff? |
| 23:05:16 | brixen | get out of town... |
| 23:05:49 | toulmean | you could be debugging java code... |
| 23:06:10 | brixen | toulmean: *you* could be debugging java code... oh wait, nvm :) |
| 23:06:59 | toulmean | I was trying to make you feel better... |
| 23:07:04 | toulmean | :) |
| 23:07:18 | brixen | heh, I know |
| 23:07:24 | brixen | it's not working :P |
| 23:08:10 | boyscout | Initial work to enable compiling with clang - 6f92669 - Dirkjan Bussink |
| 23:11:56 | boyscout | CI: rubinius: c60543d successful: 3463 files, 13809 examples, 41469 expectations, 0 failures, 0 errors |
| 23:12:34 | toulmean | ok I'll shut up. |
| 23:18:47 | brixen | toulmean: no worries, I'm just kidding |
| 23:19:14 | toulmean | oh I'm good. I wish I could help, really |
| 23:19:47 | brixen | heh, well someone else already did the hard part, I just have to figure out what the hell they did :) |
| 23:23:53 | toulmean | ok, where is that stuff you're working on ? |
| 23:25:01 | brixen | which? |
| 23:25:39 | toulmean | the stuff you mention that needs doc |
| 23:26:00 | toulmean | I guess you are looking at the MRI code and trying to replicate it inside rubinius with the optimizations you can afford |
| 23:26:20 | toulmean | and you are telling me they did mostly the job, but they documented it in a parse way |
| 23:26:29 | toulmean | so I'm asking where is that MRI code ? |
| 23:26:58 | brixen | I'm looking at vm/external_libs/libgdtoa/g_dfmt.c and fixing it to output a string in the same format as MRI |
| 23:29:37 | toulmean | brixen: and where do you go for MRI code ? |
| 23:29:50 | toulmean | also, don't you have a spec for it in your ruby test suite ? |
| 23:31:17 | brixen | indeed we do |
| 23:32:33 | toulmean | brixen: and that doesn't help you at all ? |
| 23:32:49 | brixen | not sure what ya mean |
| 23:32:54 | toulmean | actually, I'm wondering if you work against the spec or the MRI code |
| 23:33:02 | brixen | the spec |
| 23:33:22 | toulmean | it looks like you refer to MRI: "output a string in the same format as MRI" |
| 23:33:52 | toulmean | while I would expect you would say: "We are trying to be spec compliant by outputting a string in the appropriate format" |
| 23:34:22 | brixen | MRI is the "appropriate format" |
| 23:34:36 | brixen | in that MRI decides what that format is |
| 23:35:11 | toulmean | no spec for it ? |
| 23:35:22 | toulmean | hmm that code gives me a nosebleed |
| 23:35:35 | brixen | no spec for whatL |
| 23:35:37 | brixen | ? |
| 23:36:16 | toulmean | for the format of the String ? |
| 23:36:20 | toulmean | oh well. |
| 23:36:30 | brixen | there are specs |
| 23:36:38 | brixen | a little bit wonky atm, but there are specs |
| 23:36:45 | brixen | that's what I'm trying to match |
| 23:38:34 | evan | brixen: got any points charlie and I should hit in our railsconf talk about weird ruby stuff? |
| 23:38:52 | boyscout | Allow for a random server port to be used - 436e637 - Evan Phoenix |
| 23:38:57 | brixen | hmm, not offhand |
| 23:40:01 | evan | k |
| 23:40:36 | evan | i'm looking for antipatterns |
| 23:40:38 | evan | if you have any |
| 23:40:39 | evan | i've got a few. |
| 23:40:59 | brixen | hm |
| 23:41:22 | brixen | never can harp on the composition vs inheritance enough |
| 23:41:30 | brixen | if that qualifies as an anti-pattern |
| 23:42:27 | evan | oh it does. |
| 23:42:34 | evan | well, maybe |
| 23:42:38 | evan | but i'm bringing it up anyway |
| 23:42:40 | evan | thanks for reminding me |
| 23:42:50 | evan | also, i'm thinking about renaming -Xagent.port |
| 23:42:53 | evan | perhaps -Xagent.start? |
| 23:43:05 | evan | because if you do just -Xagent.start |
| 23:43:14 | evan | it picks a random port that console can find in the temp file |
| 23:43:19 | evan | or -Xagent.start=<port> |
| 23:43:27 | evan | to assign one explicitly |
| 23:43:34 | brixen | that seems reasonable |
| 23:44:18 | evan | is agent.start a good name? |
| 23:44:33 | evan | should I be putting a rbx prefix on it? |
| 23:44:43 | brixen | nah, just agent |
| 23:44:47 | evan | -Xus.rubini.agent.start |
| 23:44:50 | brixen | we removed all the rbx. |
| 23:44:54 | brixen | eeww :P |
| 23:44:58 | evan | hehehe |
| 23:44:58 | evan | k |
| 23:50:48 | boyscout | CI: rubinius: 436e637 successful: 3463 files, 13809 examples, 41469 expectations, 0 failures, 0 errors |
| 23:53:08 | boyscout | Rename agent.port to agent.start - 8a4758c - Evan Phoenix |
| 23:53:14 | evan | heh, it's pretty rad |
| 23:53:20 | evan | just throw -Xagent.start in there |
| 23:53:23 | evan | then in another window |
| 23:53:29 | evan | rbx console |
| 23:53:32 | evan | and you're in. |
| 23:53:41 | evan | there is no step 3 |
| 23:55:19 | brixen | sweet, I shall try it |
| 23:56:51 | evan | next step is to allow console to run ruby code in the target rbx |
| 23:58:35 | brixen | wait, what? it doesn't do that yet? :) |
| 23:59:04 | brixen | <3 git stash |