<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jun 19, 2025 at 4:13 PM DM Smith <<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div><div><blockquote type="cite"><div>On Jun 19, 2025, at 3:24 PM, Greg Hellings <<a href="mailto:greg.hellings@gmail.com" target="_blank">greg.hellings@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div><div>Like most things, it's a trade-off. Working with the bindings requires that the Sword bindings are installed on the host system. For someone running on Windows, this is particularly non-trivial. For someone running in macOS it's not too difficult to install from source (I don't believe Homebrew builds them). For users of major Linux distributions, it's downright trivial. On Fedora it's as simple as a single `dnf install python3-sword` command for a long time now, and it looks like the bindings are also available for Ubuntu starting in 25.04 with an `apt install python3-sword` as well.</div></div></div></div></div></blockquote><div><br></div>Regarding building SWORD on a Mac, I use homebrew for extra packages. I tried to run ./autogen.sh, but it failed on libtoolize, which homebrew doesn’t have. Then I ran cmake, which failed because icu4c required C++17 or better. Hacking that I got CMakeLists.txt, I got it to work. I’ll see if I can use that to run your script.</div></div></div></blockquote><div><br></div><div>For these purposes, neither ICU nor CLucene are needed. It's only pulling the versification data which is core to the library's builtins.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><div>Advantages of the binding method are that it doesn't rely on parsing a C header file, nor on the file laying out the values in a certain way. It also can be used offline easily, doesn't require parsing the output of HTML in order to find all the applicable files, and is likely slightly faster. Not that the speed probably matters for a single run of this, but if you're bulk processing files the speed advantages can add up.</div></div></div></div></div></blockquote><div><br></div>The way I wrote mine is that it could use the include/canon*.h files from a prior local SVN clone. This is very fast. I’d be curious to see how it differs in speed from yours. The default is to go against the web, which is painfully slow. (Note, it doesn’t yet do the standard disclaimer for the web.) Not big deal if it is a single run. Peter mentioned that he does additional analysis of the files in problematic areas that cannot be done by the script.</div><div><br></div><div>Using the python bindings does have the advantages of not re-inventing the wheel. I was impressed with chatGPT’s regular expressions to slurp the arrays and how concise it was to read the files. There really wasn’t any difficulty in parsing the files. Since the canon*.h files are very static and not likely to affect the parse. I don’t think this is that big a deal.</div></div></div></blockquote><div><br></div><div>Yeah, the canon header files are pretty well structured following a standard format to make it easier on humans, and thus regex, to swallow. The thought of doing so had simply never crossed my mind.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><div><br></div><div>Disadvantages of the binding method are that it's requiring you to revert back to a source build if you are using this to test a canon.h file or if you want to use a canon file that isn't available in the package manager of your Linux distribution. Building from source isn't terribly onerous for most of us contributors but it might be more of a problem for a module maintainer. Then again, how often do we add a new versification to the code base?</div></div></div></div></div></blockquote><div><br></div> So, it’s not something we’d expect a module maker to succeed at if not on Un*x. Maybe someone has a library release for the MacOS or Windows that could be used?</div></div></div></blockquote><div><br></div><div>Because our Python bindings are built as part of the library and generated by Swig, they aren't distributed onto PyPI (the PYthon Package Index), which is the standard way of installing third party Python modules. To install from PyPI, one simply uses the "pip" tool, or other standard Python package installers. But for ours, the binding code is generated by Swig from the library code and we don't then subsequently distribute the module separately. Doing so would not be terribly difficult, but it is not a route we have taken previously.</div><div><br></div><div>Of course, installing Python modules that include C bindings necessitates having the Python.h file available as well as a compatible version of a C compiler. For the official Python distributions, this is always and only MSVC - or at least it has been in the past. Officially Python has not historically even supported building for Windows with gcc. It's enough of a bugbear that I've never even bothered with installing modules with Python on Windows.</div><div><br></div><div>Nowadays, though, we don't really need to. Anyone who wants to can install Ubuntu under the WSL and just take advantage of the existing apt package and Python in there. As for macOS, I haven't a good solution there. I only use it as demanded for work. Probably best to just let people who want it compile it from source there, and let them know there isn't any need for the ICU add ons.</div><div><br></div><div>An alternative is to go beyond a Python script and create a full utility in C that does this same work. That would make distribution much easier to all of the platforms. The reason I did not initially take that route is that Python is so convenient for working with XML in whereas the library has no such mechanism to readily parse it and query in the same way. Obviously it can be done, as osis2mod is already doing that work. Its parsing code could be repurposed to this effect.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><div><br></div><div>So there are pros and cons between them. I was freshly off of getting the bindings to compile when I wrote the first draft of av11n.py so I naturally went that direction. I also try to avoid writing parsers when I can leverage existing ones, as grammars can be notoriously complex to get correct. So that dictated my choices as much as did anything else, really!</div></div></div></div></div></blockquote><div><br></div>My computer science masters degree was in compiler writing! It’s definitely not for the faint of heart!</div></div></div></blockquote><div><br></div><div>Mine was in AI. Also not for the faint of heart, but much more approachable of a consumer product.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><div><br></div><div>Another possible enhancement might be a CLI flag to limit the testing range to a particular book (or testament) at a time. I have heard people talk about having modules split up to one book per file or similar. If they could say, "Only check this file against Joshua" then it could keep down a significant amount of extra output. But again - I'm not really an intended user of it!</div></div></div></div></div></blockquote><div><br></div>Great idea. So David’s suggestion of a scope argument.</div></div></div></blockquote><div><br></div><div>Basically, yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div>And I’m not an intended user of it either. I’m just trying to get people to use something other than osis2mod to pick a versification. Looking at the Jira issues on osis2mod, in one issue a person listed their script that looped over the v11ns and called osis2mod with each. Yuck!</div></div></div></blockquote><div><br></div><div>Yeah, using osis2mod in that way seems fraught with trouble. But in the absence of knowing more about the internal of the library, I can see why someone would take that approach.</div></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">--Greg</div></div>