ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on September 09, 2009, 10:58:18 pm

Title: I'm bookmarking this day
Post by: Josh @ Dreamland on September 09, 2009, 10:58:18 pm
I called it fair and square.

Today consisted mostly of school and battling code. But I had fun, and made another awesome dent, at least.

Code: [Select]
Macros:
a:   Serves as typename : struct
{
  b:   Serves as typename : struct
  {
    member1:  int 
    member2:  int 
  };

  itsanintyoubastard:  int 
  nested_struct_instance:  b 
};

auto:   Serves as typename
bool:   Serves as typename
char:   Serves as typename
socks:  int 
colligma:   namespace
{
  a:  int 
  b:  float 
  c:  double 
  d:  somethin 
  e:  somethin 
  f:  char 
  g:  int  Dereference path: (params = 0)</group>
  h:  int  Dereference path: </group>[]*</group>
  somethin:   Serves as typename : struct
  {
    d:  int 
  };

};

const:   Serves as typename
double:   Serves as typename
effing_a:  a 
float:   Serves as typename
int:   Serves as typename
lime:   Serves as typename : struct
{
  candy:  bool 
  disease:  int 
};

long:   Serves as typename
register:   Serves as typename
short:   Serves as typename
signed:   Serves as typename
some_big_ass_function:  int  Dereference path: (params = 0)</group>
static:   Serves as typename
tt1:   Serves as typename : struct
{
  tt2:   Serves as typename : struct
  {
    tt3:   Serves as typename : struct
    {
      a:  int 
    };

    tt3i:  tt3 
  };

  tt2i:  tt2 
};

tt1i:  tt1 
unsigned:   Serves as typename
volatile:   Serves as typename

That was generated from this code:

Code: [Select]
struct a

{

  int itsanintyoubastard;

  struct b

  {

    int member1, member2;

  } nested_struct_instance;

} effing_a;



namespace colligma

{

  int a;

  float b;

  double c;

 

  struct somethin

  {

    int d;

  } d;

  somethin e;

 

  const mutable char f;

 
  long unsigned int (h)*[2];
 

  int g()

  {

    heh; this does nothing;;;;;;

  }

}

int some_big_ass_function()
{
  some code
}

int socks;

struct tt1
{
  struct tt2
  {
    struct tt3
    {
      int a;
    } tt3i;
  } tt2i;
} tt1i;

struct lime
{
  int disease;
  bool candy;
 
  int operator + ();
};

Pretty awesome. Almost awesome enough to cut it.
Rusky will be amused to know I just moved a 500 line if statement to its own source file. Hahahahahaha. That thing was getting in MY way. Will probably move more.

Things you may have noticed: Supports nested bloody everything. Reports types. Reports references (including functions) in some stack for reverse-iteration. Ignores code.  Clunks out at operator+ because it's skipping another huge-ass if statement I just moved. End of list.

