On Mon, June 23, 2008 3:11 pm, Andreas Schulz wrote:
> On Sunday 22 June 2008, Stephen Warren wrote:
>> In the documentation for get_key_name, it may be worth mentioning
>> that valid index values start at 1
>
> anything wrong with "index starting at 1 for '1
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> I really don't like the static buffer used by get_key_name. ...
>
> I went back and forth on this myself. I don't like it on principal, but
> then again, libconcord also does this.
>
> They're not equivale
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> It'd be nice if all symbols (types, values, functions, etc.) were all
>> prefixed with e.g. "IRR_"/"irr_" to ensure they never conflict with any
>> other library.
>
> ACK for the public functions
Andreas Schulz wrote:
> Here comes libIrremotes, that allows
> to put Pronto hex codes into the Logitech database.
scanf_pronto_hex, printf_pronto_hex: It seems like accepting a "FILE
*file" or "int fd" instead of "char *filename" would be more flexible,
and avoid all the special-cases for stdout.
Andreas Schulz wrote:
> Next, here comes the latest version of my IR learning patch for
> libconcord.
A few comments on the API:
+ * pulse_count : total number of pulse and space durations in pulses
+ * pulses should start with a pulse and end with a space duration,
+ * hence pulse_coun
Andreas Schulz wrote:
> Here comes the new congruity version, with its shiny new
> IR code learning interface.
I'm slowly reading through your version/patches. My plan is to initially
integrate any desired changes that aren't related to IR learning; these
could form part of any release prior to a
Phil Dibowitz wrote:
>> Yeah, I figure I'll probably sign up for a sourceforge project for the
>> next release, or something like that, and use their web-space for that.=
>
> That works as well, but even a small index.html in the directory you
> have the downloads in works.
Here it is:
https://s
On Mon, June 9, 2008 4:16 pm, Phil Dibowitz wrote:
One note Stephen - you should probably throw up a quick page about
> Congruity, what it is, and a link to the latest version. Nothing fancy,
> just something I can point people to (both in concordance docs/web, as
> well as to potential packagers).
On Mon, June 9, 2008 3:47 am, Andreas Schulz wrote:
> Sorry, please don't take congruity 8/8.1 as my final words - looks like
> I've been a little too keen to get it out..
Just a small note on this.
I'm very happy that people are contributing to congruity, and will
certainly review your changes a
On Fri, June 6, 2008 3:58 pm, Andreas Schulz wrote:
> Hi there,
> It's been a little silent around here recently - either everybody seems
> to be satisfied, not interested any more or busy adding new stuff...
>
> For me, it's been the latter - I've finally managed to settle a new API
> for access t
Just as an FYI, I'm going to be on vacation from this Monday through May
19th, probably without any email access.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. Ther
On Wed, April 23, 2008 2:56 pm, Phil Dibowitz wrote:
> On Wed, Apr 23, 2008 at 01:40:10PM -0400, Douglas E. Warner wrote:
>> I'm trying to get concordance/libconcord 0.20 packaged for Fedora
>> and am having some problems getting the perl bindings tests running;
>> I'm getting the following error (
On Tue, April 15, 2008 9:35 am, Michael Frase wrote:
> Any Suggestions? Is it possible to log the usb transfer (firmware
> upgrade) in windows (like usbmon in linux)?
Yes. Use SnoopyPro, available from:
http://sourceforge.net/project/showfiles.php?group_id=34567
Once you have the captures in the
On Tue, April 15, 2008 12:18 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> This raises the question though: What happens if the current initial 5
>> second wait isn't long enough?
>
> What do you mean? If my 5 second sleep isn't enough, I sleep for
> another
Stephen Warren wrote:
Phil Dibowitz wrote:
FYI: I get the feeling that unistd.h may not be available on Windows - so
someone may want to test that and let me know...
Well, the attached patch fixes the compile failure.
However, it seems like there are some pretty serious issues with the
Phil Dibowitz wrote:
FYI: I get the feeling that unistd.h may not be available on Windows - so
someone may want to test that and let me know...
Well, the attached patch fixes the compile failure.
However, it seems like there are some pretty serious issues with the
Windows USB code:
FindRemo
of the existing
proprietary GUI application.
The download is available from:
http://www.wwwdotorg.org/downloads/congruity/congruity-7.tar.bz2
NOTE: This release of congruity depends on libconcord release 0.20.
The changes are as follows:
* 2008-04-14 Stephen Warren <[EMAIL PROTEC
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> As you may have noticed, congruity does this already at the application
>> level. This whole process obviously takes some time, and could even fail
>> (e.g. if user unplugs the remote.) This change probably requires
>> res
Phil Dibowitz wrote:
> The things I thought of while setting it [Python bindings] up:
> - A README for libconcord/bindings/python would be good - a quick google
> search showed me how to install python modules, but I didn't know off-hand
See attached:
libconcord/bindings/python/README
Descript
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> Stephen Warren wrote:
>>>> Version 6 of congruity is released.
>>>>
>>>> congruity is a Python/wxPython-based GUI for libconcord. It is intended
>>>> to
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Version 6 of congruity is released.
>>
>> congruity is a Python/wxPython-based GUI for libconcord. It is intended
>> to handle downloads from the Harmony website, program the remote, and
>> communicate results back
of the existing
proprietary GUI application.
The download is available from:
http://www.wwwdotorg.org/downloads/congruity/congruity-6.tar.bz2
NOTE: This release of congruity depends on libconcord release 0.20.
The changes are as follows:
* 2008-04-13 Stephen Warren <[EMAIL PROTEC
On Fri, April 11, 2008 1:28 am, Phil Dibowitz wrote:
> Oh, another thing I was thinking about for the release:
>
> I was thinking of EITHER:
>
> A. Splitting the changelog and having one in libconcord/ and one in
> concord/ -- all the history would go in one (probably libconcord),
> but starting wi
Phil Dibowitz wrote:
Stephen Warren wrote:
There is one cosmetic bug, in that print CTRL-H doesn't do a backspace
on Windows, so the percentage progress messages looks like turd. I'll
see if that's easy to fix...
Eh, what? That should never happen on windows
Phil Dibowitz wrote:
> - final test on Windows of current code
>
> This hasn't been done - could someone do this for me?
I tested all these on Windows, built with Visual C++ 2005 Express
Edition, against my 880:
Debug: Compile -c -C -f -F -h -i -k -K -s -t -v
Release: Compile
There is one co
Phil Dibowitz wrote:
> Anyone else have anything they think needs to be in 0.20?
Well, since I've been using Doxygen a lot at work, I was contemplating
writing a bunch of Doxygen comments in libconcord.h, so we could
generate pretty looking doc pages etc., now that the API seems
reasonably stable
On Thu, April 10, 2008 1:25 pm, Phil Dibowitz wrote:
> Michael Frase wrote:
>> Hi Phil,
>>
>> thanks for your quick replies and changes in cvs. I'm back again and
>> tested latest cvs with my harmony 555.
>
> ...
> > Here's whats REALLY odd. I massaged the LatestUpdate.EZUp to be in the
> format we
of the existing
proprietary GUI application.
The download is available from:
http://www.wwwdotorg.org/downloads/congruity/congruity-5.tar.bz2
NOTE: congruity relies on libconcord from the latest CVS.
The changes are as follows:
* 2008-04-07 Stephen Warren <[EMAIL PROTECTED]> - congruity-5
Attached is the latest libconcord.py file, to match recent libconcord.h
changes.
Also included is a setup.py file, to go in the same directory. This is
essentially an install script; a standard thing to include when
distributing any Python module.
# This code NOT copyright Stephen Warren <[EM
On Fri, April 4, 2008 3:19 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Here's an updated version of the USB patch that works with WinHID on
>> Windows. I had to fix:
>>
>> HID_WriteReport: MS compiler won't allow creation of a variable-sized
>>
Here's an updated version of the USB patch that works with WinHID on
Windows. I had to fix:
HID_WriteReport: MS compiler won't allow creation of a variable-sized
array on the stack, so I made the code new/delete it instead.
HID_ReadReport: tmp wasn't being allocated, and assigning to data
fu
libconcord.cpp:get_time_dow should return rtime.dow, not rtime.day.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/cl
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> OK. Here's a complete version, with concordance.c integration. It works
>> for all the files in harmony_usb_logs, and a file of each type that I
>> got from the Website.
>
> I applied it, but with a few changes - see
Phil Dibowitz wrote:
> Phil Dibowitz wrote:
>> Stephen Warren wrote:
>>> Phil Dibowitz wrote:
>>>> ...
>>>> So I plan to switch this. Everywhere a USB message is constructed I'll NOT
>>>> include the extra 0-byte and then I'll
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> What about passing around a void* like I suggested with the size and all
>>> hidden inside of but an export_blob() API that dumps it to something easy -
>>> such as our uint8_t* with a siz
OK. Here's a complete version, with concordance.c integration. It works
for all the files in harmony_usb_logs, and a file of each type that I
got from the Website.
? concordance/.concordance.c.swp
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance
Phil Dibowitz wrote:
> What about passing around a void* like I suggested with the size and all
> hidden inside of but an export_blob() API that dumps it to something easy -
> such as our uint8_t* with a size, and of course an import_blob() to go with?
> Initially this will be kinda of silly becaus
Stephen Warren wrote:
> On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
>> Stephen Warren wrote:
>>> In congruity, I have some code to identify the action to take for a
>>> specific EzHex/EZUp file, without relying on any facet of the filename.
>> I'm c
Stephen Warren wrote:
> On Wed, April 2, 2008 2:22 am, Phil Dibowitz wrote:
>> This doesn't seem to actually work for me.
>
> Huh. I tested the expandtab and shiftwidth settings on libconcord.h, and
> those worked for me (at least before I moved them to the top of the fi
Phil Dibowitz wrote:
> ...
> So I plan to switch this. Everywhere a USB message is constructed I'll NOT
> include the extra 0-byte and then I'll ADD a 0-byte in the Windows code.
>
> Does anyone have any objections to this or concerns?
Sounds like a great idea to me - I was a little confused by t
On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> In congruity, I have some code to identify the action to take for a
>> specific EzHex/EZUp file, without relying on any facet of the filename.
>
> I'm curious as to what you use to figure it o
On Wed, April 2, 2008 2:22 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> Stephen Warren wrote:
>>>> Attached is a patch that adds the following line to the end of all
>
> This doesn't seem to actually work for me. The weird t
I'm writing some code to identify what to do with EZHex/EZUp files
downloaded from the Logitech website.
I just realized I've never seen a "learn IR" command file (I have
connectivity, config update, and firmware all working).
Does anyone have any "learn IR" files for various remotes they could
m
In congruity, I have some code to identify the action to take for a
specific EzHex/EZUp file, without relying on any facet of the filename.
I'm thinking about porting this to C for libconcord. I guess the API
would look like:
#define TYPE_CONNECTIVITY 0
#define TYPE_CONFIGURATION 1
#define TYPE_
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Attached is a patch that adds the following line to the end of all
>> *.cpp, *.c, *.h files.
>>
>> This might help keeping people like me with different vi defaults on-style!
>
> Though I was going to follow a diffe
Attached is a patch that adds the following line to the end of all
*.cpp, *.c, *.h files.
This might help keeping people like me with different vi defaults on-style!
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/
On Tue, April 1, 2008 1:45 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> It's so weird I don't get the same behavior...
>>> [variadic macros error from gcc]
>>
>> Yes indeed.
>>
>> I installed a Debian sid
On Tue, April 1, 2008 2:29 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Re: The license. I suppose since this file is essentially derived from
>> libconcord.h, it must be GPL 3? If so, are you OK with it being LGPL 3
>> instead of full GPL 3, to allow non-GPL applicati
Phil Dibowitz wrote:
> It's so weird I don't get the same behavior...
> [variadic macros error from gcc]
Yes indeed.
I installed a Debian sid chroot on my Fedora 8 system using the
debootstrap utility, and installed the gcc-4.3 and g++-4.3 packages
using aptitude (Debian seems crazy fast download
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> It appears there is a gcc option -Wno-variadic-macros.
>
> I'm cool with that - though I would like to confirm the current source does
> in fact build in windows before I nuke the warning
Hmm. MSDN says Visual C++ 20
Phil Dibowitz wrote:
> Update of /cvsroot/concordance/concordance/concordance
> In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv28807
>
> Modified Files:
> concordance.c
> Log Message:
> Get rid of that silly strdup() warning.
Just FYI, it looks like, on Linux at least, if you define
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> * It certainly won't remove the warning about strdup not being prototyped
>> (that's due to -ansi), which is a warning for me, but I believe an error
>> on gcc-4.3 (hence why I submitted the patch for libconcord to ad
Yes, switching from -pedantic-errors to -pedantic switches the varargs
error to a warning.
Note that the error/warning is pretty clear; varargs macros only exist
in C99 plus, so if we're claiming to have C89 source via -ansi, we can't
use them.
Build logs:
# Fedora 8, gcc 4.1.2:
gcc (GCC) 4.1.2
On Mon, March 31, 2008 11:38 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> On Sun, March 30, 2008 11:41 pm, Phil Dibowitz wrote:
>>> And again, you missed what I said about declarations not at the top.
>>> This
>>> is why we use -ansi -pedantic-errors:
On Sun, March 30, 2008 11:41 pm, Phil Dibowitz wrote:
> And again, you missed what I said about declarations not at the top. This
> is why we use -ansi -pedantic-errors:
>
> [EMAIL PROTECTED] tmp]$ gcc -std=c99 foo.c
> [EMAIL PROTECTED] tmp]$ gcc -std=c99 -pedantic-errors foo.c
> [EMAIL PROTECTED]
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Stephen Warren wrote:
>>> I propose we replace "-ansi -pedantic-errors" with "-std=c99".
>> Sorry, just remove "-ansi -pedantic-errors" and don't add "-std=c99";
>> the
into an official release.)
# This code NOT copyright Stephen Warren <[EMAIL PROTECTED]>
# This code is released into the public domain.
from ctypes import *
import platform
import sys
# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libc
Stephen Warren wrote:
> I propose we replace "-ansi -pedantic-errors" with "-std=c99".
Sorry, just remove "-ansi -pedantic-errors" and don't add "-std=c99";
the variadic macro works with -std=c99, but the strdup prototype still
isn't pre
Stephen Warren wrote:
> Phil Dibowitz wrote:
>> Stephen Warren wrote:
>>> Latest libconcord.h contains:
>>>
>>> static inline void debug(const char *str) {}
>>>
>>> This causes a build failure because inline isn't a valid keyword in
>
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Latest libconcord.h contains:
>>
>> static inline void debug(const char *str) {}
>>
>> This causes a build failure because inline isn't a valid keyword in
>> standard ANSI C. Simply removing "inline&qu
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing "inline" seems to fix the problem.
-
Check out t
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> A couple of license-related questions
>>
>> 1) The file libconcord/win/setupapi.h states:
>>
>> Copyright (c) 1995-1997 Microsoft Corporation
>>
>> This certainly isn't GPL, but it's possible M
Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
Both libconcord_winhid and concordance (and possibly other Window
projects I didn't build) attempt to link against odbc32.lib and
odbccp32.lib. I don't have either of these in Visual C++ Express 2005.
No apply:
It
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Both libconcord_winhid and concordance (and possibly other Window
>> projects I didn't build) attempt to link against odbc32.lib and
>> odbccp32.lib. I don't have either of these in Visual C++ Express 2005.
>
&g
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> I've sent the logs to you directly off-list, due to size.
>
> Thanks. A few questions - your tarball had log2 and log3 (with 3 being
> empty), but no log1 - was that on purpose? Also, is this writing a config,
> or firm
I built libconcord under Windows in preparation for testing congruity
there, and found some issues. Attached are the fixes:
1) When I changed libconcord.h, I didn't update the Windows .def file.
The attached concordance-win-def.patch does this.
2) Marco should comment on this:
Both libconcor
"concordance-gettag-ref-fix.patch" patch
that I recently sent to the mailing list. At this point, congruity has
feature preview status.
The changes are as follows:
* 2008-03-29 Stephen Warren <[EMAIL PROTECTED]> - congruity-4
- Renamed package from harmonygui to congruity, in line w
GetTag has an issue because it checks whether found is NULL before
assigning to it, but now it's a reference, so that check doesn't make
sense, and this renders the found value invalid, which breaks a lot of
things. The attached patch fixes this.
? concordance/.concordance.c.swp
? concordance/.deps
A couple of license-related questions
1) The file libconcord/win/setupapi.h states:
Copyright (c) 1995-1997 Microsoft Corporation
This certainly isn't GPL, but it's possible MS allows redistribution.
The thing is, I'd expect any Windows C compiler (or perhaps the platform
SDK) to include this h
Phil Dibowitz wrote:
> ... I ctrl-c'd a config update in the middle of erasing the config. This
> left the remote in a state in which the get_identity() calls could were
> failing...
>
> My guess is that the official software has either some way of getting the
> minimal identity data from the remo
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Is it possible to add a "--with-libconcord=/path/to/it" option to
>> concordance's configure script?
>
> I'd be happy to. I gotta remember how to do that with autoconf, shouldn't be
> hard.
>
Under Fedora 8 at least (and I'm sure others), compiling concordance.c
gives this warning:
concordance.c: In function ‘parse_options’:
concordance.c:589: warning: implicit declaration of function 'strdup'
Theoretically, strdup is prototyped by the include of .
However, since concordance is built
Is it possible to add a "--with-libconcord=/path/to/it" option to
concordance's configure script?
The reason is that I typically build, but don't install, libconcord,
then build concordance against it, using a configure command like this:
CFLAGS="-ggdb -I../libconcord" LDFLAGS=-L../libconcord/.li
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> One comment on ** vs *&. The code tends to use *& in any non-public API, and
>>> ** only for public functions since C requires that. You converted various
>>> private APIs to **, an
Phil Dibowitz wrote:
> One comment on ** vs *&. The code tends to use *& in any non-public API, and
> ** only for public functions since C requires that. You converted various
> private APIs to **, and I prefer to leave them *& to be consistent with the
> entire rest of the codebase. Only the actua
This patch adds a size parameter to any/all public APIs where it makes
sense. I believe it's complete.
See previous explanations for most changes. Additions are:
Fixed a few comments in libharmony.h "delete[]" -> delete_blob.
_write_fw_to_remote: Added size parameter, and use it.
_read_fw_from_
Stephen Warren wrote:
> I'll commit to adding a size parameter to the firmware APIs too, within
> a day (probably less) of this being in CVS to diff against.
Never mind; I have it done already. I'll follow up with the patch and
comments/explanations i
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> So, I worked on the patch for issue 1 separately, because I started it
>> first, and because it initially looked like we weren't going to address
>> issue 2. My plan was to fix (1), then quickly work up the fix to (2)
>
On Thu, March 27, 2008 11:03 pm, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
>>> Stephen Warren wrote:
>>>> That was easy - I'd just accidentally included the hunk that fixed the
>>>> C++ v.s.
On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
> As I mentioned, I'd like the for(;;)s to be while(1)s.
Here you go; attached.
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concorda
On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> That was easy - I'd just accidentally included the hunk that fixed the
>> C++ v.s. C comment at the end of libharmony.h, which you already
>> committed separately, which caused the conf
That was easy - I'd just accidentally included the hunk that fixed the
C++ v.s. C comment at the end of libharmony.h, which you already
committed separately, which caused the conflict.
So, here's the updated version, attached.
? libconcord/.libconcord.h.swp
Index: concordance/concordance.c
===
On Wed, March 26, 2008 12:35 am, Phil Dibowitz wrote:
> Phil Dibowitz wrote:
>> Phil Dibowitz wrote:
>>> That would be great, but don't bother just yet. When I get back
>>> I'll have a more detailed look at your patch and see if there's
>>> anything else and then you can just do any needed changes
Phil Dibowitz wrote:
> CodingStyle and SubmittingPatches documentation. Written on a plan, hopefully
> there's not too many typos.
s/plan/plane/ :-) :-)
-
Check out the new SourceForge.net Marketplace.
It's the best place to
Attached is a patch to include some extra headers, to ensure that all
used standard library functions are prototyped before reference. This is
required to get libconcord to compile on Fedora 9, which uses gcc-4.3.0,
which is evidently quite picky about such things.
diff -urN libconcord-20080318/bin
Phil,
I'm curious how 0.20 will be released; will it still be a single tarball
that contains everything in CVS, or do you anticipate separate release
files for e.g. libconcord and concordance, albeit presumably released at
the same time from the same snapshot/tag?
Also, some distros (Fedora at le
Stephen Warren wrote:
> I notice there's no COPYING file anywhere in CVS. I believe SW under the
> GPL is supposed to include a copy (sic) of COPYING somewhere for
> reference...
Oh, it is there, just called license.txt. I'd suggest it be renamed for
consistency with other proj
Phil,
I notice there's no COPYING file anywhere in CVS. I believe SW under the
GPL is supposed to include a copy (sic) of COPYING somewhere for
reference...
-
This SF.net email is sponsored by: Microsoft
Defy all challenges.
Phil Dibowitz wrote:
> You rule. Seriously man, you are awesome! Thanks! I can't wait to get back
> home and merge this code and get some testers behind it.
Thanks:-)
I've attached a libconcord patch that implements this. It's been tested
on both 880 firmwares that I have.
It replaces the previo
Stephen Warren wrote:
> Here's Python code. It works for both my 880 firmwares.
I've validated this algorithm against the firmware for all the following
remotes, using Kevin's USB logs:
550, 628, 659, 670, 676, 688, 748, 768, 880.
The only minor change relative to last night&#
Here's Python code. It works for both my 880 firmwares. I'll work up C
for inclusion in libharmony soon; need sleep!
bstr = '\x48\x47' + bstr[6:]
sumb = 0x43
suma = 0x21
for i in range(0, len(bstr), 2):
a = ord(bstr[i])
b = ord(bstr[i + 1])
suma ^= a
sumb ^= b
print "%02x %02x" % (
Phil Dibowitz wrote:
> On Sun, Mar 16, 2008 at 10:36:41PM -0600, Stephen Warren wrote:
>> Phil Dibowitz wrote:
>>> On Sun, Mar 16, 2008 at 03:02:40PM -0600, Stephen Warren wrote:
>>>> The attached patch adds a field to the remote info structure that tells
>>&g
Phil Dibowitz wrote:
> On Sun, Mar 16, 2008 at 02:25:42PM -0600, Stephen Warren wrote:
>> GetTag: Add size parameter; the point of the change.
>
> Reading through the diff it looks like the user passes in two pointers here
> - one that's the start of the data and one tha
Phil Dibowitz wrote:
> On Sun, Mar 16, 2008 at 03:02:40PM -0600, Stephen Warren wrote:
>> The attached patch adds a field to the remote info structure that tells
>> the code where to put the 4847 byte sequence in firmware images when
>> programming them.
>
> What&#
The attached patch adds a field to the remote info structure that tells
the code where to put the 4847 byte sequence in firmware images when
programming them.
? libconcord/.deps
? libconcord/.libconcord.cpp.swp
? libconcord/.libconcord.h.swp
? libconcord/.libs
? libconcord/.remote.cpp.swp
? libcon
Attached is a patch that adds a "size" parameter to all APIs that
manipulate variable-sized XML configuration data.
I have tested *all* operations that the concordance application exposes,
in particular, read/write config/firmware in xml/binary mode.
The diff looks a little scarier than I feel it
The protocol spec for flash write shows the array used to calculate byte
count values, not the actual index-to-byte-count mapping that the
previous part of the protocol spec used. The attached patch fixes this.
? docs.diff
Index: protocol.txt
===
Phil Dibowitz wrote:
> Folks - I'm not going to have much time this coming week to work on
> Concordance, but I will be checking email. I'll get caught up with
> merging/coding/bugs/etc. that I may be behind on, the following week.
:-) Should give me time to get merged up and finish the work on ad
The following is extracted purely from firmware files and USB logs, from
both Kevin's zip and my upgrade attempts:
remote, arch, fw version, d/l pattern, write pattern
550 9 2.2.3 8xFF 3a8d4847
628 7 3.04xFF 234d4847
659 7 4.14xFF ad8d4847
670 7 4.14xFF b4de4847
6
On Fri, March 14, 2008 11:09 am, Phil Dibowitz wrote:
> Stephen Warren wrote:
>> On Fri, March 14, 2008 2:23 am, Phil Dibowitz wrote:
>>> That said, it appears that variables declared not at the top was in
>>> fact
>>> not
>>> part of the c89 spec. But
101 - 200 of 224 matches
Mail list logo
