Add remote branch tracking to `status`

Problem

The status program will check local repos and their status, if they're up-to-date, if there are some scattered files in the worktree, if there are any branches that might have code I'm working on, etc.

To keep the entire git universe clean, It would be nice if status could also check the existence of branches on origin.

Solution (Partial)

Remote branches can be detected with

git branch -r

Note that any branches that have been deleted on remote will still remain on your system. You can "prune" them with:

git remote prune origin

If you want to just see which branches will be pruned, you can add the --dry-run flag:

git remote prune origin --dry-run

Some dependency symbols use wildcard characters

It's been a bit of a convention to use wildcard characters in some cases for dependencies. For example, Foo::Bar::* would represent that some constants in Foo::Bar:: are used, and it's easier to notate it like this rather than list out each one.

However, now that * characters are removed during dependency atomization, that character disappears and Foo::Bar:: is listed as the atomic dependency. This leads to a parse error in YAML where it thinks it's a name of a property (like name: or something).

For now, no longer using * in the dependency name, and enclosing the dependency in quotes in yaml: 'Foo::Bar::'.

For example:

dependencies:

  - symbol: 'Foo::Bar::'
    headers: [ Foo/Bar.hpp ]

It seems there could be a simpler solution, though.

Remove excess "protected:" section and/or "private:" section

A recent update caused each class header to include a protected: section even if it's empty. These should be removed unless there are protected: elements present.

Functions sin and cos are not recognized in Win

Primary development system is MacOS with clang. When using cos and sin they work as expected and there are no warnings or errors. On Windows with gcc, there are compile errors for missing symbols. At the time of this writing, there are no known ways to catch this error, other than building on Windows. There should be some kind of solution to catch the errors before Windows.

Some ideas:

Install gcc on Mac and build there
Provide a seamless CI that will always build on Windows and report the error.
See if there is a way to parse the code manually and detect cos or sin symbols in the codebase, and then check to be sure the appropriate header <cmath> is included.

"unsigned int" and other "unsigned" variables are not parsed as dependencies

Solution still yet to be worked out.

Needed updates to generated project template

Seek out instances of buggy "int < size_t" in for loops

Problem

A recent fix to this issue exposed a design flaw in for loops, with int indexes, comparing against a_vector.size() values. Normally this could be fine, but in circumstances where an a_vector element is erased and i-- is decremented on the 0 index value, now we got an issue.

Solution

Comb through the code, locate for loops with this code flaw, and clean them up. You could find them with something like:

$ git grep for | grep "int " | grep size

An example where I did something similar:

XCode 15, rpath change resulted in modification to Makefile

Problem

Since updating to XCode command line tools 15.0, a change in the linker behavior required a patch to this project's Makefile.

For context, executable binaries have compiled within them the folder locations(s) to use when searching for dylibs at runtime. These locations can be seen with either otool -l path/to/binary or otool -L path/to/binary after compilation, and show listings for each dylib in the executble. Some listings may be prefixed with @rpath (as in @rpath/path/to/dylib.dylib), representing a dynamic location. (This is related to LC_RPATH (the "load command" that sets the rpath at runtime) which was included in the error message presented at runtime.)

Since XCode 15, the system (somewhere in the udpated tools) will no longer use /usr/local/lib as a fallback or default location when searching for dylib files (it appears to be a security concern). It's unclear if this change is categorized as an unintended bug (I read the linker was completely rewritten to be faster), or a policy change.

Several possible changes are considered to fix this issue.

Option 1: Set a rpath during compilation

This can be done by including the flag -rpath '/usr/local/lib' during invocation of clang/g++ (e.g. something like g++ main.o -I./include -L./libs -rpath '/usr/local/lib'). The order or placement of -rpath flag does not appear to matter.

Option 2: Set a rpath after compilation

This can be done with $> install_name_tool -add_rpath /usr/local/lib path/to/binary

Solution

