scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Locale fallback

[Malcolm T. <ma...@co...>]

On Sat, 2003-08-23 at 13:48, Malcolm Tredinnick wrote:
> Hi Laszlo,
> 
> On Fri, 2003-08-22 at 22:12, Laszlo Kovacs - Sun Ireland wrote:
> > Here is another one. Scrollkeeper is designed to fall back to translated 
> > locales if docs are not translated to the current locale.
> > 
> > setlocale() (in libs/i18n.c) is used to identify the desired fallback 
> > path with the C locale sticked to the end (so that we fall back to 
> > English if all else fails).
> > 
> > But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is 
> > telling me that we should be able to fall back to a ja or ja_JP if 
> > ja_JP.UTF-8 is not available (before falling to English). This should be 
> > the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to 
> > ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this 
> > how people think it should work? Or some other way?
> 
> This should already be happening. I added some code back in September of
> last year (9/9/2002) to do this sort of stuff and it has been tested
> fairly thoroughly (since it affects the GNOME help system, for example).
> The code in question is in libs/i18n.c and should work exactly as you
> describe. This should have been in the 0.3.12 release.

Aah ... light dawns on marble head! They (your docs and build guys) may
well not be using this release, since that particular bunch of code used
strndup(), which I had not realised at the time was a GNU extension and
hence not in libc on Solaris (or *BSD amongst others). That bug has
probably been reported a dozen times since then. :-(

[Although I seem to remember that two of the bug reports came from
@sun.com, so somebody is testing things.]

I removed the strndup() usage a while ago, and have had some reports
that it now builds on those boxes. So if the case it just that Sun are
still using the 0.3.11 release, please either test the CVS version or
wait a few days until 0.3.12 comes out and try that.

Cheers,
Malcolm

Re: [Scrollkeeper-devel] category codes

[Malcolm T. <ma...@co...>]

On Fri, 2003-08-22 at 22:06, Laszlo Kovacs - Sun Ireland wrote:
> Hi All,
> 
> It's been a long time, but recently I had to look at some issues the Sun 
> docs team had with Scrollkeeper.

Welcome back (even if only briefly). :-)

Grrr. These would be the issues that they have not put into the bug
tracker so that nobody else can see them or fix them? I recently
received some patches from Glynn Foster that have been bouncing around
Sun for a while, too, that I had never seen before. Please, please,
please encourage whoever works with Scrollkeeper at Sun to use the bug
tracker so that things get fixed at the source.

I have reduced the number of outstanding bugs in the tracker by a large
number recently (from around 50 to about a dozen), so they do get read
and acted upon.

> I noticed that install.c:add_doc_to_content_list() uses the titles 
> content list entries to insert docs into them. I think this is exactly 
> what the category codes (in the OMF files) have been designed for. The 
> category codes should identify the sections where docs should be 
> inserted, they should be the same for all the locales. Titles are 
> different in every locale so they either don't work or impose extra 
> translation effort on package maintainers (category entries in OMF files 
> need translation).
> 
> Or am I missing something?

This sounds convincing. I'll have a look at it. I thought it should be
working that way, too, so if it's not it may just be a bug.

Cheers,
Malcolm

Re: [Scrollkeeper-devel] Locale fallback

[Malcolm T. <ma...@co...>]

Hi Laszlo,

On Fri, 2003-08-22 at 22:12, Laszlo Kovacs - Sun Ireland wrote:
> Here is another one. Scrollkeeper is designed to fall back to translated 
> locales if docs are not translated to the current locale.
> 
> setlocale() (in libs/i18n.c) is used to identify the desired fallback 
> path with the C locale sticked to the end (so that we fall back to 
> English if all else fails).
> 
> But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is 
> telling me that we should be able to fall back to a ja or ja_JP if 
> ja_JP.UTF-8 is not available (before falling to English). This should be 
> the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to 
> ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this 
> how people think it should work? Or some other way?

This should already be happening. I added some code back in September of
last year (9/9/2002) to do this sort of stuff and it has been tested
fairly thoroughly (since it affects the GNOME help system, for example).
The code in question is in libs/i18n.c and should work exactly as you
describe. This should have been in the 0.3.12 release.

