aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/expressions.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-05-30THE GREAT CEEIFICATION EVENTRobin Haberkorn1-277/+0
This is a total conversion of SciTECO to plain C (GNU C11). The chance was taken to improve a lot of internal datastructures, fix fundamental bugs and lay the foundations of future features. The GTK user interface is now in an useable state! All changes have been squashed together. The language itself has almost not changed at all, except for: * Detection of string terminators (usually Escape) now takes the string building characters into account. A string is only terminated outside of string building characters. In other words, you can now for instance write I^EQ[Hello$world]$ This removes one of the last bits of shellisms which is out of place in SciTECO where no tokenization/lexing is performed. Consequently, the current termination character can also be escaped using ^Q/^R. This is used by auto completions to make sure that strings are inserted verbatim and without unwanted sideeffects. * All strings can now safely contain null-characters (see also: 8-bit cleanliness). The null-character itself (^@) is not (yet) a valid SciTECO command, though. An incomplete list of changes: * We got rid of the BSD headers for RB trees and lists/queues. The problem with them was that they used a form of metaprogramming only to gain a bit of type safety. It also resulted in less readble code. This was a C++ desease. The new code avoids metaprogramming only to gain type safety. The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle (https://github.com/jstimpfle/rb3ptr). This implementation is also more memory efficient than BSD's. The BSD list.h and queue.h has been replaced with a custom src/list.h. * Fixed crashes, performance issues and compatibility issues with the Gtk 3 User Interface. It is now more or less ready for general use. The GDK lock is no longer used to avoid using deprecated functions. On the downside, the new implementation (driving the Gtk event loop stepwise) is even slower than the old one. A few glitches remain (see TODO), but it is hoped that they will be resolved by the Scintilla update which will be performed soon. * A lot of program units have been split up, so they are shorter and easier to maintain: core-commands.c, qreg-commands.c, goto-commands.c, file-utils.h. * Parser states are simply structs of callbacks now. They still use a kind of polymorphy using a preprocessor trick. TECO_DEFINE_STATE() takes an initializer list that will be merged with the default list of field initializers. To "subclass" states, you can simply define new macros that add initializers to existing macros. * Parsers no longer have a "transitions" table but the input_cb() may use switch-case statements. There are also teco_machine_main_transition_t now which can be used to implement simple transitions. Additionally, you can specify functions to execute during transitions. This largely avoids long switch-case-statements. * Parsers are embeddable/reusable now, at least in parse-only mode. This does not currently bring any advantages but may later be used to write a Scintilla lexer for TECO syntax highlighting. Once parsers are fully embeddable, it will also be possible to run TECO macros in a kind of coroutine which would allow them to process string arguments in real time. * undo.[ch] still uses metaprogramming extensively but via the C preprocessor of course. On the downside, most undo token generators must be initiated explicitly (theoretically we could have used embedded functions / trampolines to instantiate automatically but this has turned out to be dangereous). There is a TECO_DEFINE_UNDO_CALL() to generate closures for arbitrary functions now (ie. to call an arbitrary function at undo-time). This simplified a lot of code and is much shorter than manually pushing undo tokens in many cases. * Instead of the ridiculous C++ Curiously Recurring Template Pattern to achieve static polymorphy for user interface implementations, we now simply declare all functions to implement in interface.h and link in the implementations. This is possible since we no longer hace to define interface subclasses (all state is static variables in the interface's *.c files). * Headers are now significantly shorter than in C++ since we can often hide more of our "class" implementations. * Memory counting is based on dlmalloc for most platforms now. Unfortunately, there is no malloc implementation that provides an efficient constant-time memory counter that is guaranteed to decrease when freeing memory. But since we use a defined malloc implementation now, malloc_usable_size() can be used safely for tracking memory use. malloc() replacement is very tricky on Windows, so we use a poll thread on Windows. This can also be enabled on other supported platforms using --disable-malloc-replacement. All in all, I'm still not pleased with the state of memory limiting. It is a mess. * Error handling uses GError now. This has the advantage that the GError codes can be reused once we support error catching in the SciTECO language. * Added a few more test suite cases. * Haiku is no longer supported as builds are instable and I did not manage to debug them - quite possibly Haiku bugs were responsible. * Glib v2.44 or later are now required. The GTK UI requires Gtk+ v3.12 or later now. The GtkFlowBox fallback and sciteco-wrapper workaround are no longer required. * We now extensively use the GCC/Clang-specific g_auto feature (automatic deallocations when leaving the current code block). * Updated copyright to 2021. SciTECO has been in continuous development, even though there have been no commits since 2018. * Since these changes are so significant, the target release has been set to v2.0. It is planned that beginning with v3.0, the language will be kept stable.
2017-03-23fixed checks for missing left and right operands to binary operatorsRobin Haberkorn1-2/+2
* this resulted in assertions (crashes!) for harmless typos like "+23=" * a test case has been added
2017-03-03updated copyright to 2017Robin Haberkorn1-1/+1
2016-02-15revised looping implementation, aggregating loops, sane $$ semantics, some ↵Robin Haberkorn1-19/+27
optimizationa and additional checks * undo tokens emitted by the expression stack no longer waste memory by pointing to the stack implementation. This uses some ugly C++ constant template arguments but saves 4 or 8 byte per undo token depending on the architecture. * Round braces are counted now and the return command $$ will use this information to discard all non-relevant brace levels. * It is an error to close a brace when none have been opened. * The bracing rules are still very liberal, allowing you to close braces in macros belonging to a higher call frame or leave them open at the end of a macro. While this is technically possible, it is perhaps a good idea to stricten these rules in some future release. * Loops no longer (ab)use the expression stack to store program counters and loop counters. This removes flow control from the responsibility of the expression stack which is much safer now since we can control where we jump to. This also eased implemented proper semantics for $$. * It is an error to leave loops open at the end of a macro or trying to close a loop opened in the caller of the macro. Similarily it is only possible to close a loop from the current invocation frame. This means it is now impossible to accidentally jump to invalid PCs. * Even though loop context stacks could be attached directly to the macro invocation frame, this would be inefficient. Instead there's a loop frame pointer now that is part of the invocation frame. All frames will reuse the same stack structure. * Loops are automatically discarded when returning using $$. * Special aggregating forms of the loop start (":<") and loop end (":>") commands are possible now and have been implemented. This improves SciTECO's capability as a stack-oriented language. It is no longer necessary to write recursive macros to generate stack values of arbitrary length dynamically or to process them. * All expression and loop stacks are still fixed-size. It may be a good idea to implement dynamic resizing (TODO). * Added some G_UNLIKELYs to Execute::macro(). Should improve the branch prediction of modern CPUs. * Local Q-Register tables are allocated on the stack now instead of on the heap (the bulk of a table is stored on the heap anyway). Should improve performance of macro invocations. * Document that "F<" will jump to the beginning of the macro if there is no loop. This is not in standard TECO, but I consider it a useful feature.
2016-01-28updated copyright to 2016Robin Haberkorn1-1/+1
2015-09-24cleaned up operator precedence codeRobin Haberkorn1-1/+1
* use small values for low precedence
2015-09-23different operators can have the same precedence nowRobin Haberkorn1-1/+2
* SciTECO now has the same operator precedence table as C. * It is numerically important whether different operators have the same precedence. E.g. "5*2/4" used to be evaluated by SciTECO as "5*(2/4)" since division had a higher precedence than multiplication. Within in real (!) numbers this would be the expected evaluation order. Users of other programming languages however would expect the expression to be evaluated as "(5*2)/4" which makes a numerical difference when working with integers. * Operator precedence has been implemented by encoding it into the enumeration values used to represent different operators. Calculating the precedence of a given operator can then be done very efficiently and elegantly (in our case using a plain right shift operation). * documentation updated. We use a precedence table now.
2015-03-17fixed invalid memory accesses in the expression stack and reworked ↵Robin Haberkorn1-36/+24
expression stack this was probably a regression from d94b18819ad4ee3237c46ad43a962d0121f0c3fe and should not be in v0.5. The return value of Expressions::find_op() must always be checked since it might not find the operator, returning 0 (it used to be 0). A zero index pointed to uninitialized memory - in the worst case it pointed to invalid memory resulting in segfaults. Too large indices were also not handled. This was probably responsible for recent PPA build issues. Valgrind/memcheck reports this error but I misread it as a bogus warning. I took the opportunity to clean up the ValueStack implementation and made it more robust by adding a few assertions. ValueStacks now grow from large to small addresses (like stack data structures usually do). This means, there is no need to work with negative indices into the stack pointer. To reduce the potential for invalid stack accesses, stack indices are now unsigned and have origin 0. Previously, all indices < 1 were faulty but weren't checked. Also, I added some minor optimizations.
2015-03-02use g_assert_not_reached() instead of g_assert(false): works around Clang++ ↵Robin Haberkorn1-1/+1
warnings * Clang++ does not see that the PC will never go beyong g_assert(false), and so reports about possible unitialized variables
2015-02-11updated copyright to 2015Robin Haberkorn1-1/+1
2014-11-14added ^# (XOR) operatorRobin Haberkorn1-0/+3
also changed precedence of + operator (higher than minus). the effects of this should be minimal
2014-11-14fixed number formatting for radix > 10Robin Haberkorn1-1/+1
this fixes the "\" command and ^E\ string building characters
2014-11-11refactored SciTECO runtime errors: moved from parser.cpp to error.cppRobin Haberkorn1-5/+5
* the GError expection has been renamed to GlibError, to avoid nameclashes when working from the SciTECO namespace
2014-11-11added all of SciTECO's declarations to the "SciTECO" namespaceRobin Haberkorn1-0/+4
normally, since SciTECO is not a library, this is not strictly necessary since every library should use proper name prefixes or namespaces for all global declarations to avoid name clashes. However * you cannot always rely on that * Scintilla does violate the practice of using prefixes or namespaces. The public APIs are OK, but it does define global functions/methods, e.g. for "Document" that clashed with SciTECO's "TECODocument" class at link-time. Scintilla can put its definitions in a namespace, but this feature cannot be easily enabled without patching Scintilla. * a "SciTECO" namespace will be necessary if "SciTECO" is ever to be turned into a library. Even if this library will have only a C-linkage API, it must ensure it doesn't clutter the global namespace. So the old "TECODocument" class was renamed back to "Document" (SciTECO::Document).
2014-11-09prevent assertions when pushing operators without corresponding operandsRobin Haberkorn1-4/+14
instead throw an error. The error could theoretically be thrown earlier instead of only when trying to perform a calculation. test cases: "++", "+1+", etc.
2014-08-02ensure that expressions.eval(true) pops the brace "operator"Robin Haberkorn1-3/+2
test case: 1<()> * an empty brace (or content that does not leave anything on the stack) resulted in the brace op to be left on the stack which makes the op stack inconsistent
2014-02-15updated Copyright to year 2014Robin Haberkorn1-1/+1
2014-02-15catch division by zero errorsRobin Haberkorn1-8/+29
* C++ runtime does not automatically throw an exception
2013-03-17^E\ string building character to format numberRobin Haberkorn1-0/+21
* new Expressions::format() * may be used format numbers as part of arrays (Q-Register names)
2013-02-22use typedef for SciTECO integers and make it configurable at configure timeRobin Haberkorn1-11/+11
* storage size should always be 64 (gint64) to aid macro portability * however, for performance reasons users compiling from source might explicitly compile with 32 bit integers
2013-01-19updated copyright (2012-2013)Robin Haberkorn1-1/+1
2012-12-04added copyright notice to every source fileRobin Haberkorn1-0/+17
2012-12-04first working version of autotools based build-systemRobin Haberkorn1-0/+4
2012-12-04autoconf preparation: move everything into src/ subdirRobin Haberkorn1-0/+201