For blast/Makefile, I've decided to explicitly set the rpath when building in MacOS to /ur/local/lib. For my build environment, this is where all the libs are located (liballegro_font.dylib, et all). Note that Mac's -framework dylibs are already available by being included in a protected cache on the mac, so they are automatically found at runtime (unless explicitly declared to be found elsewhere).

According to "The Eskimo!" from Apple, going forward, all compiled binaries should prefer to have known locations for the dylibs they are relying on, and should not rely on implicit locations for security reasons (source).

Some links

Apple Developer thread discussing the issue: https://developer.apple.com/forums/thread/737920
Backstory and history related to this behavior change: https://developer.apple.com/forums/thread/655588?answerId=665804022#665804022
Understanding @rpath (and other similar variables) in the as shown with otool: https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath
This issue in godot from 2 weeks ago, fixing the macos project not building: godotengine/godot#83085
This useful article on using otool, install_name_tool, etc for setting/reading/etc library info: https://www.ill.eu/about-the-ill/contacts/public-relations/afilhol/macos-development/useful-commands

Introduce validators into quintessence

in quintessence:

 validate:
  - class: VectorValidator<std::string>
    init_with: '{ "who", "ha" }'
    validate_with:
      - contains("who")
      - min_token_count(2)
      - tokens_not_empty()

would produce:

{
   VectorValidator<std::string> validator({ "who", "ha" });
   std::vector<std::string> all_validator_errors;

   std::vector<std::string> validation_1 = validator.contains("who");
   all_validator_errors(all_validator_errors.end(), validation_1.begin(), validation_1.end());

   std::vector<std::string> validation_2 = validator.min_token_count(2);
   all_validator_errors(all_validator_errors.end(), validation_2.begin(), validation_2.end());

   std::vector<std::string> validation_3 = validator.tokens_not_empty();
   all_validator_errors(all_validator_errors.end(), validation_3.begin(), validation_3.end());

   if (!all_validator_errors.empty())
   {
      std::stringstream error_message;
      error_message << "ClassName::method: error: Following validations failed: ";
      ... list out all_validator_errors ...
      throw std::runtime_error(error_message);
   }
}

Add warning for excess dependencies in YAML

Improve methods with references as arguments in quintessence

As a design strategy, all function arguments have default values. Because of that, adding references gets a little clumsy. Generally, it's advised to avoid references in this way, however there are a couple workarounds:

Create a static dummy variable in the class and use it as the argument.
Use a pointer instead of a reference, and guard the presence of the pointer.

This topic could use a little more attention, for example quintessence could be modified to explicitly declare an argument without a default value. As is, the workarounds don't feel like the elegant final factoring of this feature.

Flakey test in BuildSystem/Builds/Base

Account for changes in FiLEnAmECasINg in when renaming files

Problem

Problem recently occurred when attempting to build on Windows, a file Elements/Scrollbar.q.yml that had been renamed from Elements/ScrollBar.q.yml (notice the casing) happened on allegroflare/allegro_flare@5f0d67d. On MacOS it continued to work without an issue, however Windows was unable to pickup the change until a commit was forced to change the name via git mv -f. See this article here on forcing renaming of casing.

Unfortunately, this error only becomes visible by the time it makes it to Windows building.

Solution

This contingency should be included in blast's rename_component program.

On first build; AllegroFlare expects the production library for tests

==== Stage 6: Make all the individual test executables =========================================================================================================================================================

