LateralGM endorsement

[IsmAvatar]

As of today, I'm officially endorsing Robert B Colton as the maintainer of LateralGM. My hope is that this will allow speedier development availability to the public due to less administrative overhead from having to go through me.

I'm aware this is a controversial move, but I have made it clear that I am unable to continue maintaining LateralGM due to a lack of time and a refocus of priorities. As a result, with me being the sole maintainer of LGM, it has stagnated and has been unable to compete with the products that it is intended to compete with, while Robert's fork has advanced a whole slew of new features with the future in mind.

Personally, I'm not a fan of Robert's software development methodology, and he has a lot to learn, but his commitment to the product is ineffable and, with me no longer available, I see no other way.



That said, my methodology and intentions with the product are explained in a few places, but I will restate them here in hopes that maybe Robert will listen and lead LateralGM to a solid future and not turn it into vaporware or such.

* First and foremost, LateralGM was created as a tool for dealing with the Game Maker file format. A vast majority of the users of LateralGM look to it as a way to open their GM files, especially their corrupted files. As such, this is the core of our product and it is never to stop functioning. Likewise, if LGM corrupts files, this is a critical failure.

* Secondly and finally, LateralGM has succeeded by learning from the mistakes of other products. This was the driving force behind LateralGM becoming a full-fledged IDE and not just a file-format tool - to deal with the shortcomings of Game Maker.

The reason it succeeded was because I saw where other products failed - such as G-Java and G-Creator. In my opinion, the reason they failed was because they focused on features and not core functionality. They had some fantastic and admirable features that looked very futuristic and fancy, some of which would be awesome to add to LateralGM, but without a solid foundation/core, it was just feature vaporware. As such, LateralGM learned 2 things. First, develop a solid core, and make sure it never breaks. Second, Features are second-class citizens, releases are first:

So declare the set of features you would like to see in a release, and then be ready to declare feature freeze - a time in development when you will introduce no new features into a release and will instead focus on fixing ALL the known bugs before that release. This is extremely difficult, because features are fun and leftover bugs are a pain, but it's also extremely necessary. Leaving bugs behind is what GameMaker does, not LateralGM. That said, some bugs aren't worth fixing, but they are rare.

A release is not "I've made a bunch of features guys, here, have a release so you can check them out." - that's what a prototype is for, and that's what Feature Freeze beta is for. You've made a bunch of neat features, congratulations, now fix all the leftover bugs and THEN you can declare a release.


Are there improvements to this method? Sure. But we don't have the manpower for it. From being in the workplace, I've learned a few things about software development methodologies and releases that more manpower affords you. We can't just truck through releases like they do - we need to buckle down and focus on what we said would be in the current release, or else officially bump it with good reason and update your roadmap.


I miss working on LateralGM and working with you guys. It was a lot of fun. I wish I still had the time to work on it. Maybe some day I will find some time - believe me, I've been thinking hard on ways to factor it in. If and when that happens, I can't say if I'll continue development in my own fork from the old code (where I left off) or if I pick up Robert's code and try to deal with our differences. But one thing's for sure - at this point in time, there's only 1 thing about LateralGM that I care about and that concerns me, and that's the list of open bugs. Those bugs need to be fixed, and if they're not and we keep releasing features, we are headed down the same path as G-Creator.

[daz]

Hello, Ism. Good to see you and hope life's treating you well. I agree completely with your post. I might hop back on the contribution train myself in an effort to produce a more bug-free product.

[Goombert]

And of course, here we have another propagandist shitpost. Originally I took this news sadly, until reading this topic of course.
https://github.com/IsmAvatar/LateralGM/issues/101

This is nothing more than a completely over-dramatized childish rant similar to the one Josh is now giving.

As such, this is the core of our product and it is never to stop functioning.

Right, it hasn't, and it won't. This is exactly why I have decided to leave it where it is with the GMK format, and move on to the new GMX format for RadialGM and leave GMK in the dust. LateralGM not only exists as a stable GMK editor but also a comprehensive GMK->GMX and GMX->GMK converter, which is less flawed than YoYoGames.

Leaving bugs behind is what GameMaker does, not LateralGM.

As over simplified as that may be, you just can't fix all of the bugs either, that is an unrealistic goal, and on top of that, a few of the bugs are the fault of the JDK itself. Please see the task I have on the 1.8 list which I never intended to ever check off, "Continual improvements/bugfixes"
https://github.com/IsmAvatar/LateralGM/issues/46

A release is not "I've made a bunch of features guys, here, have a release so you can check them out."

Every release for the past two months has been solid bug fixes, the only remaining bug caused by me open on the tracker is the shader editor not having code completion.
https://github.com/IsmAvatar/LateralGM/issues?page=1&state=open

