| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
should slightly reduce binary size
|
|
* turns out that glib's g_assert() does not depend on NDEBUG like Standard C's assert()
* this disables assertions in release builds and should speed up things slightly
|
|
* Some platforms like Ubuntu actually ship widechar and non-widechar versions
of ncurses with different pkg-config files.
Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file
but both point to the same wide-char library anyway.
* Currently we are not using wide-char APIs to ensure maximum compatibility even with
embedded systems where ncurses might be built without widechar support.
But in order to handle Unicode correctly, we still need to link against the widechar version
of ncurses (if available).
* Compilation on platforms without a widechar ncurses is now handled by the common
AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just
didn't install the pkg-config file).
If necessary, we could also check for the "ncurses" package if "ncursesw" is not found.
* This fixes Unicode display and input on Ubuntu.
|
|
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla
manually to the build directory.
* It turns out, that Scintilla/Lexilla was supporting this since 2016.
Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O).
* For Scinterm I opened a pull request in order to add srcdir/basedir variables:
https://github.com/orbitalquark/scinterm/pull/21
* `make distcheck` is therefore now also fixed.
* The FreeBSD package is now allowed to build out of source.
I haven't tested it yet.
* See also https://github.com/ScintillaOrg/lexilla/issues/266
|
|
* probably not necessary for std::thread support in Scintilla
* should fix MinGW nightly builds
|
|
|
|
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
files between Curses and Gtk builds into a "sciteco-common" package.
As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
--with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
|
|
default now
* On FreeBSD both the dlmalloc replacement and poll-thread via sysctl() work
but the poll-thread has been benchmarked to be significantly faster,
at least on my machine.
You can still ./configure --enable-malloc-replacement of course.
* Interestingly, the RSS of the process visible via htop does not decrease
after OOMs or command-line terminations - with neither of the implementations.
|
|
* teco_interrupt() turned out to be unsuitable to kill child processes (eg. when <EB> hangs).
Instead, we have Win32-specific code now.
* Since SIGINT can be ignored on UNIX, pressing CTRL+C was not guaranteed to kill the
child process (eg. when <EB> hangs).
At the same time, it makes sense to send SIGINT first, so programs can terminate gracefully.
The behaviour has therefore been adapted: Interrupting with CTRL+C the first time will kill
gracefully. The second time, a more agressive signal is sent to kill the child process.
Unfortunately, this would be relatively tricky and complicated to do on Windows, so CTRL+C will always
"hard-kill" the child process.
* Moreover, teco_interrupt() killed the entire process on Windows when called the second time.
This resulted in any interruption to terminate SciTECO unexpectedly when tried the second time on Gtk/Win32.
* teco_sigint_occurred renamed to teco_interrupted:
There may be several different sources for setting this flag.
* Checking for CTRL+C on Gtk involves driving the main event loop repeatedly.
This is a very expensive operation. We now do that only every 100ms. This is still sufficient since
keyboard input comes from humans.
This optimization saves 75% runtime on Windows and 90% on Linux.
* The same optimization turned out to be contraproductive on PDCurses/WinGUI.
|
|
* actually everything is updated to their current HEADs but the aforementioned versions are close.
* Scintilla uses threads now, so we added checks for pthread.
To be on the safe side, we imported AX_PTHREAD from the Autoconf archives.
The flags are kept out of the ordinary build system, though and used only for compiling Scintilla
and for linking.
SciTECO may also use threads, but via Glib.
* Scinterm removed SCI_COLOR_PAIR(), so we re-added it to src/interface-curses/interface.c.
* There is an Asciidoc lexer now.
* The <Ix$> interruption bug (see TODO) is not fixed by this upgrade.
Perhaps the Mac OS version runs better now. Feedback is needed (refs #12).
|
|
* This does not make sense for most SciTECO builds, but only when you
want to optimize for size as the lexers take up 50% of the compressed binary
size.
Without Lexilla, it should be possible get it compiled in about 500kb.
* It can be useful for instance when building for embedded distributions.
* When Lexilla is disabled, symbols-scilexer.c is also not generated
(we assume that the Lexilla sources are not available and it also doesn't serve any purpose).
* Consequently, most of the lexer configuration scripts are also not installed
under --without-lexilla.
|
|
* allows us to get rid of some workarounds
* the workarounds themselves required relatively recent PDCursesMod
versions, so we can just as well bump the version yet another time.
We are probably the only ones building it (via Github actions) anyway.
* With v4.3.4 you should be able to link dynamically, but we are still
linking statically for nightly builds to keep binary sizes small.
Unfortunately, the glib builds shipping with MinGW still have
dynamically linked helper executables.
|
|
workaround
* The keyboard hook required polling as well and was actually much less performant
than the generic getch() polling fallback.
Furthemore it did at least not work on Wine.
* We instead now release the WinGUI-internal mutex and yield the thread giving
it some time to process new key presses.
* This workaround is temporary and will probably be part of the the next PDCursesMod-release
(v4.3.4). We still want to support the latest MSYS/MinGW version though which is
currently at v4.3.2.
The fix will also currently only work when statically linking in libpdcurses_wingui.a.
This is what we do for nightly builds.
See also https://github.com/Bill-Gray/PDCursesMod/issues/197
* Once the fix is released upstream and into MSYS, we should probably bump our
minimal required PDCursesMod version.
The color-table workaround (cf9ffc0cec0d2e55930238d1752209bca659c96d) can then also be removed.
* We should also consider dropping official support for the classic PDCurses and support
only PDCursesMod - this will allow us to simplify interfaces-curses/interface.c a bit.
Support for classic PDCurses is probably broken by now anyway and trying to support it
is just too much.
|
|
* PDCursesMod is now the recommended PDCurses variant
* you should use at least v4.3.2 since earlier versions have problems
inserting CTRL+C and CTRL+V.
* We now check for PDC_get_version() since initscr() was name-mangled at least
for some time. The maintainers have now reverted to name-mangling endwin(),
we still check for PDC_get_version() as it is probably safer in the future.
* Properly define PDC_FORCE_UTF8 now.
* We no longer have to check for PDC_set_resize_limits() since PDCursesMod
now defines its own macro __PDCURSESMOD__ in curses.h.
|
|
* This simplifies writing CFLAGS="-g -O0" CXXFLAGS="-g -O0".
* We build "release" binaries by default.
NDEBUG will now be defined unless you specify --enable-debug.
This enables some optimizations that have long been implemented but were never actually active:
* SciTECO shuts down faster since it will not explicitly free memory.
On the downside, this would complicate memory debugging with Valgrind/memcheck.
* dlmalloc is built with -DINSECURE=1 which is supposedly a bit faster.
Some compilers also complained about an unportable preprocessor usage which should
now be gone.
* All CI builds are now with --enable-debug.
This will slow them down but ensure that more code is executed and thus tested.
|
|
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches).
All of the patches are now either irrelevant or have been merged upstream.
* Since Scintilla 5 requires C++17, this increases the minimum GCC version at least
to 5.0. We may actually require even newer versions.
* I could not upgrade the scintilla-mirror (which was imported from Mercurial),
so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0,
master was deleted and I reimported the entire Scintilla repo using
git-remote-hg.
This means that scintilla-mirror now contains two entirely separate trees.
But it is still possible to clone old SciTECO repos.
* The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed.
Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream
releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced),
we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3).
This branch is never rebased or deleted. Therefore, we are guaranteed to be able to
clone arbitrary SciTECO repo commits - not only releases.
Releases no longer have to be tagged in scintilla-mirror.
On the downside, fixup commits may accumulate in these new branches.
They can only be squashed once a new branch for a new Scintilla release is created
(e.g. by cherry-picking followed by rebase).
* Scinterm does no longer have to reside in the Scintilla subdirectory,
so we added it as a regular submodule.
There are no more recursive submodules.
The Scinterm build system has not been improved at all, but we use
a trick based on VPATH to build Scinterm in scintilla/bin/.
* Scinterm is now in Git and we reference the upstream repo for the
time being.
We might mirror it and apply the same branching workflow as with Scintilla
if necessary.
The scinterm-mirror repository still exists but has not been touched.
We will also have to rewrite its master branch as it was a non-reproducible
Mercurial import.
* Scinterm now also comes with patches for Scintilla which we simply applied
on our sciteco-rel-5-1-3 branch.
* Scintilla 5 outsourced its lexers into the Lexilla project.
We added it as yet another submodule.
* All submodules have been moved into contrib/.
* The Scintilla API for setting lexers has consequently changed.
We now have to call SCI_SETILEXER(0, CreateLexer(name)).
As I did not want to introduce a separate command for setting lexers,
<ES> has been extended to allow setting lexers by name with the SCI_SETILEXER
message which effectively replaces SCI_SETLEXERLANGUAGE.
* The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used
in the SciTECO standard library anyway - and have consequently been removed
from symbols-scilexer.c.
The style macros from SciLexer.h (SCE_...) are theoretically still useful - even
though they are not used by our current color schemes - and have therefore been
retained. They can be specified as wParam in <ES>.
* <ES> no longer allows symbolic constants for lParam.
This never made any sense since all supported symbols were always wParam.
* Scinterm supports new native cursor modes.
They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER
caret style is configured by default.
It makes no sense to enable native cursor modes now since the
command line should have a native cursor but is not yet a Scintilla view.
* The Scintilla upgrade performed much worse than before,
so some optimizations will be necessary.
|
|
|
|
* PDC_WIDE must be defined before including curses.h if the library
is also built against PDC_WIDE.
* Fixes building against PDCursesMod during Nightly Builds, ie.
fixes the current Win32 curses builds.
* The same problem exists for PDC_RGB.
It cannot currently be autodetected, so you must currently manually include
PDCURSES_CFLAGS="-DPDC_RGB" if you built your PDCurses with PDC_RGB.
The same will be true for PDC_NCMOUSE once we support mouses.
You best leave these settings in their defaults (disabled) if you have
control over the PDCurses build.
|
|
* follow the current terminology:
* PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
The Win32 GUI port is now called PDCurses/WinGUI.
* PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
to detect PDCursesMod API extensions.
GUIs (detached from system console) might be available both in classic PDCurses as well
as in PDCursesMod.
Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.
|
|
teco-gtk-label.gob to plain C
* Using modern GObject idioms and macros greatly reduces the necessary boilerplate code.
* The plain C versions of our GObject classes are now "final" (cannot be derived)
This means we can hide the instance structures from the headers and avoid using
explicit private fields.
* Avoids some deprecation warnings when building the Gtk UI.
* GOB2 is apparently no longer maintained, so this seems like a good idea in the long run.
* The most important reason however is that there is no precompiled GOB2 for Windows
which prevents compilation on native Windows hosts, eg. during nightly builds.
This is even more important as Gtk+3 is distributed on Windows practically
exclusively via MSYS.
(ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux
would have been an alternative.)
|
|
* I could not get malloc replacement via dlmalloc to work.
This does not work like on Linux by overwriting weak malloc() functions.
It should theoretically be possible to overwrite the default malloc zone
but I could not properly debug this since I can only build for Mac OS
via CI.
* memory polling seems to work though - test suite runs through
and it includes memory limiting test cases.
|
|
`-fno-optimize-strlen` is not supported on Clang and there is no way
to ignore unknown arguments.
|
|
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.
|
|
detect EMCurses
* Emscripten can be used (theoretically) to build a host-only platform-independant version
of SciTECO (running under node.js instead of the browser).
* I ported netbsd-curses with Emscripten for that purpose. Therefore, adaptions for running
in the browser are restricted to EMcurses now.
|
|
* Array allocations were not properly accounted since the compiler
would call the replacement new() which assumes that it would
always be called along with the replacement sized-deletion.
This is not true for array new[] allocations resulting in
a constant increase of memory_usage and unrecoverable situations.
This problem however could be fixed in principle by avoiding
memory counting for arrays or falling back to malloc_usable_size.
* The bigger problem was that some STLs (new_allocator) are broken, calling the
non-sized delete for regular new() calls which could in principle
be matched by sized-delete.
This is also the reason why I had to provide a non-sized
delete replacement, which in reality intoduced memory leaks.
* Since adding checks for the broken compiler versions or a configure-time
check that tries to detect these broken systems seems tedious,
I simply removed that optimization.
* This means we always have to rely on malloc_usable_size() now
for non-SciTECO-object memory measurement.
* Perhaps in the future, there should be an option for allowing
portable measurement at the cost of memory usage, by prefixing
each memory chunk with the chunk size.
Maintainers could then decide to optimize their build for "speed"
at the cost of memory overhead.
* Another solution to this non-ending odyssey might be to introduce
our own allocator, replacing malloc(), and allowing our own
precise measurements.
|
|
Automakefiles could be simplified by updating CXXFLAGS
in configure.ac instead.
|
|
support
* Since netbsd-curses can act as a drop-in replacement to ncurses,
SciTECO builds with --with-interface=ncurses as well.
However, it is unintuitive for users to build with ncurses support
when actually linking against netbsd-curses; so another option has been added.
* The UNIX/TTY specific code (which works with both ncurses and netbsd-curses)
was selected when NCURSES was detected at build-time.
This does not work for netbsd-curses, so we define a new symbol
NETBSD_CURSES. At build-time, a CURSES_TTY macro may now be defined.
* This effectively fixes the stdio in interactive mode, window titles
and the XTerm clipboard support for netbsd-curses.
Some minor features like the reduced ESCDELAY are still broken.
|
|
been shown to be unacceptably broken, so the fallback implementation has been improved
* mallinfo() is not only broken on 64-bit systems but slows things
down linearilly to the memory size of the process.
E.g. after 500000<%A>, SciTECO will act sluggish! Shutting down
afterwards can take minutes...
mallinfo() was thus finally discarded as a memory measurement
technique.
* Evaluating /proc/self/statm? has also been evaluated and discarded
because doing this frequently is even slower.
* Instead, the fallback implementation has been drastically improved:
* If possible use C++14 global sized deallocators, allowing memory measurements
across the entire C++ code base with minimal runtime overhead.
Since we only depend on C++11, a lengthy Autoconf check had to be introduced.
* Use malloc_usable_size() with global non-sized deallocators to
measure the approx. memory usage of the entire process (at least
the ones done via C++).
The cheaper C++11 sized deallocators implemented via SciTECO::Object still
have precedence, so this affects Scintilla code only.
* With both improvements the test case
sciteco -e '<@EU[X^E\a]"^E\a"%a>'
is handled sufficiently well now on glibc and performance is much better
now.
* The jemalloc-specific technique has been removed since it no longer
brings any benefits compared to the improved fallback technique.
Even the case of using malloc_usable_size() in strict C++ mode is
up to 3 times faster.
* The new fallback implementation might actually be good enough for
Windows as well if some MSVCRT-specific support is added, like
using _msize() instead of malloc_usable_size().
This must be tested and benchmarked, so we keep the Windows-specific
implementation for the time being.
|
|
and added a FreeBSD/jemalloc-specific implementation
* largely reverts 39cfc573, but leaves in minor and documentation
changes.
* further experimentation of memory limiting using malloc() wrapping
has shown additional problems, like dlsym() calling malloc-functions,
further reducing the implementation to glibc-specific means.
This means there had been no implementation for FreeBSD and checks
would have to rely on undocumented internal implementation details
of different libcs, which is not a good thing.
* Other problems have been identified, like having to wrap calloc(),
guarding against underruns and multi-thread safety had been identified
but could be worked around.
* A technique by calculating the memory usage as sbrk(0) - &end
has been shown to be effective enough, at least on glibc.
However even on glibc it has shortcomings since malloc() will
somtimes use mmap() for allocations and the technique
relies on implementation details of the libc.
Furthermore another malloc_trim(0) had to be added to the error
recovery in interactive mode, since glibc does not adjust the program break
automatically (to avoid syscalls I presume).
* On FreeBSD/jemalloc, the sbrk(0) method totally fails because jemalloc
exclusively allocates via mmap() -> that solution was discarded as well.
* Since all evaluated techniques turn out to be highly platform
specific, I reverted to the simple and stable platform-specific
mallinfo() API on Linux.
* On FreeBSD/jemalloc, it's possible to use mallctl("stats.allocated")
for the same purpose - so it works there, too now.
It's slower than the other techniques, though.
* A lengthy discussion has been added to memory.cpp, so that we
do not repeat the previous mistakes.
|
|
|
|
portable and faster hack
* Works by "hooking" into malloc() and friends and counting the
usable heap object sizes with malloc_usable_size().
Thus, it has no memory-overhead.
* Will work at least on Linux and (Free)BSD.
Other UNIXoid systems may work as well - this is tested by ./configure.
* Usually faster than even the fallback implementation since the
memory limit is hit earlier.
* A similar approach could be tried on Windows (TODO).
* A proper memory-limiting counting all malloc()s in the system can make
a huge difference as this test case shows:
sciteco -e '<@EU[X^E\a]"^E\a"%a>'
It will allocate gigabytes before hitting the 500MB memory limit...
* Fixed the UNIX-function checks on BSDs.
|
|
* especially to improve building on FreeBSD 11
* We need GNU Make, yet alone because Scintilla/Scinterm
needs it. We now document that dependency and added
an Autoconf check from the autoconf-archive.
We make sure that the build process is invoked with GNU make
by generating only GNUmakefiles.
The Makefile.am files have not been renamed, so this
change can be rolled back easily.
* Some GNU-Make-specific autoreconf warnings have still been
resolved. But not all of them, as this would have been
unelegant and we need GNU Make anyway.
* Declare ACLOCAL_AMFLAGS to appease autoreconf
* Added an explicit check for C++11 from the autoconf-archives.
In general we should support building with every C++11 compiler
that is sufficiently GNU-like.
* Do not use `sed` for inplace editing, as different sed-implementations
have mutually incompatible syntax for this.
Instead of declaring and checking a dependency on GNU sed,
we simply use SciTECO for the editing task.
This improves code portability on BSDs.
* Similarily, BSD/POSIX `cmp` is supported now.
This fixes the test suite on BSD without declaring a
dependency on the GNU coreutils.
* Simplified sciteco-wrapper generation.
|
|
performance issues with memory measurements
* Fixed build problems on Windows
* g_slice on Windows has been shown to be of little use either
and it does not work well with the GetProcessMemoryInfo()
measurements.
Also, it brings the same problem as on Glibc: Not even command-line
termination returns the memory to the OS.
Therefore, we don't use g_slice at all and commented on it.
* The custom Linux and Windows memory measurement approaches
have been shown to be inefficient.
As a workaround, scripts disable memory limiting.
* A better approach -- but it will only work on Glibc -- might
be to hook into malloc(), realloc() and free() globally
and use the malloc_usable_size() of a heap object for
memory measurements. This will be relatively precise and cheap.
* We still need the "Object" base class in order to measure
memory usage as a fallback approach.
|
|
* we were basing the glib allocators on throwing std::bad_alloc just like
the C++ operators. However, this always was unsafe since we were throwing
exceptions across plain-C frames (Glib).
Also, the memory vtable has been deprecated in Glib, resulting in
ugly warnings.
* Instead, we now let the C++ new/delete operators work like Glib
by basing them on g_malloc/g_slice.
This means they will assert and the application will terminate
abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
more important to have a good memory limiting mechanism.
* Memory limiting has been completely revised.
Instead of approximating undo stack sizes using virtual methods
(which is unprecise and comes with a performance penalty),
we now use a common base class SciTECO::Object to count the memory
required by all objects allocated within SciTECO.
This is less precise than using global replacement new/deletes
which would allow us to control allocations in all C++ code including
Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
checks would be cumbersome.
In any case, we're missing Glib allocations (esp. strings).
* As a platform-specific extension, on Linux/glibc we use mallinfo()
to count the exact memory usage of the process.
On Windows, we use GetProcessMemoryInfo() -- the latter implementation
is currently UNTESTED.
* We use g_malloc() for new/delete operators when there is
malloc_trim() since g_slice does not free heap chunks properly
(probably does its own mmap()ing), rendering malloc_trim() ineffective.
We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
be available elsewhere) and found that it brings no significant
performance benefit.
On all other platforms, we use g_slice since it is assumed
that it at least does not hurt.
The new g_slice based allocators should be tested on MSVCRT
since I assume that they bring a significant performance benefit
on Windows.
* Memory limiting does now work in batch mode as well and is still
enabled by default.
* The old UndoTokenWithSize CRTP hack could be removed.
UndoStack operations should be a bit faster now.
But on the other hand, there will be an overhead due to repeated
memory limit checking on every processed character.
|
|
* the new "?" (help) command can be used to look up
help topics.
* help topics are index from $SCITECOPATH/women/*.woman.tec
files.
* looking up a help topic opens the corresponding "womanpage"
and jumps to the position of the topic (it acts like an anchor
into the document).
* styling is performed by *.woman.tec files.
* Setting up the Scintilla view and munging the *.tec file
is performed by the new "woman.tes" lexer.
On supporting UIs (Gtk), womanpages are shown in a variable-width
font.
* Woman pages are usually not hand-written, but generated from manpages.
A special Groff post-processor grosciteco has been introduced for this
purpose. It is much like grotty, but can output SciTECO macros for styling
the document (ie. the *.woman.tec files).
It is documented in its own man-page.
* grosciteco also introduces sciteco.tmac - special Troff macros
for controlling the formatting of the document in SciTECO.
It also defines .SCITECO_TOPIC which can be used to mark up
help topics/terms in Troff markup.
* Woman pages are generated/formatted by grosciteco at compile-time, so
they will work on platforms without Groff (ie. as on windows).
* Groff has been added as a hard compile-time requirement.
* The sciteco(1) and sciteco(7) man pages have been augmented with
help topic anchors.
|
|
* Allows us to check for the Gob2 version at ./configure time
* this file ships with Gob2 installations, so in most cases
it could be found without shipping it with SciTECO.
* Autoconf is built such that source distributions will contain
all additional external macros compiled in aclocal.m4.
* However if somebody builds from Git, he/she would still
expect the ./configure checks to produce meaningful results
even if not all dependencies are installed properly.
It therefore seems to be good practice to include all
external M4 macros (gob2.m4) as a fallback with the source tree.
* /usr/share/aclocal contains many more useful m4 macros.
However since we can depend on pkg-config e.g. for finding
Gtk+ and Glib, I won't use those macros as else I would
have to bundle them to achieve the same kind of ./configure
robustness.
|
|
* makes sense since it already extracted information from ./configure
that is usually substituted.
* it already had to be run from a configured build directory
* it required the source tree directory, which had to be overwritten
on the Make command line when using an out-of-source build dir.
This is no longer necessary.
* It is still a stand-alone Makefile to keep it isolated from the main
build system, although it could certainly be translated to Automake.
* the generated file will now be called distribute.mk to signify
that it is a Makefile.
|
|
* Autotest ships with Autoconf, so it's available already
and relatively easy to integrate into an Autotools package.
* This is attached to `make check` using some Automake magic.
* The test suite will only call the built SciTECO for the time being.
But using tests/Makefile.am, custom programs could be easily
built.
* Since it uses the target sciteco, it cannot work in cross-compile
environments.
* The test suite tests/testsuite.at should be used for regression
tests at least: Whenever there is a bug, a test case should be
added to testsuite.at.
Later this might be split up into multiple includes for regressions
other tests.
|
|
* Usually, Scintilla will now be built with -O2
* this can improve performance significantly over the standard Scintilla -Os
(up to 10%).
* this also allows link-time-optimizing both Scintilla and SciTECO
(which are linked statically) by adding -flto to CFLAGS, CXXFLAGS and LDFLAGS.
Link-time-optimization will both reduce the total binary size
and improve performance slightly since scintilla_send_message() can be
inlined.
An -O3 optimized Scintilla when linked with LTO results in an only 300kb
larger SciTECO binary.
* the highest possible optimization thus requires the following maintainer
flags on the ./configure command line:
CFLAGS="-O3 -mtune=native -march=native -flto"
CXXFLAGS="-O3 -mtune=native -march=native -flto"
LDFLAGS="-flto"
* Windows and Debian builds use link-time-optimization now.
On Windows - where we link in everything statically - building
the dependant libraries with -flto could improve performance
even more.
* Debian builds respect the default hardening flags of the build
server now. This should ensure that SciTECO is built for the
correct architecture at the recommended optimization level etc.
|
|
* use libtool convenience libraries as much as possible
(for all static libraries except Scintilla)
* improves separation of language and user interface implementations
(e.g. the Gtk widgets are not interesting for the rest of SciTECO)
* the Curses popup widget can now be factored out of interface-curses.cpp
* some common CPPFLAGS are now defined by ./configure via AM_CPPFLAGS,
so they don't have to be repeated in each submodule.
* fixed building the Curses UI: GTK_FLOW_BOX_FALLBACK conditional
must always be defined.
|
|
* depend on Gtk+ 3.10. If necessary older versions should also
be supportable. GtkOverlay was already introduced in v3.2
* A fallback for GtkFlowBox is compiled in if the Gtk installation
is too old. This applies even to Ubuntu 14.04 which still runs
Gtk v3.10.
* the threading the Gtk UI is left as it is for the time being
even though the synchronization mechanism has been deprecated.
Alternative approaches have to be tried out and benchmarked.
* Completely revamped the GtkInfoPopup widget.
It is now as powerful as the Curses UI's popup widget.
* A GtkOverlay is used instead of the top-level window hack
in the Gtk2 version.
* GtkFlowBox is used to lay out the columns of the popup.
* I had to work around restrictions of GtkScrolledWindow
by writing my own poor-mans scrolled window which handles
size requests correctly.
* The popup window no longer overflows the screen size,
instead we scroll.
* Scrolling pagewise is finally supported. Wraps at the
end of a list just like the Curses UI.
* Instead of using only two stock icons, we now use
GIO to get file and directory icons for the current theme.
This looks even better.
* The GtkFlowBox allows selections which can be used for mouse
interaction later. But this is not yet implemented.
* Theming of the popup widget and command line is still
not performed correctly.
|
|
* Haiku can be handled like UNIX in most respects
since it is POSIX compliant, has a UNIX-like terminal
emulator and uses ncurses.
* still the Glib platform macro is G_OS_HAIKU instead of
G_OS_UNIX, so the preprocessor conditionals had to be adapted.
* the only functional difference between a Haiku and UNIX build
is the default SCITECOCONFIG path.
We use the config path returned by Glib instead of $HOME,
so .teco_ini will be in ~/config/settings on Haiku.
Other UNIX ports appear to use the same conventions.
* Some Haiku-specific restrictions still apply:
* Haiku's terminal is xterm-compatible, but only supports
8 colors. Therefore only the terminal.tes color scheme
can be used and the terminal must be set up to
"Use bright instead of bold text".
* The terminal has artifacts. This appears to be a Haiku
bug and affects other curses applications as well.
* GTK is yet unsupported on Haiku, so there may never be
a GUI port (unless someone writes a QT GUI for SciTECO).
* SciTECO cannot be built with the legacy gcc2 used for
BeOS compatibility on Haiku. This would require too many
changes for an obsolete platform.
BeOS and the x86_gcc2 platform of Haiku will therefore
never be supported.
The PPC and ARM platforms of Haiku should work but are untested.
* a HaikuPorts recipe will be provided for the next regular
SciTECO release. This should hopefully allow installation via
HaikuDepot.
|
|
* enabled via --with-interface=xcurses, so we can configure
it automatically via xcurses-config.
This also adds XCURSES_CFLAGS and XCURSES_LIBS.
* The X11 window class name is set to "SciTECO".
X11 resource overrides can currently not be set via
sciteco's command line. The user may use .Xdefaults though.
* interruptions via CTRL+C are currently not supported.
Apparently, XCurses also does send SIGINT in cbreak() mode.
An XCurses-specific hack would be cumbersome.
* ~InterfaceCurses() should probably be rewritten.
Curses cleanup should be completely in restore_batch() as
the destructor may be called after Curses-cleanup handlers.
E.g. isendwin() SEGFAULTs on XCurses when called from the
destructor.
|
|
* requires a recent patch to Scinterm
* can be overwritten in SciTECO's build system via NCURSES_CFLAGS or
PDCURSES_CFLAGS.
* NCURSES_LIBS has also been introduced. The check for ncurses
will now use pkg-config if available.
* eases multiple builds with different Curses variants
(e.g. when cross-compiling for Windows)
* pass more toolchain variables into Scintilla build process (CC and RANLIB).
This should fix Cross-compiling Scintilla/Gtk
* Pass GTK cflags into Scintilla/Gtk build system.
|
|
minimum version
* it was necessary to increase the upstream version so I could
upload new versions to launchpad while debugging PPA build issues.
* ChangeLog finalized for v0.6.4
* SciTECO requires at least libglib v2.28 (but that's only a guess)
|
|
* allows us to link against PDCurses/win32a statically.
It requires additional Windows DLLs (gdi32 and comdlg32) and since
there's no PDCurses configuration mechanism, it is easiest to set
the PDCurses linker flags using a PDCURSES_LIBS env variable.
* This is only possible since Scintilla links statically, we do the
linking of the binary and can provide the linker flags.
It is still not possible to overwrite the CFLAGS used for PDCurses
without modifying the Scinterm Makefile.
* Using PDCURSES_LIBS we can get rid of --with-interface=emcurses since
if library checks fail with EMscripten, we can simply define
PDCURSES_LIBS="-lpdcurses"
|
|
the MSVCRT versions are not glibc-compatible and we do not
actually need glibc compatible versions, as all allocations
are done through the libglib wrappers.
|
|
* activated via bit 4 of the ED flag (enabled by default)
* automatic EOL guessing on file loading and translation to LFs.
* works with files that have inconsistent EOL sequences.
* automatic translation to original EOL sequences on file saving
* works with inconsistent EOL sequences in the buffer.
This should usually not happen if the file was read in with
automatic EOL translation enabled.
* also works with the EC and EG commands
* performance is OK, depending on the file being translated.
When reading files with UNIX EOLs, the overhead is minimal
typically-sized files. For DOS EOLs the overhead is larger
but still acceptable.
* Return (line feed) is now an immediate editing command.
This centralizes EOL sequence insertion.
Later, other features like auto-indent could be added to
the editing command.
* get_eol() has been moved to main.cpp (now called
get_eol_seq()
* Warn if file ownership could not be preserved when
saving files.
* IOView has been almost completely rewritten based
on GIOChannels. The EOL translation code is also in IOView.
|
|
|
|
* sciteco.ico contains a 16 color 16px, a 255 color 32px and
a true color 48px version of the icon.
The first ones are good for legacy Windows versions like 2000,
while the latter one should be preferred by Windows >= 7.
* Also added the 48px version as a PNG for Linux.
But it is not installed currently, as there is no standardized
place for it and it wouldn't do much good in /usr/share/sciteco.
|
