Pages: 1
  Print  
Author Topic: Changes in the new compiler  (Read 2215 times)
Offline (Male) Josh @ Dreamland
Posted on: February 24, 2014, 08:36:47 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
I never make changelogs; this is a personal mistake I'll attempt to work on. I am using this thread to document notes for developers and changes to the new compiler framework. I will place these changes in the Wiki after the fact. Excuse the Wiki list notation in the meantime; there's no sense in my formatting it with SMF's syntax if it's just going to be * in the end.

Notes:
* Files in the CompilerSource/JDI folder are meant to be read-only. This is a verbatim copy of the JDI repository; please make any changes there. We might end up renaming this to JDI-read-only to comply with the precedent set by other projects.

Changes:
* EnigmaStruct is no longer the main argument to compiler functions; it has been wrapped in a new class, compile_context.
** This class also contains the global object parsed_object *EGMglobal; the other parameter to most compile routines.
** This class also contains FILE *gameModule, the other parameter passed to most resource writing routines.
* There is now a separate resource_writer class to handle—you guessed it—writing resources. This is not only so we can support multiple languages, but also so we can support multiple resource export schemes (eg, internal, external). This is generated by the compile() method of the corresponding language adapter.
* Compile functions are now all snake_case, not some_SnakeCamel_Bastardization

Changing:
* The way JDI interfaces lexers and contexts needs changed—these are independent concepts.
« Last Edit: March 03, 2014, 05:55:57 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) time-killer-games
Reply #1 Posted on: February 24, 2014, 09:47:51 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
This is great news! I can't thank you enough Josh! I'm very excited for this update.
« Last Edit: February 24, 2014, 10:40:29 PM by time-killer-games » Logged
Offline (Male) Rusky
Reply #2 Posted on: March 30, 2014, 09:08:03 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
You could use a git submodule to more forcefully show the read-only nature of the JDI directory, as well as not including the history of JDI in ENIGMA's repository, and allowing you to specify a precise commit in the upstream JDI repo that ENIGMA depends on, which can also be versioned.
Logged
Offline (Male) Josh @ Dreamland
Reply #3 Posted on: April 03, 2014, 09:30:59 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
Last I investigated Git submodules, they sucked. I'll give them another look, because we could desperately use that functionality. The ability to have users check out one repository URL to receive code from both is a must.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Rusky
Reply #4 Posted on: April 03, 2014, 10:40:13 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
The pain point of submodules is that after cloning [or updating] you have to run this:
Code: [Select]
git submodule update [--init]You at least don't need to specify the second repo url.
An alternative that avoids this problem at the expense of some different complications is git subtree.
Logged
Offline (Male) Josh @ Dreamland
Reply #5 Posted on: April 04, 2014, 11:23:10 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
Bleh. As long as it gets *all* the submodules with that one call, that's fine. There's just no room for expansion otherwise.

Here's my secondary concern: When I go to GitHub and press "Download zip," what do I find in the submodule/subtree folders?
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Rusky
Reply #6 Posted on: April 04, 2014, 12:54:41 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Sadly, it does not include the subfolder contents. However, people who want to develop ENIGMA will need Git anyway, and it should be pretty simple to create a "make dist" target that includes all the source that you could upload to GitHub as a release (when you get around to tagging releases).
Logged
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: April 04, 2014, 04:13:05 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
I was hoping to use GitHub to generate a basic zip file for release building. I want to eventually automate package generation on this server or another. I can, of course, have git check out all that stuff locally, then zip it manually, but then I have to delete the .git directories. Please tell me there's only one of those.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Rusky
Reply #8 Posted on: April 04, 2014, 04:39:50 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
There is just one .git directory; submodules have a .git file with "gitdir: ../.git/modules/<name>" or whatever in them. There's also .gitignore, .gitmodules, etc. that you may want to ignore as well (and that a GitHub zip would still have).
Logged
Pages: 1
  Print