It's damn late, and I'm tired. I'll be up at six tomorrow, so. Just bookmarking this day; it's still mine.
(I'll prolly shoot for some [nearly] equally monumental day coming up, which I will justify with some line of BS.)

Ism is working on an SVN-based updater. This is after we fixed her computer, which is also on Ubuntu, that decided to take a dump and lose her partition table. Through some googling we managed to get it working again from a LiveCD.

Would have made an awesome fish tale if we'd still had time to finish. Nyet...

And night.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 10, 2009, 06:36:37 pm
You could shoot for 11/10/09.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 10, 2009, 07:35:44 pm
That'd be easy as pie.
Like I was saying yesterday, and as the above demonstrates, the CFile parser is REALLY close to completion. Right now I'm working on parameter declarations, as those require a syntax exception I'm not fond of making. After that, I just have to tell it to recognize the template keyword, which is easy, The template system's already integrated, anyway, just needs the initializer and any debugging that hopefully won't follow.

Then I need to make sure the formatter parser knows what to do with the feedback, and same with syntax checker.

Then I'll make sure it can still compile a game...
Then I'm done...

Perhaps we need some semi-public pre-release testing. I'm thinking it'll just be for forum frequent-fliers, meaning don't tell anyone. I'll start advertising after things work, and a couple things I'm itching to do are finished.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 11, 2009, 10:23:14 am
Can you tell us what it won't do?
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 11, 2009, 02:19:59 pm
I'm unsure of timeframe once more, now that 9's have evaded me.
This is what would be in a semi-quick R4. For ASAP, remove anything that isn't already being implemented.

Certainly not 3D, or full enough Wii integration to use. Almost certainly not paths. Possibly not sounds, but those are second priority only to backgrounds. It is unlikely that I won't add backgrounds. Tiles, on the other hand, we will see. (It's a matter of time, not ease or capability. Some things will be saved for after there's a working updater and things have settled).

Maybe not Ism's almost-mplay. Not sure on that one.

No interpreter, sorry. I'll see about debug mode as I work with the compiler.

New instance system... I might put it on hold if everything works perfectly, in fear of messing it up again.

DLLs are in, though. Expect them. (Windows only, of course, unless someone has a brilliant plan for working with them on Linux somehow. I've not looked into the matter at all, and although I don't personally think I can run a Windows DLL on Linux, I've heard rumor from someone that there's some way.)

No extensions. But I won't say never.

Limited DnD. (Only the most basic of action_whatever() will be defined at this point, but code flow should work as you are used to)
Title: Re: I'm bookmarking this day
Post by: RetroX on September 11, 2009, 02:45:53 pm
Windows only, of course, unless someone has a brilliant plan for working with them on Linux somehow. I've not looked into the matter at all, and although I don't personally think I can run a Windows DLL on Linux, I've heard rumor from someone that there's some way.
WINE has the ability to load DLLs; you can use the libraries if you have it installed.
Title: Re: I'm bookmarking this day
Post by: luiscubal on September 11, 2009, 06:19:42 pm
Simple: don't support DLLs on Linux but instead add support for lib.so files!
It's really simple, actually - just google for dlopen.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 13, 2009, 08:04:01 am
This has probably been asked before, maybe even by me (no forum search function), but will Enigma-produced games be multithreaded? What about the compiler, will that use multiple cores?
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 13, 2009, 09:48:35 am
Was planning on having the ability to thread a script, and *possibly* move an instance to a new thread. There's no reason to multithread the compiler, that I can think of. GCC is the labor intensive one, and it is probably multithreaded.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 13, 2009, 11:01:15 am
Was planning on having the ability to thread a script, and *possibly* move an instance to a new thread. There's no reason to multithread the compiler, that I can think of. GCC is the labor intensive one, and it is probably multithreaded.

I meant GCC for the latter, and yes I suppose it's out of your control on that.

I don't really understand what happens when you run two threads. You wouldn't be able to access data the other thread is using, right?
Title: Re: I'm bookmarking this day
Post by: RetroX on September 13, 2009, 11:44:47 am
I don't really understand what happens when you run two threads. You wouldn't be able to access data the other thread is using, right?
Each thread has to run things in an order; you can't do two things at once in one thread.  If you tell one thread to sleep for 2000 milliseconds, you're stuck waiting 2000 milliseconds before you can do anything else on that thread.

Two threads gives you the ability to do two things at once, therefore being faster.
Title: Re: I'm bookmarking this day
Post by: luiscubal on September 13, 2009, 11:51:56 am
Multithreading is also great on multi-core machines.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 13, 2009, 12:35:17 pm
Multithreading is also great on multi-core machines.
Threading between cores is called hyperthreading, not multi-threading.  Multi-threading is within one core.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 13, 2009, 01:23:30 pm
Multithreading is also great on multi-core machines.
Threading between cores is called hyperthreading, not multi-threading.  Multi-threading is within one core.

No. Hyperthreading (HTT) is Intel's proprietary brand of Simultaneous Multithreading (SMT) which is a CPU feature that allows you to run two threads at once on one core at the same time (as opposed to slicing CPU time into segments and using some cycles on each thread). It allows you to use idle execution units when a CPU is waiting for a memory request on the other thread at the cost of increased die size.

Multithreading is running two threads at all, whether on one core or many.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 13, 2009, 09:59:20 pm
Think of it this way. If I let you multithread your object list, one object could be lagging like hell on one thread while the other worked fine. They're like mini-processes under one name. However. Synchronizing threads is a notorious bitch, except for some bloated Microsoft APIs, which I'm not touching anyway.

What that means:
Assuming I could make a separate function list on a new thread, in addition to some confusion with instance_exists (like an instance_sortof_exists()), I can't think of a way right now that objects from other threads could draw anything. (Aside from me calling it again in the first thread).

As retro said, you tell one thread to sleep, it's busy while it does. If that thread is sleeping or lagging, then, I'll have no way of telling it to draw. And frameskipping... probably doesn't work between threads. I have one GL context. So automatic threaded draw is out of the question.

HOWEVER. Once surfaces are figured out (as in, functional on more than 1 in 10 users' cards), I imagine the more... conceptually strong users could figure out how to use them to thread drawing. (IE, a thread2 object that draws global.second_thread_surface)

As far as multithreaded draw with depth... Right now, I'm really tired, so it might just be sleep talking, but I can't even think of a way to do depth between threads. Each thread would be its own "layer" as in GIMP and Photoshop, I imagine.


Another consideration would be threaded scripts. Those could easily work in the background, without much need for automatic sync.
Title: Re: I'm bookmarking this day
Post by: IsmAvatar on September 14, 2009, 02:24:49 am
The problems with threading is that if you wish to draw, they *must* be synchronized in order to avoid two problems:
1) frame lag - e.g. one second into the game, thread1.object is on frame 30 and draws such, while thread2.object is on frame 20 - a 10-frame difference)
2) tearing - a fractional-frame difference between the threads. If your frames are drawn 30 times a second, and there is a 0.900 frame lag between two threads, then you will get one thread's image drawn, and then the other's image drawn only 1/300th of a second before the screen gets flushed, causing the image to flash or not appear at all.

