Re: [sword-devel] Android SWORD
Hello, With the discussion on which back end to use, would it make sense to write a JSword adapter to the interface described by Troy below? This would enable the back ends to be swapped out with minimal effort (maybe even at runtime). -Bill On Wed, Oct 21, 2009 at 4:05 AM, Troy A. Griffitts scr...@crosswire.orgwrote: A quick update on Android progress. o Basic Bible navigation and display are working, albeit not pretty. o Text-to-Speech functionality is added. o All methods from the engine are now completely wrapped to the same swordorb.idl interface we use for SWORDWeb's Java-CORBA-C++ bridge, so a full-featured Android client should now be possible with the current engine exposure. Everything is still at the same location (below). -Troy. Troy A. Griffitts wrote: There is now a preliminary Android NDK / Java binding available in SVN. This is very very early and should just be considered a proof of concept. There is a package available to show things working, but doesn't really do much: http://crosswire.org/~scribe/bishop.apkhttp://crosswire.org/%7Escribe/bishop.apk the JNI libsword.so should be placed in your project/libs directory, e.g., ~/workspace/bishop/libs/armeabi/libsword.so and can be obtained from the above package-- believe me, you don't want to try to compile it yourself as the NDK does not have STL support out of the box. The Java classes can be obtained from the sword/bindings/java-jni/src directory, e.g. http://crosswire.org/svn/sword/trunk/bindings/java-jni/src/org/crosswire/android/sword/ Module library must exist on your SD card under a 'sword' directory to be found, e.g., unzip KJV.zip to /sdcard/sword/ Have fun, let me know if anyone else is interested in developing an Android frontend. -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
Re: [sword-devel] Android SWORD
Hello, On a related note, could this project be hosted on http://github.com? It would provide much better ability to collaborate since anyone can fork, make changes and then push them back for optional inclusion. The built-in wiki would make it easy to publish any appropriate docs. For an example of why this would be helpful, I have some libsword swig bindings for Ruby that never got committed because no one who was a commiter had the time or inclination to step up and look at them. If I could have forked the swig bindings, and checked in my changes, then whether or not they became incorporated in the official version, they would be readily available for anyone to find, evaluate and/or fix. Just my $0.02. Thanks, -Bill On Sat, Aug 28, 2010 at 11:33 PM, Kenneth Arnold kcarn...@alum.mit.eduwrote: Hi Martin and Troy, I finally got the AndBible source built; I needed to get the jsword source and also raise the memory limit for Eclipse--it thrashed and eventually crashed in the linker/dex step. There's still a dex warning that floods the Console, but it works on my Droid X. I made a few minor modifications to ensure I could, but nothing serious yet. Major things I'd like to work on as a user are navigation, continuous scrolling, and verse number sync. Also, do you think we should replace the backend with native libsword? That might help formatting and speed, but I don't know how deeply it's woven into the code. The Bishop code could be a useful example if we decide to go that way. Should we continue discussion on this list? -Ken (mobile) On Aug 26, 2010 1:39 AM, Troy A. Griffitts scr...@crosswire.org wrote: Dear Ken, Thank you for the debug. I also have had trouble with the installer and haven't had time to look into it. The history is that I build Bishop as a sort of proof of concept for the java-jni bindings for Android. I mostly work in the engine code. The jni binding code I kept in SWORD SVN and the Bishop code I just backed up occasionally to our server. Last year my drive crashed and I lost some work but might have pieced it all back together. Here is an email I sent to Gary with links to all my stuff. __ After last year when I started the work I had a harddrive die on my laptop. I had been backing up the work regularly, but lost about 2 weeks of work in the crash. I used a recovery tool to salvage many of the files from the bishop project and think I may have close to what is in the apk. Here are my resources if you want to try to piece things together: Lastest binary when I stopped, dated 11-18-2009: http://crosswire.org/~scribe/bishop.apkhttp://crosswire.org/%7Escribe/bishop.apk Latest backup of source, dated 10-31-2009: http://crosswire.org/~scribe/bishop-20091031.tar.gzhttp://crosswire.org/%7Escribe/bishop-20091031.tar.gz Latest binary after reconstructing source and I think some small new work (I think this is built with debug symbols in the native library so it's a little bigger): http://crosswire.org/~scribe/bishop2.apkhttp://crosswire.org/%7Escribe/bishop2.apk Current backup of source which built the above: http://crosswire.org/~scribe/bishop-20100804.tar.gzhttp://crosswire.org/%7Escribe/bishop-20100804.tar.gz Please excuse my ignorance of Android programming. I am fumbling through it all. I remember having trouble with the InstallMgr. It sometimes connects and downloads and other times it does not. I thought it might be the limited memory on my G1 or some trouble with the timing of the FTP code in the native library. I've found serious bugs in Android's system calls, (e.g. memccpy) and reported it to them, but they still haven't fixed it. I use my own version in the ftp lib to avoid the bug. That is where I stopped-- thinking I needed to debug this ftp intermittent issue. I didn't compare how well the older .apk works versus the newer .apk. Maybe the older version worked better? Or maybe a newer version of Android or new phone works better? Let me know what you find. Troy On 08/24/2010 09:01 PM, Kenneth Arnold wrote: I just got an Android phone, and after seeing the... ___ 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 -- Bill Burton bbur...@mail.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
Re: [sword-devel] Cocoa SWORD?
Hello Jon, Not sure if this will help or not but on a related note, someone made available Sword 1.5.7a via MacPorts ( http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/sword/Portfile) along with a number of modules. Unfortunately, this has not been maintained. It would be nice to get this port updated for 1.5.10. MacPorts seems to be a good way of making available software that needs to be built and installed for OS X. By default, it installs into /opt/local to keep away from anything manually built and installed into /usr/local. -Bill On Dec 17, 2007 2:11 PM, Jon Brisbin [EMAIL PROTECTED] wrote: I'm trying to learn to write Cocoa/Python apps on my new OS X Leopard MacBook Pro. I'm traditionally a Java and Web programmer, so I'm not really in my element here. I've downloaded and compiled the sword API, but I haven't installed it because I think I want to include the .dylib in my project directly, rather than installing it in my /usr/local, right? Doing a make install on it would break portability, if I'm understanding it right. I think my first task is to get the SWORD API built into a Mac OS X framework. Has anyone done this already? Or do you just link against a command-line-compiled version of the .dylib? First of many questions, I'm sure... Thanks! Jon Brisbin http://jbrisbin.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
Re: [sword-devel] SWORD 1.5.10
Hello, On 6/19/07, Troy A. Griffitts [EMAIL PROTECTED] wrote: Agreed. There have been many bug fixes. If anyone would like to get any other fixes in, please do so very soon. I'd like to get my Ruby SWIG bindings in if possible. However, in thinking about SWIG and other bindings, maybe they should be released separately as they require the Sword libraries to be already installed to build them and aren't necessarily tied to the Sword release that includes them. Thoughts? -Bill -Troy. Karl Kleinpaste [EMAIL PROTECTED] wrote: Troy A. Griffitts [EMAIL PROTECTED] writes: I should have tested it better before release. My apologies. Thank you for reporting the problem. I will also have a look at the InstallMgr status bars and try to release a new BibleCS within a few days. Might there be any estimate as to when a new release of the Sword libs will happen? There have been a number of fixes since last October's 1.5.9, some of which have significant effects on GnomeSword's operation. A 1.5.10 (or just 1.5.9.1) release would be hugely appreciated soon. ___ 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] Copying scripture quickly for presentation
Hello, Sounds like what you want is a presentation mode for Bible CS or other Sword front end that would have a simple input field to enter the scripture reference and then would hide the input field displaying the verse(s) in a large font taking over the whole screen like PowerPoint, etc. Another kind of integration might be possible using a web browser for the presentation. Both Firefox and IE support a Full Screen mode by going to View, Full Screen or function key F11. It would be a matter of writing a script or program as a wrapper around Diatheke (for instance) to generate the verses to a file and then wrap it with appropriate HTML and CSS and then invoke the browser with this file as the argument. You would have to configure the browser such that subsequent invocations replace the existing content rather than opening a new window or tab. Also possible is a mini web server application interface to Sword. You can then keep all your user interactions within the web browser. Hope this helps, -Bill On 2/9/07, Jari Strand [EMAIL PROTECTED] wrote: Hello. Our church is using power point presentations to display scripture but this requires copy and paste every time which is too slow if you need to show something on request. So I was wondering if there are any plans for some sort of verse exporter that would generate a html page or even better a power point presentation from selected verses? Thank you. I would probably be writing something like this for SWORD project if I'd knew the source that well. ___ 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] Python and swig
Hello Jason, On 2/1/07, Jason Turner [EMAIL PROTECTED] wrote: I recently worked on the swig bindings themselves, but I agree the build process is pretty broken. I modified the .i files, but left the build process how it was, focusing instead on the visual studio related files for building the bindings with VS.net. It's good to hear about someone else working on the SWIG bindings. I've spend quite a bit of time updating the bindings to work with Ruby and would like to submit a patch. All my changes are conditioned with #ifdef's so it shouldn't affect any other language bindings. However, it would be helpful if others can test their languages to ensure everything still works the same way it did previously. If anyone is interested in cleaning up the building of bindings, let me know, I'd be happy to test and commit the patches. One thing that would make the process easier on (Unix/Linux at least) for users building from a released version of Sword is when the tarball for the next release is created, to update bindings/swig/package/configure.ac with the release Sword version and then run ./autogen.sh to create the configure script. A second thing that should be done is to put a README file in the bindings/swig folder explaining how to build, link and install the bindings for each supported language. Either of these two things would have saved me a lot of time figuring out to to build the bindings for any of the existing languages. One thing I was wondering was the reason for the package folder under bindings/swig and why all the .i files are copied there instead of just referencing them in the bindings/swig folder? May God bless His Word, -Bill God Bless -Jason On 2/1/07, Pierre Amadio [EMAIL PROTECTED] wrote: Hi there On Tue, Jan 30, 2007 at 10:27:27AM +1100, Ben Morgan wrote: To get all book names and chapter counts in old and new testaments: Thanks a lot, things are much more clear now :) ___ 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] How to submit a patch for Ruby SWIG bindings?
Hello, Any thoughts on this? -- Forwarded message -- From: Bill Burton bburton at mail com Date: Dec 1, 2006 4:06 PM Subject: How to submit a patch for Ruby SWIG bindings? To: SWORD Developers' Collaboration Forum sword-devel@crosswire.org Hello, I've been working on adding Ruby language support to the existing SWIG bindings. So far, the autoconf part is nearly done and I've been working on fixing the API linkage where SWIG fails to translate or doesn't do so in an optimal manner. For API docs, I've been writing a skeleton Ruby file that can be processed with Ruby's rdoc utility. Thus far, I've been copying over the C++ Doxygen comments and then reformatting them into rdoc format. Questions: * When ready, should I just submit a patch to the list or is there some other procedure? * Would it be better to submit more than one smaller patch or one jumbo patch? * Since refining and testing the API is going to take some time, would it make sense to create an svn branch to work in? I'd like to also create unit tests and have a place for the API rdoc file to live. * Is there anyone listening who's supporting SWIG bindings to the other languages? My changes shouldn't affect any of the other languages but it wouldn't hurt to have someone test and make sure. Thanks, -Bill ___ 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] How to submit a patch for Ruby SWIG bindings?
Hello, I've been working on adding Ruby language support to the existing SWIG bindings. So far, the autoconf part is nearly done and I've been working on fixing the API linkage where SWIG fails to translate or doesn't do so in an optimal manner. For API docs, I've been writing a skeleton Ruby file that can be processed with Ruby's rdoc utility. Thus far, I've been copying over the C++ Doxygen comments and then reformatting them into rdoc format. Questions: * When ready, should I just submit a patch to the list or is there some other procedure? * Would it be better to submit more than one smaller patch or one jumbo patch? * Since refining and testing the API is going to take some time, would it make sense to create an svn branch to work in? I'd like to also create unit tests and have a place for the API rdoc file to live. * Is there anyone listening who's supporting SWIG bindings to the other languages? My changes shouldn't affect any of the other languages but it wouldn't hurt to have someone test and make sure. Thanks, -Bill ___ 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] Ruby GEM and Rails plugin for the Sword API
Hello Nathan,On 11/9/06, lumin8 [EMAIL PROTECTED] wrote:
I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application.
Nice, I would be glad to help with a GEM and especially a Rails plugin.
Would it be beneficial if I set up a SVN repository for this code? Or
maybe you have one available already for it.Yes, SVN access would be fine. If they can't create a branch on crosswire for us (e.g. rubydl_binding) then you setting up something is fine with me.
I'll try to clean up the module and send it to you so you can start experimenting with it.Hopefully by late Saturday (EST).
Looking forward to it. By the way, I was able
to get Sword compiled, and did some looking around and experimenting
with things. I also found these two:Ruby/DL -
http://ttsky.net/ruby/ruby-dl.htmlRuby/DLX = http://ruby-dlx.rubyforge.org/index.xhtml
Are you using one of these for the flatapi?Yes, just the Ruby/DL that's included in the Ruby distribution. If you look in the modules for the dl folder, there's some examples and a doc file. It's also briefly mentioned in the Programming Ruby book in the modules reference for DL.
Ruby/DL can supposedly bind to C++ API's but then you have to deal with mangled names. I don't suppose those are portable between compilers so I haven't gone in that direction.-Bill
-=nathanOn 11/8/06, Bill Burton [EMAIL PROTECTED]
wrote:
Hello Nathan,On 11/8/06,
lumin8 [EMAIL PROTECTED] wrote:
Bill,Yes exactly.Sounds like you are doing some great work with this.I'm trying to figure out how I can help - at the least I could packageit as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application. However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application. At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile. The ActionService web service client support might be a good pattern to start with.
Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules. What I mean is you:* Can't get a list of all the books in a Bible.* Given a book name, can't get the number of chapters in the book.
* Given a book name and chapter, can't get the number of verses in that chapter.If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi.So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata. As versifications are different in some translations, you can't necessarily use the same information for all translations.
In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like VerseKey that can take any verse reference with a variety of abbreviations and return it in OSIS notation.
Let me know if I can help with anything else.
I'll try to clean up the module and send it to you so you can start experimenting with it.
In His Service,-Bill
-=nathanOn 11/7/06, Bill Burton
[EMAIL PROTECTED] wrote: Hello, I see.You want the module information in a database because it's then
trivial to program a web application using Ruby on Rails ActiveRecord object
relational mapping support.RoR also supports other logic in controllers such as web services clients so it's entirely possible to write an application that calls Sword without using a database but the scaffolding
code generator won't be able to help much if at all. It just so happens I've been working on a Ruby interface to Sword with a longer term goal of writing a Ruby on Rails application to access it.
Initially, I couldn't figure out how to build anything with SWIG--there's no README in the bindings/swig directory.Then it happened I discovered Ruby can load shared libraries and DLL's and dynamically bind to them on the fly
using the dynamic loader (DL) module.So I started to write a Sword interface to the C flatapi in bindings/flatapi.cpp.In the process, I found a few minor bugs with the flatapi but have created patches to fix them
(which I'll submit soon). Using this Ruby to Sword flatapi interface you can output verses as follows (I'm doing this from memory so it's not exact): include Sword # SWMgr_new(FMT_HTML)
Manager.new (Sword::FMT_HTML) do |mgr| module = mgr.get_module(KJV) # iteration using Sword API's under the covers to verseKey and renderText module.each_verse_render(Psalm 133:1-3) do |verse, text|
puts #{verse} #{text}# verse reference and text end end# performs an implicit SWMgr_delete So far, I've implemented about two-thirds of the Sword C flatapi.However,
the one issue I'm just starting to address is how to call these API's within a multi-threaded multi-user environment such as a web
Re: [sword-devel] Ruby GEM and Rails plugin for the Sword API
an SWORDWeb and the supporting code for the CORBA server. As for the API, the generated docs are available but not much helpusually.The API Primer is the best start of a primer that we have, buthasn't been updated for a while.Yes. I noticed it was using SetKey (which is deprecated) instead of setKey for specifying a verse reference to a module. Notheless, it's still helpful. We have a few examples in the sourceunder sword/examples/, and a really good place to try things out are the numerous sword/tests/ and sword/utilities/, though they are veryeclectic-- but serve as good examples, as well.Of course there are thenumerous frontends themselves, and finally sword/include/ I haven't seen the SVN or CVS for the front ends. What are they called? When I last checked, I couldn't browse at the /svn level or maybe I could see them. I would be more than grateful to have additions to sword/examples/Wrote a simple C program to experiment with the different iterators in the flatapi so I could then write a Ruby/DL version. It would be good to have at least one C program example as part of the build or a test to ensure that interface isn't broken again. Finally, if you get anything working and want to start tracking changesin source control, we would love have a ruby section under sword/bindings/ with your work and READMEs and examples and anythingelse you think helpful.Please let us know and we will get you accessto our source repository.If this Ruby/DL version pans out, creating a rubydl folder would probably the most appropriate place for it. As the Ruby SWIG version is looking promising, I'd like to contribute any changes to support it--Lord willing. Thanks again for considering using the engine.I realize you probablyhaven't made a firm decision yet, but any info you find, or work you develop, I'm sure will be helpful to the next person wanting to do Rubydevelopment with SWORD.Yes, very definitely. Warmest Christian greetings,-Troy.In His Service,-Bill lumin8 wrote: Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules.What I mean is you: * Can't get a list of all the books in a Bible. * Given a book name, can't get the number of chapters in the book. * Given a book name and chapter, can't get the number of verses in that chapter. If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi. Does anyone else on this list know the answer to this question?Also, where is the documentation for the Sword API - what are the features?I must be overlooking something. I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application. Nice, I would be glad to help with a GEM and especially a Rails plugin. Would it be beneficial if I set up a SVN repository for this code?Or maybe you have one available already for it. I'll try to clean up the module and send it to you so you can start experimenting with it. Looking forward to it. By the way, I was able to get Sword compiled, anddid some looking around and experimenting with things.I also found these two: Ruby/DL - http://ttsky.net/ruby/ruby-dl.html Ruby/DLX = http://ruby-dlx.rubyforge.org/index.xhtml Are you using one of these for the flatapi? -=nathan On 11/8/06, *Bill Burton* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hello Nathan, On 11/8/06, * lumin8* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Bill, Yes exactly.Sounds like you are doing some great work with this. I'm trying to figure out how I can help - at the least I could package it as a rails plugin or gem making it easy for any ruby on rails developer to get started with it. I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application. However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application.At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile.The ActionService web service client support might be a good pattern to start with. Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules.What I mean is you: * Can't get a list of all the books in a Bible. * Given a book name, can't get the number of chapters in the book. * Given a book name and chapter, can't get the number of verses in that chapter. If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi. So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata.As versifications are different in some translations, you can't necessarily use the same information for all translations. In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like
Re: [sword-devel] modules to relational database (Ruby support)
Hello Nathan,On 11/8/06, lumin8 [EMAIL PROTECTED] wrote:
Bill,Yes exactly.Sounds like you are doing some great work with this.I'm trying to figure out how I can help - at the least I could packageit as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application. However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application. At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile. The ActionService web service client support might be a good pattern to start with.
Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules. What I mean is you:* Can't get a list of all the books in a Bible.* Given a book name, can't get the number of chapters in the book.
* Given a book name and chapter, can't get the number of verses in that chapter.If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi.So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata. As versifications are different in some translations, you can't necessarily use the same information for all translations.
In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like VerseKey that can take any verse reference with a variety of abbreviations and return it in OSIS notation.
Let me know if I can help with anything else.I'll try to clean up the module and send it to you so you can start experimenting with it.
In His Service,-Bill-=nathanOn 11/7/06, Bill Burton
[EMAIL PROTECTED] wrote: Hello, I see.You want the module information in a database because it's then trivial to program a web application using Ruby on Rails ActiveRecord object
relational mapping support.RoR also supports other logic in controllers such as web services clients so it's entirely possible to write an application that calls Sword without using a database but the scaffolding
code generator won't be able to help much if at all. It just so happens I've been working on a Ruby interface to Sword with a longer term goal of writing a Ruby on Rails application to access it.
Initially, I couldn't figure out how to build anything with SWIG--there's no README in the bindings/swig directory.Then it happened I discovered Ruby can load shared libraries and DLL's and dynamically bind to them on the fly
using the dynamic loader (DL) module.So I started to write a Sword interface to the C flatapi in bindings/flatapi.cpp.In the process, I found a few minor bugs with the flatapi but have created patches to fix them
(which I'll submit soon). Using this Ruby to Sword flatapi interface you can output verses as follows (I'm doing this from memory so it's not exact): include Sword # SWMgr_new(FMT_HTML)
Manager.new (Sword::FMT_HTML) do |mgr| module = mgr.get_module(KJV) # iteration using Sword API's under the covers to verseKey and renderText module.each_verse_render(Psalm 133:1-3) do |verse, text|
puts #{verse} #{text}# verse reference and text end end# performs an implicit SWMgr_delete So far, I've implemented about two-thirds of the Sword C flatapi.However,
the one issue I'm just starting to address is how to call these API's within a multi-threaded multi-user environment such as a web application.Because the SWMgr_new/newEx and SWModule_* functions have state, it looks like a new
Manager object will have to be created per user which means establishing a session and then saving the Manager instance in the session.So I have to refactor the code to allow multiple instances of a Manager class without
loading the shared library every time. But then last night I was about to send an email to this list asking how to build the SWIG interface but I looked at it one more time and discovered how
to do it. With some more investigation I was then able to generate SWIG bindings for Ruby and build the interface to Sword.So far I've been able to access some of the methods from the SWMgr and SWModule classes but can't
output a verse because the binding of set_key to SWModule.SetKey is incorrect.This may be a bug in the way SWIG generated the binding but I don't know yet. The nice thing about the Ruby dynamic loader interface to Sword is there's
nothing extra to build which makes it much easier to install as compared with the SWIG version.However, the C flatapi on which it's based limits one to getting and setting global options, iterating over modules and
rendering verses.The SWIG interface to the C++ API's is much more complete but has to be built. I don't know yet if the Sword C++ API's also have state which is important to know for a web application.
Right now, I'm developing
Re: [sword-devel] sword-devel Digest, Vol 32, Issue 12
Hello,It looks like Xindice doesn't work as well with documents up to or over 5 MB. I would imagine uncompressed OSIS Bible text would be at least that large. Also, I wonder how well XPath would work very well with the OSIS format. -BillOn 11/7/06, Martin Gruner [EMAIL PROTECTED] wrote: This sounds very interesting. Is there something similar for C++?mgAm Dienstag, 7. November 2006 20:24 schrieb Yiguang Hu: If you have to think of other repository than sword module, how about xindice. It stores XML directly and you can access the data using XPATH. Sure xindice is young also. http://xml.apache.org/xindice/ --- [EMAIL PROTECTED] wrote: Send sword-devel mailing list submissions to sword-devel@crosswire.org To subscribe or unsubscribe via the World Wide Web, visit http://www.crosswire.org/mailman/listinfo/sword-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of sword-devel digest... Today's Topics: 1. Re: modules to relational database (Gabriel M. Beddingfield) -- Message: 1 Date: Tue, 7 Nov 2006 12:27:57 -0600 (CST) From: Gabriel M. Beddingfield [EMAIL PROTECTED] Subject: Re: [sword-devel] modules to relational database To: SWORD Developers' Collaboration Forum sword-devel@crosswire.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=iso-8859-1 You can split up any XML document at its nodes like osisID, div etc.into rows of a database that also holds the rendering context for each of thesenodes, and also information about the tree structure of the xml document(parent-children etc.). How deep you want to split it beyond osisIDdepends on what you want to do.From what I've seen, a lot (maybe most) of the serious bible texts have structured their documents like you would a book, and then littered it with milestones to mark where chapters and verses begin.E.g. !-- my aplologies for butchering ThML -- p ScripRef verse='Gen 1:1' /In the beginning, God created the heavens and the earth.ScripRef verse='Gen 1:2' / And the earth was shapeless and void... /p On the one hand, you can store the XML document in a relational database as an XML document... preserving each tag, location, attributes, etc.On the other hand, I would expect someone (like me or the OP) to try and divide things up by Book/Chapter/Verse: +--++---+---+ | Book | Ch | Verse | Text +--++---+---+ | Gen| 1| 1 | In the beginning, God created the | ||| | heavens and the earth. +--++---+---+ | Gen| 1| 2 | And the earth was shapeless and | ||| | void... +--++---+---+ To be clear on what I'm getting at... IMHO, I just don't think there's a large advantage to converting a module to a RDMS. If you preserve the original document (OSIS, ThML, etc.)... why not just leave it in OSIS, ThML, etc.?If you redo the schema to the RDMS, I think you'll end up with a lot of headaches that the XML/SGML schemas solve well.I can be convinced otherwise (after all, I really do love RDMS's)... but this is how I see it.-- G a b r i e l M B e d d i n g f i e l d ___ 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] Problems building 1.5.9 due to osiscgi.cpp
Hello, I'm having a problem building 1.5.9 on RedHat ES 3 because of an issue in osiscgi.cpp: if g++ -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -O2 -DCURLAVAILABLE -MT osiscgi.o -MD -MP -MF .deps/osiscgi.Tpo -c -o osiscgi.o osiscgi.cpp; \ then mv -f .deps/osiscgi.Tpo .deps/osiscgi.Po; else rm -f .deps/osiscgi.Tpo; exit 1; fi osiscgi.cpp: In member function `virtual bool sword::OSISCGI::handleToken(sword::SWBuf, const char*, sword::BasicFilterUserData*)': osiscgi.cpp:102: `isdigit' undeclared (first use this function) osiscgi.cpp:102: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [osiscgi.o] Error 1 make[2]: Leaving directory `/usr/local/src/sword-1.5.9/utilities/diatheke' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/sword-1.5.9/utilities' make: *** [all-recursive] Error 1 The following patch allows osiscgi.cpp to compile although I doubt it's appropriate in all circumstances: [EMAIL PROTECTED]:/usr/local/src/sword-1.5.9/utilities/diatheke% diff -u osiscgi.cpp.orig osiscgi.cpp --- osiscgi.cpp.orig2006-07-15 16:41:24.0 -0400 +++ osiscgi.cpp 2006-10-25 23:22:20.0 -0400 @@ -22,6 +22,9 @@ #ifdef WIN32 #include ctype.h #endif +#ifndef isdigit +#include ctype.h +#endif SWORD_NAMESPACE_START Thanks, -Bill -- Bill Burton [EMAIL PROTECTED] ___ 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] swordweb small updates
Hello, On 10/25/06, Gabriel M. Beddingfield [EMAIL PROTECTED] wrote: On Tue, October 24, 2006 12:53 am, Ben Morgan wrote: Hi. If you point swordweb to Genesis 2:18, using the original KJV, there is something funny happening. In Genesis 2, at least 6 verses aren't there, and some of the ones which are there do not appear fully. Something like this appears to be happening in the NASB as well for Genesis I'm seeing this, too. Having to resort to paper for today. :-( Me three. KJV 2006 is okay though. -Bill -- Bill Burton [EMAIL PROTECTED] ___ 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] swordweb small updates
Hello Troy, I checked Genesis 2 in the NASB and older KJV and they both appear fine here. -Bill On 10/25/06, Troy A. Griffitts [EMAIL PROTECTED] wrote: Hey guys. Thanks for the report. I believe I've fixed this problem. Please report if you still see trouble. -Troy. Bill Burton wrote: Hello, On 10/25/06, Gabriel M. Beddingfield [EMAIL PROTECTED] wrote: On Tue, October 24, 2006 12:53 am, Ben Morgan wrote: Hi. If you point swordweb to Genesis 2:18, using the original KJV, there is something funny happening. In Genesis 2, at least 6 verses aren't there, and some of the ones which are there do not appear fully. Something like this appears to be happening in the NASB as well for Genesis I'm seeing this, too. Having to resort to paper for today. :-( Me three. KJV 2006 is okay though. -Bill -- Bill Burton [EMAIL PROTECTED] ___ 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
