Re: [sword-devel] Perl bindings failure

[Greg Hellings]

Peter,

I just built and ran them last night for a module I was working on. They
required a few patches to Sword, two of which I committed directly and one
of which was attached to a different email I sent. Try pulling the latest
code and applying that patch and see if it solves your problem.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Build Breakage

[Greg Hellings]

It looks like Troy's latest renaming of ftptrans -> remotetrans appears to
have broken building (at least with CMake) in a few cases. I just made
commits to fix the following:

1) Building with CMake
2) Building the Swig bindings

I have attached another patch which enables building in the absence of
cURL. For me, the compile dies at a few different locations when I try to
build with cURL absent. This patch fixes it. I believe I don't have
permissions to commit to the include/ and src/ folders, so someone else
will need to check and submit this fix.

--Greg


06-no-curl.patch
Description: Binary data
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bible book introductions

[Greg Hellings]

On Mon, Jun 3, 2013 at 10:06 AM, DM Smith  wrote:

>
> It is far more than 70. Every chapter can have an introduction. To see if
> a module one would have to check every verse 0 for text content. It is not
> sufficient to see if it has content. It may only have structural content.
> So that means it will have to be parsed for text.
>

> Worst case is a module that does not have introductions. One would have to
> check every verse 0. If all that is wanted is to know whether a module has
> at least one introduction, the code can stop having found the first one.
>
> Also, non-canonical, non-title content can appear anywhere. It is quite
> possible for there to be section introductions. AFAIK, we just haven't had
> any modules with that. (But I have paper study bibles with that feature.)
> So that would mean that every verse would have to be checked to see if it
> has pre-verse content with introductory material.
>

Then the scope of this thread has expanded from "Bible book introductions"
to "Any introduction or title or non-canonical text anywhere".

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bible book introductions

[Greg Hellings]

On Mon, Jun 3, 2013 at 7:32 AM, Chris Burrell  wrote:

> I thought of that - but then that means that low powered devices, or
> devices with large numbers of modules have to scan every part of every
> module on installation of the module while they do their discovery process.
>
> The Scope was related to Copyright & Distribution, but I'm not sure a
> discovery approach would work. The idea here is that the data doesn't
> exist, and the conf file was suggested as the place to store it. We can't
> derive that very easily from the module contents.
>

I'm curious what this option would represent for Introductions. You're
talking about checking ~70 string values for empty either at module load
time or at module install time (and then adding some sort of cache value).
Even on a low-powered device, reading 70 entries is not going to be a
cumbersome time waster if done once at module installation.

In terms of computation, this is nowhere near some of the heavier checks
where time is being saved looking for every possible Jesus quote for markup
or the like.

--Greg


>
> Another example, was my previous thread on having a marker indicating the
> type of strong numbers used (e.g. following the Septuagint in the OT, or
> the Hebrew). I'm still after a solution on that (although I believe we did
> decide to add a flag for those modules - can't recall exactly now).
>
> Chris
>
>
>
> On 3 June 2013 13:16, DM Smith  wrote:
>
>> I'm thinking of having a "sidecar" conf for a module. Right now when a
>> user wants to save certain settings for a module, we (JSword) modify the
>> conf. (I.e. CipherKey and Font).
>>
>> This could then be used to save anything a front end discovers and does
>> not want to discover a second time. Such as Scope (which to my recollection
>> was not shot down), Introductions, Colophons, user settings(?)
>>
>> The basic idea is that the engine (JSword in my case) would read the conf
>> and then the sidecar for the module, merging into a single internal
>> representation of the conf. That way the module's conf would be then kept
>> pristine.
>>
>> In Him,
>> DM Smith
>>
>> On Jun 3, 2013, at 8:03 AM, Nic Carter  wrote:
>>
>>
>> I think (& I hope?) what is being proposed is a method in Sword that will
>> check any book of the Bible to see if it is empty or not. This will
>> ultimately be very fast, as it may need to test a large number of verses?
>> This same method should be able to be adapted to live-test introductions
>> for books &/or testaments? Then you could determine whether or not to allow
>> such a preference/toggle? Also, then you could tell which introductions
>> should be navigable to?
>>
>> FYI, in PS I simply don't show options for modules that don't support a
>> feature. Why show a greyed-out Strong's Numbers toggle in the NET, for
>> example? Or Greek accents toggle for any English-language module? But,
>> obviously, this is a design decision :) :)
>>
>> BTW, I believe we're still waiting to hear whether or not an
>> isEmpty(BookName) method is going to be incorporated into Sword? I'm
>> interested in it, but I was just reminded that PS still doesn't support
>> GenBooks & thought I might actually rectify that rather than look into an
>> isEmpty() implementation... ;)
>> [yes, Karl, you requested it about 3.5 years ago, & I'm looking at the
>> redesigns required to make this happen!]
>>
>> Just my thoughts :)
>> ybic,
>> Nic :)
>>
>> Sent from my phone, hence this email may be short...
>>
>> On 03/06/2013, at 21:04, Chris Burrell  wrote:
>>
>> For clarity, my use case is as follows.
>>
>> I have a menu displaying options such as Verse numbers, Headings, Verses
>> on New Lines, Red letters. I'd like to add an option called Introductions
>> (and perhaps one called Colophon).
>>
>> The options in this menu are grayed out when the underlying module
>> doesn't support this. If the option is grayed out, I add an explanation as
>> to why that is (e.g. the module doesn't support it, or 1 option is not
>> compatible with another option that is already selected, etc.)
>>
>> The availability of the options is uniquely dependant on which version of
>> the Bible or Commentary a user has selected. If a user selects a different
>> module, the options available to him are updated automatically. For
>> example, a user is clearly aware that most of the Old Testament doesn't
>> have a Red Letter option. He might however work mainly from the ESV and
>> want his frontend to show Jesus's words in red when they are in the text,
>> so he sets up the option once.
>>
>> At this stage, we don't care about what passage/text a user is going to
>> lookup. We can't guess what's in his mind! And we can certainly not guess
>> what he's going to lookup tomorrow, the day after tomorrow, next month,
>> next year.
>>
>> This is the same for Introductions & Colophons. He might decide he's
>> never interested in seeing Introductions and Colophons and want to turn
>> them off completely. Or on the other hand he might wa

Re: [sword-devel] Bible book introductions

[Greg Hellings]

On Mon, Jun 3, 2013 at 7:16 AM, DM Smith  wrote:

> I'm thinking of having a "sidecar" conf for a module. Right now when a
> user wants to save certain settings for a module, we (JSword) modify the
> conf. (I.e. CipherKey and Font).
>
> This could then be used to save anything a front end discovers and does
> not want to discover a second time. Such as Scope (which to my recollection
> was not shot down), Introductions, Colophons, user settings(?)
>

BibleTime uses (used?) a cache for at least some of the data of modules. In
particular I know the keys of a dictionary module are cached at first
module load and only updated when the module's version number is changed. I
discovered this some time back while working on such a module which would
not reflect updates to the keys without bumping the version in the conf.

Of course, this type of behavior adapted to Scope is fine on a desktop or
even a netbook or most tablets. But it's unacceptable for a truly
low-powered device.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On May 9, 2013 7:51 PM, "Stephan"  wrote:
>
> Greg,
>
>
>> Any web server worth its salt and properly configured will already gzip
>> outgoing data. Thus the need to transfer the data in a compressed format
>> is unnecessary.
>
>
> Jpp, that's true. What do you think: Should the server part be a service
of crosswire (so it is hosted on their servers) or it is better do develop
an easy-to-install server app, that everybody can install or host it by
themself.
>
>

I have no idea what "Jpp" means, despite the fact that you have used it a
few times through this thread. So I'll just ignore it for now. :D


I think creating a reference application that can do the serializing is a
great idea. However, hosting all of Crosswire's materials in a
non-Crosswire environment through this mechanism runs into the same problem
that mirroring the modules in any other fashion encounters with limited
distribution requirements. Only CrossWire could host many of the modules
due to their limited distribution rights, but creating an app that anyone
could install and run (and doing so with Netty/Jetty in Java or similar
would be relatively straightforward) could allow for some interesting
abilities.

E.g. a user could be presented a graphical list of their installed modules
as discovered by the Sword/JSword engine and could manually check off the
ones they want to share, etc. It could be extremely simple to deploy! But
the main hosting of CrossWire's material would need to be done by CrossWire
itself.


>> Compressing for storage into a client-side storage mechanism would be
>> quite valuable on devices which truly are space-limited. But even a
>> low-end semi-intelligent phone these days comes with around 1G of
>> storage. Even our biggest Bible module, in its unprocessed full OSIS
>> glory only sits at a few MB. Such super space-limited devices are even
>> more bound by processor and RAM than by "disk" storage making any
>> on-the-fly processing quite painfully limiting.
>
>
> If we use indexedDB you can store their a compressed arrayBuffer/Blob
(using zlib.js e.g.). Have you thought about how to make the keys for a
key/value storage?
>

There are a number of designs for it, including some that would support
multiple versification schemes and even ones which could support a
versification scheme unique to the module itself (although that more
flexible implementation would require a little bit of tweaking tot he parse
code).

At one point BibleTime designed a way to implement a storage backend that
was optimized for use in a database or key/value location. That design
could be implemented with IndexedDB.

I still think compressed storing is unnecessary, especially if we're going
to support searching or similar. But it would be worthwhile to test its
impact on storage space and retrieval performance with a variety of
hardware.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Thu, May 9, 2013 at 7:17 AM, Israel  wrote:

>  On 05/09/2013 03:38 AM, Pola Edward wrote:
>
> Hi every one,
> this is very interesting topic :)
>
> Actually I like the idea of Greg, you can make a server side page that can
> convert current modules to a suitable format for JS Clients
>
>  +1 to that.  Cloud computing has become more popular (Joli Os,
> Peppermint OS, Chrome book OS, Firefox OS, etc..)
>
>
>  But I wonder if the current sword modules format is suitable to the
> expansion of nowadays OSs ?
>
>  I might help to implement a way to access compressed files, like
> LiveCD's do with the squashfs, as a way to bundle things for quicker
> downloading and make things smaller for the lower end markets, and easier
> for people in restricted countries to have more tools in limited space, and
> of course countries where internet is hard to get to, or expensive :)
>

Any web server worth its salt and properly configured will already gzip
outgoing data. Thus the need to transfer the data in a compressed format is
unnecessary.

Compressing for storage into a client-side storage mechanism would be quite
valuable on devices which truly are space-limited. But even a low-end
semi-intelligent phone these days comes with around 1G of storage. Even our
biggest Bible module, in its unprocessed full OSIS glory only sits at a few
MB. Such super space-limited devices are even more bound by processor and
RAM than by "disk" storage making any on-the-fly processing quite painfully
limiting.

I would shy away from introducing such unnecessary complexity into a
JavaScript-style solution. Now, if you can properly wrap and access the
Sword library to access native-level C++ speeds then it's a different story
altogether.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XHTML Rendering of OSIS Reference Doc - Whitespace

[Greg Hellings]

On Thu, May 9, 2013 at 6:01 AM, Troy A. Griffitts wrote:

>
>
> On 05/08/2013 12:31 PM, Troy A. Griffitts wrote:
>
> OK, so from this:
>
>
>   Old Testament > osisID="Gen" sID="gen2" type="book"/> THE FIRST BOOK OF MOSES CALLED
>> GENESIS  Introduction and
>> Outline  This is the Book of Genesis, the first
>> book in the Bible. It may be outlined as follows:  
>> 1Creation of Heaven and Earth, 1:1-2:4a
>> 2Creation of Man and Woman, 2:4b-25 3Fall,
>> 3:1-24 ...   Tables work like this:
>> Column 1 Label Column 2 Label Column 1, Row 1 Column 2, Row 1
>> Column 1, Row 2 Column 2, Row 2 
>>  From Creation to Abraham
>> (1:1–11:9)
>> [ Genesis 1:1 ] In the beginning God created the heaven and the earth.
>> 
>> [ Genesis 1:2 ] Text of verse 2.
>>
>
> As a first run, I'm going to shoot for this below.  Will this make
> everyone happy regarding whitespace?  Please ignore the poor table output--
> that another issue.
>
> Old Testament
>
>
> THE FIRST BOOK OF MOSES CALLED GENESIS
>
> Introduction and Outline
>

+1 to Peter's suggestion to add classes to these headers, or to generate
   etc based on the semantics of the OSIS source titles and not
to just generate  for all types. Through CSS an  can be rendered
down to 6pt font, non-bold with italics while an  is scaled up
arbitrarily big.


>
> 
> This is the Book of Genesis, the first book in the Bible. It
> may be outlined as follows:
> 
>

I think these breaks and the ones following the  are the wrong way to
go. Since  is, by default, a block element that already begins and ends
on its own lines, the proper way to render desired vertical spacing is to
add a class with margin-top and margin-bottom specified.


> 
> 1Creation of Heaven and Earth, 1:1-2:4a
> 2Creation of Man and Woman, 2:4b-25
> 3Fall, 3:1-24
> ...
> 
> 
> 
> Tables work like this: Column 1 Label Column 2 Label Column
> 1, Row 1 Column 2, Row 1 Column 1, Row 2 Column 2, Row 2 
> From Creation to Abraham (1:1–11:9)
>
> [ Genesis 1:1 ] In the beginning God created the heaven and the earth.  />
> [ Genesis 1:2 ] Text of verse 2.
>

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XHTML Rendering of OSIS Reference Doc - Whitespace

[Greg Hellings]

Off the cuff here, it seems the issue is the difference in semantics of
 between OSIS - where it marks a structural division within a text
which can be of many different levels and layers and in XHTML where it
represents a box of block-style layout which defaults to being the full
width of its container.

Producing "proper" output seems like it is only feasible if we are handling
a block of output. The sample you have contains 3 sID and 1 eID attributes
on div elements. And they are self-closing elements, which will typically
render as vertical whitespace in XHTML. Ideally, any with sID="..." would
be rendered with  and any with eID="..." would be rendered with .

The problem becomes rendering a list of 30 (or however many) verses, if
each is rendered separately by our filters. If  is within
Gen.0.0 but  is at the end of the chapter, which appears
to be the case here, then we don't properly want to generate something like

 Gen.0.0

 Gen.1.0
 Gen.1.1
 Gen.1.2
 ...
But rather we want something like

 Gen.0.0
 Gen.1.0
 Gen.1.1
 Gen.1.2
 ...

At least when not dealing with inter-linear versions, we do.

In BibleTime we have discussed how to properly handle this and came up with
an interesting solution that we engineered but never implemented. Our
thought was to store information along with each verse which includes a
pre- and post- verse markup. This would need to become part of the OSIS
import process, and it would track the "semantically" open elements such as
 which, by XML standards are no longer open but the OSIS
semantics designate that div is open until  is
encountered. This would be in addition to the actually open XML elements.

Every verse entry would then keep a store of the open elements at its start
and those still open at the end of the entry. Then, when an arbitrary range
is selected for rendering - say, Genesis 1:15-25 - a single, complete OSIS
document could be generated by taking Gen.1.15.pre and appending that to
the text of Gen.1.15-Gen.1.25 and then appending Gen.1.25.post. Then a
proper filter can operate on the entire block of text to generate correctly
wrapping  ...  and other markup.

Perhaps I overstepped the answer of what the above markup _should_ be, but
I just wanted to toss out the solution that the BT folks have put brain
power on to address the problem of stray open-and-close  elements.
These seem to be the main problem in the sample you have presented. Again,
there was never an implementation of this, as it would need to essentially
re-import Sword module data to generate the pre- and post- data, and that
went beyond the scope of any work heretofore on BibleTime.

--Greg

On Wed, May 8, 2013 at 2:31 PM, Troy A. Griffitts wrote:

> OK guys,
>
> I'm starting work on this. I've setup a test in our testsuite for
> whitespace against our OSIS reference doc. Here are the links:
>
> test:
> http://crosswire.org/svn/**sword/trunk/tests/osistest.cpp
> (whitespace test added at the end)
>
> OSIS Reference Document:
> http://crosswire.org/svn/**sword/trunk/tests/testsuite/**osisReference.xml
>
> Before I start any work, I want to show what output we get currently. It
> is obviously seriously messed up.
>
> This is from the new XHTML filter set (which is based on the HTMLHREF
> filter set). The first obvious issue is the passthru of the OSIS 
> elements as-is. Anyone like to suggest exactly WHAT they would like as
> output from the XHTML filterset from the OSIS Reference document here?
> Current output below:
>
>
>  Old Testament  osisID="Gen" sID="gen2" type="book"/> THE FIRST BOOK OF MOSES CALLED
> GENESIS  Introduction and
> Outline  This is the Book of Genesis, the first
> book in the Bible. It may be outlined as follows:  
> 1Creation of Heaven and Earth, 1:1-2:4a
> 2Creation of Man and Woman, 2:4b-25 3Fall,
> 3:1-24 ...   Tables work like this:
> Column 1 Label Column 2 Label Column 1, Row 1 Column 2, Row 1
> Column 1, Row 2 Column 2, Row 2 
>  From Creation to Abraham
> (1:1–11:9)
> [ Genesis 1:1 ] In the beginning God created the heaven and the earth.  />
> [ Genesis 1:2 ] Text of verse 2.
>
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Wed, May 8, 2013 at 9:45 AM, Stephan  wrote:

> Greg,
>
>
>  A client-side Sword application could do something similar. I had begun
>> work on such an app at one point. However, in order to fetch data, a
>> native client-side JavaScript implementation would be much better off
>> leveraging the existing technologies - like localStorage and IndexedDB -
>> for local storage and retrieval and downloading the requested materials
>> from a remote server that offered them up in an appropriate format. The
>> Sword format is poorly designed for client-side JavaScript access. But
>> the Sword library, either through bindings into Python or Perl or
>> through directly writing a C-based application or using Java bindings or
>> JSword could easily be made to serve up data in an XML format (imagine
>> that!) or JSON (personally, I believe this is better for web-based
>> transport) which can then be cached on the local side.
>>
>
> My aim is to build an JS app, that is fully a offline app.(maybe you need
> a internet connection to download the sword modules and store them in some
> kind of storae (indexedDB, ...), but you can also do local import). There
> is no need to convert the modules to JSON or XML, since we can access the
> sword format in JS.


If we already have a connection to the server when downloading, why not
allow the server to run the Sword library directly - e.g. through  JSword
or the JNI, Python or Perl bindings of Sword and do the OSIS/GBF/ThML -->
HTML rendering? Then it can pipe that into a JSON or XML for delivery to
the client-side. It can also normalize the encoding to UTF-8. The client
can keep the resulting module data in a standard storage mechanism on its
end for full offline access. That's the structure I was going for.

Then, the client-side needs only to implement some of the basic Sword
functionality, like parsing references and understanding different
versification schemes.


>
>  At that point, though, you're talking about something which is largely a
>> port of Sword into JavaScript rather than just a client. It would need
>> to be capable of understanding and parsing input and transforming that
>> into the appropriate values for a key-value store in order to retrieve
>> the rendered data.
>>
>
> Jpp, it is more like a port to JavaScript. But I don't want to write
> everything from scratch and hope the Emscripten project will do good
> progress =)


I think separating your application into a server doing Sword export and a
client caching the rendered data into its local mechanisms will prevent you
a world of headache.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Wed, May 8, 2013 at 9:37 AM, Stephan  wrote:

> Troy,
>
>
>  Now, having said this, I use javascript+html/css all the time and would
>> like a more native approach to building SWORD applications in this
>> environment, hence a javascript interface via Cordova.
>>
>
> That means you want to write native plugins (sword api wrappers) for every
> supported plattform? Android will rely on JSword and the others on C++ lib,
> right?


No, Android applications can be written in C/C++. There is a limited set of
JNI bindings in place (the core of the Bishop library Troy mentioned
earlier) to facilitate creation of Android apps that rely directly on Sword
instead of on JSword.


> What about Windows Phone? Do we have  C# bindings?
>

Windows Phone 8 apparently uses Silverlight, not C#. I know for a fact we
don't have Silverlight bindings. Several people have undertaken to create
C# wrappers in the past, but I don't believe any of those attempts were
long-lived.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTML5 File API and SWORD modules

[Greg Hellings]

On Wed, May 8, 2013 at 8:30 AM, Troy A. Griffitts wrote:

> Stephan,
>
> Firefox OS is the only platform I know that doesn't allow 'native'
> binaries to be installed and many other platforms all started with this
> same concept and conceded shortly before or after release.  I am confident
> it will change or FirefoxOS will be irrelevant (not necessarily related
> options).  It is my opinion that all programming for all applications in
> the whole world should not be restricted to javascript+html/css.
>
> Now, having said this, I use javascript+html/css all the time and would
> like a more native approach to building SWORD applications in this
> environment, hence a javascript interface via Cordova.
>
> Not sure what you mean by "the web", but there are very few
> client-side-only (only client-side javascript+html/css) applications on
> "the web" (none that I can think of, but I've been told they exist).
>

If you count an application that pulls data from the server, then stores it
locally for access, probably the only semi-prominent one I am aware of is
Amazon's Kindle browser app. It will store data in local browser-side
storage media (e.g. window.localStorage, IndexedDB, or whichever other
choice they went with) for retrieval, reading and viewing on the browser
side.

GMail also has an offline mode for its interface allowing this as well,
where it will queue up messages to be sent, etc in some form of local
storage until a connection is reestablished.

I've heard about other projects built just to demonstrate this technology,
but those are the only two real-life implementations I have heard of. Most
Google Chrome extensions also fit into this category, although they can
leverage C++ libraries by means of the NPAPI and successor interfaces. I
haven't seen any that do so.

A client-side Sword application could do something similar. I had begun
work on such an app at one point. However, in order to fetch data, a native
client-side JavaScript implementation would be much better off leveraging
the existing technologies - like localStorage and IndexedDB - for local
storage and retrieval and downloading the requested materials from a remote
server that offered them up in an appropriate format. The Sword format is
poorly designed for client-side JavaScript access. But the Sword library,
either through bindings into Python or Perl or through directly writing a
C-based application or using Java bindings or JSword could easily be made
to serve up data in an XML format (imagine that!) or JSON (personally, I
believe this is better for web-based transport) which can then be cached on
the local side.

At that point, though, you're talking about something which is largely a
port of Sword into JavaScript rather than just a client. It would need to
be capable of understanding and parsing input and transforming that into
the appropriate values for a key-value store in order to retrieve the
rendered data.

--Greg


>
> When FirefoxOS decides to write their system libraries in javascript, then
> I will respect their decision to not allow other developers to link to
> native libraries. :)
>
> Anyway, all this to say, practically, I hope a Cordova SWORD extension
> will give 95% of the people what they want: the ability to write a SWORD
> application using purely javascript+html/css, and for their application to
> run reasonably well on any platform supported by Cordova.
>
> Hope this is taken lightheartedly,
>
> Troy
>
>
>
> On 05/07/2013 04:34 PM, Stephan wrote:
>
>> Hi,
>>
>>  If it's interesting for your efforts, my plan for extending Bishop is to
>>> make the C++ engine available via Apache Cordova. This is more
>>> attractive now that Cordova has expanded beyond a exclusively a mobile
>>> platform.
>>>
>>
>> But you still need to make a native plugin, right? I thought of making an
>> app for e.g. FirefoxOS or "the web". There you need a pure Javascript
>> solution.
>>
>> --Stephan
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] usfm2osis.py

