Re: [pilot-db-list] few things

[Nathan K. <na...@ve...>]

Hello --

Thanks for your interest and time spent!

> 1. I translated the UI to Hebrew. You can get the file at
> <http://www.cs.tau.ac.il/~didi/iw.rcp> (I did not know if it's
> considered polite sending here attachments, so I put it there).
> I did not translate everything, mostly the commonly-used things as
> well as the ones easy to translate :-). If there is interest I do not
> mind spending a few more hours on polishing this, but I think it's
> already good enough for inclusion in a next version.

I'm probably the person who would include this, but I'm a new
maintainer for this and I haven't yet dealt with adding languages.
But if you can leave it up for a while (currently unspecified) I'll
add it as a language once we get a release candidate mostly working.

> 2. The "large DB support" didn't work very well for him, so for now
> I disabled it (compiled with '--with-vldb=0'). IIRC, it also wasn't
> that much faster - and it _is_ an issue for him, having a 1000+
> records DB with around 20 fields (still to change, but num of records
> will not get smaller - it's his todo list). How experimental is this?
> Is it going to become stable soon? Should I help debug this? Can I?

You compiled it!  Congratulations!  As best as I can tell, there are
very few people on this list who have done so.  Be warned that many of
the code paths seem to be unused in recent years, and that by
including (or omitting) configuration flags you might soon find
yourself in uncharted waters.

Yes, it is probably going to become stable in the next release by
simple method of removing all reference to the word "experimental".
As far as I know (based on my recollection of submitted bug reports)
it does not seem to add additional bugs.  I don't know about it's
performance, but I think it purpose was simply to allow very large
databases, not to necessarily make them work faster. (?)

Yes, you should help debug this! :) Submitting the slowness as a bug
report to the SourceForge website, and then giving a sample database
with some sample times would be good too.  I haven't yet tried much
profiling under POSE, but it does appear to be possible.  I'd guess
(without having looked closely at the code) that there is lots of room
for simple optimization.  If you can do it, wonderful, otherwise (like
everything else) I'll try to get to it once we have a stable release.

> 3. Searching for Hebrew phrases is a bit weird. When using one kit of
> Hebrew support, the one he got with the palm (HarelHeb 3.5, IIRC), it
> only finds things if they are at the end of a field. When using another
> support kit (a 2-week temporary license from www.kalanit.co.il for
> what seems like a newer version of the same HarelHeb, but not sure),
> it works just fine. Is this reasonable? Is there anything pilot-db can
> do about it, or is this only the foreign-language support's job? I
> did grep the source and found it's MatchString, which calls
> *Glue* functions. Are these part of the foreign-lang support?

I don't know---I haven't dealt much with the foreign language support,
and not at all with the non-latin-alphabet languages.  Submitting it
as a bug report would be useful to create a permanent record, but my
offhand guess is that if we are calling the *Glue* functions
correctly, there is not much else to be done on the pilot-db end.
But it is certainly worth checking if we are calling them correctly...

> 4. Since it's too slow for daily work, he uses the memoexport plugin
> for the daily tasks, and uses that, using pilot-db only for longer-term
> planning. Is there an easy way to export at once all the records displayed
> by a specific view/filter? I guess no. It sounds to me as something that's
> generally-useful - to make all the one-record plugins also available from
> the listview, making them operate on all the records. Does this make sense?
> Or is the right thing writing another plugin that will be specific to this
> (which he will probably need anyway, since he wants it to set also the
> category etc.)?

I'd guess it is not possible either, but yes, it does sound useful.