Now, it may not be being called in all the correct places, but as soon
as we identify those, then it should be easy to fix up.

I am going to release 0.3.13 very shortly (and probably 0.3.14 pretty
soon thereafter to include whatever bug fixes are reported from the
first release for a while). So if there are problems like this,
encourage the Sun guys to whack them into Sourceforge's bug tracking
system (as evil as it is, it's still a good place to track these
problems) and I shall attend to them as soon as possible.

Cheers,
Malcolm

[Scrollkeeper-devel] category codes

[Laszlo K. - S. I. <las...@su...>]

Hi All,

It's been a long time, but recently I had to look at some issues the Sun 
docs team had with Scrollkeeper.

I noticed that install.c:add_doc_to_content_list() uses the titles 
content list entries to insert docs into them. I think this is exactly 
what the category codes (in the OMF files) have been designed for. The 
category codes should identify the sections where docs should be 
inserted, they should be the same for all the locales. Titles are 
different in every locale so they either don't work or impose extra 
translation effort on package maintainers (category entries in OMF files 
need translation).

Or am I missing something?

Laszlo

[Scrollkeeper-devel] Locale fallback

[Laszlo K. - S. I. <las...@su...>]

Hi,

Here is another one. Scrollkeeper is designed to fall back to translated 
locales if docs are not translated to the current locale.

setlocale() (in libs/i18n.c) is used to identify the desired fallback 
path with the C locale sticked to the end (so that we fall back to 
English if all else fails).

But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is 
telling me that we should be able to fall back to a ja or ja_JP if 
ja_JP.UTF-8 is not available (before falling to English). This should be 
the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to 
ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this 
how people think it should work? Or some other way?

Please comment,

Laszlo

[Scrollkeeper-devel] AWARD NOTIFICATION.

[<pri...@ne...>]

                               LOTTERY LA PRIMITIVA.
              C/GUZMAN EL BUENO,137 MADRID - ESPAÑA.
            TEL: +34-645-633-391 AND  FAX  +34-660-697-521

FROM: THE DESK OF THE PROMOTIONS MANAGER,
INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT,
REF: LP/26510460037/02 BATCH: 24/00319/IPD.

ATTN:
                       ( CONGRATULATION)


DEAR SIR,
            "AWARD NOTIFICATION FINAL NOTICE."

We are pleased to inform you of the announcement, of winners of the
LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS held on 31TH JULY,2003.
Your name is attached to ticket number 004-05117963-198, with serial
number 99375 drew no 03/61,the winning numbers 06-11 -13-27-40-49, and
consequently won the lottery in the 6th category. You have therefore
been approved for a lump sum pay out of €UROS 705.366,80 Thousand in
cash credited to file No:LP/26510460037/02.This is from total prize
money of EUROS 3,000,000.00 shared among the six  international winners
in this category. All participants were selected through a computer
ballot system drawn form 25,000 names from Australia, New Zealand,
America, Europe, North America and Asia as part of International
Promotions Program, which is conducted annually.

     CONGRATULATIONS!!! Your fund is now insured to your name. Due to
the mix up of some numbers and names, we ask that you keep this award
strictly from public notice until your claim has been processed and your
money remitted to your account. This is part of our security protocol
to avoid double claiming or unscrupulous acts by participants of this
program. We hope with a part of you prize, you will participate in our
end of year high stakes Euros1.1 billion International Lottery. To begin
your claim, please contact your claims agent, Mr Tony Santos(+34 676 538 701) FOREIGN OPERATION MANAGERS, Email:  pri...@ne...):WEBSITE(www.thelotter.com).
   For due processing and remittance of your prize money to a
designated account with our bankers. Remember, all prize money must be
claimed not later than 30TH SEPTEMBER, 2003. After this date, all funds
will be returned as unclaimed.

NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every  of your correspondences with your agent.
Furthermore, should there be any change of your address, do inform your
claims agent as soon as possible. Congratulations again from all our
staff and thank you for being part of our promotions programm.


