I think Tobias is having trouble with SWMgr::deleteModule and not the
uninstalling part. I don't think most of us actually call deleteModule
on SWMgr. I usually just delete the SWMgr and make a new SWMgr after
the user is done installing or uninstalling modules.
That is new code and I see
FYI, I have no trouble uninstalling or re-installing modules in my
newly-built RC2, not seeing the problem Tobias reports.
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to
I'v just isolated the calls in a test program and got this back trace
after it hung. Does that help?
#0 0x7fc2c851a237 in
std::_Rb_tree_increment(std::_Rb_tree_node_base*) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x55c02f096465 in std::_Rb_tree_iteratorconst,
Bummer. It shouldn't hang. Does the user running the action have
sufficient privileges to uninstall the module? To repeat, it shouldn't
hang, regardless of your answer. I'll have a look.
In a bit of a panic because I just pushed Bishop 1.6.1 out built against
SWORD 1.9.0RC2, I just tried
Hi Troy,
Thanks for your work on this new release of SWORD!
I just gave it a try with Ezra Project and based on an automated
end-to-end acceptance test I noticed that removal of a module did not
work anymore (tested with the KJV). The test ran into a timeout. The
SWORD revision that I was
On 9/17/20 2:25 PM, Troy A. Griffitts wrote:
> Please let me know if you have positive or negative results. I would
> like to hear things are working in our mainstream frontends before
> pushing this out; it would give me happy thoughts.
Xiphos 4.2.1 builds fine against it. I don't know if I
