| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* use small values for low precedence
|
|
* 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.
|
|
* necessary since in SciTECO every operator has a different
precedence. E.g. successive additions/subtractions cannot
be evaluated from left to right (by their associativity).
Perhaps this should be changed.
* subtraction must have a higher precedence than addition,
since (a+b)-c == a+(b-c)
* division must have a higher precedence than multiplication
since (a*b)/c == a*(b/c).
This is not quite true for integer arithmetics.
* this fixes expressions like 5-1+1 which were counterintuitively
evaluated like 5-(1+1)
|
|
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.
|
|
|
|
* acts as a safe-guard against uninterrupted infinite loops
or other operations that are costly to undo in interactive mode.
If we're out of memory, it is usually too late to react properly.
This implementation tries to avoid OOMs due to SciTECO behaviour.
We cannot fully exclude the chance of an OOM error.
* The undo stack size is only approximated using the
UndoToken::get_size() method.
Other ways to measure the exact amount of allocated heap
(including size fields in every heap object or using sbrk(0) and
similar) are either costly in terms of memory or platform-specific.
This implementation does not need any additional memory per heap
object or undo token but exploits the fact that undo tokens
are virtual already. The size of an undo token is determined
at compile time.
* Default memory limit of 500mb should be OK for most people.
* The current limit can be queried with "2EJ" and set with <x>,2EJ.
This also works interactively (a bit tricky!)
* Limiting can be disabled. In this case, undo token processing
is a bit faster.
* closes #3
|
|
|
|
also changed precedence of + operator (higher than minus).
the effects of this should be minimal
|
|
* the GError expection has been renamed to GlibError, to avoid
nameclashes when working from the SciTECO namespace
|
|
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).
|
|
|
|
* ValueStack destruction might have resulted in Segfaults at shutdown
|
|
* new Expressions::format()
* may be used format numbers as part of arrays (Q-Register names)
|
|
* 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
|
|
|
|
|
|
|