( CONGRATULATION)


 BEST REGARDS,

DR. CLIFFORD F. LOPEZ.

(DIRECTOR EXTERNAL AFFAIRS)

[Scrollkeeper-devel] Request Info on scrollkeeper

[anand l. <ana...@ho...>]

Hello,

Sorry to disturbe. I am facing some problem when installing "gnome2" meta 
package for NetBSD 1.6 on my i386 platform. It goes into 
"scrollkeeper-0.3.12" and gets stuck in make. So I tried to build 
scrollkeeper alone. Attahced is the output of the make command. If you can, 
please go through and help me in this regard, else discard this message.

Sorry I could not find a mailing list for errors in:
http://scrollkeeper.sourceforge.net/contact.shtml

Thanks anyways.

Regards,
Anand Lalgondar

_________________________________________________________________
They are beautiful. They are in danger. 
http://server1.msn.co.in/Slideshow/BeautyoftheBeast/index.asp Our 
four-legged friends.

Re: [Scrollkeeper-devel] Scrollkeeper's immediate future

[Rajkumar S. <raj...@wi...>]

Hi Malcolm,

Quote:
~~~~~

> General Plans:
> ---------------
> - Work on making scrollkeeper work as a shared library. Rajkumar
>   Sivasamy from Wipro has started the ball rolling here and I do not
>   want to waste his efforts.

(http://sourceforge.net/mailarchive/forum.php?thread_id=2506741&forum_id=4112)

Am sure that you will be looking into this, pls. treat this as a
friendly reminder.


Thanks & Regards,
Raj.

Re: [Scrollkeeper-devel] New maintainership

[John F. <jf...@in...>]

A belated congratulations to Malcolm and a *huge* thanks to Dan for all
the work over the years.
Cheers,
John

On Fri, 2003-06-20 at 21:49, Dan Mueth wrote:
> Hi everybody,
> 
> It has become increasingly clear that my busy schedule does not allow 
> enough time to do a good job of maintaining ScrollKeeper and expanding it 
> to meet the needs of the community.  With careful consideration, I have 
> decided to step down as maintainer of ScrollKeeper to allow somebody with 
> more time and energy to continue the project.  
> 
> Recently, the primary contributor to ScrollKeeper has been Malcolm
> Tredinnick, and he has generously agreed to take over as maintainer of the 
> project.  I will try to make the transition smooth and help out however I 
> can, but I am confident he will have no problem moving the project forward 
> and in the right direction.  He clearly has the enthusiasm and 
> determination that this project needs.
> 
> While I do not plan to completely vanish, this is a good opportunity to
> thank everybody who has contributed to this project for their help and
> support.  While I feel like I sat in the middle of the project, almost all
> of the real work was done by all of you.  (Especially Laszlo, if he is
> still listening, who wrote the vast majority of the code:)  So many people
> contributed to the vision, design, code, translations, documentation, and
> packaging.  Many thanks to you all :)
> 
> So, without further ado, I'd like to introduce Malcolm Tredinnick....
> <applause/>
> 
> -Dan
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com
http://www.gnome.org/learn/users-guide/latest/

"Not only isn't reality real - it's an illusion created by unreal people to
sell real people unnecesary cars." - Griffy

Re: [Scrollkeeper-devel] A patch to fix scrollkeeper-update segmentation core dump

[Malcolm T. <ma...@co...>]

Hi Narayana,

