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 - Josh @ Dreamland

1771
Announcements / Re: Where do we stand?
« on: August 23, 2010, 01:40:15 AM »
Also, Ism. When winmake.txt reads this:
\MinGW\bin\mingw32-make.exe

Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?

Also, seems the gray, open console box is fixed in the latest revision.

1772
Announcements / Where do we stand?
« on: August 23, 2010, 01:35:44 AM »
I decided to implement backgrounds in the meantime, and dazappa has kept me busy with a number of interesting bug reports (the worst of which I have just worked out). I am not sure what is in the update-stable/ tag, but fixing it to actually work out of the box on at least Windows and Linux is priority one.

Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.

RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?

As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.

If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.

I am going to finish dazappa's last few bug reports.

IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.

The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.

1773
General ENIGMA / Re: Help File?
« on: August 22, 2010, 05:03:17 PM »
Sounds good to me.

1774
General ENIGMA / Re: Help File?
« on: August 22, 2010, 03:48:49 PM »
CHM files are just HTML, too. If LGM could this format natively, though, without further coding (in excess of an include and a call), then the format sounds perfect. Otherwise... Most platforms come with some sort of chm viewer, or at least have one easily available.

1775
General ENIGMA / Re: Help File?
« on: August 22, 2010, 11:21:17 AM »
I actually started a CHM file, but then I realized that maintaining it is too large a task for any one person, so I decided to invest in an online method and a way for LGM to retrieve that text, as Ism was pointing out.

With a little luck, we'll be able to pull off a Javadoc-like system, capable of looking up info on a function while you are coding.

I may maintain a generic CHM file for learning how to use LGM and ENIGMA, becoming a developer, etc... I need to think about organization, though.

But yes, when this is settled you will be able to help by submitting descriptions for functions that work in ENIGMA. We'll see what we can do with those from there.

1776
Off-Topic / Re: Some guy working since 1987 SPEAKS OUT!!!!!!
« on: August 20, 2010, 09:38:41 PM »
Quote
1. Trigraph and Universal character name conversion.
2. Backslash line splicing.
3. Conversion to preprocessing tokens. The Standard notes this is context dependent.
4. Preprocessing directives executed, macros expanded, #include's read and run through phases 1..4.
5. Conversion of source characters inside char and string literals to the execution character set.
6. String literal concatenation.
7. Conversion of preprocessing tokens to C++ tokens.