> 5. I spent some time on editing the DB on a PC. I mostly want to do this
> on linux, so dbeditor isn't my first choice. I tried to hack palm-db-tools
> into exporting and importing filters (and eventually hoped for all other
> data), but after spending on this around 10 hours, not getting it working
> and deciding it's too hard to debug, I decided to quit. Instead, I searched
> and found a small tool called par (7th google hit searching for 'par'),
> which lets you extract the appinfo to a file, each record to a file, and
> create a pdb from such files. So I intend to write a script that will
> do this:
> export and keep the appinfo
> pdb2csv to file.csv
> edit the file.csv (with openoffice, or maybe mysql+some web UI?)
> csv2pdb
> export all the records from the new pdb
> create a pdb from the records and the saved appinfo
> 
> I verified that this theoretically works, but did not make thorough tests.
> Should it? Is this a good way, considering no tool will follow closely
> enough the development of pilot-db? And, BTW, isn't something written in
> some higher-level language easier to write? E.g. things like
> datascript or DataWorkshop? I know this isn't pilot-db-related, but
> palm-db-tools seems dead to me.

We've had a bit of discussion this list about what needs to be done
about this, but no solution yet.  I wouldn't give up on the hope of
having a tool that would follow the development of pilot-db.  In fact,
I think that is just about the only hope.  

> 6. Not terribly important, but transferring it to/from the palm takes
> quite a lot of time - around 45 seconds, for a 170KB file. For comparison,
> db-iw.prc itself, which is larger, takes much less time (not sure, I think
> around 13 seconds). Is this reasonable? Is it because of the many records?

I don't know, but that does sound odd.  I've done almost all my
testing on Pose and I haven't run into this problem. 

> 7. There is a bug, that sometimes, when pressing the down-arrow or up-arrow
> icons on the buttom-right, in the "record view" (is this the name?), it
> crashes, requiring a soft reset. Pressing PgDn does work, so that's what
> he does for now. I tried for some time to debug this with pose and gdb,
> but did not really get anywhere. It says:
> "DB (1.1.0) called SysFatalAlert with the message:
> "leakdetect.c, Line:188, addr"."
> and gives control to gdb, but I can't see too much - 'where' says
> (gdb) where
> #0  0x1001d8b2 in ErrDisplayFileLineMsg ()
> #1  0x00091b88 in ?? ()
> #2  0x0008955c in ?? ()
> #3  0x0007b770 in ?? ()
> #4  0x10066b08 in PrvSendEventToForm ()
> #5  0x10069f2c in FrmDispatchEvent ()
> #6  0x0006f670 in EventLoop () at main.c:201
> #7  0x0006f8a6 in EditViewGetFieldHeight () at main.c:715
> #8  0x0006f3e4 in CheckMinVersion () at crt0.c:69
> which does not help much. I tried to also put a breakpoint in
> leakdetect.c:188, but also didn't get much further. 

I fixed something similar in the CVS version (Danger! Don't go
there!).  If possible, it would be great to see if you can reproduce
this bug with a stock binary release.  There are a number of
configuration oddities that might cause this (some codepaths seem not
to have been used in years) and it that's causing this.

Submitting this as a bug would be good for record keeping:
  http://sourceforge.net/tracker/?group_id=621&atid=100621

> How do I debug pilot-db? Is there some tutorial somewhere?

No, there is not much published information, but I'm eager and willing
to help you figure it out, and if we do it on-list it will probably
help people in the future.   

It looks like the problem you are hitting now is that pilot-db is a
multi-segment application, and that the standard prc-tools kit
(including m68k-palmos-gdb) does not really support multiple code
segments.  But there are patches available to do so:
  http://www.v-overbeek.nl/msectgdb/
While it's possible to do the compile from scratch, it's a lengthy
multi-step procedure.  I submitted Linux binaries to Ton, which should
be now available on his site.  

> I hope this isn't too long! 

On-topic length is no problem.

> If you want further discussion to be in single-issue-threads, fine
> with me.

Probably better.  Let's put the followup posts into separate threads.

> If I am supposed to subscribe before sending, fine - but I can't
> promise I will spend much time on "real" work.

Subscribing would be useful, as otherwise I have to manually approve
each post you make.  

> Thanks a lot anyway,

And thank you!


Nathan Kurz
na...@ve...