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

Proposals / Re: Documenting stuff in a more centralized location
« on: May 21, 2010, 06:22:32 PM »
Doxygen is a sad excuse for what could otherwise be a navigable system. I don't want to put too much effort into this, but I less want to put too little. Doxygen made developing for Pidgin my nightmare. I would never wish that on anyone.

Proposals / Re: Proposed Central Documentation Format
« on: May 21, 2010, 06:09:52 PM »
Further pondering has brought me to the conclusion that this would be a better idea:

Code: [Select]
Down the road, it may be thought frugal to replace ID-based lookup with pointer-based lookup. With that in mind, only the red-black tree will need removed, and as such, should be #ifdef'd out of the picture. The rest of the system, including the iterators, remains entirely applicable, though lookup functions in other sources will need minor modification to re-perfect "with" statements...

The system was chosen because precedence was given to CPU time over memory usage. Offering a wide variety of storage methods while using an additional layer of pointers-to-iterators to maintain a uniform iterator saves an entire level of complexity. To prevent extra CPU cycles from a double-dereferencing resulting from the additional layer, the first element in the iterator shall be the element that the "backbone" structure would otherwise have introduced. Because these iterators are unified, many cycles are saved in testing the type of iterator during with, and measures can be taken to avoid more than a single call of overhead, up front.


<For insight, refer to graphic images/link_graphic.svg>
This graphic illustrates the iterator systems at the object-ID level. Note that this does not necessarily imply that every instance listed by iterator is directly an instance of the object given by that ID. The way ENIGMA is structured, heredity as implemented by GM is best emulated by listing all children under each object-ID list. As such, the lists can be redundant, as well as ambiguous, but for the purposes they serve, neither is a problem.

The instance lookup system is a bit more complicated. This takes the same structure we see above, but implements a "backbone," so to speak. Here, a red-black tree (given by std::map) is used to provide lookup with logarithmic complexity. A call to the find function will return, if present, a "with"-ready iterator. In the case of with(int:100000..Infinity), this iterator can be copied and reset such that next points to NULL. In the case of with(int:all), the map can be prodded for begin() and the iterator can be copied as-is and used to traverse the entire list. This is legal as this list is neither redundant nor ambiguous. <For diagram, see images/link_with_backbone.svg>


That's all I really have right now. This will be in a separate box of the same color, right underneath.

That is actually a good foundation for the instance system documentation. Basically, that should look like this:

Code: [Select]
[future textbox] [philosophy textbox]  ; These are indicated with the --NAME----- headings. Nothing divides them between rows.
[banner graphic that spans both cols]  ; This is indicated by ^<For (.*), see URL$. Note how this "tag" takes the entire line.
[large text box w/ large span][image]  ; This is set off as a new row with -------, then spanned across two columns with an >.
[second large box, with one sentence]  ; Same; no image. Image above is float:right because its code carries to the right end.

So basically, a few symbols:
-- indicates a heading start, ----- indicates the end of the heading type.
------- is like above only without a heading given; it creates a normal box.
--Heading----------, with more hyphens, makes the box span two columns.
> Spans the box over a column.
<For ([^,]*), [(see)(refer to)(view)] PATH> includes an image.
  • Placing the <> in its own line creates a banner image.
  • Placing the <> at the beginning of a line float:left's the image.
  • Placing the <> at the end of a line float:right's the image.
  • Placing the <> inline, of course, creates an inline image. Like a smiley on this board.
* As the first non-white symbol should signify a bullet, as in an unordered list.

Proposals / Re: LGM-ENIGMA options panel.
« on: May 21, 2010, 05:13:06 PM »
Lucid, GNOME Version: 2.30.0.

Announcements / Re: Install script - Ubuntu
« on: May 21, 2010, 05:06:29 PM »
Replace the sudo calls with one call to sudo su; or combine the install parameters.

General ENIGMA / MOVED: Install script - Ubuntu
« on: May 21, 2010, 05:05:44 PM »

Proposals / Proposed Central Documentation Format
« on: May 21, 2010, 04:53:44 PM »
Anyway, the gist of my thoughts is basically what I did with that SVG explaining tiers. Those who pay attention to elements of design may have noticed that some borders contained a somewhat-cheesy image in the upper-left corner. I would like for several key groups to have such.

