pilot-db-list

[pilot-db-list] fatal exception error

[Robert D. <rda...@ne...>]

Greetings,

I have used Pilot DB on my Handspring Visor Platinum. It worked with 
out any problems.
I now am using a Visor Prism (color) - when installing any version, I 
get the message "Fatal Exception" and have to hard reset my Visor.

I have an Apple computer running OSX.

Please advise.

Thanks,
Bob Dambman

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:
> > > > 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.

I searched some more and found a few other relevant tools. Some of them:

<http://www.eecs.harvard.edu/~nr/pilot/pdb/>
"This program converts PDB files to a human-readable, human-editable, ASCII form, and back again. In fact, the ASCII form is designed to be more than just editable by humans; it's also easily editable by programs, provided the programs are written in a little language called Lua. The converter translates between PDB files and Lua data values."
They already have modules for jfile and mobiledb. jfile is 400 lines,
mobiledb is 210. Quite dense (compared to 790 lines for JFile3.{h,cpp}
and 764 for MobileDB.{h,cpp} in palm-db-tools).
Last release was in 2000.

<http://obermuhlner.com/public/Projects/Palm/PDBC/>
"    ``pdbc'' is a compiler than converts a source file into a Palm DataBase
    (PDB) file or Palm Resource (PRC) file. The language the ``pdbc''
    compiler understands is designed to be easy to understand und write. It
    is powerful enough to give the freedom to describe the binary content of
    the database records in a variety of ways.

    It should also be easy to generate the ``pdbc'' source file from another
    language (e.g. Perl).

    In addition to the ``pdbc'' tool there is also 'pdbdec'. pdbdec is a
    decompiler which converts any valid PDB or PRC file into a ``pdbc''
    source file. This is useful to check the correctness of the ``pdbc''
    generated file and to analyze other PDB files."
It is not easy to add specific support for pilot-db to it, but it still
seems useful. In the man page he says he has some idea for templates,
which sounds just like what I thought about, but only an idea.
Latest release from 2002.

The terms I used in google for the searches: 'pdb binary convert',
'pdb binary editor', 'pdb structure convert'. I can't be sure I did not
miss some killerapp that does everything, but it sure didn't use the
right words :-)

What do you think?
-- 
Didi

Re: [pilot-db-list] Script in calculated field... what am I missing?

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

On Mon, May 03, 2004 at 01:29:43PM -0600, Nelson E. Ingersoll wrote:
> 
>    I am learning Pilot-DB, so please be patient with me.   I am using 
> DB on my new Tungsten|E.  The database and program all reside in the 
> main memory.
> 
>    As a test I have made two databases.  One is a copy of my CD 
> database from CATraxx.  It has 340 records and the import, using DB-Edit 
> worked GREAT!   The second is a more interactive database... 
> specifically a fuel log database where I enter appropriate information 
> such as cost of fuel, amount of fuel, total price, and trip distance 
> since last fill-up, followed by MPG (calculated Miles Per Gallon).
> 
>    In this simple example cost, quantity, and total price are floats, 
> trip distance is an integer and MPG is calculated by dividing trip 
> distance by quantity of fuel.   In the script section I entered when 
> declaring the calculated field I put "/ %5 %3 ".  The field numbers are 
> those I see in the database design screen.

You should put parens around, e.g. "(/ %5 %3)". That's LISP.
-- 
Didi

> 
>    I get an error "?Who knows?" (after entry) or "[broken]" (after a 
> rebuild or recalculate).  I've been reading the documents trying to 
> figure out my mistake but have failed so far.  Any thoughts?
> 
> Nelson E. Ingersoll
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Pilot-db-list mailing list
> Pil...@li...
> https://lists.sourceforge.net/lists/listinfo/pilot-db-list
> 
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.

Re-2: [pilot-db-list] Devs needing PDAs to test / Donations?

[<hol...@di...>]

I agree completely with Marc's views. 

Marc - Once again I would like to thank you for all the effort 
you put into the program - in spite of the tons of mails of 
criticism (including mine) - or rather demands.

I wish you all the best for the future.

> This idea was the first idea of the Open-Source development, 
> but the minds change.

Yes, but this seems to be the trend!

The next step will be including Ad's instead of donations, and 
then sponsors and finally some commercial exploiters declaring
OpenSource as being illegal and then taking over.

Look at Napster!

If contribution to the community is replaced by money, then it
not the kind of community I would like to invest my time in!

Sorry for getting philosophical and sentimental.

Hans

-------- Original Message --------
Subject: Re: [pilot-db-list] Devs needing PDAs to test / Donations? (03-Mai-2004 19:51)
From:    mar...@la...
To:      hol...@di...

> Like all others people who worked on the project, i think i
> must give my point of view.
> I'm not as radical as Hans but my idea is closed. I use 
> Open-Source software, and i don't give never money. My
> retribution to the community was Pilot-DB. My idea is when you
> are able give a part of your work to the community, that is
> the retribution. This idea was the first idea of the
> Open-Source development, but the minds change.
> 
> To make money with Pilot-DB, i implemented the plugin feature.
> Everybody can make a Plugin and sell it to anotherone. There
> is no rule on this part. 
> 
> After if you donate, how do you redistribute the money? How
> can you tell this personn worked more than this one? And if
> you receive money and you stop to contribute to the project,
> the new maintainer works for you wallet? I think he will not
> like that. And i think you make a contract with the users and
> you certify that you will maintain Pilot-DB in the future.
> 
> If Nathan want to be retribute, he can. For myself, i don't
> want money. I paid my Open-Source contribution (but i continue
> in others projects but not as maintainer), now all is complete
> for me. When i maintained Pilot-DB, I asked more and more
> help, and i find that i didn't receive enought help (i thank
> again everybody who help me, Hans, Scott, documentation
> writters, translation writters, beta-testers... ), i spent to 
> much time to answer to the e-mails.
> 
> Salut,
> Marc.

Acc=E9dez au courrier =E9lectronique de La Poste : www.laposte.net ; 

> 3615 LAPOSTENET (0,34=80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80/mn)


> 
> 
> To: hol...@di...
> Cc: pil...@li...


To: mar...@la...
    pil...@li...

[pilot-db-list] Script in calculated field... what am I missing?

[Nelson E. I. <nin...@cs...>]

    I am learning Pilot-DB, so please be patient with me.   I am using 
DB on my new Tungsten|E.  The database and program all reside in the 
main memory.

    As a test I have made two databases.  One is a copy of my CD 
database from CATraxx.  It has 340 records and the import, using DB-Edit 
worked GREAT!   The second is a more interactive database... 
specifically a fuel log database where I enter appropriate information 
such as cost of fuel, amount of fuel, total price, and trip distance 
since last fill-up, followed by MPG (calculated Miles Per Gallon).

    In this simple example cost, quantity, and total price are floats, 
trip distance is an integer and MPG is calculated by dividing trip 
distance by quantity of fuel.   In the script section I entered when 
declaring the calculated field I put "/ %5 %3 ".  The field numbers are 
those I see in the database design screen.

    I get an error "?Who knows?" (after entry) or "[broken]" (after a 
rebuild or recalculate).  I've been reading the documents trying to 
figure out my mistake but have failed so far.  Any thoughts?

