ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on July 21, 2009, 09:27:47 PM

Title: Subject
Post by: Josh @ Dreamland on July 21, 2009, 09:27:47 PM
I told a2h to rag on me to post what I've done each day.
Don't get your hopes up though; I'm not updating the stupid 'completed functions' page.

Recent activities include collecting all my work from the last few months and organizing them into the same root directory.
What's basically happening is I'm hooking up the Expression evaluator, CFile Parser, Syntax Checker, and EDL Parser up to the Compiler, regardless of what's done and what's not.
This will, ideally, allow me to get them all working together and add on as I go.

I've also begun a large-part recode around the original EDL Parser. It has to be done at some point. Why? Well...

It's a somewhat-known fact that the EDL Parser is written in GML. A lot of you are thinking "wtf" right now. I wrote the parser, then exported it, and parsed it to C++ with itself. And it worked. (With the addition of function names around each script it parsed).

It instantly gained at least a tenfold speed increase, but that's not enough.
(Not to mention parsed GML is plug ugly; NO comments, which is 1% less than the 'desired' percentage of comments I normally leave, and no whitespace or structure)

Basically, the idea's brilliant, but the code's a bit sluggish and eww since it used to be GML. Was the ultimate benchmark, but now things need to be implemented that GML can't describe.

Please take the next couple minutes to get over the fact the parser is/was GML. Read on when you're ready.


Moving on, then, the new parser will not use < to indicate tokens in its stream. Instead, it will add a couple more letters for equally fast, less ambiguous indexing.

Scripts were scoped into each object that used them in R3. In R4, they will be defined in the global scope, and will be passed this. (The C++ loose-equivalent of id) This corrects a problem where with (a) scrname() doesn't work. You probably didn't notice.

Also, localv is being changed to local in light of Yoyo deciding that global var a; was a good idea. Now you can say local var a;, which is about as useless as saying self.varname, but is useful for saying local int a; or local double a; and not wasting all that space and time. (Though not much of either, really.)


Those who pay attention and have decent footing between these two languages know that you will now have the entirety of C++ at your disposal. If you really wanted, you could #include <iostream> and cout << "something";. Unless I decide that I'm going to maintain checking for assignment operator, in which case you'd have to say something stupid before it with an =. Haha.


There's another chunk of work I'm not looking forward to, which involves the new format. We've added basically every resource to the format, but this doesn't mean they all work yet. I'll derive background from sprite, but sound is gonna be a pain in the arse.


Another change, for those with good footing in C++, is that string() will not be a function anymore. GML fans,  don't panic: Saying string() will still work. The difference is purely technical; string() will be a constructor of a new datatype.
I had a problem with var that prohibited me from taking int as an argument type, which hindered efficiency. The new string class should fix that problem. It will be derived from std::string, with some additional namespace magic to prevent screwups.

If anyone really needs me to explain the details of that, I can, but I'm not going to unless someone asks.



In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.


Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).


No news on ENIGMA's LibOGC frontend.

Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.
Title: Re: Subject
Post by: Game_boy on July 22, 2009, 04:44:24 AM
Is there going to be any part of the final thing that'll be the same as it was in R1 ? (:P)
Title: Re: Subject
Post by: Josh @ Dreamland on July 22, 2009, 10:47:21 AM
Next to no part of R3 was the same as R1. R3 didn't have a line of code in the same place as R1, but a diff would have shown that it wasn't more than 30% changed. R4, though... Probably not.

Rusky once called the RX releases 'Proof-of-concept', and I kind of like the term. And as I'm thinking of more concepts to prove, and fixing up the old things... Most of the code just isn't going to last.