On Fri, 2003-06-27 at 21:58, Narayana Pattipati wrote:
> Hi All,
> 
> Please have a look at the attached patch which fixes a SEGV in
> scrollkeeper-update. 
> 
> Problem Description:
> 
> When scrollkeeper-rebuilddb is done on a system which has many locales,
> scrollkeeper-update is crashing at the following place in scrollkeeper
> code.
> 
> scrollkeeper/libs/install.c:create_toc_tree()
>   snprintf(command, 1024, "scrollkeeper-get-toc-from-docpath %s", 
>    docpath);
>   config_fid = popen(command, "r");
>   fscanf(config_fid, "%s", tocpath);
>   if (pclose(config_fid))
>   return NULL;
> 
> The file descriptor returned from popen() is NULL and when it is passed
> to fscanf(), the application is crashing.
> 
> Reason for popen() failure is that the process is running out of file
> descriptors.
> 
> In scrollkeeper/libs/install.c:get_unique_doc_id() function, a file
> descriptor is opened to register each OMF file with SK database. Once
> the file descriptor is used, it is not closed. If there are more than
> 256 files to be registered already, popen() fails for consequent files. 
> 
> Solution:
> Close the file descriptors after using them. I have closed file
> descriptors opened in few other places also.
> 
> Note: Max files opened varies across platforms. In Solaris, defalt value
> is 256.

Thanks for working out what was going wrong here and supplying the
patch. It looks pretty good to me and I will put it in CVS.

Cheers,
Malcolm

[Scrollkeeper-devel] A patch to fix scrollkeeper-update segmentation core dump

[Narayana P. <nar...@wi...>]

Hi All,

Please have a look at the attached patch which fixes a SEGV in
scrollkeeper-update. 

Problem Description:

When scrollkeeper-rebuilddb is done on a system which has many locales,
scrollkeeper-update is crashing at the following place in scrollkeeper
code.

scrollkeeper/libs/install.c:create_toc_tree()
  snprintf(command, 1024, "scrollkeeper-get-toc-from-docpath %s", 
   docpath);
  config_fid = popen(command, "r");
  fscanf(config_fid, "%s", tocpath);
  if (pclose(config_fid))
  return NULL;

The file descriptor returned from popen() is NULL and when it is passed
to fscanf(), the application is crashing.

Reason for popen() failure is that the process is running out of file
descriptors.

In scrollkeeper/libs/install.c:get_unique_doc_id() function, a file
descriptor is opened to register each OMF file with SK database. Once
the file descriptor is used, it is not closed. If there are more than
256 files to be registered already, popen() fails for consequent files. 

Solution:
Close the file descriptors after using them. I have closed file
descriptors opened in few other places also.

Note: Max files opened varies across platforms. In Solaris, defalt value
is 256.

Please let me know your comments on the patch.

Thanks,
Narayana

[Scrollkeeper-devel] Scrollkeeper's immediate future

[Malcolm T. <ma...@co...>]

Hi all,

As Dan mentioned the other day, I have somewhat foolishly agreed to take
over maintainership of Scrollkeeper. Not coincidentally, I have been
doing a bit of work over the past few days to try and reduce the number
of outstanding bugs and work out what remains to be done. In short, the
sourceforge bug list is much shorter (around 10 bugs open) and there are
no outstanding patches in the the patch tracker.

Since I have made a large number of changes to the build system to try
and make things work on various platforms, I am thinking of making a
release in about two or three weeks to ensure that nothing is completely
broken. In the meantime, some people may wish to try out the CVS version
-- it works for me under a variety of test conditions, but I only have
access to Linux on x86 boxes, so I trying to do what is correct on other
platforms, but it remains untests.

Milsoslav Trmac has taken over coordinating all of the translation
issues, so hopefully we can move forwards there. In particular, it is
important to translate the category list into as many locales as
possible to assist end-users.

I have attached to this mail my list of things that need to be done or
sorted out. If anybody has comments (or, even better, if anybody wants
to volunteer for something), speak up.

My goal over the next little while is try and make scrollkeeper as solid
as possible and get the known buglist down to zero. Then we can work out
where to go from there.

Cheers,
Malcolm

[Scrollkeeper-devel] ScrollKeeper hosted at the Translation Project

[Miloslav T. <mi...@vo...>]

Hello,
ScrollKeeper is now available for translation at the Translation Project.
Basic instructions about working with the Translation Project robot are
available at
http://www.iro.umontreal.ca/contrib/po/HTML/translators.html

The files in gnome-i18n/extra-po/scrollkeeper have been merged in
ScrollKeeper CVS and removed.

Thanks to all translators, especially those that have managed to
submit updated translations before this announcement :-)
	Mirek