[Greg Hellings]

On Tue, May 7, 2013 at 12:46 PM, David Haslam  wrote:

> Hi Peter,
>
> Which version of Python did you use it with ?
>
> Has anyone been successful with Python 3.3.x ?
>
> Chris designed it for CPython 2.7+ (but support CPython 3 and other
> interpreters if possible).
>

I used it with CPython 2.7. I believe Chris designed it so it could be run
on Python 3 eventually, but I don't think it is fully compatible yet. Since
2.7 is still the default on most Unix/Linux systems it makes sense to err
on the 2.x side for now.

--Greg


>
> cf. python.org states:
>
> If you don't know which version to use, try Python 3.3. Some existing
> third-party software is not yet compatible with Python 3;
> if you need to use such software, you can download Python 2.7.x instead.
>
> David
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/usfm2osis-py-tp4652232p4652239.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] usfm2osis.py

[Greg Hellings]

It has been a while, but I also used it successfully.

--Greg


On Tue, May 7, 2013 at 7:18 AM, David Haslam  wrote:

> Apart from Chris, has anyone else done any testing on his Python script
> usfm2osis.py ?
>
> See http://crosswire.org/wiki/Converting_SFM_Bibles_to_OSIS#usfm2osis.py
>
> David
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/usfm2osis-py-tp4652232.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] slightly off topic ....

[Greg Hellings]

Barry,

You might try logging in with SSH instead of FTP.

--Greg


On Thu, Apr 25, 2013 at 12:00 PM, Barry Drake  wrote:

> Sorry for off-topic.  I have not needed to log on to the crosswire site
> using ftp for a long time.  I have some spurious folders in my imap mailbox
> and my e-mail client can't delete them, so I tried to log on by ftp as I
> have in the past, but if I try to open ftp on the crosswire.org site
> using my username and password, I get an 'anonymous users only' error.  I
> can log on as anonymous, but obviously can't get to my mailbox   can
> anyone remind me what I put in to log on with a username and password
> please?
>
> God bless,Barry Drake.
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Windows Unicode woes

[Greg Hellings]

On Mon, Apr 15, 2013 at 3:30 PM, Greg Hellings wrote:

> I have hacked and hacked at this. I seem to have something working. If
> people who use Xiphos can test it out with
>
> http://dl.thehellings.com/xiphos-3.1.5-win32-sword-patch.exe (this will
> look a bit uglier than you might be used to as I have built it with an
> unstyled GTK+3 interface rather than the more familiar styled GTK+2 you're
> used to in Windows builds of Xiphos)
>
> while people with a love of the command line can test it out by
> downloading the latest sword-utils from
>
> http://dl.thehellings.com/sword-utils/
>

I've updated the "debug" builds of the utils to actually include the
debugging symbols and a binary build of gdb. If you encounter a problem and
are adept with gdb, you can help me by tracking down where that fault lies.
This effectively doubles or triples the size of those zip files, but for
most of us that won't be a problem (31MB at the largest).

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Windows Unicode woes

[Greg Hellings]

I have hacked and hacked at this. I seem to have something working. If
people who use Xiphos can test it out with

http://dl.thehellings.com/xiphos-3.1.5-win32-sword-patch.exe (this will
look a bit uglier than you might be used to as I have built it with an
unstyled GTK+3 interface rather than the more familiar styled GTK+2 you're
used to in Windows builds of Xiphos)

while people with a love of the command line can test it out by downloading
the latest sword-utils from

http://dl.thehellings.com/sword-utils/

that suit your fancy.

Anyone who wants to see my code can find it on github at
http://github.com/greg-hellings/sword in the util_open branch. Testing on
Linux/Unix/Mac would also be appreciated. I have done a cursory test on all
the major operating systems and I don't appear to have broken basic
functionality.

Testing with paths - especially on Windows - which include non-Unicode
characters would be greatly appreciated. If I get positive feedback on the
behavior of these test binaries I'll make the patch up nice and proper and
submit it in its final form.

The only odd behavior I've noticed is there seems to be occasional
performance pauses while performing file operations. I'm not sure if I'm
just imaginging that or if my patch has occasional performance impacts.
I've also been testing in a VM, so it's entirely possible that I was just
seeing variable system load messing with it.

Please - any feedback, even "it worked for me" and "me too" (or "not for
me") would be most appreciated.

--Greg


On Wed, Feb 6, 2013 at 8:41 AM, Greg Hellings wrote:

> I began porting the GLib wrapper functions for open, mkdir, access, etc
> and stripping out the dependence on Glib-specific functions in order to
> work around the engine's woes with Windows Unicode paths. I filed an API
> bug for it and attached the patch I have so far. It's by no means complete
> and I haven't had the opportunity to test my results on Windows but at
> least it's something.
>
> http://www.crosswire.org/tracker/browse/API-160
>
> A brief look through the bug tracker shows 57 issues that are open against
> the API project. Some of these I know are already resolved but are pending
> 1.7.0 release. Others have patches attached but have gone without comment
> or addressing.
>
> I don't have permissions to do anything about those which are resolved and
> several of those with attached patches I don't have permission to commit
> into the engine. Are any of these bugs the ones still holding up 1.7.0?
>
> --Greg
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword support of indents and line breaks

[Greg Hellings]

On Fri, Apr 12, 2013 at 4:37 PM, Matěj Cepl  wrote:

> My point was that documents are more valuable and more difficult to change
> than programs. So we should orient on perfecting documents and change
> programs if necessary. And yes, possibility of using stylesheets would be
> awesome, but that isn't necessarily the point.
>

The point is
1) His publishers want to control indents
2) Sword doesn't want to give this control through XML
3) Sword does not support stylesheet mechanisms for giving module creators
this control.

Presently, there are some half-way workarounds that are only effective in
some places.

1) Not use OSIS XML but instead use ThML. But this only functions in
HTML-based applications
2) Use the forms of OSIS XML that are mentioned earlier, which are
non-ideal. But this only works in xulsword
3) Change the applications, which is an unfeasible level of effort, as the
number of applications could increase without bound.

This problem has been hashed out many times. There seems to be no
satisfactory method to give publishers the type of control they want. We
can't specify CSS styles, since only some of our applications can parse and
utilize CSS. We can't specify RTF for the same reason. We can't allow XSL
because only JSword uses XSLT on the OSIS whereas Sword uses a stream text
processor that roughly resembles SAX which allows it to work marvelously on
low-memory devices with great success.

In theory the ideal way for us to handle XML sources would be to allow each
application or device to specify an XSLT which is combined with one from
the module to prevent certain output that the target device cannot handle.
But, in practice, this doesn't work very well as not every programming
environment has access to XSLT libraries and some devices can't handle the
large memory overhead needed to load in an XML file that is several MB
(like the one for the KJV), transform it, and write it back out in an
efficient manner.

So we're stuck in an unenviable position of being forced to either suggest
a user select one of these partial hacks or tell people that we can't honor
their request for control over the formatting.

--Greg


>
>
> Blessings,
>
> Matěj
>
>
> --
> http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword support of indents and line breaks

[Greg Hellings]

On Fri, Apr 12, 2013 at 3:14 PM, Matěj Cepl  wrote:

> On 12/04/13 08:04, John Austin wrote:
>
>> Sword should support basic indents and line breaks. Content providers
>> should be able to control the formatting of their texts and should not
>> be required to assign their content to artificial ... or other
>> containers to do so. Although these containers might be useful, the text
>> of some translation styles cannot be fit nicely into them. But often
>> content providers do rightly desire their texts to appear with
>> formatting similar to their printed texts, since this is exactly what
>> the translators deemed easiest to read and understand.
>>
>
> If I may give my 0.02 CZK, I would think that the answer is simple: No.
> This goes against the fundamental rule of XML, which is the separation of
> the content (and structure) from presentation.
>
> All whitespace in XML is collapsible and irrelevant for anything more than
> separating words from each other. If you want your text to look different,
> than please no  elements, no , or other
> abomination like that. We were there (e.g., see whole discussion about
>  element in HTML 3.2) and it was not nice. Elements in XML document
> are just abstract entities without ANY notion of how they are supposed to
> be rendered in the end.
>
> The only thing you should do is to fix your stylesheet or program
> rendering the XML document into whatever output you expect.
>

This is a (debate-ably) good theory.

Sword applications don't allow a module creator to specify a stylesheet,
and those which allow users to specify stylesheets are a world of hurt
because the older code in the Sword filters is not very stylesheet
friendly. Ergo markup is the only avenue open to module creators.

--Greg


>
> Best,
>
> Matěj Cepl
>
> --
> http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword support of indents and line breaks

[Greg Hellings]

On Fri, Apr 12, 2013 at 6:57 AM, John Austin wrote:

> You didn't address my main point: Content providers should be given a way
> to have final control over how their formatted texts appear, and one which
> is simple and reliable. I'll comment below, but a Bible translation is not
> a web-page or an app which might need a new look someday, or a new skin.
> CSS and content abstraction etc. are great ideas, but they should not be
> artificially forced onto Bible publishers. Yes, they should be offered, and
> even encouraged- fine. But publishers should be able to say: "This is
> exactly how I want the formatting, everywhere, any time. Period." I don't
> understand why this expectation is so abhorrent. Offering a handful of
> content abstractions and extensions, all of whose definitions are arguable
> (see below) and likely in flux, is neither simple, nor satisfying to
> content providers who desire control over the presentation of their texts.


You'll find that many people in this list are strongly opposed to giving
content providers any sort of presentational control over their text. This
is unfortunate, but it is the direction Sword is lead in.

If you really want to have presentational control over your text, you can
always encode into ThML. This gives you most of the full range of HTML tags
and allows you to place CSS into a 'style' attribute on elements inherited
from HTML. This style will work great in any Sword applications that use
HTML rendering (Xiphos, BibleTime, BPBible, PocketSword, etc). It will be
stripped and ignored on those few applications which leverage Sword and are
not doing so with HTML-enabled display widgets (The SWORD Project for
Windows, diatheke, etc). I have used this to fine effect to prepare
documents with styles vastly different from what Sword condones.

Getting ThML shoe-horned into a Bible or Commentary module requires you to
use the imp format and place ThML fragments into them. So you can do
something like

$$$Genesis 1:1
In the beginning God created the
heavens and the earth.
$$$Genesis 1:2
And the earth was formless and void

It's obviously not recommended, but it's the only viable workaround I've
encountered to circumvent the proscription against module creators being
allowed to style their modules.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] KJV 1611

[Greg Hellings]

On Thu, Apr 11, 2013 at 3:14 PM, Barnes, Jeffrey wrote:

>
> You mean U+017F? Seems like that would be a pretty easy regex. I think
> it's only a lower case entry that appears only if it is not the last
> character in a word. Any other glyphs?
>

Most attempts I see to use that character replace it with 'f'. This would
make the appropriate regex much more difficult.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] KJV 1611

[Greg Hellings]

I'm unaware of the 1611 being available in SWORD format from anywhere. The
1769 version is what we have in our repositories as it is, by far, the one
most people are thinking of when they claim to be talking about the 1611
version.

If there is a reasonable digital source of the text it should not be
difficult to put it into SWORD format. I doubt there would be strong
objection to making it a module, if the effort were put in to carefully
convert it. I looks like there are many links off the appropriate page
http://www.crosswire.org/wiki/KJV_1611 in the wiki.

--Greg


On Thu, Apr 11, 2013 at 12:29 PM, Barnes, Jeffrey wrote:

> I've seen the objections to the AV on the Crosswire website.
>
> Is there a 1611 Sword module available anywhere? It's interesting to see
> that the OSIS tutorial uses 1611 text.
>
> The poetry and flow of the version I find to be beautiful. It would be
> nice to be able to get it as a Sword module instead of reading someone's
> comments who doesn't appear to appreciate it like I do.
>
> Regards,
> Jeff
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Diatheke Patch (was Re: Next version)

[Greg Hellings]

On Sun, Mar 31, 2013 at 3:35 AM, Chris Little wrote:

> On 3/30/2013 12:54 PM, Greg Hellings wrote:
>
>> There was a patch just the other day to add a few small command-line
>> options to diatheke.
>>
>>  I'd really prefer that this patch not be added, especially not without
> discussion. I see these types of formatting options/decisions as being
> appropriate to post-processing regexes, not changes to a front end.
> Diatheke isn't a text exporter and won't necessarily output in the way that
> is most convenient to your particular unspecified use. If it doesn't work
> for you, filter diatheke's output or write your own tool.


The person proposing this change is writing LaTeX functions that a user can
use to embed scripture quotations directly into the generated files. He is
currently using post-processing regular expressions but these options would
eliminate the possibility of problems with the regular expressions.

Since Diatheke already has quite a few options for changing its formats and
filters, stripping the extra markers seems reasonable for applications like
this one where having a C or C++ file do the exporting might not be
feasible. I don't know the limits of LaTeX and whether a custom exporter
program is feasible, but is there any particular reason to not want changes
to Diatheke?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Next version

[Greg Hellings]

There was a patch just the other day to add a few small command-line
options to diatheke.

I'll also re-iterate my offer to maintain a 1.7 bugfix branch on github and
manage regular releases from that after final is cut, if you would like.

--Greg


On Fri, Mar 29, 2013 at 1:43 PM, Troy A. Griffitts wrote:

> So. Yeah...
>
> I think we have all the 'bugs' fixed now. The last couple things to look
> at hopefully this weekend are spacing issues.
>
> I know we've had a few threads I need to go back and read. What I could
> really use are a couple test cases to improve. Is there anything in our
> testsuite osis doc which causes odd spacing? Can we add something to it if
> not?
>
> Thanks for all the help up to this point. Hoping this is the last stretch.
>
> Troy
>
> Nic Carter  wrote:
>>
>>
>>
>> On 11/03/2013, at 7:16 PM, Troy A. Griffitts 
>> wrote:
>>
>> Soon and very soon. I have no more showstoppers on my list. I'd love to
>> hear feedback from frontends about the state of trunk. Apparently something
>> is broken for Xiphos. Any other feedback?
>>
>>
>> Did you want me to do any more work on the poetry indentation stuff? I
>> can't remember the state we left this in? Perhaps have it a flaggable thing
>> so it's off by default but then frontends can switch it on as they write
>> code to handle it?
>>
>> --
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SWORD + Emscripten = sword.js?

[Greg Hellings]

You could always try bindings/flatapi.cpp. It's a C++ file, but it wraps a
number of extern "C" functions for direct use by a C application. Since you
said your tools work better with C than C++.

--Greg


On Thu, Mar 28, 2013 at 8:10 AM, Stephan  wrote:

> Hi again,
>
>
>  I'll try to clean up my code and add some comments and upload it to
>> github, so somebody can play with it.
>>
>
> Here is the current state and some instructions, how to build swordjs (but
> it is not working at the moment).
>
> https://github.com/zefanja/**swordjs 
>
> I would be glad if someone can help me to build a JS library for sword!
>
>
> Best Regards,
> Stephan
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

Test code: https://gist.github.com/greg-hellings/5218094

Output with your current patch, Troy, is $ g++ `pkg-config --cflags sword`
`pkg-config --libs sword` test.cpp -o test && ./test
intro:  0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro:  0
bk (1): 0
ch (1): 0
vs (1): 0
-
intro:  1
bk (0): 0
ch (0): 0
vs (0): 0
-

The value in parenthsis represents what I thought the value "should" be. If
I comment out line 19, I get this result $ g++ `pkg-config --cflags sword`
`pkg-config --libs sword` test.cpp -o test && ./test
intro:  0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro:  0
bk (1): 1
ch (1): 1
vs (1): 1
-
intro:  1
bk (0): 0
ch (0): 0
vs (0): 0
-

which matches the expected results. So Xiphos is getting around calling
setIntros(1) by instead disabling auto-normalizing. It's odd to me that you
can set a key to a value in the intros while setIntros is false. That
doesn't seem like normalizing to me, that seems more like bounds checking,
but that's not necessarily a bug in the API, possibly it's a bug in my
understanding of intended behavior.

Troy's fix along with shuffling the location of setTestament (a change I
made earlier to Xiphos' Subversion) fixes the known bugs I've seen in
Xiphos regarding chapters not rendering and Genesis 1:1 causing a SegFault.

--Greg



On Thu, Mar 21, 2013 at 6:51 PM, Greg Hellings wrote:

>
>
>
> On Thu, Mar 21, 2013 at 6:26 PM, Troy A. Griffitts 
> wrote:
>
>> Thanks Karl,
>>
>> Yes, each snippet was helpful. Nic's was a quick test which caused the
>> bug and was easy to use for testing. Greg's snippet wasn't as helpful as
>> all his comments and stack traces leading up to his patch. He is preventing
>> book from getting to 0 which does alleviate the problem but also stops a
>> book from becoming an intro. Hope that explains.
>>
>
> If the conditional in my code is changed to
>
> if (book > (intros?0:1) ) {
>
> Then my code corrects the problem that -- was moving a VerseKey from
> Genesis 1:1 to [Testament 1 Intro] when intros is false. While not a
> SegFault producing bug, this is still a bug. Similar checks should be made
> through the same run of code to ensure moving to verse 0 and chapter 0 are
> not possible when intros is false. Both your fix and an adapted form of
> mine should be introduced. Additionally, the issue with OSISFootnotes
> should probably be fixed.
>
> I will write up a simple test case for that, if it helps, once I get back
> to my development machine.
>
> --Greg
>
>
>>
>> Troy
>>
>> Karl Kleinpaste  wrote:
>>>
>>> You didn't also need this snippet from Greg a couple days ago?
>>>
>>> --- src/keys/versekey.cpp (revision 2792)
>>>
>>> +++ src/keys/versekey.cpp (working copy)
>>> @@ -1347,7 +1347,9 @@
>>>}
>>>if (verse < (intros?0:1)) {
>>> if (--chapter < (intros?0:1)) {
>>> - --book;
>>> + if (book > 1) {
>>> +  --book;
>>> + }
>>>
>>>  chapter += (getChapterMax() + (intros?1:0));
>>> }
>>> verse += (getVerseMax() + (intros?1:0));
>>>
>>> --
>>>
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> ___
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

On Thu, Mar 21, 2013 at 6:26 PM, Troy A. Griffitts wrote:

> Thanks Karl,
>
> Yes, each snippet was helpful. Nic's was a quick test which caused the bug
> and was easy to use for testing. Greg's snippet wasn't as helpful as all
> his comments and stack traces leading up to his patch. He is preventing
> book from getting to 0 which does alleviate the problem but also stops a
> book from becoming an intro. Hope that explains.
>

If the conditional in my code is changed to

if (book > (intros?0:1) ) {

Then my code corrects the problem that -- was moving a VerseKey from
Genesis 1:1 to [Testament 1 Intro] when intros is false. While not a
SegFault producing bug, this is still a bug. Similar checks should be made
through the same run of code to ensure moving to verse 0 and chapter 0 are
not possible when intros is false. Both your fix and an adapted form of
mine should be introduced. Additionally, the issue with OSISFootnotes
should probably be fixed.

I will write up a simple test case for that, if it helps, once I get back
to my development machine.

--Greg


>
> Troy
>
> Karl Kleinpaste  wrote:
>>
>> You didn't also need this snippet from Greg a couple days ago?
>>
>> --- src/keys/versekey.cpp (revision 2792)
>> +++ src/keys/versekey.cpp (working copy)
>> @@ -1347,7 +1347,9 @@
>>}
>>if (verse < (intros?0:1)) {
>> if (--chapter < (intros?0:1)) {
>> - --book;
>> + if (book > 1) {
>> +  --book;
>> + }
>>  chapter += (getChapterMax() + (intros?1:0));
>> }
>> verse += (getVerseMax() + (intros?1:0));
>>
>> --
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

I have toyed with changing this on the Xiphos side, setting
key.setIntros(1) before setting the key to 0:0 or 1:0 and rendering. The
key that is used during rendering appears to be a copy of the module's key,
and it does not appear to be preserving the value of the intros parameter.
It seems like this should be a multi-point fix.

1) SWORD should not explode when intros == 0 and the user tries to navigate
to a Genesis {1,0}:0 destination. My previous diff appears to handle that.
2) Xiphos should properly call setIntros(1) before attempting to fetch 1:0
without the user's direct input (e.g. when the user has selected to view
headings & intros). I have a diff in hand for this, but it does not resolve
the problem because...
3) SWORD should properly preserve the value of intros when copying the key
for use during rendering.

--Greg


On Tue, Mar 19, 2013 at 8:26 AM, Greg Hellings wrote:

> The following diff seems to solve the problem. I don't know if it's the
> "correct" way to go about it, but it appears to resolve the issue from what
> I see in Xiphos. I have a feeling the "better" way to do it is to have
> Xiphos set the intros == 1 before attempting to fetch intro material? My
> editor appears to have botched the white space, so please forgive that.
>
> diff --git a/src/keys/versekey.cpp b/src/keys/versekey.cpp
> index 205..0290fd7 100644
> --- a/src/keys/versekey.cpp
> +++ b/src/keys/versekey.cpp
> @@ -1347,7 +1347,9 @@ void VerseKey::normalize(bool autocheck)
> }
> if (verse < (intros?0:1)) {
> if (--chapter < (intros?0:1)) {
> -   --book;
> +if (book > 1) {
> +--book;
> +}
> chapter += (getChapterMax() +
> (intros?1:0));
> }
>     verse += (getVerseMax() + (intros?1:0));
>
>
> On Mon, Mar 18, 2013 at 9:13 PM, Greg Hellings wrote:
>
>>
>>
>>
>> On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts 
>> wrote:
>>
>>>  Thanks Greg,
>>>
>>> Any idea where chapter 17474 is coming from?
>>>
>>> I can add code to check max before looking into the vector, which I'd
>>> rather not because it should be an unnecessary check each time and will be
>>> a speed hit, but even so, who ever is asking for the maximum verse for
>>> chapter 17474 is obviously doing something wrong.
>>>
>>>
>> I'm hardly competent with a C debugger, but let's see what sense I can
>> make of this. Somewhere in VerseKey::parseVerseList on line 944 (#5 in the
>> stack trace) curKey has a value of 17425 for chapter. The text buffer reads
>> "Genesis 1:0" and the value of the chap variable is 1.
>>
>> The value of 17,425 is being set on line 1351 of versekey.cpp when a key
>> value of "Genesis 1:0" is being parsed while intros == 0. This triggers the
>> condition
>>
>> if (verse < (intros?0:1))
>>
>> which causes the resulting block to be executed. Xiphos believes that
>> headings have been enabled here, and Xiphos has always considered
>> 'Headings' and 'Introductions' to be synonymous from my understanding. I
>> know there's been some discussion of the Headings/Intro distinction here
>> lately, so I don't know if Xiphos is now running afoul of changes you made
>> in this distinction due to prior bugs in the implementation that unified
>> them or not?
>>
>> I'm not sure if there's more I can contribute here without a deeper
>> understanding of Xiphos' options and SWORD's parsing.
>>
>> --Greg
>>
>>
>>> I'll try to have a look soon.
>>>
>>> Troy
>>>
>>>
>>>
>>>
>>> On 03/18/2013 05:12 PM, Greg Hellings wrote:
>>>
>>> #1  0x7527724c in sword::VersificationMgr::Book::getVerseMax
>>> (this=0xa60028, chapter=17424)
>>>  at
>>> /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
>>> #2  0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290)
>>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
>>> #3  0x7525b65b in sword::VerseKey::normalize (this=0xdcc290,
>>> autocheck=true)
>>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
>>> #4  0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290,
>>> iverse=0)
>>

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