Compiling test object for TestRunner obj/tests/TestRunner.o
Object for TestRunner at obj/tests/TestRunner.o compiled successfully.
Compiling standalone test executable at bin/tests/AllegroFlare/AchievementsTest
Compiling standalone test executable at bin/tests/AllegroFlare/AchievementTest
Compiling standalone test executable at bin/tests/AllegroFlare/AllegroContributorsListTest
Compiling standalone test executable at bin/tests/AllegroFlare/AI/PromptTemplateTest
Compiling standalone test executable at bin/tests/AllegroFlare/AllegroColorAttributeDatatypeTest
Compiling standalone test executable at bin/tests/AllegroFlare/AI/PromptTemplateYAMLLoaderTest
Compiling standalone test executable at bin/tests/AllegroFlare/AllegroUnstableTest
Compiling standalone test executable at bin/tests/AllegroFlare/ALLEGRO_VERTEX_WITH_NORMALTest
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lallegro_flare-0.8.11wip: No such file or directory
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lallegro_flare-0.8.11wip: No such file or directory
C:/msys64/mingw6C4/b:i/n/msy.s.6/4/lminigbw/6g4c/cb/ixn8/6._.6/4l-iwb6/4g-cmci/nxg8w63_26/41-3w.624.0-/m.i.n/g..w3/2././1.3..2/x.086/_.6.4/-.w6.4/.-./m.in.g/wx3826/b_i6n4/-lwd6.4ex-meing:w32 /cbian/nlndo.te x
feind:  -canlnaoltl efgirnod_ fla-re-l0a.l8.l1e1gwrioCp_f:l:/amr sey-Ns06.o4/ 8ms.iu1nc1ghww i6fp4i/l:bei  no/rN. .do/i lrsieubcc/thgo crfcyi/lx
 6o_r6 4d-Ciwr6:e4/c-mtmsoiyrnsyg6w4
2m/i1n3g.w26.40//b.i.n//....//.l.i/b./.g/cxc8/6x_8664_-6w46-4w-6m4i-nmgiwn3g2w/3b2i/n1/3l.d2..e0x/e../:../ .c.a/n.n.o/tx 8f6i_n6d4 -w6-4-mlianlglwe3g2r/ob_ifnl/alrde.-e0x.e8.11w:ip c:ann ot Nfinod  suc-h flia
llel eorg rdoi_rfelcatroer-y0.8
11wip: No such file or directory
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lallegro_flare-0.8.11wip: No such file or directoryC
/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lallegro_flare-0.8.11wip: No such file or directory
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AllegroContributorsListTest] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AI/PromptTemplateYAMLLoaderTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AI/PromptTemplateTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AchievementTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AllegroUnstableTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AchievementsTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/AllegroColorAttributeDatatypeTest] Error 1
make[1]: *** [Makefile:740: bin/tests/AllegroFlare/ALLEGRO_VERTEX_WITH_NORMALTest] Error 1
make: *** [Makefile:339: main] Error 2

Handfull of tests are failing on Windows

At the time of this writing, 20 failed tests on Windows, mostly related to symlinks, some missing fixture files, different system names, etc.

`generate_source_release` copies any uncommitted files

Before the releaser should copy files, it should check for any extra files in the working tree. This also goes for allegro_flare as well.

Add "after_initialized" and "before_initialized" options for getter and setter

getter: after_initialized

requires a property "initialized" on the class
auto-creates the getter the same as getter: true, but with a guard [ initialized ]

setter: before_initialized

requires a property "initialized" on the class
auto-creates the setter the same as setter: true, but with a guard [ (!initialized) ]

Quintessence Tutorial Needs to be Updated to YAML

The current walkthrough in https://github.com/MarkOates/blast/blob/master/documentation/quintessence.md contains an outdated description of the depreciated JSON format of quintessence. It's possible, but not expected, to support a JSON format in the future. But, at this time it's encouraged that users use the YAML format, because it's much easier to write and parse visually.

Remove duplicate #include headers

Makefile uses production .a file in tests

Problem

During build, a library is built that is intended for tests (e.g. lib/liballegro_flare-0.8.11wip-for_tests.a). This is different from the normal library, which will not be built until the tests have passed. At least that's the intention.

I suspect the production library is used in tests, and this should be fixed. I believe the reason it hasn't is because there is some discrepancy in the order-of-needed-things specifically in the allegro_flare project, the blast project, since they are the lowest level things that build the other projects. For example, building tests in allegro_flare should use the lib/liballegro_flare-0.8.11wip-for_tests.a library, while building tests for other projects should use the production allegro_flare library lib/liballegro_flare-0.8.11wip.a.

