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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1936
Proposals / Re: Documenting stuff in a more centralized location
« on: May 22, 2010, 12:05:55 pm »
Ah, indeed... These SFML docs are very nice. I had to question whether Doxygen had actually produced them, in fact. They've well-structured the mess of methods that need documented from each class... very easy to navigate. I'd really like to use this, in fact, but it introduces a few issues we'll need to handle...
1) We need a way to document the functions ENIGMA puts at the users disposal in a method with which LGM can interface.
2) Although these are very detailed on a per-function basis, I don't see where they've outlined the overall structure of the project (probably because, as a multimedia library, there's no need to).
In fact, the latter gives me my doubts... It seems that Doxygen becomes ugly when there's a lot of interactions between multiple systems. Like Pidgin; I have no idea how they structure protocol plugins because nothing will let me traverse what is called from the UI down. The care they'd have to put into that seems to surpass the structure of Doxygen's output...
If I used this, we'd have a very nice display of what each function does, but we'd have no illustration of what that looked like in the big picture, and we couldn't really use that to allow LGM to give users information about a function based on a downloaded INI/whatever. Unless Doxygen has some API to retrieve lists of such, but even then it would quickly turn into a clusterfuck: LGM is only concerned with docs for functions included from the main source; the ones ENIGMA users can access.
I will look into a workaround with Gary. Maybe Doxygen can cover us, or maybe we can integrate both systems. Doxygen could generate similar docs for individual functions not in main.cpp; the Markdown-like structure I proposed elsewhere could give "bigger picture" documentation and differences between key systems in GM and ENIGMA; and the database-based system Gary has already coded could provide EDL function documentation which would be available to LGM in some easily traversed format. In fact, I'm liking that idea.
We'll continue with what we've already started for now, and then we'll work on getting Doxygen up for other sources, I believe. I will have to talk this over with a2h or Gary, of course, as websites aren't really my forte.
1) We need a way to document the functions ENIGMA puts at the users disposal in a method with which LGM can interface.
2) Although these are very detailed on a per-function basis, I don't see where they've outlined the overall structure of the project (probably because, as a multimedia library, there's no need to).
In fact, the latter gives me my doubts... It seems that Doxygen becomes ugly when there's a lot of interactions between multiple systems. Like Pidgin; I have no idea how they structure protocol plugins because nothing will let me traverse what is called from the UI down. The care they'd have to put into that seems to surpass the structure of Doxygen's output...
If I used this, we'd have a very nice display of what each function does, but we'd have no illustration of what that looked like in the big picture, and we couldn't really use that to allow LGM to give users information about a function based on a downloaded INI/whatever. Unless Doxygen has some API to retrieve lists of such, but even then it would quickly turn into a clusterfuck: LGM is only concerned with docs for functions included from the main source; the ones ENIGMA users can access.
I will look into a workaround with Gary. Maybe Doxygen can cover us, or maybe we can integrate both systems. Doxygen could generate similar docs for individual functions not in main.cpp; the Markdown-like structure I proposed elsewhere could give "bigger picture" documentation and differences between key systems in GM and ENIGMA; and the database-based system Gary has already coded could provide EDL function documentation which would be available to LGM in some easily traversed format. In fact, I'm liking that idea.
We'll continue with what we've already started for now, and then we'll work on getting Doxygen up for other sources, I believe. I will have to talk this over with a2h or Gary, of course, as websites aren't really my forte.
1937
Announcements / Re: Install script - Ubuntu
« on: May 21, 2010, 09:56:26 pm »
You know, as long as this script is for Linux, you may as well call my makefile generator script under CompilerSource/genmake.sh. It'll make sure the damn makefile is current. Would be convenient if SVN could call that thing before commit.
1938
Proposals / Re: Proposed Central Documentation Format
« on: May 21, 2010, 06:41:59 pm »
Assuming Markdown is the format off which I based this idea, it's very nice but unfocused. This format is more tailored to ENIGMA's docs, I hope. I intend to ask Gary for a method of indexing based on group. For example, all --Inconsistency----- Labels, marking differences in behavior between GM and ENIGMA, would be nice if listed for quick lookup.
1939
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.
1940
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:
That is actually a good foundation for the instance system documentation. Basically, that should look like this:
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.
Code: [Select]
--Future-----
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...
--Philosophy-----
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.
1941
Proposals / Re: LGM-ENIGMA options panel.
« on: May 21, 2010, 05:13:06 pm »
Lucid, GNOME Version: 2.30.0.
1942
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.
1944
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]
[bannergraphic]http://enigma-dev.org/docs/link_graphic.svg[/bannergraphic]
[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.
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]
[bannergraphic]http://enigma-dev.org/docs/link_graphic.svg[/bannergraphic]
[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.
1945
Proposals / Re: Documenting stuff in a more centralized location
« on: May 21, 2010, 04:17:50 pm »
Heh, fuck that.
1946
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.
1947
Proposals / Re: LGM-ENIGMA options panel.
« on: May 21, 2010, 03:20:43 pm »
Ism: That was of the first things I did.
1948
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.
1949
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.
1950
Proposals / Re: LGM-ENIGMA options panel.
« on: May 20, 2010, 02:23:55 pm »
Well, my Jars open with the archive manager.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »