Cmake #25
Cmake #25
Conversation
Fixes compilation with gcc 4.7 array.h: In instantiation of ‘void ArrayStack<T>::push(const T&) [with T = BPBox*]’: array.h:372:32: required from ‘void ObjArrayStack<T>::push(T*) [with T = BPBox]’ boxprint.cc:371:39: required from here array.h:261:7: error: ‘setIndexDoubler’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] array.h:261:7: note: declarations in dependent base ‘GrowArray<BPBox*>’ are not found by unqualified lookup array.h:261:7: note: use ‘this->setIndexDoubler’ instead
Where "modern" is bison 3.* or so.
|
This work has been done a couple times already it would seem :) https://github.com/KubaO/elkhound is cloned from a repo that had cmake transition done in 2019. Tim Wanders did that work, according to the repo messages. It looks like elkhound is used by text adventure game aficionados to parse the adventures. I've done some work on it so that it's self-contained with MSVC - winflex and winbison are included as a part of the build. Not used on Unix of course. Thanks to cmake, the root folder of the repo can be opened with recent versions of Visual Studio. I've also dragged a lot of the code into the next decade. My goal is to keep it building with C++14. There were a couple little bugs here and there I caught - related to 64-bit compatibility and heisenbugs. I dropped all the containers in smbase (yes, all of them) and replaced those with C++ standard library. ASTList is a thin wrapper around std::vector, kept just to avoid having to do mechanical modifications that cause noise in the diffs. This took some work to keep the whole thing working correctly (I hope). The changes consist of small self-contained commits, and my intention was to keep the thing building and passing tests for every commit. There are 230 commits done over the last month's worth of evenings :) I needed a GLR parser nicer to use than Bison, and that's how I found elkhound. The original code used linked lists a lot and that's a performance killer on modern systems - at least with typical allocators. Where I could, I moved from lists of pointers to vectors of ideally values, or pointers if absolutely necessary. There are very few places where std::forward_list and std::list had to be used, and I'm not convinced those will stay that way. I've also included fmt::format, and a free-standing implementation of string_view. The code is being slowly migrated to use those as/when needed. The overall idea is to use movable values to where they help maintain performance while obviating old optimizations. E.g. I've carefully de-optimized the GLR core to make the code readable by the average person (like myself :). The generated code is still excellent due to man-centuries of effort spent on modern compilers :) Long-term, I imagine this should use the excellent mimalloc memory allocator, since it provides very lightweight heaps, with excellent locality based on object size; creating and destroying them often is no problem. |
|
@KubaO Is your work on this available anywhere? |
|
So are you coordinating with Tim? I am curious how many forks of elsa and
oink there are and if any are still mutually compatible/mergeable.
Given that clang now exists, what do you think accounts for the ongoing
interest in elsa and oink?
…-- Daniel
On Fri, Jul 21, 2023, 01:42 Kuba Sunderland-Ober ***@***.***> wrote:
This work has been done a couple times already it would seem :)
https://github.com/KubaO/elkhound is cloned from a repo that had cmake
transition done in 2019. Tim Wanders did that work, according to the repo
messages. It looks like elkhound is used by text adventure game aficionados
to parse the adventures.
I've done some work on it so that it's self-contained with MSVC - winflex
and winbison are included as a part of the build. Not used on Unix of
course. Thanks to cmake, the root folder of the repo can be opened with
recent versions of Visual Studio.
I've also dragged a lot of the code into the next decade. My goal is to
keep it building with C++14.
There were a couple little bugs here and there I caught - related to
64-bit compatibility and heisenbugs.
I dropped all the containers in smbase (yes, all of them) and replaced
those with C++ standard library. ASTList is a thin wrapper around
std::vector, kept just to avoid having to do mechanical modifications that
cause noise in the diffs.
This took some work to keep the whole thing working correctly (I hope).
The changes consist of small self-contained commits, and my intention was
to keep the thing building and passing tests for every commit. There are
230 commits done over the last month's worth of evenings :) I needed a GLR
parser nicer to use than Bison, and that's how I found elkhound.
The original code used linked lists *a lot* and that's a performance
killer on modern systems - at least with typical allocators. Where I could,
I moved from lists of pointers to vectors of ideally values, or pointers if
absolutely necessary. There are very few places where std::forward_list and
std::list had to be used, and I'm not convinced those will stay that way.
I've also included fmt::format, and a free-standing implementation of
string_view. The code is being slowly migrated to use those as/when needed.
The overall idea is to use movable values to where they help maintain
performance while obviating old optimizations. E.g. I've carefully
de-optimized the GLR core to make the code readable by the average person
(like myself :). The generated code is still excellent due to man-centuries
of effort spent on modern compilers :)
Long-term, I imagine this should use the excellent mimalloc memory
allocator, since it provides very lightweight heaps, with excellent
locality based on object size; creating and destroying them often is no
problem.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAL6XHZLS6U35DR4SDVV3LXRIJDTANCNFSM6AAAAAASHFHJIM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I am not coordinating with anyone at this moment... my interest is in supporting static analysis in a GitHub Action outside clang-tidy and cppcheck because I believe it's worthwhile to run as many static analysis tools as possible on code to make sure it's free of defects, and reading about and researching oink strongly piqued my interest. I'm in the process of integrating Facebook's Infer and another tool called Flawfinder. |
6 participants
I've integrated a few PR's, as well as started on a CMake build system, which can successfully build astgen, elkhound, and elsa/ccparse.