[Scrollkeeper-devel] Re: Suggestions for message improvement

[Karl E. <ke...@gm...>]

Malcolm Tredinnick <ma...@co...> writes:

> Ah, cool. Hopefully when Miloslav is happy with the setup there, he will
> also make sure it gets removed from gnome-i18n/extra-po. (*hint, hint*
> :-) ).

Thnings should work by now.  Jordi already tried to submit ca.po; if it
made its way through, the setup is in a sane shape.

-- 
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke...@su... (work) / ke...@gm... (home)               |   (*)/'(*)

Re: [Scrollkeeper-devel] Suggestions for message improvement

[Malcolm T. <ma...@co...>]

On Wed, 2003-06-25 at 02:03, Christian Rose wrote:
> #: cl/src/get-cl.c:92
> #, c-format
> msgid "scrollkeeper-get-cl: Cannot open temp file: %s\n"
> 
> Please don't include literal file names/function names, that shouldn't
> be translated anyway, in messages. Replace it with %s instead if
> necessary.

Good point. I'll change all the occurrences of this. If you get a
moment, could you whack a bug into scrollkeeper's tracker so that it
doesn't get lost.

> Btw, I just saw that scrollkeeper has been imported into the Translation
> Project. Awesome stuff!

Ah, cool. Hopefully when Miloslav is happy with the setup there, he will
also make sure it gets removed from gnome-i18n/extra-po. (*hint, hint*
:-) ).

Malcolm

[Scrollkeeper-devel] Suggestions for message improvement

[Christian R. <me...@me...>]

#: cl/src/get-cl.c:92
#, c-format
msgid "scrollkeeper-get-cl: Cannot open temp file: %s\n"

Please don't include literal file names/function names, that shouldn't
be translated anyway, in messages. Replace it with %s instead if
necessary. The rationale for that can be found on
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#generic.

Btw, I just saw that scrollkeeper has been imported into the Translation
Project. Awesome stuff!


Christian

[Scrollkeeper-devel] Patches committed to scrollkeeper

[Malcolm T. <ma...@co...>]

All,

I spent a bit of time over the weekend tidying up a couple of
scrollkeeper things. As part of this, I tried to clear out the backlog
of patches that I had piling up -- mostly things that had been submitted
to the mailing list by other people.

As far as I can tell, the following patches were the only ones submitted
to the mailing list:

- Mariano Suarez-Alvarez: Makefile.am fix to build scrollkeeper.h
correctly.

- Jordi Mallach: ca.po update.

- Miloslav Trmac: Patch to link in libintl correctly for some platforms.

Still in the pending queue: patch from Rajkumar Sivasamy to add a
scrollkeeper_find_omffile_count() function. Still needs review, but I'll
get to it today or tomorrow. 

If you have sent in a fix and it is not in this list, please sing out,
since I have overlooked your contribution.

Note that this does not count patches submitted to bugzilla or via the
patch tracker -- I am just trying to verify that I have pulled all the
patches out of the mailing list that might otherwise be overlooked.

Cheers,
Malcolm

[Scrollkeeper-devel] Automake upgrade?

[Malcolm T. <ma...@co...>]

I would like to upgrade the automake requirement for scrollkeeper to
Automake 1.6. This will make some of the build issues a bit easier to
manage and keeps us vaguely in tune with the automake distributions.

This will only affect people building from the CVS sources and will
require the builder in those cases to have Automake 1.6.x (for any 'x')
or Automake 1.7 on their system. These days, most distributions are
shipping one of these versions (and they are parallel installable with
Automake 1.4, so it's not an "either/or" situation).

Does anybody have a good reason *not* to do this? I will leave this
alone until Wednesday or so to give people time to think about it.

Cheers,
Malcolm

Re: [Scrollkeeper-devel] Re: Scrollkeeper delay

[Malcolm T. <ma...@co...>]

On Sat, 2003-06-21 at 14:40, Karl Eichwalder wrote:
> Pablo Fernandez <pa...@bl...> writes:
> 
> > The problem is that the installation is about 15 minutes longer due to
> > scrollkeeper, since it rebuilds it database like five times.
> 
> such a delay usually happens when scrollkeeper download the DocBook DTD
> from the net (again and again) because the DTD isn't available on the
> local system.
> 
> Unfortunately, scrollkeeper does not support a switch like --no-net to
> prevent such a bahavior from happening.  (I already file a feature
> request concerning this issue, IIRC).

That one is on the TODO list, along with things like supporting multiple
DocBook versions. You have not been forgotten, Karl. :)