Nelson E. Ingersoll

Re: [pilot-db-list] Devs needing PDAs to test / Donations?

[marc\.chalain <mar...@la...>]

Like all others people who worked on the project, i think i
must give my=
 point of view.
I'm not as radical as Hans but my idea is closed. I use=0D
=
Open-Source software, and i don't give never money. My
retribution to th=
e community was Pilot-DB. My idea is when you
are able give a part of yo=
ur work to the community, that is
the retribution. This idea was the fir=
st idea of the
Open-Source development, but the minds change.

To make=
 money with Pilot-DB, i implemented the plugin feature.
Everybody can ma=
ke a Plugin and sell it to anotherone. There
is no rule on this part.=0D
=

After if you donate, how do you redistribute the money? How
can you te=
ll this personn worked more than this one? And if
you receive money and =
you stop to contribute to the project,
the new maintainer works for you =
wallet? I think he will not
like that. And i think you make a contract w=
ith the users and
you certify that you will maintain Pilot-DB in the fut=
ure.

If Nathan want to be retribute, he can. For myself, i don't
want=
 money. I paid my Open-Source contribution (but i continue
in others pro=
jects but not as maintainer), now all is complete
for me. When i maintai=
ned Pilot-DB, I asked more and more
help, and i find that i didn't recei=
ve enought help (i thank
again everybody who help me, Hans, Scott, docum=
entation
writters, translation writters, beta-testers... ), i spent to=0D
=
much time to answer to the e-mails.

Salut,
Marc.=0A=0AAcc=E9dez au co=
urrier =E9lectronique de La Poste : www.laposte.net ; =0A3615 LAPOSTENET =
(0,34=80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80/mn)=0A=0A

Re: [pilot-db-list] archive not updated

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