My parser does the first six in one pass. The seventh one is unnecessary for my purposes. Also, my compiler skips over the code inside implemented functions, and is not precise in its template instantiations. As a result, I can parse a whole lot of libraries (the entire C posix library and C++ standard template library, in addition to ENIGMA's own headers) in under a third of a second on my machine. (The libraries in question being libraries being sys/signal.h; cpio.h, dirent.h, fcntl.h, grp.h, pthread.h, pwd.h, sys/ipc.h, sys/msg.h, sys/sem.h, sys/stat.h, sys/time.h, sys/types.h, sys/utsname.h, sys/wait.h, tar.h, termios.h, unistd.h, utime.h;  map, list, stack, string, vector, limits, iostream, fstream, cstdlib, cstdio, and cmath.)
I can't control how the GCC does its passes, though, and so yes, I inherit its problems, to which that list applies.

I have, however, done my best to make ENIGMA modular. The vast majority of ENIGMA is partitioned into independent modules that only need recompiled when updated.

Someone told me I should roll my own compiler, too (Not necessarily for C++, but for EDL). I could probably modify my parser to pay closer attention to templates and to tree up the code as well as the declarations, without doubling the time taken. However, I don't have what it takes to assemble and optimize all of that code myself. I believe that I could do it faster than the GCC. I have no idea that I could do it faster than Clang. But I could not do as good a job on the output as either.

Item number 5 on that man's list, though, is just the kind of thing my parser fixes.
Quote
5. The meaning of every semantic and syntactic (not just lexical) construct depends on the totality of the source text that precedes it. Nothing is context independent. There's no way to correctly preparse, or even lex, a file without looking at the #include file contents. Headers can mean different things the second time they are #include'd (and in fact, there are headers that take advantage of this).
The actual function code in the headers is never necessary to assess such. The very point of my parser is, in fact, to fix that. ENIGMA reads the headers up front, extracting only type and parameter information, in order to emulate GM's speedy syntax check. The method is rough at present, but the parsers are still quite fast. They will probably increase in precision over time, as it becomes necessary for me to do accurate checks on function parameter casts.

Anyway, the point is, I have recognized these problems for a while and have done my best to deal with them. We will alwas have dependencies on the GCC (or some other competent compiler--I've been looking into ways to allow compiler trade-out for anything that supports the GNU extensions I use, which presently may just be lrint). It falls on them to implement fixes for the obvious problems.

1777
Announcements / Re: ENIGMA R4
« on: August 20, 2010, 12:24:10 PM »
God damn it, that is the stupidest fucking excuse in the book, and it's officially pissed me off, because now we have the most flaringly beautiful fallacy of accident I have ever seen.
1. Using a runtime library makes binaries smaller, WHEN MORE THAN ONE BINARY DEPENDS ON THE LIBRARY AND SO THE USER CAN BE GUARANTEED THAT IT IS ALREADY INSTALLED. I have to include a megabyte-large AL installer with ENIGMA, and if I don't do something about it, users will have to include that same installer with their games. Why? Because no one has fucking AL installed! As the sole proprietor of libcompileEGMf.so, it doesn't matter WHERE THE FUCK WE PUT IT, IT'S STILL A MEGABYTE OF DLL. Maybe if fuck-anybody had any reason to install OpenAL on Microsoft, I could happily leave AL's DLLs dynamic. But as it stands, no. one. does.

2. Putting a DLL in a system folder that would, ideally, be updated by LGM moderately frequently, is not a good idea. Sure, you can set its permissions to allow LGM to replace it, but then 20 different things have to be modified in LGM to make sure /usr/lib is what this particular operating system supports: so far, Mac has been riding Linux's coattails to functioning at the bare minimum. I'm not exactly sure what trying to write into the correct system folder would do.

1778
Announcements / Re: ENIGMA R4
« on: August 19, 2010, 04:13:32 PM »
Make is the longest part *on your connection.

1779
General ENIGMA / Re: Someone should
« on: August 17, 2010, 02:59:10 PM »
My proposals are, since I am now in the clear of being the "first person" and therefore likewise clear of being shot, as follows:




ENIGMA vector:
http://dl.dropbox.com/u/1052740/elogo.svg

1780
Announcements / Re: Enigma on all platforms
« on: August 17, 2010, 02:04:35 PM »
Brett: IsmAvatar is working on that one. Assuming she's working on anything right now; I haven't bothered her about it lately.
Ism: Are you working on that right now?

1781
Off-Topic / Re: ORACLE begins patent-trolling with Java.
« on: August 17, 2010, 12:37:29 PM »
If the founders of our country thought like you just did, we'd be sipping expensive tea right now instead of arguing about changing systems being an undue risk.

1782
Announcements / Re: Enigma on all platforms
« on: August 17, 2010, 12:32:59 PM »
Brett:
Indeed, as Ism said (and I corrected), your game's code can be found under ENIGMAsystem/SHELL/. Your own code (and the code-generated filler code) is under ENIGMAsystem/SHELL/Preprocessor_Environment_Editable/.

There's almost no point to working with that code, though, since C++ and EDL are almost perfectly intermixable. Ninety percent of C++ is available to you in a typical script, and likewise for GML available in C++ functions. I've yet to document the real differences (Mostly with() and switch(), which haven't even really re-surfaced since R3).

1783
Off-Topic / Re: ORACLE begins patent-trolling with Java.
« on: August 16, 2010, 07:12:13 PM »
I agree they should use C++, because C++ is perfect in every way.

1784
Announcements / Re: Enigma on all platforms
« on: August 16, 2010, 07:03:38 PM »
fix'd

1785
Announcements / Re: Enigma on all platforms
« on: August 16, 2010, 02:27:23 PM »
Disclaimer: Getting ENIGMA to work on the toaster required minor hardware modification to appease OpenAL.