Re: [coldsync-hackers] approaching three point zero
David A. Desrosiers
>> How would this work for the growing number of people who do not run
>> hotplug?
> Perhaps those "growing numbers" could talk to the hotplug developers
> to work out what is wrong for them.
I completely agree! I've been trying to drag it out of the
users to figure out exactly what the problem is. I know for a fact,
that 99% of the problems we hear with Palm and timing, are on SuSE
systems, flat out.
> Otherwise they will just blissfully continue on with the assumption
> that hotplug works for everyone, and all is good with the world...
*nod* Its a hard bugger to nail down, and its completely
random, and varies per-Palm device type. Sony appears to "hang" much
more than Palm and pa1mOne devices, by far.
David A. Desrosiers
des...@gnu-designs.com
http://gnu-designs.com
sp...@yandex.ru
>> 5. i think "pda" blocks in coldsync.conf file must be deprecated, we
>> can move all parameters to palms file (today in daemon mode i must add
>> both new line in palms file and new "pda" block in coldsync.conf
>> file). i need only one new parameter in palms file - "directory".
>> you agree?
AZ> not everyone uses daemon mode. why do you need a pda block in daemon
AZ> mode?
AZ> Anyway, I use this system to handle my users:
AZ> I create a real user with this directory tree:
AZ> realuser/palm01
AZ> realuser/palm02
AZ> ...
i create virtual user "palm" and create separate directory for each
palm like this:
/home/palm/user01
/home/palm/user02
i like it ;)
all other programms, related to palm syncronization works under "palm"
account.
Alessandro Zummo
sp...@yandex.ru wrote:
>
> 1. i try allow to do two or more syncs concurrently via libusb code,
> but how?
> - in device detection cycle (pconn_libusb_open() function in
> PConnection_libusb.c file) do fork after new palm is found (parent
> process wait for other palm, chlid do sync);
> - use hotplug linux subsystem similar description in README.usb
> (hotplug run one coldsync instance for every sync and pass bus number
> and device number to it)
>
> first solution is more portable, but i like second
I would do concurrency using hotplug, it's easier. Maybe we can add
it to the libusb code in the future.
> 2. serial code can freeze on disconnect if delay before palm connect
> is long (we start coldsync, wait several minutes and press hotsync
> button).
> this error appear ony with serial-connected palm (via serial cable on
> cradle).
> i don't know it's linux specific or not.
>
> empiric solution is
> comment next lines:
> if (PConn_get_palmerrno(pconn) == PALMERR_TIMEOUT)
> continue;
> in cmp_accept() function cmp.c file (we don't wait palm device)
> and restart coldsync like this:
> while (true); do
> /usr/local/bin/coldsync -md -n S0
> sleep 1
> done
>
> are you agree with this solution?
uhm... I don't like it so much... Andrew?
> 3. i don't know how add new option into coldsync.conf file (my free
> time is very limited). for example may be you add support for this:
> /* XXX This should be made configurable */
> sleep(5);
> in PConnection_serial.c file.
> i think something like "periodicity" must be added to "listen" block.
I'll give it a look.
> 4. i need auto-install some databases to new palm (for example support
> for russian fonts and graffiti). i find next lines:
> /* Install any file in the system wide "install" directory */
> /* InstallNewFiles(palm, GLOBAL_INSTALL_DIR, False, False); */
> /* Removed... it wasn't the right implementation. Maybe
> * it should be an user option...
> */
> why it is removed? what is right solution?
I must admit I can't remember ;) I'll give it a look...
> 5. i think "pda" blocks in coldsync.conf file must be deprecated, we
> can move all parameters to palms file (today in daemon mode i must add
> both new line in palms file and new "pda" block in coldsync.conf
> file). i need only one new parameter in palms file - "directory".
> you agree?
not everyone uses daemon mode. why do you need a pda block in daemon
mode?
Anyway, I use this system to handle my users:
I create a real user with this directory tree:
realuser/palm01
realuser/palm02
...
Then, in the .coldsyncrc, I put:
options {
CS_DOTPALM: "$(HOME)/$(CS_PALMUSERNAME)";
}
so each palm gets his own directory.
> some requests for coldsync:
> - protocol (full, net, simple) MUST BE autodetected (it's not very
> complex)
In the libusb code this almost works... :D
> - databases with over-64kb records must be supported
I agree. Someone can please send me such a database and
tell me which version of the Palm OS I'll need to
properly use them?
Anyway, I'd like to release 3.0 as is and then made some
more corrections in 3.1. I'll see if I can test
the libusb code with a T3...
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
Alessandro Zummo
Christophe Beauregard <christophe...@sympatico.ca> wrote:
>
> p5-Palm isn't a well-behaved CPAN module. We (Palm:: module uploaders)
> really want to be able to reference p5-Palm as a dependency (PM_PREREQ)
> and, well, that just doesn't happen with the current CPAN version. This
> breaks 'cpan install Palm::Blah' and causes the CPAN smoke testing to
> generate many erroneous test reports on perfectly good Palm:: modules.
>
> Not sure what exactly needs to be done to fix it (it _looks_ sane to me),
> but I'd really like to see something sorted out in the 3.0 timeframe.
i once uploaded a module of mine, not Palm:: related to CPAN,
but don't have too much knowledge of the PREREQ
requirements.
Do you have more insights? A failed installation report, a module
you know is correctly referenced by PREREQ_PM... ?
Christophe Beauregard
> On Thu, Oct 21, 2004 at 11:40:47PM -0400, Christophe Beauregard wrote:
> > p5-Palm isn't a well-behaved CPAN module. We (Palm:: module uploaders)
> > really want to be able to reference p5-Palm as a dependency (PM_PREREQ)
> > and, well, that just doesn't happen with the current CPAN version.
>
I can try, but most of it is speculation.
> Is it the name? Is it the fact
> that it's sorta-kinda named after a non-terminal node in the module
> tree ("Palm" rather than "Palm::Files" or some such)?
No. "Palm" should work just as well as "PDL" or "XMLTV".
It _may_ be the lack of a Palm.pm, in which case it's an easy fix. Actually,
a root Palm.pm is probably a good idea anyways. I actually doubt that this
is the case... I'm leaning towards some kind of indexing issue with CPAN
itself.
It could simply be something about the relative age of the module and some
kind of CPAN config thing... then it's just a matter of uploading the
current version and forcing CPAN to reindex.
Might also just be something silly like the Makefile missing stuff CPAN has
grown to expect like ABSTRACT and AUTHOR. Seems unlikely.
Could be the lack of Palm in the CPAN namespace list
(https://pause.perl.org/pause/authenquery?ACTION=apply_mod). Or maybe it's
supposed to be Palm::PDB... I've tried using p5-Palm, Palm, and Palm::PDB
in my PM_PREREQ without any luck. I'm actually leaning towards this since
apparently the namespace entry is semi-related to the CPAN searching
facilities.
I can certainly attack the code/config related stuff, but you're the only
one who can manipulate p5-Palm in CPAN, so... If you want to try doing an
update to force a reindex, I can version++ one of my modules and upload it
to see what happens with the smoke tests.
c.
sp...@yandex.ru
>> (formating, minor improvements, etc).
>>
>> patched areas:
>> - libusb support (i need review current cvs code)
>> - read serial number support for various devices
AZ> Ok, just keep me informed. If you want some help,
AZ> feel free to ask!
yes, i need help ;)
but my english is very bad ;(
1. i try allow to do two or more syncs concurrently via libusb code,
but how?
- in device detection cycle (pconn_libusb_open() function in
PConnection_libusb.c file) do fork after new palm is found (parent
process wait for other palm, chlid do sync);
- use hotplug linux subsystem similar description in README.usb
(hotplug run one coldsync instance for every sync and pass bus number
and device number to it)
first solution is more portable, but i like second
2. serial code can freeze on disconnect if delay before palm connect
is long (we start coldsync, wait several minutes and press hotsync
button).
this error appear ony with serial-connected palm (via serial cable on
cradle).
i don't know it's linux specific or not.
empiric solution is
comment next lines:
if (PConn_get_palmerrno(pconn) == PALMERR_TIMEOUT)
continue;
in cmp_accept() function cmp.c file (we don't wait palm device)
and restart coldsync like this:
while (true); do
/usr/local/bin/coldsync -md -n S0
sleep 1
done
are you agree with this solution?
3. i don't know how add new option into coldsync.conf file (my free
time is very limited). for example may be you add support for this:
/* XXX This should be made configurable */
sleep(5);
in PConnection_serial.c file.
i think something like "periodicity" must be added to "listen" block.
4. i need auto-install some databases to new palm (for example support
for russian fonts and graffiti). i find next lines:
/* Install any file in the system wide "install" directory */
/* InstallNewFiles(palm, GLOBAL_INSTALL_DIR, False, False); */
/* Removed... it wasn't the right implementation. Maybe
* it should be an user option...
*/
why it is removed? what is right solution?
5. i think "pda" blocks in coldsync.conf file must be deprecated, we
can move all parameters to palms file (today in daemon mode i must add
both new line in palms file and new "pda" block in coldsync.conf
file). i need only one new parameter in palms file - "directory".
you agree?
some requests for coldsync:
- protocol (full, net, simple) MUST BE autodetected (it's not very
complex)
Alessandro Zummo
Greg KH <gr...@kroah.com> wrote:
> On Sun, Oct 24, 2004 at 12:04:25PM -0400, David A. Desrosiers wrote:
> >
> > > I would do concurrency using hotplug, it's easier. Maybe we can
> > > add it to the libusb code in the future.
> >
> > How would this work for the growing number of people who do
> > not run hotplug?
>
> Perhaps those "growing numbers" could talk to the hotplug developers to
> work out what is wrong for them.
>
> Otherwise they will just blissfully continue on with the assumption that
> hotplug works for everyone, and all is good with the world...
On my side, I do not have any specific complaint against hotplug.. it works
just fine. Even concurrency could be easily done by having
multiple coldsync instances listening on consecutive tts/usb/x pairs.
Maybe an improvement would be to not claim the interface unless
the specific tts has been opened, so libusb support would
coexist nicely with hotplug.
But that's a matter of the usbserial driver and
I don't really know if the effort required is worth the benefits...
Andrew Arensburger
> p5-Palm isn't a well-behaved CPAN module. We (Palm:: module uploaders)
> really want to be able to reference p5-Palm as a dependency (PM_PREREQ)
> and, well, that just doesn't happen with the current CPAN version.
Could you please elaborate? Is it the name? Is it the fact
that it's sorta-kinda named after a non-terminal node in the module
tree ("Palm" rather than "Palm::Files" or some such)?
--
Andrew Arensburger This message *does* represent the
are...@ooblick.com views of ooblick.com
Christopher Robin Hood steals from the rich and gives to the Pooh.
Alessandro Zummo
"David A. Desrosiers" <hac...@gnu-designs.com> wrote:
>
> > I would do concurrency using hotplug, it's easier. Maybe we can
> > add it to the libusb code in the future.
>
> How would this work for the growing number of people who do
> not run hotplug?
It will work by adding concurrency to the libusb code in the future :D
I didn't thought there were so much people with such a requirement.
I'mm already working on it, but this feature will be only
added after 3.0.
The only showstoppers for the 3.0 release are the T2 and T3 compatibility
with the libusb code. If I will not be able to sort out the problem
in within the next week, I think I will propose to release 3.0 without
T2/T3 support.
Alessandro Zummo
Hi folks,
Andrew make me notice that 3.0-pre4 is quite old so
I would like to release ColdSync 3.0 in the next few days...
If any of you has critical bug reports or simple patches
to commit, please do it now.
Thank you for your attention :)
Christophe Beauregard
> Andrew make me notice that 3.0-pre4 is quite old so
> I would like to release ColdSync 3.0 in the next few days...
>
> If any of you has critical bug reports or simple patches
> to commit, please do it now.
I don't have anything outstanding, but I do want to point out a fairly major
problem (and this is more for Andrew) that should be addressed with a
coldsync/palm-perl release:
p5-Palm isn't a well-behaved CPAN module. We (Palm:: module uploaders)
really want to be able to reference p5-Palm as a dependency (PM_PREREQ)
and, well, that just doesn't happen with the current CPAN version. This
breaks 'cpan install Palm::Blah' and causes the CPAN smoke testing to
generate many erroneous test reports on perfectly good Palm:: modules.
Not sure what exactly needs to be done to fix it (it _looks_ sane to me),
but I'd really like to see something sorted out in the 3.0 timeframe.
c.
sp...@yandex.ru
AZ> I would like to release ColdSync 3.0 in the next few days...
AZ> If any of you has critical bug reports or simple patches
AZ> to commit, please do it now.
Alessandro Zummo
sp...@yandex.ru wrote:
>
> i have some patches for coldsync, but it need some edit to publish
> (formating, minor improvements, etc).
>
> patched areas:
> - libusb support (i need review current cvs code)
> - read serial number support for various devices
Ok, just keep me informed. If you want some help,
feel free to ask!
David A. Desrosiers
> I would do concurrency using hotplug, it's easier. Maybe we can
> add it to the libusb code in the future.
How would this work for the growing number of people who do
not run hotplug?
Greg KH
>
> > add it to the libusb code in the future.
>
> How would this work for the growing number of people who do
> not run hotplug?
Perhaps those "growing numbers" could talk to the hotplug developers to
work out what is wrong for them.
Otherwise they will just blissfully continue on with the assumption that
hotplug works for everyone, and all is good with the world...
thanks,
greg k-h