Re: [pilot-db-list] editing on a PC

[Yedidyah Bar-D. <di...@ta...>]

On Mon, Apr 26, 2004 at 02:06:33PM -0600, Nathan Kurz wrote:
[snip]
> 
> Yes, certainly a tool that did not throw away all the information it
> did not understand would be a useful improvement.  I must confess I
> haven't actually tried using palm-db-tools in the last couple years. :(

And you don't need to? Do you use a Palm regularly and is it good enuogh?
My typing speed on it is maybe 10 times slower than on a PC. That's the
main reason for me to edit on a PC. The actual user types much slower, but
he wants/needs to see more information at the same time. I even thought
about patching pilot-db to give each record in the listview more than one
screen line, to see longer fields without entering the recordview. Does
this sound good? Do you have any idea if it's easy to do?

> 
> > But when writing for a PC, we can use some higher level language. Either
> > a general-purpose scripting language (such as perl or python),
> 
> Yes, definitely.  I think the best way to achieve this might be to
> have a C language library that allows access to PDB files (ideally one
> that actually shares most of its code with the Palm version), and then

Ideally. But is it practical? From looking at both sources, it seems it
will require mostly rewriting at least one of them.

> write some interfaces to this from Perl, Python, etc.  But just doing
> it directly in some other language would be fine too.
> 
> At this point, we could happily benefit from anything that works.
> 
> > is what I suggested, to use a tool that is specifically intended for such
> > a thing - a tool in which you define your data in some language and can
> > automatically edit or export/import it, without adding code in a lower
> > level language.
> 
> Sadly, I fear what we really need is just a good definition of our
> data format.  Currently, there does not seem to be one other than as
> defined by the current C code.

Yes.
My current patch, from reading the code, to the file docs/format.txt, is:
In the CHUNK_FIELD_TYPES section, add:
  6 - List
  7 - Link
  8 - Float
  9 - Calculated
  10 - Linked
That's the easy one. Then add 3 sections: "CHUNK_DATABASE_INFO (255)"
and "CHUNK_ADVANCED_FILTER (1024)" (not yet documented), and

CHUNK_GLOBAL_SCRIPTS (512)

  char name[32]
  UInt8 bytecode_sz
  UInt8 version? 0x20
  UInt8 access
  UInt8 returnType
  UInt8 * bytecode (array of bytecode_sz bytes)

I also tried adding to palm-db-tools support for CHUNK_GLOBAL_SCRIPTS,
even without parsing the bytecode (which I do want to have - I even have
dreams of pdb2sql that will also create SQL views according to the views
and scripts you have), but after many hours of work got something that
works with a bug, which some more hours were not enough to solve. That's
the point I decided C isn't the right language for this - it's too hard
to debug. Well, at least for me - maybe there are better programmers that
will do it. Ah, one more thing: It's written in C++, not C, and I do not
know C++. This was the first time I tried to debug a C++ program. Is the
palm-db-tools project alive? Should I correspond with them, or here?

A patch against 0.3.6 of my current try is at
<http://www.cs.tau.ac.il/~didi/palm-db-tools-global-scripts.patch>, but
as I said, it's not working. In one of the directions (don't remember
which), it chops the bytecode in the first zero byte. Sounds like a
trivial wrong use of a *str* function, I know, but I could not find it.
That's a 300 added lines patch, way too much, IMHO, for such a thing.
I think in a very specific language for defining data, it should not be
much longer than the 10 lines it takes in English (in format.txt).

BTW, do you want to be in the "To:" line? I manually send to the list
only, guessing it's annoying for you to get everything twice. Is it?
-- 
Didi