Of those in the SVG was a clock. The clock signifies future implications and was purely aesthetic. Same for the question mark, which I would like to change later on. It signifies notes on philosophy. I want another symbol with some kind of yellow and green divided image that will signify a difference between GM and ENIGMA resulting from the system. This is where it gets important: It would be useful to have a method of indexing such, especially the differences, possibly the philosophy and possibly notes on future implications. That way, if anyone pulls an Ism and finds what seems to be some minute difference between ENIGMA and GM, They can check it against that list. Otherwise, they can file a bug report.

Problem is, that requires indexing via something akin to SQL. Perhaps the format could be a simple to parse BBCode-like tagset that represents a div with a particular image in the corner. For example,
[future]This system implies that down the road...[/future] [philosophy]The system was chosen because precedence was given to the idea of...[/philosophy]
[simple=2]This graphic illustrates the system at work assuming that the conditions are such to allow for...[/simple]

Notice a few things. There are no
s. I was thinking the system would be best suited to a well-padded table. Tag [bannergraphic] ends the current row, if there is one, allocating a new row especially for a centered graphic. The example shows SVG. This is negotiable, and may in fact be best left out, though most browsers are capable of displaying them considering that the format is open.
Also, the =2 following the simple. This is to imply that the span/td should span two columns. Otherwise the parser should assume overflow should be done vertically.

This is my proposal for a good HTML-based help format. I wouldn't mind working with it, assuming Gary can whip me up a respectable inline editor, and I know he is beyond capable.

Proposals / Re: Documenting stuff in a more centralized location
« on: May 21, 2010, 04:17:50 PM »
Heh, fuck that.

Proposals / Re: Documenting stuff in a more centralized location
« on: May 21, 2010, 03:22:45 PM »
And yes, I seemed to be avoiding the real problem here and that is a blatant lack of central docs. I'm torn between the love of my life, SVG, and a format that most people can actually work with. Even printing to PDF doesn't really help. Would you care to propose an easily navigable and at least remotely eye-pleasing format? Especially if the program is even moderately pleasant to work with.

Proposals / Re: LGM-ENIGMA options panel.
« on: May 21, 2010, 03:20:43 PM »
Ism: That was of the first things I did.

Proposals / Re: LGM-ENIGMA options panel.
« on: May 20, 2010, 07:43:45 PM »
Nope. Bitches not marked executable if not so, otherwise opens in archive manager anyway. Even though I just picked Sun Java 6 Runtime.

Proposals / Re: Documenting stuff in a more centralized location
« on: May 20, 2010, 02:45:24 PM »
Those are all just broken after various switches between R3 and 4. R3 supported everything you've named off; I'm waiting for a "good opportunity" to install the new instance system for some of those.

Proposals / Re: LGM-ENIGMA options panel.
« on: May 20, 2010, 02:23:55 PM »
Well, my Jars open with the archive manager.

Proposals / Re: LGM-ENIGMA options panel.
« on: May 20, 2010, 08:51:14 AM »
Without doubt, versioning will be easier with any sort of directory/archive based "format." Extensibility will also be increased. Now, each approach has some different problems. I've gradated these here:

Storing as a Directory:
This is a radical approach that will make copying and sharing tedious. Copying a directory makes the kernel iterate file hierarchy, which there doesn't seem to be a good platform at doing. The alternative is to zip the file yourself, which can  be time consuming. The benefit is that the IDE or user can use their own compression scheme, and manipulating resources becomes faster and relatively infallible. Version control would be operable immediately at the push of a button. Selecting the file to load in ENIGMA could be a pain in the ass unless a manifest file is configured: it would just be a directory with an extension; how would ENIGMA know if you just wanted to explore it or if you wanted to explore it?

I would like to propose a solution, part of which I implied in that paragraph. When exploring for a file to open, LGM/the IDE could check for a file called EGMmanifest.egm. If found, it reads it for version, and if the version is sane, it opens it or errors that it is too new/old. Otherwise it just opens the directory. Problem with this is, it would take a lot of work (at least in the APIs with which I am familiar) to specify that behavior when exploring directories. Perhaps Java makes that easier.

