On Thu, 3 Sep 2015 12:54:53 -1000
Kahunapule Michael Johnson wrote:
Aloha nui,
> I use the actual Ethnologue/ISO 693-3 language code for the first 3
> characters of the module names in the eBible.org repository. To do otherwise
> increases the risk of collisions and the risk of confusing mysel
Peter is right. Looking toward the bigger and brighter future, the
module name should be an internal code to represent a particular text
from a particular publisher. By "publisher" I mean whoever actually
created the module, not the copyright holder. If another publisher wants
to issue the "sam
On Fri, 2015-09-04 at 07:17 +1000, Mark Morgan wrote:
> Peter,
>
> I don't use Perl, but it seems to me that you are assigning $doc_text
> to $tmp and thus throwing away the new SWBuf you created. From then
> on, $tmp and $doc_text will refer to the same thing. The string they
> contain will
On 09/03/2015 12:02 PM, Karl Kleinpaste
wrote:
On 09/03/2015 04:21 PM, Kahunapule
Michael Johnson wrote:
The
new grcTisheb module should at least display correctly, even
though it is missing some features.
- grcTisch
Thank you.
I use the actual Ethnologue/ISO 693-3 language code for the first
3 characters of the module names in the eBible.org repository. To
do otherwise increases the risk of collisions and the risk of
confusing myself. I could do like I do when matching up Bib
On 09/03/2015 10:50 AM, Peter von
Kaehne wrote:
Oy! :-)
Michael, we are still discussing and trying to find a consensus which
will last! Please do not do anything just yet.
Too late. Actually, if I need to undo what I just did, that can be
done,
On 09/03/2015 04:21 PM, Kahunapule Michael Johnson wrote:
> The new grcTisheb module should at least display correctly, even
> though it is missing some features.
- grcTischeb.conf is not individually in eBible's pub/sword/mods.d,
though it is present within pub/sword/mods.d.tar.gz.
- grcTischeb.co
On Tue, 1 Sep 2015 09:32:31 -1000
Kahunapule Michael Johnson wrote:
Hi Michael,
About fraFOB1724, which is a module for the French Bible Ostervald, I think it
must be renamed to FreFOB:
- Fre is the recommended prefix for French modules.
- The Ostervald Bible was first made public in the year 1
Good point. For now, I'm going to
assume that nobody else in CrossWire is as interested and active
in ASV maintenance as I am, and put that Obsoletes line in. If I'm
mistaken, please let me know.
On 09/02/2015 07:54 AM, DM Smith wrote:
Peter,
I don't use Perl, but it seems to me that you are assigning $doc_text to
$tmp and thus throwing away the new SWBuf you created. From then on, $tmp
and $doc_text will refer to the same thing. The string they contain will
never be different.
God bless.
Mark Morgan
On Fri, Sep 4, 2015 a
In terms of precendent:
the Wycliffe repo uses namespaces in modulenames. Per copyright owner
rather than repo publisher, but still.
[lang]_[namespace]_[year] is the form of modulenames there.
For reasons David has mentioned - small displays, this is not ideal.
[lang]{year](namespace] or
[lang
On Thu, 2015-09-03 at 14:32 -0400, DM Smith wrote:
> If I’m right then one could rename the kjv.conf to whatever-kjv.conf
> and it would work just as well.
>
> If this is the case, then the conf can have a namespace prefix.
yes, that will work. At least for Sword. I have not tested JSword on
it
Oy! :-)
Michael, we are still discussing and trying to find a consensus which
will last! Please do not do anything just yet.
I think whatever we should do should be permanent and consensual
I remain convinced that my proposal is the best as it will work
immediately with all frontends of all kin
Based on Peter's good advice and sound
reasoning, I'm appending an "eb" to every Bible module name in the
eBible.org repository. I didn't want to lengthen the module names
excessively with something like "eBible_org" or even "ebib" on the
end-- just enough to avoi
I am trying to take a string, pack it into a SWBuf, take a copy of it
into another SWBuf, run the copy through a stripfilter and then compare
the string content of the outcome with the initial string:
my $tmp = new Sword::SWBuf();
$tmp=$doc_text; # where $doc_text is a SWBuf, obtained earli
I suggest folder per repository as the correct long term solution. But thinking
about it, we might be able to solve it without a software change.
There are three problems to be solved:
1) data path collisions
We have a long held tradition of what the data path should be. There are two
forms of t
On Thu, 2015-09-03 at 13:23 +0100, Peter von Kaehne wrote:
> On Thu, 2015-09-03 at 13:01 +0100, Peter von Kaehne wrote:
>
> > It would be very easy to pass on the type attribute for further
> > use.
>
> One interesting problem is that we have never enforced any particular
> note type attributes
The former - installing from each repository into a different folder.
Does it require changes to front-ends? Yes, unless we push that
behavior into the default construction of an SWMgr. Does that mean we
should discount it in its entirety? I don't believe so.
The path to it is not the simplest, bu
The library already does support this, if the application asks it to do so.
SWMgr::augmentModules(const char * path, bool multiMod = false)
"multiMod whether or not to keep multiple copies of the same book if
found in different paths default - false, uses last found version of
the book"
How the d
On Thu, 2015-09-03 at 08:54 -0500, Greg Hellings wrote:
> This is a proposal I've brought up multiple times in the past ...
> On Thu, Sep 3, 2015 at 8:08 AM, DM Smith
> wrote:
> > If we had each repository downloaded to its own folder,
> >
> > > On Sep 3, 2015, at 5:26 AM, Peter von Kaehne
>
On Thu, 2015-09-03 at 09:29 -0400, Karl Kleinpaste wrote:
>
> Adding complexity to configuration will not solve the problems being
> fought. Module de-dup and filesystem choice conflicts are readily
> solvable. Analogy: I'm finishing up a novel, and I need a title.
> Hm, how about "To Kill a
On 09/03/2015 09:54 AM, Greg Hellings wrote:
> It would necessitate changes to existing front-ends, but they would not be
> drastic.
Generally speaking, I am suspicious of things that require "changes to
[all] existing front-ends," because then it smells very much like
something that ought to be s
Yes, it requires no change to existing software. Yes, it makes the move
towards Abbreviation more compelling, but does not actually require it.
And I think these both "yes" are a necessity right now.
We can not afford to do any _required_ changes as it would take forever
before all frontends are
This is a proposal I've brought up multiple times in the past when
people have said it would be difficult to resolve multiple copies with
the same name. It would necessitate changes to existing front-ends,
but they would not be drastic. However, this only addresses the
duplication issue in terms of
BTW, I'm thinking about adding a snippet of code to Xiphos' mod.mgr to
check to-be-installed modules' DataPath against all installed modules,
to ensure that no conflicts are manufactured. Seems to be reasonable
self-defense against poor choices.
___
swor
On 09/03/2015 05:26 AM, Peter von Kaehne wrote:
> Looking at the flurry of emails from the last few weeks I am thinking
> if I was Michael, I would start hitting my head against the wall.
I'm not Michael, and I already feel like I've been beating my head
against eBible's wall.
In an unusual-for-m
This suggestion requires no change to existing software. It almost necessitates
software to be changed to use Abbreviation and to do that well.
If we had each repository downloaded to its own folder, e.g. ebible, xiphos,
ibt, sword, sword-beta, … that would solve the mechanical problem of one re
On Thu, 2015-09-03 at 03:55 -0700, David Haslam wrote:
> cf. Long module names such as SpaRV2009ebib could be a problem for
> some mobile apps with small screens, unless perhaps the front-end
> makes better use of Abbreviation.
The eBible repo represents such a big amount of new modules that mo
On Thu, 2015-09-03 at 13:01 +0100, Peter von Kaehne wrote:
> It would be very easy to pass on the type attribute for further use.
One interesting problem is that we have never enforced any particular
note type attributes. We will likely encounter a huge range and
probably not well chosen ones to
Dear all,
Currently note type attributes (nor indeed note placement attributes)
are largely ignored by the engine (and the frontends).
It would be very easy to pass on the type attribute for further use. I
have done so in the Latex filters.
Try after updating svn and compiling:
diatheke -b WLC
I just checked the source.
The types x-strongsMarkup and crossReference get special treatment. The
rest are seen as footnotes.
WHen I have time I will think if this can be changed to passing on more
info to frontends. "When" might be a long time, but I would like it
too.
Peter
On Thu, 2015-09-0
Peter,
I'm a bit reluctant to see even longer module names than what we have
already, though I can appreciate that including a namespace might somehow
solve the collisions problems.
cf. Long module names such as SpaRV2009ebib could be a problem for some
mobile apps with small screens, unless perh
Thanks Peter.
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Note-placement-inline-tp4654336p4655211.html
Sent from the SWORD Dev mailing list archive at Nabble.com.
___
sword-devel mailing list: sword-devel@crosswire.o
On Thu, 2015-09-03 at 02:05 -0700, David Haslam wrote:
> Still waiting for a response!
The inline placement is currently not respected.
The note becomes a footnote.
There are a couple of issues here:
1) libsword treats only one type of notes in a separate and distinct
way - (type="crossRefere
Dear all,
Looking at the flurry of emails from the last few weeks I am thinking
if I was Michael, I would start hitting my head against the wall.
There are quite clearly two kinds of problems:
1) Things that stop us actually putting the repo formally online
2) Things that would be nice to get f
Still waiting for a response!
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Note-placement-inline-tp4654336p4655208.html
Sent from the SWORD Dev mailing list archive at Nabble.com.
___
sword-devel mailing list: sword-d
It's even worse when there are collisions when the [ModName]s are identical
apart from case.
e.g. [spaRV1909] collides with [SpaRV1909]
In this situation, the DataPath is the same, but Xiphos did not remove the
installed module before installing the "update". This led to having a
corrupted module
37 matches
Mail list logo