Those bugs need to be fixed

*yawn* so fix your bugs or else I will do so, such as I did with EGM's having a thousand unclosed file handles.

Edit: I'd also like to request this be moved out of announcements, there are things actually worth announcing, and this is not one of them.

[The 11th plague of Egypt]

And of course, here we have another propagandist shitpost. Originally I took this news sadly, until reading this topic of course.
https://github.com/IsmAvatar/LateralGM/issues/101

This is nothing more than a completely over-dramatized childish rant similar to the one Josh is now giving.

Oh, com'on man!
It's not like you never wrote an emotional post before ;-)

People love their work, and suffer from leaving it.
You got blessed with trust and a warning.

You should be happy for this, not draw more hate.

[IsmAvatar]

Do not mistake my language for emotion or a rant. It is a thoroughly thought out manifesto for my LateralGM and the direction I hope to see it go. The warning within my post is not an attack on you, Robert, and the fact that you feel the need to defend yourself from it - by retributing and attacking my character - makes me wonder if perhaps you are aware of more of your own shortcomings on these topics than I am. I'm also curious what kind of propaganda I'm advocating for here, since it's not like I have a competing product that I'm trying to steal your users over to.

That said, I do forgive you if you felt the language was directed - because it was, just not at you. It was directed at the developers of a number of other projects (like G-Java) that have failed for those reasons. I do not question your commitment to the quality of LateralGM. The warning to you in my post is not "you have caused these problems with LateralGM", but rather, "While you have not yet caused these problems, you are also not acutely aware of them, so here I lay them out so that you can better understand and avoid them." That is to say, while before I may have been the lead to help steer what needs to be addressed, and help refocus efforts when they drifted a little bit - I simply do not have the time to babysit LateralGM's direction anymore, so I've laid out this manifesto in hopes that it makes that direction more clear.

The open bugs concern may be an exception to this, but it may also have been due to a misunderstanding in process. I'll address this in a moment.


I'll now respond to some of your comments:

This is exactly why I have decided to leave it where it is with the GMK format, and move on to the new GMX format for RadialGM and leave GMK in the dust

This was an edge case, and I believe you handled this admirably. Again, you continue to demonstrate your commitment to quality, and your ability to devote such great thought to the file format is one of the main reasons I can endorse you. And now you can see that it's a higher priority so if you do see it drifting from this, you know when to correct for this and fix the format.

As over simplified as that may be, you just can't fix all of the bugs either, that is an unrealistic goal

I agree, and I mentioned this in the post as well.

a few of the bugs are the fault of the JDK itself.

Aware. When it comes to those, address them how you like, but try hard to hack around them. You might find a few places where I document my hacks around the JDK's shortcomings or bugs. Usually what I do is make sure the JDK has an open ticket for it, find a/the workaround (usually in the ticket), and use it (with a link to the ticket so the workaround can be removed whenever the Java gets around to fixing it). One thing I've learned in the workplace is that, when you get a ticket that you'd rather just leave behind, the best approach is to just buckle down and give it a go (that is, try to fix it anyways). Once you know that you've put an effort into it, if you can't fix it, that's fine, say so in the ticket and either close it (if it's not a big enough deal) or leave it in hopes someone else can pick it up. Of course, for those, remember you can always ask me for help, as I have a lot of valuable "architectural" insights into the more complex tickets.

Every release for the past two months has been solid bug fixes

This is just a difference of opinion on what's a bug and what's a feature. Not a big deal - glad you know that bugs are a priority. (For example, I often consider support for newer versions of GM as a "feature" until the version has been around for a while, and then it might become a "bug" - completely subjective... there might be a better process for that - heck, maybe even you know of it - so I'm not judging)

so fix your bugs or else I will do so

(The open bugs concern) The misunderstanding here was probably because a lot of the open tickets are difficult things that I don't really trust others to fix reliably, since I designed it, so pretty much I'm the only one who knows how the system works/should work. As I don't have time to work on them, it was hoped that I'd find a free weekend (or, more realistically, a free week) to get to them, but that never happened, so those tickets sat stale forever. Sorry if I take those tickets out on you, I understand your hesitation to take them on when they obviously have my name on them. However, with you in charge now, they are your tickets now, to do as you want with them. Don't be afraid to do a crappy job with them - you can fix bugs as they come up. I just have 2 small suggestions/requests:
1) You can/should consult with me about the best way to approach them if the ticket doesn't make it crystal clear. I obviously don't document exactly my plans for things when I make a ticket for them since I usually figure I'm the only one who will work on it, so the ticket can sometimes be a less-than-descript reminder.
2) As you close off the tickets, especially if you feel your solution isn't a rock-solid facsimile of what I had envisioned, be so kind as to document it somewhere where those things can be grouped together (e.g. the wiki) so that I might be able to look it over when I get a chance. If nothing else, just have one page where you link to each of the tickets.

