Simon Lagendijk wrote:
I wasn't aware of that. I searched the crosswire website for some diagrams, but couldn't find one. But if the Sword Engine does already contain a nice architecture, I can better spend my time in programming with the Sword Engine.
Thank you for your heart! It's hard sometimes when it seems people might be more interested in starting their own project than working together.
One question about the architecture of the Sword Engine: Does each module knows what it contains? In other words: if I have a bible module, does that module 'knows' which bible books it contains, and how much verses in each chapter? The reason I ask is because I don't want a fixed versification scheme, like that of the KJV, which makes it impossible to have the apocryphia or the book of mormon, or what else people want to add as an addiction to the canonical books (I am a protestant christian, so for me the apocryphia not that important, but there are people who consider them as holy). Another reason for wanting to have that information is to only show the biblebooks the module really contains. Can you please tell me if this problem exists, and what is planned to fix it?
Here's a little detail on the SWORD architecture.
Re: A couple base classes: SWModule and SWKey.
SWModule is the base class of all module drivers and 'has' an SWKey. The key is the device used to position the module to a location.
e.g.
SWMgr mgr; // finds all Bibles installed on the system. SWModule &kjv = *mgr["KJV"]; // grab the KJV
kjv.setKey("John 3:16");
cout << kjv;Bibles, Commentaries, Lexicons, Dictionaries, General Books, are all decendents of SWModule, and they all supply their own specific SWKey decendent.
The current SWKey decendent that the Bible class uses is called VerseKey and is hardcoded with the KJV versification.
VerseKey used to use files to load it's versification, but about 8 years ago, every Bible we had used KJV and all these files where duplicated identically. I think it was during an optimization pass that we just hardcoded the table in the class, but it's been on our todo list to revert back to a similar behaviour.
Well, If nobody's working on it, maybe I can give it a try. The only problem is that I have to relearn C++ (last 4 years I've been working with Delphi and assembly, not much with C++), and get used to the wxWindows library and the Sword Engine, but I think that within a month I am as used to C++ as I am now to Delphi.
We have some CLX controls somewhere in the source that wouldn't take much work to get compiling again :) But jumping in and relearning C++, since your interface would be in wxWindows is probably the best :)
First, I don't share the idea that XML is only a interchange format.
Well, that's a pretty general statement, but in the context of the conversation it was referring to, the issue went something like: if you're going to break the 20 meg Bible up into smaller, more usable XML chunks, then you might as well just process the Bible into a useful, compressed, optimized internal format, and keep all the ugly OSIS normalization (because OSIS has a quite a few ways to encode the same thing) code to handle all types of markup all in an importer.
I think XML is good for SAX parsing-- one sequential pass of an entire document, for say, printing or other transformation.
I think XML is good for DOM manipulation of reasonably sized documents < 500k. There aren't many DOM parsers that do very well, or even work at all when you get up above 3 megs.
Indexes that contain Book-Chapter-Verse info are very easy to create, fast to access, and can be very small (using the right techniques).
Agreed, that's not the issue. Our 2 current Bible drivers, zText and RawText, both build indecies. RawText can leave the document unchanged and could likely do what you want with an OSIS document.
Secondly, I don't know if the Sword Engine has indexes for fulltext searches, but those can be created the same way for XML documents.
Right, we have a search plugin mechanism in the engine (which needs to be reworked a little). Haven't officially announced this yet, but current CVS contains clucene as a plugin. The web interface uses this plugin for a number of Bibles, including the default NASB. You can try all clucene syntax and see the results and score:
http://www.crosswire.org/sword/biblenew/passagestudy.jsp
We need to update our clucene library to the latest, as a few things like ~3 (within 3 words) returns strange things. Hope they've fixed the bugs.
http://jakarta.apache.org/lucene/docs/queryparsersyntax.html
Thirdly, I think supporting an well described format (like OSIS) with keeping the original file intact, instead of converting to a own module format, has some advantages. It makes the user more or less independant from the module making communitie, they can download an OSIS file, press the 'create indeces' button, and the document can be used
I don't see why keeping the document in OSIS format makes this possible. Our current thinking to provide an OSIS importer would also allow this.
Fourth, OSIS contains a lot of info about the text which is not saved in the module (correct me if I'm wrong). For example, take the CEV OSIS file, some verses are merged, it contains introductions, etc...
I'm not sure what you mean about 'not saved in the module'. If the data is not captured, then it is a lack of _our support_ for some of that data and a deficiency on our part. We're hoping to fully support OSIS soon.
Last, I want to write a script that automatically converts HTML/ThML/Text documents to OSIS.
We have many documents saved as ThML. You can ask the engine for OSIS markup and no matter what the source document is (ThML, GBF, OSIS), correct filters will be applied to give you OSIS output. That's already working to the extent that we support certain elements of each markup.
A friend of me is working on a program and website that can display and print OSIS files in a eastetic form. The idea behind it is that most theological documents on the internet have a very ugly layout (bold typeface, difficult to read background, unreadable font, etc).
Right, we also support the other direction. The new NASB module (also not announced yet, but should be publicly available from Lockman soon) is stored in OSIS markup (not an OSIS flat file, but sliced into verse chunks and compressed and indexed) and all of our frontends that make engine calls can ask for the data in their desired markup: RTF, HTML, even ThML, if they want.
If that script is ready, tons of theological documents (mostly books) will be available in OSIS format.
Yes! conversion to OSIS is a good thing! Actually, I believe Harry (CCEL) has a button you can click to get any of his documents as OSIS.
It would be nonsense if a user needs to wait until a OSIS text is converted to a module, before he can use it.
Not sure what you mean 'wait until OSIS text is converted to a module'. This process, in my mind is identical to your idea: "they can download an OSIS file, press the 'create indecies' button, and the document can be used"
I think we are on very much (amazingly so) the same page, just some terminology differences and only a few 'real' difference that I hope I can convince of 'better' ways :)
I have considered, and you're totally right.
Well, it's not me. I just think it's silly for Christian to all be out there competing to spread the Word of Christ. We're all about community for common goals!
Any restrictions that apply for code submitted to the Sword Project (besides that it has to be easy-to-read, and under GPL)?
Well, there is a CODINGSTYLE document at the root of the source tree.
Also, you are welcome to build all kinds of programs using the SWORD engine, but if you want code included by CrossWire into the engine itself and distributed by CrossWire, then we request copyright of the code be given to CrossWire so we can legally control all the code in our repository.
If there is a todo list (including
priorities), please let me know...
I was about to post one on Wednesday for the 1.5.7 release due out Christmas.
Some last question:
* Can the Sword Engine be compiled with MinGW? I don't have Borland C++ Builder or Visual C++, and prefer a free compiler (like MinGW) much above those commercial ones.
Yes, it compiles with most all C++ compiles that I know of now (now that someone actually got Microsoft's embedded C++ to compile it). That's the 'engine', not necessarily any frontend.
* I noticed the Sword Engine uses a unicode library. In what way is that compatible with the wxString type of wxWindows?
Haven't looked at wxString, but ICU is conditionally compiled into the library. You don't have to use it. If you include it, you get cool stuff like Arabic font shaping and transliteration.
Hope this helps. I'm really excited to work together, and should be more attentive after Monday!
-Troy.
In Christ,
Simon
In Christ, -Troy.
PS. Blessings on your paper! PPS. OSIS 1.1.1 docs are available here: http://bibletechnologieswg.org/osis/docs/
Simon Lagendijk wrote:
Hi all,
Thanks for your reply. Currently I'm using MinGW Studio for the programming, MinGW as compiler, and VisualWx for the form designing. It's does not work as well as, let say, Delphi, but its good enough to work with, and its free!
Development has stopped for this week because I've to write an essay for English class. As subject I choose 'ethics in a computer age', it's about the negative side of the computer age (about wasting time, unwanted temptations (porno), etc, and about how to deal with it). Very nice to see how, even on a non-christian school, lots of people admit the existence of those problems. If someone knows some good texts about this topic, please let me know....
Next week I hope to have a simplified OSIS reader ready, including a test app (console app). When thats finished, I'm going to work on the TagConversion (conversion of OSIS tags to HTML). When the HTML conversion is working, the GUI will be made (text showing will be done in a wxHTML control, so displaying text won't be to difficult). When that all is working, I'm going to implement the SWORD Engine. My idea is to support multiple 'reading engines', which are all independant from the original code, and all output OSIS, which will be converted to the format needed. Take a look at the attachment for an illustration of that idea.
PS> I do not want to offend anyone here by not just implementing the Sword Engine at the start, but I want first to have something wich is relatively simple working, and then add the more complex parts.
Simon
Simon,
I believe you earlier asked about cross-development compiler tools for Windows development?
If I understand your question (and if it was you that asked), there are several alternatives that I am aware of.
1. Al Stevens donated "Quincy" for free usage. It is a relatively simple ide
that utilizes a gnu based compiler/linker back-end. It comes with several
editions of his "Teach Yourself C++". The 2002 version comes with edition 7.
It is mostly to facilitate building the sample code in his book. Kinda
cool, but probably only adequate for early prototypes?
2. The Palm interface to the InVerse Scripture memorization freeware used
the cgywin command line tools. It also uses gnu based compiler back-end. For
me, I had to struggle to set it up, since I have little or no Linux
experience. There may very well be an ide. My impression is that a very
similar setup could be used for the development you have proposed, except
some of the Palm specific files replaced. (someone else on this list
probably is far more aware than I on this)
If you are interested and/or still need info, I can hunt around for links
and directions.
HTH and sharing the reason for the season, http://learningcards.eeworks.org/EeCard01.html
Lynn A
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
------------------------------------------------------------------------
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
