Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - serprex

Pages: « 1 2 3 4 5 6 7 »
31
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 06:27:27 PM »
http://www.parashift.com/c%2B%2B-faq-lite/value-vs-ref-semantics.html#faq-31.6

You're explanation of dependent typing is only explaining what compilers already do http://en.wikipedia.org/wiki/Sparse_conditional_constant_propagation

The reason dependent typing isn't wide spread is that it is focused on moving the complexity of the program into the type system. The more powerful the type system, the more complex it becomes to reason about, as the complexity of the program begins to infest the type system. Simplicity is not a thing to be born out of the wild with fire. You're talking about a language designed around the idea that your program mustn't fail. As in, failure equates to killing people. Either that, or you want to mechanize some proof of a proof. Enigma is a game development environment. If there's a segfault, the game ends. Nobody dies. It's just a game

32
Announcements / Re: Collisions
« on: March 28, 2010, 07:30:04 AM »
Hassle is that & requires lhs, so it won't work on rhs expressions

33
Proposals / Re: Idea for var
« on: March 28, 2010, 07:20:47 AM »
Why is this faster? There's too many types. GM is a two type system. struct{union{double d;size_t i;}char*s;} is the optimal type. Though struct{union{double d;struct{uint32_t i;uint32_t r;}}char*s} would be the way to go about refcounting. My version has unboxed doubles. So does Josh's. Yours doesn't. You're designing a smaller var, not faster

34
Announcements / Re: Collisions
« on: March 27, 2010, 10:05:53 PM »
Mean can be parsed mean(a,b,c) -> add(a,add(b,c))/argc
Choose can be parsed choose(a,b,c) -> *((var*[]){&a,&b,&c})[randint(argc)]

35
Announcements / Re: Collisions
« on: March 27, 2010, 08:19:49 AM »
It isn't slow. Inlinining+Compiler Optimizations will make it faster than a generic loop. See http://en.wikipedia.org/wiki/Loop_unwinding

C99 states that a function need only be able to accept 127 arguments, this solution removes that limit

36
Proposals / Re: execute_string via Google V8
« on: March 26, 2010, 10:14:55 PM »
No

37
Announcements / Re: Collisions
« on: March 26, 2010, 09:14:22 PM »
It's called parsing. You parse the fold into multiple calls. Get it? Because you parse it. Also inlining makes it nice. But you don't parse for that

38
Announcements / Re: Quick Poll
« on: March 12, 2010, 06:21:09 AM »
Checkboxes are bad. Different sources will have different habits, and this causes code to be less transferable. The semicolon at the end of a struct is really just some hack of an attempt to have C++ be compatible with C while still extending the syntax to make it feel more OO

39
Announcements / Re: I hate the last ten days before a release.
« on: March 12, 2010, 06:13:54 AM »
but I have yet to set up whatever key it wants me to have in order to use it, so that's a hassle
No, you refuse to set up an RSA public ssh key

40
Announcements / Re: Pride
« on: March 08, 2010, 10:44:09 PM »
Those stats are for the compiler, not the output. Josh, you're still not getting that LLVM is a native code compiler. Here's some links by Dons comparing GHC's native, C, and LLVM backends
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen
http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-llvm

And no JITs on Xbox: http://lua-users.org/lists/lua-l/2009-11/msg00130.html

41
Announcements / Re: Pride
« on: March 07, 2010, 05:38:59 PM »
Generating code for an AOT based VM like LLVM is more work than generating C. It's designed for supplanting a machine code generator with a more generic case. C is similar. Haskell's GHC allows for GCC as a back end; albeit deprecated for a machine code generator, and now someone has devoted their PhD to implementing an LLVM backend. Multiple Scheme implementations (Bigloo, Gambit, Chicken, etc) use C as a back end. PHC, the php compiler, converts to C++. All these languages support closures. I love first class functions, my design of Fractaler shows it, but we're just trying to work out a translation of GML here, and GML's closure support is something along the lines of passing strings around to be executed with execute_string. Also notice how all the languages I listed have closures. Scheme is a dialect of Lisp, which introduced closures to the game

I'll agree, I believe LLVM could make a suitable backend for a well designed implementation of GM. Enigma isn't such an implementation though. To use LLVM, you'd have to change the manner by which you go about it. We're attacking this is a completely different manner than code generation

Rusky, I'm not judging anything you do outside of this project. I don't even know what you do
Don't pull Josh not accepting anything you do because he didn't do it, you never offered a working fork of Enigma that consists of your work. He's cooperating with the changes I've been making because I'm applying them to a copy of Enigma which can showcase the changes

42
Announcements / Re: Rejoice
« on: March 07, 2010, 08:04:55 AM »
One of the qualities I enjoy of English is how easily verbs and nouns can be interchanged. It's something that doesn't work well in French

43
Announcements / Re: Prophase
« on: March 07, 2010, 07:56:45 AM »
Yeah, before I could get a C compiler working I recall Josh was just starting with C++. When I found GM7's debug flag, I had him write a program to essentially fopen;fseek;fputc;fclose; Enigma is the first large piece of code of another I ever poked around, it's odd seeing how I've changed in respect to it. It's a place where I write code and think it seems pretty nice, only to rewrite it again a year later

Enigma taught me C++, though I was fortunate enough to have already known programming. If you want to work on adding Enigma functions, work off the git repo @ http://github.com/serprex/Enigma-R3 though it's been modified to be developed on Linux, so some patchery will be needed to get it back to the Windows state. Hassle yes, but Josh plans to have that fixed for R4

44
Announcements / Re: Pride
« on: March 07, 2010, 07:40:56 AM »
I think GML is simple enough that it'd be better to compile it more like many ML/Haskell compilers do, native code with calls to a fat libc-esque library for the language

I've read that some prefer to hand roll their parsers. Josh is one such such. Rusky, you're complaining that Enigma is hard coded to GML? I wasn't aware it was suppose to be anything else

You're a lazy ass. You don't contribute anything to the project but weenieism. Complain with examples; I wrote up a toy implementation of GML's type system catered to GC and type tracing, something Josh hasn't quite explained to me how he plans to deal with. Nothing really came of it, because I was unsure how to integrate it into Enigma. I recall you wrote a bit of a grammar for GML, that could have been useful. Unfortunately, because you didn't implement a patch to integrate it with Enigma, it's shit for dicks

45
Announcements / Re: Encryption
« on: March 05, 2010, 06:39:35 PM »
It's funny when people think they're introducing some advanced concept, and so they include a wiki link
It's also funny when people forget the magic of hashing

Pages: « 1 2 3 4 5 6 7 »