The second point is really what the whole "review before I pull your code" was for - mostly just for me to get a chance to look at how you addressed certain things that concerned me. What I've learned is that doing that, while ensuring you have a rock-solid product, will also slow development to a crawl. Realistically, we can tolerate a few bugs here or there when they spring up, and that's why we have a ticket system to report those bugs and developers to fix them. This can also create smaller/easier bugs for less experienced developers to take on and get a foot into LateralGM.

[Goombert]

Oh, well I was going to say, even dazappa thought you were being a tad over dramatic.

Aware. When it comes to those, address them how you like, but try hard to hack around them.

Actually, for a few of these things there are ways to hack around them. Take for instance the Game Info RTF bug, I can easily extend the RTF kit to handle alignment or use a different one entirely. Also take the Sound Editor issue with it only playing WAV and not being able to preview OGG, I could easily grab Java FX or something and add a dependency. But this has largely been why I have avoided them, because I did not want to add dependencies to LateralGM and was hoping for ways to resolve them without bloating it, you know? The fewer dependencies, the better imho.

This is just a difference of opinion on what's a bug and what's a feature.

No, I think you can take that a lot further, a feature that is buggy, simply doesn't work, and that therefore disregards it as being a feature or improvement until it operates correctly. This is something YYG fails to understand, it doesn't matter how much shit they add when nobody can use any of it because the whole thing is so damn buggy. This has also been kind of one of my main goals here between ENIGMA and LGM was to get them usable and bug free and in the hands of developers. I feel I made great progress in doing so by fixing so many pre-existing bugs, and also with fundies help and overseeing and helping develop the ENIGMA Portable for Windows. Before it was a real pain to set up ENIGMA when I got here, today, even though people may not find the programs still as useful as they could be, they can at least set the programs up easily and have a chance to test them, you know?

The misunderstanding here was probably because a lot of the open tickets are difficult things that I don't really trust others to fix reliably

I share the exact same opinion, and I also get rather frustrated with the ENIGMA tracker where issues can often be swept under the rug. Due to my OCD nature, I get very ill when this happens because I like to make sure I resolve a bug perfectly.

You can/should consult with me about the best way to approach them if the ticket doesn't make it crystal clear.

I have also made many requests on existing tickets on both ENIGMA and the LGM tracker asking for the posters to please elaborate with more details.

Another issue is for instance the shader editor code completion. I am not able to really decide how best to abstract this and was hoping for help from you or Josh because I didn't know whether to make generic completion classes or if each marker should implement its own or what to do.
https://github.com/IsmAvatar/LateralGM/issues/98

[IsmAvatar]

The fewer dependencies, the better imho.