Thread issues are almost always solved with synchronization, which means waiting for one of the threads to catch up (or reach a certain synchronization point, such as the begin of the Draw phase - in which case you don't care if there's a 10-frame difference between the threads, as long as it's not a fractional difference like 10.001 or 0.900).
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 14, 2009, 06:58:57 pm
And waiting for the threads to catch up would often be disadvantageous. It would be a pain in the ass to synchronize the threads in the first place, but then you have the fact that people might not want it done so.

That being the case, I think the best way is to let the user do it with my surface method (Possibly double buffering them, as well. I could implement a specific function set for doing so.)

In fact... I could probably fully implement an automatic system that worked off of that surface idea. The draw event of threaded instances would be called while the target is set to a specific buffer for thread two.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 14, 2009, 07:36:41 pm
While I don't know how much hell this would be to program, you should have thread scripts like create_thread(), destroy_tread(), set_thread(), while the set_thread() would always set back to the original thread at the end of events so that drawing can be done.  That way, you can use multiple threads within objects.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 14, 2009, 08:51:03 pm
Objects can potentially be moved to a separate thread by threading the instance handling code and treating it as a set of separate lists. Scripts can be threaded by turning them over to the kernel to run until they complete. It will be impossible to obtain a return value from a threaded script. (It would have to set a global variable when it is done.)

Functions would look like this:
script_start_thread(script)
thread_create()
instance_set_thread(inst,thread)
thread_destroy(thread)
instance_exists_thread(object,thread)
instance_exists_allthreads(object)

The last function probably raised some O_o. It exists for efficiency, so that instance_exists won't waste time iterating an unused feature. Because of this, threaded instances would be essentially nonexistent. At best, they would exist when the function is called on their own thread. This function would deliberately iterate all threads.
Title: Re: I'm bookmarking this day
Post by: IsmAvatar on September 15, 2009, 12:14:53 am
LGM uses threads to load the Game Information and Global Game Settings frames without freezing LGM itself. Those frames are simply inaccessible until they are fully loaded, and if the user requests them and they are not fully loaded yet, LGM will wait for them to finish loading (essentially it will momentarily freeze). Similarly, LGM calls Enigma in a thread so that LGM isn't frozen while enigma is running. We actually use several threads for enigma. One for running enigma itself, one for retrieving output, and one for retrieving errors. Whenever output/error text is retrieved, it synchronizes with LGM and appends it to a textarea.

These are just a few examples of how threads are useful.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 15, 2009, 10:33:55 am
Yeah, threads are useful to run code in parallel even on single-core hardware, but the real use for the future is multi-core. AMD's launching a 12-core server chip in a few months for example, and even on the desktop it's clear the future contains more cores.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 15, 2009, 02:53:27 pm
12 cores? :o

Anyways, I thought the max was 32?
Title: Re: I'm bookmarking this day
Post by: IsmAvatar on September 15, 2009, 05:59:07 pm
And chances are you'll never use more than 4 cores.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 16, 2009, 11:41:30 am
And chances are you'll never use more than 4 cores.

That's why it's a server chip; they can usually scale to any number of threads.

But we'll never use more than 640k of memory...

--

@Retro

Where did you hear that? Cray uses tens of thousands of x86 cores in its more recent supercomputers.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 16, 2009, 02:19:54 pm
Where did you hear that? Cray uses tens of thousands of x86 cores in its more recent supercomputers.
Well, I thought one individual processor was limited to 32 cores.  Or do you mean multiple processors?  I thought I read it somewhere, but I forgot. :/
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 16, 2009, 02:38:10 pm
Well, I thought one individual processor was limited to 32 cores.  Or do you mean multiple processors?  I thought I read it somewhere, but I forgot. :/

I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.

Title: Re: I'm bookmarking this day
Post by: RetroX on September 16, 2009, 08:21:29 pm
I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.
I've never heard of a 48-core processor, and, to be honest, it sounds pretty pointless in my opinion unless you have 48 things you want to do at once.
Title: Re: I'm bookmarking this day
Post by: luiscubal on September 17, 2009, 08:33:31 am
It seems pointless because programmers aren't used to threads yet.
Honestly, you DO have many things to do at once. Synchronization issues aside, think about this: A single game could have:

1. A thread to do the drawing
2. A thread to handle the input
3. A thread to perform AI
4. A thread to handle the audio
5. A thread to handle collisions
6. A thread to handle GC(since it was in its own thread, GC would no longer be bad for game speed)

So a single game could use 6 threads, so 6 cores would be used.
Now, onto more futuristic situations - you could have the OS use a different core, leading us to 7 cores being used.
Then, antiviruses(assuming you use Windows and not Linux) could use a different core, so they wouldn't affect the game speed. We're now reaching the 8 cores.

Of course, you could merge this things into a single core, but this way would allow multiple cores to be used.

And, yes, I know 8 cores != 48 cores, but then again, why have only *one* thread to handle drawing? And why just *one* to handle AI? Done efficiently, a really big number of cores/threads could mean a really good speed.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 17, 2009, 09:13:31 am
1. A thread to do the drawing
  Why bother
2. A thread to handle the input
  Mark does that, you end up getting the mouse in eight different positions during a lagtastic step
3. A thread to perform AI
  Can't think of an instance that'd be useful, but that wouldn't be part of ENIGMA
4. A thread to handle the audio
  That's necessary, everyone does that
5. A thread to handle collisions
  That would be awful. Unless you had them split up across multiple cores, there'd be more harm than good to come from doing that. (Taking sync on all this into account)
6. A thread to handle GC(since it was in its own thread, GC would no longer be bad for game speed)
  GC? Garbage collection? This is C++. The only garbage collection I do is leftovers from instance_destroy(), and that causes next to no lag. But yeah, it wouldn't hurt, and that's probably the best use for threads here.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 17, 2009, 11:24:43 am
I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.
I've never heard of a 48-core processor, and, to be honest, it sounds pretty pointless in my opinion unless you have 48 things you want to do at once.

It's a GPU. That means it runs graphics. Rendering 3D graphics is highly parallelisable - though shaders aren't enirely like cores, modern graphics cards have up to 1600 of them per chip. So Larrabee will use all 48 cores.
Title: Re: I'm bookmarking this day
Post by: IsmAvatar on September 17, 2009, 02:14:55 pm
I can't imagine how threading AI would be useful. Practically everything but the input is dependent on the results of the AI.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 17, 2009, 02:58:41 pm
I can see threading a pathfinding script, as long as you didn't constantly need the entire path.
If it was optimized for threading, especially. Optimized in the sense that it can put multiple pieces together, including fixing the beginning and end of the path where the points may have moved during processing.

With things like threading, you'll lose the general-purpose functionality you get from simpler scripting, but ideally with a great speed gain.
Title: Re: I'm bookmarking this day
Post by: luiscubal on September 17, 2009, 04:46:46 pm
I was just exemplifying how many cores could be used.

Also, here's a possible AI function:

var whatever = new BehaviorThread();
whatever.start();
//Do something
whatever.waitUntilThatThreadFinishes();
var result = whatever.result;
//Do something with result

As you can see, if I *know* I'm going to need the value of "result" in the future, why not put it in a separated thread and ask the result later(in the scenario of having an "unlimited" number of cores)?
Title: Re: I'm bookmarking this day
Post by: RetroX on September 17, 2009, 05:22:54 pm
Wow, why did I read that as CPU. :/

Anyways, threads are useful.  For doing multiple things at once.  Windows uses a thread for each application.  A single thread for the OS is not one thread; it is many.  It would make sense to use threads to run things in threads for speed, wait for all threads to finish, whereas if the threads do not finish within x time, it's considered too much lag and an error pops up.  All of this is controlled from a separate thread.

why did everyone ninja me

doesn't SMF have an anti-ninja feature

oh, paged, stupid
Title: Re: I'm bookmarking this day
Post by: Rusky on September 17, 2009, 06:22:38 pm
Windows usually has several threads for each application, even. Right now, Firefox is running with 20 threads, explorer with 11, pidgin with 5... Even if you never need more than a few threads for each application (which in the future will probably change), having more cores would still be nice because applications could use separate cores rather than sharing one or two.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 17, 2009, 07:05:55 pm
That's the programs making the threads, not Windows. :/

And yes, it is.  However, it's nice to have threads split across cores, and normally, they do not.
Title: Re: I'm bookmarking this day
Post by: Rusky on September 18, 2009, 10:47:15 am
I know that, silly. I just used the same language as you did with "Windows uses a thread for each application."
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 18, 2009, 11:34:11 am
That's the programs making the threads, not Windows. :/

And yes, it is.  However, it's nice to have threads split across cores, and normally, they do not.

Is that because they can't? Are there two kinds of threads or something?
Title: Re: I'm bookmarking this day
Post by: luiscubal on September 18, 2009, 01:46:19 pm
Look. You can only split threads across cores if there *ARE* multiple threads to split.
That's one of the modern programming challenges. Multi-cores are coming and many applications are single-threaded.Even if there are a few *processes* split across different cores, typically you can find that only one of those processes is doing really hard work. When that process has only one thread - which is more common than it should be - you often end up with a core at 100% and the other(s) at 1%/2%.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 18, 2009, 02:33:54 pm
Thing is, you need the application to do the splitting.  Windows won't and shouldn't split the threads itself; that way, a game can split to one core and all applications can split to one, etc.  For example, you should assign each core a name and task - for example, one is a "game" core, one is a "utility" core, etc.  The OS should decide which core the thread should go to depending on the cores' activity, the requested core, and the resources required by the thread, merging and freeing certain cores according to required tasks, so the most is always used out of the cores.  Obviously, that isn't happening right now.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 18, 2009, 02:55:20 pm
Look. You can only split threads across cores if there *ARE* multiple threads to split.

I know that, I was just thrown by the wording.
Title: Re: I'm bookmarking this day
Post by: Micah on September 18, 2009, 04:41:48 pm
Quote from: RetroX
The OS should decide which core the thread should go to depending on the cores' activity, the requested core, and the resources required by the thread, merging and freeing certain cores according to required tasks, so the most is always used out of the cores.
Sounds like Grand Central Dispatch. It's a new feature in Snow Leopard.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 18, 2009, 08:14:23 pm
Sounds like Grand Central Dispatch. It's a new feature in Snow Leopard.
It is?  Well, thumbs up for Apple.  Maybe Linux will do something like this in kernel 27 or something, if they think of making it.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 19, 2009, 03:41:07 am
Great explanation of GCD:

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13

Too bad the license is incompatible with the Linux kernel.

Title: Re: I'm bookmarking this day
Post by: RetroX on September 19, 2009, 07:16:22 am
I meant something like it, not taking the code.  Unless Apple was a jerk and patented it or something, which I doubt.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 19, 2009, 08:07:33 am
Too much debate, all the time ;_;

For those who are interested, I got a B on my first English paper. It makes me want to bite into something.

At any rate, parsers are still moving along in my free time, which isn't much, but now it's weekend, so I can conjure more.

Have a second English paper to write. Makes me want to smash something.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 19, 2009, 10:27:38 am
Why did you take English? I'm not sure how US colleges work, but couldn't you just take maths and sciences?

Title: Re: I'm bookmarking this day
Post by: RetroX on September 19, 2009, 11:44:38 am
No, you need to take English and History as well as Math and Science.
Title: Re: I'm bookmarking this day
Post by: Rusky on September 19, 2009, 02:20:33 pm
English is also writing and literature.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 19, 2009, 09:56:22 pm
Which is part of English class.

I learn writing and literature in French, too.
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 20, 2009, 04:02:36 am
Ah, right. I don't know if its comparable, but in UK Sixth Form (A-level) you take 4 subjects and I do two Maths, Physics and Chemistry. No writing and almost no work outside of class unless you need to revise something.
Title: Re: I'm bookmarking this day
Post by: score_under on September 20, 2009, 05:03:54 am
but in UK Sixth Form (A-level) you take 4 subjects
I'm taking 5. (In order: Biology, Spanish, Chemistry, Maths, and Further Maths)
I have a friend who is taking 3 - Vocational Business Studies, Applied Science (AKA Science for those with an attention span of zero), and [...something else? It'll come to me soon]. I didn't manage to persuade him to change, but IMO that's a really bad set of qualifications he's going to end up with.

And if you haven't already, this (http://wolframalpha.com/) is a big help with pretty much every one of my subjects except Spanish. (You can look up species, molecules, solve equations, rearrange equations, deal with imaginary numbers, etc)
Title: Re: I'm bookmarking this day
Post by: Game_boy on September 20, 2009, 07:42:55 am
Yes, but it's usual to take four at AS and three for A2.

Where are you applying for university and what for, by the way?
Title: Re: I'm bookmarking this day
Post by: RetroX on September 20, 2009, 09:48:55 am
In the US, you're required to take Math, Science, English, History, and a language other than English (for me, French) in Middle School, High School, and College.

Also, on the download page, it says 2k and up, and I'm quite sure that the G++ will work in 9x as well.
Title: Re: I'm bookmarking this day
Post by: Josh @ Dreamland on September 20, 2009, 08:56:59 pm
If it was just math and science, I'd do nothing outside of class. There are so many core requirements, it's not funny. Or fair.
Right now I'm finishing my psychology essay. I Just finished my Econ project, and made the cfile parser correctly handle typedef'ing new types. (as in typedef struct {...})

I may have to make a unique flag to tell if the type is a typedef, and then use the primary member, that way typedef will work with all the references.

That would mean that it'd use the only member in the type as the official one.
And recurse on more typedefs.
Title: Re: I'm bookmarking this day
Post by: RetroX on September 21, 2009, 02:23:55 pm
And you ignored my 9x note thing. D: