On Thu, 2009-05-21 at 19:02 -0700, David Brownell wrote:
This can feed into the how to structure libraries of TCL utils
discussion ... I think substructure in the target/... stuff will
be needed, and think there's likely a better way to use TCL to
cope with these common similar but not quite
On Tue, 2009-05-19 at 23:17 -0700, Rick Altherr wrote:
On May 19, 2009, at 10:42 PM, Zach Welch wrote:
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things
consistent.
I'd
Hi all,
I want to get the style guide up-to-date. Here's my plan.
Barring any objections, I will add doc/manual/style.txt by moving the
relevant bits out of openocd.texi. The style guide is for developers
working on the code; the user guide should not need to mention the code.
though that may
On Tue, 2009-05-19 at 22:50 -0500, Dean Glazeski wrote:
Hey all,
I ran into this during my random googlings: oocd-quickreference. I
was thinking, this might be something cool to put together as part of
the next release. I'd be willing to help kick it off, just wanted to
see what people
On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote:
Duane Ellis wrote:
Dean Glazeski wrote:
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E:
statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf
/usr/lib64/openocd/ecos/at91eb40a.elf
On Wed, 2009-05-20 at 22:23 -0700, Rick Altherr wrote:
On Mar 25, 2009, at 2:54 PM, joern kaipf wrote:
* autodetection if FS or HS device attachted - adapt tck max
* enable adaptive clocking if HS device attached and jtag_khz = 0 in
cfg (not
tested yet)
Note:
The HS devices are
On Tue, 2009-05-19 at 08:04 +0200, Øyvind Harboe wrote:
- J-link stability and compatibility
- CFI driver chip/bus width issues (status??)
- PIC32 support (long-term)
Should we make the old tms sequences default for 0.2? I don't like it
from the point of view that we can't then *force*
On Tue, 2009-05-19 at 10:53 +0200, Magnus Lundin wrote:
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
Let's not remove the test, even if it only works with newer versions.
For now, I
On Tue, 2009-05-19 at 00:09 -0700, Paul Thomas wrote:
On Mon, May 18, 2009 at 10:49 PM, Zach Welch z...@superlucidity.net
wrote:
Hi all,
Since this weekend, I have spent some time working on a set of
Perl
scripts to prototype the back-end system
On Wed, 2009-05-20 at 02:22 +0800, SimonQian wrote:
Hi,
In replacement.h standard integer type is used but stdint.h isn't
included.
However, types.h includes it, and that file should always be included
before replacements.h. In what file do you see otherwise?
Cheers,
Zach
On Tue, 2009-05-19 at 15:35 -0700, David Brownell wrote:
On Monday 18 May 2009, Zach Welch wrote:
The tables track reports from users detailing the results from running
the regression test suite. A report will specify the platform,
interface, and target or board that was tested by the user
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things consistent.
I'd rather do away with all typedefs myself, except maybe
for int variants. Ditto that *_t convention.
Anyone
Hi all,
I have posted the prototype of my OpenOCD Support Database (scripts and
data files) at the following URL. [[Be nice to my server/bandwidth.]]
http://openocd.superlucidity.net/
The code can be downloaded piecemeal (in 'support_db/'). You can also
view the raw data files (in
On Mon, 2009-05-18 at 19:33 +0100, Peter Denison wrote:
On Mon, 18 May 2009, Øyvind Harboe wrote:
[Oops - failed to copy the original to the list...]
On Mon, May 18, 2009 at 8:21 AM, Peter Denison open...@marshadder.org
wrote:
On Sat, 16 May 2009, Øyvind Harboe wrote:
Could you post
On Mon, 2009-05-18 at 21:51 +0200, Øyvind Harboe wrote:
Try using
libtool gdb ../openocd
or the more pedantic (but future-proof):
libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
in
these areas constructively. Following the community's reaction, I will
convert the basic text and any feedback to add guidelines to the doxygen
developer guide.
Cheers,
Zach Welch
Corvallis, OR
[1] https://lists.berlios.de/pipermail/openocd-development/2009-May/006358.html
and compatibility
- CFI driver chip/bus width issues (status??)
- PIC32 support (long-term)
Aside from the J-Link madness, nothing seems like a blocker for 0.2.0 to
me, and even that might wait. I would like to know what others think,
but I have several
Cheers,
Zach Welch
Corvallis
.
Does this proposal sound acceptable?
Cheers,
Zach Welch
Corvallis, OR
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
the release process itself for the
short term. Nevertheless, I hope this thread can be used by someone as
the launching pad for identifying the strategic goals that we should be
thinking about for 0.3.0 (which I consider the next major release).
Cheers,
Zach Welch
Corvallis
messages
sent by the automated tester.
- Automated tester does not report PASS/FAIL and send e-mails.
I will try to post my initial implementation in the next day or two, but
I am curious what others think of this approach.
Cheers,
Zach Welch
Corvallis
On Sat, 2009-05-16 at 14:37 +0200, Øyvind Harboe wrote:
Hmmm I love true false as much as the next guy + I'd even like to
see some restrained usage of C++ instead of all the ad hoc constructs
in C that mimic object oriented features...
I think it would be wrong of me to commit this
On Sat, 2009-05-16 at 21:10 +0200, Øyvind Harboe wrote:
On Sat, May 16, 2009 at 8:42 PM, Zach Welch z...@superlucidity.net wrote:
On Sat, 2009-05-16 at 14:37 +0200, Øyvind Harboe wrote:
Hmmm I love true false as much as the next guy + I'd even like to
see some restrained usage of C
On Sat, 2009-05-16 at 16:57 +0200, Øyvind Harboe wrote:
Committed.
It took me a while to recognize the fact, but this was a case where the
current patch policy fails us badly.
r1798 broken the history for all of the files that were moved, because
they were removed ('svn rm') and then new copies
On Fri, 2009-05-15 at 08:26 +0200, Øyvind Harboe wrote:
My interest lies in a couple of things. I don't know what
role this translates into though:
- recruit first rate maintainers. Actually I'm kinda done with this as
it seems we have a positive feedback loop now.
This is Recruiter, and
On Sat, 2009-05-16 at 00:20 +0200, Benjamin Schmidt wrote:
Hello,
I'm trying to build on GCC 4.4.0 on Linux.
building stops with following error:
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -
I../../src/server -I../../src/target
On Thu, 2009-05-14 at 12:36 +0200, Øyvind Harboe wrote:
I've been thinking a bit about a selftest script:
- write a script that can run basic tests on all targets
- this script will need some parameters: working memory,
where to store temporary files, etc.
- each target will have
On Thu, 2009-05-14 at 14:46 -0700, Paul Thomas wrote:
[snip]
Thanks Zach, here's the cfg file.
In the future, even new files should be submitted as a patch, as I was
not immediately _certain_ where you wanted me to put this. A patch made
from the root of the tree would eliminate all doubt.
Hi all,
I want everyone to know The List has hit the repository in r1791.
It has evolved beyond my ability to manage it without some help.
There has been so much activity lately that I know some things may have
slipped through the cracks. At this point, the amount of time it will
take me to
On Thu, 2009-05-14 at 17:52 -0700, David Brownell wrote:
On Thursday 14 May 2009, Zach Welch wrote:
If you are still willing continue in this role, I would like to see you
document the release processes (perhaps in doc/manual/releases.txt?) and
inform the rest of us what we need to do
On Thu, 2009-05-14 at 18:10 -0700, David Brownell wrote:
On Thursday 14 May 2009, Zach Welch wrote:
I think that these links catapult The List
beyond a mere TODO or task list. It has started to provide references
to explain how the items got there in the first place, and I would like
On Thu, 2009-05-14 at 17:41 -0700, David Brownell wrote:
Alternatively, maybe the folk who now have responsibilities
http://developer.berlios.de/project/memberlist.php?group_id=4148
could start by saying how they see their roles, and what they
see the process as being ... and what it
On Thu, 2009-05-14 at 19:57 -0700, David Brownell wrote:
On Thursday 14 May 2009, Zach Welch wrote:
Re Why, IMO it might suffice to say that after four or five
months, lots of bugs have been fixed and features added, so
it's just time to clean up the rough spots and declare victory
On Thu, 2009-05-14 at 20:20 -0700, David Brownell wrote:
On Thursday 14 May 2009, Zach Welch wrote:
One point to make here is the conflicting desires of a release manager
and developers. At their extremes, the former would have us making
stable releases every night, while the later would
Hi all,
If anyone knows of patches that have not been applied, please reply here
with a link into the mailing list archives to the last version posted:
https://lists.berlios.de/pipermail/openocd-development/
If there are other issues to which the maintainers failed to respond,
please
On Wed, 2009-05-13 at 08:53 +0100, John Devereux wrote:
Zach Welch z...@superlucidity.net writes:
On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote:
[snip]
[...]
comfortable situation, because I know how to compile the package, but -
believe me - there are hundreds of domestic ARM
Hi all,
In r1771, I committed an initial skeleton of files that begin to
transform Doxygen's output into a genuine OpenOCD Developer Manual.
I know that I probably missed some important structural bones, but I am
still learning OpenOCD's anatomy. When it is done, that learning curve
should be
Hi all,
The following documentation files seem like they should be moved into
the doc/ directory:
src/scripting.txt
src/server/httpd/readme.txt
src/non-arm-targets.txt
src/tcl/README_ABOUT_TCL.txt
src/target/target/readme.txt
Given the new doxygen manual skeleton from r1771, I am
On Wed, 2009-05-13 at 03:17 -0700, Zach Welch wrote:
On Wed, 2009-05-13 at 12:00 +0200, Francois Lorrain wrote:
[snip]
2) It looks like the stdint.h need to be included in system.h, not
types.h, otherwise binarybuffer.c does not compile
I have a better fix in mind; please do not apply
On Wed, 2009-05-13 at 17:01 -0400, Nicolas Pitre wrote:
On Wed, 13 May 2009, David Brownell wrote:
When I tried -d 3 it suddenly worked, and has worked
again since. Note -- this is with *NO* rebuild, and
using an executable which previously failed.
This is scary. Anyone with valgrind
On Wed, 2009-05-13 at 23:06 +0200, Michael Fischer wrote:
Hello list,
please can some one test if it is possible
to build the 1770 on Mac OS X?
Here I need libtoolize, but this was not found,
even if I install libtool over mac port.
I only found glibtoolize, therefore I set a symbolic
On Thu, 2009-05-14 at 00:41 +0200, Edgar Grimberg wrote:
Hi,
Right. I forgot about this madness. *sigh* An updated bootstrap
script has been committed as r1779.
The attached patch does the trick for bootstrap. :)
D'oh. Fixed in r1780. Thanks. :)
But at the end, I got a ld
On Thu, 2009-05-14 at 01:00 +0200, Edgar Grimberg wrote:
Right. I forgot about this madness. *sigh* An updated bootstrap
script has been committed as r1779.
The attached patch does the trick for bootstrap. :)
Now that we are at MacOS issues, when I do:
mac-mini:build edgar$
On Wed, 2009-05-13 at 16:42 -0700, Rick Altherr wrote:
On May 13, 2009, at 3:41 PM, Edgar Grimberg wrote:
But at the end, I got a ld error like:
ld: duplicated symbol _Jim_SetResult_sprintf
Mac OS X 10.5.7 and GCC 4.0.1
I had no problems with the old build where libtoolize
is
On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote:
Sorry to interrupt (; I thought that I'd share my outsider's opinion
with all.
Not at all. I hope more folks are willing to step up and share their
opinions; without feedback, the maintainers cannot know what you think.
Thank you for
On Tue, 2009-05-12 at 15:49 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Zach Welch wrote:
On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote:
[snip]
There seems to be no strong reason that OpenOCD should
always need to be told here's the only scan chain you
should
On Tue, 2009-05-12 at 15:36 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't know ... then who could?
I do. Cats can be
On Tue, 2009-05-12 at 17:21 -0700, Rick Altherr wrote:
[snip]
I had mentioned this a while back. I've been thinking through the
approach and I'm slowly settling on a C++ implementation that would
essentially be a rewrite. That said, I believe an autoconfig
mechanism could be done on
On Tue, 2009-05-12 at 08:02 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Zach Welch wrote:
+ Which do we want: jtag.h or jtag/jtag.h? **
openocd/jtag.h since there are other jtag projects
working to provide a library interface (e.g. urjtag).
I grok and agree. That said, I think
On Tue, 2009-05-12 at 17:59 -0400, Gene Smith wrote:
Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a
yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a
bit of mention on this list about jlink and thought I would give it a
try. I was at r1567 on
Hi all,
As a consequence of my recent clean-up work, I turned on some of the
basic GraphViz features in doxygen. This feature can be turned off by
change the HAVE_DOT Doxyfile setting from YES to NO.
Its file dependency graphs are now much more insightful than before I
started my clean-up, so I
On Mon, 2009-05-11 at 10:08 +0200, Nico Coesel wrote:
Zach,
I'm a little concerned here. I've seen many doxygen generated API
'reference' manuals. Most of them are useless because they don't
describe why a certain function is there and what its relation is to
other functions. Doxygen is a
Exactly. This is what that type was designed to do.
On Mon, 2009-05-11 at 18:16 +0100, Nick Brereton wrote:
How about C99's intptr_t ?
-Original Message-
From: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of David
On Mon, 2009-05-11 at 10:22 -0700, Rick Altherr wrote:
On May 11, 2009, at 7:15 AM, Spencer Oliver wrote:
This one-time step comes from the addition of the
AC_PROG_LIBTOOL macro.
It will be performed automatically in the bootstrap script
for newly checked out working copies. Sorry for
On Sun, 2009-05-10 at 15:20 +0200, Dirk Behme wrote:
[snip]
As already mentioned, looking into the code: ocd_mem2array is
registered in tclapi_register_commands() in tclapi.c. But: It seems to
me that tclapi_register_commands() isn't called anywhere, and even
worse, tclapi.c isn't
On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote:
So some progress, but nothing more ;)
(all: Above error is from TCL script containing ocd_mem2array
romtable_cid 32 [expr ($debugbase0xF000) + 0xFF0] 4)
Do you have any special patches or do I need any special configure
Hi all,
The offer by Martin Thomas to contribute testing feedback inspired me.
I think that it would be an incredible asset for the OpenOCD maintainers
to be able to see a current support matrix, since no one individual can
reasonably be expected to test all platforms, interfaces, and targets.
Hi all,
I wanted to let everyone know that I have committed the changes required
to build libopenocd.{a,so} using libtool (part of the GNU autotools).
Obviously, this will require that all developers have the libtool
package installed, though it will probably already be present for most.
In
Hi all,
I have finished committing my outstanding patches that eliminate the
redundancies in OpenOCD header file #include directives, which resulted
in the elimination of about 1000 lines of code and helped decouple
various parts of the system. Work remains to be done on this later.
Let me know
On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote:
[snip]
I have to give a bit of thought on how to best to profile this, i.e. to
find the precise location of the culprit.
Any ideas?
I have had success with oprofile. This would give you what you need.
--Z
On Fri, 2009-05-08 at 09:43 +0200, Øyvind Harboe wrote:
On Fri, May 8, 2009 at 9:40 AM, Zach Welch z...@superlucidity.net wrote:
On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote:
[snip]
I have to give a bit of thought on how to best to profile this, i.e. to
find the precise location
Hi all,
I did not think I needed to get involved in this thread, but I feel that
my contribution at this point might be to help resolve the situation.
I ask that the community actually give Øyvind a chance to finish his
work with in_handler. His opponents are shouting on the list without
this
document and regurgitate anything useful that I find to the list, but I
just want to point out that the lack of up-to-date backing documentation
raises questions about the objectivity of anyone's current opinions.
I believe internals should be fair game for being rewritten at any time.
Zach Welch
On Fri, 2009-05-08 at 10:34 -0400, Chris Zimman wrote:
Which was last updated when? I will make it a priority to grok this
document and regurgitate anything useful that I find to the list, but I
just want to point out that the lack of up-to-date backing
documentation raises questions
On Fri, 2009-05-08 at 11:10 -0400, Chris Zimman wrote:
No arguments here. You cut out the part of my reply where I agreed
with you on this exact point. The execution was far from ideal.
If you already said it, my not reposting it does not in any way invalidate
it.
It's called quoting
On Fri, 2009-05-08 at 20:08 +0200, Igor Skochinsky wrote:
Hi All,
On Fri, May 8, 2009 at 19:19, Zach Welch z...@superlucidity.net wrote:
[...]
I apologize for hitting Reply instead of Reply-all (and the for my
mailing system for delaying the second message just minutes later).
Clearly
On Fri, 2009-05-08 at 17:05 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Fri, 2009-05-08 at 13:49 +0200, Magnus Lundin wrote:
[snip]
Zach Welch wrote:
[snip]
* Are you _certain_ the current bugs being experienced cannot be the
result of other bugs that were uncovered
On Thu, 2009-05-07 at 08:59 +0200, Øyvind Harboe wrote:
I've deleted an old flash driver (at91sam7_old). Your build will fail
unless you run bootstrap.
... unless you are using --enable-maintainer-mode. If you are, make
should detect the changed Makefile.am and will rebuild the associated
On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620.
But this is not solving the problem in the last version
r1649 if I remove AC_PROG_CC_C99 here too.
Can
On Thu, 2009-05-07 at 15:18 -0700, Rick Altherr wrote:
On May 7, 2009, at 1:30 PM, Zach Welch wrote:
On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620
Hi all,
The file, src/helper/tclapi.c, is not used in-tree. Can we remove it?
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Wed, 2009-05-06 at 08:17 +0200, Øyvind Harboe wrote:
Looks like more fun with the code below in jim.c...
#if !defined(HAVE_UNISTD_H) || !defined(__GNU_LIBRARY__)
extern char **environ;
#endif
../../../openocd/src/helper/jim.c: In function `Jim_EnvCoreCommand':
On Tue, 2009-05-05 at 23:27 -0700, Zach Welch wrote:
On Wed, 2009-05-06 at 08:17 +0200, Øyvind Harboe wrote:
Looks like more fun with the code below in jim.c...
#if !defined(HAVE_UNISTD_H) || !defined(__GNU_LIBRARY__)
extern char **environ;
#endif
../../../openocd/src
On Wed, 2009-05-06 at 15:50 +0200, Uwe Hermann wrote:
Hi,
On Mon, May 04, 2009 at 11:56:00AM -0700, Zach Welch wrote:
The attached patch should fix the cast alignment warnings caused by
jim.c on platforms with stricter alignment rules.
If you get more problems, please run the builds
On Wed, 2009-05-06 at 16:24 -0700, Zach Welch wrote:
On Wed, 2009-05-06 at 15:50 +0200, Uwe Hermann wrote:
Hi,
On Mon, May 04, 2009 at 11:56:00AM -0700, Zach Welch wrote:
The attached patch should fix the cast alignment warnings caused by
jim.c on platforms with stricter alignment
On Mon, 2009-05-04 at 12:21 +0200, Uwe Hermann wrote:
Hi,
I uploaded a new Debian package of OpenOCD recently (based on r1583)
which produced a number of build warnings (now errors because of
-Werror). Haven't had the time to look into the issues, but the build
logs could be useful for
On Sun, 2009-05-03 at 11:39 -0500, Dick Hollenbeck wrote:
I have never seen a project that needs to be forked as badly as this
one. You sit around and nit pick about about which dinner glasses to
pour the water into. Somebody shows up with a firetruck wanting to fill
the swimming pool
On Sat, 2009-05-02 at 01:01 -0500, Dick Hollenbeck wrote:
Dick,
Once again, it's not you, it's me. Blah, blah, blah :)
English please. No idea what the above sentence is saying.
It meant do not take this personally, it's my opinion. The blah blah
blah was because I figured
On Sat, 2009-05-02 at 07:04 +0200, Michael Bruck wrote:
I would like to start another holy war while we are at it:
1. Are false preprocessor variables in OpenOCD specified by not
defining a variable or by defining it as 0 ?
OpenOCD's variables are defined as 0 or 1. This is not standard.
On Fri, 2009-05-01 at 20:25 -0500, Dick Hollenbeck wrote:
Fixes some problems. Has worked on OS2, Linux, Windows, Cygwin now.
It generates both openocd executable and also now a libopen-ocd.so file
for folks wanting to make a shared object / DLL. That would be me. I
think I want to call
On Sat, 2009-05-02 at 10:45 +0200, Øyvind Harboe wrote:
What does this patch do?
Looks like it fixes the link for the DLL build by moving those symbols
into a file that does not contain main(). It may be better to add a
httpd_stub.c file though, given my understanding of how thinks link up.
On Fri, 2009-05-01 at 23:30 -0400, Gene Smith wrote:
If you build openocd with --enable-rlink (or probably with other options
that use USB) and at least usb.h is not present in the system headers,
you get a build failure.
./configure --enable-rlink does not check for presence of usb.h which
On Sun, 2009-05-03 at 00:40 +0200, Michael Schwingen wrote:
Zach Welch wrote:
If the header is required, the configure step should fail when it is not
found in the system. The rule is to fail as early as possible.
Which headers?
Not system headers - I was thinking about in-project
Hi all,
The attached patch gives a minor upgrade to OpenOCD's autotools support.
Its commit message should provide ample detail for understanding all of
the changes that were made, though the patch itself is easy to read.
I would have simply committed these changes, but I recognize that they
as an open source project.
Cheers,
Zach Welch
Corvallis, OR
==
The List
==
OpenOCD's Pending and Open Tasks
On Fri, 2009-05-01 at 01:42 -0700, Zach Welch wrote:
You beat me to posting a summary thread.
On Fri, 2009-05-01 at 09:17 +0200, Øyvind Harboe wrote:
We don't have a way to measure consensus but I belive the current
consensus can be summarized as:
- OpenOCD stays C for now. There has
Dick,
Once again, it's not you, it's me. Blah, blah, blah :)
On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote:
This patch is large and:
... should have been split into pieces.
** allows the ft2232 cable to be detached and reattached without having
to restart openocd.
Patch
On Wed, 2009-04-29 at 13:24 -0500, Dick Hollenbeck wrote:
[snip]
The C99 stuff is purely arbitrary IMO, there is almost always another
way to code those things. And rather than ifdef-ing them out, I would
simply find that other way and offer those changes as patches, removing
the C99
On Wed, 2009-04-29 at 17:25 -0500, Dick Hollenbeck wrote:
[snip]
This group has talked about using trying to use C++ features; why not
simply start by adopting C99 features?
Yes, minus the designated initializers if not C++ compatible.
I would not consider using the
former language
On Thu, 2009-04-30 at 01:23 +0200, Michael Bruck wrote:
jim.c fails on cygwin with the new settings.
Please consider the attached patch as it seems to better reflect the
core of the problem, i.e. that environ is declared in unistd.h.
Committed as r1572.
--Z
On Wed, 2009-04-29 at 20:02 -0500, Dick Hollenbeck wrote:
Michael Bruck wrote:
This problem was introduced by r1559 in replacements.h
in ft2232.c windows.h (or more precise winsock2.h) must be included
after sys/select.h
Michael
I put this change into my pending patch, so it
On Thu, 2009-04-30 at 05:17 +0200, Michael Bruck wrote:
On Thu, Apr 30, 2009 at 1:16 AM, Zach Welch z...@superlucidity.net wrote:
On Wed, 2009-04-29 at 17:25 -0500, Dick Hollenbeck wrote:
What? It is only several days to get this project to compile with C++,
maybe several weeks
On Tue, 2009-04-28 at 09:03 +0200, Michael Bruck wrote:
On Tue, Apr 28, 2009 at 8:23 AM, Øyvind Harboe oyvind.har...@zylin.com
wrote:
Do we really want to go down the path of macros?
Yes. The ifs obscure the actual algorithm by turning a short one-line
function call into five lines of
On Tue, 2009-04-28 at 15:21 +0200, Øyvind Harboe wrote:
Please welcome Zach Welch as an OpenOCD maintainer.
He has in short time proved himself a valuable member of the OpenOCD
community. This is both in terms of quantity and quality of patches.
...
Thanks Øyvind!
I will do my best to help
On Tue, 2009-04-28 at 18:25 -0700, Zach Welch wrote:
Hi all,
I just made my first commit to the repository and discovered that the
openocd-svn mailing list requires some adjusting to allow my posts.
Since that commit message may not be delivered soon (or at all), the
attached patch shows
On Sun, 2009-04-26 at 00:19 +, Martin Panter wrote:
[snip]
From your patch:
+/// @brief calculates number of bytes required to hold @a n TAP scan bits
+#define TAP_SCAN_BYTES(n)(((n) / 8) + !!((n) % 8))
Are you aware that in src/helper/binarybuffer.h there's a similar
macro?
On Sun, 2009-04-26 at 11:43 -0700, Zach Welch wrote:
On Sun, 2009-04-26 at 16:16 +0200, Dirk Behme wrote:
[snip]
3. Running resulting openocd binary for OMAP3 tests immediately stops
with
Runtime error, file src/target/board/ti_beagleboard.cfg, line 10:
Line 10 in this file
Hi all,
The attached patch wraps two definitions of _GNU_SOURCE in the code,
which could cause problems with -D_GNU_SOURCE -Wredundant-decls.
Cheers,
Zach
Index: src/helper/jim.c
===
--- src/helper/jim.c (revision 1531)
+++
Hi all,
This patch adds two additional warnings with --enable-extra-warnings:
-Wcast-align (to prevent mis-aligned memory accesses through bad casts)
and -Wbad-function-cast (to prevent casts to 'anything *'). I believe
these will assist developers with portability when writing new code.
Please
On Mon, 2009-04-27 at 02:33 +0200, Magnus Lundin wrote:
We should be a bit more careful. I am all in favour of cleaning up the
bit rot !!! But how to fix the warnings needs to be not carefully
considered.
My example:
cortex_me.c : cortex_m3_register_command. It is declared both at the
Hi all,
The following message posted to the gpgme-cvs mailing lists documents
their solution to the build error @include `version.texi': No such file
or directory that was recently reported to this list:
http://lists.gnupg.org/pipermail/gpa-dev/2002-May/000626.html
Following the thread back
701 - 800 of 873 matches
Mail list logo
