what's new, what's coming

0 views
Skip to first unread message

Yann Dirson

unread,
Apr 20, 2008, 4:21:20 PM4/20/08
to tagua...@googlegroups.com
Hi all,

I have finally created the "stable" branch and pushed some
component-api stuff to master.

It includes a small refactoring of the "variant loader" classes, which
makes it possible to implement support for other plugin systems than
the KDE one. The main motivation was to be able to implement a loader
for "builtin variants", which is in master as well. You can make all
standard plugins builtin by passing -DMONOLITH=yes to cmake.

It will make it much easier to develop and debug tagua, bringing to us
among other advantages:

- it is not necessary to install a plugin in a special place, they are
be dynamically linked: the good old src/tagua.shell script is now
working again to run from the source tree (which is going to same me
hours, and will hopefully make it easier for people to contribute).

- you can use mpatrol and other debugging tool which need to know
after exit what the memory map of your process was (an mpatrol run the
other day was showing scary things, but I was unfortunately not been
able to get detailed info about them, now that will be possible).

- the whole framework should make it easier to port tagua to platforms
without kde, possibly by relying on the Qt plugin loader only (I still
want to see tagua run on my iPAQ some day, and/or possibly on a Neo
Freerunner it I get one first ;)

It is not perfect yet - a known issue is that a kde-loaded variant has
problems locating its dependencies when those are builtin. But it's
not really a problem before this mechanism is used in production.


I have also run valgrind on the current code for a couple of sample
sessions, and noted a number of real problems. Some I could fixed
right away, some will require more thought, and I put a couple of
FIXME tags in the source. More usage of valgrind has to be done
anyway - and possibly some tuning, the number of possibly-problems it
shows, which seem to come solely from X11/Qt/KDE/whatever libs we use
ise truely scary and hides ours).


On my branch, the shogi and minishogi ports have slightly progressed,
and will surely progress faster now. I still have to make pools work
for them - and, incidently, the remaining crash when starting a new
crazyhouse game from the menu is *also* pool-related. Not sure they
are related, but there is surely some work to do around those pools
(not to mention they are more than essential to the upcoming Entropy
variant :)

Best regards,
--
Yann.

Reply all
Reply to author
Forward
0 new messages