Malcolm

[Scrollkeeper-devel] Re: Scrollkeeper delay

[Karl E. <ke...@gm...>]

Pablo Fernandez <pa...@bl...> writes:

> The problem is that the installation is about 15 minutes longer due to
> scrollkeeper, since it rebuilds it database like five times.

such a delay usually happens when scrollkeeper download the DocBook DTD
from the net (again and again) because the DTD isn't available on the
local system.

Unfortunately, scrollkeeper does not support a switch like --no-net to
prevent such a bahavior from happening.  (I already file a feature
request concerning this issue, IIRC).

-- 
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke...@su... (work) / ke...@gm... (home)               |   (*)/'(*)

Re: [Scrollkeeper-devel] Scrollkeeper delay

[Malcolm T. <ma...@co...>]

On Sat, 2003-06-21 at 13:17, Dan Mueth wrote:
> On 21 Jun 2003, Malcolm Tredinnick wrote:
> 
> > On Sat, 2003-06-21 at 00:52, Dan Mueth wrote:
[...]
> > > The real solution to this problem is to extend ScrollKeeper so that one 
> > > can process the docs at build time and install the generated data so that 
> > > ScrollKeeper doesn't have to do it at install time.
> > 
> > Can you explain this a bit more, because I am stupid and do not
> > understand. :-(
> > 
> > We already run scrollkeeper-preinstall in the build phase and
> > scrollkeeper-update in the install phase. So it sounds like you are
> > proposing some kind of optimised output from the build phase so that the
> > update part will be faster at install time, but, like I said, I don't
> > really understand.
> 
> When we build a package, ScrollKeeper is actually run in a way that it 
> generates the metadata files from the document and writes them to files.  
> However, these files are not kept in the package.  They are just left in 
> the temporary build tree and then are later destroyed.  The reasoning is: 
> (1) We want to generate and install (in the temporary path) the metadata 
> to make sure any errors are found, and (2) We don't keep and install the 
> generated metadata because you have to worry about compatibility between 
> different versions of ScrollKeeper and potential customization of 
> stylesheets on different systems.  At install time, the metadata is 
> re-generated from the original documents, which is why ScrollKeeper makes 
> package installation time grow dramatically for packages with long 
> documents.

Oh, doh! Sorry, I was thinking along the completely wrong track when I
posted earlier -- I don't think I had quite woken up yet. All is
clear(er) now, I understand what you are getting at.

> The original hope was that we would win the speed race... that libxml and
> computers would both speed up faster than the documentation body grows and
> that the package installation time would not be too painfully lengthened.  
> Since this is not the case, we need to consider the other options which we
> originally wanted to avoid (things like pre-generating and installing the
> metadata, using cron to process metadata at a more convenient time,
> backgrounding the metadata generation, etc.).  They all have their 
> drawbacks, but it sounds like we need to provide at least an optional 
> workaround so that distributions have a way to avoid lengthening 
> distribution installation times significantly.

Agreed.

> As for scrollkeeper-preinstall, it is simply a little utility which 
> modifies an OMF entry to include the actual path that a document will be 
> installed at, since this is generally not known until build time.  It 
> doesn't actually read or process the document itself.

Yes, I understand this. Sorry, not meaning to confuse the issue: I had
completely misunderstood where you were going earlier. Now I feel silly.

Still, no harm done. There is stuff to think about here.

Cheers,
Malcolm

[Scrollkeeper-devel] New maintainership

[Dan M. <mu...@al...>]

Hi everybody,

It has become increasingly clear that my busy schedule does not allow 
enough time to do a good job of maintaining ScrollKeeper and expanding it 
to meet the needs of the community.  With careful consideration, I have 
decided to step down as maintainer of ScrollKeeper to allow somebody with 
more time and energy to continue the project.  

Recently, the primary contributor to ScrollKeeper has been Malcolm
Tredinnick, and he has generously agreed to take over as maintainer of the 
project.  I will try to make the transition smooth and help out however I 
can, but I am confident he will have no problem moving the project forward 
and in the right direction.  He clearly has the enthusiasm and 
determination that this project needs.

While I do not plan to completely vanish, this is a good opportunity to
thank everybody who has contributed to this project for their help and
support.  While I feel like I sat in the middle of the project, almost all
of the real work was done by all of you.  (Especially Laszlo, if he is
still listening, who wrote the vast majority of the code:)  So many people
contributed to the vision, design, code, translations, documentation, and
packaging.  Many thanks to you all :)

