Da
Show enters and exits. Hide enters and exits.
| 00:02:52 | codebrulee enters the room. | |
| 00:02:52 | bricolage leaves the room. | |
| 00:07:26 | gilesgoatboy leaves the room. | |
| 00:07:41 | mutle_ leaves the room. | |
| 00:08:35 | CIA-20 | * Move the haphazard __ivars__ into the object header; d5d35be - Evan Phoenix |
| 00:08:43 | mutle leaves the room. | |
| 00:09:55 | CIA-20 | * Remove absent functions; 515449e - Evan Phoenix |
| 00:13:33 | imajes_ enters the room. | |
| 00:13:37 | enebo enters the room. | |
| 00:18:21 | benny enters the room. | |
| 00:29:28 | yroc leaves the room. | |
| 00:31:16 | nari leaves the room. | |
| 00:38:24 | evan | oh oh. |
| 00:38:36 | evan | I think i'm going to juggle the header a little |
| 00:38:42 | evan | and make things cleaner. |
| 00:38:45 | blakewatters leaves the room. | |
| 00:39:19 | evan | who's around? |
| 00:39:21 | brixen | me |
| 00:39:24 | drbrain | me |
| 00:39:26 | evan | i need to bounces names around |
| 00:39:26 | evan | ok |
| 00:39:31 | blakewatters enters the room. | |
| 00:39:31 | evan | TypeInfo blows as a name |
| 00:39:36 | brixen | agreed |
| 00:39:44 | evan | it says about as much as "meat sandwich" |
| 00:39:52 | brixen | :) |
| 00:40:34 | evan | here's what it is, you can help me think of a better name |
| 00:40:56 | evan | there is one for every kind of object layout in the system |
| 00:41:12 | evan | a particular object layout is what i've been calling a type |
| 00:41:36 | evan | give a type, you can get a TypeInfo about that describes that type |
| 00:41:40 | evan | and call methods on it |
| 00:41:59 | evan | i've been saying that it "shadows" the Ruby class of |
| 00:42:02 | evan | s/of// |
| 00:42:13 | evan | providing VM specific operations |
| 00:42:37 | evan | I wish we didn't need them |
| 00:43:22 | evan | but they're a necessary evil to be able to organize things polymorphicly |
| 00:43:50 | drbrain | they're metadata |
| 00:44:59 | evan | well, they're metafunctionality |
| 00:45:03 | evan | but yes. |
| 00:45:06 | brixen | hrm, given what it is, TypeInfo isn't that terrible I suppose |
| 00:45:38 | brixen | looking at synonyms for information, knowledge, data |
| 00:47:01 | evan | I could just call it Type |
| 00:47:06 | evan | i thought about that originally |
| 00:47:13 | evan | but that seems like it would cause more confusion |
| 00:47:18 | brixen | are you hitting a problem with it? |
| 00:47:33 | evan | no |
| 00:47:34 | brixen | I'd suggest leaving it for now if not |
| 00:47:36 | evan | just been staring at it today |
| 00:47:38 | evan | ok |
| 00:47:54 | drbrain | yeah |
| 00:48:07 | drbrain | TypeInfo sounds like it's minimally terrible |
| 00:48:39 | evan | ok |
| 00:48:43 | evan | well, i've planted the seed now |
| 00:48:55 | evan | maybe one of you guys will come up with a better name |
| 00:49:27 | brixen | sure, it can be difficult if you're just see it |
| 00:49:35 | brixen | it was one of my Q's in that list |
| 00:49:45 | brixen | but given a little doc about it, it's not terrible |
| 00:49:54 | brixen | s/see/seeing/ |
| 00:50:27 | evan | ok, question 2: |
| 00:50:39 | evan | is 2 ** 18 (262144) too small for the max object size? |
| 00:50:57 | drbrain | what is a max object size? |
| 00:51:01 | drbrain | how many slots? |
| 00:51:05 | evan | yeah |
| 00:51:08 | evan | actually, it would be 524287 |
| 00:51:11 | evan | 2 ** 19 - 1 |
| 00:51:14 | evan | 18 full bits |
| 00:51:20 | evan | max slots |
| 00:51:26 | evan | the only thing I can think it would impact is Array |
| 00:51:30 | drbrain | why would it need to be bigger than, say, 32? |
| 00:51:32 | evan | since Tuple uses the slots directly |
| 00:51:45 | evan | drbrain: for Tuple |
| 00:51:54 | evan | and String |
| 00:52:02 | evan | well, ByteArray |
| 00:52:21 | evan | the backends for Array and String |
| 00:52:32 | binary42 enters the room. | |
| 00:52:36 | evan | if it were 32, you could only have an array with 32 elements |
| 00:52:43 | evan | unless we come up with a chunking storage for Arary |
| 00:52:49 | evan | (which we should eventually anyway) |
| 00:53:04 | brixen | yeah, Array will need some work |
| 00:53:13 | evan | but barring that |
| 00:53:22 | drbrain | then I think we should use 32 |
| 00:53:29 | evan | seems like 524287 elements would be an ok limitation? |
| 00:53:34 | evan | drbrain: 32 slots max? |
| 00:53:36 | drbrain | since I've made Arrays with a million or more elements before |
| 00:53:37 | evan | or 32bits? |
| 00:53:46 | evan | oh wait |
| 00:53:53 | evan | were you meaning 32bits the whole time? |
| 00:53:58 | drbrain | it seems like 500k slots is temptation to do bad things |
| 00:54:09 | drbrain | so I say we arbitrarily make it small to force us to Do It Right |
| 00:54:13 | evan | and 4B isn't? |
| 00:54:19 | evan | so, you do mean 32 slots |
| 00:54:25 | evan | please answer. |
| 00:54:34 | drbrain | I through 32 slots out there abritrarily |
| 00:54:48 | brixen | heh |
| 00:54:55 | brixen | evan: here's your chance! |
| 00:54:59 | drbrain | it seems that the only valid reason for having it be 500k slots is "because we are lazy" |
| 00:55:00 | brixen | threw? |
| 00:55:11 | evan | drbrain: sure |
| 00:55:11 | drbrain | sorry, threw |
| 00:55:19 | evan | it's 32bits (ie, 4G) now |
| 00:55:24 | evan | but we can't actually support an object that big |
| 00:55:30 | evan | well, we could |
| 00:55:34 | evan | but the machine would tip over before that. |
| 00:55:49 | brixen | seems that Array and String should be considered separately |
| 00:55:53 | evan | let me check what the squeak max is |
| 00:56:04 | imajes_ leaves the room. | |
| 00:56:07 | brixen | I believe the specs for Array on 64bit MRI allow you to allocate as much memory as possible |
| 00:56:11 | dgtized | what about renaming TypeInfo to ClassInfo -- it seems like it has the same problems with using the name type as ruby does |
| 00:56:30 | evan | dgtized: hm.. |
| 00:56:34 | evan | brixen: true |
| 00:56:55 | dgtized | or am I misunderstanding it's relationship to classes |
| 00:56:56 | AndrewO leaves the room. | |
| 00:57:36 | drbrain | right now the max Array size in 1.8 trunk is 1073741824 |
| 00:57:40 | drbrain | for 32 bit |
| 00:57:56 | evan | drbrain: and you make one |
| 00:57:58 | drbrain | #define ARY_MAX_SIZE (LONG_MAX / sizeof(VALUE)) |
| 00:58:03 | drbrain | if I read that right |
| 00:58:03 | evan | right |
| 00:58:06 | evan | thats 4G of memory |
| 00:58:12 | evan | because sizeof(VALUE) == 4 |
| 00:58:24 | evan | so it's 1G of VALUE's in order |
| 00:59:52 | drbrain | my main objection is that allowing a lot of slots tempts us to take shortcuts |
| 01:00:11 | drbrain | how is the slot count currently determined? |
| 01:00:13 | evan | well, have we been taking shortcuts up to now? |
| 01:00:24 | evan | other than Tuple and ByteArray |
| 01:00:27 | evan | staticly, at compiletime |
| 01:00:30 | drbrain | the Array thing seems like a shortcut |
| 01:00:52 | evan | you mean just using a single Tuple as flat storage is a shortcut? |
| 01:00:57 | evan | it's certainly the simplest way |
| 01:01:02 | evan | i'm not sure i'd call it shortcut |
| 01:01:12 | drbrain | I meant, why is it 500k and not a long or something? |
| 01:01:18 | evan | it's not. |
| 01:01:23 | evan | it's a long now. |
| 01:01:28 | brapse leaves the room. | |
| 01:01:29 | evan | i'm trying to move stuff around in the header |
| 01:01:29 | drbrain | ok |
| 01:01:38 | evan | and was considering reuse a few bits for flags and stuff |
| 01:01:41 | evan | just cleaning it up |
| 01:01:47 | evan | trying to decide if we needed the full 32bits |
| 01:01:53 | brixen | I don't think so |
| 01:01:54 | drbrain | ah, ok |
| 01:02:04 | brixen | the Array limitation has to be addressed a different way |
| 01:02:11 | brixen | so, I'd say use the bits |
| 01:02:27 | evan | ok |
| 01:02:43 | drbrain | how many bits are otherwise allocated, and would it be a problem if we wanted to use more bits? |
| 01:02:46 | brixen | we're going to namespace Tuple anyway, right? |
| 01:02:55 | brixen | so, it shouldn't actually be in Ruby code |
| 01:03:02 | evan | drbrain: if we want to use more bits, we can just reshuffle the header again |
| 01:03:07 | evan | drbrain: and use more header space |
| 01:03:08 | brixen | and we can modify how Array works under the covers |
| 01:03:16 | evan | shuffling the header isn't hard |
| 01:03:19 | evan | it's just trade-offs |
| 01:03:51 | evan | brixen: we've going to refactor Tuple out of the common code, yes. |
| 01:03:57 | evan | into the Rubinius specific stuff |
| 01:03:58 | brixen | cool |
| 01:04:02 | drbrain | I don't see why we don't keep using long then |
| 01:04:08 | drbrain | for number of header fields |
| 01:04:46 | evan | drbrain: you don't see why we'd continue if we're going to move stuff around in Array? |
| 01:06:02 | drbrain | if we can use a significant fraction of a long's worth of slots for Array, (like 1.8 does), then why should we limit ourselves to 500k? |
| 01:06:17 | drbrain | I see two alternatives, use a lot of slots, or use very few |
| 01:06:48 | drbrain | the middle ground doesn't look very fruitful |
| 01:07:01 | evan | i consider 500k being a lot |
| 01:07:03 | evan | do you? |
| 01:07:09 | evan | or do you consider that the middle ground |
| 01:07:20 | drbrain | I consider that middle ground |
| 01:07:30 | drbrain | since 500k isn't a lot of Array slots |
| 01:07:53 | evan | what would you consider a lot? |
| 01:07:58 | evan | just trying to get your guage |
| 01:08:00 | drbrain | with few we run into the walls quickly and find robust solutions |
| 01:08:06 | drbrain | a long's worth |
| 01:08:13 | evan | I mean, MRI tips over if you have a 1G array as is |
| 01:08:24 | evan | so you could say it doesn't really support it either. |
| 01:08:25 | drbrain | yes |
| 01:08:44 | drbrain | obviously there's the LONG_MAX / sizeof(long) limit |
| 01:08:53 | drbrain | but that's defined by hardware |
| 01:09:04 | evan | oh ok. |
| 01:09:10 | evan | here's the 2 definitions |
| 01:09:17 | evan | should slots be physical max or functional max? |
| 01:09:27 | evan | MRI's number is physical max |
| 01:09:37 | brixen | MRI's number is an implementation limitation |
| 01:09:55 | brixen | MRI chooses to impl it as a single array |
| 01:10:00 | evan | right |
| 01:10:12 | evan | I think that we'll decide soon that we need Array to be sparse anyway |
| 01:10:16 | evan | using a simple chunking algo |
| 01:10:17 | brixen | yep |
| 01:10:19 | brixen | we should |
| 01:10:29 | brixen | what would you use the bits for evan ? |
| 01:10:32 | evan | in which case, the need for a huge Tuple goes away |
| 01:10:37 | brixen | right |
| 01:10:50 | evan | we could have a chunked String to |
| 01:10:53 | drbrain | do we only use huge tuples for Array? |
| 01:10:57 | evan | yep |
| 01:11:11 | evan | everything else is like Tuples of 4 or 5 slots |
| 01:11:20 | drbrain | and I'm guessing huge ByteArrays for String |
| 01:11:21 | evan | basically used as a small, cheap Array |
| 01:11:26 | evan | drbrain: exactly. |
| 01:11:57 | nari enters the room. | |
| 01:12:33 | drbrain | I say we move towards the using more like 8 bits for slot numbers |
| 01:12:38 | drbrain | -the |
| 01:12:40 | jbarnette leaves the room. | |
| 01:12:43 | evan | yeah |
| 01:12:46 | evan | I like that. |
| 01:13:04 | fizx enters the room. | |
| 01:20:32 | evan | I'm going to go for the middle ground for right now |
| 01:20:40 | headius | evening |
| 01:20:43 | evan | and schedule a task to implement chunking in Array |
| 01:20:48 | evan | headius: hey |
| 01:21:11 | headius | array chunking? |
| 01:21:51 | evan | headius: we were discussing how an Array with 1M elements should be represented |
| 01:22:21 | headius | do people use arrays with 1M elements? |
| 01:22:34 | evan | accidentally sometimes |
| 01:22:51 | evan | well, also, what should the max object size be |
| 01:23:08 | evan | which, current, influences how large an Array can be |
| 01:23:25 | evan | if we implement Array's storage as chunking, that influence goes away |
| 01:23:35 | headius | mmm I see |
| 01:23:47 | headius | this is embedding data in object header yes? |
| 01:23:51 | headius | like str/ary length |
| 01:23:56 | evan | no |
| 01:23:58 | evan | not really. |
| 01:24:10 | evan | Rubinius has variable sized objects in memory |
| 01:24:20 | evan | things like Tuple and ByteArray make use of that |
| 01:24:30 | evan | to store their data directly after the object header |
| 01:24:50 | evan | the object size is how many fields it has |
| 01:25:02 | headius | ahh |
| 01:25:04 | evan | things like Array have like 4 or 5 |
| 01:25:17 | evan | one of them being a ref to a Tuple, which it uses for storage. |
| 01:25:36 | headius | so you want to use less than 64 or 32 bits for length to shrink that size? |
| 01:26:08 | evan | the size of the count in the header, yes. |
| 01:26:21 | evan | so I can use it for something else |
| 01:26:24 | headius | is that really a big enough savings to matter? |
| 01:26:59 | evan | if we have 50_000 objects, thats an extra 200k |
| 01:27:07 | dfg59 leaves the room. | |
| 01:27:09 | headius | 200k isn't much |
| 01:27:20 | evan | *shrug* |
| 01:27:32 | evan | it's an issue we've needed to deal with anyway |
| 01:27:42 | evan | giant Array's |
| 01:28:32 | fizx leaves the room. | |
| 01:28:52 | brixen | and there's even papers on dealing with such things: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9607 |
| 01:29:07 | yugui enters the room. | |
| 01:29:13 | evan | ack |
| 01:29:21 | evan | making this change blows up the 64bit alignment. |
| 01:29:41 | evan | oh, i can fix that easy. |
| 01:29:42 | evan | nm. |
| 01:29:42 | evan | :) |
| 01:30:50 | headius | brixen: dealing with what things |
| 01:31:01 | brixen | headius: see the link |
| 01:31:15 | headius | ahh, sorry, new citeseer layout confused me |
| 01:31:22 | brixen | yeah, it's weird :) |
| 01:31:28 | brixen | citeseer beta heh |
| 01:31:29 | headius | I just saw "3, and" |
| 01:32:14 | headius | yeah, I played with some sparse arrays for dispatch tables a while back |
| 01:32:29 | evan | hm, this change cleans up as<> too |
| 01:33:13 | headius | just seems like an unusual change to consider, but I don't fully understand all your motives |
| 01:33:30 | lopex leaves the room. | |
| 01:34:11 | evan | which? |
| 01:34:27 | nari leaves the room. | |
| 01:35:07 | headius | I suppose both chunked arrays and non-integer array size |
| 01:35:15 | headius | er non-int |
| 01:35:43 | evan | huh? |
| 01:35:50 | headius | non-32-bit-always |
| 01:35:52 | evan | not sure what ya mean by the later |
| 01:37:27 | Defiler leaves the room. | |
| 01:38:06 | headius | maybe I'm not understanding how this saves you 200k or why that's significant |
| 01:38:41 | headius | eliminating a 4-byte array size seems like it would only help array object size, so perhaps if you had 50k arrays you'd save that |
| 01:39:33 | evan | it's not Array |
| 01:39:38 | evan | you're not getting it. |
| 01:39:51 | evan | it's the fundemental object size |
| 01:40:14 | headius | oh, so this is the number of slots you have for the object's data? |
| 01:40:21 | evan | think about it as 'how big can a single, contigious object be' |
| 01:40:29 | evan | headius: right. |
| 01:41:19 | headius | isn't that used primarily by rubinius core classes though? and probably no more than a handful of slots ever? |
| 01:41:32 | evan | yep. |
| 01:41:33 | headius | like why would there be more than 256 slots ever |
| 01:41:41 | evan | (this is the discussion we had 20 minutes ago) |
| 01:41:55 | headius | well, good for you :) |
| 01:42:01 | evan | the only thing need more than, say 256, is Tuple and ByteArray |
| 01:42:18 | evan | in the current setup, a flat Tuple is used as an Array's storage |
| 01:42:22 | evan | and ditto for String to ByteArray |
| 01:42:34 | headius | ok, I see drbrain asked that as well |
| 01:42:40 | evan | yeah |
| 01:42:41 | evan | if you can |
| 01:42:42 | evan | scroll up |
| 01:43:12 | imajes_ enters the room. | |
| 01:43:31 | jtoy enters the room. | |
| 01:43:42 | ezmobius leaves the room. | |
| 01:43:44 | headius | why do tuple and bytearray need more |
| 01:43:59 | headius | I don't see that mentioned |
| 01:44:05 | evan | you'd like an Array with more thon 256 elements |
| 01:44:12 | evan | or a String with more than 1024 bytes |
| 01:44:38 | headius | why isn't the physical array a pointer to an array |
| 01:44:51 | evan | it is. |
| 01:45:03 | evan | you mean a pointer into random C heap memory? |
| 01:45:06 | evan | not GC managed memory? |
| 01:45:11 | evan | rubinius doesn't do that. |
| 01:45:19 | evan | it doesn't handle Array and String the way MRI does |
| 01:45:25 | evan | by having the storage point of into C heap |
| 01:45:26 | headius | well, neither does JVM, but an object with an array in it is not the size of that array |
| 01:45:43 | evan | headius: Rubinius has no primitive types |
| 01:45:44 | headius | have the GC allocate the array and provide a reference to it for you |
| 01:45:47 | evan | and thus no 'raw' Array. |
| 01:45:54 | evan | er. s/Array/array/ |
| 01:45:57 | headius | and access array elements through the reference |
| 01:46:04 | evan | but that thing still has a max size |
| 01:46:07 | evan | it's the same thing really |
| 01:46:29 | evan | if you must, think of our Tuple like a java array. |
| 01:46:43 | evan | in memory, it's almost exactly the same |
| 01:46:54 | evan | except a Tulpe has a header on it to say what it is, and how big it is. |
| 01:47:13 | headius | yes, java arrays have the same thing |
| 01:47:21 | headius | they are still full Objects |
| 01:47:34 | evan | what do they say their class is? |
| 01:47:50 | headius | the array type of that class |
| 01:47:58 | headius | array types are instantiated at runtime as needed |
| 01:48:31 | evan | anyways |
| 01:48:33 | headius | but that's more an internal detail |
| 01:48:43 | evan | i'm going to head home |
| 01:48:46 | evan | be back on in a bit. |
| 01:48:53 | headius | so your problem is that tuple and bytearray are also presented to ruby code |
| 01:48:58 | headius | so they need a full header appropriate for ruby |
| 01:49:09 | evan | everything does, yes. |
| 01:49:16 | evan | thats not really the problem though. |
| 01:49:20 | evan | at least how I see it. |
| 01:49:20 | headius | and thus you can't reduce them to non-ruby-compatible internal data structures with their own layout |
| 01:49:41 | evan | and we wouldn't want to |
| 01:49:45 | evan | they're a building block |
| 01:49:48 | evan | plain and simple. |
| 01:50:00 | headius | why not have a building block that's not a ruby object |
| 01:50:04 | evan | they're supposed to be built upon to create more powerful abstractions |
| 01:50:08 | evan | headius: whats the point? |
| 01:50:14 | evan | what does that buy us? |
| 01:50:31 | headius | to avoid having to fiddle with object sizes at the ruby level just to accommodate arbitrary-length arrays |
| 01:51:04 | evan | well |
| 01:51:11 | evan | 1) object size isn't fiddle at the ruby level. |
| 01:51:11 | headius | you could have a byte slot count for everything if you didn't have to deal with just a handful of types that want large slot counts |
| 01:51:31 | yugui leaves the room. | |
| 01:51:34 | evan | I think your abstraction makes it more complicated |
| 01:51:37 | evan | rather than less. |
| 01:51:58 | headius | I don't think so...tuple and bytearray are already implemented mostly in C/++ aren't they? |
| 01:52:04 | evan | no |
| 01:52:12 | evan | i mean |
| 01:52:27 | evan | they only have a couple of operations |
| 01:52:30 | evan | which i guess are in C |
| 01:52:37 | evan | but we're talking like 3 methods each |
| 01:52:42 | evan | anyways |
| 01:52:46 | evan | i've got get home. |
| 01:52:47 | evan | bbiab. |
| 01:52:57 | headius | so why does it matter whether they store their data in the tuple/bytearray object itself or as a handle to data of arbitrary size elsewhere |
| 01:52:59 | ijcd enters the room. | |
| 01:53:02 | headius | ok, ttfn |
| 01:56:38 | edwardam enters the room. | |
| 01:56:51 | ijcd_ enters the room. | |
| 01:57:08 | c0sin leaves the room. | |
| 01:59:02 | trythil enters the room. | |
| 02:03:43 | yugui enters the room. | |
| 02:05:33 | trythil_ enters the room. | |
| 02:06:48 | yugui_ enters the room. | |
| 02:12:40 | ijcd leaves the room. | |
| 02:13:23 | jackdempsey leaves the room. | |
| 02:14:23 | yugui leaves the room. | |
| 02:17:00 | nicksieger leaves the room. | |
| 02:20:04 | trythil leaves the room. | |
| 02:20:50 | nicksieger enters the room. | |
| 02:23:54 | imajes_ leaves the room. | |
| 02:25:34 | evan | headius: so, I think what I failed to mention is how the object size/header interacts with the GC |
| 02:25:57 | evan | I see what you were talking about |
| 02:25:59 | evan | that could work |
| 02:26:48 | zenspider | 'sup my bitches? |
| 02:26:59 | evan | he lives! |
| 02:27:21 | zenspider | barely |
| 02:27:35 | zenspider | I don't remember if I msg'd you |
| 02:27:44 | evan | you did earlier today |
| 02:27:51 | zenspider | I'm not an alternate, so I've got deliberations tomorrow... |
| 02:27:58 | zenspider | but I don't think it'll take very long |
| 02:27:58 | evan | oh yay! |
| 02:28:03 | zenspider | "sadly" |
| 02:28:30 | headius leaves the room. | |
| 02:28:43 | evan | ah |
| 02:28:53 | evan | well, you can tell us about it once it hits the papers |
| 02:28:58 | evan | or whatever the rule is |
| 02:30:20 | zenspider | I'll be able to talk about it once we're done with deliberations... I'm guessing tomorrow, but *shrug* |
| 02:33:38 | evan | ok, i'm off to a bbq |
| 02:33:40 | evan | summer style. |
| 02:34:32 | obvio171 enters the room. | |
| 02:35:01 | zenspider | nom nom nom |
| 02:42:50 | qrush enters the room. | |
| 02:46:04 | jackdempsey enters the room. | |
| 03:04:56 | benburkert leaves the room. | |
| 03:05:53 | benburkert enters the room. | |
| 03:06:42 | benburkert leaves the room. | |
| 03:07:23 | iamclovin enters the room. | |
| 03:09:18 | c0sin enters the room. | |
| 03:12:18 | c0sin leaves the room. | |
| 03:16:18 | iamclovin leaves the room. | |
| 03:16:48 | shayarnett enters the room. | |
| 03:23:41 | blakewatters leaves the room. | |
| 03:25:53 | codebrulee leaves the room. | |
| 03:27:47 | yugui_ leaves the room. | |
| 03:59:19 | benburkert enters the room. | |
| 04:01:25 | trythil_ leaves the room. | |
| 04:03:14 | enebo leaves the room. | |
| 04:06:54 | yugui enters the room. | |
| 04:13:20 | yugui leaves the room. | |
| 04:26:27 | keisukefukuda enters the room. | |
| 04:34:18 | ijcd_ leaves the room. | |
| 04:34:20 | shayarnett leaves the room. | |
| 04:39:07 | ezmobius enters the room. | |
| 04:40:16 | AndrewO enters the room. | |
| 04:44:15 | nicksieger leaves the room. | |
| 04:54:59 | Yurik enters the room. | |
| 04:59:27 | edwardam leaves the room. | |
| 05:11:05 | keisukefukuda leaves the room. | |
| 05:14:55 | benburkert leaves the room. | |
| 05:16:15 | antares enters the room. | |
| 05:22:14 | nari enters the room. | |
| 05:22:36 | yugui enters the room. | |
| 05:24:40 | guitsaru enters the room. | |
| 05:28:14 | obvio171 leaves the room. | |
| 05:29:56 | qrush leaves the room. | |
| 05:36:25 | trythil enters the room. | |
| 05:43:08 | gilesgoatboy enters the room. | |
| 05:47:30 | gilesgoatboy leaves the room. | |
| 05:47:52 | dbussink | dgtized: still there? |
| 05:48:07 | dbussink | you had a question about all the Integer::from versions? |
| 05:48:30 | evan | dbussink: yo |
| 05:48:55 | evan | dbussink: we took the native_int version out |
| 05:49:02 | dbussink | yeah i saw it |
| 05:49:05 | evan | because, as you saw, it conflicts with either int or long |
| 05:49:20 | evan | and it depends on the platform which it conflicts with |
| 05:49:23 | dbussink | seems fine to me |
| 05:49:28 | evan | so since native_int is either or anyway, should be fine |
| 05:49:29 | evan | yeah |
| 05:49:31 | dbussink | it'll work out itself now |
| 05:49:51 | evan | yep |
| 05:51:52 | evan | I like the look a lot better though |
| 05:51:55 | evan | good job! |
| 05:52:35 | dbussink | hopefully it helps against Defiler's confusion too ;) |
| 05:54:51 | AndrewO leaves the room. | |
| 05:58:31 | nicksieger enters the room. | |
| 06:06:29 | fbuilesv enters the room. | |
| 06:14:53 | guitsaru leaves the room. | |
| 06:21:14 | lchin enters the room. | |
| 06:30:11 | benburkert enters the room. | |
| 06:40:55 | trythil_ enters the room. | |
| 06:42:41 | benny leaves the room. | |
| 06:46:23 | jtoy leaves the room. | |
| 06:46:35 | jtoy enters the room. | |
| 06:52:21 | jayWHY_ enters the room. | |
| 06:57:17 | jackdempsey leaves the room. | |
| 06:57:32 | trythil leaves the room. | |
| 06:58:18 | jayWHY leaves the room. | |
| 07:01:57 | benny enters the room. | |
| 07:12:23 | benny leaves the room. | |
| 07:12:38 | benny enters the room. | |
| 07:18:31 | thehcdreamer enters the room. | |
| 07:20:48 | benburkert leaves the room. | |
| 07:22:35 | gnufied leaves the room. | |
| 07:43:00 | rubuildius_amd64 leaves the room. | |
| 07:48:15 | lchin leaves the room. | |
| 07:49:39 | krsh enters the room. | |
| 07:54:27 | w1rele55 enters the room. | |
| 08:02:20 | yroc enters the room. | |
| 08:04:03 | BlackEdder enters the room. | |
| 08:04:33 | BobFunkasdas leaves the room. | |
| 08:06:32 | dysinger leaves the room. | |
| 08:08:01 | mutle enters the room. | |
| 08:09:53 | BlackEdder leaves the room. | |
| 08:10:05 | BlackEdder enters the room. | |
| 08:11:26 | trythil enters the room. | |
| 08:14:44 | antares leaves the room. | |
| 08:15:17 | antares enters the room. | |
| 08:18:33 | michalw enters the room. | |
| 08:18:50 | mutle__ leaves the room. | |
| 08:21:54 | Arjen_ enters the room. | |
| 08:26:27 | trythil_ leaves the room. | |
| 08:39:16 | octopod enters the room. | |
| 08:42:36 | jayWHY_ leaves the room. | |
| 08:46:53 | trythil leaves the room. | |
| 08:52:29 | yroc leaves the room. | |
| 09:07:06 | Maledictus enters the room. | |
| 09:10:24 | keisukefukuda enters the room. | |
| 09:15:02 | NoKarma enters the room. | |
| 09:28:38 | headius enters the room. | |
| 09:34:17 | lchin enters the room. | |
| 09:43:13 | ezmobius leaves the room. | |
| 09:44:53 | Arjen_ leaves the room. | |
| 09:57:11 | benny leaves the room. | |
| 10:26:49 | headius leaves the room. | |
| 10:37:53 | scoopr leaves the room. | |
| 10:41:30 | michalw leaves the room. | |
| 10:59:46 | chris2 enters the room. | |
| 11:02:15 | nari leaves the room. | |
| 11:06:30 | mutle_ enters the room. | |
| 11:23:36 | mutle leaves the room. | |
| 11:26:30 | yugui leaves the room. | |
| 11:40:45 | krsh leaves the room. | |
| 11:43:15 | jtoy leaves the room. | |
| 11:48:32 | scoopr enters the room. | |
| 11:54:22 | lchin leaves the room. | |
| 12:04:23 | Maledictus leaves the room. | |
| 12:04:23 | w1rele55 leaves the room. | |
| 12:04:23 | rubuildius_ey64 leaves the room. | |
| 12:04:23 | evan leaves the room. | |
| 12:04:23 | josb leaves the room. | |
| 12:04:23 | explody leaves the room. | |
| 12:04:51 | Maledictus enters the room. | |
| 12:04:51 | w1rele55 enters the room. | |
| 12:04:51 | josb enters the room. | |
| 12:04:52 | rubuildius_ey64 enters the room. | |
| 12:04:52 | evan enters the room. | |
| 12:04:52 | explody enters the room. | |
| 12:17:23 | w1rele55 leaves the room. | |
| 12:20:50 | kota enters the room. | |
| 12:22:35 | thehcdreamer leaves the room. | |
| 12:23:33 | thehcdreamer enters the room. | |
| 12:24:48 | botanicus enters the room. | |
| 12:37:25 | thehcdreamer leaves the room. | |
| 12:38:28 | thehcdreamer enters the room. | |
| 12:56:26 | thehcdreamer leaves the room. | |
| 12:58:04 | thehcdreamer enters the room. | |
| 13:00:41 | benny enters the room. | |
| 13:01:25 | thehcdreamer leaves the room. | |
| 13:03:05 | antares leaves the room. | |
| 13:51:30 | keisukefukuda leaves the room. | |
| 14:10:02 | antares enters the room. | |
| 14:20:20 | Fullmoon enters the room. | |
| 14:24:13 | blakewatters enters the room. | |
| 14:32:30 | trythil enters the room. | |
| 14:33:37 | foysavas enters the room. | |
| 14:34:47 | trythil leaves the room. | |
| 14:36:04 | moofbong enters the room. | |
| 14:44:54 | binary42 leaves the room. | |
| 14:47:53 | AndrewO enters the room. | |
| 15:00:50 | Fullmoon leaves the room. | |
| 15:02:49 | benburkert enters the room. | |
| 15:03:07 | ch0wda enters the room. | |
| 15:06:37 | wmoxam enters the room. | |
| 15:08:32 | pauldix enters the room. | |
| 15:15:03 | binary42 enters the room. | |
| 15:20:04 | fbuilesv leaves the room. | |
| 15:25:08 | benny leaves the room. | |
| 15:30:35 | BobFunk enters the room. | |
| 15:36:26 | edwardam enters the room. | |
| 15:36:41 | foysavas leaves the room. | |
| 15:37:09 | nari enters the room. | |
| 15:49:06 | lorenzod8n enters the room. | |
| 16:13:39 | krsh enters the room. | |
| 16:16:28 | edwardam leaves the room. | |
| 16:17:07 | joachimm_ enters the room. | |
| 16:20:20 | bricolage enters the room. | |
| 16:28:08 | Defiler enters the room. | |
| 16:37:41 | joachimm leaves the room. | |
| 16:38:07 | joachimm_ leaves the room. | |
| 16:45:55 | dfg59 enters the room. | |
| 16:49:53 | keisukefukuda enters the room. | |
| 17:07:15 | evan | wonderful |
| 17:07:37 | evan | someone in Russia stole my credit card number. :/ |
| 17:07:55 | loop | ouch |
| 17:09:35 | evan | and they changed $2k |
| 17:11:47 | brixen | yikes |
| 17:11:55 | benburkert leaves the room. | |
| 17:13:54 | Defiler | If they bought a bunch of Apple products and VM books you are going to have a hard time proving it :) |
| 17:14:30 | evan | nope |
| 17:14:32 | evan | Russian Diamonds. |
| 17:14:36 | evan | pretty easy to tell. |
| 17:14:53 | evan | since I've 1) never been to Russia, and 2) Don't be jewelry, esp. diamonds |
| 17:15:11 | Defiler | heh |
| 17:16:55 | jbarnette enters the room. | |
| 17:25:17 | atok leaves the room. | |
| 17:27:23 | foysavas enters the room. | |
| 17:28:07 | brixen | evan: so, a bit of thinking aloud in code: http://gist.github.com/5075 |
| 17:28:42 | brixen | I looked at using multimap, but you can't get all the keys. you get any one of the keys if there are multiple |
| 17:29:07 | brixen | evan: so, my idea is a single map where the values can be chained. and the hash is the key |
| 17:29:18 | brixen | the value has the symbol, string, and next* |
| 17:31:20 | evan | one sec. |
| 17:31:21 | evan | sorry. |
| 17:34:48 | evan | brixen: ok |
| 17:34:55 | evan | i've got a couple of notes |
| 17:35:07 | brixen | k |
| 17:35:16 | evan | 1) probably shouldn't use std:map |
| 17:35:21 | evan | it's not a hash table at all |
| 17:35:26 | evan | it's a balanced tree |
| 17:35:44 | brixen | k |
| 17:36:20 | evan | also |
| 17:36:26 | evan | for this first cut |
| 17:36:39 | evan | lets just use the same data structure setup / algo as we did before |
| 17:36:51 | evan | ie, the table contains a hash and an array |
| 17:36:56 | evan | the hash is used for string => id |
| 17:37:00 | evan | the array is used for id => string |
| 17:37:00 | brixen | well, in that case, what's the reason to switch? |
| 17:37:07 | brixen | why not just replace Hash with LT? |
| 17:37:19 | evan | it's recursive. |
| 17:37:23 | evan | you can't have strings for keys |
| 17:37:28 | evan | unless you symbolize them |
| 17:37:32 | brixen | ah yeah |
| 17:37:34 | evan | but you need the symbol table |
| 17:37:35 | evan | oh crap. |
| 17:37:36 | evan | :) |
| 17:37:52 | brixen | so, you don't like chaining the values? |
| 17:37:57 | brixen | seems simpler |
| 17:38:05 | evan | I don't get what ya mean |
| 17:38:12 | evan | just chaining like a chaining hash table? |
| 17:38:14 | jbarnette | evan: i just started reading, and this is probably irrelevant, but the STL has a pretty comprehensive set of balanced tree stuff |
| 17:38:24 | evan | jbarnette: we don't want a balanced tree |
| 17:38:28 | evan | we want a hash table. |
| 17:38:36 | jbarnette | evan: guess i should scroll up :) |
| 17:38:40 | brixen | evan: ok, so what do I use for a DT? |
| 17:38:52 | evan | whats a DT? |
| 17:38:57 | brixen | data type |
| 17:38:59 | brixen | structure |
| 17:39:34 | michalw enters the room. | |
| 17:39:37 | brixen | i.e. we're removing Hash, so what do I replace it with? |
| 17:39:43 | brixen | I thought that was the point of this? |
| 17:39:58 | evan | well, thats why I was saying, for now, we move it into C++ |
| 17:40:15 | brixen | you want me to impl a C++ only Hash? |
| 17:40:28 | evan | or find one. |
| 17:40:32 | evan | as a first cut though |
| 17:40:35 | evan | you can use std::map |
| 17:41:15 | evan | but we'll need to replace it's usage with a real hash table |
| 17:41:17 | loop | there is tr1::unordered_map |
| 17:41:26 | evan | loop: i've never been able to get it to work |
| 17:41:38 | enebo enters the room. | |
| 17:41:42 | evan | loop: so if you have skills related to that, i'm all ears. |
| 17:41:59 | loop | evan: i think i have some source code that uses it, i'll check it when i get home |
| 17:42:00 | brixen | evan: ok, I'll take a look at it when I return from class |
| 17:42:13 | evan | ok |
| 17:42:30 | evan | brixen: for a first cut, the easiest way to be to port the algo we currently use |
| 17:42:34 | evan | using std::map and std::vector |
| 17:42:40 | brixen | yeah, I see that |
| 17:42:40 | evan | then we can tweak and refactor from there |
| 17:42:44 | brixen | I'll look at unorded_map |
| 17:42:49 | brixen | unordered* |
| 17:43:04 | evan | ok |
| 17:43:18 | evan | Defiler: was there something you wanted me to look at? |
| 17:43:48 | evan | Defiler: wrong (on Qnil) |
| 17:43:53 | Defiler | Yeah. I just want to make sure I understand the impact of the __ivars__ change |
| 17:43:57 | evan | Defiler: Qnil in the ivars field just means it doesn't have any ivars. |
| 17:43:59 | evan | thats all. |
| 17:44:05 | Defiler | For example, I notice that the function for 'hey do you support ivars' always returns TRUE now |
| 17:44:07 | evan | it doesn't mean it can't store any. |
| 17:44:09 | Defiler | OK |
| 17:44:11 | evan | yep |
| 17:44:14 | evan | everything can now |
| 17:44:18 | evan | except for non-references |
| 17:44:32 | evan | which are handled specially in Object::get_ivar and Object::set_ivar |
| 17:45:07 | evan | the impact is that normal classes don't have to declare an __ivars__ slot |
| 17:45:13 | evan | everything gets one |
| 17:45:49 | Defiler | OK, dumb C++ question.. what is really happening when this is declared: typedef Fixnum* FIXNUM; |
| 17:46:08 | loop | Defiler: makes FIXNUM an alias for Fixnum* |
| 17:46:11 | Defiler | sure |
| 17:46:13 | keisukefukuda leaves the room. | |
| 17:46:32 | jbarnette | Defiler: it's purely an alias |
| 17:46:43 | Defiler | but what is so special about Fixnum that it gets one of those, and (for example) Array does not |
| 17:46:44 | evan | it's just for looks |
| 17:46:47 | Defiler | OK |
| 17:46:58 | evan | because FIXNUM is an immediate |
| 17:47:03 | evan | and it looks strange with the * there |
| 17:47:10 | evan | making you think it points into memory |
| 17:47:11 | evan | when it doesn't |
| 17:47:18 | evan | it's for look and feel alone. |
| 17:47:29 | Defiler | and OBJECT has an equivalent typedef for the same reason, etc |
| 17:47:48 | evan | because we type it so much |
| 17:47:56 | Defiler | and hey, it might be a Fixnum anyway |
| 17:47:57 | evan | and I wanted it to feel more opaque |
| 17:48:02 | evan | exactly. |
| 17:50:14 | antares leaves the room. | |
| 17:54:26 | dbussink | Defiler: more happiness for you in my last commit just now :) |
| 17:54:52 | ijcd enters the room. | |
| 17:55:22 | Defiler | dbussink: hot |
| 17:56:47 | CIA-20 | * Copy paste woes, oops; bd6f790 - Dirkjan Bussink |
| 17:58:49 | dbussink | why does it pick up that commit but not the previous one? |
| 17:59:31 | evan | CIA is weird |
| 17:59:33 | evan | is why. |
| 18:00:09 | CIA-20 | * Add some additional assertions for FFI conversions; d8f190f - Dirkjan Bussink |
| 18:00:12 | dbussink | Defiler: what do you think of the new more consistent api? :) |
| 18:00:28 | Defiler | Much nicer |
| 18:01:43 | dbussink | next step i want to do is clean up several to_ methods that convert into another type |
| 18:01:53 | dbussink | to_float or to_f, to_string or to_s etc. |
| 18:01:58 | dbussink | any preference? |
| 18:02:03 | evan | Defiler: i think the answers to those questions, btw, are covered in vm/doc/ARCH.txt |
| 18:02:18 | evan | which is yet another reason we need to get a process for exporting our docs to the web |
| 18:02:37 | Defiler | Aah, so they are |
| 18:02:43 | Defiler | Answered very clearly, in fact. |
| 18:03:45 | evan | alright, i'm going to head to the coffee shop |
| 18:04:28 | dbussink | evan: do i have to regenerate instructions? because i changed some calls there too |
| 18:04:38 | dbussink | if so, how should i do that? |
| 18:04:42 | evan | in instructions.rb you did? |
| 18:04:43 | evan | you change |
| 18:04:46 | evan | you changed, rather. |
| 18:04:51 | dbussink | yeah |
| 18:05:07 | evan | it will do it automatically |
| 18:05:09 | evan | so you're fine |
| 18:05:40 | dbussink | ah, because i saw an instructions.o commit just after my last refactor |
| 18:12:13 | shame leaves the room. | |
| 18:14:31 | krsh leaves the room. | |
| 18:14:46 | dbussink | hmm, the coverage task fails for me |
| 18:15:19 | dbussink | because of the tmpname method that ensures the deletion of a file the coverage tool needs |
| 18:19:21 | octopod leaves the room. | |
| 18:21:08 | evan | dbussink: ack. |
| 18:21:15 | evan | hm, it did work originally for me.. |
| 18:21:21 | CIA-20 | * Modified some wording in vm/doc/ARCH.txt; 845c6ff - Wilson Bilkovich |
| 18:21:27 | evan | i think we're going to go have to go back to gen/ files |
| 18:21:33 | evan | rather than tmp |
| 18:22:34 | BobFunk leaves the room. | |
| 18:38:29 | c0sin enters the room. | |
| 18:45:52 | Defiler | evan: the regexp_new primitive in shotgun sets the 'klass' field on the created Regexp instance, in order to allow it to return subclasses of Regexp |
| 18:46:04 | evan | yep. |
| 18:46:08 | Defiler | evan: It looks to me like that same approach will work here. |
| 18:46:10 | Defiler | Does that sound right? |
| 18:46:12 | evan | yep. |
| 18:46:19 | evan | use SET(other, klass, blah) |
| 18:46:22 | Defiler | yeah |
| 18:46:42 | octopod enters the room. | |
| 18:47:50 | Defiler | Should I do the additional work the primitive wants in a function that then calls Regexp::create, or should I modify create until it does everything the primitive needs? |
| 18:48:01 | Defiler | I ask because it is already pretty long, due to the oniguruma API |
| 18:48:10 | evan | up to you. |
| 18:48:30 | Defiler | I'll do it with a second function first and if it ends up boiling down to one line or something I will change my mind |
| 18:49:34 | evan | ok |
| 18:58:57 | benburkert enters the room. | |
| 18:59:46 | benburkert leaves the room. | |
| 19:02:45 | benburkert enters the room. | |
| 19:04:49 | keisukefukuda enters the room. | |
| 19:05:04 | BlackEdder enters the room. | |
| 19:06:14 | BlackEdder enters the room. | |
| 19:11:38 | keisukef_ enters the room. | |
| 19:11:54 | keisukefukuda leaves the room. | |
| 19:13:04 | tmornini enters the room. | |
| 19:14:22 | tmornini leaves the room. | |
| 19:14:26 | tmornini enters the room. | |
| 19:14:44 | ezmobius enters the room. | |
| 19:23:31 | Arjen_ enters the room. | |
| 19:25:06 | ezmobius leaves the room. | |
| 19:35:32 | joachimm enters the room. | |
| 19:44:37 | BobFunk enters the room. | |
| 19:48:19 | keisukef_ leaves the room. | |
| 19:52:50 | dbussink | dgtized: you there? |
| 19:57:48 | imajes enters the room. | |
| 20:03:10 | cikqc enters the room. | |
| 20:09:59 | BobFunk leaves the room. | |
| 20:11:30 | botanicus leaves the room. | |
| 20:17:43 | octopod leaves the room. | |
| 20:24:38 | chris2 leaves the room. | |
| 20:46:32 | shame enters the room. | |
| 20:48:44 | nari_ enters the room. | |
| 20:50:12 | nari leaves the room. | |
| 20:53:41 | dgtized | yes |
| 20:53:47 | guitsaru enters the room. | |
| 21:01:19 | dbussink | dgtized: i was wondering if you'd be willing to test whether my refactoring broke anything for you |
| 21:01:33 | dbussink | you seem to have the most anal compiler :P |
| 21:01:56 | timo enters the room. | |
| 21:02:38 | dbussink | and you were wondering what all the different types are about? |
| 21:14:43 | dgtized | let me check |
| 21:14:58 | dgtized | yup that compiles clean |
| 21:15:29 | dgtized | it just seems we can't use native_int as a parameter for a function |
| 21:15:35 | dgtized | we have to provide a int and long |
| 21:15:53 | dgtized | unless we can guarentee that only native_ints will be passed to the function |
| 21:16:22 | benny enters the room. | |
| 21:17:19 | yroc enters the room. | |
| 21:20:15 | ezmobius enters the room. | |
| 21:23:25 | Fullmoon enters the room. | |
| 21:27:30 | Defiler | evan: Got a question about cpp primitives and subclasses |
| 21:27:40 | evan | ok |
| 21:27:41 | evan | wassup |
| 21:27:53 | Defiler | Let's say we have "string_new" |
| 21:28:04 | Defiler | and class MyString < String |
| 21:28:40 | Defiler | We need to make sure that the string we create has MyString as its klass field, etc, etc. |
| 21:28:44 | Defiler | So two questions.. |
| 21:29:22 | Defiler | OK, one question.. do we have a generic way to get at the receiver of a primitive other than 'this'? |
| 21:29:36 | Defiler | Because 'this' can't be used in static functions, and we have various static prims |
| 21:31:02 | dbussink | dgtized: well, the reason for all the types is mainly because of FFI |
| 21:31:03 | evan | ah ha! |
| 21:31:13 | evan | Defiler: I had this thought too. |
| 21:31:25 | dbussink | dgtized: which has to handle all those types coming from C functions, internally only native_int is used |
| 21:31:31 | Defiler | My current idea is to ask the active task what the recevier is |
| 21:31:36 | Defiler | but I'm not all that sure that is the right way |
| 21:31:38 | evan | it doesn't know. |
| 21:31:39 | dbussink | dgtized: that's why Fixnum::from only has a version for native_int |
| 21:31:56 | Defiler | I thought task had a 'self' accessor? |
| 21:31:56 | evan | Defiler: that would work, but the active context's self isn't set to the receiver of a primitive |
| 21:32:09 | Defiler | ah |
| 21:32:09 | evan | yeah, but it's the self of the context that called the primitive |
| 21:32:11 | Defiler | brutal |
| 21:32:12 | evan | not the primitive itself. |
| 21:32:18 | Defiler | makes sense though |
| 21:32:31 | evan | we should just extend field_extract a little |
| 21:32:46 | Defiler | changing 'self' inside a method, which is what the effect would be, would probably lead to fun |
| 21:32:47 | evan | have it check if the 2nd argument is 'OBJECT self' |
| 21:32:49 | evan | if it is |
| 21:32:55 | evan | pass the primitive receiver in |
| 21:33:37 | Defiler | is task->active->primitive a bad idea to add? |
| 21:33:48 | evan | yes. |
| 21:33:51 | evan | well, what would it do? |
| 21:34:16 | evan | typically, adding new fields to MethodContext should be avoided |
| 21:34:41 | Defiler | I was imagining that it might contain information about the currently-executing primitive, if any |
| 21:34:48 | Defiler | but you are right, MC has enough jobs already |
| 21:35:01 | Defiler | What with bustin' phat rhymes and all |
| 21:35:13 | evan | yeah, it's a tough job throwin' it down. |
| 21:35:23 | jbarnette | AND keepin' it real |
| 21:35:39 | Defiler | Representin' can indeed be a burden. |
| 21:35:55 | jbarnette | mo money, mo problems |
| 21:36:09 | Defiler | OK, so field_generator is the plan? |
| 21:36:23 | evan | yeah |
| 21:36:30 | evan | you want to tackle that? |
| 21:36:36 | Defiler | Sure |
| 21:36:37 | evan | oh awit |
| 21:36:39 | evan | hold up. |
| 21:36:40 | Defiler | k |
| 21:36:59 | evan | I made a change to field_gen earlier today |
| 21:37:03 | evan | let me commit it first |
| 21:37:14 | evan | so you're working against the real deal. |
| 21:37:19 | Defiler | Sweet |
| 21:37:33 | evan | er. |
| 21:37:37 | evan | we're talking about field_extract |
| 21:37:38 | evan | btw. |
| 21:37:44 | evan | not sure why I was calling it field_gen |
| 21:38:20 | evan | alright, the shiz is in. |
| 21:38:23 | CIA-20 | * Add ability to have custom mark logic; c785864 - Evan Phoenix |
| 21:38:23 | CIA-20 | * Fix glue generation for static methods; 53f3ce1 - Evan Phoenix |
| 21:38:24 | Defiler | It's all good. I speak evan pretty fluently these days I think |
| 21:41:31 | Defiler | So, do I just want to emulate what 'pass_state' does, but for 'pass_receiver'? |
| 21:41:45 | evan | sue |
| 21:41:47 | evan | sure |
| 21:41:47 | Defiler | 'punt_returner' |
| 21:41:55 | evan | hah |
| 21:41:59 | evan | 'score_touchdown' |
| 21:42:14 | evan | 'chopblock_tightend' |
| 21:42:23 | Defiler | OK we totally need a function with that name |
| 21:42:29 | evan | which? |
| 21:42:33 | Defiler | chopblock |
| 21:42:44 | evan | heh |
| 21:42:51 | ezmobius leaves the room. | |
| 21:59:30 | octopod enters the room. | |
| 22:01:20 | ezmobius enters the room. | |
| 22:03:01 | wmoxam leaves the room. | |
| 22:03:52 | imajes leaves the room. | |
| 22:03:58 | AndrewO leaves the room. | |
| 22:11:59 | yroc leaves the room. | |
| 22:25:36 | pauldix leaves the room. | |
| 22:38:41 | headius enters the room. | |
| 22:44:23 | Maledictus leaves the room. | |
| 22:48:00 | shame leaves the room. | |
| 22:50:12 | shame enters the room. | |
| 22:50:18 | shame leaves the room. | |
| 22:51:13 | blakewatters leaves the room. | |
| 22:51:14 | Defiler | evan: What kind of 'flags' are supported by // slot? |
| 22:51:21 | evan | flags? |
| 22:51:34 | evan | none? |
| 22:51:35 | Defiler | the field extractor looks for a pattern after // slot |
| 22:51:40 | Defiler | and calls it 'flag' |
| 22:51:57 | Defiler | which it then passes to 'add_field' along with the index, name, and type |
| 22:52:11 | evan | oh |
| 22:52:12 | evan | readonly |
| 22:52:14 | evan | is the old flag |
| 22:52:16 | evan | only |
| 22:52:25 | Defiler | I don't see any usage of it. can I remove it? |
| 22:52:29 | evan | you can see that in all_fields |
| 22:52:31 | evan | no |
| 22:52:35 | evan | it's supposed to be in use. |
| 22:52:40 | evan | someone must have remove it |
| 22:52:52 | Defiler | What's an example slot that would have this flag on it? |
| 22:53:16 | evan | Tuple* look_but_dont_touch; // slot readonly |
| 22:54:11 | Defiler | I mean in the existing VM |
| 22:54:36 | evan | there are potentialy a number of them |
| 22:54:48 | Defiler | OK. Cool. |
| 22:55:53 | Defiler | Do we need a generic flag concept, or should we consider just supporting readonly directly? |
| 22:56:11 | evan | well, it's not really generic |
| 22:56:13 | evan | as you can see |
| 22:56:14 | Defiler | yeah |
| 22:56:22 | evan | the only thing that can be detected is readonly |
| 22:56:28 | evan | so the code is already doing that. |
| 22:56:30 | Defiler | I'm just thinking that // readonly_slot would be less code |
| 22:56:34 | evan | no |
| 22:56:50 | evan | less code in field_extract, more confusing in the cpp |
| 22:56:50 | Defiler | or even just // slot readonly explicitly in the pattern |
| 22:56:58 | enebo leaves the room. | |
| 22:56:58 | evan | nah |
| 22:57:10 | evan | do I need to pull you out of the rabit hole? |
| 22:57:12 | evan | rabbit |
| 22:57:12 | Defiler | No |
| 22:57:28 | Defiler | Just wanting to make sure I understand the feature set of field_extract |
| 22:57:42 | Defiler | Since I get yelled at whenever I ask a question that is answered by this code. :) |
| 23:01:02 | headius | evan: saw your response...ok |
| 23:01:32 | evan | headius: for an array type, does it use the same header as other objects? |
| 23:01:36 | evan | headius: or a more compact one? |
| 23:01:40 | headius | it's a more compact one |
| 23:01:43 | michalw leaves the room. | |
| 23:02:05 | evan | ok |
| 23:02:14 | headius | the only methods you can call on arrays are those that exist on Object...they're objects, but not really full Class types in themselves |
| 23:02:14 | evan | I play with that idea a little last night and this morning. |
| 23:02:30 | evan | well |
| 23:02:38 | evan | then they have some primitive operations I assume |
| 23:02:50 | evan | who's usage is decided upon using static typeing |
| 23:04:48 | headius | yes, primitive operations include accessing elements and length |
| 23:05:48 | headius | bytecodes for each array store/load operation per component type (reference or one of the primitives) and a single bytecode for array construction |
| 23:06:36 | headius | for a VM with no primitives, obviously they could all just be reference or handle operations |
| 23:07:21 | headius | it's largely because of the array bytecodes that JVM can eliminate boundschecking, unroll array element iteration loops, and so on |
| 23:07:43 | evan | so there are array_get_int, array_get_byte, array_get_bool, etc bytecodes? |
| 23:08:02 | headius | yes |
| 23:08:12 | headius | and one for object references |
| 23:08:53 | headius | in-memory the primitive arrays are C + N |
| 23:08:55 | headius | er |
| 23:08:57 | headius | C + N * element size |
| 23:08:59 | headius | where C is some constant header size and N is number of elements |
| 23:09:02 | moofbong leaves the room. | |
| 23:09:12 | headius | so an array of bytes is actually byte-sized elements |
| 23:09:39 | evan | sure |
| 23:09:46 | evan | normal C semantics. |
| 23:09:55 | headius | but it's worth noting that most other primitive references are 32-bit always |
| 23:10:20 | evan | there isn't 64bit integer or float? |
| 23:10:36 | headius | there is, but they're not atomic 64-bit operations |
| 23:10:56 | headius | so a 64-bit long field on a class needs to be synchronized if it's read/written across threads |
| 23:11:06 | headius | not an issue that comes up in practice much though |
| 23:11:25 | headius | and that may not be the case on 64-bit JVMs...more an impl detail |
| 23:11:46 | headius | of more import is the fact that no field reference ever takes up less than 32 bits |
| 23:11:47 | evan | ok |
| 23:11:57 | headius | byte, short, whatever...a field is at least 32 bits always |
| 23:12:33 | headius | so for example there's more int (32-bit) operations than ops for <32bit |
| 23:12:38 | evan | but one byte doesn't use 32bits per byte, right? |
| 23:12:49 | headius | it does except when it's in an array |
| 23:12:57 | headius | everywhere else it takes up a full 32-bit slot |
| 23:13:01 | evan | right, ok. |
| 23:13:20 | headius | and of course the stack is uniformly 32 bit |
| 23:13:32 | headius | which is largely why long operations aren't natively atomic |
| 23:14:14 | headius | at any rate, array types are a special class of object in memory |
| 23:15:54 | headius | some of these articles might be interesting to you |
| 23:15:55 | headius | http://wikis.sun.com/display/HotSpotInternals/Home |
| 23:16:41 | evan | k |
| 23:16:49 | bremac2 enters the room. | |
| 23:16:51 | headius | hotspot in general would probably be interesting to you since it's largely modeled after smalltalk VMs and the core is C++ |
| 23:18:06 | evan | headius: whats present in an empty JVM? |
| 23:18:33 | headius | well, that's a good question |
| 23:18:53 | headius | a mix of a lot of C++, ASM, and Java code |
| 23:18:55 | headius | probably mostly Java code |
| 23:19:01 | evan | i mean |
| 23:19:04 | evan | if you boot up the jvm |
| 23:19:11 | evan | what stuff is already loaded in? |
| 23:19:17 | evan | the java core library? |
| 23:19:42 | headius | not the entire library...but all classes (Java and C++) needed for the basic bootstrapping |
| 23:19:45 | binary42 leaves the room. | |
| 23:20:03 | BobFunk enters the room. | |
| 23:20:04 | headius | which includes some filesystem-related classes for loading, classloaders, bytecode verifiers |
| 23:20:25 | headius | a bytecode interpreter, memory manager, maybe a JIT |
| 23:20:44 | evan | but most of that isn't exposed in java-land |
| 23:20:55 | evan | thats all stuff loaded under-the-hood |
| 23:21:00 | headius | very little of it is exposed directly, a lot of it never exposed |
| 23:21:25 | headius | for userspace, JVM only presents the set of core classes in java.lang on boot |
| 23:21:56 | headius | file:///Users/headius/java6-docs/api/java/lang/package-summary.html |
| 23:21:57 | headius | er |
| 23:21:58 | headius | oops |
| 23:22:10 | headius | http://java.sun.com/j2se/1.5.0/docs/api/java/lang/package-summary.html |
| 23:23:04 | headius | the smallest JVMs might *only* expose that set of classes |
| 23:25:27 | headius | on my system a simple Java class that starts up and immediately sleeps takes about 10MB of memory |
| 23:25:48 | evan | ok |
| 23:26:11 | headius | a script that sleeps in JRuby starts up around 20MB |
| 23:28:11 | evan | gotcha |
| 23:28:45 | shame enters the room. | |
| 23:30:47 | octopod leaves the room. | |
| 23:31:36 | edwardam enters the room. | |
| 23:33:46 | c0sin leaves the room. | |
| 23:34:14 | Arjen_ leaves the room. | |
| 23:36:35 | BobFunk leaves the room. | |
| 23:36:36 | codebrulee enters the room. | |
| 23:38:11 | BobFunk enters the room. | |
| 23:45:44 | Fullmoon leaves the room. | |
| 23:46:44 | Fullmoon enters the room. | |
| 23:47:03 | ch0wda leaves the room. | |
| 23:47:42 | cyndis leaves the room. | |
| 23:49:07 | c0sin enters the room. | |
| 23:49:54 | c0sin leaves the room. | |
| 23:56:36 | yipstar leaves the room. | |
| 23:58:29 | cyndis enters the room. |