The following diff seems to solve the problem. I don't know if it's the
"correct" way to go about it, but it appears to resolve the issue from what
I see in Xiphos. I have a feeling the "better" way to do it is to have
Xiphos set the intros == 1 before attempting to fetch intro material? My
editor appears to have botched the white space, so please forgive that.

diff --git a/src/keys/versekey.cpp b/src/keys/versekey.cpp
index 205..0290fd7 100644
--- a/src/keys/versekey.cpp
+++ b/src/keys/versekey.cpp
@@ -1347,7 +1347,9 @@ void VerseKey::normalize(bool autocheck)
}
if (verse < (intros?0:1)) {
if (--chapter < (intros?0:1)) {
-   --book;
+if (book > 1) {
+--book;
+}
chapter += (getChapterMax() +
(intros?1:0));
}
verse += (getVerseMax() + (intros?1:0));


On Mon, Mar 18, 2013 at 9:13 PM, Greg Hellings wrote:

>
>
>
> On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts 
> wrote:
>
>>  Thanks Greg,
>>
>> Any idea where chapter 17474 is coming from?
>>
>> I can add code to check max before looking into the vector, which I'd
>> rather not because it should be an unnecessary check each time and will be
>> a speed hit, but even so, who ever is asking for the maximum verse for
>> chapter 17474 is obviously doing something wrong.
>>
>>
> I'm hardly competent with a C debugger, but let's see what sense I can
> make of this. Somewhere in VerseKey::parseVerseList on line 944 (#5 in the
> stack trace) curKey has a value of 17425 for chapter. The text buffer reads
> "Genesis 1:0" and the value of the chap variable is 1.
>
> The value of 17,425 is being set on line 1351 of versekey.cpp when a key
> value of "Genesis 1:0" is being parsed while intros == 0. This triggers the
> condition
>
> if (verse < (intros?0:1))
>
> which causes the resulting block to be executed. Xiphos believes that
> headings have been enabled here, and Xiphos has always considered
> 'Headings' and 'Introductions' to be synonymous from my understanding. I
> know there's been some discussion of the Headings/Intro distinction here
> lately, so I don't know if Xiphos is now running afoul of changes you made
> in this distinction due to prior bugs in the implementation that unified
> them or not?
>
> I'm not sure if there's more I can contribute here without a deeper
> understanding of Xiphos' options and SWORD's parsing.
>
> --Greg
>
>
>> I'll try to have a look soon.
>>
>> Troy
>>
>>
>>
>>
>> On 03/18/2013 05:12 PM, Greg Hellings wrote:
>>
>> #1  0x7527724c in sword::VersificationMgr::Book::getVerseMax
>> (this=0xa60028, chapter=17424)
>>  at
>> /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
>> #2  0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290)
>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
>> #3  0x7525b65b in sword::VerseKey::normalize (this=0xdcc290,
>> autocheck=true)
>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
>> #4  0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290,
>> iverse=0)
>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523
>> #5  0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0,
>> buf=0xea5e1b "", defaultKey=0x0, expandRange=false,
>> useChapterAsVerse=false) at
>> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944
>> #6  0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0,
>> checkAutoNormalize=true)
>> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293
>> #7  0x004922df in sword::VerseKey::setText (this=0xeb7fa0,
>> ikey=0xd04b20 "Genesis 0:0")
>> at /usr/local/include/sword/versekey.h:210
>> #8  0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0,
>> ikey=0xd04b20 "Genesis 0:0")
>> at /usr/local/include/sword/versekey.h:475
>> #9  0x752df98f in sword::OSISFootnotes::processText
>> (this=0xef4920, text=..., key=0xd14a00, module=0xef9618)
>> at
>> /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65
>> #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618,
>> filters=0xef90b0, buf=..., key=0xd14a00)
>> at /home/ghel

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

On Mon, Mar 18, 2013 at 5:07 PM, Troy A. Griffitts wrote:

>  Thanks Greg,
>
> Any idea where chapter 17474 is coming from?
>
> I can add code to check max before looking into the vector, which I'd
> rather not because it should be an unnecessary check each time and will be
> a speed hit, but even so, who ever is asking for the maximum verse for
> chapter 17474 is obviously doing something wrong.
>
>
I'm hardly competent with a C debugger, but let's see what sense I can make
of this. Somewhere in VerseKey::parseVerseList on line 944 (#5 in the stack
trace) curKey has a value of 17425 for chapter. The text buffer reads
"Genesis 1:0" and the value of the chap variable is 1.

The value of 17,425 is being set on line 1351 of versekey.cpp when a key
value of "Genesis 1:0" is being parsed while intros == 0. This triggers the
condition

if (verse < (intros?0:1))

which causes the resulting block to be executed. Xiphos believes that
headings have been enabled here, and Xiphos has always considered
'Headings' and 'Introductions' to be synonymous from my understanding. I
know there's been some discussion of the Headings/Intro distinction here
lately, so I don't know if Xiphos is now running afoul of changes you made
in this distinction due to prior bugs in the implementation that unified
them or not?

I'm not sure if there's more I can contribute here without a deeper
understanding of Xiphos' options and SWORD's parsing.

--Greg


> I'll try to have a look soon.
>
> Troy
>
>
>
>
> On 03/18/2013 05:12 PM, Greg Hellings wrote:
>
> #1  0x7527724c in sword::VersificationMgr::Book::getVerseMax
> (this=0xa60028, chapter=17424)
>  at
> /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
> #2  0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290)
> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
> #3  0x7525b65b in sword::VerseKey::normalize (this=0xdcc290,
> autocheck=true)
> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
> #4  0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290,
> iverse=0)
> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523
> #5  0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0,
> buf=0xea5e1b "", defaultKey=0x0, expandRange=false,
> useChapterAsVerse=false) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944
> #6  0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0,
> checkAutoNormalize=true)
> at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293
> #7  0x004922df in sword::VerseKey::setText (this=0xeb7fa0,
> ikey=0xd04b20 "Genesis 0:0")
> at /usr/local/include/sword/versekey.h:210
> #8  0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0,
> ikey=0xd04b20 "Genesis 0:0")
> at /usr/local/include/sword/versekey.h:475
> #9  0x752df98f in sword::OSISFootnotes::processText
> (this=0xef4920, text=..., key=0xd14a00, module=0xef9618)
> at
> /home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65
> #10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618,
> filters=0xef90b0, buf=..., key=0xd14a00)
> at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352
> #11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618,
> buf=..., key=0xd14a00)
> at /home/ghellings/Projects-old/sword/include/swmodule.h:622
> #12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618,
> buf=0x0, len=-1, render=true)
> at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826
> #13 0x0049219f in sword::SWModule::operator char const*
> (this=0xef9618) at /usr/local/include/sword/swmodule.h:709
> #14 0x0049e093 in GTKChapDisp::getVerseBefore (this=0xf0b420,
> imodule=...) at ../src/main/display.cc:1130
>
>  When I drill all the way down in, the appear to try and pull the verse
> max for chapter 17424 when asked to render Genesis 0:0.
>
>  --Greg
>
>
>
>>
>>
>>  This segfault only seems to happen when I enter Genesis 1 in the
>> navigation panel and not at any other time. Those with more gdb savvy than
>> I can maybe figure out more of what is going on.
>>
>>  --Greg
>>
>>
>> On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste wrote:
>>
>>> I see that your new showchapter.cpp works.  The only difference in how
>>> that works versus Xiphos code is you changed the VerseKey init slightly,
>>> so I made that change:
>>>
>>> VerseKey *key

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings wrote:

> Troy, Karl,
>
> It should also be noted that this update to SWORD causes a segfault in the
> following code in Xiphos https://gist.github.com/anonymous/5187582
>
> Specifically the line  key->setAutoNormalize(oldAutoNorm); on line 38 of
> that Gist generates a SegFault with the following backtrace.
>
> #0 0x75278ef0 in std::vector >::size
> (this=0x676e6175685a20) at
> /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626
> #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax
> (this=0xa60028, chapter=17424) at
> /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2
> 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3
> 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60,
> autocheck=true) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4
> 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60,
> iautonorm=true) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5
> 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930,
> imodule=...) at ../src/main/display.cc:1138
>

I'm still seeing a SegFault as before, after I fixed the issue with other
text not displaying. However, the offending line is now display.cc:1130
which is lines 30-32 of the code I pasted above. The stack trace looks like
this

#0  0x75278ef0 in std::vector >::size
(this=0x676e6175685a20)
at
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626
#1  0x7527724c in sword::VersificationMgr::Book::getVerseMax
(this=0xa60028, chapter=17424)
at /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241
#2  0x7525aebb in sword::VerseKey::getVerseMax (this=0xdcc290)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243
#3  0x7525b65b in sword::VerseKey::normalize (this=0xdcc290,
autocheck=true)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353
#4  0x7525bbe9 in sword::VerseKey::setVerse (this=0xdcc290,
iverse=0)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1523
#5  0x752596b3 in sword::VerseKey::parseVerseList (this=0xeb7fa0,
buf=0xea5e1b "", defaultKey=0x0, expandRange=false,
useChapterAsVerse=false) at
/home/ghellings/Projects-old/sword/src/keys/versekey.cpp:944
#6  0x752570d8 in sword::VerseKey::parse (this=0xeb7fa0,
checkAutoNormalize=true)
at /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:293
#7  0x004922df in sword::VerseKey::setText (this=0xeb7fa0,
ikey=0xd04b20 "Genesis 0:0")
at /usr/local/include/sword/versekey.h:210
#8  0x00492310 in sword::VerseKey::operator= (this=0xeb7fa0,
ikey=0xd04b20 "Genesis 0:0")
at /usr/local/include/sword/versekey.h:475
#9  0x752df98f in sword::OSISFootnotes::processText (this=0xef4920,
text=..., key=0xd14a00, module=0xef9618)
at
/home/ghellings/Projects-old/sword/src/modules/filters/osisfootnotes.cpp:65
#10 0x75296fec in sword::SWModule::filterBuffer (this=0xef9618,
filters=0xef90b0, buf=..., key=0xd14a00)
at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:1352
#11 0x75297aa1 in sword::SWModule::optionFilter (this=0xef9618,
buf=..., key=0xd14a00)
at /home/ghellings/Projects-old/sword/include/swmodule.h:622
#12 0x75293ea7 in sword::SWModule::renderText (this=0xef9618,
buf=0x0, len=-1, render=true)
at /home/ghellings/Projects-old/sword/src/modules/swmodule.cpp:826
#13 0x0049219f in sword::SWModule::operator char const*
(this=0xef9618) at /usr/local/include/sword/swmodule.h:709
#14 0x0049e093 in GTKChapDisp::getVerseBefore (this=0xf0b420,
imodule=...) at ../src/main/display.cc:1130

When I drill all the way down in, the appear to try and pull the verse max
for chapter 17424 when asked to render Genesis 0:0.

--Greg



>
>
> This segfault only seems to happen when I enter Genesis 1 in the
> navigation panel and not at any other time. Those with more gdb savvy than
> I can maybe figure out more of what is going on.
>
> --Greg
>
>
> On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste wrote:
>
>> I see that your new showchapter.cpp works.  The only difference in how
>> that works versus Xiphos code is you changed the VerseKey init slightly,
>> so I made that change:
>>
>> VerseKey *key = (VerseKey *)imodule.getKey();
>>
>> And yet Xiphos still fails to construct the chapter.  The loop never
>> executes once.  I don't know what to make of it.  I will have to look at
>> it some more.
>>
>> __

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

Also, I just committed a fix that permits Xiphos to display text. The issue
was, after attempting to fetch material from 0:0 and n:0 the restoration
was being done through a call to

setBook
setChapter
setVerse
setTestament

I moved the setTestament to be the first call and text display works
swimmingly. Except I still see the segfault I mentioned in trying to
navigate to Genesis 1:1 in both our KJV and ASVD. Xiphos head SVN should
work for other references now, though.

--Greg


On Mon, Mar 18, 2013 at 9:41 AM, Greg Hellings wrote:

> Troy, Karl,
>
> It should also be noted that this update to SWORD causes a segfault in the
> following code in Xiphos https://gist.github.com/anonymous/5187582
>
> Specifically the line  key->setAutoNormalize(oldAutoNorm); on line 38 of
> that Gist generates a SegFault with the following backtrace.
>
> #0 0x75278ef0 in std::vector >::size
> (this=0x676e6175685a20) at
> /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626
> #1 0x7527724c in sword::VersificationMgr::Book::getVerseMax
> (this=0xa60028, chapter=17424) at
> /home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2
> 0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3
> 0x7525b65b in sword::VerseKey::normalize (this=0x1249a60,
> autocheck=true) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4
> 0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60,
> iautonorm=true) at
> /home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5
> 0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930,
> imodule=...) at ../src/main/display.cc:1138
>
> This segfault only seems to happen when I enter Genesis 1 in the
> navigation panel and not at any other time. Those with more gdb savvy than
> I can maybe figure out more of what is going on.
>
> --Greg
>
>
> On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste wrote:
>
>> I see that your new showchapter.cpp works.  The only difference in how
>> that works versus Xiphos code is you changed the VerseKey init slightly,
>> so I made that change:
>>
>> VerseKey *key = (VerseKey *)imodule.getKey();
>>
>> And yet Xiphos still fails to construct the chapter.  The loop never
>> executes once.  I don't know what to make of it.  I will have to look at
>> it some more.
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

Troy, Karl,

It should also be noted that this update to SWORD causes a segfault in the
following code in Xiphos https://gist.github.com/anonymous/5187582

Specifically the line  key->setAutoNormalize(oldAutoNorm); on line 38 of
that Gist generates a SegFault with the following backtrace.

#0 0x75278ef0 in std::vector >::size
(this=0x676e6175685a20) at
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:626
#1 0x7527724c in sword::VersificationMgr::Book::getVerseMax
(this=0xa60028, chapter=17424) at
/home/ghellings/Projects-old/sword/src/mgr/versificationmgr.cpp:241 #2
0x7525aebb in sword::VerseKey::getVerseMax (this=0x1249a60) at
/home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1243 #3
0x7525b65b in sword::VerseKey::normalize (this=0x1249a60,
autocheck=true) at
/home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1353 #4
0x7525bc85 in sword::VerseKey::setAutoNormalize (this=0x1249a60,
iautonorm=true) at
/home/ghellings/Projects-old/sword/src/keys/versekey.cpp:1548 #5
0x0049e118 in GTKChapDisp::getVerseBefore (this=0xefc930,
imodule=...) at ../src/main/display.cc:1138

This segfault only seems to happen when I enter Genesis 1 in the navigation
panel and not at any other time. Those with more gdb savvy than I can maybe
figure out more of what is going on.

--Greg


On Mon, Mar 11, 2013 at 8:57 PM, Karl Kleinpaste wrote:

> I see that your new showchapter.cpp works.  The only difference in how
> that works versus Xiphos code is you changed the VerseKey init slightly,
> so I made that change:
>
> VerseKey *key = (VerseKey *)imodule.getKey();
>
> And yet Xiphos still fails to construct the chapter.  The loop never
> executes once.  I don't know what to make of it.  I will have to look at
> it some more.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTTPS and crosswire.org

[Greg Hellings]

Most likely the Apache config for the :443 host needs to be updated like
the :80 host is so it hands off execution of jsp files to our servlet
handler. It looks like the :443 hanlder in ssl.conf is very minimal
compared with the :80 handler.

--Greg


On Sat, Mar 16, 2013 at 11:30 AM, DM Smith  wrote:

> I probably can do the work, but I don't know what the change needs to be.
>
> On Mar 16, 2013, at 12:28 PM, Greg Hellings 
> wrote:
>
> Chris, DM, Troy - I think you guys are the only ones who can do anything
> about this. Any chance you could?
>
> --Greg
>
>
> On Sat, Mar 16, 2013 at 11:05 AM, yvand  wrote:
>
>> I drop it.
>>
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>> Instructions to unsubscribe/change your settings at above page
>>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTTPS and crosswire.org

[Greg Hellings]

Chris, DM, Troy - I think you guys are the only ones who can do anything
about this. Any chance you could?

--Greg


On Sat, Mar 16, 2013 at 11:05 AM, yvand  wrote:

> I drop it.
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] breakage in verse management at -r2785?

[Greg Hellings]

On Mon, Mar 11, 2013 at 7:51 PM, Troy A. Griffitts wrote:

> Thanks Karl,
>
> I just checked in a "showchapter.cpp" example here, which I think
> represents your use case:
>
> http://crosswire.org/svn/**sword/trunk/examples/classes/**showchapter.cpp
>
> It seems to work for me with this execution:
>
> ./showchapter jonah.3.1
>
> Could it be the module being used that trips the error?  Or maybe the
> normalization or intros settings on the key?


The latter option seems the most likely. Karl and others have seen this
behavior starting with r2785, which was the big commit you made regarding
the HunKar module's odd behavior in BibleTime when normalization and intros
were present and enabled in certain ways. It's possible that the way Xiphos
accesses the modules is sufficiently different from BibleTime (BT is av11n
aware while Xiphos is not yet) that the code which seems to work OK in
BibleTime breaks in Xiphos now.

--Greg


>
>
> Troy
>
>
>
>
> On 03/12/2013 01:31 AM, Karl Kleinpaste wrote:
>
>> Regrets for not following up until this evening; I can send mail here
>> only from home, being firewalled at the office these days.
>>
>> "Troy A. Griffitts"  writes:
>>
>>> Do you have an idea of how you are using versekey?
>>> When you display a chapter, are you iterating on the key or on the
>>> module?
>>>
>> The essential code is:
>>
>>  VerseKey *key = (VerseKey *)(SWKey *)imodule;
>>  int curVerse = key->getVerse();
>>  int curChapter = key->getChapter();
>>  int curBook = key->getBook();
>>
>>  for (key->setVerse(1);
>>  (key->getBook()== curBook)&&
>>  (key->getChapter() == curChapter) &&
>>  !imodule.popError();
>>  imodule++) {
>>  /* ... lots of hacking based on current key ... */
>>  }
>>
>> I've been wondering literally for years why key is typecast twice, from
>> module through SWKey to VerseKey, but this code predates my presence and
>> there's actually quite a lot that I've learned to accept somewhat
>> uncritically.  If there is a better way to loop through this, by all
>> means re-educate me.
>>
>> --karl
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Sword API-151 bug patch

[Greg Hellings]

Bibletime's sword-svn-compat branch has now been updated with the latest
changes necessary to build so you should be able to test it now.

--Greg


On Sat, Feb 23, 2013 at 11:12 PM, Gary Holmlund wrote:

> Troy,
>
> We currently don't have a BibleTime that is compatible with sword svn. I
> did try the test program that I sent with the bug report. It looks like it
> produces the correct result.
>
> Thanks for the fix.
>
> Gary
>
>
>
> On 02/23/2013 03:59 PM, Troy A. Griffitts wrote:
>
>> Dear Gary,
>>
>> Thank you for reporting this bug and spending the time to pinpoint a
>> place in the code where this error manifests!  Your patch was invaluable to
>> finding the problem.
>>
>> I have committed a fix that I hope resolves this problem.  Can you test
>> svn head and let me know how things work for you?
>>
>> Thank you again for spending the time to hunt this one down.  It was a
>> doozy to find even with your help.  I'd still be hunting without it.  Most
>> appreciated.
>>
>> Troy
>>
>>
>>
>> On 01/31/2013 02:46 AM, Gary Holmlund wrote:
>>
>>> On 12/24/2012 09:00 AM, Gary Holmlund wrote:
>>>
 I have attached a small patch to the Sword API-151 bug. I would
 appreciate someone looking at it and applying it.

 This problem is affecting indexing in BibleTime with certain modules.
 In the example I gave, part of the HunKar module before Malachi can't be
 searched.

 Thanks,

 Gary Holmlund