ENIGMA used to be C, which means that some of the code still uses malloc() instead of new[]. (And then still fewer frees it with delete[] even after allocating with malloc XD). Things like that didn't make it to R3; only survived R2 because they worked. And I've thought of better ways to do certain things each progressing release (scripts in R1 probably didn't even work. R2's had some glitches, R3's didn't work in with()... R4's will be, so far as I can see right now, flawless).

ENIGMA's such a big project that it's impossible not to get better at things as you work on it. And as you get better, you notice how bad your old code was, you get a great feel for the big picture, and you think of ways to make even trivial things more efficient. I like being able to say I've paid attention to detail as far as efficiency goes. And even though no matter what I do wrong, it'll never be as slow as GM, I want to keep it as fast as possible.


Thinking back to the first release, how disoriented I was hooking everything together... There was so much that interacted with and depended upon so much else... I wanted to just lie down and quit. Couldn't follow it all in my head. I ended up blindly following the original plan without giving any question to what was going on, and it worked. Since then, I have no problem, as you can see, gutting the entire project and putting it all back together. It's even taking less time to do things.
Title: Re: Subject
Post by: RetroX on July 22, 2009, 06:36:51 PM
I pretty much do the same thing.  I like to keep things consistent, and when I find something better than what I used to do, I edit everything else to do the same thing.  I used to use "i+=1" in all my scripts.  I changed them all manually to "i++" because my opinion changed from "why do I care" to "hey, it's faster."

And while you don't have to update the completed functions list, at least update it when R4 is released.

Local is good.  It's always nice to have the default as an option to set, even when it does nothing normally.  Will (local) and (global) typecasting be possible?

And here's an idea - debug mode makes console applications, which cout information about the functions run (similar to how Code::Blocks compiles all debug projects as console), and LGM can set an optional logfile to store the information in.  Plus, closing the console will instantly kill the process, so if the window freezes, you can still easily exit.  Just displaying the function and the argument values would be plenty, since you could easily know what lines were executed in case a fatal error happens.
Title: Re: Subject
Post by: Josh @ Dreamland on July 22, 2009, 09:45:44 PM
Retro:

Debug mode will hopefully utilize that expression evaluator I made.
Currently debug mode will offer some additional error checking, such as adding strings to integers.

I don't understand how casting to the global scope would work, really.
As in GM7, you can declare a global by saying
Code: [Select]
global var a;ENIGMA will just add local to that for things like this:
Code: [Select]
global var a;
local int b;
global double c;


Anyway.
Today's standings:

I've called this function basically every bad word in my vocabulary. It needs to keep track of scope for when you say "using", which totally fucks the simplistic find-replace structure of my parser in the ass.

Parser strips and stores strings now, and successfully removes all whitespace and comments. This was going to be the only major change, and it's proving to be just as big a pain as I thought it would.

The goal of what I'm doing right now is to set up what I call a syntax map, which is a copy of the code kept in a separate string, only where varnames, numbers, statements (such as if), declarators (such as var), etc, are each given a separate letter to represent them.

This is the same thing the original parser did, only I've condensed it, and am doing a couple things slightly different for improved efficiency.

The problem is figuring out whether the current name I've run into is just a name, or if it's a declarator like var. Checking if it is var is easy, but C++ brings classes to the table, so I need to be able to check if the user has declared a class by that name, too. Overall, it is a huge pain in the ass.
Title: Re: Subject
Post by: Rusky on July 23, 2009, 11:18:13 AM
GM doesn't actually support "global var", but rather a new keyword "globalvar". It's rather stupid, but if you use the global/local system you could just add globalvar as an alias for backwards compatibility.

On the parser... those problems are why people use recursive decent and LR parsing and stuff instead of find-replace.
Title: Re: Subject
Post by: RetroX on July 23, 2009, 12:30:41 PM
I don't understand how casting to the global scope would work, really.
unsigned int x; // x is unsigned int
x=(signed int)x; // x is signed int

unsigned int x; // x is unsigned int
x=(signed)x; // x is signed int

local int x; // x is a local int
x=(global int)x; // x is a global int

local int x; // x is a local int
x=(global)x; // x is a global int
Title: Re: Subject
Post by: Rusky on July 23, 2009, 12:59:19 PM
Wow, you described the syntax for casts. Amazing.
Casting changes something's type, not its scope. Changing the scope of a variable doesn't make any sense. The only thing I can think of is that you're trying to access a global variable x when you're shadowing it with a local variable x. That wouldn't be a problem for casting, but rather for ::.
Title: Re: Subject
Post by: Josh @ Dreamland on July 23, 2009, 05:38:53 PM
*facepalm*

global int x = x;
local int x = x;

alternatively

global.x = x;
local.x = x;

But both of those will end up being var.
Title: Re: Subject
Post by: Josh @ Dreamland on July 24, 2009, 01:26:55 AM
Today's standings:
Getting ass raped by preprocessors.
Code: [Select]
var a =
#if somemacro
  0;
#else
  20;
#endif

Don't get me wrong, that's a SHITTY way to do ANYTHING. But because it CAN be done, I have to accommodate it. And that just sucks.
The question left by the above piece of code is, should they not use them, HOW DO I ADD SEMICOLONS TO THAT?
The only way to take care of it is to go all out on my expression evaluator and have it evaluate #if. That way, I don't rely on GCC for that part.

#pragma will result in a PEBKAC exception, or will be moved to the DESIGNATED resource for such bull.
#define will probably be #undefine'd after the piece of code they are used in. This is mostly to remove confusion in cheap hacks, by eliminating them entirely.

And this sort of rage is why I never post progress XD
The general public isn't used to the fact that when I am flaming something like that, it's because I'm enjoying myself and am intrigued by a problem.
Consider it a way of not only venting, but also recollecting based on what's known to not work, process-of-elimination style.
This is nothing I can't handle. (I hope. Just believe it.)
Title: Re: Subject
Post by: notachair on July 25, 2009, 12:46:23 AM
bump
Title: Re: Subject
Post by: score_under on July 25, 2009, 10:22:36 AM
Quote from: Josh @ Dreamland link=topic=298.msg2125#msg2125 date=1248416815
[code
var a =
#if somemacro
  0;
#else
  20;
#endif
[/code]

Don't get me wrong, that's a SHITTY way to do ANYTHING.
Code: [Select]
void DecodeProc2(FILE* fileM_,
unsigned int narc,
unsigned int FileZoomPos,
char*filename
#ifndef DLL
,FILE*fsend
#endif
)
{
My code.
And I don't see any way around it, apart from passing NULL to it, which would kill me from the inside knowing that I'd committed such a crime, or repeating the function definition, which is silly and unnecessary.

Also the argument names have been renamed countless times due to collisions with other variables... you should see one of my other functions, I have 2 variables and the only difference between their names is the position of their capital letter.
Title: Re: Subject
Post by: luiscubal on July 25, 2009, 03:15:06 PM
@score_under You are probably doing something wrong. I don't mean the preprocessor, but the variable names. No matter what you do, names should always be kept relevant. If you have collisions, then maybe you're not doing it the best way? For C++ class code, fields are often prefixed with "m_" to avoid those conflict problems.
Passing NULL as argument isn't a crime. 2 variables with such small difference in their names, however, is.
Title: Re: Subject
Post by: Josh @ Dreamland on July 25, 2009, 10:30:55 PM
Luis-- score_under's a C programmer. If he has collisions, it's because what he's doing is so unforgivingly complicated that he needs that many variables.

score_under:
That's the less ugly way. There is an alternative, though, which is what I would have used instead in my example.
Code: [Select]
#ifndef DLL
  #define filearg_if_not_a_dll, char*filename
#else
  #define filearg_if_not_a_dll, char*filename
#endif

void DecodeProc2(FILE* fileM_,
unsigned int narc,
unsigned int FileZoomPos,
char*filename
                 filearg_if_not_a_dll)
{

But overall, people consider that a gruesome mutilation of the language, I imagine.





As for progress, it's anyone's game. Meaning. I'm tossing some ideas back and forth with Ism, who will be gone this week anyway. But basically, what we've done now is isolated which groups of keywords will have to be uniquely tokenized. (This grouping is changing a lot since I'm now supporting C++. When it was just the C basics and some GML, there was no need for this kind of reordering. Now there is.)
Title: Re: Subject
Post by: Josh @ Dreamland on July 26, 2009, 10:51:54 PM
Today's progress:
Got the syntax map working with basic tokens, and the rest of it is still being planned out.
The simplistic find-and-replace style of the original parser will no longer cut it, due to this trinket:

Code: [Select]
struct type
{
  int value;
  type& operator int() { return value; }
}

type a;
a.value = instace_nearest(x,y,object0); //This sets the 'value' member of 'a'
a.b = c; //This pretends 'a' is an integer, treats it like an id, and thus sets object0.b to the id of whatever the nearest object0 was

Depending on the practicality of your thoughts and your knowledge of C++, you're either saying "oh boy, can't wait", "who cares", or "he'll never pull it off".

Maybe one of you is thinking "good luck," but somehow I don't think so. sadface

That assessment will be based on whether the class you named has a method of casting as int, and whether or not it contains a member by that name. This was a real no-brainer scenario. Not sure what to do if someone says

Code: [Select]
struct a {} b;
b.a=0;

Will probably try to throw a syntax error.
Title: Re: Subject
Post by: skarik on July 27, 2009, 05:07:04 PM
Code: [Select]
struct a {} b;
b.a=0;
Do people actually have that happen?
Title: Re: Subject
Post by: RetroX on July 27, 2009, 09:12:24 PM
That's essentially the equivalent of doing:
Code: [Select]
int x;
x.int=0;
Title: Re: Subject
Post by: skarik on July 28, 2009, 12:31:38 PM
Why?
Title: Re: Subject
Post by: RetroX on July 28, 2009, 10:17:06 PM
I dunno; ask Josh.  He's seen things way crazier than I have or ever will.
Title: Re: Subject
Post by: Josh @ Dreamland on July 29, 2009, 12:11:39 AM
It's worse than int x; x.whatever;

In that code, you at least have four bytes to work with. This offers nothing; the structure has no member by that name, and it certainly can't be treated as an integer, so ENIGMA really has nothing to do with that but error.
Title: Re: Subject
Post by: RetroX on July 29, 2009, 08:11:41 AM
I still don't get why someone would say int x; x.int=0;
Title: Re: Subject
Post by: Rusky on July 29, 2009, 11:21:19 AM
Because they're stupid. You can't just ignore possible stuff just because nobody would do it, you have to give an error.
Title: Re: Subject
Post by: RetroX on July 29, 2009, 10:00:33 PM
Because they're stupid. You can't just ignore possible stuff just because nobody would do it, you have to give an error.
Even GM doesn't do that completely, and they'll have at least 9000 more dumb users than we ever will.
Title: Re: Subject
Post by: score_under on July 30, 2009, 08:18:03 AM
at least 9000

No no no, it's "at least 100" or "over 9000", but not a mix of both! You may as well say "Last thursday we can has at least 9000 moar n00bs".
Title: Re: Subject
Post by: Rusky on July 30, 2009, 10:39:00 AM
How doesn't GM do it completely? If you do something that doesn't make sense, it errors. Saying x.var is a syntax error, saying x.player_obj is an unknown variable error.
Title: Re: Subject
Post by: Josh @ Dreamland on July 30, 2009, 11:07:13 AM
And var xy; xy.a=0; will error "Undefined variable xy", even though you declared it. var x; errors that you can't redefine a builtin variable. Which is dumb. I may have to make EINGMA error if you say local int x; though.
Title: Re: Subject
Post by: Rusky on July 30, 2009, 01:44:59 PM
But xy is undefined. It's declared, but it has no value. Think of it in a dynamic typing sense, not a static one.
Title: Re: Subject
Post by: notachair on July 31, 2009, 02:33:45 AM
(http://i27.tinypic.com/nwlgxx.png)
Title: Re: Subject
Post by: Josh @ Dreamland on July 31, 2009, 08:52:36 AM
Rusky-
Yes...

a2h-
1/x?
Title: Re: Subject
Post by: score_under on July 31, 2009, 11:56:40 AM
a2h-
1/x?
Yes.
Title: Re: Subject
Post by: whaddsoft on July 31, 2009, 05:16:47 PM
In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.


Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).


No news on ENIGMA's LibOGC frontend.

Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.
How about make it cross platform compatible? Just write once, compile many times?
Title: Re: Subject
Post by: RetroX on August 01, 2009, 11:44:07 AM
That's going to happen, except you need to be responsible and realize certain things when writing your code for non-Windows OSes (filenames, is one example).
Title: Re: Subject
Post by: Josh @ Dreamland on August 01, 2009, 09:25:45 PM
whaddsoft--
If you mean that I should use something cross platform, there's nothing *that* cross platform for me to use. I'm writing it in as low a level interfaces as I can manage. From what I'm seeing, it should work on everything with a monitor.

...Okay, not really. But from what I can tell, pretty much everything in the realm of computers that doesn't support Win32Api supports XLib. And everything else... Well, I'll get to it.

Anyway, as for progress:

Code: [Select]
int a = 0; if a = 1 b=2c=3     else d=4 e=5 f='test removal of strings'g=\"poop\" \
 endorphin = /*removal of comments*/ 6; motherlicker = 7; //or eight\r\n end\
 break; label: goto label; awful_code() return 0  /*

Becomes these so far:
Code: [Select]
ddd n = 0; ss(n = 0);n=0;n=0;bbbb;n=0;n=0;n=";n=";nnnnnnnnn = 0; nnnnnnnnnnnn = 0; nnn;bbbbb; nnnnn: pppp nnnnn; nnnnnnnnnn();pppppp 0;
Code: [Select]
int a = 0; if(a = 1);b=2;c=3;else;d=4;e=5;f=";g=";endorphin = 6; motherlicker = 7; end;break; label: goto label; awful_code();return 0;
Although I was originally considering total removal of spaces, it's proven to work efficiently without doing so thus far. I think I may yet do so for later efficiency/ease, however.

As for explanation of methodology here...

This is a more insightful revamping of my original parser; the one written in GML. However, this one is more capable of handling all the C++ tokens, too.  The old one was modified to do so; this one is being designed for it.

I'm still using the original flow of things, though, so I think I can get away with saying it was still originally GML. The idea was good enough that it operated fine for its time...  now it just needs some polishing up.

Anyway, how it works is relatively easy when you break it down. The code is first stripped of all comments, strings, and whitespace for workability. Comments/Other whitespace become a single space. Strings of any type are replaced with the quote character ("). Variable names become "n". They are then broken down into specific treatments based on if they represent a statement...

Statements requiring () are replaced with "s". These include if(), with(), switch()...
Statements requiring a parameter without needing or plain without () become "p". Take return x; and goto lbl; for example.
Statements requiring an immediate semicolon are parsed as "b". This is raising some questions as to what to do with "do" and "else".

Those two exceptions ("do" and "else") cannot be treated the same.
Code: [Select]
do do a=b() until c=d until e=f
Code: [Select]
if a if b c() else else d()
The first code is valid if "do do" is left alone. The second is only valid if it becomes "else; else". The semicolon there means "do nothing". I'm considering just adding a token for each of them. (Probably "c" for do and "e" for else).

These will mean a couple extra rules added in two simple functions.


The code will seem so simple when it's all laid out. But for now, it's scraping brain matter.
Title: Re: Subject
Post by: RetroX on August 02, 2009, 05:33:53 PM
If I honestly find anyone that codes like that, I will grab them by their throat and toss them out a window.
Title: Re: Subject
Post by: notachair on August 03, 2009, 02:52:33 AM
whaddsoft--
If you mean that I should use something cross platform, there's nothing *that* cross platform for me to use. I'm writing it in as low a level interfaces as I can manage. From what I'm seeing, it should work on everything with a monitor.
Amiga?
Title: Re: Subject
Post by: Josh @ Dreamland on August 04, 2009, 11:51:18 PM
And the Commodore 64, sure. I just have to write up a couple window functions for t-- oh, that's right.

But seriously, all the major OSes either are Microsoft, or they support XLib. So that's BASICALLY everything with a monitor. And since GL guarantees two colors, and XLib doesn't guarantee shit, we're good.

Progress:

(ddd)a is ccccca instead, so )a isn't misread and replaced with );a
Still working toward finishing parsers. Tomorrow I must experiment with syntax checker, making sure it's finished and incorporating inline structures/classes. (And inline asm if syntax check doesn't have that in yet).
Title: Re: Subject
Post by: Rusky on August 05, 2009, 10:29:10 AM
*chokes and dies*
Title: Re: Subject
Post by: notachair on August 06, 2009, 06:44:38 AM
/me covers Rusky's eyes
Title: Re: Subject
Post by: IsmAvatar on August 06, 2009, 10:37:42 AM
* IsmAvatar puts pennies on Rusky's eyes
Title: Re: Subject
Post by: RetroX on August 06, 2009, 12:46:54 PM
/me realizes he had just misread IsmAvatar's post
Title: Re: Subject
Post by: Josh @ Dreamland on August 07, 2009, 07:24:21 AM
/me wonders where the discussion went, but likes combos
Title: Re: Subject
Post by: Rusky on August 07, 2009, 10:18:52 AM
* Rusky writes a real parser
Title: Re: Subject
Post by: Josh @ Dreamland on August 07, 2009, 08:20:58 PM
/me laughs for a number of reasons
Title: Re: Subject
Post by: Rusky on August 07, 2009, 08:26:10 PM
* Rusky fights with Josh on MSN
Title: Re: Subject
Post by: Josh @ Dreamland on August 07, 2009, 09:21:13 PM
/me hates bittersweet compromises
Title: Re: Subject
Post by: RetroX on August 08, 2009, 06:30:47 PM
/me likes to mention that what he misread was "IsmAvatar puts err... something on Rusky's eyes"
Title: Re: Subject
Post by: IsmAvatar on August 09, 2009, 11:12:48 PM
C-c-c-combo Breaker!

It's an old norse- and similar belief that when you die, you need to pay the boatman (the guy who boats you to whatever afterworld) a fee. As such, they tended to put silver coins (and eventually pennies) on peoples eyes when they died. The Beatles make note of this in one of their songs and mention "My advice for those who die: declare the pennies on your eyes. Taxman!"
Title: Re: Subject
Post by: Josh @ Dreamland on August 10, 2009, 08:30:00 AM
He thinks I'm paying two cents to go to hell?
Title: Re: Subject
Post by: qc.zackf on August 10, 2009, 01:43:22 PM
LMAO. Wait. What if you don't pay this 'taxman'? Do I not have to go to hell?
Title: Re: Subject
Post by: luiscubal on August 10, 2009, 02:35:36 PM
The alternative is worse.
Title: Re: Subject
Post by: IsmAvatar on August 10, 2009, 05:13:51 PM
In those religions, the afterlife was heaven, even if it was underground. The alternative was to stop existing, which was undesirable to them. They didn't have a land of torture like Christianity's Hell. People were just good because they wanted to get into their "heaven".
Title: Re: Subject
Post by: RetroX on August 10, 2009, 08:34:00 PM
atheism

Seriously, the idea of having different things happen to you depending on what religion you believe in has always boggled me.
Title: Re: Subject
Post by: qc.zackf on August 10, 2009, 08:52:49 PM
That's why you must define "GOD' in your own way and not use ANY religion to do it for you. I wouldn't say I'm an atheist; I do believe in "GOD" just I don't believe he's this higher entity who rules over everything, just simply 'the thing' that created life. Which I don't know what is yet.

Anyways isn't this all going OFF-topic?
Title: Re: Subject
Post by: Game_boy on August 11, 2009, 04:09:04 AM
That's why you must define "GOD' in your own way and not use ANY religion to do it for you. I wouldn't say I'm an atheist; I do believe in "GOD" just I don't believe he's this higher entity who rules over everything, just simply 'the thing' that created life. Which I don't know what is yet.

Anyways isn't this all going OFF-topic?

Here's my question: is your concept of God supernatural? That is, does it suspend natural laws, determinism, or "live outside the universe"? If it does, how could you believe in it, as all phenomena we have found so far (have evidence for) are deterministic etc. If it doesn't, then God is an unnecessary concept and instead of natural laws -> God -> life you could just eliminate the middle step to make it simpler and therefore more likely. [Occam's razor].

Title: Re: Subject
Post by: qc.zackf on August 11, 2009, 04:51:12 AM
No, my "GOD" IS the natural laws of the universe.
Title: Re: Subject
Post by: luiscubal on August 11, 2009, 07:11:17 AM
Code: [Select]
No, my "GOD" IS the natural laws of the universe.That's an acceptable definition. However, what natural laws are you referring to? Relativity and Quantum Physics?

Code: [Select]
Seriously, the idea of having different things happen to you depending on what religion you believe in has always boggled me.Theoritically, different things don't happen to you depending on your religion. Different things happen depending on which religion is right(not which we believe is right). And the bonus thing is, we have no way to find out/prove which one is correct! Yay! You can just rely on faith(and considering the number of incompatible religions in the world, a huge number of people have faith in something that's incorrect) or do what many people do - don't care(which might not be the most wise option).

And yes, this is getting off-topic. A lot.
Title: Re: Subject
Post by: Game_boy on August 11, 2009, 12:14:52 PM
No, my "GOD" IS the natural laws of the universe.


How does calling that God help? If I rename watermelons to God, does that add anything to my life? I think you don't believe in God but you don't want to let go of being brought up in a religion and the moral/cultural/social systems it provided.

Title: Re: Subject
Post by: RetroX on August 11, 2009, 01:56:01 PM
Question: Why do we care
Answer: We don't.  ...which is why politics should become separated from religion, people should stop caring about religion, and SCIENCE should rule the world.  Don't bother with something you can't prove.

Question: Josh, do you think you can release r4 by 09/09/09, to follow the sequence that r3 had set?
Answer: ???
Title: Re: Subject
Post by: Josh @ Dreamland on August 11, 2009, 03:48:06 PM
I hope so :3
</religious war>, or I'll change all your signatures to state your support for a random religion.
Title: Re: Subject
Post by: RetroX on August 11, 2009, 04:05:33 PM
</religious war>, or I'll change all your signatures to state your support for a random religion.
That would be awesome.

But really, we should stop.

And it would be cool if r4 was done by 09/09/09.  And you wouldn't have to worry about releasing v1 until 10/10/10!
Title: Re: Subject
Post by: Josh @ Dreamland on August 11, 2009, 04:41:13 PM
People won't even mind the wait, if I finish the updater.

Meaning there'd be a small update every here and there, perhaps even a big one, but it'd eventually need re-published.
Title: Re: Subject
Post by: IsmAvatar on August 12, 2009, 08:57:32 AM
What about v1.3? There is no 13th month.
Title: Re: Subject
Post by: Josh @ Dreamland on August 13, 2009, 02:10:26 PM
We'll compromise and make the 1.3 release 32 days after the 1.2 release.