Am 16.05.2009 um 21:57 schrieb Jonathan Marsden:
I'm wondering whether it might end up being simpler to create a Python
(or whatever your chosen portable scripting language is) GUI wrapper
for
the SWORD utilities, that people run locally on their own machine,
rather than a web UI for a
On May 17, 2009, at 6:48 AM, Manfred Bergmann wrote:
Am 16.05.2009 um 21:57 schrieb Jonathan Marsden:
I'm wondering whether it might end up being simpler to create a
Python
(or whatever your chosen portable scripting language is) GUI
wrapper for
the SWORD utilities, that people run
2009/5/17 Greg Hellings greg.helli...@gmail.com:
You could patch that out in configure.ac (so it just sets -O0 and -g3)
and then regenerate configure.in and configure, to test whether that
solves the FTBFS issue. I'm pretty sure it would, but tests are better
than guesses.
Jonathan
I went
2009/5/17 Jonathan Marsden jmars...@fastmail.fm:
Jonathan Marsden wrote:
I'll try a build of SWORD 1.6.0 with --enable-debug in a Jaunty 32bit
(x86) VM here... hmmm, it works fine for me! However, uncommenting the
--enable-debug in debian/rules gets me FTBFS, on 32bit and 64bit Jaunty.
2009/5/16 Jonathan Marsden jmars...@fastmail.fm:
I'm wondering whether it might end up being simpler to create a Python
(or whatever your chosen portable scripting language is) GUI wrapper for
the SWORD utilities, that people run locally on their own machine,
rather than a web UI for a central
Am 17.05.2009 um 14:54 schrieb Dmitrijs Ledkovs:
2009/5/16 Jonathan Marsden jmars...@fastmail.fm:
I'm wondering whether it might end up being simpler to create a
Python
(or whatever your chosen portable scripting language is) GUI
wrapper for
the SWORD utilities, that people run locally on
On Sun, May 17, 2009 at 10:02 AM, Manfred Bergmann bergman...@web.de wrote:
Am 17.05.2009 um 14:54 schrieb Dmitrijs Ledkovs:
2009/5/16 Jonathan Marsden jmars...@fastmail.fm:
I'm wondering whether it might end up being simpler to create a Python
(or whatever your chosen portable scripting
Am 17.05.2009 um 16:10 schrieb Greg Hellings:
On Sun, May 17, 2009 at 10:02 AM, Manfred Bergmann
bergman...@web.de wrote:
Am 17.05.2009 um 14:54 schrieb Dmitrijs Ledkovs:
2009/5/16 Jonathan Marsden jmars...@fastmail.fm:
I'm wondering whether it might end up being simpler to create a
Dear Manfred,
If you decide to continue down the web route, as DM mentioned, we indeed
plan to have a web tool to let organizations and other users manage
their own library of SWORD modules (we've had requests for this from
some of the larger orgs that use our stuff). There is the start of a
We ran into an interesting issue with ListKeys. The code in question
is used in Xiphos to get a list of search results, then iterate
through them to add to a gui control. I started noticing that
occasionally, an entry would be junk, ie non-printing characters. We
traced it down to this portion of
Yes, as a general rule, you should not count on the return value of a
const char * persisting after the assignment.
e.g., it is alway safe to:
string value = results.getText();
results.anything();
it is not necessarily safe to:
const char *value = results.getText();
results.anything();
It turns out that if we use ++results instead of results++ we don't
have a problem. So it would seem that there is still something funny
going on.
Nevertheless we will not count on the result persisting.
Matthew
___
sword-devel mailing list:
Again, the details with this, if interested are:
results++ mandates increment then return of a temporary which
represented the object before the increment.
You are assigning your retval to the internal text value of this
temporary, which goes out of scope immediately after the assignment
The 3.1 source tarball was released a little while ago; binary builders
will be doing their thing soon and packages should be available in short
order. I believe the necessary arrangements for mostly-automatic
inclusion in Linux repos have been finalized, and the Windows installer
will be
To me, none of that answers the question why everyone in 64-bit was
able to replicate the problem, while people in 32-bit machines weren't
able to replicate the bug. That just seems like an inconsistency.
Are we willing to just say it's something that the versions of the
compilers handled
osis2mod doesn't handle comments - is this known/cared about?
osis2mod currently assumes that a div eID=... that appears outside a
verse, but inside a chapter is a chapter-closing div (presumably because
that is how commentaries close chapters). This breaks the pre-verse logic
when you have this
Ben Morgan wrote:
I wonder if we need to release some of the important utilities at
different times from the engine. (i.e. have a osis2mod release once
problems are fixed with it)
To me, this suggests more the need for (more and better?) automated
tests of the utilities, rather than a
On Mon, May 18, 2009 at 3:15 PM, Jonathan Marsden jmars...@fastmail.fmwrote:
Ben Morgan wrote:
I wonder if we need to release some of the important utilities at
different times from the engine. (i.e. have a osis2mod release once
problems are fixed with it)
To me, this suggests more the
Ben Morgan wrote:
I didn't add regression tests... I'm not sure how workable they are. (though
they would probably be a good idea)
Can't we do osis2mod and then mod2osis (or even mod2imp) and
store/compare that output, so that the comparison is of text? Or is
there some reason why that can't
On Mon, May 18, 2009 at 3:35 PM, Jonathan Marsden jmars...@fastmail.fmwrote:
Ben Morgan wrote:
I didn't add regression tests... I'm not sure how workable they are.
(though
they would probably be a good idea)
Can't we do osis2mod and then mod2osis (or even mod2imp) and
store/compare that
20 matches
Mail list logo