So, without further ado, I'd like to introduce Malcolm Tredinnick....
<applause/>

-Dan

Re: [Scrollkeeper-devel] Scrollkeeper delay

[Dan M. <mu...@al...>]

On 21 Jun 2003, Malcolm Tredinnick wrote:

> On Sat, 2003-06-21 at 00:52, Dan Mueth wrote:
> > On 20 Jun 2003, Malcolm Tredinnick wrote:
> > 
> > > On Fri, 2003-06-20 at 21:09, Pablo Fernandez wrote:
> > 
> > > > Is there anyway to avoid the rebuild of the database without rebuilding
> > > > the packages that use the scrollkeeper-update program?
> > > 
> > > Not easily. An ugly, but possibly workable solution would be to
> > > temporarily alias the scrollkeeper-update name to something harmless
> > > like ':' and then run scrollkeeper-update once as part of some
> > > post-install fixup.
> > 
> > Is the system really doing a complete rebuild of the database?  If so, 
> > then it is duplicating work and it would make sense to have a way to turn 
> > scrollkeeper off (such as temporarily replacing the binary or having a 
> > line in /etc/scrollkeeper.conf).  Then when the distribution installation 
> > is done, you should update the database.
> 
> I was thinking about this while falling asleep last night and realised a
> solution might be to have an environment variable that prevented a
> database rebuild in a big install scenario. So if
> SCROLLKEEPER_NO_REBUILD is set in the environment, scrollkeeper-rebuild
> just exits when called without doing anything. This can the be disabled
> an re-enabled at will and doesn't require hacking any files . The latter
> case can lead to inconsistencies if the install failed or the machine
> crashed or something, whereas an environment variable would just
> harmlessly disappear.

That is far more elegant :)

I'm not particularly familiar with how installations are typically done.  
It seems completely reasonable that one is free to set environment 
variables and pass them along as needed.  Does anybody know if that is 
right?