>>> I am sending a gentle reminder about this defect. We have had another
>>> person run into this today.
>>>
>>> I have solved it and supplied a patch (a 1 character change). I would
>>> like to see it fixed before a sword 1.7 release.
>>>
>>> Gary
>>>
>>> __**_
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/**mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] HTTPS and crosswire.org

[Greg Hellings]

Simply an issue that the HTTPS host in Apache was not configured with the
appropriate handler for JSP files.

--Greg


On Thu, Feb 28, 2013 at 8:01 AM, David Haslam  wrote:

> HTTPS_CrossWire_Screenshot.png
> <
> http://sword-dev.350566.n4.nabble.com/file/n4652025/HTTPS_CrossWire_Screenshot.png
> >
>
> Uploaded screenshot illustrates the issue.
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/HTTPS-and-crosswire-org-tp4652023p4652025.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Bindings cleanups and others

[Greg Hellings]

On Wed, Feb 27, 2013 at 7:05 AM, Troy A. Griffitts wrote:

> Greg,
>
> Can you update the README in the pertinent bindings/ folders to explain
> how to compile the bindings.  All the README files seem to be wrong.  I
> know you didn't write them, but you've been the most visibly proactive on
> the make system and the bindings lately. :)
>

Done!

Also, in regards to your comment in #sword on IRC, you can always test the
configure and build against a Debug configuration with both bindings,
examples and tests by executing 'cmake/build-debug.sh' from the root of
SWORD. It should work as advertised. I just did a fresh build today with
CMake after seeing your message and it worked flawlessly. I'm not sure why
you would have gotten the out of stream error if you were inside of the
build/ subdir.

--Greg


>
> Thanks for any help,
>
> Troy
>
>
>
>
>
> On 08/29/2012 03:41 PM, Greg Hellings wrote:
>
>> I have further cleaned up the building of the Bindings. They are now
>> built and installed along with a single command with everything else.
>> You still specify -DSWORD_BINDINGS="Perl Python" if you want to e.g.
>> build both language bindings at once. Then just a standard make/make
>> install at the library level will also compile and install the
>> bindings.
>>
>> Other improvements:
>> - Previously the bindings would be recompiled every single time you
>> issued a 'make' or 'make install' command. This is no longer the case.
>> It should be a much nicer experience for people who are hacking on the
>> rest of the engine who don't want to fiddle with recompiling the
>> bindings every small change of utility file or the like.
>> - Successfully builds against static libraries. Previously the whole
>> process would just explode if you tried to build using only a static
>> library build. Now the bindings can be built against either static or
>> shared libraries. If you build both libraries with the same command
>> then the bindings will be built against the shared.
>> - Significant cleanup of the CMake rules surrounding the library
>> building. They are now proper subdirectories of the main project
>> instead of some crazy tacked-on addition. This should make it much
>> clearer what is going on in the CMake system.
>>
>> All these improvements apply only to the CMake build process and not
>> to the autotools, although some of the warnings cleanup were changes
>> in the SWIG code itself and will be reflected if you use autotools to
>> build.
>>
>> --Greg
>>
>> On Tue, Aug 28, 2012 at 10:41 PM, Greg Hellings 
>> wrote:
>>
>>> If you're building with CMake you add the flag -DSWORD_BINDINGS="Perl"
>>> to build the Perl bindings. Then after issuing your standard make
>>> command you'll be prompted somewhere in the output with the next step.
>>> After installing SWORD with a sudo make install you need to cd into
>>> bindings/swig/perl and do a 'sudo make install' from there as well.
>>>
>>> It's not quite as clean as it should be, but it works at present.
>>> Report any problems you have with it.
>>>
>>> --Greg
>>>
>>> On Tue, Aug 28, 2012 at 10:37 PM, Andrew Thule 
>>> wrote:
>>>
>>>> Speaking of which, are the Perl bindings automatically generated with
>>>> makes
>>>> or are there additional steps required?  I've had no success either
>>>> finding
>>>> documentation on generating the Perl bindings or in using them
>>>> ~A
>>>>
>>>> On Tuesday, August 28, 2012, Greg Hellings wrote:
>>>>
>>>>> For those of you who don't follow the SVN commit logs I have just
>>>>> cleaned up a couple of compile warnings that the Python and Perl SWIG
>>>>> bindings would throw during the install stage. Most notable changes
>>>>> are removal of the Traversable() and Index() methods on the
>>>>> sword::SWKey class. If you have code that uses those, you should
>>>>> update it to use getTraversable/setTravsable and getIndex/setIndex.
>>>>> These methods have been deprecated in the C++ library for a little
>>>>> while now and were causing the bindings to give deprecation warnings
>>>>> during compile.
>>>>>
>>>>> There were also a few little cleanups of some code internal to the
>>>>> bindings that were producing warnings. The Python bindings are now
>>>>> clean, but the P

Re: [sword-devel] Generated footnote markers in non-Roman modules

[Greg Hellings]

On Tue, Feb 19, 2013 at 9:21 AM, David Haslam  wrote:

> Some Bible modules that are for a language with a non-Roman script do NOT
> have an attribute 'n' value in the OSIS,
> so the automatically generated footnote markers (a, b, c, d, ...) look
> especially bad.
>

That is what the 'n' attribute is for. If the auto-generated footnote
markers look bad, then put in an 'n' attribute to the source OSIS file.

Defaults generally look bad when applied to circumstances outside of their
source default.


>
> If at all possible, we should employ letters from the same script.
>

I don't know of a programmatic method for this, but if there is one it
would probably introduce dependency on another library such as ICU or
similar. Xiphos currently does not require ICU directly and BibleTime tries
to not require it at all by using the built-in Qt libraries for Unicode
handling. But, in general, if users don't like the 'default' behavior they
should use the provided mechanism of the 'n' attribute to change it.


>
> For collaboration projects, this subject should be something to be reviewed
> with the copyright owners and/or Bible translators.
>

And they should provide values for the 'n' attribute.


>
> /This was briefly commented on in a private email concerning the Central
> Kurdish (Sorani NT) module/.
>
> David
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/Generated-footnote-markers-in-non-Roman-modules-tp4651985.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] FTP, JSword and Xiphos

[Greg Hellings]

On Mon, Feb 18, 2013 at 9:54 AM, David Haslam  wrote:

> Even using the Xiphos (Windows) module manager, the ftp connection to the
> Xiphos repo seems to be currently unattainable.
>
> It just displays a blank window.
>
> Is it possible that they've changed the connection details from what's
> documented in
> http://crosswire.org/wiki/Module_Repositories#Xiphos
> ?
>

The host that Xiphos' FTP is hosted on has been flaky of late. I contacted
Karl and he has bounced the service - it should be accessible again.

--Greg


>
> Or is it just a temporary server outage?
>
>
> David
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/FTP-JSword-and-Xiphos-tp4651970p4651973.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] VerseMgr ---> VersificationMgr

[Greg Hellings]

On Sat, Feb 16, 2013 at 8:58 AM, Troy A. Griffitts wrote:

> One last rename for this release.  I've changed the class VerseMgr to
> VersificationMgr.  "VerseMgr" did not communicate well enough the intention
> of the class.  I found myself referring to this class as VersificationMgr
> too often, all to find that I initially named it VerseMgr.  My apologies.
>  Since this is mostly an internal-use class, I haven't tried to think how
> to deprecate an entire class in favor of a new name.  I'm not sure if this
> was exposed to the binding, (it probably shouldn't be), but if so, they
> need to be updated.
>

The CMake scripts have been updated to reflect this change and the SWIG
bindings have been updated as well.

I disagree that having VersificationMgr hidden is wise. While they might
not be necessary for client apps focused on display, it is very reasonable
to have a script try to access this data. My sample av11n.py script in the
repository make such access. Other than BPBible, the bindings serve as the
point of contact for a number of useful scripts which do things that
applications like BPBible, Xiphos, etc are not attempting to do. Access to
the VersificationMgr definitely permits more such access than limiting it.

--Greg


>
> Troy
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Windows Unicode woes

[Greg Hellings]

I began porting the GLib wrapper functions for open, mkdir, access, etc and
stripping out the dependence on Glib-specific functions in order to work
around the engine's woes with Windows Unicode paths. I filed an API bug for
it and attached the patch I have so far. It's by no means complete and I
haven't had the opportunity to test my results on Windows but at least it's
something.

http://www.crosswire.org/tracker/browse/API-160

A brief look through the bug tracker shows 57 issues that are open against
the API project. Some of these I know are already resolved but are pending
1.7.0 release. Others have patches attached but have gone without comment
or addressing.

I don't have permissions to do anything about those which are resolved and
several of those with attached patches I don't have permission to commit
into the engine. Are any of these bugs the ones still holding up 1.7.0?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Updated SWORD utils

[Greg Hellings]

The most recent version of the SWORD utilities build for your favorite
flavor of Windows can be found at

http://dl.thehellings.com/sword-utils/

Download the zip file appropriate to your wants and needs. These should be
updated to r2778 and the 32-bit builds should resolve some outstanding
issues with ICU detection. Let me know if there is trouble with them.

As always, these are built with Xiphos' patch and linked against GLib to
properly handle non-ASCII characters in their paths.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Sun, Jan 20, 2013 at 3:02 PM, Greg Hellings wrote:
>
>
> Additionally, BibleTime's sword-svn-compat branch has been updated to
> build cleanly against this, (excluding the unused variables message I
> mentioned in the other thread).
>
> --Greg
>

On the heels of the second set of deprecations, Xiphos now works again and
you can fetch r or beyond from the repository to solve compatibility
with the new naming scheme. Updating Xiphos is more important than updating
BibleTime as the changes caused Xiphos' build to fail compiling and later
to produce blank module text, both of which r and the latest SWORD fix.
BT's fixes only eliminate warnings.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Xiphos: Checked out revision 4411. (errors)

[Greg Hellings]

On Thu, Jan 24, 2013 at 10:00 PM, Andrew Thule  wrote:

> Thanks Greg .. Ill go looking for the patch .. or perhaps I won't.  Ill
> give it thought.
> It might be best if I keep a working version of Xiphos, allowing for the
> compiler problems, until Karl's updates are merged.
>

I just pushed an update to r which fixes the newest set of deprecations
in SWORD and also fixes the module display issue. You'll need to get the
latest SWORD (these deprecations were just in the past day or three) and
Xiphos.

--Greg


>
> I'm not sure how bad Xiphos withdraw can get ..
> ~A
>
>
> On Thu, Jan 24, 2013 at 10:42 PM, Greg Hellings 
> wrote:
>
>> If you monitored the proper message stream you'd see I have created a
>> patch which attempts to fix this compile problem but introduces a minor
>> display bug in the process (module text will not display at all...).
>>
>> --Greg
>>
>>
>> On Thu, Jan 24, 2013 at 9:39 PM, Andrew Thule wrote:
>>
>>> I was Karl.  Thanks for the heads up.  I look forward to your fixes (no
>>> rush).
>>>
>>> ~A
>>>
>>>
>>> On Thu, Jan 24, 2013 at 9:34 PM, Karl Kleinpaste wrote:
>>>
>>>> If you're trying to build Xiphos against recently updated Sword, it's
>>>> going to be a mess right now.  I'll deal with it by week's end.
>>>>
>>>> ___
>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>>
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CD ISO

[Greg Hellings]

On Fri, Jan 25, 2013 at 5:42 AM, Troy A. Griffitts wrote:

> Dear Frontend Teams,
>
> I'm planning to burn CDs for people (about 60) who have requested them
> (yes, we still get occasional CD requests), and was wondering if you might
> wish to update your stuff in the 'latest' ISO folder here which is the root
> from where we build the ISO.
>
> ftp://ftp.crosswire.org/pub/**sword/iso/latest/
>
> I'll update the modules and clean off the ridiculously archaic blobs of
> whatever.
>

Is your intention for this CD to include software based off of 1.6.2 or
will 1.7 be finished before that for front-ends to target?

--Greg


>
> Historically, we've tried to include installers for Mac, Windows, and
> Linux.  I'm conceding to give up on the Linux software (on the CD), so we
> should probably just remove all of our Linux binary bundles.
>
> These installers should be configured to allow installing of modules from
> the CD.  The InstallMgr class supports installation not just from a remote
> source, but from a local path as well.  If your installers could add the
> root of the CD path as an install source, that would be excellent.
>
> We also try to make things run from the CD if possible.  I know BPBible
> has a 'portable' install for this and some of our other frontends run find
> from the CD as well.  If there is a binary you can place somewhere on the
> CD that, when double clicked, it can start and find it's modules from the
> CD (at least), that would be great.  SWORD looks in the current folder for
> modules, so if you place your binary in the root of the CD, it might just
> magically work.  Otherwise, you could have a subdirectory with your stuff
> and include a sword.conf which specifies a datapath of ../ or something.
>  Just ideas.
>
> You can download the latest ISO image from here so you can locally update
> it and play to test how your stuff works.
>
> ftp://ftp.crosswire.org/pub/**sword/iso/
>
> When you get it working well, if you could update the crosswire.org:
> /home/sword/ftp/**pub/sword/iso/latest/ with your stuff, that would be
> great.  I'm also happy to update the CD autorun splash screens with
> anything you'd like.  Not sure how this works on a Mac, but we launch a
> silly little windows app with buttons to launch each installer.
>
> We could also think about instructions to help people burn this to a thumb
> drive.
>
> Thanks for any help,
>
> Troy
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Question about CMAKE build proceedures

[Greg Hellings]

I have found it usually necessary. It is heavily encouraged in CMake, and
enforced in SWORD's scripts for just that reason, to do a build from
outside of the main source directory in an entirely enclosed environment.

To be truthful, when building with the autofoo toolchain I usually found
the same difficulty and got in the habit of building that from a
subdirectory as well.

In general, you shouldn't need to blow away the directory and start again
unless the CMake files have changed or you want to use different options in
the build process. As the maintainer of the CMake toolchain, I find myself
doing it frequently, but most of the time it shouldn't be necessary. I have
made quite a few changes over the past few months, though, to accommodate a
number of enhancements, usually related to the bindings.

--Greg


On Thu, Jan 24, 2013 at 10:20 PM, Andrew Thule  wrote:

> I'm still fairly new to using CMAKE (but liking it).  I'm finally starting
> to feel comfortable with its use, but still have questions .. so if this is
> a newbie question, sorry.
>
> Using traditional "./configure; make; make install' I could simply grab a
> more recent copy (of sword) via svn and make && make install.
>
> However, I'm finding with CMAKE I have to completely blow away my cmake
> build directory before I "cmake -DSWORD_BINDINGS="Perl Python" ../sword".
> If I don't, I seem to get never ending compiler/build loops.
>
> Is it generally necessary to start with a fresh cmake build directory
> before make && make install?
>
> ~A
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Xiphos: Checked out revision 4411. (errors)

[Greg Hellings]

If you monitored the proper message stream you'd see I have created a patch
which attempts to fix this compile problem but introduces a minor display
bug in the process (module text will not display at all...).

--Greg


On Thu, Jan 24, 2013 at 9:39 PM, Andrew Thule  wrote:

> I was Karl.  Thanks for the heads up.  I look forward to your fixes (no
> rush).
>
> ~A
>
>
> On Thu, Jan 24, 2013 at 9:34 PM, Karl Kleinpaste wrote:
>
>> If you're trying to build Xiphos against recently updated Sword, it's
>> going to be a mess right now.  I'll deal with it by week's end.
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Thu, Jan 24, 2013 at 9:17 AM, ref...@gmx.net  wrote:

>
> FWIW, I am probably the only frequent Perl binding user and I would accept
> whatever is easiest for you. Thanks for doing this. Once the bindings are
> working, I will fix all scripts depending on it
>

Perl and Python bindings should be identical to within the limits of SWIG
to emulate them. I have already submitted the chance that removes all
deprecated methods from the SWIG bindings. If you do an SVN up, you should
get the updated bindings.

To help with your updating, you can find the list of deprecated and removed
functions in bindings/swig/deprecated.i or similar.

--Greg


>
> Peter
> Sent from my HTC
>
>
> ----- Reply message -
> From: "Greg Hellings" 
> To: "SWORD Developers' Collaboration Forum" 
> Subject: [sword-devel] Method Name Normalization
> Date: Thu, Jan 24, 2013 15:55
>
>
>
>
>
> On Sun, Jan 20, 2013 at 5:30 PM, Ben Morgan  wrote:
>
>> Hi Greg,
>>
>> On Mon, Jan 21, 2013 at 6:28 AM, Greg Hellings 
>> wrote:
>>
>>>
>>>
>>>
>>> SWIG bindings now up-to-date.
>>>
>>> Bindings users, please holler if I removed things overzealously.
>>>
>>> I haven't tried it, but I believe that this will break BPBible for
>> example.
>>
>> As the bindings are part of SWORD, I believe it makes sense to mirror the
>> deprecations in the bindings somehow if possible, rather than ignoring the
>> deprecated definitions.
>> I know that's what e.g. wxPython does, but I'm not sure how it does it.
>>
>
> I can't see any way of marking the methods as deprecated using SWIG. A
> Google search has turned up no such evidence that it is even possible.
> While I would like to mark them as deprecated, I think it is more proper
> for there to be no such warnings coming from building the engine. I think
> it would just smack as an issue with building if the engine produced
> warnings that it uses its own deprecation warnings!
>
>
>>
>> Doing this will make it easier to support both SWORD 1..6 and SVN, which
>> I think is desirable until a couple of versions down the road.
>>
>
> Supporting both is not something that either BibleTime or Xiphos is able
> to do at this point, either. In BT we maintain a separate branch for
> compatibility with SWORD while in Xiphos we simply can't make a new release
> until the engine releases. BPBible will probably need to take a similar
> path.
>
> Part of cleaning up warnings from building are to allow the bindings to
> make it into distros. I've cleaned them up enough since 1.6.2 that
> hopefully this release will see at least Dmitrijs and whoever is our Fedora
> maintainer at this point able to build the bindings and include them in the
> distro which ought to allow BPBible to be packaged as well. Previously at
> least Debian was choking on the bindings failing to build due to warnings
> and -Werror flags.
>
> In short, I'd rather keep these out unless there's a way to suppress the
> compile warnings and mark them as deprecated in the SWIG output. If you
> find evidence of that possibility, please let me know.
>
> --Greg
>
>
>>
>> God Bless,
>> Ben
>> -
>>  For I have no pleasure in the death of anyone,
>> declares the Lord God; so turn, and live.”
>> Ezekiel 18:32 (ESV)
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Sun, Jan 20, 2013 at 5:30 PM, Ben Morgan  wrote:

> Hi Greg,
>
> On Mon, Jan 21, 2013 at 6:28 AM, Greg Hellings wrote:
>
>>
>>
>>
>> SWIG bindings now up-to-date.
>>
>> Bindings users, please holler if I removed things overzealously.
>>
>> I haven't tried it, but I believe that this will break BPBible for
> example.
>
> As the bindings are part of SWORD, I believe it makes sense to mirror the
> deprecations in the bindings somehow if possible, rather than ignoring the
> deprecated definitions.
> I know that's what e.g. wxPython does, but I'm not sure how it does it.
>

I can't see any way of marking the methods as deprecated using SWIG. A
Google search has turned up no such evidence that it is even possible.
While I would like to mark them as deprecated, I think it is more proper
for there to be no such warnings coming from building the engine. I think
it would just smack as an issue with building if the engine produced
warnings that it uses its own deprecation warnings!


>
> Doing this will make it easier to support both SWORD 1.6 and SVN, which I
> think is desirable until a couple of versions down the road.
>

Supporting both is not something that either BibleTime or Xiphos is able to
do at this point, either. In BT we maintain a separate branch for
compatibility with SWORD while in Xiphos we simply can't make a new release
until the engine releases. BPBible will probably need to take a similar
path.

Part of cleaning up warnings from building are to allow the bindings to
make it into distros. I've cleaned them up enough since 1.6.2 that
hopefully this release will see at least Dmitrijs and whoever is our Fedora
maintainer at this point able to build the bindings and include them in the
distro which ought to allow BPBible to be packaged as well. Previously at
least Debian was choking on the bindings failing to build due to warnings
and -Werror flags.

In short, I'd rather keep these out unless there's a way to suppress the
compile warnings and mark them as deprecated in the SWIG output. If you
find evidence of that possibility, please let me know.

--Greg


>
> God Bless,
> Ben
> -
>  For I have no pleasure in the death of anyone,
> declares the Lord God; so turn, and live.”
> Ezekiel 18:32 (ESV)
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] bindings/objc build broken

[Greg Hellings]

On Wed, Jan 23, 2013 at 10:30 PM, Barnes, Jeffrey wrote:

>
> On Jan 23, 2013, at 8:31:29PM, Nic Carter  wrote:
>
> > You could also look at the PocketSword source to get another idea of how
> to go about compiling things?
> >
>
> The reason I posted to sword-devel is because they own the broken build.
> Whoever is the objc bindings build maintainer should fix it.
>

Well that's Manfred and Nic (more Manfred from what I see in the commit
logs, but both Pocket Sword and Eloquent are based on getting SWORD to
build in XCode and I know the two have worked together on it), so you've
come to the right place!

--Greg


>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] bindings/objc build broken

[Greg Hellings]

The Obj-C bindings have not been updated since Troy's major commit to
deprecate methods and the like. However, the error you're seeing appears to
be a result of missing some of the autofoo material that you need. Do you
have any information on the state of your autotools package? That might
help the Obj-C maintainer with your problem.

--Greg


On Wed, Jan 23, 2013 at 7:38 AM, Jeff Barnes  wrote:

> Did a fresh checkout of https://crosswire.org/svn/sword/trunk. Changed to
> bindings/objc.
>
> 1) The bindings/objc/README instructions are inaccurate. There is no
> Makefile in build_sword.
> 2) The build breaks in build_sword/build_mac_sword.sh.
>
> $ cd build_clucene
>
> $ make release-fat
> ...
> looks like successful build for 3 platforms
>
> $ cd ../build_sword
> $ ./build_mac_sword.sh -a fat -c
>
> ...
>
> ./configure: line 15671: syntax error near unexpected token `CLUCENE2,'
> ./configure: line 15671: `PKG_CHECK_MODULES(CLUCENE2, libclucene-core >=
> 2.3,,true)'
>
> $ pkg-config --cflags --libs libclucene-core
> -I/usr/local/include -I/usr/local/include/CLucene/ext  -L/usr/local/lib/
> -lclucene-core
>
> $ which pkg-config
> /usr/bin/pkg-config
>
>   System Version:Mac OS X 10.6.8 (10K549)
> ...
>   Model Name:MacBook Pro
>   Model Identifier:MacBookPro6,2
>   Processor Name:Intel Core i5
>
> Any help appreciated.
>
> Jeff
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Tue, Jan 22, 2013 at 12:16 PM, Andrew Thule  wrote:

> To add .. the cmake build works, it is only the traditional
> ./configure;make;make install that appears broken.
>

If you run the cmake toolchain with "make VERBOSE=1" do the commands have
-Werror -Wall enabled? If not, try running cmake with the flag
SWORD_ENABLE_WARNINGS set to "Yes" and build again.

And please be more specific when you say "appears broken". Plenty of us
have built with this commit without it being broken, so we need more
information about what you mean.

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Trends in mobile platforms

[Greg Hellings]

If QML refers to the methods and libraries, etc used by Qt development,
then your work would integrate well with BibleTime. Our application is
written in Qt and we would like to eventually separate the lower half of
our application from the presentation layer so that we can target multiple
form-factors of applications from a shared code base that would handle
direct interaction with the SWORD code.

--Greg


On Mon, Jan 21, 2013 at 6:51 AM, Israel  wrote:

> I am new to the developers list here, and David has written about the
> whole reason I have joined.  I have begun familiarizing myself with QML,
> the language the Ubuntu Phone apps are written in.  I would like to begin
> work on a sword app for the Ubuntu Phone UI, and as such I thought I should
> subscribe here, so I can get help if I need it, and see if anyone is
> already working on that very same idea.
> -Israel
>
>
> On 01/21/2013 05:11 AM, David Haslam wrote:
>
>> Further information at 
>> http://www.ubuntu.com/devices/**phone
>>
>> David
>>
>>
>>
>> --
>> View this message in context: http://sword-dev.350566.n4.**
>> nabble.com/Trends-in-mobile-**platforms-tp4651673p4651723.**html
>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> --
> Regards
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Sun, Jan 20, 2013 at 1:28 PM, Greg Hellings wrote:

>
>
>
> On Sat, Jan 19, 2013 at 10:13 AM, Troy A. Griffitts 
> wrote:
>
>> In anticipation of a new release, I have a large checkin I'm about to
>> commit which will break everything for everyone compiling with -Werror.
>>
>> We've been normalizing method names toward a clean API interface at 2.0.
>>  SWORD started 20+ years ago when there was not standard naming
>> conventions.  In fact, originally we tried to keep variable names less than
>> 8 characters, as, at the time, some compilers stopped disambiguating after
>> this.  Besides these, there are a number of conventions we used back then
>> for which standards have now become the norm: camelCase conventions,
>> standard set/getProperty naming, and the like.  We've been slowly moving
>> toward these changes and have been deprecating old names for a few years
>> now.  What I'm about to introduces standard names for all methods within
>> the SWKey and SWModule classes and deprecates the non standard names.
>>
>> A few not obvious changes:
>>
>> Headings() has been renamed to setIntros(bool) and bool isIntros()
>> Headings() -- used to turn on chapter, book, testament, and module
>> introductions, has frequently been a point of confusion with the global
>> option "Headings" -- used to turn on and off section headings in the text.
>>  This new property name will hopefully remove that confusion.
>>
>> Error() has become popError(), as the functionality has always been to
>> return and clear any error code for the object.
>>
>> The bindings are probably in a state of disarray now.  I've updated the
>> omniorb bindings.  I'd appreciated any help with other stuff.
>
>
Additionally, BibleTime's sword-svn-compat branch has been updated to build
cleanly against this, (excluding the unused variables message I mentioned
in the other thread).

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Sat, Jan 19, 2013 at 10:13 AM, Troy A. Griffitts wrote:

> In anticipation of a new release, I have a large checkin I'm about to
> commit which will break everything for everyone compiling with -Werror.
>
> We've been normalizing method names toward a clean API interface at 2.0.
>  SWORD started 20+ years ago when there was not standard naming
> conventions.  In fact, originally we tried to keep variable names less than
> 8 characters, as, at the time, some compilers stopped disambiguating after
> this.  Besides these, there are a number of conventions we used back then
> for which standards have now become the norm: camelCase conventions,
> standard set/getProperty naming, and the like.  We've been slowly moving
> toward these changes and have been deprecating old names for a few years
> now.  What I'm about to introduces standard names for all methods within
> the SWKey and SWModule classes and deprecates the non standard names.
>
> A few not obvious changes:
>
> Headings() has been renamed to setIntros(bool) and bool isIntros()
> Headings() -- used to turn on chapter, book, testament, and module
> introductions, has frequently been a point of confusion with the global
> option "Headings" -- used to turn on and off section headings in the text.
>  This new property name will hopefully remove that confusion.
>
> Error() has become popError(), as the functionality has always been to
> return and clear any error code for the object.
>
> The bindings are probably in a state of disarray now.  I've updated the
> omniorb bindings.  I'd appreciated any help with other stuff.
>

SWIG bindings now up-to-date.

Bindings users, please holler if I removed things overzealously.

--Greg


>
> I hope this doesn't cause too much of a headache for everyone.  I hope
> these naming standards raise coherence to the look of our API for newcomers.
>
> Hope you are all at the start of a blessed new year,
>
> Troy
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

Attached is a patch (I don't think I have commit privileges to that
directory? If so, I can commit it directly.).

--Greg


On Sun, Jan 20, 2013 at 12:00 PM, Greg Hellings wrote:

> Building the library (with CMake) now I get many warnings coming from
> examples/cmdline. Among those I get the following errors:
> /home/greg/Source/sword/examples/cmdline/threaded_search.cpp:101:
> undefined reference to `sword::VerseKey::ParseVerseList(char const*, char
> const*, bool, bool)'
> collect2: error: ld returned 1 exit status
> /home/greg/Source/sword/examples/cmdline/verserangeparse.cpp:48: undefined
> reference to `sword::VerseKey::ParseVerseList(char const*, char const*,
> bool, bool)'
> collect2: error: ld returned 1 exit status
> /home/greg/Source/sword/examples/cmdline/search.cpp:102: undefined
> reference to `sword::VerseKey::ParseVerseList(char const*, char const*,
> bool, bool)'
> collect2: error: ld returned 1 exit status
>
> It looks like this has become parseVerseList now and you just missed those
> couple of places.
>
> --Greg
>
>
> On Sat, Jan 19, 2013 at 10:13 AM, Troy A. Griffitts 
> wrote:
>
>> In anticipation of a new release, I have a large checkin I'm about to
>> commit which will break everything for everyone compiling with -Werror.
>>
>> We've been normalizing method names toward a clean API interface at 2.0.
>>  SWORD started 20+ years ago when there was not standard naming
>> conventions.  In fact, originally we tried to keep variable names less than
>> 8 characters, as, at the time, some compilers stopped disambiguating after
>> this.  Besides these, there are a number of conventions we used back then
>> for which standards have now become the norm: camelCase conventions,
>> standard set/getProperty naming, and the like.  We've been slowly moving
>> toward these changes and have been deprecating old names for a few years
>> now.  What I'm about to introduces standard names for all methods within
>> the SWKey and SWModule classes and deprecates the non standard names.
>>
>> A few not obvious changes:
>>
>> Headings() has been renamed to setIntros(bool) and bool isIntros()
>> Headings() -- used to turn on chapter, book, testament, and module
>> introductions, has frequently been a point of confusion with the global
>> option "Headings" -- used to turn on and off section headings in the text.
>>  This new property name will hopefully remove that confusion.
>>
>> Error() has become popError(), as the functionality has always been to
>> return and clear any error code for the object.
>>
>> The bindings are probably in a state of disarray now.  I've updated the
>> omniorb bindings.  I'd appreciated any help with other stuff.
>>
>> I hope this doesn't cause too much of a headache for everyone.  I hope
>> these naming standards raise coherence to the look of our API for newcomers.
>>
>> Hope you are all at the start of a blessed new year,
>>
>> Troy
>>
>>
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>> Instructions to unsubscribe/change your settings at above page
>>
>
>


04-big-refactor-examples.patch
Description: Binary data
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

Building the library (with CMake) now I get many warnings coming from
examples/cmdline. Among those I get the following errors:
/home/greg/Source/sword/examples/cmdline/threaded_search.cpp:101: undefined
reference to `sword::VerseKey::ParseVerseList(char const*, char const*,
bool, bool)'
collect2: error: ld returned 1 exit status
/home/greg/Source/sword/examples/cmdline/verserangeparse.cpp:48: undefined
reference to `sword::VerseKey::ParseVerseList(char const*, char const*,
bool, bool)'
collect2: error: ld returned 1 exit status
/home/greg/Source/sword/examples/cmdline/search.cpp:102: undefined
reference to `sword::VerseKey::ParseVerseList(char const*, char const*,
bool, bool)'
collect2: error: ld returned 1 exit status

It looks like this has become parseVerseList now and you just missed those
couple of places.

--Greg


On Sat, Jan 19, 2013 at 10:13 AM, Troy A. Griffitts wrote:

> In anticipation of a new release, I have a large checkin I'm about to
> commit which will break everything for everyone compiling with -Werror.
>
> We've been normalizing method names toward a clean API interface at 2.0.
>  SWORD started 20+ years ago when there was not standard naming
> conventions.  In fact, originally we tried to keep variable names less than
> 8 characters, as, at the time, some compilers stopped disambiguating after
> this.  Besides these, there are a number of conventions we used back then
> for which standards have now become the norm: camelCase conventions,
> standard set/getProperty naming, and the like.  We've been slowly moving
> toward these changes and have been deprecating old names for a few years
> now.  What I'm about to introduces standard names for all methods within
> the SWKey and SWModule classes and deprecates the non standard names.
>
> A few not obvious changes:
>
> Headings() has been renamed to setIntros(bool) and bool isIntros()
> Headings() -- used to turn on chapter, book, testament, and module
> introductions, has frequently been a point of confusion with the global
> option "Headings" -- used to turn on and off section headings in the text.
>  This new property name will hopefully remove that confusion.
>
> Error() has become popError(), as the functionality has always been to
> return and clear any error code for the object.
>
> The bindings are probably in a state of disarray now.  I've updated the
> omniorb bindings.  I'd appreciated any help with other stuff.
>
> I hope this doesn't cause too much of a headache for everyone.  I hope
> these naming standards raise coherence to the look of our API for newcomers.
>
> Hope you are all at the start of a blessed new year,
>
> Troy
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Extra warnings

[Greg Hellings]

I don't know if you fixed this in this week's super-commit, as I'm just
about to try and build BibleTime against that, but
InstallMgr::getCipherCode has long been throwing the pair of warnings
"unused parameter `modName'" and "unused parameter `config'" because it is
defined with the method body "{ return false; }".

Is there a way to handle this differently - either implement it as a pure
virtual or work it around to not throw these errors?

--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] XHTML Filterset

[Greg Hellings]

On Sun, Jan 20, 2013 at 3:43 AM, Jonathan Morgan wrote:

> Hi Greg,
>
> On Sun, Jan 20, 2013 at 3:52 AM, Greg Hellings wrote:
>
>>
>>
>>
>> On Sat, Jan 19, 2013 at 10:28 AM, Troy A. Griffitts > > wrote:
>>
>>> I've done my part and changed one more tag.  transChange has been
>>> upgraded from:
>>> 
>>>
>>> to:
>>>
>>> .transChangeSupplied {
>>>   font-style: italic;
>>> }
>>>
>>> 
>>>
>>> More changes welcome.
>>>
>>> Nic, you mentioned doing similar work on your own copies of our filters.
>>>  Any experience you'd like to share?
>>>
>>> Bibletime, same.  I know you guys have had stuff styled for quite some
>>> time.
>>>
>>
>> BT outputs the following (found on lines 383ff of
>> src/backend/filters/osistohtml.cpp):
>>  .. 
>>
>> where **type** is the value of the type attribute of transChange. If no
>> type attribute is specified, the value of the changeType attribute is used.
>> If the type or changeType attribute of transChange is equal to "added" then
>> the outer span gets a title="Added text" and if it is equal to
>> "tenseChange" it gets a title="Verb tense changed" added to it.
>>
>
> Would you really want a title to be output for this?  It seems very
> specific markup, quite different from the "class based" markup, and also
> raises the questions "How do we change the text displayed for a transChange?
>

I'm thinking we may have gotten our wires crossed in that line. The title
is not instead of the class but in addition to. So a  is replaced with **textual content of
original**

So the CSS still works as intended. Granted, you can set CSS selectors on
arbitrary attributes with XPath-inspired syntax if you have a new enough
rendering engine, which both BibleTime and Xiphos have at this time. Based
on the code, I'm guessing this handling was originally limited to only
added and tenseChange and later people just got a little lazy with it and
didn't add in those titles.


>   Or translate it?
>

It's translated the same way every other UI string in BibleTime is
translated.

buf.append("");


> Or show it in some other way than a tooltip?"
>

At least in the QtWebKit bindings, you can listen in on mouseover/hover
events and pull out the text of the elements to display it however you want.

Also, to be clear, I wasn't suggesting that this BT code is /the way to
go/, I was just answering Troy's question about how do those frontends
which customize their HTML renderers handle the transChange element by
telling him what the BT code does for the sake of comparison and discussion.

--Greg


>
> Jon
>
>
>>
>> Only some of our styles have CSS associated with the .transchange, but
>> those which do have font-style=italic.
>>
>> Looking at the particular C++ code, I see a very straightforward
>> simplification we could do for it, so I'll probably simplify that logic
>> down.
>>
>> --Greg
>>
>>
>>>
>>> Would ultimately like to get this filter set to something we all can
>>> share and improve.
>>>
>>> Troy
>>>
>>>
>>>
>>> __**_
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Method Name Normalization

[Greg Hellings]

On Sat, Jan 19, 2013 at 12:31 PM, Peter von Kaehne  wrote:

> On Sat, 2013-01-19 at 17:13 +0100, Troy A. Griffitts wrote:
> >
> > Headings() has been renamed to setIntros(bool) and bool isIntros()
> > Headings() -- used to turn on chapter, book, testament, and module
> > introductions, has frequently been a point of confusion with the global
> > option "Headings" -- used to turn on and off section headings in the
> > text.  This new property name will hopefully remove that confusion.
>
> Does this mean that headings and intros are now formally separated?
> Right now both are turned on jointly, while a more natural way would be
> to turn on headings and turn on intros separately of each other - maybe
> making latter dependent on former, but former should be possible without
> sudden appearance of huge intro paragraphes.
>

I can only speak about Xiphos and BibleTime, as those are the only two I
have used: Xiphos you still have to request the 0'th chapter in order to
see the introduction, and with BibleTime, the window is pre-scrolled past
the Headings and the user needs to scroll back to read them if they want
to. I was thrown off the first time I was looking for module header
information in BT because the module window was scrolled beyond it.

--Greg


>
> Peter
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

On Tue, Jan 8, 2013 at 2:39 PM, Greg Hellings wrote:

> Thanks! I updated CMake as we talked about.
>
> The current SVN HEAD of Xiphos now has support for adding SFTP sources
> through its module manager. Shout-out to Karl (or whoever wrote that
> dialog) for making the code there very straightforward. Just adding a
> source with type "SFTP" in Xiphos' module manager will create the
> necessary entry in InstallMgr.conf and any SFTP sources that SWORD
> reports will act normally.
>

I've also added the ability to create/modify HTTP, HTTPS and SFTP
transports to BibleTime, although it still lacks the ability to specify a
username or password. Support can be found in the branch sword-svn-compat
from the BibleTime repositories. However, it probably will not compile if
your build of SWORD has Troy's check in from earlier this morning.

--Greg


>
> Note that SWORD will silently and harmlessly ignore any
> InstallMgr.conf entries that are SFTPSource entries if it was compiled
> without SFTP support.
>
> --Greg
>
> On Sun, Jan 6, 2013 at 1:29 PM, Troy A. Griffitts 
> wrote:
> > Applied.  Thanks Greg, for the original contribution and for taking the
> time
> > to work through the details.
> >
> >
> > On 12/31/2012 03:53 PM, Greg Hellings wrote:
> >
> > Here is the updated patch adding CURLSFTPAVAILABLE support to CMake as
> > well as to the library code. It defaults to assuming no SFTP support
> > if either the curl-config executable cannot be found or if it returns
> > a value other than "1" from the quick detection process we have
> > settled on.
> >
> > Users of Windows builds through either VisualStudio or Borland will
> > need to figure out if curl-config is available on their systems and,
> > if not, come up with another way to detect and support SFTP for
> > clients using those builds. On Linux it is a Bash script, so it might
> > be adaptable to Manfred's XCode system in some way also.
> >
> > For those in the JSword world, I am sure there are SFTP Java clients
> > available which could be leveraged if they wanted to add support for
> > the same functionality to JSword applications.
> >
> > --Greg
> >
> > On Sun, Dec 30, 2012 at 9:11 PM, Troy A. Griffitts  >
> > wrote:
> >
> > OK Greg,
> >
> > I've hacked detection of CURL SFTP into the autotools build (hopefully--
> it
> > works for me).
> >
> > I've added a new compile time define with -DCURLSFTPAVAILABLE to go along
> > with the existing -DCURLAVAILABLE
> >
> > If you'd like to update the sftp patch to conditionally compile support
> in
> > based on this define, that would be cool.  I'll do it myself soon if you
> > don't have time.
> >
> > Troy
> >
> >
> >
> > On 12/28/2012 11:42 AM, Greg Hellings wrote:
> >
> > Further digging with help from our friends has revealed this nugget:
> >
> > $ curl-config --protocols
> >
> > produces a newline-delimited list of protocols that the particular
> > build of libcurl supports. curl-config is a shell script which can be
> > run on the build system and should satisfy both the requirements of
> > native builds and cross-compiling support. We could use this to set a
> > compiler macro indicating support (or not) for SFTP in the target
> > libcurl library.
> >
> > If someone wants to tackle that in the autotools world, I can add
> > detection to CMake as well. A simple command such as
> > $ curl-config --protocols | grep SFTP | wc -l
> > 1
> >
> > in Fedora will result in a value of 1 or greater if SFTP is supported
> > while it should produce 0 if SFTP support is left out. An Ubuntu
> > system produce this output:
> > $ curl-config --protocols | grep SFTP | wc -l
> > 0
> >
> > And it even works for cross-compiling:
> > $ /usr/i686-w64-mingw32/sys-root/mingw/bin/curl-config --protocols |
> > grep SFTP | wc -l
> > 1
> >
> >
> > This appears to be our best way forward if we want to enable
> > compile-time enabling or disabling of this option.
> >
> > --Greg
> >
> > On Mon, Dec 24, 2012 at 8:43 AM, Greg Hellings 
> > wrote:
> >
> > Troy,
> >
> > On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
> >  wrote:
> >
> > Dear Greg,
> >
> > Looking to apply this SFTP patch, could you give me some background as
> > to
> > why the check to ignore across all transports for '.' and '..'?
> >
> > Our downloading method runs recursiv

Re: [sword-devel] XHTML Filterset

[Greg Hellings]

On Sat, Jan 19, 2013 at 10:28 AM, Troy A. Griffitts wrote:

> I've done my part and changed one more tag.  transChange has been upgraded
> from:
> 
>
> to:
>
> .transChangeSupplied {
>   font-style: italic;
> }
>
> 
>
> More changes welcome.
>
> Nic, you mentioned doing similar work on your own copies of our filters.
>  Any experience you'd like to share?
>
> Bibletime, same.  I know you guys have had stuff styled for quite some
> time.
>

BT outputs the following (found on lines 383ff of
src/backend/filters/osistohtml.cpp):
 .. 

where **type** is the value of the type attribute of transChange. If no
type attribute is specified, the value of the changeType attribute is used.
If the type or changeType attribute of transChange is equal to "added" then
the outer span gets a title="Added text" and if it is equal to
"tenseChange" it gets a title="Verb tense changed" added to it.

Only some of our styles have CSS associated with the .transchange, but
those which do have font-style=italic.

Looking at the particular C++ code, I see a very straightforward
simplification we could do for it, so I'll probably simplify that logic
down.

--Greg


>
> Would ultimately like to get this filter set to something we all can share
> and improve.
>
> Troy
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Fwd: automake issue under Arch Linux

[Greg Hellings]

On Tue, Jan 15, 2013 at 11:06 AM, Stefan Husmann  wrote:

> Am 15.01.2013 17:44, schrieb Greg Hellings:
>
>> Stefan,
>>
>> Does this patch affect the ability of SWORD to compile with the help of
>> older versions of automake, or does it break the older stuff?
>>
>> --Greg
>>
>>
>> On Tue, Jan 15, 2013 at 10:35 AM, Stefan Husmann <
>> stefan-husm...@t-online.de
>>
>>> wrote:
>>>
>>
>>
>>> Betreff: automake issue under Arch Linux
>>> Datum: Sun, 13 Jan 2013 13:12:28 +0100
>>> Von: Stefan Husmann 
>>> An: sword-devel@crosswire.org
>>>
>>> Hello,
>>>
>>> this is my first post here, and if it has been brought up already
>>> -- I only searched in January and december's mail archives --, I
>>> apologize.
>>>
>>> I am building the sword library from the svn sources and have had
>>> problems
>>> with aclocal coming with automake 1.13.1.
>>>
>>> The simple patch at 
>>> http://paste.pound-python.org/show/29082/<http://paste.pound-python.org/**show/29082/>
>>> <http://paste.**pound-python.org/show/29082/<http://paste.pound-python.org/show/29082/>
>>> >**solves this.
>>>
>>>
>>> Please consider it.
>>>
>>> Best Regards Stefan Husmann
>>>
>>>
>>>
>>> ___
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel<http://www.crosswire.org/**mailman/listinfo/sword-devel>
>>> http://www.crosswire.org/mailman/listinfo/sword-devel>
>>> >
>>>
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
>>
>>
>> __**_
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>> Instructions to unsubscribe/change your settings at above page
>>
>>  Greg,
>
> according to http://forum.world.st/PATCH-**build-don-t-use-obsolescent-**
> AM-PROG-CC-STDC-and-AM-CONFIG-**HEADER-td4630038.html<http://forum.world.st/PATCH-build-don-t-use-obsolescent-AM-PROG-CC-STDC-and-AM-CONFIG-HEADER-td4630038.html>the
>  variable AM_CONFIG_HEADER is deprcated since 2002.
>
> According to 
> http://www.mail-archive.com/**autom...@gnu.org/msg18202.html<http://www.mail-archive.com/automake@gnu.org/msg18202.html>INCLUDES
>  is obsolete since 2003, but in this case only a warning, not a
> failure, is given by automake 1.13.1.
>

I imagine a decade worth of deprecation is probably sufficient to put it
out of the requirements of SWORD's targetted support. I believe we usually
compare againt any LTS versions of Ubuntu, current Debian and RHEL as our
benchmarks for "old enough". AFAIK all of those fall within the past decade
with at least one release!

--Greg


>
> I did not test it, though.
>
> Best Regards Stefan
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Fwd: automake issue under Arch Linux

[Greg Hellings]

Stefan,

Does this patch affect the ability of SWORD to compile with the help of
older versions of automake, or does it break the older stuff?

--Greg


On Tue, Jan 15, 2013 at 10:35 AM, Stefan Husmann  wrote:

>
> Betreff: automake issue under Arch Linux
> Datum: Sun, 13 Jan 2013 13:12:28 +0100
> Von: Stefan Husmann 
> An: sword-devel@crosswire.org
>
> Hello,
>
> this is my first post here, and if it has been brought up already
> -- I only searched in January and december's mail archives --, I apologize.
>
> I am building the sword library from the svn sources and have had problems
> with aclocal coming with automake 1.13.1.
>
> The simple patch at 
> http://paste.pound-python.org/**show/29082/solves
>  this.
>
> Please consider it.
>
> Best Regards Stefan Husmann
>
>
>
> __**_
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/**mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

Thanks! I updated CMake as we talked about.

The current SVN HEAD of Xiphos now has support for adding SFTP sources
through its module manager. Shout-out to Karl (or whoever wrote that
dialog) for making the code there very straightforward. Just adding a
source with type "SFTP" in Xiphos' module manager will create the
necessary entry in InstallMgr.conf and any SFTP sources that SWORD
reports will act normally.

Note that SWORD will silently and harmlessly ignore any
InstallMgr.conf entries that are SFTPSource entries if it was compiled
without SFTP support.

--Greg

On Sun, Jan 6, 2013 at 1:29 PM, Troy A. Griffitts  wrote:
> Applied.  Thanks Greg, for the original contribution and for taking the time
> to work through the details.
>
>
> On 12/31/2012 03:53 PM, Greg Hellings wrote:
>
> Here is the updated patch adding CURLSFTPAVAILABLE support to CMake as
> well as to the library code. It defaults to assuming no SFTP support
> if either the curl-config executable cannot be found or if it returns
> a value other than "1" from the quick detection process we have
> settled on.
>
> Users of Windows builds through either VisualStudio or Borland will
> need to figure out if curl-config is available on their systems and,
> if not, come up with another way to detect and support SFTP for
> clients using those builds. On Linux it is a Bash script, so it might
> be adaptable to Manfred's XCode system in some way also.
>
> For those in the JSword world, I am sure there are SFTP Java clients
> available which could be leveraged if they wanted to add support for
> the same functionality to JSword applications.
>
> --Greg
>
> On Sun, Dec 30, 2012 at 9:11 PM, Troy A. Griffitts 
> wrote:
>
> OK Greg,
>
> I've hacked detection of CURL SFTP into the autotools build (hopefully-- it
> works for me).
>
> I've added a new compile time define with -DCURLSFTPAVAILABLE to go along
> with the existing -DCURLAVAILABLE
>
> If you'd like to update the sftp patch to conditionally compile support in
> based on this define, that would be cool.  I'll do it myself soon if you
> don't have time.
>
> Troy
>
>
>
> On 12/28/2012 11:42 AM, Greg Hellings wrote:
>
> Further digging with help from our friends has revealed this nugget:
>
> $ curl-config --protocols
>
> produces a newline-delimited list of protocols that the particular
> build of libcurl supports. curl-config is a shell script which can be
> run on the build system and should satisfy both the requirements of
> native builds and cross-compiling support. We could use this to set a
> compiler macro indicating support (or not) for SFTP in the target
> libcurl library.
>
> If someone wants to tackle that in the autotools world, I can add
> detection to CMake as well. A simple command such as
> $ curl-config --protocols | grep SFTP | wc -l
> 1
>
> in Fedora will result in a value of 1 or greater if SFTP is supported
> while it should produce 0 if SFTP support is left out. An Ubuntu
> system produce this output:
> $ curl-config --protocols | grep SFTP | wc -l
> 0
>
> And it even works for cross-compiling:
> $ /usr/i686-w64-mingw32/sys-root/mingw/bin/curl-config --protocols |
> grep SFTP | wc -l
> 1
>
>
> This appears to be our best way forward if we want to enable
> compile-time enabling or disabling of this option.
>
> --Greg
>
> On Mon, Dec 24, 2012 at 8:43 AM, Greg Hellings 
> wrote:
>
> Troy,
>
> On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
>  wrote:
>
> Dear Greg,
>
> Looking to apply this SFTP patch, could you give me some background as
> to
> why the check to ignore across all transports for '.' and '..'?
>
> Our downloading method runs recursively from the given directory until
> it runs out of directory depth. FTP servers don't usually seem to
> return . and .. as valid paths, and the HTTP(S) transport attempts to
> parse the returned HTML page to avoid the link to the parent
> directory. But whatever options are passed by cURL to the SFTP
> transport resulted in it returning . and .. as paths within the
> current directory. Because '.' came first in the list, the installmgr
> was running through an infinite loop whenever it tried to pull data
> from the server.
>
> I added it at the level of all transports because we don't want to
> either loop infinitely on '.' or accidentally pull a whole server
> recursively by following '..' to the root of the server. It might be a
> server config option that permits it, but I wanted to avoid the
> possibility of the InlstallMgr class getting choked up on it.
>
> --Greg
>
> Thanks,

Re: [sword-devel] ISV status?

[Greg Hellings]

On Mon, Jan 7, 2013 at 1:37 PM, Andrew Thule  wrote:
> Greg, respectfully you're still missing the point.
>
> Because a work is Copyright, doesn't grant Crosswire the right to inform me
> of anything, since CrossWire is not the CopyRight owner.

Correct. Nor does it mean CrossWire is required to inform you of
anything - such as its own license agreement.

>
> It is only if the Copyright Owner grants Crosswire rights (and restrictions)
> though the use of a license to use the Copyright work that CrossWire has any
> legal obligations at all.

Yes, and CrossWire has a private agreement with the ISV publishers to
publish the ISV text in its module.

>
> The ISV's copyright found here:
> http://www.isv.org/legal.php

CrossWire's private agreement with the publisher applies beyond these
general rights to CrossWire's use of the text.

The above rights apply to your use of the text. And to mine. And to
DM's. And to Chris Little's. And to Peter's. Unless one of us has
acquired a separate agreement, none of us may distribute or use the
ISV text in any way other than what is detailed at
http://www.isv.org/legal.php. CrossWire is not limited to the text of
that URL because it has been granted exception to that general clause.
You have not, and thus may not offer the text anymore than I may do so
because I have not gained permission. Even if I am working on a module
for CrossWire, under CrossWire's auspices, I am not permitted to
publish a copy of that myself. This is exactly what you have done.

Last year I had in my possession about 1000 modules under Copyright by
different people and organizations. The intention was that these
modules would be transformed into SWORD modules for the organization
that had rights to do this. Despite being a part of that organization
as a volunteer, I was not able to send copies of the modules to Troy
or Karl or Chris or anyone else when I ran into problems because none
of them are members of that organization. Once the conversion was
completed, I was not permitted to send a copy of those modules to the
QA and test people because I am not that organization. Since I'm not
actively working on those modules any longer I have removed them from
my local machines so that even my personal friends that I grant SSH
access to my home computer would not inadvertently acquire copies of
them. All because I had no right to distribute those modules any more
than you had a right to distribute the ISV.

I never had to see that organization's specific agreement with each
publisher for each of those 1000 works to know that I, as a private
individual, am not governed by the private agreement that organization
has with each publisher. But for some reason you think you need to
know the text of a private agreement to know that your use is governed
by Copyright law.

Let me provide you a good rule-of-thumb, so you can avoid making a
fool of yourself again in the future: If you have not received a
notice - specific like CrossWire's or generic like the one on the
ISV's website - from the Copyright holder granting you permission to
distribute a work then you do not have permission to distribute that
work to anyone for any purpose. Yes, there are some exceptions to
this, but you've already proven you don't know what those exceptions
are or when they apply to you.

>
> Doesn't say anything about Crosswire's right to control how I distribute ISV
> text.   If I am bound by the ISV's agreement only than if I abide by the
> terms of that agreement I can do anything the agreement allows me to do, and
> Crosswire has no say in the matter.

CrossWire has no right to control your distribution of the ISV text.
We're not asserting we have that right. We're trying to tell you that
you also don't have that right nor do you have a right to distribute
it (unless you're hiding from us the fact that you have negotiated
distribution rights, in which case I apologize for being wrong and I'm
sure everyone else here would as well). We can't control your
distribution - only the Copyright holder can do so through the proper
legal channels.

>
> However, because Crosswire is playing a role in the development of modules,
> I assumed (perhaps incorrectly) that Crosswire has 'license' to use the ISV
> as Copyright work, which means I am not bound by what is at the ISV site,
> but by the agreement Crosswire has with ISV.

It does have that right. Are you CrossWire? No. So why would you
assume that CrossWire's right extended to you?

>
> If CrossWire has no such agreements, I woudln't be touching any Copyrighted
> work for fear of the legal liabilities involved.

It does have that right. Do you? Because that's what actually the issue here.

>
> Either Crosswire has Lisenses covering each Copyright work it deals with, or
> it does.  If it doesn't there are larger problems than me sharing a module.
> If its does, those terms must be passed on with the work (under copyright
> law).

Multiple people have assured you that CrossWire is very careful

Re: [sword-devel] ISV status?

[Greg Hellings]

On Mon, Jan 7, 2013 at 12:43 PM, Andrew Thule  wrote:
> Greg, its not clear you understand copyright law.
>
> Copyright Law is generic .. it applies generally.  If you read American,
> Canadian, or European copyright law you won't find anything mentionion
> CrossWire, ISV, ESV specifically.  That means it lays down principles.
>
> Therefore, copyright law with respect to either printed work or digital work
> covers specifics in licenses.  If you read the licensing that comes with the
> ESV  (found here http://www.esv.org/tools/licensing/  ) which is specific,
> you'll see that nothing there says anything about CrossWire having the right
> to distribute the ESV either, which means CrossWire's 'right' to distribute
> the ESV (since the entire bible is being distributed)  is covered under its
> own license.
>
> Thefore anyone using CrossWire's ESV module, or developing that module are
> bound by a license that is apparently 'confidential'.
>
> Therefore if I have done as I've claimed, and distributed the ISV in
> contravention of some law, you should be able to produce some document that
> says I'm not permitted to do it.  Since the Copyright act doesn't
> specifically speak about the ISV, you would presumably go to the ISV
> foundation site.  Yes there is a document there (just like with the ESV),
> except it says nothing about CrossWire's right to distribute, so that
> license is not the one I've breached.   For Crosswire to assert its right to
> distribute the ISV it must have a license that says this, and that is what
> we're talking about.

The text is Copyrighted. CrossWire informs you of this in the conf
file. You are bound by whatever rights have been granted to you by the
holder of the ISV's Copyright. In this case, the text on the page you
reference is the ISV's generic rights that go out to anyone who
legally holds a copy of the text. You legally hold a copy of the text.
Therefore you are bound by that statement by the ISV's Copyright
holder.

The rights that CrossWire has negotiated separately have no bearing on
your rights to use or distribute the text. Those rights apply to
CrossWire. You have no need to see the agreements because they in no
way have a bearing on you. You are neither CrossWire nor the publisher
of the ISV nor any legal or law enforcement organization within whose
jurisdiction any of the affected parties fall.

That is how Copyright law works in the USA which is where CrossWire
falls. If you can point to a jurisdiction where you reside that is
affected by a law or requirement that Copyright agreements be made
public then you might have grounds for your request. Until then, you
are asking for private information which does not concern you.

--Greg

>
> ~A
> .
>
>
> On Mon, Jan 7, 2013 at 1:26 PM, Greg Hellings 
> wrote:
>>
>> On Mon, Jan 7, 2013 at 12:19 PM, Andrew Thule  wrote:
>> > What I did have a hard time with was being publicly held accountable to
>> > license restrictions reasonably unknown to me (and apparently secret),
>> > while
>> > having the issue made personal.  It isn't reasonable to assume I knew
>> > sharing a compiled module with this group would set off a firestorm if
>> > the
>> > license between the ISV foundation and CrossWire is treated as
>> > confidential
>>
>> You're not being held accountable to CrossWire's terms of
>> distribution. You're being held accountable to Copyright law.
>> Something you are reasonably expected to know. But which you have
>> repeatedly shown yourself either unknowledgeable of - in the case of
>> the Dead Sea Scroll modules discussion - or unwilling to abide by
>> without some sort of extra treatment - in this case knowledge of a
>> contract between two parties which has no bearing on you.
>>
>> Stop trying to insult the rest of our intelligences by taking the
>> position of victim in this. You have shown flagrant disregard for
>> Copyright and an unwilling attitude to learn or be instructed in it.
>>
>> --Greg
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] ISV status?

[Greg Hellings]

On Mon, Jan 7, 2013 at 12:19 PM, Andrew Thule  wrote:
> What I did have a hard time with was being publicly held accountable to
> license restrictions reasonably unknown to me (and apparently secret), while
> having the issue made personal.  It isn't reasonable to assume I knew
> sharing a compiled module with this group would set off a firestorm if the
> license between the ISV foundation and CrossWire is treated as confidential

You're not being held accountable to CrossWire's terms of
distribution. You're being held accountable to Copyright law.
Something you are reasonably expected to know. But which you have
repeatedly shown yourself either unknowledgeable of - in the case of
the Dead Sea Scroll modules discussion - or unwilling to abide by
without some sort of extra treatment - in this case knowledge of a
contract between two parties which has no bearing on you.

Stop trying to insult the rest of our intelligences by taking the
position of victim in this. You have shown flagrant disregard for
Copyright and an unwilling attitude to learn or be instructed in it.

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Exclusive Rights Granting Crosswire License to Distribute

[Greg Hellings]

On Mon, Jan 7, 2013 at 11:58 AM, Andrew Thule  wrote:
>
> On Sun, Jan 6, 2013 at 11:12 AM, DM Smith  wrote:
>
>> No, we cannot publish the terms of licensing agreements. Think about it.
>> These are confidential, privileged contracts between organizations.
>
>
> Umm, with software Licenses, Acceptable Use Policies, Copyright Restrictions
> and Copyright limitations are not typically priviledge ..
>
> The contractual agreement itself may be, but License for use, especially in
> public forums is not, otherwise how can you come down so hard on someone
> like me for trying to abide by licensing agreement when those agreements are
> not know?
>
> You're saying on the one had I have to abide by Crosswire's agreement with
> the Copyright Owner and on the other hand I cannot know what those
> provisions are.

False. We're saying you have to abide by Copyright laws. According to
Copyright laws you have no claim on these modules unless there is
either (1) no Copyright holder, as is the case for any modules in the
public domain or (2) you have been granted permission by the Copyright
holder. This could be in the case of content where the holder has
publicly permitted anyone rights, otherwise you need to negotiate your
own license with the Copyright holder if you want to distribute. You
have no need to make your license public to anyone if you negotiate
the rights to a module and neither does CrossWire. The only people who
need to know the specific terms are CrossWire's point of contact
(usually Troy or Chris but it could be whoever negotiated the
contract) and the Copyright holder. Additionally a copy could be
submitted to law enforcement or courts if legislation arose or the
like.

> For example, I am particularly disappointed that I was accused of breaking
> Crosswire's licensing restrictions, yet no one has bothered to either
> publically name one module that was available at my repo that should have
> been, or provide access to Crosswire's license as evidence this was wrong.

You don't need to see the specifics of CrossWire's license agreements.
You just need to understand basic Copyright function. Is the text
under Copyright? Do you have the permission of the Copyright holder to
distribute the text? If the answer to the first question is "yes" and
the answer to the second is "no" then you don't have the right to
distribute the work. Regardless of who DOES have the right, you do
not. And regardless of under which conditions they have the right, you
do not.

You don't need to know under what permissions CrossWire has the right
to distribute a module publicly in electronic format anymore than you
need to know what agreement Zondervan has to publish a paper copy. You
also don't need to know what agreement Amazon has or Netflix has to
electronically make available copies of movies to know that you do not
have a right to mirror their content without permission from at least
the Copyright holder.

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CMS volunteers required

[Greg Hellings]

Chris,

A good first step might be to develop a simple library (possibly as simple
as a function or a class) that fetches the data from STEP. Then you could
have a single PHP class, Java class, Python class, Ruby class, etc that
fetch the data from STEP and anyone could use a class like that to
trivially write a plugin like you're describing.

--Greg


On Sat, Jan 5, 2013 at 5:15 AM, Chris Burrell  wrote:

> Hi all
>
> Just wondering if we have some CMS plugin developers on this list?  STEP
> will expose an API to other websites, so I'm looking for volunteers to help
> brainstorm & possibly write the plugins for the various CMSs around. The
> idea is pretty straightforward at the moment, and I can think of at least 3
> use cases:
>
>- Verse or passage display
>- Verse of the day (mainly because other people do it), but possibly
>also following some devotional schemes
>- Looking up a strong number
>- maybe some more things if people want to suggest more ideas.
>
> I read from http://www.siteground.com/best_cms_tools.htm that the top CMS
> are:
>
>- Joomla
>- WordPress
>- Drupal
>
> Any ideas if churches tend to use other popuplar CMS frameworks?
>
> STEP currently exposes a REST like interface, but some people might prefer
> a "javascript" include snippet to include, etc. Would be interested to hear
> your thoughts on that too.
>
> Chris
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] CMake ICU (was Re: cmake python)

[Greg Hellings]

On Sat, Dec 22, 2012 at 12:51 PM,   wrote:
> On Wed, Dec 19, 2012 at 9:06 PM, Greg Hellings  
> wrote:
>>> On Tue, Dec 18, 2012 at 9:27 PM,   wrote:
>>> Here's a patch that helps some with osistest. I still get the
>>> following error when I run osistest, though:
>>> UTF8Transliterator: ICU: no resource index to load
>>> UTF8Transliterator: ICU: status U_MISSING_RESOURCE_ERROR
>>
>> This is because it's not finding the locales or some such. I very
>> frequently get it, mainly when running from an uninstalled SWORD
>> instance but it happens other times even on install.
>>
>> I'll see about applying these patches.
>
> Here's patch that I think helps with the ICU support. It finds the
> genrb command, and then also sets the ICU_VERSION variable, like the
> configure build system does. (The osis test still fails, but it
> doesn't have the UTF8Transliterator error.)

Your patch was on the right path but used icu-config which is horridly
broken in native Windows builds (it's a Bash script) or in cross-build
environments from Linux (it explodes looking for a .so library when it
should look for a .dll).

I have substituted using CMake's built-in pkg-config functions to pull
out the modversion variable of libicuuc, which is one of the few that
we actually link directly against.

I wish I could tell you why that fixes the issue, but it does. Thank
you much, because that has been bugging me for a long time. The fix
should be in the SVN HEAD now.

--Greg

>
> -Ben
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cmake python

[Greg Hellings]

Ben,

I just made a series of commits which further improve handling of
Python builds. They do the following:

1) Move handling of bindings configuration up a directory level so
CMake can include support for bindings other than SWIG in the future
(unrelated to your complaint)
2) Add detection for the Python development headers and libraries that
are necessary. This should leave you and anyone else wanting to build
the library with bindings a little less flustered when Python is
supposedly detected by CMake but not able to build.
3) Adds the ability for the user to optionally define
SWORD_PYTHON_INSTALL_DIR which will be passed as an argument to --home
when setup.py is invoked.

These are in the tip of SVN. Let me know if they resolve that problem
for you. I haven't had a chance to get your ICU fix worked out, but
that's next on my list.

--Greg

On Sat, Dec 22, 2012 at 12:51 PM,   wrote:
> On Wed, Dec 19, 2012 at 9:06 PM, Greg Hellings  
> wrote:
>>> On Tue, Dec 18, 2012 at 9:27 PM,   wrote:
>>> Here's a patch that helps some with osistest. I still get the
>>> following error when I run osistest, though:
>>> UTF8Transliterator: ICU: no resource index to load
>>> UTF8Transliterator: ICU: status U_MISSING_RESOURCE_ERROR
>>
>> This is because it's not finding the locales or some such. I very
>> frequently get it, mainly when running from an uninstalled SWORD
>> instance but it happens other times even on install.
>>
>> I'll see about applying these patches.
>
> Here's patch that I think helps with the ICU support. It finds the
> genrb command, and then also sets the ICU_VERSION variable, like the
> configure build system does. (The osis test still fails, but it
> doesn't have the UTF8Transliterator error.)
>
> -Ben
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire mirroring

[Greg Hellings]

On Fri, Jan 4, 2013 at 3:06 PM, DM Smith  wrote:
> If someone posts to sword-support a problem with the text in a module (we
> get these all the time), having mirrors complicates support.

If Fedora can have many dozen mirrors, and Debian can have many dozen
mirrors and so can every Linux distribution out there, is it so hard
for us to have mirrors when it comes down to it? Each of these has
requirements for what a mirror MUST, SHOULD and MAY provide and they
have a vetting process when someone wants to become an official mirror
they ensure that the offer follows those requirements.

For the most part those requirements boil down to: provide the
mandatory parts of the distribution with the same layout they have on
the master, and update at minimum every X hours or days. That's hardly
a burdensome task to setup, consisting mostly of a handful of options
to something like rsync. If we wanted to have official mirrors we
could be sure anyone offering followed those requirements and then add
them to a master list of mirrors. It's not that complicated to require
and it's not that complicated to configure. Many people offering to
setup mirrors would already be familiar with the methods and
requirements.

Yes, licensing would still be an entirely different issue, but the
technical implications of offering a mirror system for a pure list of
files is not difficult. And certainly it's not more difficult than
offering ISO images for users to download and encouraging them to be
able to share them with friends!

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] ISV status?

[Greg Hellings]

On Thu, Jan 3, 2013 at 2:44 PM, Andrew Thule  wrote:
> I just thought about this a bit more .. I suppose that's what "Version=1.5"
> is for ...

No, the Copyright limitation applies to the source material. It's very
possible that multiple versions of the module could be made from the
same initial source copy as bugs are uncovered in the encoding, in the
transformation process, in the conf file, etc. So the Copyright
permission is not given for Version 1.5 of the module but for a
particular copy of the original material received from the Copyright
holder.

There is no way to know from most conf files if there has been only
one or possibly dozens of versions of the source material iterated
through. In this case it is likely that there are no more than 5
copies of the source text but more likely there was only 1 or 2
versions received from upstream and the other revisions represent bug
fixes in the importation or distribution process.

--Greg

>
> Nevermind.
> ~A
>
>
> On Thu, Jan 3, 2013 at 3:42 PM, Andrew Thule  wrote:
>>
>> Thanks for the clarification DM.
>> Perhaps for the sake of clarity then, the .conf file's
>> "DistributionLicense=" attribute could contain the version for which
>> permission was granted (rather than appearing to be generic).
>>
>> ~A
>>
>>
>> On Thu, Jan 3, 2013 at 3:35 PM, DM Smith  wrote:
>>>
>>> I can see how you might conclude that.
>>>
>>> However, when we get permission for a copyrighted work, we get permission
>>> for that copyright. If the work is updated, there is a new copyright and we
>>> have to obtain permission for that.
>>>
>>> In Him,
>>> DM
>>>
>>>
>>> On Jan 3, 2013, at 3:30 PM, Andrew Thule  wrote:
>>>
>>> I should add that prior to doing anything I did check the isv.conf file
>>> which says this:
>>> DistributionLicense=Copyrighted; Permission to distribute granted to
>>> CrossWire
>>>
>>>
>>> From .conf file at least, any reasonable person would conclude that
>>> permission had already been obtained to distribute (and redistribute) ISV
>>> and any additional revisions.
>>>
>>> ~A
>>>
>>>
>>> On Thu, Jan 3, 2013 at 2:56 PM, Andrew Thule  wrote:

 Come now Peter, don't be so quick to find fault.

 The Crosswire repository currently contains version 1.5 of the ISV
 module.  Nic's question was asking about the inclusion of the OT in that
 module.  The Crosswire site doesn't say anything about the status of this
 module, and Nic's question seems to suggest he was not aware Crosswire was
 prohibited from distributed a later versions of this module.  His comment
 was specifically asking about the ISV with OT included suggesting this was
 already  direction that was being pursued.

 I was trying to extend an offer to help (as a volunteer).  I certainly
 wasn't aware that permission hadn't been obtained to distribute the ISV 
 with
 the OT, and the fact the ISV is already distributed with the NT suggests
 (perhaps incorrectly) that permission has been already obtained.  Once 
 Chris
 made it known that Crosswire has no such permission to distribute newer
 versions of the ISV I did exactly as Chris asked.  So what infraction have 
 I
 committed now?

 Respectfully, if every time a newcomer or volunteer's offer is met with
 criticism or controversy the treatment of newcomers and volunteers in this
 group is going to appear somewhat suspect and unwelcoming.  It's a very 
 good
 way to drive people away from a project.  If my lack of awareness of this
 prohibition on the ISV is why you're asking me to leave - that says much
 about this community.

 Now that I know Crosswire doesn't have permission to distribute versions
 of the ISV other than the one currently in the repository, I'll respect
 that.  If others feel as you do, that outside contributions are unwelcome
 here - I will kick the sand from my sandals and leave

 ~A

 On Thu, Jan 3, 2013 at 2:20 PM, ref...@gmx.net  wrote:
>
> Andrew, this is now quite enough. Please desist posting further onto
> our list. Your presence is undesired
>
> Sent from my HTC
>
>
> - Reply message -
> From: "Andrew Thule" 
> To: "SWORD Developers' Collaboration Forum" 
> Subject: [sword-devel] ISV status?
> Date: Thu, Jan 3, 2013 18:53
>
>
> Done.
>
> I made it available here only in response to this request ..
>
> ~A
>
>
> On Thu, Jan 3, 2013 at 1:28 PM, Chris Little 
> wrote:
>>
>> Andrew, this document is copyrighted. We do not have permission to
>> distribute it. You certainly and absolutely do not have permission to
>> distribute it, much less to distribute it and claim that we have 
>> permission
>> to distribute it.
>>
>> Remove it immediately.
>>
>> --Chris
>>
>>
>>
>> On 1/3/2013 9:37 AM, Andrew Thule wrote:
>>>
>>> I beli

Re: [sword-devel] SFTP Support

[Greg Hellings]

Also note, I didn't test building this with autotools, only with
CMake. The library silently ignores any SFTP sources listed in the
InstallMgr.conf file if it is compiled without SFTP support.

--Greg

On Mon, Dec 31, 2012 at 8:53 AM, Greg Hellings  wrote:
> Here is the updated patch adding CURLSFTPAVAILABLE support to CMake as
> well as to the library code. It defaults to assuming no SFTP support
> if either the curl-config executable cannot be found or if it returns
> a value other than "1" from the quick detection process we have
> settled on.
>
> Users of Windows builds through either VisualStudio or Borland will
> need to figure out if curl-config is available on their systems and,
> if not, come up with another way to detect and support SFTP for
> clients using those builds. On Linux it is a Bash script, so it might
> be adaptable to Manfred's XCode system in some way also.
>
> For those in the JSword world, I am sure there are SFTP Java clients
> available which could be leveraged if they wanted to add support for
> the same functionality to JSword applications.
>
> --Greg
>
> On Sun, Dec 30, 2012 at 9:11 PM, Troy A. Griffitts  
> wrote:
>> OK Greg,
>>
>> I've hacked detection of CURL SFTP into the autotools build (hopefully-- it
>> works for me).
>>
>> I've added a new compile time define with -DCURLSFTPAVAILABLE to go along
>> with the existing -DCURLAVAILABLE
>>
>> If you'd like to update the sftp patch to conditionally compile support in
>> based on this define, that would be cool.  I'll do it myself soon if you
>> don't have time.
>>
>> Troy
>>
>>
>>
>> On 12/28/2012 11:42 AM, Greg Hellings wrote:
>>>
>>> Further digging with help from our friends has revealed this nugget:
>>>
>>> $ curl-config --protocols
>>>
>>> produces a newline-delimited list of protocols that the particular
>>> build of libcurl supports. curl-config is a shell script which can be
>>> run on the build system and should satisfy both the requirements of
>>> native builds and cross-compiling support. We could use this to set a
>>> compiler macro indicating support (or not) for SFTP in the target
>>> libcurl library.
>>>
>>> If someone wants to tackle that in the autotools world, I can add
>>> detection to CMake as well. A simple command such as
>>> $ curl-config --protocols | grep SFTP | wc -l
>>> 1
>>>
>>> in Fedora will result in a value of 1 or greater if SFTP is supported
>>> while it should produce 0 if SFTP support is left out. An Ubuntu
>>> system produce this output:
>>> $ curl-config --protocols | grep SFTP | wc -l
>>> 0
>>>
>>> And it even works for cross-compiling:
>>> $ /usr/i686-w64-mingw32/sys-root/mingw/bin/curl-config --protocols |
>>> grep SFTP | wc -l
>>> 1
>>>
>>>
>>> This appears to be our best way forward if we want to enable
>>> compile-time enabling or disabling of this option.
>>>
>>> --Greg
>>>
>>> On Mon, Dec 24, 2012 at 8:43 AM, Greg Hellings 
>>> wrote:
>>>>
>>>> Troy,
>>>>
>>>> On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
>>>>  wrote:
>>>>>
>>>>> Dear Greg,
>>>>>
>>>>> Looking to apply this SFTP patch, could you give me some background as
>>>>> to
>>>>> why the check to ignore across all transports for '.' and '..'?
>>>>
>>>> Our downloading method runs recursively from the given directory until
>>>> it runs out of directory depth. FTP servers don't usually seem to
>>>> return . and .. as valid paths, and the HTTP(S) transport attempts to
>>>> parse the returned HTML page to avoid the link to the parent
>>>> directory. But whatever options are passed by cURL to the SFTP
>>>> transport resulted in it returning . and .. as paths within the
>>>> current directory. Because '.' came first in the list, the installmgr
>>>> was running through an infinite loop whenever it tried to pull data
>>>> from the server.
>>>>
>>>> I added it at the level of all transports because we don't want to
>>>> either loop infinitely on '.' or accidentally pull a whole server
>>>> recursively by following '..' to the root of the server. It might be a
>>>> server config option that permits it, but I wanted 

Re: [sword-devel] SFTP Support

[Greg Hellings]

Here is the updated patch adding CURLSFTPAVAILABLE support to CMake as
well as to the library code. It defaults to assuming no SFTP support
if either the curl-config executable cannot be found or if it returns
a value other than "1" from the quick detection process we have
settled on.

Users of Windows builds through either VisualStudio or Borland will
need to figure out if curl-config is available on their systems and,
if not, come up with another way to detect and support SFTP for
clients using those builds. On Linux it is a Bash script, so it might
be adaptable to Manfred's XCode system in some way also.

For those in the JSword world, I am sure there are SFTP Java clients
available which could be leveraged if they wanted to add support for
the same functionality to JSword applications.

--Greg

On Sun, Dec 30, 2012 at 9:11 PM, Troy A. Griffitts  wrote:
> OK Greg,
>
> I've hacked detection of CURL SFTP into the autotools build (hopefully-- it
> works for me).
>
> I've added a new compile time define with -DCURLSFTPAVAILABLE to go along
> with the existing -DCURLAVAILABLE
>
> If you'd like to update the sftp patch to conditionally compile support in
> based on this define, that would be cool.  I'll do it myself soon if you
> don't have time.
>
> Troy
>
>
>
> On 12/28/2012 11:42 AM, Greg Hellings wrote:
>>
>> Further digging with help from our friends has revealed this nugget:
>>
>> $ curl-config --protocols
>>
>> produces a newline-delimited list of protocols that the particular
>> build of libcurl supports. curl-config is a shell script which can be
>> run on the build system and should satisfy both the requirements of
>> native builds and cross-compiling support. We could use this to set a
>> compiler macro indicating support (or not) for SFTP in the target
>> libcurl library.
>>
>> If someone wants to tackle that in the autotools world, I can add
>> detection to CMake as well. A simple command such as
>> $ curl-config --protocols | grep SFTP | wc -l
>> 1
>>
>> in Fedora will result in a value of 1 or greater if SFTP is supported
>> while it should produce 0 if SFTP support is left out. An Ubuntu
>> system produce this output:
>> $ curl-config --protocols | grep SFTP | wc -l
>> 0
>>
>> And it even works for cross-compiling:
>> $ /usr/i686-w64-mingw32/sys-root/mingw/bin/curl-config --protocols |
>> grep SFTP | wc -l
>> 1
>>
>>
>> This appears to be our best way forward if we want to enable
>> compile-time enabling or disabling of this option.
>>
>> --Greg
>>
>> On Mon, Dec 24, 2012 at 8:43 AM, Greg Hellings 
>> wrote:
>>>
>>> Troy,
>>>
>>> On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
>>>  wrote:
>>>>
>>>> Dear Greg,
>>>>
>>>> Looking to apply this SFTP patch, could you give me some background as
>>>> to
>>>> why the check to ignore across all transports for '.' and '..'?
>>>
>>> Our downloading method runs recursively from the given directory until
>>> it runs out of directory depth. FTP servers don't usually seem to
>>> return . and .. as valid paths, and the HTTP(S) transport attempts to
>>> parse the returned HTML page to avoid the link to the parent
>>> directory. But whatever options are passed by cURL to the SFTP
>>> transport resulted in it returning . and .. as paths within the
>>> current directory. Because '.' came first in the list, the installmgr
>>> was running through an infinite loop whenever it tried to pull data
>>> from the server.
>>>
>>> I added it at the level of all transports because we don't want to
>>> either loop infinitely on '.' or accidentally pull a whole server
>>> recursively by following '..' to the root of the server. It might be a
>>> server config option that permits it, but I wanted to avoid the
>>> possibility of the InlstallMgr class getting choked up on it.
>>>
>>> --Greg
>>>
>>>> Thanks,
>>>>
>>>> Troy
>>>>
>>>>
>>>>
>>>>
>>>> On 12/03/2012 04:06 PM, Greg Hellings wrote:
>>>>
>>>> The attached patch will introduce support for SFTPSource transports in
>>>> the SWORD engine, allowing a user to access remote repositories over
>>>> SFTP (which is enabled by default when a user enables SSH).
>>>>
>>>> --Greg
>>>>
>>>

Re: [sword-devel] SFTP Support

[Greg Hellings]

Further digging with help from our friends has revealed this nugget:

$ curl-config --protocols

produces a newline-delimited list of protocols that the particular
build of libcurl supports. curl-config is a shell script which can be
run on the build system and should satisfy both the requirements of
native builds and cross-compiling support. We could use this to set a
compiler macro indicating support (or not) for SFTP in the target
libcurl library.

If someone wants to tackle that in the autotools world, I can add
detection to CMake as well. A simple command such as
$ curl-config --protocols | grep SFTP | wc -l
1

in Fedora will result in a value of 1 or greater if SFTP is supported
while it should produce 0 if SFTP support is left out. An Ubuntu
system produce this output:
$ curl-config --protocols | grep SFTP | wc -l
0

And it even works for cross-compiling:
$ /usr/i686-w64-mingw32/sys-root/mingw/bin/curl-config --protocols |
grep SFTP | wc -l
1


This appears to be our best way forward if we want to enable
compile-time enabling or disabling of this option.

--Greg

On Mon, Dec 24, 2012 at 8:43 AM, Greg Hellings  wrote:
> Troy,
>
> On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
>  wrote:
>> Dear Greg,
>>
>> Looking to apply this SFTP patch, could you give me some background as to
>> why the check to ignore across all transports for '.' and '..'?
>
> Our downloading method runs recursively from the given directory until
> it runs out of directory depth. FTP servers don't usually seem to
> return . and .. as valid paths, and the HTTP(S) transport attempts to
> parse the returned HTML page to avoid the link to the parent
> directory. But whatever options are passed by cURL to the SFTP
> transport resulted in it returning . and .. as paths within the
> current directory. Because '.' came first in the list, the installmgr
> was running through an infinite loop whenever it tried to pull data
> from the server.
>
> I added it at the level of all transports because we don't want to
> either loop infinitely on '.' or accidentally pull a whole server
> recursively by following '..' to the root of the server. It might be a
> server config option that permits it, but I wanted to avoid the
> possibility of the InlstallMgr class getting choked up on it.
>
> --Greg
>
>>
>> Thanks,
>>
>> Troy
>>
>>
>>
>>
>> On 12/03/2012 04:06 PM, Greg Hellings wrote:
>>
>> The attached patch will introduce support for SFTPSource transports in
>> the SWORD engine, allowing a user to access remote repositories over
>> SFTP (which is enabled by default when a user enables SSH).
>>
>> --Greg
>>
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

Troy,

On Sun, Dec 23, 2012 at 10:39 PM, Troy A. Griffitts
 wrote:
> Dear Greg,
>
> Looking to apply this SFTP patch, could you give me some background as to
> why the check to ignore across all transports for '.' and '..'?

Our downloading method runs recursively from the given directory until
it runs out of directory depth. FTP servers don't usually seem to
return . and .. as valid paths, and the HTTP(S) transport attempts to
parse the returned HTML page to avoid the link to the parent
directory. But whatever options are passed by cURL to the SFTP
transport resulted in it returning . and .. as paths within the
current directory. Because '.' came first in the list, the installmgr
was running through an infinite loop whenever it tried to pull data
from the server.

I added it at the level of all transports because we don't want to
either loop infinitely on '.' or accidentally pull a whole server
recursively by following '..' to the root of the server. It might be a
server config option that permits it, but I wanted to avoid the
possibility of the InlstallMgr class getting choked up on it.

--Greg

>
> Thanks,
>
> Troy
>
>
>
>
> On 12/03/2012 04:06 PM, Greg Hellings wrote:
>
> The attached patch will introduce support for SFTPSource transports in
> the SWORD engine, allowing a user to access remote repositories over
> SFTP (which is enabled by default when a user enables SSH).
>
> --Greg
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

Troy,

I've trawled through the curl header files and have found no mechanism
to determine if SSH is enabled for a build with it already enabled.
The libcurl docs I've read have said, regarding the ambiguous message
Peter received (stating that support is "either" disabled or
unavailable) that there is no way to determine if this message results
from libcurl not supporting a protocol or from it being disabled at
libcurl's compile time.

Taking that together, unless someone on Debian can locate a variable
in curl header file indicating SSH_SUPPORT_DISABLED or something
equivalent then I would say there is no way to positively determine at
compile time if SFTP support should be included. So it would seem like
we can't do any better than this patch unless we actually attempt to
compile and run a sample file against libcurl that connects out to
SFTP. But I know relying on this is terrible for cross-compiling and
lots of build systems are setup to disallow network traffic, so this
method may not be very robust.

On a related note, I have a colleague who is actively pursuing
resolution of the outstanding Debian issues to enable libssh2 to be
admitted to Debian's "main" repository, which is the blocking bug
preventing the Debian-family of distros from having SFTP support in
libcurl. So hopefully that issue is resolved in that universe soon.

Unless new details come up, it seems we will either have to just leave
out SFTP support for being unable to determine its availability or let
libcurl fail in its own ways if it lacks it and blindly pass off
control to it. You'll have to make a determination of which one you
prefer.

There are other architectural changes to the way InstallMgr works that
could also be added to enhance the user experience - allowing them to
specify a public key instead of a password (libcurl defaults to
looking at ~/.ssh/id_rsa.pub when traversing SFTP which is a problem
for us DSA key users or anyone storing their key in a non-standard
location) and/or not storing passwords in plaintext in InstallMgr.conf
which are outside of the purview of this patch.

--Greg

On Sat, Dec 22, 2012 at 1:23 PM, Troy A. Griffitts  wrote:
> So guys.  What's the status on this one?  Last I heard, we might want to add
> libcurl ssh detection to prevent a flurry of support emails.  Should I
> commit as-is, or would you like more time to experiment with and add
> detection?
>
> Troy
>
>
> On 12/19/2012 05:07 AM, Greg Hellings wrote:
>
> If this gets approved and submitted, then yes. Otherwise, there is no point.
>
> --Greg
>
> On Dec 19, 2012 4:12 AM, "David Haslam"  wrote:
>>
>> A summary of SFTP module installation would be a useful addition to the
>> wiki.
>>
>> Please would one of you condense the details and post a suitable section
>> the
>> most relevant wiki page.
>>
>> /Thanks/.
>>
>> David
>>
>>
>>
>> --
>> View this message in context:
>> http://sword-dev.350566.n4.nabble.com/SFTP-Support-tp4651358p4651440.html
>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cmake python

[Greg Hellings]

On Wed, Dec 19, 2012 at 7:59 PM,   wrote:
> On Tue, Dec 18, 2012 at 9:27 PM,   wrote:
> Here's a patch that helps some with osistest. I still get the
> following error when I run osistest, though:
> UTF8Transliterator: ICU: no resource index to load
> UTF8Transliterator: ICU: status U_MISSING_RESOURCE_ERROR

This is because it's not finding the locales or some such. I very
frequently get it, mainly when running from an uninstalled SWORD
instance but it happens other times even on install.

I'll see about applying these patches.

--Greg

>
> $ svn diff
> Index: tests/CMakeLists.txt
> ===
> --- tests/CMakeLists.txt(revision 2751)
> +++ tests/CMakeLists.txt(working copy)
> @@ -30,6 +30,7 @@
> localetest
> mgrtest
> modtest
> +osistest
> parsekey
> rawldidxtest
> romantest
> Index: tests/testsuite/CMakeLists.txt
> ===
> --- tests/testsuite/CMakeLists.txt  (revision 2751)
> +++ tests/testsuite/CMakeLists.txt  (working copy)
> @@ -6,6 +6,7 @@
> tests_configure
> COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/*.sh 
> ${CMAKE_CURRENT_BINARY_DIR}
> COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/*.good
> ${CMAKE_CURRENT_BINARY_DIR}
> +COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/osisReference.xml
> ${CMAKE_CURRENT_BINARY_DIR}
> COMMAND echo
> \"[Install]\\nLocalePath=${CMAKE_CURRENT_SOURCE_DIR}/../../\" >
> ${CMAKE_CURRENT_BINARY_DIR}/sword.conf
> DEPENDS ${test_PROGRAMS}
> WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
>
> -Ben
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Need help tracking down a bug in the API...

[Greg Hellings]

"Yes, the trailing '.' does change the behavior:
1Ti2:6f." yields the whole chapter
"Ga1:1,11f." behaves the same as without the trailing '.'

On Wed, Dec 19, 2012 at 10:08 AM, Troy A. Griffitts
 wrote:
> Thanks guys. I was, too, going to try the parsekey test in the engine. In
> the testsuite we have a zillion verse reference patterns we support and I'm
> sure we have 'f' and 'ff' tests. What I suspect the problem might be is the
> trailing '.'. We parse this as an acceptable book.chapter.verse separator
> and I suspect we need to tweak it slightly for this case. Nic, David, Greg,
> you guys have provided great information and saved me tons of time digging
> myself. Thank you.
>
> Troy
>
>
> Greg Hellings  wrote:
>>
>> We might get better information on what is happening by passing each
>> of the noted references to the verserangeparse command line example
>> from the engine:
>>
>> Passing in "1Ti2:6f" gives 1 Timothy 2:6-7.
>> "1Ti2:6ff" gives 1 Timothy 2:6-15.
>> "Ga1:1,11f" gives Galatians 1:1 and 1:11-12.
>>
>> The engine appears to handle these references correctly.
>>
>> --Greg
>>
>>
>> On Wed, Dec 19, 2012 at 9:03 AM, David Haslam 
>> wrote:
>>>
>>> These analysis statistics might give further clues for investigation.
>>>
>>> For module RWP, in the output of mod2imp, ...
>>>
>>> There are 22159 matches to "" in total.
>>>
>>> There are 736 matches to the exact pattern "f.".
>>> btw. The same number as when matched even without the "f".
>>>
>>> cf. There are 21117 matches to regexp "(\d+)"
>>>
>>> There are 304 matches to regexp "[a-z]"
>>> of which 299 match exactly to "f"
>>> among which 40 match exactly to "ff"
>>>
>>> btw. By my reckoning, this leaves 2 patterns yet to account for.
>>> 22159 - 21117 - 736 - 304 = 2
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://sword-dev.350566.n4.nabble.com/Need-help-tracking-down-a-bug-in-the-API-tp4651439p4651446.html
>>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>>
>>> 
>>>
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> 
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Need help tracking down a bug in the API...

[Greg Hellings]

We might get better information on what is happening by passing each
of the noted references to the verserangeparse command line example
from the engine:

Passing in "1Ti2:6f" gives 1 Timothy 2:6-7.
"1Ti2:6ff" gives 1 Timothy 2:6-15.
"Ga1:1,11f" gives Galatians 1:1 and 1:11-12.

The engine appears to handle these references correctly.

--Greg


On Wed, Dec 19, 2012 at 9:03 AM, David Haslam  wrote:
> These analysis statistics might give further clues for investigation.
>
> For module RWP, in the output of mod2imp, ...
>
> There are 22159 matches to "" in total.
>
> There are 736 matches to the exact pattern "f.".
> btw. The same number as when matched even without the "f".
>
> cf. There are 21117 matches to regexp "(\d+)"
>
> There are 304 matches to regexp "[a-z]"
> of which 299 match exactly to "f"
> among which 40 match exactly to "ff"
>
> btw. By my reckoning, this leaves 2 patterns yet to account for.
> 22159 - 21117 - 736 - 304 = 2
>
> David
>
>
>
>
>
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Need-help-tracking-down-a-bug-in-the-API-tp4651439p4651446.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

If this gets approved and submitted, then yes. Otherwise, there is no point.

--Greg
On Dec 19, 2012 4:12 AM, "David Haslam"  wrote:

> A summary of SFTP module installation would be a useful addition to the
> wiki.
>
> Please would one of you condense the details and post a suitable section
> the
> most relevant wiki page.
>
> /Thanks/.
>
> David
>
>
>
> --
> View this message in context:
> http://sword-dev.350566.n4.nabble.com/SFTP-Support-tp4651358p4651440.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

On Tue, Dec 18, 2012 at 10:31 AM, Peter von Kaehne  wrote:
> Hi Greg,
>
> On Tue, 2012-12-18 at 07:47 -0600, Greg Hellings wrote:
>> From the other thread, Troy writes:
>> "I have been following the discussion on the SFTP patch and hadn't
>> seen it come to a conclusion yet regarding what might be necessary to
>> detect SSL support in cURL. I don't feel I've been negligent with
>> this."
>>
>> I guess we had a chicken/egg type problem because I was waiting to
>> hear back from Peter on his success and you on what you thought of it
>> before going further.
>
> Apologies. It still fails, but in a "better" way than before.
>
> I have compiled libcurl on Ubuntu from source, enabling ssh and sftp.
>
> I had no joy with putting a password anywhere where it made sense.

Your line in InstallMgr.conf should look like this if you want to use
password authentication:
SFTPSource=Home|domain.com|/home/username/.sword|username|password|20121203172011

>
> It clearly tries to connect with the help of a public key, but there
> appears to be some confusion as I am getting error messages that my
> user name and my key do not fit together.

It probably isn't picking up the username from your conf file
properly. It likely is defaulting to user 'anonymous' or somesuch in
that case (or maybe the current user on your local machine, which is
what OpenSSH defaults to - this often trips me up because I use 'greg'
on all my personal machines but I'm usually 'ghellings' at work or on
public systems). You can modify the line above by taking out the
'password' field and leaving the space between those two pipes blank.
That should do the public key auth if you provide it the password
entry at least.

--Greg

>
> I can ssh into the same server with a key no problem
>
> Peter
>
>
>
> CURLFTPTransport: TEXT: SSH authentication methods available:
> publickey,password
>
> CURLFTPTransport: TEXT: Using ssh public key
> file /home//.ssh/.pub
>
> CURLFTPTransport: TEXT: Using ssh private key
> file /home//.ssh/
>
> CURLFTPTransport report progress: totalSize: 0; xfered: 0
>
> CURLFTPTransport: TEXT: SSH public key authentication failed:
> Username/PublicKey combination invalid
>
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cmake python

[Greg Hellings]

If you configure with SWORD_BUILD_TESTS="Yes" CMake will configure the tests.

You can then issue 'make tests' from the top build directory and it
will build _and_ attempt to run all the tests. Now it fails for me on
the first one because of a missing directory "../../osistest". I have
a feeling this is because I force the build to be out-of-stream? I
don't really know, as I have never run our test suite. But if you want
to compile and run the tests manually, all you need to do is specify
'make tests' and they'll be built in the tests/ subdirectory of your
build dir.

--Greg

On Mon, Dec 17, 2012 at 8:56 PM,   wrote:
> On Mon, Dec 17, 2012 at 9:40 PM,   wrote:
>> On Mon, Dec 17, 2012 at 9:17 AM, Greg Hellings  
>> wrote:
>>> What does it seem to be doing improperly? That's a very broad
>>> statement. I pretty much don't build the tests because they aren't
>>> really kept up with and are intended to be a thing for people actively
>>> developing on the engine, not for packagers, users, or client app
>>> writers - which is the main hat I wear.
>>
>> I just don't see the tests being compiled by cmake. With the old
>> system, in the tests directory, the tests like casttest, ciphertest,
>> keytest, ... are automatically compiled, so the executables are right
>> there ready to run when  code is changed. I don't see the test
>> executables being created by cmake.
>
> Here's a small diff:
>  FOREACH(TEST ${test_PROGRAMS})
> -   ADD_EXECUTABLE(${TEST} EXCLUDE_FROM_ALL ${TEST}.cpp)
> +   ADD_EXECUTABLE(${TEST} ${TEST}.cpp)
> IF(BUILDING_SHARED)
>
> Not sure what the "EXCLUDE_FROM_ALL" was for, but if I take it out, at
> least some of the test executables get built. (By the way, I'm not too
> worried about the tests being run automatically, although it'd be nice
> to be able to do that.) If the test binaries get created, and the .sh
> and .good files from tests/testsuite get copied into  the build
> directory, then the tests can be run as needed (just as shell
> scripts).
>
> -Ben
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Pumpkin juggling (was Re: New public git mirror of Sword SVN trunk and why)

[Greg Hellings]

On Tue, Dec 18, 2012 at 8:43 AM, Troy A. Griffitts  wrote:
> Greg, the CMAKE
> system.  Others, the bindings (not sure who's still claiming which bindings
> these days).

For the record: I also juggle the SWIG pumpkin ever since I committed
a fix to the Perl build to reduce Peter's usfm-->OSIS iteration time
from hours to seconds. I try to never make changes without getting the
'all clear' sign from BPBible (Python) and Peter (Perl) as they are
the only ones I know who make consistent use of the bindings.

The bindings/ and cmake/ folders and CMakeLists.txt files are the only
ones I have write privileges to (unless that changed without my
knowledge).

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] New public git mirror of Sword SVN trunk and why

[Greg Hellings]

On Mon, Dec 17, 2012 at 11:11 PM, Troy A. Griffitts
 wrote:
> I deserve the rebuke for the release schedule. The release schedule was not
> even mentioned in the email to which I responded.

Are you the only person capable of making a release? I remember talk,
I believe it was in sword-devel, about designating another
person/persons to be the release maintainers because you focus mainly
on development. Cutting a 1.6 branch (or a 1.7 now) and giving
maintenance of that branch and release privileges to a few other
people so that they can maintain a regular release schedule
independent of your commitments. Such a person could even have the
privilege of cutting a new branch when the time is right and would be
responsible for back-porting trunk fixes to the release branch.

This has become a regular thing - pleading for a release, seeing the
promised date slip by, and then gradually upping the level of
antagonism until one comes out. It would be great to see this shared
with people who are willing to commit to it.

>
> The NASB ball was dropped by at least 2 volunteers before I personally took
> the task to finally make it happen (unwillingly, but I did commit and spend
> quite a bit of time on it, so I deserve the rebuke).

The two other volunteers are a moot point by now. It has been years
since you took it onto your plate. You said you've put quite a lot of
time into it. Where is the evidence? There is at least one user who
used to come into IRC monthly and ask about it. I never saw you reply
to him. There's a resounding silence on the topic.

What level of coaxing and prodding will bring this about? Those few of
us who are willing to risk goodwill over getting new releases out feel
we will be treading awfully dangerously if we push our luck on too
many topics. We talk sometimes about "pumpkin holders" in this list
and you're very nearly a pumpkin patch. I've offered at least once to
take this on. I always see myself as floating somewhere intermediate
between a developer and a module creator. If NASB needs a little of
both, then that's exactly what I like to focus on.

>
> I have been following the discussion on the SFTP patch and hadn't seen it
> come to a conclusion yet regarding what might be necessary to detect SSL
> support in cURL. I don't feel I've been negligent with this.

I replied in the SFTP thread to this with what I've found so far.

>
> I have no sympathy and honestly think the email Jaak sent was rebellious by
> nature, having never had a patch submitted by Jaak, nor any recent complaint
> or correspondence, along with the accusation of issues with "code quality"
> being the reason for the fork.
>
> I take the criticism I deserve, but none of your valid criticisms have
> anything to do with the original thread.
>
> Regarding release schedules, our private email conversation, Karl, were
> productive and I thought I had outlined a plan to you. I accept the
> accusation of a deficiency in release times. I tend to be a perfectionist
> and want to get everything in that I know is pending before a release, we
> keep SVN very stable-- worst case, packagers already apply patches to our
> releases and can easily release a distro package from HEAD if they choose--
> but I told you I would move forward with a plan to settle with what we have
> in HEAD now and release unless we had warranted pending items from an
> actively developed solution to a problem voiced. I'm not sure why the public
> criticism now, but accepted.
>
> Feel free to publicly vent your frustrations about release schedules, but
> please start a thread that warrants constructive conversation rather than
> the heavily loaded, non-constructive, generic insults expressed by a
> non-contributor which started this thread.

So in this thread I see two currents of discontent:
1) The barrier to entry is too high. Jaak wants to know how to become
a SWORD contributor. He wants to know how to submit patches, branches,
and fixes for problems he sees in the code. This list has brought up
the following multiple times:
a) The website is somewhat of a mess. We have a decent path for a
developer to find the location of our SVN, or to download releases.
Not much else, etc. This is a whole can of worms itself as we've
discovered and let's not re-visit that issue in this discussion. It
has proven impossible to rework the site by committee/too many
cooks/etc. Maybe someone just has to be deignated The Website Guru and
given privileges to implement updates over the protestations of the
rest of us.
b) Lack of exposure of documentation. Yes, I maintain the Doxygen
files in my personal space on crosswire.org and they're linked from
the wiki. But that's where most of the documentation stops. You had
started a series of "Learn to love the API" or whatever it was
messages - were those moved to the site somewhere? There's still no
mention of the wiki anywhere on the site that I can find. At this
point it even has some helpful material in it and I reference it ever

Re: [sword-devel] SFTP Support

[Greg Hellings]

>From the other thread, Troy writes:
"I have been following the discussion on the SFTP patch and hadn't
seen it come to a conclusion yet regarding what might be necessary to
detect SSL support in cURL. I don't feel I've been negligent with
this."

I guess we had a chicken/egg type problem because I was waiting to
hear back from Peter on his success and you on what you thought of it
before going further.

>From what I have seen and read on libcurl - which has not yet been
complete - seems to indicate that there is no build-time way to know
if the library has SSH support enabled. This seems incredible to me,
so I'm going to press on with getting a firm answer to that. At
runtime the library handles transports that it doesn't support and
transports it was optionally compiled without identically - by issuing
a general statement to the user that no such transport is available.
Peter's initial response includes that line in the output of
installmgr: "CURLFTPTransport: TEXT: Protocol sftp not supported or
disabled in libcurl".

I'm presuming SWORD already has handling for such an error? Obviously
installmgr prints the error to stdout/stderr. But it seems like that's
the only real way to determine. If we wanted to, we could probably try
to run a test at configure-time for that, but I know I would freak out
if I was configuring a library to build and received a message from my
firewall that it was trying to connect out to the network.

I suppose, if there's no indication at build-time, that there will be
no way for us to know if support is available other than this error.

--Greg

On Tue, Dec 4, 2012 at 1:45 PM, Greg Hellings  wrote:
> You shouldn't need to compile anything more than libcurl, which I thought to
> be a relatively small library.
>
> --Greg
>
> On Dec 4, 2012 1:29 PM, "Peter von Kaehne"  wrote:
>>
>> On 04/12/12 17:04, Peter von Kaehne wrote:
>> > In essence it does not work on Ubuntu (and maybe Debian) and it will
>> > not work in future - unless one builts their own libcurl. Peter
>>
>> I am trying this right now out. But it is a major undertaking to build -
>> takes a long time so far on a perfectly well specced laptop with c2d,
>> 4gb ram, a nice ssd.
>>
>> I presume, if this gets properly added, it requires a buildtime check
>> for presence of libssh and libcurl ability to use it. Otherwise we are
>> in a world of pain with bug reports for which there is no reason.
>>
>> Peter
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] New public git mirror of Sword SVN trunk and why

[Greg Hellings]

On Mon, Dec 17, 2012 at 4:48 PM, Troy A. Griffitts  wrote:
> Hi Jaak.  Of course I would discourage confusing potential developers with
> an unofficial fork of the SWORD library on gitorious.

I have been maintaining a personal SWORD repository on github for
quite some time now (github.com/greg-hellings/Sword). It hasn't seemed
to cause any confusion, but I make sure that  is always
identical to SWORD's official Subversion  branch. I mainly use
it to shuttle my own branches and changes around from environment to
environment and to share them with others before I make a patch
against  for submission.

>
> But I'm confused by your comments.
>
> My apologies if I have any outstanding commits in my queue from you which I
> haven't committed.  Do I?

I don't know about ones from Jaak, but I haven't seen a reply from you
about my SFTP patch submission (maybe I missed it?). It was a direct
feature request from a user in #xiphos and I already have a patch
prepared for Xiphos to support it. Our friends at Wycliffe are also
very excited about it because they are unable to expose FTP and HTTP
is a pain on their end and not well supported - but they are already
prepared with SSH/SFTP access for their target users.

>
> My complaint against the Bibletime code is that they inefficiently use the
> SWORD engine by trying to wrap everything in their own classes which even I
> have trouble understanding the intent.  SWORD was made to be used in a
> frontend, and we make it pretty easy to use. I use it directly in the
> frontends and projects I have written and cater it to real frontend needs.
> Bibletime, for the long life of the project, has said they want to maintain
> this wrapper layer around SWORD such that they can replace SWORD with an
> alternate backend in the future.  This has never happened, and I the
> Bibletime frontend code which has been 'protected' from SWORD has itself
> been rewritten many times, as far as I can see from the mailing list.  And
> though we've tried to encourage collaboration for years, we have seen next
> to zero contributions to SWORD from any of the Bibletime team (no offence to
> Greg and others who contribute to many projects and who do contribute to
> SWORD).  I have tried to get participation, but I usually only get
> complaints and arrogant calls for a complete rewrite from developers who
> don't even understand what's under the hood.

Perhaps a little background, which I present as objectively as I can:

One of the main complaints that's been going through IRC the past 3-6
months has been lack of a new release of the engine. Back in the
Spring we were gearing up for what was already a seemingly over-due
release. If my memory serves, you had said we would do a beta sometime
in April or May with the intention of releasing by June 1. You then
had a personal emergency that caused a delay in that time schedule,
but nothing has ever come since then - no comment, no response to a
timeline for a new release. I'm not sure if anyone else has been
christened as being allowed to cut alpha/beta/rc/final releases of the
engine, but if so they didn't step up to fill the gap.

Today's most recent bug that Jaak found in the engine is an
incompatibility with llvm+clang that causes compile failure in that
realm. This could pose an issue going forward as Apple has switched to
llvm+clang for its default compiler in Snow Leopard and I believe BSD
is going that direction as well. Turns out his bug is already fixed in
Sword's SVN (I'm guessing from gcc 4.7 patches?) but BibleTime can
only reliably track released versions for the sake of packaging
systems.

The discussion of the above bug, along with existing updates that are
in SWORD SVN (XHTML, HTTPS, deprecated API functions) but which are
not released led to some discussion in IRC about how to get reliable
releases out. Suggestions of bundling SWORD SVN in the application
were mentioned (but Linux packagers will absolute forbid that); once
again the suggestion of making BibleTime not rely on SWORD was
mentioned (a significant amount of effort would be required, but it
would be possible); also entertained was forking the project and
maintaining a separate project that would have no changes to the code
but would just make predictable releases of the engine (but that would
mean yet another thing for distros to package and for client build
systems to search for as a replacement to SWORD - thus representing a
huge barrier to such a fork doing any good).

But at this point BibleTime has apparently fielded at least one issue
related to building against SWORD's headers in a clang environment and
Xiphos is committed to using the XHTML filters. Both projects are,
therefore, desperate for a new release of the engine and some
developers are starting to wonder aloud if forking SWORD is the only
way that

Re: [sword-devel] cmake python

[Greg Hellings]

On Mon, Dec 17, 2012 at 5:32 AM, Ben  wrote:
> Cool, thanks. Also, I was looking at the tests, and it didn't look to me
> like cmake was building the tests directory properly, so I actually went
> back to using the old build system. If you want to commit any changes to
> build the tests, that would be helpful to me (or maybe I missed
> something...).

What does it seem to be doing improperly? That's a very broad
statement. I pretty much don't build the tests because they aren't
really kept up with and are intended to be a thing for people actively
developing on the engine, not for packagers, users, or client app
writers - which is the main hat I wear.

--Greg

>
>
> -Ben
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] cmake python

[Greg Hellings]

On Sat, Dec 1, 2012 at 9:44 PM, Ben  wrote:
> On 11/21/2012 10:27 PM, Ben wrote:
>>
>> Hello,
>>
>> A couple thoughts related to building python bindings with cmake:
>>
>> 1. /bindings/swig/python/setup.py has the following line:
>> #!/usr/bin/python python
>> Looks like that should just be /usr/bin/python, or /usr/bin/env python?
>>
>> 2. It'd be nice to be able to install the python module to some
>> non-standard location, so as to not require root access or conflict with
>> system packages.
>> /bindings/swig/python/install.cmake - I added --user to the
>> python setup.py install command, and that installed it just to my user
>> directory. That doesn't require root access, although it still might
>> conflict some with a system package. Another option might be to just
>> install the python bindings to the same custom prefix as the sword
>> library? Not sure what the best way is to implement this option.
>
>
> I'm attaching a patch that corrects number 1. For number 2, I set it up to
> allow installing the python Sword module to the user's directory, if
> -DPYTHON_USER_INSTALL=Yes is passed to the cmake command. If the option's
> not there, it just operates as normal.

I committed a fix for 1. It's more of a linting issue than a functional issue.

>
> I tried to set it up with running "python setup.py install --home=",
> but I didn't get it working with directories with spaces in the path.

I'll experiment with some ways to do this. I have already done a solid
reworking of the Python build and install process and cleaned up quite
a few warnings since the last SWORD release so they build much more
cleanly now. This is a good change to have as well.

The cmake install system should allow quite a bit more ease of
flexibility for configuring and installing to target locations. I will
try to remember to add this when I add that functionality as well.

--Greg

>
> Feedback and suggestions are welcome.
>
> Thanks,
> -Ben
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] filter patch

[Greg Hellings]

On Thu, Dec 13, 2012 at 11:03 PM, Chris Little  wrote:
> Most of the uses of  are found in the HTMLHREF filters, and I believe
> almost all front ends use these filters. Nothing will change in those
> filters, so nothing need be changed in front ends using HTMLHREF.

The next version of Xiphos will use XHTML but previous versions relied
on HTMLHREF. If you want to see how it affects things, you can do a
source build of Xiphos SVN HEAD against SWORD SVN HEAD and you should
be seeing the XHTML results.

BibleTime extends HTMLHREF but heavily modifies it. I don't know if it
ever encounters or handles . The string '' only appears once
in the BibleTime source code and that is in a C++ comment.

--Greg

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] filter patch

[Greg Hellings]

On Thu, Dec 13, 2012 at 8:31 PM, Ben Morgan  wrote:
> G'day Ben,
>
> From the viewpoint of a frontend developer, I don't really want this change
> committed.
>
> If this change is committed, it will break existing frontends which look for
> , and it produces little or no benefit -  may be invalid, but I
> think it will just get ignored.
> We already don't really have a good way to generate completely validated
> HTML as it is as too many of the existing modules have markup issues (I've
> been running across these recently...)

I disagree with this mentality. I remember learning a basic principle
of software engineering - be very rigorous about what you produce and
very lenient about what you accept. If we claim to produce HTML or
XHTML then by all means we should produce as close to that as
possible. But if we say we accept OSIS of a particular format, then we
should be as lenient as is safe and reasonable about deviations from
that. Both of these make a better experience for our users.

If a user of the engine - be that a front end developer or any other
application that might connect to SWORD - receives exactly what they
expect, then we save them the trouble and frustration of figuring out,
"What is this invalid HTML that I'm receiving? I thought this was an
HTML filter..." Likewise, if we accept modules that might have a
little bit of typos or errors in them but are "close enough" that we
can figure out how to handle it, then we give our module creators a
pleasant experience.

The import utilities are pretty snazzy about accepting a wide range of
input from the users, even if it is not exactly perfect. So that means
there might be some modules out there that don't parse exactly well
into our output targets. But that doesn't mean we ought to be lax in
what we produce. We should be very particular about only producing
what is documented. If our APIs and docs state we produce valid HTML
fragments then we should and this is a bug in either the software or
the documentation. If they state that we produce proto-HTML with
certain strings (like ) that need post-processing by the client,
then the current behavior is fine.

As to the matter of breaking front-ends, library upgrades are going to
do that anyway. The current development head of BibleTime does not
even compile against the current development head of SWORD because the
API has changed - so we have to maintain a compatibility branch that
includes changes which are going to be in the next release of SWORD
(*whenever that might be). If this behavior changes, it will be
another thing that we have to keep abreast of and update. I don't
think that changing the behavior of the library and documenting that
output has changed from  to  will be such a hardship on
applications, especially if it puts us in line with our documentation.

So it really comes down to: what do we claim to produce, and does our
library produce it? If not, then this is a bug that needs to be
addressed by changing the library or changing our claims.

--Greg

>
> If it is ever a problem for anyone, I think it's easy enough to instruct
> them to do the replacement just like everyone already does.
>
> God Bless,
> Ben
> -
> For I have no pleasure in the death of anyone,
> declares the Lord God; so turn, and live.”
> Ezekiel 18:32 (ESV)
>
>
>
>
> On Fri, Dec 14, 2012 at 12:45 PM,  wrote:
>>
>> Hello,
>>
>> I came across the following output in various filters: . A comment
>> in the code talks about this being a silent html comment that the
>> front-ends can replace if desired. However, that tag is not valid
>> (x)html (I guess it used to be a valid comment).
>>
>> I'm attaching a patch that replaces  with , so that it's
>> valid html or xhtml output, in all the filters where I found .
>>
>> If anyone would be willing to commit this, that would be great. Or, if
>> there are changes/improvements/problems with the patch, please let me
>> know.
>>
>> Thanks,
>> -Ben
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

You shouldn't need to compile anything more than libcurl, which I thought
to be a relatively small library.

--Greg
On Dec 4, 2012 1:29 PM, "Peter von Kaehne"  wrote:

> On 04/12/12 17:04, Peter von Kaehne wrote:
> > In essence it does not work on Ubuntu (and maybe Debian) and it will
> > not work in future - unless one builts their own libcurl. Peter
>
> I am trying this right now out. But it is a major undertaking to build -
> takes a long time so far on a perfectly well specced laptop with c2d,
> 4gb ram, a nice ssd.
>
> I presume, if this gets properly added, it requires a buildtime check
> for presence of libssh and libcurl ability to use it. Otherwise we are
> in a world of pain with bug reports for which there is no reason.
>
> Peter
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

I would still call that a bug. :)

Alternatively, have you installed the libcurl-ssl-dev package? That might
have what you need. But I wouldn't hold my breath.

--Greg
On Dec 4, 2012 11:06 AM, "Peter von Kaehne"  wrote:

> On 04/12/12 16:43, Greg Hellings wrote:
> >  or your distro does not include those as
> > build-time dependencies and you should file a packaging bug with your
> > distribution.
>
> Indeed. But not a bug, but a conscious decision!
>
> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/175891
>
> This is so annoying.
>
> In essence it does not work on Ubuntu (and maybe Debian) and it will not
> work in future - unless one builts their own libcurl.
>
> Peter
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

Peter,

I see two problems:

1) You need to specify Username and Password in your InstallMgr.conf
file. This is clearly NOT ideal, as the values are stored in plain
text. Alternatively, you can have key-based authentication and just
include the username - but you have to have your keys stored in
~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. These values can be changed, but
doing so was beyond the scope of my initial plan as it would require
additional fields in InstallMgr.conf. For me, that is a bit of an
issue because I use RSA keys, but the problem can be resolved by just
symlinking between id_rsa and id_dsa and their .pub files.

If this becomes a viable option, we might want to consider a
modification to InstallMgr.conf which permits public-key
authentication methods to be specified.

2) Your "CURLFTPTransport: TEXT: Protocol sftp not supported or
disabled in libcurl" debugging output line indicates that, even if you
provide your username/password combination then it wouldn't work as
your build of libcurl was not linked against libssl/libssh. Either you
built it yourself and didn't have the development files for those
libraries installed or your distro does not include those as
build-time dependencies and you should file a packaging bug with your
distribution. In Fedora, the command "ldd /usr/lib64/libcurl.so"
reveals links to libssl.so.10, libssl3.so and libssh2.so.1. I'm
guessing the equivalent ldd for you would show at least libssh2
missing from your libcurl build.

See if getting a properly built libcurl resolves (2) and then we can
see if there are debugging output complaints about (1) that we can
resolve in a secure manner for you without further changes to SWORD -
although I presume we will need to implement such changes if SFTP is
to be supported properly.

--Greg

On Tue, Dec 4, 2012 at 4:13 AM, Peter von Kaehne  wrote:
> On 04/12/12 05:28, David "Judah's Shadow" Blue wrote:
>
> Greg Hellings  wrote:
>>
>> The attached patch will introduce support for SFTPSource transports in
>> the SWORD engine, allowing a user to access remote repositories over
>> SFTP (which is enabled by default when a user enables SSH).
>
>
> This is a brilliant idea, Greg, particularly for having access to private
> modules on the road.
>
> 1) It applies and compiles cleanly
> 2) installmgr continues to function with the standard protocolls.
>
> Unfortunately when trying to use it I get the (username edited) debug
> message attached below from installmgr. What I had done is I added a line to
> my InstallMgr.conf:
>
> SFTPSource=Home|backup|/home//.sword|||
>
> "backup" is resolved in my /etc/hosts file to my NAS which is accessible via
> ssh. /home//.sword is the path from /
>
> Am I doing something wrong or is there something malfunctioning? I tried
> also @backup as servername
> ---
>
> netCopy: backup, mods.d.tar.gz,
> /home/peter//.sword/InstallMgr/backup/mods.d.tar.gz, f,
> * using CURLOPT_FTP_USE_EPRT
>
> * About to perform curl easy action.
>
> * destPath: /home///.sword/InstallMgr/backup/mods.d.tar.gz
>
> * sourceURL: sftp://backup/home//.sword/mods.d.tar.gz
>
> CURLFTPTransport: TEXT: Protocol sftp not supported or disabled in libcurl
>
> CURLFTPTransport: TEXT: Unsupported protocol
>
> * Finished performing curl easy action.
>
> netCopy: failed to get file
> sftp://backup/home//.sword/mods.d.tar.gz
> netCopy: backup, mods.d, /home///.sword/InstallMgr/backup/mods.d,
> t, .conf
> NetTransport: getting dir sftp://backup/home//.sword/mods.d/
>
> * using CURLOPT_FTP_USE_EPRT
>
> * About to perform curl easy action.
>
> * destPath:
>
> * sourceURL: sftp://backup/home//.sword/mods.d/
>
> CURLFTPTransport: TEXT: Protocol sftp not supported or disabled in libcurl
>
> CURLFTPTransport: TEXT: Unsupported protocol
>
> * Finished performing curl easy action.
>
> FTPURLGetDir: failed to get dir sftp://backup/home//.sword/mods.d/
>
> NetTransport: failed to read dir
> sftp://backup/home//.sword/mods.d/
>
>
> Error Refreshing Remote Source
>
> -
>
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] SFTP Support

[Greg Hellings]

It also has the added benefit of being one of the easiest ways for
people to expose their personal repositories to their other devices -
e.g. mobile or simply other remote systems. For myself, I know, SFTP
is the easiest type of remote file access to expose.

Safety of users is what initially prompted someone to ask on IRC about
SFTP/SCP availability (SCP is more difficult as, from what I've read,
it does not provide a straightforward mechanism for giving directory
listings whereas SFTP returns the same listing format as FTP).

Also, this permits entities to expose private repositories to either
internal users or testers. I work on-and-off with a group at Wycliffe
that is required to adhere to strict legal standards with regards to
some of the modules they produce. They have been asking for a way to
securely expose file repositories to members - FTP is not an option
because their IT department will not punch FTP holes in their
firewall, and HTTP/HTTPS authentication is much more tedious to setup.
So when a user asked about SSH-based access and I saw it was trivial
with libcurl I went ahead and implemented it.

If someone with commit privileges to those files could land the patch
or if I could get access to land it, I'd be appreciative.

--Greg

On Mon, Dec 3, 2012 at 11:28 PM, David "Judah's Shadow" Blue
 wrote:
> Greg Hellings  wrote:
>>
>> The attached patch will introduce support for SFTPSource transports in
>> the SWORD engine, allowing a user to access remote repositories over
>> SFTP (which is enabled by default when a user enables SSH).
>>
>> --Greg
>>
>> 
>>
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
> That would be really helpful especially wrt hostile areas if you are
> discerning with what repos you trust.
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] SFTP Support

[Greg Hellings]

The attached patch will introduce support for SFTPSource transports in
the SWORD engine, allowing a user to access remote repositories over
SFTP (which is enabled by default when a user enables SSH).

--Greg


sftp_sword_support.patch
Description: Binary data
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page