Re: [Barry-devel] perl contributions, was: GUI on gentoo

2008-07-05 Thread Chris Frey
On Fri, Jul 04, 2008 at 11:40:53PM -0500, ashley willis wrote:
 you're welcome. i escaped the binary strings (without testing *all* my 
 changes) as well as modified barrybkup to only attempt to tar 
 directories with data. i also added a -p option to the relevant programs 
 to select the device when more than one is installed, but i can't test 
 it as i only have one device. i've tested barrybkup. comparing the new 
 output to the old ouput, but i haven't tested the changes to the other 
 programs (same changes, copy and paste, *should* work).

Thanks for these changes.  I took a quick look at the package, and noticed
that now the -p option is required, otherwise you end up with an empty
-p command line option, if I'm reading the code right.  The -p option
should only be added if the user specifies it.


 one odd thing i've noticed: the record type on *all* databases is 
 usually 08 00, but sometimes they are *all* 07 00 (while in your file 
 bb_task_format.txt you list 09 00). any idea what this is about?

The rec type in bb_task_format.txt is mis-named.  That is actually
what I call the socket number, and can change at the whim of the device.
It is usually consistent, but the device tells btool what number to use,
so it could change for some reason internal to the device.

The socket number is merely part of the communications protocol, and
should not be saved in the backup.

The bb_task_format.txt file was a patch sent before tasks parsing was
supported, as I recall, and it is probably out of date.  The best place
to find the format of task records would be in the r_task.h and r_task.cc
files.  (sorry, it's code, not english) :-)

I took another look at btool's DataDumpParser, and it dumps the whole
response packet to stdout, instead of just the data portion.
This probably makes the work harder for you, when the offset
to the actual data is sitting right there in the ParseFields() arguments.

It wouldn't be hard to display the offset too, but I suspect that would
break your script.

- Chris


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


Re: [Barry-devel] perl contributions, was: GUI on gentoo

2008-07-05 Thread ashley willis
On Sat, 5 Jul 2008, Chris Frey wrote:

  Thanks for these changes.  I took a quick look at the package, and
  noticed that now the -p option is required, otherwise you end up with
  an empty -p command line option, if I'm reading the code right.  The
  -p option should only be added if the user specifies it.

actually, it should otherwise probe for the pin if the -p option is not 
given, but this only really needs to be done in barrybkup, not the other 
programs. and is the pin always an 8 digit hex number (or is that just 
my pin)? if so, i could add some error-checking. i'd also like to see 
the output of just btool when 2 and 3 devices are plugged in.

   one odd thing i've noticed: the record type on *all* databases is 
   usually 08 00, but sometimes they are *all* 07 00 (while in your 
   file bb_task_format.txt you list 09 00). any idea what this is 
   about?

  The rec type in bb_task_format.txt is mis-named.  That is actually
  what I call the socket number, and can change at the whim of the
  device. It is usually consistent, but the device tells btool what
  number to use, so it could change for some reason internal to the
  device.

  The socket number is merely part of the communications protocol, and
  should not be saved in the backup.

  The bb_task_format.txt file was a patch sent before tasks parsing was
  supported, as I recall, and it is probably out of date.  The best
  place to find the format of task records would be in the r_task.h and
  r_task.cc files.  (sorry, it's code, not english) :-)

thanks for explaining.

  I took another look at btool's DataDumpParser, and it dumps the whole
  response packet to stdout, instead of just the data portion. This
  probably makes the work harder for you, when the offset to the actual
  data is sitting right there in the ParseFields() arguments.

  It wouldn't be hard to display the offset too, but I suspect that
  would break your script.

probably. but i'm not following what you're saying. if i print the 
offset, i always get 'f', which means nothing to me however i look at 
it. i mentioned in another email that i've written a significantly 
faster version, but it's not quite ready for distribution, and requires 
modification of data.cc and data.h (to display binary instead of hex 
dumps).

-ashley
-- 
No one can make you feel inferior without your consent.
Eleanor Roosevelt

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel


Re: [Barry-devel] perl contributions, was: GUI on gentoo

2008-07-04 Thread Chris Frey
On Sat, Jun 28, 2008 at 09:15:27PM -0500, ashley willis wrote:
 if anyone has downloaded this already, download it again. i made a 
 non-destuctive patch which adds an -n option to btool to use the null 
 parser, and modified my programs to reflect this. it might not be an 
 ideal patch, as i don't really know what i'm doing, but it works afaict.

Hi Ashley,

I've applied your btool null parser patch to the latest CVS, so your
perlbarry package doesn't need a special patch anymore.

I've also added your perlbarry package under contrib/perlbarry.

I'm working through testing the scripts, and so far found just a few
small issues:

- if two devices are plugged in at once, the scripts get
  confused... this isn't too big a deal, but would be nice
  to have handled better

- some of the scripts embed binary ASCII characters in the
  sources... this confuses tools like diff, making it think
  the files are binary... could those characters be substituted
  for escaped codes?

- when running the barrybkup script, some database directories
  end up empty, and tar gives a blast of errors in those cases

Also, in testing your btool null parser patch, I found a bug in the
null parser itself, which caused the record unique IDs to be incorrect.
I fixed this as well.

Thanks very much for your scripts and for making them available to be
added to Barry.  I'm quite pleased to see the IPD file format in perl
script form.

- Chris


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel