Show enters and exits. Hide enters and exits.
| 16:02:53 | evan | morning gents! |
| 16:10:25 | brixen | morning! |
| 16:21:37 | cremes | hey guys; what are the priorities for this week? |
| 16:24:54 | brixen | unicorns and rainbows |
| 16:25:02 | brixen | but sometimes I get my priorities confused |
| 16:25:12 | brixen | so that may in fact be rainbows and unicorns |
| 16:25:15 | brixen | :) |
| 16:28:44 | brixen | and by that I mean, unicorns == pack/unpack, rainbows == tickets |
| 16:30:29 | cremes | ah, the unicorns are still a thorn in your side i see |
| 16:30:35 | cremes | did you figure out the floating point packing yet? |
| 16:33:01 | brixen | yeah, it's all done |
| 16:33:16 | brixen | everything that is done has new specs |
| 16:33:36 | brixen | so you can look at spec/ruby/core/array/pack/* and spec/ruby/core/string/unpack/* |
| 16:47:46 | evan | hm, i'd really like a C parser as a ruby library. |
| 16:48:15 | evan | there is the weird gcc-xml thingy |
| 16:49:54 | brixen | could we wrap clang in FFI? |
| 16:51:14 | evan | i'd just use rbgccxml if i was going to do that. |
| 17:07:27 | dbussink | evening peeps |
| 17:08:04 | dbussink | brixen: you accidently hit #450? |
| 17:09:03 | brixen | dbussink: come again? |
| 17:09:24 | dbussink | brixen: just curious how you found that :) |
| 17:12:51 | brixen | I had a signed value (-4) passed as a size_t due to a boundary error in unpack |
| 17:13:07 | brixen | String.pattern(-4, 0) will do it though :) |
| 17:16:08 | evan | brixen: oh, on that. |
| 17:16:29 | evan | ByteArray::create should bounds check the size |
| 17:16:45 | evan | align has that issue, yes, but it shouldn't be fixed in align. |
| 17:18:30 | dbussink | shouldn't String::create also check whether the value is sane? |
| 17:18:33 | dbussink | and not for example < 0 ? |
| 17:18:48 | dbussink | otherwise it will try to allocate a huge bytearray, since it's already casted to a size_t at that point |
| 17:19:36 | dbussink | for allocating a string with a negative size that is |
| 17:20:41 | brixen | dbussink: that would be fixed with the bounds check in bytearray |
| 17:21:00 | brixen | evan: ok, that was the most reasonable solution |
| 17:21:17 | dbussink | brixen: true, but just wondering whether it should be checked there too |
| 17:21:20 | brixen | evan: what do you think about not using memset in BA creation |
| 17:21:29 | evan | could give it a shot. |
| 17:21:41 | brixen | ok, I'll audit that |
| 17:22:26 | dbussink | brixen: it would be fixed with a signed upper bound i guess yeah |
| 17:22:40 | dbussink | does mri have a limit on string length? |
| 17:23:01 | brixen | of course |
| 17:24:42 | brixen | evan: I have a repro for #411 (PackedObject as Module TypeError) |
| 17:25:03 | brixen | evan: time for a call? I have a bunch of questions so I can write docs for PackedObject |
| 17:25:10 | evan | sure. |
| 17:25:14 | brixen | k |
| 17:25:21 | brixen | http://gist.github.com/557721 |
| 17:25:25 | brixen | call whenever |
| 17:26:11 | evan | what is this doc? |
| 17:26:20 | evan | i mean, i see what it details |
| 17:26:30 | evan | but... any particular reason why? |
| 17:26:32 | brixen | it's the basis of various questions |
| 17:26:38 | brixen | so we can discuss |
| 17:26:49 | evan | k |
| 17:27:02 | brixen | the repro is: create a vanilla rails 2.1.2 app, then run http://gist.github.com/557724 |
| 17:31:12 | brixen | http://gist.github.com/557731 |
| 17:37:25 | brixen | http://gist.github.com/557740 |
| 17:45:56 | brixen | http://gist.github.com/557746 |
| 17:48:02 | srbaker | Defiler: ping |
| 17:48:17 | srbaker | Defiler: aware of a change in ruby 1.8 that changes how objects are calculated, assigned, managed, etc? |
| 17:48:38 | brixen | #<MetaClass:Class <some object>:0x5175dd0> |
| 17:49:48 | srbaker | hrm |
| 17:50:09 | srbaker | i've got a test suite that passes on 1.8.7pl72 and fails on 1.8.7pl306 (i think, it's in the low 300s) |
| 17:50:20 | srbaker | with no real explanation why. the only diffs are object ids. |
| 17:50:33 | srbaker | and wilson mentioned some weirdness while we were beer and hotdogging in NYC |
| 17:51:10 | brixen | "a test suite"? |
| 17:51:22 | srbaker | yeah, the test suite for our app |
| 17:51:23 | brixen | do you mean something unrelated to rbx or rubyspec? |
| 17:51:27 | brixen | ahh ok |
| 17:51:35 | srbaker | yes. sorry, i was just talking about it here because i know Defiler to hang out here |
| 17:51:52 | brixen | hm, no idea off hand |
| 17:52:51 | srbaker | i want to avoid the situation with this codebase that we had when i worked at postrank |
| 17:53:15 | srbaker | at postrank, the code was so shit, full of bugs, and dependency on bugs, they passed around a VirtualBox VM that you were expected to SSH into and develop on |
| 17:54:45 | BrianRice-work | :o |
| 17:54:52 | srbaker | i wish i was joking |
| 17:56:04 | srbaker | when i first started here at goldstar, we had to custom compile ruby, and it had to be a very specific patchlevel of 186. |
| 17:56:11 | srbaker | but we've moved past that |
| 18:00:28 | srbaker | ah, the diff is @name. |
| 18:00:29 | srbaker | weird |
| 18:02:42 | srbaker | in fact, here's the outptu |
| 18:03:04 | srbaker | http://pastie.org/private/ctfokwo7c5yojhprmwwuda |
| 18:03:11 | srbaker | can you see if that looks simple to you? |
| 18:03:16 | srbaker | that test passes on several other machiens |
| 18:11:50 | brixen | are you saying you have tests with embedded object_id values? |
| 18:15:24 | dwaite | brixen: are you trying to imply object_id's aren't portable? :D |
| 18:15:38 | brixen | heh |
| 18:16:08 | brixen | I'm wondering if I need to link to evan's *facepalm* pics |
| 18:17:45 | evan | brixen: http://skitch.com/evanphx/n6hid/cam |
| 18:18:07 | brixen | I should hot link that to something |
| 18:18:21 | brixen | oh, I know! http://github.com/dwaite/mac-text-substitutions |
| 18:18:25 | dwaite | noooo |
| 18:18:27 | brixen | I'll create a txt sub |
| 18:18:36 | dwaite | I like my little project |
| 18:18:44 | brixen | dwaite: did you get some good drugs for your foot? |
| 18:18:54 | dwaite | anti-inflammatories |
| 18:18:58 | evan | brixen: i'd use http://img.skitch.com/20100830-jy18jeatteyt8ydai6ee5xe36g.png |
| 18:19:06 | evan | if you want to hot link it. |
| 18:19:21 | brixen | ok |
| 18:19:45 | dwaite | will take one soon |
| 18:20:01 | brixen | dwaite: if only they made those for egos :) |
| 18:20:27 | dbussink | evan: that even embeds in linkinus :P |
| 18:20:34 | evan | dbussink: limechat too! |
| 18:20:40 | brixen | dwaite: not that you need it, just saying |
| 18:20:50 | dwaite | brixen: yeah, I wouldn't mind an anti-inflammatory that worked on other people's forum posts and blog comments |
| 18:21:32 | dwaite | brixen: you and evan keep me humble |
| 18:22:05 | dwaite | shame the anti-inflammatory isn't the sort of drug that will give me more small hack project ideas |
| 18:23:18 | dwaite | I forgot how fun it can be to go from idea to done on a sunday night |
| 18:24:55 | brixen | yeah, that is fun |
| 18:25:11 | evan | brixen: worked on marlowe a bit yesterday |
| 18:25:25 | brixen | sweet |
| 18:25:28 | evan | i've got the interpreter able to bind to external functions via FFI |
| 18:26:24 | brixen | nice! |
| 18:26:34 | dbussink | evan: hmm, no readme :) http://github.com/evanphx/marlowe |
| 18:27:35 | evan | :D |
| 18:28:10 | evan | i've been trying to balance the idea that marlowe is powerful enough to not require you to write in another language to write it's core classes at all |
| 18:29:34 | brixen | evan: but does it have web scale via /dev/null ? |
| 18:29:44 | evan | of course it's web scale. |
| 18:29:54 | evan | it uses atomic tokens to facility lock free computing! |
| 18:29:55 | brixen | that would be an important point in the readme or FAQ or both :) |
| 18:30:02 | evan | facilitate, rather. |
| 18:30:33 | dwaite | I like atomic tokens, so space-age |
| 18:30:52 | evan | sort of like nuclear clock radios |
| 18:37:05 | BrianRice-work | nuclear turbines |
| 18:37:43 | evan | atomic wristwatches |
| 18:43:17 | dbussink | evan: it's a typed language? |
| 18:43:24 | evan | yep |
| 18:43:41 | evan | it's a language you'd write a GC in. |
| 18:43:55 | evan | rich, static types. no memory management. |
| 18:47:11 | dbussink | evan: it generates some c code now? |
| 18:47:19 | evan | it will |
| 18:47:25 | evan | and/or LLVM LL |
| 18:47:36 | evan | but i'm mandating it also have an interpreter |
| 18:47:40 | evan | which is what i'm working on first. |
| 18:48:07 | evan | I want it to have an interpreter because i want there to be the ability to run code at compile time |
| 18:48:30 | bakkdoor | macros! =) |
| 18:48:49 | evan | :D |
| 18:49:13 | evan | yes, code macros, not just string substitution macros. |
| 18:49:27 | bakkdoor | cool :) |
| 18:50:00 | BrianRice-work | interesting |
| 18:50:00 | evan | it's a language to write a high level language in |
| 18:50:27 | evan | but that doesn't mean it has has to be a pain in the ass. |
| 18:50:31 | BrianRice-work | slate still has its C-level dialect (which flattens multimethods and infers types) |
| 18:50:40 | evan | nice |
| 18:50:59 | BrianRice-work | it isn't interpretable, though. I guess that'd be a fun project. |
| 18:51:13 | BrianRice-work | maybe a good reason to start leveraging llvm |
| 18:51:24 | evan | my interpreter is just a simple AST walker |
| 18:51:30 | evan | it's not meant to be performant. |
| 18:51:35 | evan | at least, not at this stage. |
| 18:51:37 | BrianRice-work | sure, just something cranked out |
| 18:51:42 | evan | yep. |
| 18:51:49 | evan | i'm pretty early on in the lang |
| 18:52:22 | evan | working out the best balance between modern conventions and lowlevel concerns |
| 18:54:43 | dwaite | as long as it has a string eval |
| 18:55:05 | evan | hah |
| 18:55:11 | evan | compile time string eval, sure. |
| 18:55:54 | dwaite | I've never tried to write C code with string eval |
| 18:55:55 | bakkdoor | =D |
| 18:56:13 | dwaite | (open new temp file, make shared library with gcc, load shared library) |
| 18:56:28 | evan | basically, in rbx, we do this stuff with autogenerating C++ code |
| 18:56:37 | evan | i want that to be in language with marlowe |
| 18:57:16 | dwaite | I had someone once try and explain code macros vs. text substitution macros to me |
| 18:57:25 | dwaite | but they had such a horrible lisp I really couldn't understand it |
| 18:57:32 | dwaite | Lisp, rather |
| 18:57:36 | evan | it's easy |
| 18:57:50 | evan | code macros are just methods that take other code as objects as arguments |
| 18:57:55 | dwaite | string manipulation vs. AST manipulation? |
| 18:57:59 | evan | yep |
| 18:59:23 | dwaite | yeah if only they had just said that |
| 18:59:32 | dwaite | instead they kept saying left-paren this, and right-paren that |
| 18:59:42 | evan | hah |
| 18:59:53 | evan | yes, lispers have a hard time seeing beyond the lisp sometimes. |
| 19:22:32 | BrianRice-work | as a lisper, I vaguely agree. slate macros are indeed methods on syntax node types |
| 19:24:00 | BrianRice-work | and the worst lisp code as a mature lisp user is the code you see other people writing when they talk about lisp but haven't used it in anger |
| 19:24:34 | evan | heh |
| 20:05:18 | boyscout | More FFI API merging. Support auto-offset calculation in Struct - 6e91c52 - Evan Phoenix |
| 20:06:39 | BrianRice-work | dwaite: out of curiosity, which horrible lisp was this? maybe elisp or autolisp |
| 20:14:55 | boyscout | CI: rubinius: 6e91c52 successful: 3522 files, 15298 examples, 43156 expectations, 0 failures, 0 errors |
| 20:44:01 | dbussink | brixen: you're post is already outdated ;) |
| 20:44:15 | dbussink | "with Ruby 1.9 due to be released shortly" |
| 20:56:59 | brixen | dbussink: blast it |
| 20:57:08 | brixen | such are the perils of corporate blogging... |
| 20:57:26 | dbussink | brixen: hehe, i can imagine you probably wrote it some time ago :) |
| 20:57:28 | brixen | my post edit cycle predates 1.9.2 release :( |
| 20:57:34 | dbussink | before hell froze over in the ruby world :0 |
| 20:57:35 | dbussink | :) |
| 20:57:54 | brixen | yes, I did not want to be typing frozen |
| 20:58:15 | brixen | since I seem to be inhabiting hell (ie rubyspecs for class variables) |
| 21:16:45 | boyscout | Check the number of bytes to allocate. Fixes #450. - 053d94c - Evan Phoenix |
| 21:19:56 | brixen | evan: I think an ArgumentError there with a reason would be better |
| 21:20:07 | brixen | I was working on specs for this (and the class var issues) :P |
| 21:20:07 | evan | ok |
| 21:20:13 | evan | oh sorry. |
| 21:20:16 | brixen | n/p |
| 21:20:19 | evan | feel free to change it |
| 21:20:21 | brixen | k |
| 21:26:40 | boyscout | CI: rubinius: 053d94c successful: 3522 files, 15298 examples, 43156 expectations, 0 failures, 0 errors |
| 21:56:15 | brixen | evan: what do you think of String::MAX_SIZE and Array::MAX_SIZE ? |
| 21:56:20 | brixen | I'd like to formalize this a bit |
| 21:56:27 | brixen | it's pretty haphazard now |
| 21:56:36 | evan | well, |
| 21:56:41 | evan | i'm not particularly in favor of them. |
| 21:56:49 | evan | how does one define what they are? |
| 21:56:56 | brixen | you just did for String |
| 21:57:08 | evan | so just pick some value? |
| 21:57:34 | evan | it would be ByteArray::MAX and Tuple::MAX |
| 21:57:35 | brixen | yes |
| 21:57:35 | evan | btw |
| 21:57:38 | evan | not String or Array |
| 21:57:55 | brixen | well, those are implementation details |
| 21:58:04 | brixen | I think it should be exposed on String and Array too |
| 21:58:06 | evan | then i'm against it |
| 21:58:07 | evan | no |
| 21:58:09 | evan | i don't think so. |
| 21:58:25 | evan | the size restriction is 100% implementation detail |
| 21:58:30 | brixen | so, some ruby code uses a random value and it works, another value and it fails |
| 21:58:34 | evan | ie, if we supported array ranges |
| 21:58:35 | brixen | and that's hidden |
| 21:58:42 | evan | we could allow for indexes in the trillions |
| 21:58:48 | evan | without actually allocating that much memory |
| 21:58:53 | evan | that would be perfectly legal |
| 21:58:59 | brixen | ok |
| 21:58:59 | evan | so the restriction is fully based on our implementation. |
| 21:59:06 | brixen | that's reasonable |
| 21:59:20 | brixen | but if we have the limit, which we absolutely do, it should be consistent |
| 21:59:26 | brixen | and visible somewhere |
| 21:59:37 | brixen | our Ruby code is not just user Ruby code |
| 21:59:39 | evan | my limit was not a real limit. |
| 21:59:51 | evan | thats more like a sentenal value |
| 22:00:23 | brixen | not exactly |
| 22:00:43 | brixen | our C++ code makes assumptions like size_t on the values it can pass to eg memset |
| 22:00:51 | evan | i don't believe your system would support a string with 2 billion chars |
| 22:00:56 | evan | so it's not a realy limit |
| 22:01:02 | evan | since it's unattainable. |
| 22:01:05 | brixen | if we changed the impl to ropes, there would be a different set of assumptions |
| 22:01:34 | brixen | ok, perhaps we need some definitions then |
| 22:01:42 | evan | for instance |
| 22:01:48 | evan | on my machine |
| 22:01:51 | brixen | because 1. we should not be able to segfault the vm, 2. we could very easily |
| 22:01:55 | evan | i'd have made that be INT64_MAX |
| 22:02:02 | evan | which is clearly an unattainable value |
| 22:02:10 | evan | and is thusly not a user limit. |
| 22:02:11 | brixen | sure, but whatever you set we could use to set the constant |
| 22:02:16 | brixen | Fixnum::MAX exists |
| 22:02:19 | brixen | should we remove that? |
| 22:02:31 | evan | I believe that Fixnum::MAX is entirely different. |
| 22:02:42 | brixen | how so? |
| 22:02:44 | evan | since that max value is fully attainable and used. |
| 22:03:02 | evan | it represents a maximum value that a user will actually see |
| 22:03:07 | evan | and could consider |
| 22:03:26 | evan | Array::MAX of 2 ** 64 doesn't represent a value the user is concerned with |
| 22:03:38 | evan | because it is unattainable. |
| 22:03:47 | brixen | I'm not concerned with the user |
| 22:03:49 | evan | under the current implementation |
| 22:03:49 | brixen | only |
| 22:03:59 | brixen | I'm concerned about not having these bugs |
| 22:04:15 | evan | exposing Array::MAX in ruby doesn't solve these bugs |
| 22:04:17 | evan | imgo. |
| 22:04:17 | brixen | by having formally defined limits based on the actual implementation |
| 22:04:18 | evan | imho. |
| 22:04:34 | evan | where would you use Array::MAX? |
| 22:04:36 | brixen | the value would be known in ruby and whatever is underneath |
| 22:04:44 | brixen | testing for one |
| 22:04:51 | evan | testing what? |
| 22:04:57 | evan | because you can't actually do |
| 22:05:02 | evan | a[Array::MAX-1] = nil |
| 22:05:06 | evan | and expect your machine to work |
| 22:05:08 | brixen | that I cannot segfault the vm with String.pattern(-1) |
| 22:05:14 | brixen | no |
| 22:05:15 | evan | given MAX is 2**64 |
| 22:05:22 | evan | the negative numbers is a different situation |
| 22:05:24 | brixen | that an exception is raised |
| 22:05:38 | evan | but not an exception based on the value of MAX |
| 22:05:54 | brixen | the negative becomes an out of bounds value due to being interpreted as a size_t |
| 22:06:04 | evan | specing that pattern doesn't support negative numbers i totally agree with |
| 22:06:13 | evan | and that we cast negatives into a giant positives is bad |
| 22:06:19 | evan | we should spec and fix all of those. |
| 22:06:33 | brixen | sure |
| 22:06:39 | evan | not allow those negatives to be giant positives, and then attempt to spec the giant positive value in a range. |
| 22:06:40 | brixen | but I'm still concerned with code in the vm |
| 22:07:35 | brixen | there should be a definitive set of constraints for bounds given the actual implementation |
| 22:07:44 | brixen | ByteArray, Tuple, Array indices, etc |
| 22:08:02 | evan | they apply only to ByteArray and Tuple though |
| 22:08:09 | evan | is my argument. |
| 22:08:21 | brixen | that's not true |
| 22:08:22 | evan | because those 2 classes mandate their implementation |
| 22:08:27 | evan | le sigh. |
| 22:08:30 | brixen | they apply to anything that accesses those |
| 22:08:36 | brixen | and that code is not easily isolated |
| 22:08:45 | brixen | not really a fan of le sigh here |
| 22:08:50 | evan | no, i know. |
| 22:08:51 | evan | sorry. |
| 22:08:56 | brixen | I spent time trying to figure out why that segfault existed |
| 22:09:05 | evan | yeah, you did. |
| 22:09:17 | evan | ok |
| 22:09:29 | evan | if you feel it's important to have Array::MAX and String::MAX, i guess thats fine |
| 22:09:32 | evan | should probably be |
| 22:09:36 | evan | MAX_SIZE though. |
| 22:09:49 | evan | Fixnum::MAX is the maximum value |
| 22:09:54 | evan | which makes no sense for Array |
| 22:09:57 | brixen | I honestly don't know the best approach |
| 22:10:06 | brixen | but I can give you the principles I'm concerned with |
| 22:10:18 | brixen | 1. it's consistent and knowable in both C++ and Ruby |
| 22:10:25 | brixen | even if only on our internal Ruby classes |
| 22:10:35 | brixen | 2. it's definitive and in one place |
| 22:10:56 | brixen | eg for the bounds of Tuple/ByteArray/Array indices |
| 22:11:00 | brixen | 3. it's doc'd :) |
| 22:11:26 | evan | i'm fine on all but /Array |
| 22:11:28 | evan | honestly. |
| 22:11:55 | brixen | ok, but our C++ code iterates elements in an Array |
| 22:11:57 | evan | my code was not an attempt to define a maximum size value |
| 22:12:02 | evan | at all. |
| 22:12:03 | brixen | and we have a @total attribute, tec |
| 22:12:10 | brixen | sure |
| 22:12:21 | brixen | I'm not arguing for a particular approach |
| 22:12:25 | brixen | I'm just concerned |
| 22:12:25 | evan | it was simply to clamp the input value to the range of the type being used. |
| 22:12:41 | evan | integer type |
| 22:13:00 | evan | i don't see where you'd use a maxmimum value when iterating an Array in C++ |
| 22:13:02 | brixen | yes, but these details are often subtle and distributed |
| 22:13:09 | evan | perhaps you could show me an example. |
| 22:13:13 | evan | to me, it's a number without use. |
| 22:13:22 | evan | and is therefore confusing. |
| 22:13:35 | brixen | well... |
| 22:13:38 | brixen | looks |
| 22:13:43 | brixen | Array::from_tuple uses size_t |
| 22:14:00 | brixen | Array::aref uses native_int |
| 22:14:02 | evan | so? |
| 22:14:07 | evan | i don't get what you mean |
| 22:14:15 | brixen | Array::concat uses size_t |
| 22:14:21 | brixen | so? |
| 22:14:23 | brixen | seriousl? |
| 22:14:26 | brixen | :( |
| 22:14:32 | evan | call me. |
| 22:14:32 | brixen | goes for a walk... |
| 22:15:25 | evan | my point was related to Array |
| 22:15:31 | evan | that all those backend with tuple |
| 22:15:35 | evan | so Tuple would clamp the value |
| 22:15:52 | evan | so a max size/index on Tuple does make sense. |
| 22:30:23 | rue | Strictness and defensiveness in type usage is valuable. |
| 22:31:36 | rue | As is clear and consistent type policy. If Array is dependent on Tuple, it ought be so constructed |
| 23:16:07 | boyscout | Deal with being interrupted while writing better. Fixes #373. - 569e69f - Evan Phoenix |
| 23:16:09 | evan | fuck yeah. finally got that signal spam bug fixed. |
| 23:16:21 | brixen | nice |
| 23:16:51 | evan | MRI handles signal handlers so weirdly |
| 23:17:20 | evan | if it can, it evaluates the ruby code for the signal FROM WITHIN the C signal handler function. |
| 23:17:47 | evan | which is not all the time. |
| 23:19:08 | brixen | crazy |
| 23:19:37 | brixen | I was taught to do the minimum possible in the handler and get out |
| 23:25:59 | boyscout | CI: rubinius: 569e69f successful: 3522 files, 15298 examples, 43156 expectations, 0 failures, 0 errors |
| 23:27:00 | evan | boyscout: yeah, thats the proper way. |
| 23:27:02 | evan | running ruby code is scary. |