On 24 November 2011 05:41, Greg Hellings wrote:
> $ apt-cache showpkg swig
> Package: swigVersions: 2.0.4+really1.3.40-3ubuntu4
>
While 2.0.4 was uploaded sometime in the past into the archive, it was
decided to go back to 1.3.40 (downgrade).
Regards,
Dmitrijs.
I suspect from the wchar_t reference that it has to do with the new code we
added for clucene2. This method does not need to be exposed via the bindings.
Is there some way to say "ignore this method"?
Greg Hellings wrote:
>$ apt-cache showpkg swig
>Package: swigVersions: 2.0.4+really1.3.40-3ub
$ apt-cache showpkg swig
Package: swigVersions: 2.0.4+really1.3.40-3ubuntu4
I have no idea what that really means. My guess is that in the change
from 1.3.x (which was actually present in Natty and earlier to swig 2
in Oneiric there were changed/removed macros. It seems to just be a
macro or two r
On Wed, 2011-11-23 at 23:13 -0600, Greg Hellings wrote:
> Yeah, trying to build it myself jogged my memory. I haven't rebuilt
> the bindings in a little while but was just getting myself setup with
> Ubuntu 11.10 on my laptop. Seems to be changes in SWIG that caused it,
> not on our end. I'll see w
Yeah, trying to build it myself jogged my memory. I haven't rebuilt
the bindings in a little while but was just getting myself setup with
Ubuntu 11.10 on my laptop. Seems to be changes in SWIG that caused it,
not on our end. I'll see what I can do, but I know very little about
SWIG, so no promises!
On Wed, 2011-11-23 at 00:42 -0600, Greg Hellings wrote:
> Guys,
>
> Looks like the SWIG Python bindings (and, based on the error, I would
> assume the Perl bindings as well) are broken
Thanks. Yes, the Perl bindings are broken. I reported this a couple of
weeks ago.
Peter
Matthew Talbert wrote:
> I think there is some confusion here.
>
> The only SWIG bindings that actually work are the Python bindings. The
> others would need some work to even compile. It has been this way for
> some time.
>
> swordweb uses the CORBA bindings, which are unrelated.
You are right
> We have had the occasional bug in SWIG that has been worked around
> (particularly in SWIG's iteration over STL types, which has the
> unpleasant side effect of occasionally causing access violations).
> It's also worth considering the overhead of converting types like
> SWBuf to native Python ty
I think there is some confusion here.
The only SWIG bindings that actually work are the Python bindings. The
others would need some work to even compile. It has been this way for
some time.
swordweb uses the CORBA bindings, which are unrelated.
Matthew
__
Jonathan Morgan wrote:
> On Sat, Nov 28, 2009 at 5:55 PM, Troy Melhase wrote:
>>> We probably could replace SWIG with SIP, but it is unlikely we would
>>> do it soon just because BPBible works and works now with what is
>>> there. The changes you describe would be far more likely to benefit
>>> t
On Sat, Nov 28, 2009 at 5:55 PM, Troy Melhase wrote:
>> We probably could replace SWIG with SIP, but it is unlikely we would
>> do it soon just because BPBible works and works now with what is
>> there. The changes you describe would be far more likely to benefit
>> the Python programmer working
> We probably could replace SWIG with SIP, but it is unlikely we would
> do it soon just because BPBible works and works now with what is
> there. The changes you describe would be far more likely to benefit
> the Python programmer working with the SWORD API directly than they
> would be to benefi
On Sat, Nov 28, 2009 at 3:37 PM, Troy Melhase wrote:
> Greetings,
>
> I've created a Python binding for libsword via SIP[1]. The code is here:
>
> http://github.com/natural/sword-sip
>
> The binding is mostly complete, certainly the larger classes and
> methods. I'd like it if folks who use t
On Wednesday 19 March 2008 23:47:02 Ben Morgan wrote:
> Hi,
>
> Step 2 can be done using
> VerseKey.castTo(swkey)
Thanks! I had guessed that .castTo might help me, but I couldn't work
out how to use it.
Cheers,
Luke
--
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor
Hi,
Step 2 can be done using
VerseKey.castTo(swkey)
castTo will return None if it cannot cast to it (it uses dynamic cast).
This will happen if (for example) the range is Genesis 1:1, in which
case it seems to just return a SWKey.
Most of the wrapped classes have castTo for them.
If you want to
This is probably why I get a crash when I exit my python shell after
testing the Sword module from the command line.
Now I'm trying to figure out how to best use modules. I think, for the
time being, I'll use the same methodology that MacSword uses, which is
to place the ".swd" modules insi
Hi,
Instead of:
>>> from Sword import *
>>> mf = MarkupFilterMgr(FMT_WEBIF)
>>> mgr = SWMgr(mf)
Try
>>> from Sword import *
>>> mf = MarkupFilterMgr(FMT_WEBIF)
>>> mf.thisown = False
>>> mgr = SWMgr(mf)
mf.thisown = False tells swig not to GC the sword object.
This may or may not help. I have
Hi,
> cd sword-1.5.7/bindings/swig/package/
I tried the same commands with Sword's current CVS - it worked fine. I test
the "import Sword" command.
Make sure to configure the Sword library with ./usrinst.sh --enable-shared and
then configure the Swig bindings.
I think the bindings got some fix
18 matches
Mail list logo
