Show enters and exits. Hide enters and exits.
| 00:03:41 | headius | evan: whatcha seein |
| 00:17:27 | jbarnette leaves the room. | |
| 00:17:53 | NoKarma leaves the room. | |
| 00:18:09 | nari leaves the room. | |
| 00:32:56 | qrush_ leaves the room. | |
| 00:35:44 | lopex leaves the room. | |
| 00:41:21 | dysinger enters the room. | |
| 00:43:26 | dysinger leaves the room. | |
| 00:43:34 | dysinger enters the room. | |
| 01:02:07 | benburkert_ enters the room. | |
| 01:02:12 | headius leaves the room. | |
| 01:18:30 | benburkert leaves the room. | |
| 01:20:44 | nari enters the room. | |
| 01:27:46 | jicksta enters the room. | |
| 01:30:38 | wmoxam enters the room. | |
| 01:30:58 | michalw leaves the room. | |
| 01:35:10 | jtoy enters the room. | |
| 01:37:02 | cored leaves the room. | |
| 01:37:49 | imajes_ enters the room. | |
| 01:41:03 | nari leaves the room. | |
| 01:42:56 | nari enters the room. | |
| 01:58:12 | benny leaves the room. | |
| 02:05:16 | guitsaru leaves the room. | |
| 02:12:58 | dysinger leaves the room. | |
| 02:13:38 | moofbong enters the room. | |
| 02:14:39 | lstoll enters the room. | |
| 02:16:59 | brapse enters the room. | |
| 02:20:49 | ezmobius leaves the room. | |
| 02:26:07 | jbarnette enters the room. | |
| 02:27:33 | jackdempsey leaves the room. | |
| 02:33:05 | pauldix enters the room. | |
| 02:41:23 | jackdempsey enters the room. | |
| 02:43:48 | nari leaves the room. | |
| 02:47:11 | cremes enters the room. | |
| 02:50:23 | nari enters the room. | |
| 02:52:55 | Defiler | Anyone know what I'm doing wrong here? http://pastie.org/251089.txt |
| 03:10:13 | imajes leaves the room. | |
| 03:11:15 | lchin enters the room. | |
| 03:39:37 | jbarnette | Defiler: you still seeing the behavior you pastied? 'cause I'm getting that on "rake vm" with a fresh checkout |
| 03:46:20 | pauldix leaves the room. | |
| 03:49:07 | Defiler | Yep |
| 03:49:13 | Defiler | Still getting it, even after a distclean |
| 03:49:17 | Defiler | time to look and see what broke it heh |
| 03:49:26 | Defiler | thanks for verifying that it happens on a fresh checkout |
| 03:56:52 | Defiler | aah, I see what it is |
| 03:58:07 | moofbong leaves the room. | |
| 03:58:30 | CIA-20 | * A comment for String::apply_and; 6524cab - Wilson Bilkovich |
| 03:58:31 | CIA-20 | * Change LLVM_STYLE back to 'Release'; 9541ea8 - Wilson Bilkovich |
| 03:58:47 | Defiler | oh, forgot I had that other commit on that branch hah |
| 03:59:06 | Defiler | jbarnette: Try building it with that change |
| 04:00:33 | jbarnette | Defiler: good to go :) |
| 04:01:15 | jbarnette | ...assuming the assertion failure in test_channel is a known thing |
| 04:01:29 | Defiler | Probably |
| 04:01:40 | Defiler | Let me see if it looks familiar. heh |
| 04:01:49 | Defiler | (by running them here) |
| 04:01:54 | jbarnette | chan->waiting->empty_p |
| 04:02:34 | Defiler | Hrm. No test failures here |
| 04:02:56 | jbarnette | O.o |
| 04:03:02 | jbarnette | damned sunspots |
| 04:04:05 | Defiler | maybe try suffering through a rake clean? =( |
| 04:04:24 | jbarnette | already started the pain |
| 04:09:25 | benburkert enters the room. | |
| 04:26:08 | benburkert_ leaves the room. | |
| 04:31:26 | nari leaves the room. | |
| 04:34:47 | mernen leaves the room. | |
| 04:35:26 | edwardam enters the room. | |
| 04:36:00 | keisukefukuda enters the room. | |
| 04:36:46 | blakewatters leaves the room. | |
| 04:38:24 | obvio171 leaves the room. | |
| 04:52:42 | jbarnette | Defiler: weird, same failure. guess I should actually look at the test |
| 04:58:46 | nari enters the room. | |
| 05:01:12 | benburkert leaves the room. | |
| 05:02:24 | Defiler | jbarnette: What OS is this on again? |
| 05:02:35 | jbarnette | Defiler: os/2 warp |
| 05:02:37 | jbarnette | erm |
| 05:02:41 | jbarnette | OS X |
| 05:02:53 | jbarnette | OS X/x86 |
| 05:04:12 | Defiler | hah |
| 05:07:27 | ryanlowe leaves the room. | |
| 05:08:51 | ezmobius enters the room. | |
| 05:31:15 | benny enters the room. | |
| 05:32:47 | benburkert enters the room. | |
| 05:44:24 | aotearoa enters the room. | |
| 05:48:05 | RyanTM leaves the room. | |
| 05:51:29 | antares leaves the room. | |
| 05:55:00 | gnufied leaves the room. | |
| 06:04:57 | jackdempsey leaves the room. | |
| 06:12:16 | jbarnette leaves the room. | |
| 06:15:07 | trythil enters the room. | |
| 06:34:06 | wmoxam leaves the room. | |
| 06:37:09 | blakewatters enters the room. | |
| 07:11:33 | dysinger enters the room. | |
| 07:18:38 | thehcdreamer enters the room. | |
| 07:28:27 | BobFunkasdas enters the room. | |
| 07:37:19 | thehcdreamer leaves the room. | |
| 07:38:05 | keisukefukuda leaves the room. | |
| 07:39:16 | blakewatters leaves the room. | |
| 07:40:58 | blakewatters enters the room. | |
| 07:54:22 | blakewatters leaves the room. | |
| 08:02:19 | Fullmoon leaves the room. | |
| 08:02:49 | Fullmoon enters the room. | |
| 08:03:34 | dbussink | morning |
| 08:12:12 | evan | hey there. |
| 08:13:32 | keisukefukuda enters the room. | |
| 08:17:09 | dbussink | evan: ah, i have a question for you :) |
| 08:17:25 | evan | sure, wassup? |
| 08:17:53 | dbussink | i was wondering, what's your opinion on changing mp_get_int in libtommath so it doesn't clip stuff at 32 bit? |
| 08:18:04 | dbussink | because it could make our bignum code a lot cleaner |
| 08:18:08 | BlackEdder enters the room. | |
| 08:18:20 | dbussink | and it's pretty much the only place where it's done |
| 08:18:30 | evan | I thought we already made that change |
| 08:18:34 | dbussink | nope |
| 08:18:42 | evan | well, mp_get_int has to clip it somewhere |
| 08:18:43 | dbussink | but if there's no objection, i'm gonna change it ;) |
| 08:18:58 | dbussink | why? because our native_int matches their internal representation |
| 08:19:02 | dbussink | and that's a long |
| 08:19:06 | evan | no no |
| 08:19:08 | evan | i mean |
| 08:19:08 | dbussink | which is the same as our native_int |
| 08:19:17 | evan | you can't represent the contents of a mp entirely as a long |
| 08:19:25 | evan | you have to decide to only put some many bits in |
| 08:19:28 | dbussink | yeah ok |
| 08:19:30 | evan | so what do you want to change it to? |
| 08:19:35 | dbussink | to nothing |
| 08:19:42 | evan | you.. can't. |
| 08:19:43 | dbussink | so it gets the lower long |
| 08:19:45 | evan | you have to clip it to something |
| 08:19:59 | evan | so you want to clip it to a long instead of an int? |
| 08:20:02 | benburkert leaves the room. | |
| 08:20:04 | dbussink | yeah |
| 08:20:14 | dbussink | because their internal mp_digit has that size |
| 08:20:17 | dbussink | and our native_int too |
| 08:20:22 | evan | why not clip it to exactly the number of bits our Fixnum is? |
| 08:20:27 | evan | 29 |
| 08:20:32 | dbussink | 28 / 60 |
| 08:20:36 | evan | i guess, i don't understand. |
| 08:20:36 | dbussink | but yeah, that could be done too |
| 08:20:48 | evan | i don't see what doing long versus int buys us |
| 08:20:58 | evan | but if you think it's important, go for it. |
| 08:20:59 | dbussink | 64 bit platform issues |
| 08:21:08 | dbussink | because they are different there |
| 08:21:21 | evan | i'd prefer you write a new function |
| 08:21:29 | evan | mp_get_dbussink_number() |
| 08:21:33 | evan | or something :) |
| 08:21:36 | jackdempsey enters the room. | |
| 08:21:44 | dbussink | yeah, that could be done |
| 08:22:14 | evan | i'd prefer that to changing the meaning of mp_get_int |
| 08:23:42 | dbussink | yeah, mp_get_native_int |
| 08:23:45 | dbussink | something like that |
| 08:24:23 | keisukef_ enters the room. | |
| 08:24:54 | benburkert enters the room. | |
| 08:25:02 | Arjen_ enters the room. | |
| 08:26:05 | evan | sure. |
| 08:26:18 | krsh enters the room. | |
| 08:27:03 | keisukefukuda leaves the room. | |
| 08:30:09 | trythil_ enters the room. | |
| 08:30:32 | trythil leaves the room. | |
| 08:32:14 | Fullmoon leaves the room. | |
| 08:37:14 | trythil_ leaves the room. | |
| 08:41:53 | Fullmoon enters the room. | |
| 08:55:17 | brapse leaves the room. | |
| 08:55:58 | octopod enters the room. | |
| 09:01:59 | wvdschel leaves the room. | |
| 09:15:52 | Fullmoon leaves the room. | |
| 09:30:08 | jackdempsey leaves the room. | |
| 09:31:10 | yugui enters the room. | |
| 09:37:00 | aotearoa leaves the room. | |
| 09:42:34 | thehcdreamer enters the room. | |
| 09:45:34 | thehcdreamer leaves the room. | |
| 09:59:31 | benburkert leaves the room. | |
| 10:00:06 | thehcdreamer enters the room. | |
| 10:08:45 | Maledictus enters the room. | |
| 10:17:23 | ezmobius leaves the room. | |
| 10:20:52 | imajes enters the room. | |
| 10:21:25 | chris2 enters the room. | |
| 10:26:21 | aotearoa enters the room. | |
| 10:28:07 | imajes_ leaves the room. | |
| 10:47:53 | Arjen_ leaves the room. | |
| 11:07:46 | lchin leaves the room. | |
| 11:09:36 | jtoy leaves the room. | |
| 11:26:18 | mutle_ enters the room. | |
| 11:26:50 | lchin enters the room. | |
| 11:27:34 | mutle leaves the room. | |
| 11:34:49 | lchin leaves the room. | |
| 11:37:30 | krsh leaves the room. | |
| 11:44:43 | aotearoa leaves the room. | |
| 11:49:58 | chris2 leaves the room. | |
| 12:44:46 | antares_ enters the room. | |
| 13:00:13 | yugui leaves the room. | |
| 13:00:58 | jicksta leaves the room. | |
| 13:05:29 | jicksta enters the room. | |
| 13:22:22 | jicksta leaves the room. | |
| 13:38:16 | keisukef_ leaves the room. | |
| 13:41:12 | robin_dewd_ leaves the room. | |
| 13:52:44 | thehcdreamer leaves the room. | |
| 14:01:19 | robin_dewd enters the room. | |
| 14:05:02 | edwardam leaves the room. | |
| 14:17:19 | mib_pwf0ge enters the room. | |
| 14:31:34 | atmos leaves the room. | |
| 14:35:19 | atmos enters the room. | |
| 14:37:15 | binary42 leaves the room. | |
| 14:37:36 | nari leaves the room. | |
| 14:40:54 | moofbong enters the room. | |
| 14:41:06 | wyhaines enters the room. | |
| 14:49:21 | dysinger leaves the room. | |
| 14:52:36 | michalw enters the room. | |
| 15:02:46 | botanicus enters the room. | |
| 15:08:21 | thehcdreamer enters the room. | |
| 15:08:28 | binary42 enters the room. | |
| 15:15:23 | Defiler | dbussink: I added an 'mp_get_long' or something long ago for that reason. It should still be there. |
| 15:15:40 | dbussink | Defiler: ah, maybe i should look for that then somewhere |
| 15:15:45 | dbussink | do you where you put it? |
| 15:17:57 | Defiler | dbussink: sec |
| 15:18:39 | Defiler | dbussink: aah.. I was thinking of e53047bc1b5a890f9fe8de4c |
| 15:18:44 | Defiler | where I added 'mp_set_long' |
| 15:18:48 | Defiler | vs. get long |
| 15:19:00 | dbussink | ah ok, well, we'll probably want a get_long version too then |
| 15:19:11 | dbussink | because with that the bignum code can be cleaned up another tad |
| 15:19:12 | Defiler | Yeah, that sounds fine to me |
| 15:19:42 | Defiler | I didn't want to teach libtommath about native_ints, because they are signed |
| 15:19:57 | thehcdreamer leaves the room. | |
| 15:21:43 | octopod_ enters the room. | |
| 15:26:29 | octopod leaves the room. | |
| 15:26:54 | botanicus_ enters the room. | |
| 15:29:37 | nari enters the room. | |
| 15:50:39 | pauldix enters the room. | |
| 15:52:44 | chris2 enters the room. | |
| 15:54:53 | atmos leaves the room. | |
| 15:55:10 | atmos enters the room. | |
| 15:55:43 | botanicus leaves the room. | |
| 15:57:02 | benburkert enters the room. | |
| 15:58:21 | antares_ leaves the room. | |
| 16:00:15 | krsh enters the room. | |
| 16:01:06 | blakewatters enters the room. | |
| 16:02:34 | jackdempsey enters the room. | |
| 16:11:16 | shayarnett enters the room. | |
| 16:16:14 | jackdempsey leaves the room. | |
| 16:19:08 | enebo enters the room. | |
| 16:22:48 | nicksieger enters the room. | |
| 16:22:57 | thehcdreamer enters the room. | |
| 16:23:00 | jackdempsey enters the room. | |
| 16:24:42 | shayarnett leaves the room. | |
| 16:36:35 | guitsaru enters the room. | |
| 16:40:50 | jackdempsey leaves the room. | |
| 16:44:45 | AndrewO enters the room. | |
| 16:47:29 | lopex enters the room. | |
| 16:50:27 | dbussink | Defiler: what do you think of all the to_int / to_i / to_nint stuff in bignum? |
| 16:50:32 | dbussink | i'd like to clean it up a bit |
| 16:51:03 | Defiler | I can't say it is my favorite part, but we do have a legitimate need for various kinds of conversion |
| 16:51:13 | Defiler | We should look and see where each is used, I suppose |
| 16:51:19 | dbussink | of course, but the naming seems a bit sometimes |
| 16:51:36 | dbussink | sometimes int means native_int, sometimes not |
| 16:52:07 | Defiler | Oh man don't get me started |
| 16:52:29 | Defiler | We should ban the letter 'n' from these function names |
| 16:52:33 | dbussink | hehe |
| 16:52:41 | Defiler | So ambiguous |
| 16:52:44 | dbussink | yeah |
| 16:52:45 | botanicus_ leaves the room. | |
| 16:52:48 | dbussink | and what about int? |
| 16:52:52 | Defiler | same, yeah |
| 16:53:00 | dbussink | to_int, do you expect a native_int or an int? |
| 16:53:05 | dbussink | or should it be to_native_int |
| 16:53:08 | Defiler | to_numeric was vetoed when I proposed it |
| 16:53:13 | Defiler | because it was 'too much to type' |
| 16:53:38 | dbussink | typing a bit extra is not a problem if it removes insanity :) |
| 16:53:41 | Defiler | template <> { public public static public volatile concept_map SquizzList is so short |
| 16:53:47 | Defiler | I can see why to_numeric would be cast down |
| 16:54:45 | dbussink | well, numeric can create confusion with ruby's numeric |
| 16:54:52 | dbussink | i can see that as an objection |
| 16:54:57 | Defiler | So, I think to_numeric and to_native (or to_native_int, etc) should be the names |
| 16:55:12 | Defiler | no, to_numeric would be the one that returned a subclass of Numeric |
| 16:55:15 | Defiler | e.g. Bignum or Fixnum |
| 16:55:26 | Defiler | so it would return Object* |
| 16:55:28 | dbussink | to_integer perhaps then? |
| 16:55:32 | dbussink | and to_native_int |
| 16:55:32 | dbussink | ? |
| 16:55:36 | Defiler | Sure |
| 16:55:53 | dbussink | i've added back the set and get from long now |
| 16:56:09 | evan | what would to_numeric return? |
| 16:56:10 | Defiler | though I think to_native is an easier sell, personally |
| 16:56:12 | Defiler | a numeric |
| 16:56:20 | evan | what is a numeric? |
| 16:56:26 | Defiler | a ruby object representing a number |
| 16:56:31 | dbussink | well, i would use to_integer there |
| 16:56:37 | Defiler | Just trying to think of words that have no meaning in C++ |
| 16:56:38 | dbussink | because it's actually an Integer object |
| 16:56:43 | evan | so, to_numeric == Object::i2n |
| 16:57:17 | Defiler | The 'i' in i2n means 'native int', and the n means what again? |
| 16:57:18 | evan | well, we could just mirror the ruby API |
| 16:57:24 | evan | and have a function called Integer() |
| 16:57:42 | dbussink | well, i don't see that being used in Bignum now |
| 16:57:44 | Defiler | I personally really like these being member functions, rather than macros or other weirdness |
| 16:57:56 | dbussink | most of the annoyance i have is with the int / native_int confusion |
| 16:58:04 | evan | Defiler: you can't have member functions on 'int' or 'native_int' |
| 16:58:07 | Defiler | Yeah, I know |
| 16:58:08 | evan | they're not objects. |
| 16:58:12 | Defiler | Not until C++0x at least ha ha |
| 16:58:53 | Defiler | Maybe I am just slow, but I constantly have to remind myself which is which between i2n and n2i |
| 16:59:06 | evan | they're not in the same places |
| 16:59:07 | Defiler | Because I think 'native_int' when I think of what I want an inward-facing function to return |
| 16:59:15 | evan | so i'm sure it's caught quickly |
| 16:59:24 | Defiler | Sure. It doesn't introduce bugs, just new tabs in vim |
| 17:00:32 | Defiler | We are so big on naming things clearly (LookupTable instead of rbxlt or something mad), that the three-letter converters stand out as being relatively hard to read |
| 17:01:03 | danlucraf1 enters the room. | |
| 17:02:15 | evan | ok, so what should Object::i2n() be renamed to? |
| 17:02:38 | evan | takes a signed int, returns an Integer |
| 17:03:20 | dbussink | well, it works for me a lot better in the cpp vm |
| 17:03:36 | dbussink | because seeing Object:: triggers me into "ok, we're not working on an object" |
| 17:03:44 | dbussink | contrary to ->i2n() |
| 17:04:05 | evan | Defiler: it'n n2i() |
| 17:04:07 | evan | hah |
| 17:04:11 | evan | but yeah. |
| 17:04:17 | headius enters the room. | |
| 17:04:21 | evan | i've fine changing them |
| 17:04:27 | evan | it's a pretty simple refactoring job |
| 17:04:28 | dbussink | that makes a huge difference imho compared to I2N() and N2I() in shotgun |
| 17:06:09 | Defiler | evan: so, n2i is meant to be 'native to Integer', just to confirm |
| 17:06:18 | Defiler | and i2n is convert self (an Integer) to a native_int |
| 17:06:19 | evan | no |
| 17:06:34 | evan | and no. |
| 17:06:38 | Defiler | Oh, you were correcting dbussink not yourself |
| 17:06:41 | evan | you've got them bacwards. |
| 17:06:46 | evan | Defiler: yeah |
| 17:06:57 | Defiler | OK, yeah, then I had it right before, just reverse what I just said. Heh |
| 17:07:29 | Defiler | So I don't understand the i2n name at all, then |
| 17:07:52 | Defiler | int to numeric? |
| 17:09:17 | evan | yes |
| 17:09:33 | Defiler | static Object::to_integer and member functions Fixnum/Bignum::to_native perhaps? |
| 17:09:36 | evan | how about using caps? |
| 17:09:42 | evan | since they're gonig to be objects? |
| 17:09:45 | evan | i2N |
| 17:09:49 | evan | and N2i |
| 17:09:54 | evan | that looks pretty weird though |
| 17:10:05 | dbussink | i'm ok with Defiler's idea |
| 17:10:06 | Defiler | Yeah, looks weird, but it would be a little clearer than what we have now, amazingly. :) |
| 17:10:30 | Defiler | I am totally open to other ideas for what to call 'to_native', but it does return a native_int so it makes sense to me |
| 17:10:43 | Defiler | It's not like you can work on the VM without knowing what a native_int is anyway |
| 17:10:44 | dbussink | or Integer.from_native() |
| 17:10:48 | dbussink | and to_native() |
| 17:10:50 | Defiler | Ooh |
| 17:11:17 | dbussink | Integer.from_long_long |
| 17:11:18 | Defiler | I like that |
| 17:11:23 | dbussink | or whatever you want |
| 17:11:57 | Defiler | No great reason for it to be on Object anyway, right? |
| 17:12:06 | Defiler | Integer reads nicely |
| 17:12:12 | dbussink | yeah, that was my thinking too |
| 17:12:13 | evan | sure |
| 17:12:18 | dbussink | and we already have an Integer object |
| 17:12:26 | evan | but lets use C++ |
| 17:12:32 | evan | we only need one |
| 17:12:38 | evan | with multiple signatures |
| 17:12:52 | evan | thats why i was suggesting Integer() |
| 17:12:55 | Defiler | static Integer::from_native(native_int val) |
| 17:13:02 | Defiler | but yeah, I see what you mean there |
| 17:13:07 | dbussink | i like the overloading actually yeah |
| 17:13:09 | Defiler | because we kinda want static Integer::from_someting |
| 17:13:15 | evan | having a dozen from_* methods is dumb |
| 17:13:26 | evan | why not just from? |
| 17:13:28 | dbussink | evan: there are dozen of those on Object now ;) |
| 17:13:33 | Defiler | hot |
| 17:13:33 | evan | Integer::from(native_int i) |
| 17:13:40 | evan | Integer::from(int i) |
| 17:13:44 | evan | Integer::from(unsigned int i) |
| 17:13:44 | dbussink | yeah |
| 17:13:45 | dbussink | cool :) |
| 17:13:46 | Defiler | Integer::from(unsigned long long i) |
| 17:13:47 | Defiler | etc |
| 17:13:48 | Defiler | nice |
| 17:14:10 | dbussink | can you use a type as an argument in c++? |
| 17:14:17 | dbussink | we could do the same with to() then |
| 17:14:30 | evan | hm... |
| 17:14:30 | Defiler | Integer::to(TypeInfo destination_type) |
| 17:14:32 | Defiler | right? |
| 17:14:34 | evan | like how? |
| 17:14:55 | evan | you can as a template |
| 17:15:10 | Defiler | I guess we would need hardcore contravariant return types from that function |
| 17:15:11 | evan | if you make to a template function |
| 17:15:31 | evan | which would probably be ok |
| 17:15:33 | rudebwoy_ enters the room. | |
| 17:15:43 | evan | since it would just do a cast to the type they want. |
| 17:15:54 | Defiler | Hrm.. the return type would be something that wasn't a class, though |
| 17:15:57 | rudebwoy leaves the room. | |
| 17:16:06 | Defiler | How do you make a C++ function that can return an unsigned long or a native_int? |
| 17:16:07 | evan | Defiler: that actually doesn't matter |
| 17:16:15 | evan | you can pass any time as a template param |
| 17:19:32 | dbussink | maybe it's easiest to do it manually still, i dunno |
| 17:19:43 | dbussink | would it have any performance impact? |
| 17:19:51 | evan | dbussink: we'll be right back |
| 17:19:53 | Defiler | It would all be compile-time |
| 17:19:56 | evan | we've having a quick meeting |
| 17:20:04 | dbussink | ok |
| 17:21:21 | headius_ enters the room. | |
| 17:21:21 | headius leaves the room. | |
| 17:22:32 | wmoxam enters the room. | |
| 17:26:51 | thehcdreamer leaves the room. | |
| 17:28:53 | BobFunk enters the room. | |
| 17:29:20 | jayWHY enters the room. | |
| 17:29:25 | BobFunk leaves the room. | |
| 17:30:53 | benny leaves the room. | |
| 17:34:27 | michalw leaves the room. | |
| 17:35:18 | rudebwoy_ leaves the room. | |
| 17:44:52 | mib_pwf0ge leaves the room. | |
| 17:52:23 | gnufied enters the room. | |
| 17:53:08 | BobFunk enters the room. | |
| 17:54:09 | BobFunk leaves the room. | |
| 17:55:52 | thehcdreamer enters the room. | |
| 17:56:13 | thehcdreamer leaves the room. | |
| 17:58:41 | lopex leaves the room. | |
| 18:04:10 | krsh leaves the room. | |
| 18:05:39 | octopod_ leaves the room. | |
| 18:06:18 | chris2_ enters the room. | |
| 18:12:59 | chris2 leaves the room. | |
| 18:24:12 | ijcd enters the room. | |
| 18:24:29 | benburkert leaves the room. | |
| 18:24:45 | ryanlowe enters the room. | |
| 18:25:02 | c0sin enters the room. | |
| 18:26:45 | ijcd_ enters the room. | |
| 18:35:34 | dgtized | evan: gcc 4.2.3 is complaining about jumping over an initialization in context.cpp |
| 18:35:52 | evan | could ya paste the error? |
| 18:36:24 | dgtized | http://gist.github.com/4901 |
| 18:37:12 | evan | oh rm. |
| 18:37:14 | evan | hrm. |
| 18:37:23 | evan | need to just move the bytes declaration to the top |
| 18:38:12 | dgtized | yea I mean that fixes it |
| 18:38:57 | dgtized | I gather the goto's are from the squeak stuff directly? |
| 18:39:27 | evan | no |
| 18:39:41 | evan | just the simplest way to implement the logic I wanted |
| 18:40:45 | dgtized | k |
| 18:41:58 | CIA-20 | * moved initialization of variable bytes out of goto block to make the compiler happier; 5668296 - Charles Comstock |
| 18:42:03 | ijcd leaves the room. | |
| 18:48:23 | headius leaves the room. | |
| 18:48:51 | headius enters the room. | |
| 18:49:16 | headius leaves the room. | |
| 18:52:00 | jicksta enters the room. | |
| 18:52:31 | benburkert enters the room. | |
| 19:04:37 | guitsaru leaves the room. | |
| 19:12:30 | blakewatters leaves the room. | |
| 19:17:54 | bricolage enters the room. | |
| 19:19:46 | Arjen_ enters the room. | |
| 19:27:07 | BlackEdder enters the room. | |
| 19:27:21 | ezmobius enters the room. | |
| 19:30:52 | ijcd_ leaves the room. | |
| 19:37:47 | krsh enters the room. | |
| 19:37:50 | dgtized leaves the room. | |
| 19:37:56 | CIA-20 | * Add Context tests and ability to filter tests run. Set the env vars TEST and SUITE to filter which tests and suites are run. For instance, setting ...; d0399ec - Evan Phoenix |
| 19:37:57 | CIA-20 | * Add autotest hook output, activated with AUTO=1 Hooks for running cxxtest under autotest. Outputs --- F SuiteName::testname::file::line for a test ...; 9f6c3f2 - Evan Phoenix |
| 19:38:37 | evan | ok, you can now filter the C++ tests that are run using the SUITE and TEST env vars |
| 19:38:48 | viimrles leaves the room. | |
| 19:38:57 | evan | I got tired of waiting for 492 test to run everytime I changed something |
| 19:39:29 | dgtized enters the room. | |
| 19:40:50 | enebo leaves the room. | |
| 19:43:37 | brixen | sweet |
| 19:43:45 | dbussink | cool |
| 19:43:56 | evan | I added an autotest hook |
| 19:44:03 | evan | if someone wants to hook it up to autotest |
| 19:44:09 | evan | just set AUTO=1 |
| 19:44:10 | dbussink | my header skills are as always lacking, was trying to get that integer refactor going |
| 19:44:19 | evan | and it will print out easy to parse info about each test it runs |
| 19:44:50 | evan | oh, I was going to check something about template functions |
| 19:45:57 | dbussink | ah, no problem, go right ahead |
| 19:46:09 | dbussink | first step i was going to try was the Integer::from stuff |
| 19:47:40 | evan | so, we could have |
| 19:48:00 | evan | char blah = integer->to<char>(); |
| 19:48:13 | evan | that works |
| 19:48:58 | brixen | that's pretty clean |
| 19:49:10 | brixen | pointy, but clean :) |
| 19:49:14 | evan | heh |
| 19:49:49 | dbussink | looks nice :) |
| 19:53:53 | dbussink | ok, i'm just being plain dumb |
| 19:54:08 | dbussink | copy pasted a header conditional and didn't rename it |
| 19:58:09 | evan | I see a couple problems with out<>() |
| 19:58:33 | evan | it doesn't really tell you anything about what kinds of types you can pass into the <> |
| 19:58:49 | evan | maybe we don't care about that, just let them pass any thing they want, and expect them to know what they're doing |
| 19:59:47 | evan | where as ::to_int() self documents nicely. |
| 20:00:36 | dbussink | yeah, well, maybe we need it to be explicit |
| 20:00:53 | dbussink | because when i think of it, the implementations could be pretty different |
| 20:00:59 | brixen | the type should be fairly clear from context though |
| 20:01:17 | dbussink | in order to ensure correct behavior for different bitsizes and endianness |
| 20:01:47 | evan | well |
| 20:02:16 | evan | why not just have just have ->to_signed() and ->to_unsigned() |
| 20:02:41 | evan | or better, just 'native_int to_real()' |
| 20:02:42 | dbussink | on what? only those two? |
| 20:02:49 | evan | and require the caller to cast it to the type they need |
| 20:02:58 | evan | I mean, thats all that to<>() would do anyway |
| 20:03:15 | evan | pull it out as the best type, then cast it to what you asked for |
| 20:03:17 | dbussink | well, stuff like FFI could need something that is able to convert a bignum into a long long for example |
| 20:03:42 | evan | ah. |
| 20:03:43 | evan | ok. |
| 20:03:55 | evan | we'd have to get into template specialization to do that |
| 20:04:04 | evan | seems like we should just make it explicit |
| 20:04:18 | dbussink | yeah, probably we should indeed |
| 20:04:44 | evan | esp. in the case of long long |
| 20:04:51 | evan | since you can't ask a Fixnum to be a long long anyway |
| 20:05:00 | evan | so it's not really a property of Integer |
| 20:05:02 | evan | just of Bignum |
| 20:06:27 | dbussink | well, on 64 bit you can |
| 20:06:33 | michalw enters the room. | |
| 20:06:47 | dbussink | because long long is still 64 bit there |
| 20:07:33 | evan | hm. |
| 20:07:39 | dbussink | evan: http://gist.github.com/4921 |
| 20:07:42 | evan | but you wouldn't ever explicitly ask for that of a Fixnum |
| 20:07:42 | dbussink | that's for the from case |
| 20:07:47 | scoopr | hint: #include <stdint.h> -> int64_t |
| 20:07:48 | evan | because a 32bit platform can't deliver. |
| 20:08:05 | dbussink | evan: true, but you can if you don't know what it is |
| 20:08:16 | evan | huh? |
| 20:08:17 | larrytheliquid enters the room. | |
| 20:08:19 | dbussink | if you look at large file support for example |
| 20:08:19 | evan | that makes no sense to me |
| 20:08:29 | brixen | evan: should we be using SYMBOL in tests instead of Symbol*, or do you care? |
| 20:08:41 | dbussink | which uses long long which could turn into a Fixnum on 64 bit platforms |
| 20:08:43 | evan | so Fixnum::to_long_long on a 32platform would just be the 32bit value cast to a long long? |
| 20:09:00 | evan | brixen: probably best to use SYMBOL. |
| 20:09:04 | dbussink | yeah, i think it would be |
| 20:09:05 | brixen | evan: k |
| 20:09:06 | evan | just to be consistent |
| 20:09:14 | dbussink | purely consistency yeah |
| 20:09:23 | dbussink | everywhere the same behavior |
| 20:09:45 | evan | ok, well, don't forget |
| 20:09:51 | evan | if you put these methods on Integer |
| 20:09:58 | evan | you can't use virtual dispatch |
| 20:10:16 | dbussink | what i can see now is that everything except for converting to / from native_int is only really useful for ffi |
| 20:10:22 | dysinger enters the room. | |
| 20:10:23 | evan | either these methods go on Fixnum and Bignum seperately, and happen to have the same names |
| 20:10:36 | dbussink | evan: why can't they? |
| 20:10:39 | evan | or they go on Integer, and the Integer versions have to be made aware of it's subtypes |
| 20:10:54 | evan | dbussink: because we can not use virtual methods in builtin classes |
| 20:10:54 | dbussink | well, doesn't the code have to be already? |
| 20:11:06 | dbussink | also not if they are static? |
| 20:11:30 | evan | the to methods wont be static |
| 20:11:34 | evan | the from methods will be |
| 20:11:40 | dbussink | yeah ok, the to's wont be yeah |
| 20:11:40 | evan | perhaps we switched topics |
| 20:11:47 | dbussink | sorry for the confusion |
| 20:11:56 | dbussink | the from() should be fine though i think |
| 20:12:06 | evan | Sure. |
| 20:12:16 | evan | they all need to take STATE to though. |
| 20:12:29 | evan | otherwise you can't create Bignum's |
| 20:12:32 | dbussink | ah ok |
| 20:12:56 | ijcd enters the room. | |
| 20:13:02 | dbussink | because of the allocation that is isn't it? |
| 20:13:16 | evan | yep |
| 20:14:31 | enebo enters the room. | |
| 20:15:04 | evan | dbussink: right now, we have a Object::i2n() that doesn't take a STATE |
| 20:15:07 | ezmobius leaves the room. | |
| 20:15:10 | evan | it's used in a few places where we don't have state |
| 20:15:20 | evan | and we know that we just need a Fixnum (ie, no allocation) |
| 20:15:30 | evan | we should put a static method on Fixnum for that |
| 20:15:34 | dbussink | yeah |
| 20:15:38 | dbussink | Fixnum::from() |
| 20:15:43 | evan | yeah |
| 20:15:46 | dbussink | should be pretty explicit i think :) |
| 20:15:48 | evan | it doesn't need the massive overloading |
| 20:15:53 | evan | int is enough. |
| 20:15:59 | evan | the caller can cast if they need more. |
| 20:16:12 | dbussink | not native_int? |
| 20:16:19 | dbussink | would make more sense i think |
| 20:16:31 | evan | sure |
| 20:22:11 | evan | dbussink: hm, do we need all those forms of from() |
| 20:22:12 | evan | ? |
| 20:22:24 | dbussink | mwah, not really i think |
| 20:22:36 | dbussink | the char's and short's could be discarded |
| 20:22:42 | evan | yeah |
| 20:22:44 | dbussink | they go fine with just casting them when need |
| 20:22:46 | dbussink | needed |
| 20:22:52 | evan | exactly |
| 20:22:56 | evan | lets do that. |
| 20:23:06 | evan | btw, you don't need to put the code for these in headers |
| 20:23:14 | evan | throw them in .cpp files |
| 20:23:22 | evan | we can optimize them back into the headers later if we need to. |
| 20:23:53 | dbussink | i was putting it in a separate cpp file |
| 20:24:04 | dbussink | i also moved the numeric definition to the integer.hpp header |
| 20:24:10 | evan | sounds good. |
| 20:24:13 | dbussink | or do you have objections against that? |
| 20:24:23 | evan | nope |
| 20:27:19 | brixen | yay for SUITE |
| 20:27:26 | aemadrid enters the room. | |
| 20:27:49 | aemadrid | hey |
| 20:28:21 | aemadrid | having some troubles building rubinius on OSX PPC |
| 20:28:48 | aemadrid | anybody built it on PPC and can help me figure it out? |
| 20:29:33 | Yurik leaves the room. | |
| 20:32:00 | evan | aemadrid: what troubles are you having? |
| 20:33:39 | aemadrid | LINK librubinius-local-dev.dylib |
| 20:33:40 | aemadrid | ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 |
| 20:33:40 | aemadrid | make[2]: *** [librubinius-local-dev.dylib] Error 1 |
| 20:33:40 | aemadrid | make[1]: *** [lib/librubinius-0.9.0.dylib] Error 2 |
| 20:33:40 | aemadrid | make: *** [vm] Error 2 |
| 20:33:41 | aemadrid | rake aborted! |
| 20:33:50 | aemadrid | Command failed with status (2): [make vm...] |
| 20:33:51 | aemadrid | (See full trace by running task with --trace) |
| 20:33:53 | aemadrid | pastie is really slow right now |
| 20:34:05 | ezmobius enters the room. | |
| 20:34:21 | brixen | aemadrid: gist.github.com |
| 20:34:58 | ijcd leaves the room. | |
| 20:35:21 | aemadrid | sorry |
| 20:35:23 | aemadrid | http://gist.github.com/4926 |
| 20:35:33 | aemadrid | brixen: thx for the link |
| 20:36:00 | aemadrid | evan: it's osx 10.4 on a g5 ppc box |
| 20:36:23 | evan | aemadrid: run |
| 20:36:29 | evan | export MACOSX_DEPLOYMENT_TARGET=10.4 |
| 20:36:31 | evan | then try again |
| 20:36:50 | aemadrid | evan: do I need to make clean before? |
| 20:36:55 | evan | no |
| 20:37:35 | aemadrid | evan: cool, thx |
| 20:37:56 | aemadrid | lib/librubinius-0.9.0.dylib(single module) definition of ___hexnan_D2A |
| 20:39:08 | aemadrid | evan: bunches of this http://gist.github.com/4927 but it keeps going |
| 20:39:21 | BobFunk enters the room. | |
| 20:39:30 | evan | aemadrid: hm, |
| 20:39:33 | evan | perhaps try a 'rake clean' :) |
| 20:40:28 | aemadrid | evan: rake clean seems to have _cleaned_ everything, trying rake build again |
| 20:40:44 | evan | k. |
| 20:42:28 | aemadrid | evan: bunches of those warnings again http://gist.github.com/4928 |
| 20:42:44 | ijcd enters the room. | |
| 20:42:53 | aemadrid | evan: is gcc4.0 a problem? |
| 20:43:00 | evan | nope |
| 20:43:02 | evan | strange |
| 20:43:06 | evan | it warned, but kept going |
| 20:43:09 | evan | well, you should be fine. |
| 20:43:09 | aemadrid | weird |
| 20:43:13 | evan | we'll have to look into it |
| 20:43:18 | evan | would you open a ticket about this on lighthouse? |
| 20:43:25 | aemadrid | sure |
| 20:43:57 | evan | include the output from 'uname -a' and 'gcc --version' |
| 20:43:59 | evan | in the ticket. |
| 20:44:03 | aemadrid | the 10.1 souldn't be too hard to fix |
| 20:44:16 | aemadrid | any idea in which area I can look? |
| 20:44:20 | aemadrid | I will |
| 20:44:28 | evan | can look for what? |
| 20:45:09 | aemadrid | where it's doing 10.1 instead of 10.4 |
| 20:45:09 | tmornini enters the room. | |
| 20:45:11 | tmornini leaves the room. | |
| 20:45:36 | aemadrid | where it's setting MACOSX_DEPLOYMENT_TARGET to 10.1 instead of 10.4 |
| 20:45:49 | evan | thats really supposed to be set by you. |
| 20:45:54 | evan | thats why we don't set it anymore |
| 20:46:00 | aemadrid | ok |
| 20:46:05 | evan | we recommend people set that in their shell's rc file |
| 20:46:13 | evan | we used to set it |
| 20:46:16 | aemadrid | I thought it was figuring it out on it's own |
| 20:46:19 | evan | but don't anymore. |
| 20:46:43 | octopod enters the room. | |
| 20:46:49 | aemadrid | I guess it should be added to http://rubinius.lighthouseapp.com/projects/5089/getting-started |
| 20:47:03 | evan | ok. |
| 20:48:13 | aemadrid | or in INSTALL? |
| 20:48:19 | gilesgoatboy enters the room. | |
| 20:51:26 | evan | sure |
| 20:53:04 | brapse enters the room. | |
| 20:53:25 | evan | wow, vm_copy is a rad darwin function |
| 20:54:48 | Defiler | Hrm.. why do I see the docs for that online, but I don't appear to have a 'man vm_copy' |
| 20:56:05 | evan | no clue |
| 20:56:09 | evan | i guess because it's a mach function |
| 20:56:15 | evan | there aren't many man pages for mach functions |
| 20:56:31 | evan | it gives you copy-on-write memory at the kernel level |
| 20:58:36 | nicksieger leaves the room. | |
| 20:59:27 | aemadrid leaves the room. | |
| 20:59:33 | nicksieger enters the room. | |
| 20:59:56 | shayarnett enters the room. | |
| 21:00:24 | larrytheliquid leaves the room. | |
| 21:04:25 | chris2 leaves the room. | |
| 21:23:58 | joachimm leaves the room. | |
| 21:24:42 | joachimm enters the room. | |
| 21:24:46 | Maledictus leaves the room. | |
| 21:24:50 | joachimm leaves the room. | |
| 21:29:33 | joachimm enters the room. | |
| 21:31:24 | dfg59 enters the room. | |
| 21:31:52 | gilesgoatboy leaves the room. | |
| 21:39:35 | shayarnett leaves the room. | |
| 21:40:26 | yroc enters the room. | |
| 21:56:05 | CIA-20 | * Fix stack GC invariant When a context is activated, if it's mature, it's remembered. This keeps us from having to run the write barrier when the stack ...; dbe8229 - Evan Phoenix |
| 21:56:06 | CIA-20 | * Refactor context cache, fix semantics. Context cache now only recycles young contexts, like it should.; ee2c395 - Evan Phoenix |
| 21:56:23 | krsh leaves the room. | |
| 21:59:13 | gilesgoatboy enters the room. | |
| 22:04:16 | blakewatters enters the room. | |
| 22:06:06 | jbarnette enters the room. | |
| 22:11:46 | fbuilesv leaves the room. | |
| 22:18:19 | michalw leaves the room. | |
| 22:31:36 | brapse leaves the room. | |
| 22:35:07 | dbussink | evan, Defiler I've pushed the first step of the refactor |
| 22:35:22 | evan | cool |
| 22:35:22 | dbussink | all tests still work for me, but please check :) |
| 22:36:11 | wmoxam leaves the room. | |
| 22:36:26 | dbussink | need to add some nasty and insane tests for all the signed / unsigned etc. cases |
| 22:36:35 | dbussink | to verify they are 100% correct |
| 22:36:43 | dbussink | they now behave the same as they did |
| 22:36:57 | dbussink | but there aren't any specific tests for it as far as i can tell |
| 22:38:29 | dbussink | but i'm off to bed, late enough over here |
| 22:38:31 | dbussink | nite |
| 22:39:22 | brixen | night dbussink, and thanks :) |
| 22:40:58 | headius enters the room. | |
| 22:42:28 | brixen | things like this make static languages so much fun: hashval hash = str->hash_string(state); |
| 22:42:33 | brixen | talk about redundant info |
| 22:43:00 | brixen | evan: can I make static hashval String::hash_string and hasval String::hash ? |
| 22:43:23 | brixen | instead of hash_str for static and hash_string? |
| 22:43:31 | evan | well |
| 22:43:33 | evan | no |
| 22:43:34 | brixen | s/hasval/hashval/ |
| 22:43:36 | evan | because there is Object::hash |
| 22:43:42 | brixen | ahh, right |
| 22:43:42 | evan | and you can't shadow it in String |
| 22:43:47 | brixen | yep |
| 22:44:26 | brixen | I would say our C++ is cleaner, but definitely more obscure |
| 22:44:37 | brixen | or perhaps I just don't have it all in my head yet :P |
| 22:45:43 | CIA-20 | * Isolated access to SymbolTable behind VM methods.; 195ef1b - Brian Ford |
| 22:46:23 | brapse enters the room. | |
| 22:46:56 | brixen | I should get our rubuildus bots running the cpp tests |
| 22:50:03 | joachimm leaves the room. | |
| 22:52:59 | brixen | hmm, I really like the look of Fixnum::from(0) over Object::i2n(0) |
| 22:53:07 | moofbong leaves the room. | |
| 22:53:36 | evan | me too |
| 22:57:57 | evan | hrm |
| 22:57:59 | evan | broken dp |
| 22:58:00 | evan | dep |
| 22:58:14 | evan | dbussink's header change didn't cause instructions.o to get recompiled |
| 22:58:14 | dgtized | http://gist.github.com/4956 |
| 23:00:15 | dgtized | build is broken for me because of the above paste |
| 23:00:27 | evan | compiled fine for me. |
| 23:00:37 | lopex enters the room. | |
| 23:00:46 | evan | ack. |
| 23:00:50 | evan | fucking linux gcc! |
| 23:00:55 | evan | complains about newlines at the ends of files. |
| 23:01:07 | evan | means dbussink probably used textmate |
| 23:01:28 | drbrain | ha! that's no error! |
| 23:01:37 | evan | we have -Werror on |
| 23:01:38 | evan | though. |
| 23:02:06 | drbrain | that shouldn't even be a warning |
| 23:02:17 | dgtized | what the int -> native_int switch? |
| 23:02:19 | evan | I know. |
| 23:02:27 | evan | linux gcc is stupid like that. |
| 23:02:53 | evan | ok, pushed "fix", ie. a newline. |
| 23:02:58 | jackdempsey enters the room. | |
| 23:03:04 | CIA-20 | * Fix primitive failure, rework primitive type checks. Primitive type checks are now performed carefully, defering to failure if the typecheck fails.; 5d54bad - Evan Phoenix |
| 23:03:04 | CIA-20 | * Fix instructions.o dep, add newline; 933877d - Evan Phoenix |
| 23:03:06 | evan | drbrain: I kludged the instructions.o deps |
| 23:03:12 | evan | drbrain: by throwing *hdrs on the end |
| 23:03:21 | dgtized | not fixed |
| 23:03:23 | evan | if you've got a better way, feel free to fix it. |
| 23:03:36 | dgtized | same type failure as before |
| 23:03:43 | Arjen_ leaves the room. | |
| 23:03:44 | evan | dgtized: you have |
| 23:03:50 | evan | dgtized: you have 933877d ? |
| 23:04:29 | drbrain | evan: I don't know if I have a better one, did you mark it? |
| 23:04:32 | dgtized | if I do a git pull it says I'm up to date |
| 23:04:44 | evan | drbrain: mark it? |
| 23:04:49 | evan | dgtized: same error? |
| 23:04:50 | dgtized | and that includes the newline fix |
| 23:04:55 | dgtized | evan: exact same |
| 23:04:59 | evan | wtf. |
| 23:05:01 | evan | um. |
| 23:05:06 | drbrain | with a # TODO or HACK or FIXME |
| 23:05:14 | evan | ah, no. |
| 23:05:15 | evan | should have. |
| 23:05:50 | evan | dgtized: could you check there is a newline there? |
| 23:05:55 | evan | dgtized: ie, see if you can resolve it on your end |
| 23:07:52 | dgtized | I guess I don't follow how a "cannot be overloaded" is affected by newlines |
| 23:08:01 | evan | oh |
| 23:08:05 | evan | so the newline one is gone |
| 23:08:11 | evan | but the others are still there? |
| 23:08:37 | evan | hm. |
| 23:08:42 | evan | i wonder why it's complaining about that |
| 23:08:43 | evan | one sec |
| 23:08:47 | dgtized | oh I'm sorry -- yea it did change, no I don't have the newline anymore, but the overloading was the one I paid attention to |
| 23:09:25 | dgtized | I didn't even register the newline error was in there somehow, I was focused on the overload error |
| 23:10:48 | pauldix leaves the room. | |
| 23:13:04 | evan | oh |
| 23:13:16 | evan | it's because native_int is a typedef of int |
| 23:13:23 | evan | so you can't overload both of them. |
| 23:14:09 | evan | dgtized: go into integer.hpp |
| 23:14:19 | evan | and comment out line 28 |
| 23:14:23 | evan | and see if that fixesit. |
| 23:16:00 | joachimm enters the room. | |
| 23:16:17 | dgtized | well it fixes that error, but then it complains later about an ambiguous call to vm/ffi.cpp:822: error: call of overloaded ‘from(rubinius::VM*&, long int&)’ is ambiguous |
| 23:16:35 | evan | hrm. |
| 23:16:35 | evan | k |
| 23:16:45 | dgtized | so it does need both |
| 23:16:54 | evan | nah |
| 23:16:56 | evan | it doesn't. |
| 23:17:18 | evan | those ffi calls need casts |
| 23:17:28 | evan | they should be more explicit |
| 23:17:39 | evan | on 822, add (native_int) in from of result |
| 23:19:42 | lstoll leaves the room. | |
| 23:19:58 | evan | our native_int is a typedef from intptr_t |
| 23:20:14 | evan | which means 32bit on 32bit platforms, 64bit on 64bit platforms |
| 23:20:53 | evan | which, on all 64bit platforms I know of, means a native_int is the size of a long |
| 23:20:59 | mass | the problem with getting into ruby with rails, I keep typing things like "rails test" instead of "rake test" |
| 23:21:02 | evan | so we should be able to just have things that take native_int |
| 23:22:27 | dgtized | you also have to cast it in dir.cpp at line 78, and comment out the actual implementation in integer.cpp |
| 23:22:33 | evan | yep |
| 23:22:38 | evan | just thinking about it now. |
| 23:22:40 | dgtized | and all of these fixes will fail if I were running 64 bit |
| 23:22:49 | dgtized | because then it would be the same as the long int instead |
| 23:22:55 | evan | seems that darwin, on 32bit, says that intptr_t == int |
| 23:23:00 | evan | and on linux, intptr_t == long |
| 23:23:04 | evan | which is fine, they're the same thing on 32bit |
| 23:23:19 | evan | but it's causing a disconnect in how C++ wants to treat the type |
| 23:24:46 | NoKarma enters the room. | |
| 23:25:26 | dgtized | what if we just don't bother with a native_int from? |
| 23:25:38 | dgtized | shouldn't the long and int definitions just take care of it naturally? |
| 23:25:45 | evan | hm |
| 23:25:49 | evan | perhaps |
| 23:25:50 | evan | yes. |
| 23:25:54 | evan | they should |
| 23:26:00 | dgtized | k, I'll set it up that way |
| 23:27:22 | evan | k |
| 23:28:43 | ch0wda enters the room. | |
| 23:29:34 | ijcd leaves the room. | |
| 23:31:09 | dgtized | yea we already had this problem once before -- there was a comment in the integer.hpp saying we didn't need from(*,long) because it was taken care of by native_int |
| 23:32:09 | enebo leaves the room. | |
| 23:34:30 | dgtized | I'm converting Bignum::from(*,native_int) into int and long versions as well |
| 23:36:36 | evan | ok |
| 23:37:08 | ch0wda leaves the room. | |
| 23:38:07 | dgtized | are we actually using every one of those from types? |
| 23:38:21 | dgtized | Fixnum::from is getting by just fine with only native_int |
| 23:38:59 | evan | that one is a little different |
| 23:39:19 | evan | fix it up enough to work where you are |
| 23:39:28 | evan | then lets talk with dbussink again |
| 23:39:30 | evan | when he's around |
| 23:39:32 | dgtized | k |
| 23:40:44 | CIA-20 | * fix for type overloading problems on Integer from native_int; 49bce9f - Charles Comstock |
| 23:43:21 | binary42 leaves the room. | |
| 23:43:46 | BobFunk leaves the room. | |
| 23:44:02 | dgtized | that still work for everyone else? |
| 23:44:25 | brixen | checking.. |
| 23:45:47 | octopod leaves the room. | |
| 23:47:22 | brixen | dgtized: worked for me on osx intel |
| 23:48:35 | evan | almost done moving ivars into the object header |
| 23:48:49 | mutle_ enters the room. | |
| 23:49:08 | brixen | cool |
| 23:52:59 | dgtized | brixen: good -- I was worried since it was compiler fixing that I might break the build in reverse |
| 23:59:53 | mutle__ enters the room. |