That introduces the problem of associating ENIGMA projects with ENIGMA. When you double click a GMK, you get Game Maker. Causing that on Windows/Linux would be a hack at best. For that, I propose that double clicking the .EGM manifest will open the file in ENIGMA. To enable this with mime types, the file could be prefixed with EGM as the first line by standard. Thus, to open their project, users would double click the directory, then double click the manifest. Relatively painless, but somewhat annoying after time, especially with orphaned folder windows.

Storing as a Zip Archive:
This has worked for Java for executables for a long time. Not a lot needs written to a Jar at runtime, if anything, but the functionality is out there. This could make writing slow; the question is whether it would be slower than GM's method of packing everything each and every save. Logically, how could it be? But we've yet to see. Association becomes a real prick on Linux, as Linux doesn't care that the extension is a Jar, it sees the ZIP magic number at the beginning of the file. So Linux users would have to Right Click->Open With->LateralGM. Windows users could just double click though, which is who we're really concerned about not offending with trivial tasks.

Sharing would be fast and easy. Versioning would be kind of a pain in the ass, since the entire thing needs compressed, so you have to wait for that, then the versioning application gets to run on it, so you wait for that, then it gets compressed again... Depending on how often that was, I'd be annoyed.

Storing as a PNG-like format:
Basically, this avoids the above problems of file association, and takes a different approach to attaining an extensible format. This would be the most difficult for third-party applets to manipulate, as they would, unlike in the other two methods, need an understanding of a special format. It would also introduce problems for versioning amid all the plugins.

Consider that in the other two methods, versioning was ready either all the time or as soon as the file was automatically unpacked by a completely unrelated third-party compression tool (even though zip is embedded into Java's language, it still has nothing to do with ENIGMA). Here, a third party would actually have to do a little research to figure out how to open the file.

Plugins would need a method not only for writing and reading their extension from the file, but for unpacking to a directory for versioning, which is just an example of a functionality that someone may wish to implement that would be lost because individual plugins would have to be designed around it: If the plugin wasn't built to support versioning or numerous other functionalities brought to the table by other plugins, then it simply never will unless the author of the versioning plugin or X new plugin specifically codes a method for all the extensions. In case the sheer amount of information in that paragraph made my meaning unclear, I am saying that coordination between formats that are entirely plugin-dependent can be difficult for a new, unrelated plugin.

Also, the "reading" part of this format is likely to get messy due to Ism having no way of knowing (as far as I can tell) how they (plugin/extension programmers, though they don't exist) label their extensions to the format. Not to mention that the order of plugin loading is  likely to change from instance to instance of installed versions, so Ism can't just iterate the plugins asking if this is their work: they could be called prematurely. Basically, Ism would have to make calls to each plugin who has registered itself as a format editor to ask, "Is this your doing? If so, undo it." These methods would all be called (until one fessed up to it) on every extension.

Announcements / Re: Fixed those Makefiles
« on: May 20, 2010, 08:16:05 AM »
luis, flexaplex:
Mark decided he'd take a different approach to the woeful inadequacy of computers' floating point capabilities. While it is true that most languages cannot correctly compare fifths/tenths added together (it is a repeating decimal in binary and therefore can not be represented in a single string of bits of any size), or that sin(pi) == 0 (it's actually 1.2246063538223773e-16), Mark decided that GM should have that capability. That being the case, he made his comparison operators not compare the entire double.

If GM evaluates 1.0000000000001 > 1 as false, Mark is an idiot. ENIGMA will evaluate 1.0000000000001 > 1 and 1.000000000000001 > 1 as true, 1.0000000000000001 > 1 as false. This is because 1.0000000000000001 is simply outside the precision of a floating point value. In actuality, both ENIGMA and GM will store more bits of precision than they check, which is all the solution really needs at this point.

Because of this, I was going to replicate the behavior in ENIGMA by casting to float before comparisons. IEEE tells us that this isn't as simple as just chopping off a large part of the significand, since doubles implement larger exponents as well. But I'm assuming FPUs have a special path just for the occasion.

Announcements / Re: Fixed those Makefiles
« on: May 19, 2010, 06:56:25 PM »
Scratch that. As it happens, sin(180*pi/180) = 1.2246063538223773e-16.

GM implemented a threshold for such in its == operators. I guess ENIGMA will have to do the same. Morbidly disappointing, really.