Right. A few requests do need to have the line drawn. I think a good approach for these dependency-hogging features is the plugin concept. Natively, they are not a part of LateralGM, but if the user opts to include them somehow, the functionality becomes available. This also brings in the idea of some sort of package (e.g. possibly through TGMG's package manager) which allows the user convenient ways to determine whether it will be a minimal install or which extensions will be available for use. These are all features, since the core sound-playing functionalities are already there, so not being able to play additional sound types (such as OGG, MP3) is a feature request, not a bug.
A bug, on the other hand, would be if a button is available for some ability (like RTF stuff) but does nothing (either because we have not implemented it yet or because it would require a library dependency or heavy code for a small feature). In those cases, use your discretion to determine whether the button should be implemented or whether the button should be removed - keeping in mind whether GM supports it or not and whether that would be a big deal or not.

I am not able to really decide how best to abstract this and was hoping for help from you or Josh because I didn't know whether to make generic completion classes or if each marker should implement its own or what to do.

I think Josh handled the syntaxes. He would probably have the most valuable input. If he can't help you, my suggestion is to just go with whichever seems most logical. A refactor of some of the internals of that system is always an option here, since that particular system was kind of hacked together as a replacement for JEdit, and I found that I frequently had to adjust it to meet my requirements where JEdit had better support for it before.


When you have architectural questions, like these, each architectural person has their own preferred avenues of contact. Since I'm not able to actively monitor the forums, irc, wiki, or tickets (due to a mismatch of my available time and the quantity of information on them), I'm going to say the best way to contact me with architectural questions is to email me (although you're free to reference whatever wiki, forum post, ticket, etc you need to in your email). I usually respond very quickly to emails. I think that's why some tickets may go ignored by me while others get an instant response is because some of them get forwarded to my inbox.

[Goombert]

Right. A few requests do need to have the line drawn. I think a good approach for these dependency-hogging features is the plugin concept.

Right, I was going to propose a major change to that system to you, plugin priority, this way you can force certain plugins to load before other ones. This way EGM could be separated from the ENIGMA plugin into its own, which would make the enigma plugin a lot cleaner, because it and LGM kind of have to play red light green light for a bit when loading, back whenever I caused issues with the plugin so that you could double click EGM's, you remember?

I think Josh handled the syntaxes.

Part of the code as I was working on it is in the code base right now, I have the old update completions menu and the one I was working on side by side where you can see the issue I encountered and I avoided going any further.
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/components/CodeTextArea.java#L367
I don't want to write a switch case there with 50 different cases for every lexer. The only way around it is to write an abstract FunctionCompletion, ResourceCompletion, etc. class, which I didn't know if that is what I should do or if every TokenMarker should implement its own, or what, I just didn't want to mess it up.

[IsmAvatar]

Plugin Priority was an idea I toyed with, but I couldn't think of a way to implement it in an agnostic way. Either LGM already knows about the plugins that it can have, and assigns them priorities, or else plugins choose their own priorities. In the latter case, we depend on plugin developers giving their plugin an "honest" priority, and they need to have some sort of concept of scale - while a high priority plugin like Enigma may be a 1, what is a low priority plugin? 5? 100? 31415? Then there comes the fun job of priority fine-tuning - one plugin chose priority 4, and another one chose 5, and now another plugin wants to come in right in the middle...
Then there's the issue of how to handle priority. Does a higher priority plugin get loaded first or last? If he gets handled first, then all the lower priority plugins can overwrite everything he did. Of course, a possible workaround for this is for plugins to not trample when they do something - so e.g. check if something is already set before going ahead and setting it up themselves.

[Goombert]

Actually IsmAvatar, it would be a lot easier than that. But I would be in favor of the plugin registering itself to LGM to be loaded with whatever priority it wants, then LGM will sort and call there initialize method, then we can also have plugins register into a delayed thread. As for the solution to your problem, that is simple, we just allow the plugins to also register with a list of any other plugins they should come before or after, or actually, we could do this via md5 sums. All of this would really only be needed as the system gained complexity of course.

[IsmAvatar]

Yes, that's what I was thinking as well. Similar to plugin dependency, plugins can identify other plugins to take higher or lower priority over. A pretty elegant solution whenever we get to that point in development.

[Goombert]

Ism, it would make me feel greatly relieved actually to resolve some of the bug reports. Would you be able to help to me work out what changes to make in order to code the shader editor code complete window? It is fine if you can not respond as frequently as I am kind of chilling out waiting for Josh to finish his compiler, but just so long as you can answer a few questions I would be able to resolve that issue, and it would help be a lot less stressed out.

[IsmAvatar]

Ask away, but again, the question you asked before is more of a Josh question, and if he can't answer it, just use your best judgement and/or refactoring it would be a sufficient solution.

[Goombert]

Ok I decided to go it alone and came up with moving the keyword, variable, etc. classes into DefaultKeywords and making them abstract base classes which can be overridden.
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/joshedit/lexers/DefaultKeywords.java

I then implemented the abstract method GetKeywords() to the DefaultTokenMarker which must be overridden by any child classes. This way CodeTextArea can obtain the keywords and not have them statically hardcoded for each language, it is now completely oblivious to what language is in use.
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/joshedit/lexers/DefaultTokenMarker.java#L45
The GML TokenMarker implements it as follows.

Code: (java) [Select]

        @Override
        public Keyword[][] GetKeywords()
                {
                DefaultKeywords.Keyword[][] GML_KEYWORDS = { GMLKeywords.CONSTRUCTS,
                GMLKeywords.FUNCTIONS,GMLKeywords.VARIABLES,GMLKeywords.OPERATORS,GMLKeywords.CONSTANTS };
                return GML_KEYWORDS;
                }

The following commits were used to implement this bug fix. The first commit is where the actual coding occurred.
https://github.com/IsmAvatar/LateralGM/commit/34d41dedc6b8c1f36304a4fc55858234350375b9
The second was just cleanup.
https://github.com/IsmAvatar/LateralGM/commit/85c43ce94a91ea319c7b6c85d1ff7799a445afa7

This resolves the following bug report filed by myself.
https://github.com/IsmAvatar/LateralGM/issues/98

I would simply like you to review these changes and make sure that this was the correct way of resolving it IsmAvatar. There are also important comments in the shader editor source which should not be ignored, such as moving my code to check if the lexer actually changes into the JoshEdit base classes.
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/subframes/ShaderFrame.java#L177