It can be helpful to remove the @ on build lines (e.g. @g++ ...) to see the output.

I also believe this went largely unnoticed because the obj files were linked as well as the library, causing the object files to override the library. This duplication should be fixed, too.

This could also explain the noisy warnings when running the debug console (and when running certain other stages of build related to debugging symbols).

Quintessence improvements

Following features should be considered for improvement to the quintessence files:

Remove "explicit_setter:" attribute in yaml

explicit_setter: true is depreciated for setter: explicit. Same goes for getter.

explicit_setter and explicit_getter should be removed as options.

status program missing features

status does not check if some compiled items are up to date after a pull/sync with remote. Compiled library, executables, example programs, tests, etc, may still be behind.

system_test has a feature that checks if some executables have a created_at that is after their source files. This technique could be used (or something similar) in status to be sure it is up-to-date.

Consider "type branch" function template

  - name: type_branch
    template:
      - type: type_branch
        cases:
         - type: AllegroFlare::DialogSystem::CharacterStagingLayouts::BasicCentered
           body: |
             ALLEGRO_BITMAP *speaking_character_bitmap = lookup_speaking_character_avatar(speaking_character_identifier);
             if (!speaking_character_bitmap) as->clear_speaking_character_bitmap();
             else as->set_speaking_character_bitmap(speaking_character_bitmap);
         - type: AllegroFlare::DialogSystem::CharacterStagingLayouts::BasicCentered
           body: |
             ALLEGRO_BITMAP *speaking_character_bitmap = lookup_speaking_character_avatar(speaking_character_identifier);
             if (!speaking_character_bitmap) as->clear_speaking_character_bitmap();
             else as->set_speaking_character_bitmap(speaking_character_bitmap);

Use response files when building on Win

When compiling on gcc in win, a make[1]: g++: Argument list too long error appears on some projects, namely allegro_flare.

At the time of this writing, it seems that there is limited support for response files on mac, and splitting the build logic between Win and Mac in the Makefile would cause a lot of convoluted branching logic. Both of these need to be investigated further.

Note these changes should appear on a generated project's Makefile and the Makefile assembled in programs/build_source_release.

CharacterInput.hpp
ElementBase.hpp
Frame.hpp
HeaderBar.hpp
Menu.hpp
ProgressBar.hpp
Rectangle.hpp
Scene.hpp
Table.hpp
TabSet.hpp
Text.hpp
TextInput.hpp
WcharText.hpp

The following ncurses functions (and flags) appear to be used during (various stages) of rendering:

attron
mvaddnwstr
attroff
styles flags:
  A_BLINK
  A_BOLD
  A_UNDERLINE
  A_REVERSE
COLOR_PAIR?
mvaddch
mvaddstr
SCS_ULCORNER
ACS_URCORNER
ACS_HLINE
ACH_VLINE
ACS_BTEE
ACS_URCORNER
ACS_LLCORNER
ACS_ULCORNER
ACS_LRCORNER
ACS_VLINE
ACS_HLINE
mvaddch
attroff
A_REVERSE
attron
attroff
mvaddnstr
mvprintw
attroff
A_REVERSE
COLS
COLORS
LINES
chgat
mvprintw

Add "default_argument_dependency_symbols"

Problem

Sometimes dependencies are needed for default arguments, but they are not able to be listed anywhere.

Solution

In quintessence, add a default_argument_dependency_symbols to functions > parameters.

https://github.com/biojppm/rapidyaml - MIT License, single-header

markoates / blast Goto Github PK

blast's People

Contributors

Watchers

blast's Issues

Problem

Solution (Partial)

Problem

Solution

Problem

Option 1: Set a rpath during compilation

Option 2: Set a rpath after compilation

Other solutions proposed

Solution

Some links

Problem

Solution

Problem

Problem

Solution

Recommend Projects

Recommend Topics

Recommend Org