Show enters and exits. Hide enters and exits.
| 00:01:05 | cremes | aniero: i tried to fix fattr a few months back but i couldn't figure it out; that code was hard for me to grok |
| 00:01:08 | cremes | good luck with it |
| 00:12:07 | aniero | cremes: heh, thanks |
| 00:43:24 | boyscout | Cleanup loading extensions, provide MRI extension detection - cac8158 - Evan Phoenix |
| 00:48:57 | evan | dbussink: you're asleep, I assume. |
| 00:52:41 | boyscout | CI: rubinius: cac8158 successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 01:45:19 | boyscout | Remove custom sorting logic in Enumerable, use Array. - ddc4d8a - Evan Phoenix |
| 01:53:26 | boyscout | CI: rubinius: ddc4d8a successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 03:58:18 | DeM0nFiRe | Hello |
| 03:59:27 | DeM0nFiRe | I am wondering if anyone here has a lot of experience working with object oriented VMs (like Ruby's) from the C/C++ side |
| 04:06:08 | postmodern | is there a channel just for RubySpec? |
| 04:06:30 | DeM0nFiRe | Yeah |
| 04:06:32 | DeM0nFiRe | #rubyspec :P |
| 04:26:25 | brixen | DeM0nFiRe: what do you mean by experience? |
| 04:26:59 | DeM0nFiRe | Well, ideally I would like someone who's programmed an OOVM, but at least someone who's done a lot of poking around in them and knows the concepts behind it |
| 04:27:20 | DeM0nFiRe | There's probably all of about seven people in the world who have actually programmed one, haha |
| 04:27:56 | brixen | well, Rubinius is an OOVM, if by OOVM you mean implemented in an OO language (which C++ qualifies, I think) |
| 04:29:00 | slava | what's an OOVM? |
| 04:29:01 | DeM0nFiRe | Well, for what I am talking about C++ does not qualify since the actual data is not processed as objects. By an OOVM I mean the virtual machine itself is object oriented |
| 04:29:40 | DeM0nFiRe | So the virtual machine's memory stores objects, and the opcodes would be for manipulating objects, not data, if that makes sense |
| 04:29:52 | slava | you're thinking about things in the wrong way |
| 04:30:06 | DeM0nFiRe | Why would you say that? |
| 04:30:18 | slava | interpreter opcodes are an implementation detail |
| 04:30:46 | slava | whether or not the language running on the VM is object oriented, the choice of opcodes doesn't really matter |
| 04:32:31 | brixen | is still lost on opcodes manipulating objects, not data |
| 04:32:42 | slava | usually data is objects is data :) |
| 04:32:43 | DeM0nFiRe | I probably just didn't use the right word. What I need is a virtual machine that manipulates objects as objects, not as data. Obviously this virtual machine itself would be running in the native environment which is not object oriented |
| 04:32:50 | brixen | has a nice head-cold haze too though |
| 04:33:04 | slava | terms such as data and object are pretty vague |
| 04:33:20 | brixen | indeed |
| 04:33:21 | DeM0nFiRe | Yeah, I know, it's not easy to communicate what I am thinking because of that, haha |
| 04:33:22 | slava | does your language have an Object type at the root of the hierarchy or not? :) |
| 04:33:43 | DeM0nFiRe | Yes, the language will have Object as being the lowest level you can get. No primitives |
| 04:34:22 | slava | actually why is that an advantage? |
| 04:34:51 | DeM0nFiRe | Well, for what I have planned, it will make it easier to go from C++ to script |
| 04:34:59 | slava | the JVM's primitive support allows you to pack binary data more efficiently in memory |
| 04:35:07 | slava | you can store numbers directly in objects and arrays without boxing everything |
| 04:35:29 | DeM0nFiRe | Yeah, for sure doing it other ways is faster and more memory efficient, but I am willing to sacrifice some of that for this |
| 04:35:30 | slava | as far as the java language's support for primitives and how they're exposed at the syntax, that's a different matter |
| 04:35:42 | DeM0nFiRe | By easier to go from C++ to script I mean |
| 04:35:52 | DeM0nFiRe | That you could take some existing C++ engine. say Irrlicht |
| 04:36:45 | DeM0nFiRe | And easily be able to create a C++ app using Irrlicht which lets the script actually create and destroy objects. If anyone's used Irrlicht here, that would be letting the script easily create and modify SceneNodes |
| 04:37:12 | slava | if you want to script existing C libraries and embed a dynamic language interpreter in your app, you might want to take a look at Lua |
| 04:37:39 | DeM0nFiRe | I have taken a look at Lua, I decided against it because of the syntax of the language itself, but thanks for the suggestion |
| 04:37:58 | slava | JavaScript can be embedded too |
| 04:38:06 | slava | JavaScriptCore and V8 have embedding APIs |
| 04:39:10 | DeM0nFiRe | Yeah, I have looked at those as well, but that's more of where you define a JavaScript object as being a group of otherwise disjointed C or C++ functions and such, it's not easy to embed in an existing engine because you have to manually define each object in a kind of long process |
| 04:39:31 | slava | well, there's no easy automated way to bind to C or C++ libraries anyway |
| 04:39:45 | DeM0nFiRe | I know there isn't, that's why I want to make it :P |
| 04:39:47 | DeM0nFiRe | Well |
| 04:40:06 | DeM0nFiRe | Sort of, obviously there will have to be some kind of process |
| 04:40:09 | slava | every dynamic language has its own way of interfacing with native code |
| 04:40:32 | DeM0nFiRe | Yep, exactly |
| 04:40:49 | slava | sounds like all you need to do is look around and find one that matches what you need |
| 04:41:11 | DeM0nFiRe | Well, I am pretty sure at this point that one doesn't exist, I've been looking for quite some time now, hehe |
| 04:41:13 | slava | for embedded scripting another one to look at is Io |
| 04:41:39 | slava | are you sure that between Lua, JS and Io you can't find a decent scripting engine to embed inside your app? |
| 04:41:52 | slava | what about Guile |
| 04:42:05 | slava | that's Scheme-based so it might be a bit more flexible |
| 04:42:22 | slava | everyone wants to make their own language :) |
| 04:42:32 | DeM0nFiRe | What's the license? Is it GPL? |
| 04:42:57 | slava | ask google |
| 04:43:07 | DeM0nFiRe | The license is kind of important, because if I get anywhere with what I am doing, I'd like to MIT/zlib it |
| 04:44:13 | DeM0nFiRe | Anyway, it's also not a bad idea for me to try this project from the ground up as a learning experience, anyway |
| 04:44:18 | slava | sure |
| 04:44:21 | slava | it depends on what your goals are |
| 04:44:33 | slava | do you want to spend a few years working on an OSS project or do you take an off the shelf solution and build your app around it |
| 04:45:09 | slava | if you're more interested in interfacing with C code than with language design, you might want to help out one of the FFI projects for an existing language implementation in any case |
| 04:45:13 | DeM0nFiRe | Well, I've been saying an existing engine like Irrlicht but really it's because I am wiorking on my own engine. and I really don't want to have to change how I code the engine for the language I use for scripting |
| 04:45:48 | DeM0nFiRe | When you take all of my goals, they add up to something that definitely has not been done before. I can live without most of them, since they were added once I decided to try to make the language and VM myself |
| 04:46:29 | DeM0nFiRe | But the key is that it's got to be easy for someone to write normal C++ code and then script the app with the language without having to spend a bunch of time and effort bridging the two |
| 04:46:47 | DeM0nFiRe | Oh, and it has to be an OO language that isn't retarded, haha XD |
| 04:46:57 | Defiler | people generally just embed Lua and call it a day :) |
| 04:46:59 | slava | what if you just kill two birds with one stone and use something like C# or Ocaml for the project :) |
| 04:47:01 | Defiler | it's quite good for this |
| 04:47:13 | slava | instead of using C++ with a scripting language |
| 04:47:15 | DeM0nFiRe | I mean, JavaScript isn't retarded, but prototypical OO isn't my thing |
| 04:47:32 | DeM0nFiRe | Well, I definitely want C++, the stuff I need to do, I need to do in C#, I can't imagine this engine being coded in C# |
| 04:47:47 | slava | you'd be surprised how fast modern C# and Java implementations are |
| 04:47:55 | Defiler | C++ is the most painful scripting language imaginable |
| 04:47:57 | slava | don't pick a language prematurely |
| 04:48:00 | DeM0nFiRe | I know it sounds strange saying I am sacrificing performance in the scripting language, but for the engine I can't |
| 04:48:17 | Defiler | but if you're building a game engine you have to be able to twiddle words |
| 04:48:25 | slava | not necessarily |
| 04:48:36 | slava | nothing in the problem domain inherently requires low level memory access, etc |
| 04:48:39 | DeM0nFiRe | slava: I didn't pick it prematurely, heh, I really really like C++ for doing core programming |
| 04:49:02 | slava | its not like device driver programming where you really do need to touch memory to get anything done |
| 04:49:10 | slava | a game engine manipulates objects like most other things |
| 04:49:11 | Defiler | quake, for example, uses the trick of operating on subsets of the bits of ieee floats |
| 04:49:17 | Defiler | good luck doing that in C# |
| 04:49:18 | slava | you can do that in Java |
| 04:49:20 | slava | eh |
| 04:49:26 | DeM0nFiRe | slava actually, my engine will be able to theoretically run cross platform (atm, Linux cannot support the OpenGL versions I am using, so technically it can't run there yet) |
| 04:49:36 | Defiler | without getting it handled as an IEEE float by the cpu? |
| 04:49:38 | slava | both JVM and CLR support double <-> long and float <-> int puns |
| 04:49:49 | Defiler | the whole point is to avoid that, and just treat it as a region of memory |
| 04:49:52 | slava | so you can definitely do bitwise math on floats very cheaply |
| 04:49:53 | DeM0nFiRe | And so I will be doing a sort of mini lightweight file system that will require working with void memory pointers and such |
| 04:50:13 | slava | Defiler: I'm pretty sure Java's Double.doubleToLongBits() and longBitsToDouble() compile as no-ops or register moves only |
| 04:51:12 | DeM0nFiRe | For what I am doing, C++ is definitely what I need. Especially since the way I am coding it is like other existing engines, so even though I don't want to use Lua, someone else could use Lua just fine with it |
| 04:51:34 | Defiler | I mean for |
| 04:51:34 | Defiler | http://scholar.google.com/scholar?hl=en&lr=&cites=10407872751027742461&um=1&ie=UTF -8&sa=X&ei=wJIhTNXlM8T_lgfmrfDHAQ&ved=0CBQQzgIwAA |
| 04:51:42 | DeM0nFiRe | C++ will give me the best performance, portability, low level access etc. that I need, I'm definitely in the right language heh |
| 04:51:45 | Defiler | http://scholar.google.com/scholar?cluster=10407872751027742461&hl=en&as_sdt=20000000000 |
| 04:52:01 | Defiler | game engine C++ isn't going to be all that portable heh |
| 04:52:06 | slava | and the best compile time and the best compile error messages |
| 04:52:30 | DeM0nFiRe | Defiler: Nah, if you know how to write portable code you are good |
| 04:53:09 | DeM0nFiRe | Basically the only 2 things in my plans thus far that limit where it can work are OpenGL support in other OSes (Nothing I can do about that) and my file system will load files from an encrypted MS cab, which only works on Windows |
| 04:53:17 | DeM0nFiRe | But later, if I want, I can replace that file format |
| 04:53:30 | DeM0nFiRe | I am just using it because it's the most secure I could find that was easy to work with |
| 04:53:42 | slava | secure? |
| 04:53:48 | Defiler | I mean when you take advantage of platform-specific features for performance reasons, you by necessity become something that needs porting |
| 04:54:07 | DeM0nFiRe | slava: It's not the normal compression algorithm I am using |
| 04:54:16 | DeM0nFiRe | I am using a full 16 round blowfish with a 592 bit key |
| 04:54:35 | slava | why are you encrypting your data file? |
| 04:54:41 | slava | if your code can decrypt it, so can another progrma |
| 04:54:47 | slava | you can't hide the key in the executable in any meaningful way |
| 04:54:57 | DeM0nFiRe | Well, it makes it harder, that's all. |
| 04:55:13 | DeM0nFiRe | Ie, joe schmoe can't just take the stuff and start using |
| 04:55:28 | DeM0nFiRe | Obviously it's impossible to protect it 100% |
| 04:55:59 | DeM0nFiRe | Even if you could hide the key in a meaningful way, the data's got to be unencrypted in memory at some point. someone could nab it then |
| 04:56:27 | matthewd | DeM0nFiRe: Then why not use a trivial xor or something? |
| 04:57:12 | DeM0nFiRe | Heh, sounds better for marketing this way. I mean, if you have the right key, it's a reasonably fast algorithm, but also currently impossible to break without knowing thekey or a brute force |
| 04:57:14 | matthewd | Is there a real subset of people who'd get past "I can't just grab this and use it as is", but not think to go looking for the decryption key? |
| 04:57:24 | DeM0nFiRe | And unless you get lucky, a brute force isn't gonna break a 592 bit key :P{ |
| 04:57:37 | Defiler | also, why not just aes block cipher a gzip blob |
| 04:57:54 | Defiler | and use your mother's maiden name and the sha1 of the release binary as the key |
| 04:57:58 | DeM0nFiRe | The cab file also has really good compression |
| 04:58:04 | Defiler | and then magically hash-collide it into the binary |
| 04:58:17 | Defiler | :) |
| 04:58:56 | DeM0nFiRe | On one test I saw, the file size was half of like zip |
| 04:59:31 | DeM0nFiRe | About 15 percent or so smaller than Tar + Gzip |
| 04:59:38 | DeM0nFiRe | Anyway, I mean |
| 04:59:48 | DeM0nFiRe | I will make it modular, won't be hard to pick different file types later but |
| 04:59:50 | Defiler | cab is a good format, yeah |
| 05:00:01 | Defiler | there are better things now though |
| 05:00:35 | DeM0nFiRe | I found a publically available library that does it, which is great because even though everyone knows the exact algorithm for ecnryption, no one knows how to break it |
| 05:01:00 | DeM0nFiRe | So a publicly available library will suffice, I can just pop it in, so there's tons less thinking involed |
| 05:01:28 | DeM0nFiRe | I don't plan to support macs, and Linux can't support OGL 3.3/4.0 so I don't need to worry about CP yet, I just have to make sure it's easy to make it CP later |
| 05:01:39 | DeM0nFiRe | Which so far will mean just changing to a different file format |
| 05:02:01 | Defiler | actually, do you know about this? http://sourceforge.net/projects/libxad/ |
| 05:02:13 | Defiler | supports everything ever |
| 05:02:23 | DeM0nFiRe | Haha |
| 05:02:33 | DeM0nFiRe | What type of ecnryption algorithms does it have? |
| 05:05:53 | DeM0nFiRe | Anyway, back to the original discussion, anyone here have any experience with how to actually implement an OOVM? I mean, I am not totally lost, there's just some ideas I want to bounce around |
| 05:06:13 | slava | you might want to start by studying some classic texts |
| 05:06:18 | slava | such as the Smalltalk blue book |
| 05:06:22 | slava | that's how evan got started anyway |
| 05:06:47 | brixen | DeM0nFiRe: I'm still trying to understand what issues are specific to an OOVM |
| 05:07:03 | brixen | opcodes just mutate some stuff typically |
| 05:07:04 | DeM0nFiRe | Well, like I said, I am not needing someone to talk about the basics of it with, I'm pretty well set on that. I just mainly want to talk with someone about keeping it easily accesible thorugh C++ |
| 05:07:09 | brixen | why does the format matter? |
| 05:07:30 | DeM0nFiRe | Well, there will be no bytecode, so opcodes are the lowest level of instruction |
| 05:07:40 | Defiler | and read this http://www.amazon.com/Virtual-Machines-Versatile-Platforms-Architecture/dp/1558609105 |
| 05:07:41 | brixen | keeping what easily accessible? |
| 05:07:57 | DeM0nFiRe | Keeping the objects and classes that are exposed to the script easily accessible |
| 05:07:58 | brixen | DeM0nFiRe: I'm using opcode/bytecode/instruction as synonyms |
| 05:08:02 | Defiler | (which, by the way, has a kindle edition now) |
| 05:08:23 | DeM0nFiRe | Well, like I said, I am not looking for someone to help me with the basics of VMs or even with OOVMs |
| 05:08:41 | Defiler | what are you looking for? you're probably in the right channel to talk about vms |
| 05:08:57 | brixen | so, you want a calling convention in your script that will transparently bind/call a C++ method? |
| 05:09:14 | Defiler | ok, I see what you are asking |
| 05:09:18 | DeM0nFiRe | brixen, that's pretty close to what I want, but not quite |
| 05:09:19 | Defiler | ok, your 'scripts' will be C++ |
| 05:09:38 | Defiler | and your engine just uses, say, LLVM to take in that C++ at runtime and link it into memory |
| 05:09:50 | DeM0nFiRe | I don't need the scripts to be able to arbitratily call C++ methods and such, I am OK with C++ having to explicitly allow it (Actually, that's what I prefer) |
| 05:10:12 | DeM0nFiRe | But I just want the actual code to expose C++ to the script to be non intrusive |
| 05:10:24 | Defiler | yeah, check out LLVM |
| 05:10:52 | brixen | DeM0nFiRe: we have a way of calling C++ primitives from Ruby |
| 05:11:02 | brixen | DeM0nFiRe: it requires a bit of infrastructure |
| 05:11:14 | DeM0nFiRe | Specifically for Rubinius or from the Ruby C API? |
| 05:11:22 | brixen | for Rubinius |
| 05:11:28 | brixen | the MRI C-API is in C |
| 05:11:36 | DeM0nFiRe | Oh, got any docs or anything I can look at? |
| 05:11:57 | brixen | not any really up-to-date docs, but I can take you through it |
| 05:12:09 | brixen | do you happen to have the rbx repo cloned locally? |
| 05:12:18 | DeM0nFiRe | brixen, you are not by any chance familiar with Irrlicht, are you? |
| 05:12:26 | brixen | no I'm not |
| 05:12:42 | DeM0nFiRe | No, I actually don't even have Rubinius, I came here because I knew people here would know at least generally what I am talking about, haha |
| 05:12:58 | brixen | well, it would be easiest to show you in code |
| 05:13:03 | brixen | but I can also describe it |
| 05:13:24 | brixen | basically, we want to be able to call a Ruby method, but in effect, we are calling a C++ method |
| 05:13:40 | brixen | so, we have a special construct that the Ruby compiler recognizes |
| 05:13:54 | brixen | and we parse the C++ .hpp files to pick up the C++ method signatures |
| 05:14:12 | brixen | then we generate a bunch of C++ code as glue that actually invokes the C++ method |
| 05:14:23 | DeM0nFiRe | Oh, Rubinius can do this automatically? |
| 05:14:34 | brixen | kinda automatically |
| 05:14:39 | brixen | there is some ceremony |
| 05:14:49 | brixen | I'll show you some code... |
| 05:14:50 | DeM0nFiRe | Because my plan involved doing something kind of similar, yeah, obviously there's some work involved |
| 05:15:23 | Defiler | http://clang.llvm.org/features.html#libraryarch |
| 05:15:31 | DeM0nFiRe | In my idea, the C++ developer would create a factory of factories that would define which C++ objects you can create, and then in that factory of factories you would actually define how the C++ works with the script |
| 05:15:41 | brixen | DeM0nFiRe: would you be able to do: git clone git://github.com/evanphx/rubinius.git |
| 05:15:48 | brixen | DeM0nFiRe: I could take you through some files |
| 05:16:03 | DeM0nFiRe | I don't have git installed atm, sorry |
| 05:16:08 | brixen | ok |
| 05:16:39 | DeM0nFiRe | I mean, if it would make it that much easier, I can get it tomorrow and you can wait to walk me through it til then |
| 05:16:57 | Defiler | http://llvm.org/docs/FAQ.html#translatecxx |
| 05:17:22 | DeM0nFiRe | the question I have, brixen, is how would Rubinius handle a fairly complex inheritance structure |
| 05:17:42 | Defiler | rubinius doesn't do it the way you're talking about |
| 05:17:52 | Defiler | (nor does any existing language vm that I know of) |
| 05:18:03 | DeM0nFiRe | I know it doesn't do it with a factory of factories |
| 05:18:16 | DeM0nFiRe | BUt I mean when it looks through hpp code to generate the glue |
| 05:18:22 | brixen | DeM0nFiRe: rbx binds a Ruby method directly to a C++ method |
| 05:18:29 | Defiler | objects are sequences of bits, some of which are used as a header |
| 05:18:39 | brixen | DeM0nFiRe: http://github.com/evanphx/rubinius/blob/master/kernel/bootstrap/fixnum.rb#L48 |
| 05:19:23 | Defiler | it doesn't sound to me like you want a VM at all |
| 05:19:24 | DeM0nFiRe | So brixen is that the ceremony, having to call Ruby,primitve :symbolname |
| 05:19:37 | Defiler | you just want to be able to include external C++ code as 'scripts' at runtime |
| 05:19:41 | DeM0nFiRe | . not , |
| 05:19:48 | DeM0nFiRe | Defiler: No, that's not what I want |
| 05:19:48 | brixen | DeM0nFiRe: http://github.com/evanphx/rubinius/blob/master/vm/builtin/fixnum.hpp#L81-82 |
| 05:19:50 | Defiler | that's just a hint to the compiler essentially |
| 05:20:06 | Defiler | that emits a call to the c++ method behind the scenes |
| 05:20:20 | brixen | DeM0nFiRe: the // Ruby.primitive! :fixnum_div comment is processed |
| 05:20:27 | DeM0nFiRe | I don't want to run C++ as script, I want to set up the application using C++ and then let the script work with C++ objects at the same times as being able to creat eit's own |
| 05:20:58 | Defiler | I thought you wanted to script it in the same language |
| 05:21:03 | DeM0nFiRe | No, I don't |
| 05:21:16 | Defiler | if not, just embed Lua, and include primitive functions for doing the domain work your engine needs |
| 05:21:21 | Defiler | I dunno, Scene.new etc etc |
| 05:21:25 | DeM0nFiRe | I don't like Lua |
| 05:21:34 | Defiler | ok, embed your favorite scripting language |
| 05:21:35 | DeM0nFiRe | Oh, you werent' the one I was talking to when I said that, hehe |
| 05:21:36 | brixen | DeM0nFiRe: this is the script that generates the C++ glue code http://github.com/evanphx/rubinius/blob/master/vm/codegen/field_extract.rb |
| 05:21:49 | DeM0nFiRe | Nah, no existing language combines a syntax I like all the other features I need |
| 05:22:05 | Defiler | well, your users are the ones that need to like it |
| 05:22:20 | Defiler | and lua is used for engine scripting all around, so it would make your code more applicable |
| 05:22:24 | Defiler | but up to you of course |
| 05:22:35 | DeM0nFiRe | Haha, well, if someone else wants to use Lua, they can, the engine will be one that is coded similarly to existing engines |
| 05:22:43 | Defiler | building an engine and designing and implementing a scripting language don't seem like projects I'd want to take on simultaneously |
| 05:22:53 | DeM0nFiRe | So if someone wants to embed lua and do the bindings etc. they can do that just as they normally would |
| 05:23:01 | DeM0nFiRe | Hehe, well, I am a masochist :D |
| 05:23:07 | DeM0nFiRe | No, actually, I just HATE game logic scripting |
| 05:23:20 | Defiler | ok, then you just need to design and implement your scripting language |
| 05:23:26 | Defiler | and when you do that, do it as a c++ shared library |
| 05:23:33 | Defiler | then embed it in your engine and you are done |
| 05:23:57 | Defiler | you won't need to study up on any technique for invoking your C++ functions |
| 05:24:03 | DeM0nFiRe | Well, I need to design my language, but to implement it I need a new VM to implement the features I want |
| 05:24:04 | Defiler | since they will be right there in process with you |
| 05:24:15 | DeM0nFiRe | I mean |
| 05:24:15 | Defiler | I don't see how this is a VM problem |
| 05:24:39 | Defiler | just build an interpreter and have every thing it does call a C++ function |
| 05:24:47 | DeM0nFiRe | But that's not what I want |
| 05:24:55 | DeM0nFiRe | I need the script to be able to create it's own objects |
| 05:25:01 | DeM0nFiRe | And it's own classes |
| 05:25:02 | Defiler | it can't. it's a script. |
| 05:25:05 | DeM0nFiRe | etc. etc. |
| 05:25:19 | Defiler | all it can do is ask something more powerful to do that for it |
| 05:25:32 | brixen | DeM0nFiRe: for that one primitive, this is the glue code 449539 |
| 05:25:37 | brixen | er http://gist.github.com/449539 |
| 05:25:39 | DeM0nFiRe | Defiler: That isn't what I want |
| 05:26:00 | DeM0nFiRe | Brixen the glue code is generate after you do the other code? |
| 05:26:18 | brixen | that glue code is generated by the field_extract.rb script |
| 05:26:28 | brixen | from parsing the C++ .hpp files |
| 05:26:30 | Defiler | build time, in other words |
| 05:26:50 | Defiler | brixen: what he wants is for user scripts to be able to declare new primitives, essentially |
| 05:27:00 | brixen | sure |
| 05:27:02 | Defiler | for which llvm is the correct answer |
| 05:27:05 | brixen | you could do that |
| 05:27:10 | brixen | yep, with llv |
| 05:27:11 | brixen | m |
| 05:27:27 | DeM0nFiRe | I am looking at LLVM as well right now |
| 05:27:45 | brixen | llvm is just probably the easiest way to do it |
| 05:27:49 | DeM0nFiRe | brixen that seems pretty cool, but like it would still be a bit too much for something as large as a whole game engine |
| 05:27:50 | Defiler | with llvm, all you need to do is write a translator from your scripting language into calls to set up a function in memory via LLVM |
| 05:27:51 | brixen | you could do it various ways |
| 05:28:00 | Defiler | and then you just call it like a C++ function |
| 05:28:15 | Defiler | or, in this case, save a reference to it and call it many times later |
| 05:28:18 | DeM0nFiRe | Well, Defiler will I also still be able to have the language itself be a full OOP language? |
| 05:28:29 | Defiler | sure |
| 05:28:38 | Defiler | you'll be implementing it, so do whatever you want |
| 05:28:54 | Defiler | it's all opcodes in the end |
| 05:29:04 | Defiler | whether it's forth or java or ocaml |
| 05:30:00 | Defiler | if you make your grammar restrictive enough you can probably have a trivial mapping to prefab llvm functions |
| 05:30:02 | scoopr | are you doing this game engine with consoles in mind? |
| 05:30:19 | Defiler | but if you want it all fancy you will need an interpreter that calls llvm at runtime |
| 05:30:22 | DeM0nFiRe | I am not, consoles don't have support for OpenGL 3.3/4.0 which is the primary target rendering API |
| 05:30:53 | Defiler | you'd just need a runtime assembler of a different flavor on a console anyway |
| 05:31:34 | Defiler | (and a pile of extra code to do some of the other things llvm does for you) |
| 05:31:46 | DeM0nFiRe | I don't have any legal rights to develop on a console, I don't have any current gen consoles to work with, and consoles can't do OpenGL 3.3/4.0 so consoles are out for sure |
| 05:31:47 | Defiler | which would all be console-specific anyway |
| 05:31:49 | scoopr | because consoles, and some console-like platforms stricly restrict all jit-type of shenannigans.. also handling of memory needs a lot more care |
| 05:32:17 | Defiler | well, I think he knows this design is pretty far off the beaten path |
| 05:32:18 | DeM0nFiRe | Yeah, scoopr I know, another reason why I am not relaly interested in doing consoles |
| 05:32:39 | scoopr | right |
| 05:32:51 | DeM0nFiRe | Yeah, haha, I fully understand my design is pretty weird compared to... anything that exists currently :P |
| 05:32:54 | scoopr | you've chosen your battles wisely =) |
| 05:33:32 | DeM0nFiRe | Haha, yeah, I mean, I am all for trying crazy stuff, like what I am trying now, but I am really not interested in fighting legal battles and corporate rules and all of that stuff that's required to develop on consoles |
| 05:33:53 | DeM0nFiRe | However, I am interested in trying to develop for OpenPandora when it comes out XD |
| 05:34:34 | scoopr | there goes your opengl4 requirement ;) |
| 05:34:40 | DeM0nFiRe | Oh, of course |
| 05:34:51 | DeM0nFiRe | I would write a new renderer that uses OpenGL ES 2 |
| 05:34:59 | scoopr | not that wrapping a rendering api is that difficult usually |
| 05:35:05 | DeM0nFiRe | Yeah, exactly |
| 05:35:21 | DeM0nFiRe | I mean, I am already writing the engine in a way so that it won't even bee too diffficult to perhaps explore a DX11 renderer later |
| 05:35:56 | DeM0nFiRe | adding an OpenGL ES 2 renderer would be even easier, since it would largely be stripping down the 3.3/4.0 renderer |
| 05:36:43 | scoopr | but hopefully you have an actual project that you do that guides the engine development.. engines developed in isolation are usually useless |
| 05:37:27 | DeM0nFiRe | Well, I don't have a specific project, but I am being mindful of the problem of over abstraction |
| 05:38:40 | DeM0nFiRe | I have a couple of existing commercial games I am using as guidelines, to make sure it could make that sort of game without needing to twist it around or anything |
| 05:40:56 | DeM0nFiRe | In any case, thanks for the help guys. I know I'm not doing a very good job of communicating my ideas :P |
| 05:41:43 | brixen | is checking if the ruby bindings for irrlicht work with rbx |
| 05:42:01 | DeM0nFiRe | I don't even know if the ruby bindings for irrlicht work with ruby :P |
| 05:42:26 | DeM0nFiRe | They are for like RUby 0.3 and Irrlicht 0.2 (an exaggeration, of course :P ) |
| 05:43:16 | scoopr | I once tried embedded mri+mostly ruby code as a engine of sorts |
| 05:43:23 | scoopr | kinda worked nicely |
| 05:44:11 | DeM0nFiRe | Well, before I ruled out Ruby, I actually started writing a small engine and the ruby bindings for it simultaneously, and it was like wiritng the same thing 3 or 4 times |
| 05:44:25 | scoopr | but in the end, there are quite many performance sensitive parts that I preferred to write in the ruby side, which made it a bit of a mess |
| 05:44:40 | DeM0nFiRe | You had to write the engine in C++, then the C code to get Ruby to understand it, then the interfacing Ruby code |
| 05:45:04 | Defiler | oh man I am totally doing this upgrade |
| 05:45:05 | Defiler | http://vimeo.com/5851280 |
| 05:45:14 | Defiler | must have air jacks |
| 05:45:18 | scoopr | heh, I did api interfacing parts directly in c, like it was an extension |
| 05:45:33 | DeM0nFiRe | Also the way I am writing it and the way the Ruby interacts with C++ I was getting reasonable performance |
| 05:45:53 | DeM0nFiRe | 1000 sprites was 8500 FPS or thereabouts |
| 05:46:01 | DeM0nFiRe | No, sorry |
| 05:46:06 | DeM0nFiRe | hehe, that was only 3 sprites |
| 05:46:23 | DeM0nFiRe | 1000 sprites is about 500FPS |
| 05:47:12 | DeM0nFiRe | I made it so you could add a sprite from either C++ or Ruby and then the graphics module would automatically sort it by z, and that worked pretty well, only a problem if you need to sort frequently |
| 05:47:53 | DeM0nFiRe | Hehe, here was the test rb script http://pastebin.com/NE3sPsbR |
| 05:48:47 | DeM0nFiRe | I was happy with the performance, but it was getting to be a real pain to code on the C/C++ side |
| 05:49:39 | Defiler | ohhh yeah http://www.hrpworld.com/index.cfm?form_prod_id=1673&action=product |
| 05:49:52 | Defiler | man why don't I already have air jacks :) |
| 05:50:45 | DeM0nFiRe | IN that script, Engine is a class entirely defined in C++ and it interfaces with a running instance of the engine's main device, which was cool |
| 05:50:53 | DeM0nFiRe | But a PITA to do with Ruby's C API :( |
| 05:51:06 | DeM0nFiRe | And then you can see Graphics is a mix of C/C++ and Ruby |
| 05:51:09 | scoopr | yeah, I tried to do only the lowlevel stuff in c and the engine in ruby |
| 05:51:45 | DeM0nFiRe | Yeah, I did a mix because there was a lot of stuff in the main device that would have no real reason to have exposed to ruby and would really kill the performance |
| 05:51:46 | DeM0nFiRe | I mean |
| 05:52:11 | DeM0nFiRe | 1000 sprites in 500 FPS seems OK, but even then that's on an i7 and HD5850, which si well above the average case |
| 05:52:12 | DeM0nFiRe | is*\ |
| 05:54:05 | scoopr | well, anything over 60fps is meaningless as a performance measurement, you need to talk in terms of milliseconds used for some particular task |
| 05:54:30 | DeM0nFiRe | Hehe, 500FPS, 2 miliseconds, lol |
| 05:54:32 | DeM0nFiRe | Actually |
| 05:54:39 | DeM0nFiRe | The way I did it this way |
| 05:55:00 | DeM0nFiRe | The code for stepping the engine is << 1ms |
| 05:55:45 | DeM0nFiRe | Oh, hmm |
| 05:55:49 | DeM0nFiRe | less bad ass than I though |
| 05:55:57 | DeM0nFiRe | 10000FPS, so you are talking 1/10 of a ms |
| 05:56:12 | scoopr | yes, and that's noise |
| 05:56:44 | scoopr | essentially measuring how fast the driver can do buffer swaps and other synchronization |
| 05:56:55 | DeM0nFiRe | Well, not necessarily |
| 05:57:32 | DeM0nFiRe | Because that is also lower because Ruby is just there for reach frame, which slows it down |
| 05:58:02 | scoopr | sure it "slows" it, but it's immeasurable in that scale |
| 05:58:12 | DeM0nFiRe | Like, the real engine I was talking about earlier, no ruby and better optimized code and it's something like 0.025 ms per frame |
| 05:58:31 | DeM0nFiRe | When all you are doing is clearing with glClear and swapping buffers |
| 05:58:45 | DeM0nFiRe | Now, that may not sound like a lot |
| 05:59:10 | DeM0nFiRe | But drawing, say, an individual pixel takes even less time |
| 06:00:53 | DeM0nFiRe | So the difference between 0.1ms and 0.025 ms for that one part of the engine translates to like another few hundred sprites or so |
| 06:03:10 | DeM0nFiRe | But I mean, doing that kind of low level stuff is what I like. I hate scripting game logic, which is why I want to make a language that makes it as easy as possible |
| 06:03:26 | DeM0nFiRe | Hey guys, now would I go about implementing a makeGame() function? |
| 09:14:21 | bakkdoor | the compiler & codegen tools in rubinius are all written in ruby, correct? |
| 10:17:02 | dbussink | bakkdoor: most of it yeah, the parser is take from mri though |
| 10:17:22 | dbussink | bakkdoor: but after a structure comes out of that, everything from there is compiled in ruby |
| 10:24:11 | bakkdoor | dbussink: yeah i knew that about the parser. does the parser simply output stuff as text or how does it work exactly? |
| 10:27:25 | dbussink | bakkdoor: it returns an ast |
| 10:29:11 | bakkdoor | dbussink: yeah but i mean does it ouput that ast as text somehow or how does the ruby code use it? the parser is written in c (or c++) right? |
| 10:29:35 | bakkdoor | dbussink: or it the parser simply used as an extension within ruby? |
| 10:35:50 | dbussink | bakkdoor: it's an extension in ruby and you get a ruby structure back from it |
| 10:36:00 | dbussink | bakkdoor: you can "a = 1".to_ast to see what you get back |
| 10:36:08 | bakkdoor | ah ok. thanks! |
| 15:24:04 | goyox86 | Hi all , i've recently switched to develop in rails, i'm trying to build the ruby-debug gem but, it doesn't build |
| 15:24:42 | goyox86 | I think this is due to ruby-debug is tightly coupled with MRI? |
| 15:25:17 | goyox86 | Hi all , i've recently switched to develop in rails with Rubinius, i'm trying to build the ruby-debug gem but, it doesn't build ** |
| 15:46:14 | goyox86 | I insert a call to debugger, in the code but it doesn´t start the debugger :-s |
| 15:47:13 | kstephens | rubninus has its own debugger, AFIAK. |
| 15:49:46 | goyox86 | kstephens: i understand, i'm checking at the rubinius docs, and it tells me that if i want to debug ruby code i just need to inser a call +debugger+ or +breakpoint+ |
| 15:50:13 | goyox86 | kstephens: but it doesn´t work |
| 16:21:36 | brixen | morning |
| 16:21:53 | evan | brixen: morning |
| 16:21:54 | brixen | goyox86: ruby-debug does not work with rbx |
| 16:22:09 | evan | brixen: you might want to warn people in rake that they need to rerun configure |
| 16:22:15 | evan | atm, they're just getting a warning about needing MRI |
| 16:22:24 | brixen | erg, ok |
| 16:22:27 | evan | which is confusing them. |
| 16:22:36 | brixen | undoubtedly |
| 16:22:59 | evan | but hey! USA won! WOOOO |
| 16:23:06 | brixen | WOOOO |
| 16:23:19 | brixen | so, yesterday, I basically slept from 10am to 6:30 |
| 16:23:26 | brixen | I'm trying the sitting up thing again |
| 16:23:39 | brixen | my head feels like 6 cubic meters of cotton atm |
| 16:23:51 | evan | :( :( |
| 16:24:03 | evan | i figured you were sick yesterday. |
| 16:24:24 | brixen | yeah, I thought I'd have a little rest |
| 16:24:29 | brixen | woke up at 6:30 |
| 16:24:38 | evan | :D |
| 16:24:44 | evan | thats your body telling you something |
| 16:24:49 | evan | guess what your body is telling you today? |
| 16:24:52 | evan | USA WOOOOOOOOOOOOOOOOOO! |
| 16:26:05 | brixen | haha |
| 16:26:14 | brixen | goyox86: http://gist.github.com/450160 |
| 16:27:22 | brixen | goyox86: right now you can inspect stuff and set a new breakpoint |
| 16:27:31 | brixen | goyox86: then type 'c' to continue running |
| 16:27:45 | brixen | goyox86: step and other stuff isn't done yet |
| 16:53:13 | evan | montywilliams: monty! |
| 16:53:18 | boyscout | Ensure Rakefile checks configure version before anything. Closes #385. - e846db9 - Brian Ford |
| 17:01:25 | boyscout | CI: rubinius: e846db9 successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 17:04:42 | Cheba | Hello. I'm having troubles building rubinius from git. First error message is "undefined reference to `ruby_xmalloc'". Any insights on how can I fix it? |
| 17:05:07 | brixen | Cheba: gist the output from your terminal |
| 17:13:14 | Cheba | http://gist.github.com/450214 |
| 17:13:59 | brixen | Cheba: could you please run ./configure --show and gist that |
| 17:15:18 | Cheba | Same gist. |
| 17:15:57 | brixen | could you run rake extensions:clean; rake |
| 17:16:25 | Cheba | Sure. |
| 17:16:29 | Cheba | brb |
| 17:16:32 | brixen | k |
| 17:40:41 | Cheba | Nope, no luck. http://gist.github.com/450214#file_rake%20extensions:clean;%20rake |
| 17:43:06 | evan | Cheba: for some reason it's not linking right... |
| 17:43:53 | dbussink | maybe ruby is stripped from symbols? |
| 17:44:03 | dbussink | Cheba: which platform? |
| 17:44:09 | Cheba | Linux. |
| 17:44:18 | dbussink | which linux? |
| 17:44:26 | Cheba | Gentoo. |
| 17:44:28 | tarcieri | how long until Rubinius has 10 virtual machines inside of every metaclass? |
| 17:44:40 | Cheba | i686 |
| 17:44:53 | dbussink | i've heard other people having issues with gentoo stripping library symbols |
| 17:44:56 | dbussink | that was with sqlite3 |
| 17:45:04 | dbussink | maybe it happened with your ruby install |
| 17:45:19 | dbussink | Cheba: to other c gems work? |
| 17:45:41 | Cheba | Yes. Have no problems with c gems. |
| 17:45:55 | Cheba | I can try build not stripped mri and try again. |
| 17:46:16 | Cheba | Should I? |
| 17:46:55 | dbussink | Cheba: you could try that first yeah |
| 17:46:57 | dbussink | to see if that works |
| 17:47:13 | dbussink | but if you're mri is like this, i can hardly imagine that other c gems work :S |
| 17:48:29 | evan | Cheba: run it with --trace |
| 17:48:31 | evan | and gist the output |
| 17:48:48 | Cheba | Sec. |
| 17:51:29 | Cheba | evan: http://gist.github.com/450214#file_rake%20extensions:clean;%20rake%20__trace |
| 17:52:16 | evan | erp |
| 17:52:17 | evan | one sec. |
| 17:54:35 | evan | Cheba: ok, run again with -v |
| 17:54:36 | evan | not --trace |
| 17:54:38 | evan | sorry |
| 17:55:02 | evan | i'm to get the command used to link it to be printed |
| 17:55:04 | evan | not just LDSHARED |
| 17:55:36 | Cheba | evan: rake -v? |
| 17:55:41 | evan | yes. |
| 17:56:10 | dbussink | evan: it's at the bottom |
| 17:56:15 | dbussink | Command failed with status (1): [g++ -shared -lstdc++ ruby/bstrlib.o ruby/quark.o ruby/var_table.o ruby/node_types.o ruby/visitor.o ruby/melbourne.o ruby/grammar.o ruby/symbols.o -shared -L. -Wl,-O1 -rdynamic -Wl,-export-dynamic -Wl,--no-undefined -L. -lpthread -lrt -ldl -lcrypt -lm -lc -o ruby/melbourne.so > /dev/null] |
| 17:56:40 | evan | oh oh. |
| 17:56:59 | evan | why the heck doesn't that work |
| 17:57:08 | evan | oh wait |
| 17:57:09 | goyox86 | brixen: i supposed ruby-debug doesn't work with rubinius since it is tightly coupled tom MRI internals |
| 17:57:12 | evan | there is no -lruby in there. |
| 17:57:21 | evan | thats why. |
| 17:58:00 | evan | I guess normally thats fine. |
| 17:58:06 | evan | since the symbols are bound at dlopen time. |
| 17:58:22 | evan | but your g++ doesn't seem to like that. |
| 17:59:31 | dbussink | goyox86: yeah |
| 17:59:45 | evan | goyox86: yes. |
| 17:59:56 | dbussink | goyox86: but we want to have a debugger infrastructure so people might be able to write a ruby-debug compatible layer on top of that |
| 18:00:05 | evan | the same reason there is a completely different of ruby-debug for 1.9 |
| 18:00:11 | dbussink | but we want to have a more awesome debugger ourselves :P |
| 18:00:46 | dbussink | evan: dunno if you saw it, but dan removed that stuff from veritas too |
| 18:01:03 | evan | he sent me a message that he changed it |
| 18:01:05 | evan | i didn't see what he did |
| 18:01:07 | evan | i'll pull and see. |
| 18:01:55 | goyox86 | evan: you mean some wrapper in ruby-debug, to use the Rubinius debugger? faking the program being run? or something like that |
| 18:02:04 | Cheba | evan: Adding -lruby to failed command doesn't make it work. |
| 18:02:22 | evan | Cheba: what about -lruby18 |
| 18:02:30 | evan | goyox86: eh? |
| 18:02:37 | evan | goyox86: i mean that ruby-debug doesn't work on 1.9 directly either |
| 18:02:38 | Cheba | Nope. It complains that it can't find a bunch of .o files. |
| 18:02:39 | evan | they had to port it. |
| 18:02:43 | evan | hm. |
| 18:03:25 | dbussink | goyox86: guess you replied to my remark :) |
| 18:03:31 | Cheba | evan: http://gist.github.com/450214#file_g++ |
| 18:03:33 | goyox86 | evan: I know, ruby-debug is only compatible with 1.8 |
| 18:03:46 | dbussink | goyox86: what we want to do is to have a debugging infrastucture available and provide a standard debugger for that in rbx |
| 18:04:05 | dbussink | goyox86: other people could perhaps use that infrastructure to build another debugger api on top of it at some moment |
| 18:04:55 | evan | Cheba: you're running that in the wrong directory |
| 18:04:57 | evan | Cheba: i'm betting. |
| 18:05:08 | evan | you need to be in lib/ext/melbourne |
| 18:05:18 | goyox86 | dbussink: BTW i prefer the Rubinuis aproach, that implementation dependent thins like ruby-debug |
| 18:05:35 | evan | goyox86: i want us to have a custom backend to ruby-debug |
| 18:05:36 | evan | eventually |
| 18:05:44 | evan | i'm going to basically build a reference debugger |
| 18:05:55 | evan | that someone can use to patch in support to ruby-debug |
| 18:06:10 | goyox86 | evan: neat |
| 18:12:37 | goyox86 | What is the best way to determine from inside a ruby program, that i'm running on Rubinius, such the example of requiring "debugger",available on rubinius but not in MRI 1.8.7? |
| 18:13:03 | goyox86 | checking the RUBY_DESCRIPTION global? |
| 18:13:48 | dbussink | goyox86: defined?(RUBY_ENGINE) && RUBY_ENGINE == 'rbx' |
| 18:15:01 | goyox86 | RUBY_ENGINE is only used in rubinius right? |
| 18:15:29 | brixen | RUBY_ENGINE is used in every alt impl and in mri 1.9 |
| 18:15:32 | evan | goyox86: no. |
| 18:15:38 | brixen | it does not exist in mri 1.8.x |
| 18:16:14 | brixen | if it's not defined ore == 'ruby' that is mri |
| 18:16:32 | brixen | rbx is rubinius, ironruby is ironruby, jruby is jruby, maglev is maglev |
| 18:17:26 | evan | we should have been rubinius, but oh well. |
| 18:17:37 | evan | I gotta be flashy. |
| 18:17:42 | brixen | yep |
| 18:17:47 | brixen | all that flash |
| 18:17:48 | brixen | hehe |
| 18:17:55 | Cheba | evan: you're right. |
| 18:18:10 | Cheba | In right dir with -lruby it worked. |
| 18:18:34 | goyox86 | brixen: good. I was testing it just between MRI 1.8.7, and rubinius, sorry for that :-s, lol |
| 18:18:56 | evan | Cheba: oh good! ok. |
| 18:19:01 | dbussink | evan: just remember all the power saved by only having three bytes in there instead of 8 |
| 18:19:19 | evan | i'm doing my part to stop global warming. |
| 18:19:36 | goyox86 | evan: lol |
| 18:20:07 | goyox86 | rbx is nicer BTW |
| 18:20:13 | dbussink | evan: would it be possible for me to add that module ivar packing myself? |
| 18:20:21 | evan | dbussink: i've just finished :) |
| 18:20:23 | evan | i'm about to commit it. |
| 18:20:33 | dbussink | evan: ah, too bad :P |
| 18:20:47 | evan | but when you see the commit, you'll understand |
| 18:20:56 | evan | the way it works is pretty straight forward |
| 18:21:02 | Cheba | evan: after compiling Melbourne rake went on. |
| 18:21:05 | evan | I taught it to recognize attr_* too |
| 18:21:14 | dbussink | evan: ok, cool, well, understanding is often a lot easier than writing it though ;) |
| 18:21:14 | evan | Cheba: ok, we need to fix something in there. |
| 18:21:33 | dbussink | evan: ah, knowing about accessors is nice too yeah :) |
| 18:21:35 | Cheba | Though, it stopped with "no such file to load -- auto_gem". Probably, that's Gentoo specific. |
| 18:21:36 | brixen | evan: working on a fix |
| 18:21:41 | evan | brixen: danku. |
| 18:21:53 | evan | Cheba: must be |
| 18:21:56 | evan | never heard of auto_gem. |
| 18:22:54 | Cheba | It's the way Gentoo solved multiple ruby versions/implementations. They added that for some reason to make gems work when they're installed by gentoo package manager. |
| 18:23:07 | Cheba | Nice backtrace. =) |
| 18:23:08 | dbussink | they add it to RUBYOPT by default |
| 18:23:14 | dbussink | http://groups.google.com/group/emm-ruby/browse_thread/thread/d64eae647d7aa136 |
| 18:23:56 | Cheba | dbussink: thanks. |
| 18:23:58 | evan | thats a crappy solution. |
| 18:24:03 | evan | auto_gem itself |
| 18:24:09 | evan | not undef'ing RUBY_OPT |
| 18:24:13 | evan | because it means you hit this constantly |
| 18:24:21 | evan | if you install something outside the gentoo sandbox. |
| 18:24:32 | dbussink | man, nocode is good at finding obscure stuff :P |
| 18:24:38 | dbussink | looking at the tickets |
| 18:24:40 | evan | dbussink: yeah. |
| 18:24:58 | dbussink | i thought i was able to, but this guy surely beats me :p |
| 18:25:19 | brixen | Cheba: could you apply this patch, then run: rake extensions:clean; rake build |
| 18:25:23 | brixen | Cheba: http://gist.github.com/450322 |
| 18:25:48 | evan | brixen: you should be able to get the proper name from rbconfig |
| 18:26:16 | dbussink | i bet there are distro's that make -lruby1.9 or -lruby1.8 out of it |
| 18:26:28 | evan | yeah |
| 18:26:31 | brixen | oh, for -lruby18... |
| 18:27:06 | dbussink | LIBRUBYARG |
| 18:27:10 | brixen | Cheba: one sec |
| 18:27:11 | goyox86 | people, i jsut asked about "auto_gem" to ruby-gentoo people here is the answer: "yep. it does 'require "rubygems"' on ruby 1.8 where it it not loaded by default" |
| 18:29:45 | dbussink | evan: i'm awaiting anxiously ;) |
| 18:29:54 | evan | it's rebuilding and testing |
| 18:30:14 | evan | goyox86: :/ |
| 18:30:20 | evan | goyox86: why did they not put -rrubygems in RUBYOPT then? |
| 18:30:27 | evan | *eyeroll* |
| 18:30:37 | brixen | Cheba: http://gist.github.com/450322 |
| 18:31:31 | goyox86 | evan: I'm just digging depper in the gentoo-ruby channel :-), just wait for the details, hehe |
| 18:32:20 | evan | goyox86: 10-4 |
| 18:33:11 | Cheba | brixen: This fixes the issue. Thanks. |
| 18:33:23 | brixen | Cheba: ok, cool |
| 18:34:49 | goyox86 | evan: "the way is more flexible, i.e. you can specify per-ruby-version commands." |
| 18:35:09 | evan | *eyeroll* |
| 18:35:22 | goyox86 | evan: i just asked him exactly waht you asked me lol |
| 18:36:32 | Cheba | Oh, yeah. Gentoo has a few commands for gem. I.e. gem18, gem19. And you can choose active ruby version. Than it will ink ruby -> ruby18, gem -> gem18, rake -> rake18. |
| 18:37:19 | brixen | they should just use rvm :) |
| 18:37:27 | brixen | the whole build from source thing fits right in |
| 18:37:48 | Cheba | Though, they do it only with this executables. Other bins from installed gems just use simple wrappers that get correct bin based on current ruby version. |
| 18:38:21 | wayneeseguin | w00t w00t! |
| 18:38:31 | brixen | wayneeseguin: :) |
| 18:38:32 | Cheba | brixen: there was a few propositions on that. Probably, rvm handles building on its own and that's the show stopper for gentoo folks. |
| 18:38:52 | wayneeseguin | heh |
| 18:38:58 | wayneeseguin | Gentoo folks are a show stopper for gentoo folks. |
| 18:39:04 | wayneeseguin | ask Pistos in #rvm |
| 18:39:13 | wayneeseguin | he had a "wonderful" experience with them. |
| 18:39:39 | wayneeseguin | Actually due to that I highly recommend against Gentoo for all of my clients. |
| 18:39:43 | wayneeseguin | Anyway. |
| 18:40:59 | boyscout | Have autopacking take included modules and attrs into account - 1756eea - Evan Phoenix |
| 18:41:30 | goyox86 | brixen: well, i just told some of that, "what about using rvm?" |
| 18:41:54 | dbussink | evan: woohoo |
| 18:41:58 | goyox86 | brixen: or even support it in their package manager |
| 18:42:35 | Cheba | goyox86: hehe, what was the answer? |
| 18:43:18 | goyox86 | brixen: here is the answer: https://gist.github.com/d9e87b436714c3bb047b |
| 18:43:24 | goyox86 | .s |
| 18:43:38 | goyox86 | brixen: :-s |
| 18:44:07 | brixen | well, the situation with different distros and versions is just asinine IMO |
| 18:44:13 | Cheba | goyox86: who was that? |
| 18:44:17 | dbussink | evan: any reason for the 25 elements limit or just to have a somewhat sane limit for now? |
| 18:44:24 | brixen | the analogy is having a different receptacle standard in every building you visit |
| 18:44:44 | goyox86 | Cheba: Mmm let me check |
| 18:44:48 | brixen | so every program has in it's build system a zillion adapters to handle these different platforms |
| 18:44:51 | evan | dbussink: safety. |
| 18:44:54 | brixen | which is stupid as hell |
| 18:45:02 | evan | dbussink: just a sane limit for now. |
| 18:45:06 | brixen | platforms should agree on standards and stick to them |
| 18:45:07 | evan | there had to be some limit |
| 18:45:10 | evan | 25 seemed fine. |
| 18:45:28 | evan | after 25, it's pretty clear that the class does something weird with ivars. |
| 18:45:33 | goyox86 | Cheba: a3li |
| 18:45:54 | goyox86 | Cheba: Alex Legler |
| 18:46:11 | wayneeseguin | goyox86: Actually, http://github.com/wayneeseguin/rvm/tree/master/pkg/gentoo/ ;) |
| 18:46:16 | wayneeseguin | goyox86: User contributed but. |
| 18:46:18 | Cheba | Yeah, I know him. Not personal, though. |
| 18:46:30 | dbussink | evan: btw, algeria - usa was pretty much a thriller game i guess :P |
| 18:46:37 | evan | dbussink: yeah |
| 18:46:39 | wayneeseguin | brixen: I'm trying like hell to unify it all ;) |
| 18:46:39 | evan | it was crazy. |
| 18:46:48 | wayneeseguin | brixen: Once I have binary installs... should be all set. |
| 18:46:55 | brixen | wayneeseguin: yeah, crazy isn't it |
| 18:47:01 | brixen | wayneeseguin: but bravo on that :) |
| 18:47:13 | wayneeseguin | Not easy problem I'll admit |
| 18:47:31 | goyox86 | wayneeseguin: neat! |
| 18:47:44 | brixen | wayneeseguin: a perfect example of trying to handle complexity with more complexity |
| 18:48:01 | brixen | wayneeseguin: instead of making a standard, we make autotools |
| 18:48:19 | brixen | if that doesn't tell you how ridiculous the situation is, nothing will |
| 18:49:22 | goyox86 | brixen: autotools == GNU autotools? |
| 18:49:38 | brixen | yes |
| 18:49:39 | Cheba | Well, there's LSB. It's in version 4 now and about decade old. But nobody still really cares. |
| 18:50:02 | dbussink | evan: do you follow tennis a bit? |
| 18:50:17 | brixen | Cheba: right, a standard with no conformance is no standard |
| 18:50:35 | goyox86 | brixen: agree |
| 18:50:57 | Cheba | brixen: I beliseve RedHat is the closest one to LSB. |
| 18:50:58 | evan | dbussink: you mean the 47-48 match going on now? |
| 18:51:01 | evan | dbussink: :) |
| 18:51:05 | evan | dbussink: I follow somewhat, yes. |
| 18:51:19 | goyox86 | brixen: and about autotools, is just insane, i think |
| 18:51:22 | evan | oh 49-48 now. |
| 18:51:40 | brixen | goyox86: about as insane as you can get, yes |
| 18:51:41 | dbussink | evan: yeah, it's already the longest match ever with most games ever :) |
| 18:51:53 | dbussink | funny to see in progress for records on wikipedia :P |
| 18:51:58 | evan | the current set is longer than most matches |
| 18:52:24 | evan | i wonder if they're going to hold on |
| 18:52:30 | evan | and get postponed for another day |
| 18:52:59 | goyox86 | brixen: Libtool is the king of insanity, lol, this is just understanted by the folks who actually wrote it :-s |
| 18:53:13 | boyscout | CI: rubinius: 1756eea successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 18:56:41 | dbussink | evan: yay, it's picking up properties now in packed ivars :) |
| 19:01:15 | evan | sweet. |
| 19:01:29 | evan | dbussink: hah |
| 19:01:45 | evan | the scoreboard in the isner game broke |
| 19:01:49 | evan | they've gone so long. |
| 19:01:52 | evan | it's almost 51-50 |
| 19:03:56 | dbussink | evan: hmm, it's slower with autopack enabled :S |
| 19:05:05 | evan | that happens, yes. |
| 19:05:10 | evan | if you can extract it at all |
| 19:05:12 | evan | i'll see what I can do. |
| 19:10:07 | boyscout | Add ruby as a link library when building Melbourne for MRI. - 83690bb - Brian Ford |
| 19:16:25 | brixen | excerpt of alan kay to the fonc list http://gist.github.com/450411 |
| 19:16:36 | brixen | that is just a priceless paragraph |
| 19:17:03 | brixen | M$ clueless all these years and CIA all over tech |
| 19:17:18 | brixen | I wonder what the CIA folder on rbx looks like :) |
| 19:25:33 | BrianRice-work | huh |
| 19:26:22 | BrianRice-work | oh now I see the email |
| 19:30:34 | wayneeseguin | brixen: Yeah... autotools... |
| 19:35:24 | boyscout | CI: rubinius: 83690bb successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 19:44:08 | tarcieri | sooooo |
| 19:44:09 | tarcieri | this is odd |
| 19:44:33 | tarcieri | rbx-1.0.1-20100603 > class Foo; end; module Foo; end => nil |
| 19:44:40 | tarcieri | blah newslines :( |
| 19:44:44 | tarcieri | new... lines... |
| 19:45:54 | tarcieri | anywho MRI raises a TypeError if you do that |
| 19:48:10 | Defiler | brixen: wow. |
| 19:48:22 | Defiler | re: that gist |
| 19:52:04 | brixen | tarcieri: hrm, could you file a ticket on that |
| 19:52:28 | brixen | grabs lunch |
| 19:52:32 | brixen | bbiab... |
| 20:02:46 | tarcieri | brixen: http://github.com/evanphx/rubinius/issues/issue/386 |
| 20:02:54 | tarcieri | ungh @ formatting |
| 20:07:45 | goyox86 | people, Where can look for a guide about the Rubinius debugger commands, use? |
| 20:08:26 | brixen | goyox86: http://gist.github.com/450160 |
| 20:08:47 | brixen | 09:27 brixen >> goyox86: right now you can inspect stuff and set a new breakpoint |
| 20:08:50 | brixen | 09:27 brixen >> goyox86: then type 'c' to continue running |
| 20:08:53 | brixen | 09:27 brixen >> goyox86: step and other stuff isn't done yet |
| 20:08:58 | brixen | tarcieri: thanks man |
| 20:09:37 | brixen | finally leaves for lunch |
| 20:10:08 | goyox86 | brixen: thx man, i've not read this line: "right now you can inspect stuff and set a new breakpoint" |
| 20:31:26 | evan | tarcieri: fixing that now |
| 20:31:31 | evan | it's because I did |
| 20:31:34 | evan | unless obj.kind_of? Module |
| 20:31:41 | evan | and a class is a module. |
| 20:50:38 | rue | Defiler: How are your plans coming along for the ultimate metal hexperience? |
| 20:51:59 | tarcieri | evan: aah |
| 20:52:09 | tarcieri | got sucked into the meeting monster |
| 20:52:24 | Defiler | rue: sadly I have had to cancel the trip :( |
| 20:52:31 | Defiler | for numerous irritating reasons |
| 20:52:42 | Defiler | but I'm consoling myself with numerous motorsports events later in the year |
| 20:53:04 | tarcieri | evan: heh, wrote some code that did that accidentally, worked on rbx then broke on our CI server |
| 20:53:07 | Defiler | going to try to get to colorado this weekend somehow for the Pikes Peak hill climb |
| 20:53:10 | Defiler | but may fail at that |
| 20:53:14 | tarcieri | heh |
| 20:53:14 | evan | tarcieri: ha. |
| 20:53:17 | tarcieri | hooray for Colorado |
| 20:53:58 | dbussink | evan: if you want i have a really basic benchmark script that allocates datamapper objects |
| 20:54:05 | dbussink | evan: that you can also compare to mri performance |
| 20:54:16 | evan | dbussink: please |
| 20:54:41 | evan | Defiler: somehow? I'd suggest airtravel. |
| 20:55:27 | Defiler | heh yeah |
| 20:57:01 | dbussink | evan: https://gist.github.com/de660c29f0e1b316fc4f |
| 20:57:08 | dbussink | evan: added some basic numbers in the comments |
| 20:57:43 | evan | Defiler: please rerun with -Xgc.autopack=no |
| 20:58:09 | dbussink | evan: added that too |
| 20:58:16 | Defiler | ok! :) |
| 20:58:23 | evan | hm. |
| 20:58:25 | evan | ack. |
| 20:58:29 | evan | Defiler: :) |
| 20:58:40 | evan | dbussink: how much fucking code runs for .new |
| 20:58:41 | evan | geez. |
| 20:58:54 | dbussink | evan: quite a big i guess :P |
| 20:58:59 | dbussink | but it's all ruby stuff |
| 20:59:02 | dbussink | no C code here |
| 20:59:06 | evan | well |
| 20:59:07 | Defiler | new should use Module.new to make a new anonymous new object maker and then call make_object on it |
| 20:59:11 | evan | thats obviously not completely true |
| 20:59:14 | evan | since 1.9 is 0.9 |
| 20:59:16 | dbussink | but it's something that probably could very well be optimized |
| 20:59:24 | evan | so you're clearly hitting a lot of core class methods |
| 20:59:26 | dbussink | well, no explicit C extensions, let put it that way |
| 20:59:27 | evan | which are C. |
| 20:59:31 | dbussink | that's probably true yeah |
| 20:59:37 | evan | run with -Xprofile |
| 20:59:42 | rue | Defiler: Motorsports works for that |
| 21:00:09 | Defiler | yeah. I'm going to get my regional racing license this year as well |
| 21:00:16 | Defiler | and hopefully a national one in 2011 |
| 21:00:38 | dbussink | evan: https://gist.github.com/404a2dd8378ee4980b4b |
| 21:00:49 | Defiler | http://www.scca.com/contentpage.aspx?content=47 |
| 21:01:02 | evan | or |
| 21:01:07 | evan | so very, very heavy Hash write. |
| 21:01:14 | dbussink | evan: yeah, looks like it |
| 21:02:36 | dbussink | evan: is the iterator hash writing? or do you mean the number of tuple writes? |
| 21:02:55 | evan | 2.81 3.85 0.77 1001363 0.00 0.00 Hash.new_from_literal |
| 21:02:56 | dbussink | more in general hash heavy it looks like |
| 21:03:08 | evan | created 1 million Hashes |
| 21:03:18 | evan | which makes me assume it used them all |
| 21:04:51 | dbussink | evan: it uses a hash to initialize all the attributes |
| 21:04:55 | dbussink | which is probably to blame then |
| 21:05:12 | evan | because you're also creating them then throwing them away |
| 21:05:13 | dbussink | evan: it actually doesn't do that much |
| 21:05:21 | dbussink | but it could be optimized |
| 21:07:02 | dbussink | evan: but i guess creating empty hashes is a lot more light weight on mri then |
| 21:07:11 | dbussink | i wonder if it's something worth optimizing in rbx for |
| 21:07:12 | cored | h/whois dbussink |
| 21:07:18 | dbussink | if it happens a lot |
| 21:07:22 | dbussink | cored: curious? ;) |
| 21:07:28 | cored | dbussink: yes :-) |
| 21:07:28 | evan | hahahhaha |
| 21:07:31 | evan | wow, BUSTED. |
| 21:07:54 | cored | I typed too fast |
| 21:08:24 | dbussink | cored i can tell you stuff myself :P |
| 21:09:36 | cored | :-) |
| 21:09:59 | cored | I thought I saw you in #padrino the other day, that's was it |
| 21:17:07 | boyscout | Fix EBADF spec failure - 15faaca - Evan Phoenix |
| 21:17:08 | boyscout | Add spec for module trying to reopen a class - 5c18c14 - Evan Phoenix |
| 21:17:08 | boyscout | Check only for Module, not Class too. Fixes #386. - 8e2195f - Evan Phoenix |
| 21:18:05 | Defiler | empty hashes are created a LOT in many styles of ruby code |
| 21:18:10 | Defiler | e.g. def zazz(options = {}) |
| 21:18:23 | dbussink | yeah, so hence i was wondering if it's a case worth optimizing for |
| 21:18:32 | evan | i'm writing some benchmarks for it right now |
| 21:18:38 | evan | dbussink: what would be written to the hash? |
| 21:18:53 | Defiler | but optimizing for the common case of 'hash with two or three keys' is probably just as important |
| 21:18:54 | dbussink | evan: in this case nothing actually |
| 21:18:56 | kstephens | I use def zazz(options = EMPTY_HASH) wherever possible, because of the allocation/GC costs. |
| 21:19:02 | dbussink | it used as a default value |
| 21:19:10 | Defiler | yeah, same here |
| 21:19:25 | Defiler | though I generally do options = nil to avoid having to normalize for when people deliberately pass in a nil |
| 21:19:38 | Defiler | then options ||= empty hash |
| 21:19:54 | kstephens | yea that too |
| 21:20:05 | evan | a raw loop doing {} is about the same |
| 21:20:54 | evan | 1.4s vs 1.9s for 3M iterations |
| 21:20:59 | evan | so it must be something else in the DM case |
| 21:21:11 | dbussink | evan: this also iterates over the empty hash |
| 21:21:47 | dbussink | evan: ok, small optimization turned it from 10 secs into 2.3 secs :) |
| 21:21:55 | dbussink | removing the {} allocation and the iteration over it |
| 21:22:07 | evan | oh? what did you change and where? |
| 21:22:09 | evan | in DM? |
| 21:22:13 | dbussink | in DM yeah |
| 21:22:17 | evan | show me the gist |
| 21:22:18 | evan | i'm curious. |
| 21:22:20 | evan | er. |
| 21:22:21 | evan | diff. |
| 21:22:39 | dbussink | evan: https://gist.github.com/8fbbfd2a7cd0c5ebf73e |
| 21:22:46 | dbussink | self.attributes is a method call here |
| 21:22:59 | dbussink | that iterates over the hash and sets the ivars through the accessors |
| 21:23:14 | evan | there are ivars and a hash? |
| 21:23:32 | Defiler | Foo.new :attr1 => 1, :attr2 => 2 |
| 21:23:35 | dbussink | no, the hash is used for initialization |
| 21:23:36 | Defiler | sets @attr1 = 1 |
| 21:23:38 | Defiler | etc etc |
| 21:23:54 | dbussink | quite a diff between auto packing enabled / disabled here though: https://gist.github.com/24a12e488c5db16d101a |
| 21:23:55 | evan | um |
| 21:23:57 | evan | to me |
| 21:24:04 | rue | Defiler: For the regional licence you just have to drive from Bronx to Brooklyn through the city? |
| 21:24:07 | evan | your diff just assigns a hash to @attributes |
| 21:24:08 | Defiler | rue: hah |
| 21:24:32 | dbussink | evan: no, attributes is a method that is called |
| 21:24:40 | evan | right |
| 21:24:45 | evan | which does what with the hash? |
| 21:25:13 | Defiler | it does hash.each {|k,v| instance_variable_set("@#{k}", v} |
| 21:25:13 | boyscout | CI: rubinius: 8e2195f successful: 3456 files, 13605 examples, 41169 expectations, 0 failures, 0 errors |
| 21:25:14 | Defiler | basically |
| 21:25:32 | evan | oh for fucks sake guys. |
| 21:25:40 | dbussink | evan: http://github.com/datamapper/dm-core/blob/master/lib/dm-core/resource.rb#L339-353 |
| 21:25:44 | evan | shakes his head |
| 21:25:45 | Defiler | yeah it's retarded but it's how every damn ruby library works now |
| 21:25:51 | Defiler | so it has to be fast :( |
| 21:25:59 | Defiler | rails *shakefist* |
| 21:26:09 | dbussink | that's how people expect stuff to work.. |
| 21:26:31 | kstephens | maybe setter = :"#{name}=" ? |
| 21:26:51 | Defiler | yeah you avoid ivar_set if you can |
| 21:27:06 | dbussink | evan: btw, that __send__ there is because people wanted to use send as a datamapper model property |
| 21:27:09 | Defiler | but lots of things let you pass arbitrary attributes and then create accessors for them |
| 21:27:24 | dbussink | evan: although i think that people who do that should shoot themselves in the foot now |
| 21:27:28 | evan | dbussink: ok, so if you could dig in a bit and see where it's slow |
| 21:27:34 | evan | i'll work it backwards into benchmarks and such |
| 21:27:38 | evan | some friends showed up |
| 21:27:42 | evan | brb |
| 21:27:46 | dbussink | evan: well, what surprises me now is that autopacking makes it slower |
| 21:27:56 | dbussink | without it, it's faster than 1.9.2 actually |
| 21:28:00 | dbussink | with this optimization fix |
| 21:28:20 | dbussink | but i guess allocating a bigger object is heavier on memory pressure |
| 21:28:23 | dbussink | which would explain |
| 21:29:35 | kstephens | class Symbol; def setter; @setter ||= :"#{self}="; end; end |
| 21:33:34 | dbussink | looks like mri has some pretty fast empty hash optimizations |
| 21:34:02 | dbussink | going from no hash argument to using one entry makes it a lot slower |
| 22:59:49 | evan | i'm back |
| 23:00:01 | evan | dbussink: my friend and his 6 month old came over |
| 23:01:05 | slava | who's the better programmer? |
| 23:01:12 | brixen | heh |
| 23:01:27 | spastorino | brixen: how are you? |
| 23:01:30 | slava | kids learn fast these days |
| 23:01:33 | evan | than my friends 6 month old? me. |
| 23:01:42 | evan | she can't crawl yet. |
| 23:01:44 | brixen | spastorino: good, you? |
| 23:03:06 | spastorino | good |
| 23:03:20 | spastorino | trying some things on rubinius :) |
| 23:03:29 | brixen | excellent |
| 23:03:32 | brixen | how's that going? |
| 23:03:34 | spastorino | rails on rbx to be more exact |
| 23:03:42 | spastorino | rails tests |
| 23:03:49 | spastorino | it's quite good |
| 23:03:50 | spastorino | ;) |
| 23:03:58 | spastorino | for me awesome |
| 23:04:05 | evan | spastorino: woo! |
| 23:04:07 | spastorino | i want rbx to be the default ruby |
| 23:04:08 | spastorino | :D: |
| 23:04:13 | brixen | heh |
| 23:04:47 | spastorino | brixen: don't tell to nicksieger :P |
| 23:04:50 | evan | dbussink: did you go to bed? |
| 23:04:57 | brixen | spastorino: my lips are sealed :) |
| 23:05:28 | brixen | spastorino: pero el esta aqui tambien ;) |
| 23:05:47 | spastorino | hahahaha |
| 23:06:14 | spastorino | he want to copy you guys :P |
| 23:06:17 | slava | rbx is the tupac of ruby vms |
| 23:06:24 | brixen | spastorino: ya se! |
| 23:06:33 | spastorino | hahaha |
| 23:06:41 | brixen | spastorino: sorry, I don't type accents :( |
| 23:06:51 | spastorino | hehe no problem |
| 23:06:54 | brixen | I'm a lazy estadounidense |
| 23:07:18 | parndt | so it's soon to die in a drive by? |
| 23:07:22 | spastorino | hehehe it's nice at least you're trying to say something in spanish ;) |
| 23:07:26 | bcg | brixen: I followed your instructions and updated RubySpecs with RBIGNUM_SIGN and all the tests seem to work just fine in rbx. I wanted to test 1.9 against my RubySpec changes but a ton of stuff was breaking ... should I be able to run mspec against my 1.9 target successfully? |
| 23:07:35 | spastorino | you have to steal some good things of JVM |
| 23:07:38 | spastorino | :P |
| 23:07:58 | brixen | bcg: usually 1.9 head works ok |
| 23:08:14 | brixen | bcg: anything less than 1.9.2preview3 is an unknown quantity |
| 23:08:27 | brixen | parndt: let's hope not! |
| 23:08:28 | bcg | brixen: I tried ruby-head too, something else must be going on ... |
| 23:08:39 | brixen | bcg: how did you run it? |
| 23:09:53 | bcg | rvm system ruby-head ; mspec -tr ... |
| 23:10:03 | brixen | hmm |
| 23:10:07 | brixen | I'll try here |
| 23:10:29 | brixen | usually I have a separate 1.9 build so I do: bin/mspec -truby1.9 ... |
| 23:10:59 | brixen | bcg: ohhh, wait, this is c-api specs |
| 23:11:06 | goyox86 | spanish por aqui tambien, and using rbx for rails too ;-) |
| 23:11:07 | brixen | they are really broken on 1.9 atm |
| 23:11:09 | brixen | sorry :( |
| 23:11:53 | goyox86 | spastorino: where are you from? |
| 23:11:56 | brixen | bcg: I need to work on getting the c-api specs running on 1.9 |
| 23:12:07 | brixen | goyox86: where are you from? :) |
| 23:12:25 | goyox86 | brixen: Venezuela here! |
| 23:12:37 | brixen | goyox86: awesome! thanks for trying out rbx :) |
| 23:13:10 | brixen | I need to come to the next rails/rubyconf in sudamerica |
| 23:13:26 | bcg | brixen: so c-api doesn't work on 1.9? |
| 23:13:55 | brixen | bcg: most of it should work ok since 1.9 didn't change that much from 1.8 in the C-API |
| 23:14:11 | brixen | bcg: but for some reason the c-api specs have a bunch of errors |
| 23:14:32 | brixen | bcg: I just need to look into it |
| 23:14:48 | bcg | brixen: ok, well I'll see if I can verify that it behaves the same way as 1.9 if I can't fix the 1.9 c-api issues myself. Thanks for the info! |
| 23:15:04 | bcg | brixen: well if you do let me know. Thanks! |
| 23:15:44 | brixen | bcg: for one thing, it looks like the specs use stuff that is a syntax error on 1.9 |
| 23:16:06 | goyox86 | brixen: I'm an Alan Kay/Goldberg/Ingalls fan ;-) , and i remember the old rubinius site, when i read that rubinius implementation was Blue-Book based! |
| 23:16:27 | evan | bcg: btw, on your work |
| 23:16:28 | brixen | goyox86: ahh yes, it started there in evan's brain :) |
| 23:16:32 | evan | you didn't need to change msgpack at all. |
| 23:16:46 | evan | bcg: nor should you directly expose rb_big_sign() in msgpack |
| 23:16:59 | evan | i was saying that you should define the RBIGNUM_SIGN macro in rubinius |
| 23:17:05 | evan | in our ruby.h |
| 23:18:24 | goyox86 | brixen: i really liked it (Blue book stuff), but i was pretty busy by that days, so i checked out the sources and gave a try, but i left rubinius until a few days ago |
| 23:18:30 | bcg | evan: yea brixen mentioned that to me, I misunderstood you guys in our last chat. I thought thats what you had told me to do ... |
| 23:18:40 | evan | no prob. |
| 23:19:09 | brixen | bcg: ok, looks like mainly 2 things re c-api specs with 1.9: it's not finding ruby.h correctly and some syntax errors in the specs |
| 23:19:10 | evan | I don't want people to have to do #ifdef RUBINIUS in their extensions unless it's the only way to do something |
| 23:19:29 | brixen | bcg: I'll look into fixing that soon |
| 23:19:43 | goyox86 | by the way yesterday i was watchin the docs and i realized that there is some compiler documentation pending |
| 23:19:48 | bcg | I have rectified it but have not updated my msgpack branch yet ... I actually I haven't pushed a thing yet ... will send you guys patches when I get a chance |
| 23:20:27 | brixen | goyox86: yeah, I need to document the basics of the bytecode compiler |
| 23:20:52 | brixen | bcg: awesome! thanks for working on it |
| 23:21:42 | goyox86 | brixen: give some start guidelines, i think this will help me to understand more quickly the implementation |
| 23:22:20 | brixen | goyox86: start guidelines for? |
| 23:22:37 | goyox86 | brixen: so what exactly do you think is the aproach?, to the bytecode compiler? |
| 23:23:13 | brixen | goyox86: do you mean, how does the bytecode compiler work? or something else? |
| 23:23:29 | goyox86 | brixen: about how it works? how it's implemented?, or the API for extending? (ByteCodecompiler) |
| 23:24:15 | goyox86 | brixen: i know that it is implemented in ruby |
| 23:24:18 | brixen | goyox86: I'll write a short doc on how it works |
| 23:25:01 | brixen | basically, the melbourne C ext calls the methods in lib/melbourne/processor.rb to create an AST |
| 23:25:15 | brixen | the classes for the AST are all in lib/compiler/ast/*.rb |
| 23:26:02 | goyox86 | brixen: ok, so what are the main files inside the source tree? That i need to check out to have an idea of the big picture |
| 23:26:30 | brixen | the compiler calls the #bytecode(g) method on the AST nodes, passing g, in insntance of Rubinius::Generator (see lib/compiler/generator.rb) |
| 23:27:24 | goyox86 | brixen: i see |
| 23:27:26 | brixen | goyox86: the compiler is all in lib/compiler |
| 23:27:50 | brixen | the parser is the melbourne ext, lib/melbourne and lib/ext/melbourne |
| 23:28:37 | goyox86 | brixen: melbourne is a port from the MRI 1.8.7 grammar, i mean that grammar? |
| 23:28:40 | brixen | lib/compiler/compiler.rb and lib/compiler/stages.rb are a good start |
| 23:28:55 | brixen | yes, melbourne is the MRI parser wrapped up in a C ext |
| 23:29:46 | brixen | lib/ext/melbourne/visitor.cpp implements a visitor pattern over the C struct parse tree that the MRI parser produces |
| 23:30:10 | goyox86 | brixen: as i see, the parser is not the most important thing to document right?, is the ByteCodeCompiler? |
| 23:30:23 | goyox86 | brixen how is the melbourne documentation? |
| 23:30:33 | brixen | yeah, the bytecode compiler is what most folks want to know about |
| 23:31:01 | brixen | goyox86_: http://gist.github.com/450732 |
| 23:31:17 | brixen | goyox86_: there is not melbourne documentation, sorry :( |
| 23:32:09 | brixen | most of melbourne that is relevant is in lib/ext/melbourne/visitor.cpp and lib/melbourne/processor.rb |
| 23:32:42 | goyox86 | brixen: good, but i agree you the ByteCodeCompiler is most important, than melbourne at this point |
| 23:33:04 | brixen | goyox86_: do this: put some ruby code that you're curious about in a file, then do bin/rbx compile -ABS file.rb |
| 23:33:35 | brixen | you'll get the AST, bytecode, and a s-exp output |
| 23:33:54 | brixen | then use whichever is most relevant to what you are trying to do |
| 23:34:03 | goyox86 | brixen: neat :-) |
| 23:34:26 | brixen | ie, sometimes you just want to see the bytecode, sometimes the whole AST, and sometimes just what it parses to, the s-exp |
| 23:35:19 | goyox86 | brixen: the bytecode instruction set is documented?, primitives and taht stuff? |
| 23:35:42 | brixen | see vm/instructions.def |
| 23:36:07 | brixen | there are a few insns that don't have docs, but they are pretty easy to understand |
| 23:36:10 | evan | primitives aren't in the instruction set. |
| 23:36:23 | brixen | primitives aren't really documented yet either |
| 23:36:43 | goyox86 | was just a question :-) |
| 23:37:42 | evan | brixen: the ones hooked up to ruby methods basically use the ruby method as documentation |
| 23:38:03 | brixen | well, yeah :) |
| 23:38:24 | brixen | the primitives system is a bit more complex |
| 23:51:00 | brixen | evan: did you see that dan ingalls joined SAP? |
| 23:51:34 | evan | oh really? |
| 23:51:37 | evan | no, i didn't. |
| 23:51:42 | evan | dan's great |
| 23:51:47 | brixen | according to this http://www.infoq.com/interviews/ingalls-smalltalk |
| 23:51:54 | evan | oh, i watched bits of that |
| 23:51:58 | evan | must have missed when the talked about that |
| 23:52:02 | brixen | I wonder how blue ruby is going |
| 23:52:12 | brixen | I just saw the SaP bit in the bio |
| 23:52:14 | evan | they've been pretty underground |
| 23:52:24 | brixen | I haven't watched any yet |
| 23:53:03 | evan | brixen: i'm going to selectively change using to_iter in Hash to direct iteration over the Entries |
| 23:53:05 | evan | for performance reasons |
| 23:53:18 | evan | just going to change #each for now |
| 23:53:31 | brixen | ok |
| 23:54:00 | evan | i love the idea, and I need to investigate how we can get the overhead donw |
| 23:54:48 | evan | I think escape detection is a ways off |
| 23:54:49 | brixen | mostly, it was for code quality |
| 23:54:54 | evan | yeah, i know. |
| 23:55:05 | brixen | it's hard to beat a pure loop in code |
| 23:55:14 | brixen | I tried :) |
| 23:55:56 | evan | actually, you know |
| 23:55:59 | evan | with block inlining turned on |
| 23:55:59 | brixen | it will be fun to work on this in the JIT |
| 23:56:03 | evan | we could probably use each {} in methods |
| 23:56:16 | evan | I should do a few experiments |
| 23:56:21 | brixen | cool |
| 23:58:33 | evan | oh actually |
| 23:58:34 | evan | man |
| 23:58:36 | evan | in a hot loop |
| 23:58:44 | evan | an each_entry {} method is faster than to_iter |