On Wed, Apr 28, 2004 at 01:28:44AM +0300, Yedidyah Bar-David wrote:
> On Tue, Apr 27, 2004 at 03:02:51PM -0600, Nathan Kurz wrote:
> > On Tue, Apr 27, 2004 at 10:55:34PM +0300, Yedidyah Bar-David wrote:
> > > Sorry for a probably FAQ, but:
> > > The web archive is not updated. I did not keep all messages, assuming
> > > I can use the archive.
> > > 1. Does anyone know why it's not updated?
> > > 2. Is it possible to ask mailman to send to me messages? I sent 'help'
> > > to pilot-db-list-request and it does not have a command for this.
> > 
> > I just checked on the SourceForge status page and found this:
> > 
> >   ( 2004-04-19 05:44:42 - Mailing List Service ) Performance testing
> >   of an updated SourceForge.net mailing list archive architecture has
> >   commenced as of the morning of 2004-04-19; this change is expected
> >   to increase search performance and resolve long-term mailing list
> >   archive reliability problems. During this test period (of up to a
> >   few days), archive updates will be suspended temporarily and
> >   archives will be backdated to their state as of approx. two weeks
> >   ago. Pending completion of testing and performance monitoring,
> >   updates will resume.
> > 
> > As far as I know, there is no general way to get the non-archived
> > messages.  In general, my impression is that SourceForge is dying a
> > slow painful death.  Many good projects have left due to reliability
> > problems.  We'd probably leave too, if we were strong enough to move.
> 
> :-(
> Hopefully we will. Am I now part of "we"?
> 
> > 
> > I've got most of the April messages undeleted.  Should I bundle
> > together those that I can find and send you a batch of them?
> 
> Please do. The one I wanted specifically was with the URL of a multi-
> section prc-tools, but I already found it with google, so it's not that
> important. Actually, I made quite a lot of progress - I compiled 1.1.0
> with it, and using the patched gdb found the source of the problem I
> mentioned (of pilot-db crashing in Up/Down arrow).
> 
> The bug is (mainly, maybe not only) in SetupRecordData:
> It goes over the Schema's fields rather than over the View's fields.
> The place in which the actual crash happens is in EditViewScroll,
> in the line 'str = LockMemHandle(fields[fieldIndex].editor->h);' (847).
> fieldIndex is counted in the View, but fields was initialized according
> to the DB Schema.

Well, I am very happy to announce a fix. It wasn't, after all, in
SetupRecordData - the description above was a bit harsh and stupid of
me. It was a simple bug directly in the place of the crash, but is only
revealed in very specific cases (described below).
The patch is this one-liner:
--- ../../../t/pilot-db/src/edit.c      Fri Nov 14 18:14:06 2003
+++ edit.c      Mon May  3 18:58:04 2004
@@ -844,7 +844,7 @@
 
                 switch (CurrentSource->schema.fields[ActiveView->cols[fieldIndex].fieldNum].type) {
                 case FIELD_TYPE_STRING:
-                    str = LockMemHandle(fields[fieldIndex].editor->h);
+                    str = LockMemHandle(fields[ActiveView->cols[fieldIndex].fieldNum].editor->h);
                     height += FldCalcFieldHeight(str, columnWidth)
                         * FntLineHeight();
                     UnlockMemPtr(str);

Later,
-- 
Didi

> 
> A trivial DB that shows the bug:
> Create a DB with enough rows (num of screen lines +, say, 2. I tried
> it with a 12 field DB), make the second a boolean (or any other type
> with no editor) and the others string, then create a listview in which
> the second field is e.g. the first DB's field (a string), edit a row,
> press Down, Up, it will crash. Why? Because it tries to access the
> second field's editor, because it's a string, but it was initialized
> without an editor, because it's boolean.
> You can get my minimal db in <http://www.cs.tau.ac.il/~didi/testdb.pdb>.
> It took me several hours to find this, and I'm going to sleep now (it's
> 01:30 now and I work tomorrow). If you want I can try to write a patch.
> Unless it's only in SetupRecordData, it's going to be quite complex -
> it seems as though the original code was for a DB without a listview
> object, in which a listview is the same as the DB (at least in terms
> of field order), and later a listview was added, without taking care
> of all the places. What I do not understand yet is why PgDn/PgUp do
> work (and that's what I told my brother-in-law to do for the time being).
> -- 
> Didi
> 

Re: [pilot-db-list] Devs needing PDAs to test / Donations?

[<Cyb...@ao...>]

In a message dated 5/1/2004 9:58:18 PM US Mountain Standard Time, 
na...@ve... writes:
> From:    dav...@ya...
> To:      pil...@li...
>
> > Have you discussed with Tom or any of the other developers of
> > putting up a Donate link?  I certainly would be willing to donate
> > $$ to the cause (I have more of this than time.) And perhaps
> > others on the list would as well.

This is the only discussion that there has been.  I _was_ approached
by someone a few weeks ago about someone who was interested in making
a donation in return for some specific feature additions, but because
of his short time frame and the large size of what he needed we
decided it would make more sense to do it with me as a private
contract.  Then the project he was going to need it for fell through.

> > If enough money is donated, you guys could pick up some actual new
> > rev palms (PalmOS4 or higher) or Sonys, or whatever your
> > preference is so you have your own test bed right in front of you.

Lacking a modern Palm pilot is probably less of a development
impediment than it sounds.  The real problem is that the modern Palm
Simulators (not the older Emulator, aka POSE) run only on Windows.  I
tend to run only Linux, which generally is a great development
environment and historically has been well supported by Palm, but is
not currently being supported much at all.

So while having a new Palm would be better than nothing, having a
working Simulator would actually be a much better situation.  It's
faster, smoother, allows one to switch and test different devices, and
is easier to debug.  Unfortunately, convincing Palm and the other
manufacturers to do this---or to help get the Simulator working under
Wine---is a much harder task than just buying a new device.

> > I have also been accumulating Palm Bucks.  If I get enough, I
> > would even be willing to part with my dear, trusty old m130 if
> > your interested...

That might be a useful thing to have, although what would be more
useful would be a device that supports high resolution.  That's what's
proving hardest to debug because the Emulator does not support it.

> > But I think putting up a donate link might be the way to go.  Not
> > sure what the sourceforge rules are on this.
> > What are your thoughts?

SourceForge sent me mail a while ago strongly encouraging me to put up
such a link.  My thought was that we are too loosely organized to make
use of such a donation right now.  Equipment would be a possible use,
but I'm not sure if it would be a good use of funds.  Paying for a
couple PalmSource trouble tickets might be another use that would
serve us well in the future when we run into devlopment brick walls.


> From: hol...@di... [mailto:hol...@di...] 
> Sent: Saturday, May 01, 2004 8:04 AM
> 
> Donations? A definite NO!! This is an OpenSource program!

I'm not as strongly against the idea as this.  There may be points in
the future where it would be useful, but probably not right now.

> Whom should such a donation go to? 

I think the better question is for what, not for whom.  If a donation
of money or used equipment would improve the rate of development, I
wouldn't argue against it.  I'm just not sure it would right now.

> It would be unfair if the 'old' programmers, who are not
> active anymore, but on whose ideas this great program is
> based on, do not benefit from such 'donations'. 

Well, if the donation is of testing equipment, I'd think it would be
quite fair if it would go to anyone who is willing to commit to using
it for increased testing.  If that would either attract new people, or
reinvolve old ones, I don't see much of a problem with fairness.

> The best 'donation' that one can give is one's own time
> by helping out.
> There are many ways of helping out - Beta-Testing is the
> easiest - one can make databases available that one
> has made - one can help out with icons etc. 

I'd agree that this is absolutely true.  Time is certainly my limiting
factor right now.  The testers that have been helping with the
alpha-releases have helped things go a lot faster.

> THIS is what is required - upholding the spirit of 
> OpenSource programs!! This is more precious than money!

On the other hand, there are people (as stated above) who would like
to help with development but currently have more money than time
available to them.  If that money could help the development, then it
would be a valuable gift.  But right now what we need most is more
involvement on the development side, and I'm not sure the money could
be put to a good enough use.  But I wouldn't eliminate the idea.

--nate


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Pilot-db-list mailing list
Pil...@li...
https://lists.sourceforge.net/lists/listinfo/pilot-db-list
I for one have been known to help dev many different projects including 
Stampede, SourceMage, and Wine. Lately though with all my work and a LOT of 
personal stuff getting in the way I am having more and more time taken away leaving 
me with little to do but read some email and go to bed. 
So for me if there is a way to donate to the project even though I have 
little time it would be great. 
Yes I do understand some people think opensource means spend no money, but 
this idea usually does not pan out very well in the real world. However I do 
respect nate's hold on accepting donations at this time due to not knowing where 
it should all go to best help out the project. 
If any ideas for hardware are good. I recommend putting up a "wish-list" on 
the website so if anyone has the hardware to donate they can instantly see it. 
Like for example would a 2mb Zire be a good thing only to test cpu and memory 
load of the database engine. What kind of high res palm would be a good idea 
to have to test the high res you cant on the emulator?

Re: [pilot-db-list] Devs needing PDAs to test / Donations?

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

> From:    dav...@ya...
> To:      pil...@li...
>
> > Have you discussed with Tom or any of the other developers of
> > putting up a Donate link?  I certainly would be willing to donate
> > $$ to the cause (I have more of this than time.) And perhaps
> > others on the list would as well.

This is the only discussion that there has been.  I _was_ approached
by someone a few weeks ago about someone who was interested in making
a donation in return for some specific feature additions, but because
of his short time frame and the large size of what he needed we
decided it would make more sense to do it with me as a private
contract.  Then the project he was going to need it for fell through.

> > If enough money is donated, you guys could pick up some actual new
> > rev palms (PalmOS4 or higher) or Sonys, or whatever your
> > preference is so you have your own test bed right in front of you.

Lacking a modern Palm pilot is probably less of a development
impediment than it sounds.  The real problem is that the modern Palm
Simulators (not the older Emulator, aka POSE) run only on Windows.  I
tend to run only Linux, which generally is a great development
environment and historically has been well supported by Palm, but is
not currently being supported much at all.

So while having a new Palm would be better than nothing, having a
working Simulator would actually be a much better situation.  It's
faster, smoother, allows one to switch and test different devices, and
is easier to debug.  Unfortunately, convincing Palm and the other
manufacturers to do this---or to help get the Simulator working under
Wine---is a much harder task than just buying a new device.

> > I have also been accumulating Palm Bucks.  If I get enough, I
> > would even be willing to part with my dear, trusty old m130 if
> > your interested...

That might be a useful thing to have, although what would be more
useful would be a device that supports high resolution.  That's what's
proving hardest to debug because the Emulator does not support it.

> > But I think putting up a donate link might be the way to go.  Not
> > sure what the sourceforge rules are on this.
> > What are your thoughts?

SourceForge sent me mail a while ago strongly encouraging me to put up
such a link.  My thought was that we are too loosely organized to make
use of such a donation right now.  Equipment would be a possible use,
but I'm not sure if it would be a good use of funds.  Paying for a
couple PalmSource trouble tickets might be another use that would
serve us well in the future when we run into devlopment brick walls.


> From: hol...@di... [mailto:hol...@di...] 
> Sent: Saturday, May 01, 2004 8:04 AM
> 
> Donations? A definite NO!! This is an OpenSource program!

I'm not as strongly against the idea as this.  There may be points in
the future where it would be useful, but probably not right now.

> Whom should such a donation go to? 

I think the better question is for what, not for whom.  If a donation
of money or used equipment would improve the rate of development, I
wouldn't argue against it.  I'm just not sure it would right now.

> It would be unfair if the 'old' programmers, who are not
> active anymore, but on whose ideas this great program is
> based on, do not benefit from such 'donations'. 

Well, if the donation is of testing equipment, I'd think it would be
quite fair if it would go to anyone who is willing to commit to using
it for increased testing.  If that would either attract new people, or
reinvolve old ones, I don't see much of a problem with fairness.

> The best 'donation' that one can give is one's own time
> by helping out.
> There are many ways of helping out - Beta-Testing is the
> easiest - one can make databases available that one
> has made - one can help out with icons etc. 

I'd agree that this is absolutely true.  Time is certainly my limiting
factor right now.  The testers that have been helping with the
alpha-releases have helped things go a lot faster.

> THIS is what is required - upholding the spirit of 
> OpenSource programs!! This is more precious than money!

On the other hand, there are people (as stated above) who would like
to help with development but currently have more money than time
available to them.  If that money could help the development, then it
would be a valuable gift.  But right now what we need most is more
involvement on the development side, and I'm not sure the money could
be put to a good enough use.  But I wouldn't eliminate the idea.

--nate

RE: [pilot-db-list] Devs needing PDAs to test / Donations?

[Kyle d. <dav...@ya...>]

Tag hans,

	I didn't mean to offend.  After I had already sent the message out,
I thought about how it wouldn't be fair to the developers who are no longer
involved.

	However, it wasn't necessarily *my idea* I just merely noticed other
projects at sourceforge have donation links.  These products are just as
worthwhile to me (Clamwin, GAIM, etc.) as pilot-db is.  I guess I was just
looking for an easy way out (I know that I should be more involved and
testing it on the m130, and the departments TC (when it's working) but right
now I just don't have the time. 

	Again, entshuldegung.  I have contributed a couple of databases.  I
also feel like I have tested (pilot-DB) because I use it at my job every
day.  However, I feel like the rudimentary testing I'm able to do on the
units I have isn't good enough.  I don't have POSE installed, even if I did,
I'm not sure I'd be able to duplicate an error on POSE that I get on my m130
or the department's TC.

	BTW, I like the web page design, es ist sehr toll.



-----Original Message-----
From: hol...@di... [mailto:hol...@di...] 
Sent: Saturday, May 01, 2004 8:04 AM
To: pil...@li...
Cc: dav...@ya...
Subject: Re: [pilot-db-list] Devs needing PDAs to test / Donations?

Hi,



Donations? A definite NO!! This is an OpenSource program!



This means that anyone who is willing to help out can take 

part - I for my part look after the Web-Site.



Whom should such a donation go to? 



It would be unfair if the 'old' programmers, who are not

active anymore, but on whose ideas this great program is

based on, do not benefit from such 'donations'. 



This can only be done if someone makes his own

program and looks for people to help him/her out. 

This is NOT the spirit of OpenSource programming!



OpenSource programs such as this one live from the fact 

that various people with various interests, from various 

regions of the world get together to develop software 

which is freely available to every one.



The best 'donation' that one can give is one's own time

by helping out.



There are many ways of helping out - Beta-Testing is the

easiest - one can make databases available that one

has made - one can help out with icons etc. 



THIS is what is required - upholding the spirit of 

OpenSource programs!! This is more precious than money!



The license is GNU. Have a look at it.



Hans Ajiet Holtkamp



-------- Original Message --------

Subject: [pilot-db-list] Devs needing PDAs to test, possy solution?
(28-Apr-2004 20:27)

From:    dav...@ya...

To:      pil...@li...



> Nate, (et al lurking developers or developing tinkerers..)

> 

>      Have you discussed with Tom or any of the other developers of 
> putting

> up a Donate link?  I certainly would be willing to donate $$ to the 
> cause (

> I

> have more of this than time.) And perhaps others on the list would as
well.

> If enough money is donated, you guys could pick up some actual new rev

> palms

> (PalmOS4 or higher) or Sonys, or whatever your preference is so you 
> have

> your own test bed right in front of you.

> 

> 	I have also been accumulating Palm Bucks.  If I get enough, I would

> even be willing to part with my dear, trusty old m130 if your
interested...

> 

> 	But I think putting up a donate link might be the way to go.  Not

> sure what the sourceforge rules are on this.

> 

> 	What are your thoughts?

> 

> 

> 

> -------------------------------------------------------

> This SF.Net email is sponsored by: Oracle 10g

> Get certified on the hottest thing ever to hit the market... Oracle 10g. 

> Take an Oracle 10g class now, and we'll give you the exam FREE.

> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

> _______________________________________________

> Pilot-db-list mailing list

> Pil...@li...

> https://lists.sourceforge.net/lists/listinfo/pilot-db-list

> 

> To: pil...@li...





To: pil...@li...

Cc: dav...@ya...

Re: [pilot-db-list] Devs needing PDAs to test / Donations?

[<hol...@di...>]

Hi,

Donations? A definite NO!! This is an OpenSource program!

This means that anyone who is willing to help out can take 
part - I for my part look after the Web-Site.

Whom should such a donation go to? 

It would be unfair if the 'old' programmers, who are not
active anymore, but on whose ideas this great program is
based on, do not benefit from such 'donations'. 

This can only be done if someone makes his own
program and looks for people to help him/her out. 
This is NOT the spirit of OpenSource programming!

OpenSource programs such as this one live from the fact 
that various people with various interests, from various 
regions of the world get together to develop software 
which is freely available to every one.

The best 'donation' that one can give is one's own time
by helping out.

There are many ways of helping out - Beta-Testing is the
easiest - one can make databases available that one
has made - one can help out with icons etc. 

THIS is what is required - upholding the spirit of 
OpenSource programs!! This is more precious than money!

The license is GNU. Have a look at it.

Hans Ajiet Holtkamp

-------- Original Message --------
Subject: [pilot-db-list] Devs needing PDAs to test, possy solution? (28-Apr-2004 20:27)
From:    dav...@ya...
To:      pil...@li...

> Nate, (et al lurking developers or developing tinkerers..)
> 
>      Have you discussed with Tom or any of the other developers of putting
> up a Donate link?  I certainly would be willing to donate $$ to the cause (
> I
> have more of this than time.) And perhaps others on the list would as well.
> If enough money is donated, you guys could pick up some actual new rev 
> palms
> (PalmOS4 or higher) or Sonys, or whatever your preference is so you have
> your own test bed right in front of you.
> 
> 	I have also been accumulating Palm Bucks.  If I get enough, I would
> even be willing to part with my dear, trusty old m130 if your interested...
> 
> 	But I think putting up a donate link might be the way to go.  Not
> sure what the sourceforge rules are on this.
> 
> 	What are your thoughts?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Pilot-db-list mailing list
> Pil...@li...
> https://lists.sourceforge.net/lists/listinfo/pilot-db-list
> 
> To: pil...@li...


To: pil...@li...
Cc: dav...@ya...

[pilot-db-list] Devs needing PDAs to test, possy solution?

[Kyle d. <dav...@ya...>]

Nate, (et al lurking developers or developing tinkerers..)

     Have you discussed with Tom or any of the other developers of putting
up a Donate link?  I certainly would be willing to donate $$ to the cause (I
have more of this than time.) And perhaps others on the list would as well.
If enough money is donated, you guys could pick up some actual new rev palms
(PalmOS4 or higher) or Sonys, or whatever your preference is so you have
your own test bed right in front of you.

	I have also been accumulating Palm Bucks.  If I get enough, I would
even be willing to part with my dear, trusty old m130 if your interested...

	But I think putting up a donate link might be the way to go.  Not
sure what the sourceforge rules are on this.

	What are your thoughts?

Re: [pilot-db-list] archive not updated

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

On Tue, Apr 27, 2004 at 03:02:51PM -0600, Nathan Kurz wrote:
> On Tue, Apr 27, 2004 at 10:55:34PM +0300, Yedidyah Bar-David wrote:
> > Sorry for a probably FAQ, but:
> > The web archive is not updated. I did not keep all messages, assuming
> > I can use the archive.
> > 1. Does anyone know why it's not updated?
> > 2. Is it possible to ask mailman to send to me messages? I sent 'help'
> > to pilot-db-list-request and it does not have a command for this.
> 
> I just checked on the SourceForge status page and found this:
> 
>   ( 2004-04-19 05:44:42 - Mailing List Service ) Performance testing
>   of an updated SourceForge.net mailing list archive architecture has
>   commenced as of the morning of 2004-04-19; this change is expected
>   to increase search performance and resolve long-term mailing list
>   archive reliability problems. During this test period (of up to a
>   few days), archive updates will be suspended temporarily and
>   archives will be backdated to their state as of approx. two weeks
>   ago. Pending completion of testing and performance monitoring,
>   updates will resume.
> 
> As far as I know, there is no general way to get the non-archived
> messages.  In general, my impression is that SourceForge is dying a
> slow painful death.  Many good projects have left due to reliability
> problems.  We'd probably leave too, if we were strong enough to move.

:-(
Hopefully we will. Am I now part of "we"?

> 
> I've got most of the April messages undeleted.  Should I bundle
> together those that I can find and send you a batch of them?

Please do. The one I wanted specifically was with the URL of a multi-
section prc-tools, but I already found it with google, so it's not that
important. Actually, I made quite a lot of progress - I compiled 1.1.0
with it, and using the patched gdb found the source of the problem I
mentioned (of pilot-db crashing in Up/Down arrow).

The bug is (mainly, maybe not only) in SetupRecordData:
It goes over the Schema's fields rather than over the View's fields.
The place in which the actual crash happens is in EditViewScroll,
in the line 'str = LockMemHandle(fields[fieldIndex].editor->h);' (847).
fieldIndex is counted in the View, but fields was initialized according
to the DB Schema.

A trivial DB that shows the bug:
Create a DB with enough rows (num of screen lines +, say, 2. I tried
it with a 12 field DB), make the second a boolean (or any other type
with no editor) and the others string, then create a listview in which
the second field is e.g. the first DB's field (a string), edit a row,
press Down, Up, it will crash. Why? Because it tries to access the
second field's editor, because it's a string, but it was initialized
without an editor, because it's boolean.
You can get my minimal db in <http://www.cs.tau.ac.il/~didi/testdb.pdb>.
It took me several hours to find this, and I'm going to sleep now (it's
01:30 now and I work tomorrow). If you want I can try to write a patch.
Unless it's only in SetupRecordData, it's going to be quite complex -
it seems as though the original code was for a DB without a listview
object, in which a listview is the same as the DB (at least in terms
of field order), and later a listview was added, without taking care
of all the places. What I do not understand yet is why PgDn/PgUp do
work (and that's what I told my brother-in-law to do for the time being).
-- 
Didi

Re: [pilot-db-list] development environment (was: Hebrew support)

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

> BTW, I tried playing with the simulator very briefly. I saw it has its
> own ROMs, which IIRC are the really compatible with real devices' ROMs.
> Is it so? Doesn't this mean that for debugging a problem with a new real
> device you still need a new real device (unless the problem isn't specific
> to it, but rather is related to high resolution etc.)?

There are some device specific Simulator ROM's as well, but you are
correct that they are not identical to the real ROM's.  The supposed
advantage is that as a Simulator rather than an Emulator, it can be
more aggressive in flagging subtle bugs.  Personally, I think the
Emulator made much more sense, but this could be my prejudice just
because it is open source and works on Linux.

> That's just fine with me - 1.1.0 is ok for me. I just wanted to make
> sure that CVS doesn't also include fixes to bugs in 1.1.0 (and not only
> the middle of adding new features). Are you sure it's not the case?

It's possible (and certainly seemed probable) that it contains fixes
not contained in 1.1.0, but I haven't found them yet.  Instead I've
found layers of untested code with subtle untested bugs, mismatched
parentheses in some code branches (indicating code was never
compiled), and the absence of fixes present in the 1.1.0 code.

The hope that it included fixes as well as problems was what kept me
plugging away at it, but I've now decided that that hope was
misplaced, and the lack of finding these fixes is why I'm planning to
rollback to version 1.1.0.  I'm uncertain about this decision, though.

> For example, io.c from 1.1.0 #includes CharAttr.h, which does not exist
> in sdk5r3 (but does in older versions). CVS does not include it. Not that
> it's such a big thing, but maybe there are other fixes.

This was one of the first changes I made to the CVS code.  You can
browse <http://cvs.sourceforge.net/viewcvs.py/pilot-db/pilot-db/src/>
to get an idea of what I've changed versus what was found there.  So
trivially true: it is going to have to be redone as a fix
(discouraging) but it doesn't count as a fix found in the CVS.

> > > > Yes, external SDK's are required for these.  Worse, these SDK's aren't
> > > > all easily available, and need to be extensively massaged if they are
> > > > to work with GCC (prc-tools).  While you can build successfully
> > > > without them, in the CVS version I found bugs in the non-enabled code
> > > > path.  Contact me if you'd like help getting these SDK's.
> > > 
> > > No, unless you think I should also use them with 1.1.0.
> > 
> > Probably you should, but you are more likely to be safe without them.
> 
> If it's trivial for you to email, and not legally or otherwise
> problematic, go ahead. I'd rather work on an environment as yours and
> see the same bugs you see.

I'll try to wrap them up for you tomorrow.  Anyone else interested in
trying to do developement?

--nate

Re: [pilot-db-list] archive not updated

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

On Tue, Apr 27, 2004 at 10:55:34PM +0300, Yedidyah Bar-David wrote:
> Sorry for a probably FAQ, but:
> The web archive is not updated. I did not keep all messages, assuming
> I can use the archive.
> 1. Does anyone know why it's not updated?
> 2. Is it possible to ask mailman to send to me messages? I sent 'help'
> to pilot-db-list-request and it does not have a command for this.

I just checked on the SourceForge status page and found this:

  ( 2004-04-19 05:44:42 - Mailing List Service ) Performance testing
  of an updated SourceForge.net mailing list archive architecture has
  commenced as of the morning of 2004-04-19; this change is expected
  to increase search performance and resolve long-term mailing list
  archive reliability problems. During this test period (of up to a
  few days), archive updates will be suspended temporarily and
  archives will be backdated to their state as of approx. two weeks
  ago. Pending completion of testing and performance monitoring,
  updates will resume.

As far as I know, there is no general way to get the non-archived
messages.  In general, my impression is that SourceForge is dying a
slow painful death.  Many good projects have left due to reliability
problems.  We'd probably leave too, if we were strong enough to move.

I've got most of the April messages undeleted.  Should I bundle
together those that I can find and send you a batch of them?

--nate

[pilot-db-list] archive not updated

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

Hi,

Sorry for a probably FAQ, but:
The web archive is not updated. I did not keep all messages, assuming
I can use the archive.
1. Does anyone know why it's not updated?
2. Is it possible to ask mailman to send to me messages? I sent 'help'
to pilot-db-list-request and it does not have a command for this.

Thanks,
-- 
Didi

Re: [pilot-db-list] development environment (was: Hebrew support)

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

On Tue, Apr 27, 2004 at 09:57:01AM -0600, Nathan Kurz wrote:
> > > I've found that the Palm Simulators _almost_ work under Wine, and
> > > perhaps someone with greater knowledge could actually make them work.
> > > I have had success running GDB on Linux ethernet connected to
> > > Simulators running on Windows.  If you do this, note that you will
> > > need gdbpanel installed for  GDB to work with a Simulator.
> > 
> > I currently won't try this, as Windows is much less convinient for me.
> > If/When you make it work with wine, I might try this.
> 
> Windows is terribly inconvenient for me as well, as besides making me
> violent, I need to borrow a laptop just to run it.  The problem is

For me it means to connect to a Windows Terminal Server at work, over
ADSL. Not that bad, compared to borrowing a laptop, but still...

> that all recent Palm devices (including all high resolution ones) will
> not run on Pose.  So if one wishes to check for compatibility, one
> either needs recent real devices to test on needs to run the Simulator.
> 
> Most of the known problems with the CVS version were with recent devices.

OK, but the *good* things are the same, I hope. So if you fix the bad
ones (or simply go to 1.1.0), I can still work with pose only, if all I
want is to add new stuff (or fix bug that also happen in pose, such as
the one I talked about).

BTW, I tried playing with the simulator very briefly. I saw it has its
own ROMs, which IIRC are the really compatible with real devices' ROMs.
Is it so? Doesn't this mean that for debugging a problem with a new real
device you still need a new real device (unless the problem isn't specific
to it, but rather is related to high resolution etc.)?

> 
> > > What this means is that you should concentrate your efforts on the
> > > 1.1.0 release code, and ignore the CVS and alpha series.  I'll try to
> > > make the appropriate changes to the CVS repository later this week.
> > > 
> > 
> > I will try and see if there is anything that works for me better with
> > the CVS version. If not, Fine. Otherwise I'll try to back-port to 1.1.0.
> 
> Feel free to use it, but to be clearer: by the end of the week, I hope
> that the CVS version will become a branch called "Scott", and the
> 1.1.0 will become the version you get by default (HEAD).  The Scott
> branch (current CVS) will be preserved for historical interest and
> occasional code consultation, but likely will never be released again.
> If you write patches for it, they will not be of use by others.

That's just fine with me - 1.1.0 is ok for me. I just wanted to make
sure that CVS doesn't also include fixes to bugs in 1.1.0 (and not only
the middle of adding new features). Are you sure it's not the case?

For example, io.c from 1.1.0 #includes CharAttr.h, which does not exist
in sdk5r3 (but does in older versions). CVS does not include it. Not that
it's such a big thing, but maybe there are other fixes.

> 
> > > Yes, external SDK's are required for these.  Worse, these SDK's aren't
> > > all easily available, and need to be extensively massaged if they are
> > > to work with GCC (prc-tools).  While you can build successfully
> > > without them, in the CVS version I found bugs in the non-enabled code
> > > path.  Contact me if you'd like help getting these SDK's.
> > 
> > No, unless you think I should also use them with 1.1.0.
> 
> Probably you should, but you are more likely to be safe without them.

If it's trivial for you to email, and not legally or otherwise
problematic, go ahead. I'd rather work on an environment as yours and
see the same bugs you see.
-- 
Didi

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

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

On Tue, Apr 27, 2004 at 09:41:13AM -0600, Nathan Kurz wrote:
> > > 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?
> 
> No, that's the sad part.  I don't actually use a Palm now.  I've got a
> Palm III deep in my closet somewhere, but I'm doing everything
> Simulators and Emulators.  I used DB on a Palm about 4 years ago, when
> Tom Dyas was just developing it, and then came back to it recently
> with an idea for how it could be made useful to me if it would support
> better linking, automatic sorting, and multi-line record displays.
> 

I also have no Palm. I do this mostly for my brother-in-law and for fun.
I also tend to think that if/when I will buy a machine of this size, I
will still want it to run Linux, and guess it will be easier for me to
use this way. But maybe I am wrong - using unix on a 80x25 text console
or on a 1300x1000 graphic one is probably very different from on a 160x160
(or even a 320x320) one.

> But as I started poking around, I realized the project was well on its
> way to dying: there was no one left on the list who even had write
> access to the SF code.  I managed to get CVS access from Tom Dyas, the
> original but no longer involved author.  I started fixing things, and
> only later realized that the CVS was junk and that 1.1.0 was the last
> code that was ever compiled.
> 
> But I don't use it currently, since without the true link support, I
> have no current use for it.  My goal is just to keep it breathing
> until a stranger from the holy land appears to save it.  But who knows
> when that will happen. :) (hope the hereticism doesn't offend)

That's not me :-)

> 
> > 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?
> 
> Great idea, hard to do because of the way records are layed out.  My
> last plan (haven't thought about it for a bit) was basically to allow
> "newlines" to be added to record views, such that items after the
> newline would appear on a second line on a per view basis.  But this
> wouldn't allow for one record to be on multiple lines.  The other way,
> but probably harder to implement, would be to just wrap at the pixel
> width if a "wrap" flag is set.  Likely one would also need word wrap.

I think both are generally needed, but not that urgent. It of course
depends on the specific use.

> 
> > > > 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.
> 
> My assumption (perhaps unjustified) was that rewriting a PDB interface
> from scratch, adding a Perl XS layer, and then writing the utility in
> Perl would be easier than modifying the current db-tools code.  
> 

Yes, that's also what I think.

> Writing the entire thing in Perl (I'm more comfortable there than
> Python) would probably be easier yet, but would be less generally
> useful.  C is usually so much easier as an interface langauage (to
> Python, to Java, etc).  
> 

I know no Perl, no Python, and no Java. Only C and sed/awk/shell (and
some other less useful (at least for this) stuff). I did not mention,
that I am a sysadmin. I do program a bit from time to time, but do not
consider myself a good programmer.

> > Is the palm-db-tools project alive?  Should I correspond with them,
> > or here?
> 
> As far as I know, it has no life other than here.  Neither
> administrator listed is still involved, and there don't appear to have
> been any changes to CVS in recent years.

Yes, I saw that.
Are you in touch with any other relevant project? jpilot-db, dbeditor?

> 
> > 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?
> 
> No, I'm happy with list only.  I added you to the first few messages
> only because I wasn't sure if you had subscribed to the list yet.

OK. This was a good opportunity to learn a bit more about mutt, and add
'subscribe pil...@li...' to my .muttrc. This also
causes mutt to add a header 'Mail-Followup-To' which it looks at to see
if you want email CCed to you or not.
-- 
Didi

Re: [pilot-db-list] development environment (was: Hebrew support)

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

> > I've found that the Palm Simulators _almost_ work under Wine, and
> > perhaps someone with greater knowledge could actually make them work.
> > I have had success running GDB on Linux ethernet connected to
> > Simulators running on Windows.  If you do this, note that you will
> > need gdbpanel installed for  GDB to work with a Simulator.
> 
> I currently won't try this, as Windows is much less convinient for me.
> If/When you make it work with wine, I might try this.

Windows is terribly inconvenient for me as well, as besides making me
violent, I need to borrow a laptop just to run it.  The problem is
that all recent Palm devices (including all high resolution ones) will
not run on Pose.  So if one wishes to check for compatibility, one
either needs recent real devices to test on needs to run the Simulator.

Most of the known problems with the CVS version were with recent devices.

> > What this means is that you should concentrate your efforts on the
> > 1.1.0 release code, and ignore the CVS and alpha series.  I'll try to
> > make the appropriate changes to the CVS repository later this week.
> > 
> 
> I will try and see if there is anything that works for me better with
> the CVS version. If not, Fine. Otherwise I'll try to back-port to 1.1.0.

Feel free to use it, but to be clearer: by the end of the week, I hope
that the CVS version will become a branch called "Scott", and the
1.1.0 will become the version you get by default (HEAD).  The Scott
branch (current CVS) will be preserved for historical interest and
occasional code consultation, but likely will never be released again.
If you write patches for it, they will not be of use by others.

> > Yes, external SDK's are required for these.  Worse, these SDK's aren't
> > all easily available, and need to be extensively massaged if they are
> > to work with GCC (prc-tools).  While you can build successfully
> > without them, in the CVS version I found bugs in the non-enabled code
> > path.  Contact me if you'd like help getting these SDK's.
> 
> No, unless you think I should also use them with 1.1.0.

Probably you should, but you are more likely to be safe without them.

--nate

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

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

> > 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?

No, that's the sad part.  I don't actually use a Palm now.  I've got a
Palm III deep in my closet somewhere, but I'm doing everything
Simulators and Emulators.  I used DB on a Palm about 4 years ago, when
Tom Dyas was just developing it, and then came back to it recently
with an idea for how it could be made useful to me if it would support
better linking, automatic sorting, and multi-line record displays.

But as I started poking around, I realized the project was well on its
way to dying: there was no one left on the list who even had write
access to the SF code.  I managed to get CVS access from Tom Dyas, the
original but no longer involved author.  I started fixing things, and
only later realized that the CVS was junk and that 1.1.0 was the last
code that was ever compiled.

But I don't use it currently, since without the true link support, I
have no current use for it.  My goal is just to keep it breathing
until a stranger from the holy land appears to save it.  But who knows
when that will happen. :) (hope the hereticism doesn't offend)

> 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?

Great idea, hard to do because of the way records are layed out.  My
last plan (haven't thought about it for a bit) was basically to allow
"newlines" to be added to record views, such that items after the
newline would appear on a second line on a per view basis.  But this
wouldn't allow for one record to be on multiple lines.  The other way,
but probably harder to implement, would be to just wrap at the pixel
width if a "wrap" flag is set.  Likely one would also need word wrap.

> > > 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.

My assumption (perhaps unjustified) was that rewriting a PDB interface
from scratch, adding a Perl XS layer, and then writing the utility in
Perl would be easier than modifying the current db-tools code.  

Writing the entire thing in Perl (I'm more comfortable there than
Python) would probably be easier yet, but would be less generally
useful.  C is usually so much easier as an interface langauage (to
Python, to Java, etc).  

> Is the palm-db-tools project alive?  Should I correspond with them,
> or here?

As far as I know, it has no life other than here.  Neither
administrator listed is still involved, and there don't appear to have
been any changes to CVS in recent years.

> 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?

No, I'm happy with list only.  I added you to the first few messages
only because I wasn't sure if you had subscribed to the list yet.

--nate

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

[pilot-db-list] development environment (was: Hebrew support)

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

On Mon, Apr 26, 2004 at 01:50:38PM -0600, Nathan Kurz wrote:
> On Mon, Apr 26, 2004 at 09:57:21PM +0300, Yedidyah Bar-David wrote:
> > OK, I will make it a separate message for each issue.
> > I also subscribed to the list. Still, there are a few things I won't
> > repeat in each message: I use Debian sid, with the following versions:
> > prc-tools 2.2.90.cvs20030306-4 (has gcc 2.95.3, gdb 5.3)
> > pose 3.5-6 (the first version working for me - for a few months I
> > was pretty sure I'll have to use the simulator on Windows, which isn't
> > as simple for me) with the ROM of a Palm m130 (PalmOS 4.1)
> > palmos sdk 5r3
> 
> I'm having luck with Pose 3.5-2 with Slackware 9 and Linux 2.2.24.  I

Yes, but Slackware's "-2" isn't Debian's. It probably took debian more
versions to get something working.

> recall problems with some versions regarding XWindows color depths
> (24bpp did not work?), but otherwise have not have problems with Pose.

I only work with 16bpp, as it's a quite old card and 24bpp is less
convinient. Thanks for telling me, though, so I won't try :-)

> As I mentioned earlier, you will need the MSectGDB patches if you want
> GDB to work more than minimally.  Note also that you need all the
> pieces of those patches installed, not just the gdb replacement.

OK.

> 
> I've found that the Palm Simulators _almost_ work under Wine, and
> perhaps someone with greater knowledge could actually make them work.
> I have had success running GDB on Linux ethernet connected to
> Simulators running on Windows.  If you do this, note that you will
> need gdbpanel installed for  GDB to work with a Simulator.

I currently won't try this, as Windows is much less convinient for me.
If/When you make it work with wine, I might try this.

> 
> > I tried and worked with pilot-db 1.1.0, 1.2.0 alpha 5 (the compiled
> > prc from sf.net), and the CVS version of today. Earlier versions needed
> > minor tweaks to compile against sdk-5r3, the CVS compiled cleanly.
> 
> Since getting involved in this project a couple months ago, I've spent
> most of my time trying to get the CVS version working again.  I've
> recently come to the conclusion that the CVS code is more trouble than
> it is worth, represents an experimental branch from the release
> version sometime prior to 1.1.0, and that the 1.1.0 should replace the
> CVS version as the current head.
> 
> What this means is that you should concentrate your efforts on the
> 1.1.0 release code, and ignore the CVS and alpha series.  I'll try to
> make the appropriate changes to the CVS repository later this week.
> 

I will try and see if there is anything that works for me better with
the CVS version. If not, Fine. Otherwise I'll try to back-port to 1.1.0.

> > I used the following to compile:
> > ./configure --enable-standard --enable-debug --enable-sony=no --enable-handera=no --enable-fiveways=no --enable-make_plugins
> > without '--enable-sony=no --enable-handera=no --enable-fiveways=no', I
> > had some compilation problems, I guess because you need a different sdk
> > for this, didn't check.
> 
> Yes, external SDK's are required for these.  Worse, these SDK's aren't
> all easily available, and need to be extensively massaged if they are
> to work with GCC (prc-tools).  While you can build successfully
> without them, in the CVS version I found bugs in the non-enabled code
> path.  Contact me if you'd like help getting these SDK's.

No, unless you think I should also use them with 1.1.0.
-- 
Didi

Re: [pilot-db-list] a bug in recordview up/down arrows

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

On Mon, Apr 26, 2004 at 02:17:55PM -0600, Nathan Kurz wrote:
> > > I fixed something similar in the CVS version (Danger! Don't go
> > > there!). 
> > 
> > Already done :-) but only on pose, it's not dangerous (except maybe
> > for my mental health?).
> 
> Yes, mostly I mean for your mental health.  When I came to this
> project a few months ago, I found that the previous maintainers had
> disappeared*, and that the CVS was left in an uncompileable state. 
> 
> Thinking that the CVS code probably represented the most current code,
> I set off getting it into working order.  Now several months later,
> I'm realizing that it represents an incomplete early branch with lots
> of untested code, and that the 1.1.0 release was maintained and
> developed outside of CVS!  Frankly, I find this disgusting.

Now I understand your comments in the alpha5 release notes.

> 
> Essentially, I've wasted my time and that of many others by having
> them test the CVS version, which now works reasonably well under Pose
> (which I have access to) but still fails miserably on most real modern
> machines (which I don't currently have access to).
> 
> AVOID THE CVS VERSION UNTIL 1.1.0 BECOMES THE NEW HEAD!
> 
> > > If possible, it would be great to see if you can reproduce
> > > this bug with a stock binary release.  There are a number of
> > 

It's the same in the binary 1.1.0, but with two different messages:
db-standard:
DB (1.1.0m) called SysFatalAlert with the message:
"MemoryMgr.c, Line:4365, NULL handle".

db-mid:
same as db-standard

db-light:
DB (1.1.0l) called SysFatalAlert with the message:
"MemoryMgr.c, Line:4372, Non-word-aligned handle".

I tried each twice, on the same DB. I will, as promised, try to make
a sample DB that exposes this. I think it happens always if you have
enough fields, though.

> > If you refer to db-1.2.0-alpha5.prc then it's mostly the same. It
> > crashes at the same point, but with a different message:
> 
> No, 1.2.0 alpha series is based on the CVS code, which I'm suggesting
> you avoid spending time on.  I was hoping you could try it a
> precompiled 1.1.0 binary and see if you can reproduce the problem.
> Otherwise, I fear it may have to do with the particular choice of
> compile options which you (and I, as the compiler of the alpha) chose.
> 
> --nate
> 
> * - Marc has just lately resurfaced, at least partially, and his
>     comments have helped me understand the role of the CVS code.
-- 
Didi

Re: [pilot-db-list] a bug in recordview up/down arrows

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

> > I fixed something similar in the CVS version (Danger! Don't go
> > there!). 
> 
> Already done :-) but only on pose, it's not dangerous (except maybe
> for my mental health?).

Yes, mostly I mean for your mental health.  When I came to this
project a few months ago, I found that the previous maintainers had
disappeared*, and that the CVS was left in an uncompileable state. 

Thinking that the CVS code probably represented the most current code,
I set off getting it into working order.  Now several months later,
I'm realizing that it represents an incomplete early branch with lots
of untested code, and that the 1.1.0 release was maintained and
developed outside of CVS!  Frankly, I find this disgusting.

Essentially, I've wasted my time and that of many others by having
them test the CVS version, which now works reasonably well under Pose
(which I have access to) but still fails miserably on most real modern
machines (which I don't currently have access to).

AVOID THE CVS VERSION UNTIL 1.1.0 BECOMES THE NEW HEAD!

> > If possible, it would be great to see if you can reproduce
> > this bug with a stock binary release.  There are a number of
> 
> If you refer to db-1.2.0-alpha5.prc then it's mostly the same. It
> crashes at the same point, but with a different message:

No, 1.2.0 alpha series is based on the CVS code, which I'm suggesting
you avoid spending time on.  I was hoping you could try it a
precompiled 1.1.0 binary and see if you can reproduce the problem.
Otherwise, I fear it may have to do with the particular choice of
compile options which you (and I, as the compiler of the alpha) chose.

--nate

* - Marc has just lately resurfaced, at least partially, and his
    comments have helped me understand the role of the CVS code.

Re: [pilot-db-list] Hebrew support

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

On Mon, Apr 26, 2004 at 09:57:21PM +0300, Yedidyah Bar-David wrote:
> OK, I will make it a separate message for each issue.
> I also subscribed to the list. Still, there are a few things I won't
> repeat in each message: I use Debian sid, with the following versions:
> prc-tools 2.2.90.cvs20030306-4 (has gcc 2.95.3, gdb 5.3)
> pose 3.5-6 (the first version working for me - for a few months I
> was pretty sure I'll have to use the simulator on Windows, which isn't
> as simple for me) with the ROM of a Palm m130 (PalmOS 4.1)
> palmos sdk 5r3

I'm having luck with Pose 3.5-2 with Slackware 9 and Linux 2.2.24.  I
recall problems with some versions regarding XWindows color depths
(24bpp did not work?), but otherwise have not have problems with Pose.
As I mentioned earlier, you will need the MSectGDB patches if you want
GDB to work more than minimally.  Note also that you need all the
pieces of those patches installed, not just the gdb replacement.

I've found that the Palm Simulators _almost_ work under Wine, and
perhaps someone with greater knowledge could actually make them work.
I have had success running GDB on Linux ethernet connected to
Simulators running on Windows.  If you do this, note that you will
need gdbpanel installed for  GDB to work with a Simulator.

> I tried and worked with pilot-db 1.1.0, 1.2.0 alpha 5 (the compiled
> prc from sf.net), and the CVS version of today. Earlier versions needed
> minor tweaks to compile against sdk-5r3, the CVS compiled cleanly.

Since getting involved in this project a couple months ago, I've spent
most of my time trying to get the CVS version working again.  I've
recently come to the conclusion that the CVS code is more trouble than
it is worth, represents an experimental branch from the release
version sometime prior to 1.1.0, and that the 1.1.0 should replace the
CVS version as the current head.

What this means is that you should concentrate your efforts on the
1.1.0 release code, and ignore the CVS and alpha series.  I'll try to
make the appropriate changes to the CVS repository later this week.

> I used the following to compile:
> ./configure --enable-standard --enable-debug --enable-sony=no --enable-handera=no --enable-fiveways=no --enable-make_plugins
> without '--enable-sony=no --enable-handera=no --enable-fiveways=no', I
> had some compilation problems, I guess because you need a different sdk
> for this, didn't check.

Yes, external SDK's are required for these.  Worse, these SDK's aren't
all easily available, and need to be extensively massaged if they are
to work with GCC (prc-tools).  While you can build successfully
without them, in the CVS version I found bugs in the non-enabled code
path.  Contact me if you'd like help getting these SDK's.

--nate