> > The real solution to this problem is to extend ScrollKeeper so that one 
> > can process the docs at build time and install the generated data so that 
> > ScrollKeeper doesn't have to do it at install time.
> 
> Can you explain this a bit more, because I am stupid and do not
> understand. :-(
> 
> We already run scrollkeeper-preinstall in the build phase and
> scrollkeeper-update in the install phase. So it sounds like you are
> proposing some kind of optimised output from the build phase so that the
> update part will be faster at install time, but, like I said, I don't
> really understand.

When we build a package, ScrollKeeper is actually run in a way that it 
generates the metadata files from the document and writes them to files.  
However, these files are not kept in the package.  They are just left in 
the temporary build tree and then are later destroyed.  The reasoning is: 
(1) We want to generate and install (in the temporary path) the metadata 
to make sure any errors are found, and (2) We don't keep and install the 
generated metadata because you have to worry about compatibility between 
different versions of ScrollKeeper and potential customization of 
stylesheets on different systems.  At install time, the metadata is 
re-generated from the original documents, which is why ScrollKeeper makes 
package installation time grow dramatically for packages with long 
documents.

The original hope was that we would win the speed race... that libxml and
computers would both speed up faster than the documentation body grows and
that the package installation time would not be too painfully lengthened.  
Since this is not the case, we need to consider the other options which we
originally wanted to avoid (things like pre-generating and installing the
metadata, using cron to process metadata at a more convenient time,
backgrounding the metadata generation, etc.).  They all have their 
drawbacks, but it sounds like we need to provide at least an optional 
workaround so that distributions have a way to avoid lengthening 
distribution installation times significantly.

As for scrollkeeper-preinstall, it is simply a little utility which 
modifies an OMF entry to include the actual path that a document will be 
installed at, since this is generally not known until build time.  It 
doesn't actually read or process the document itself.

-Dan

Re: [Scrollkeeper-devel] Scrollkeeper delay

[Malcolm T. <ma...@co...>]

On Sat, 2003-06-21 at 00:52, Dan Mueth wrote:
> On 20 Jun 2003, Malcolm Tredinnick wrote:
> 
> > On Fri, 2003-06-20 at 21:09, Pablo Fernandez wrote:
> 
> > > Is there anyway to avoid the rebuild of the database without rebuilding
> > > the packages that use the scrollkeeper-update program?
> > 
> > Not easily. An ugly, but possibly workable solution would be to
> > temporarily alias the scrollkeeper-update name to something harmless
> > like ':' and then run scrollkeeper-update once as part of some
> > post-install fixup.
> 
> Is the system really doing a complete rebuild of the database?  If so, 
> then it is duplicating work and it would make sense to have a way to turn 
> scrollkeeper off (such as temporarily replacing the binary or having a 
> line in /etc/scrollkeeper.conf).  Then when the distribution installation 
> is done, you should update the database.

I was thinking about this while falling asleep last night and realised a
solution might be to have an environment variable that prevented a
database rebuild in a big install scenario. So if
SCROLLKEEPER_NO_REBUILD is set in the environment, scrollkeeper-rebuild
just exits when called without doing anything. This can the be disabled
an re-enabled at will and doesn't require hacking any files . The latter
case can lead to inconsistencies if the install failed or the machine
crashed or something, whereas an environment variable would just
harmlessly disappear.

> However, when each package installs, it should only be doing an update of 
> the database.  Since these are incremental, it shouldn't be much faster to 
> do one large update at the end of the distribution installation than to do 
> a number of smaller updates during the installation.

Hmm. This is a valid point. It will be slightly faster, but not a lot.

[...]
> The real solution to this problem is to extend ScrollKeeper so that one 
> can process the docs at build time and install the generated data so that 
> ScrollKeeper doesn't have to do it at install time.

Can you explain this a bit more, because I am stupid and do not
understand. :-(

We already run scrollkeeper-preinstall in the build phase and
scrollkeeper-update in the install phase. So it sounds like you are
proposing some kind of optimised output from the build phase so that the
update part will be faster at install time, but, like I said, I don't
really understand.

Cheers,
Malcolm

Re: [Scrollkeeper-devel] about sending new/updated translations

[Dan M. <mu...@al...>]

On Sat, 17 May 2003, Malcolm Tredinnick wrote:

> On Fri, May 16, 2003 at 10:48:13AM +0200, Miloslav Trmac wrote:
> > On Fri, May 16, 2003 at 09:21:42AM +0200, Luca Ferretti wrote:
> > > Results? How can I send my translation now?
> > I'm also missing this.
> > 
> > I can set ScrollKeeper up at the translation project and take care
> > of commiting the incoming translations if nobody else has time.
> 
> The resolution of the most recent thread was to set up a Translation
> Project account (or whatever they call it) for Scrollkeeper. The po
> files in extra-po in the GNOME CVS were to be removed. Dan wanted to
> wait a couple of days on this so that he could get things synchronised
> and then was going to make the change.
> 
> So I guess we need to find out where Mr Muet is up to, but my guess
> would be that if Miroslav has the time to coordinate this, he's going to
> be elected unopposed as soon as Dan reads his mail. :-)

:)

Thanks for the help Mirek.  If you haven't already done so, feel free to 
set it up and then post the new instructions for translators.

-Dan