on the new Ubuntu
server are combining to mean astyle 2.03 made almost none of the
changes which it should have been for the last several months.
(ouch!)
Updating the astyle version to 2.04 plus bug fixes to our scripts
resolves all these issues. It also resolves some very old
stylistic things
to make sure it does not add any problems would be good in
advance if possible though.
Sure. A full test can be run on east shortly.
east is now ready for testing astyle etc. Current status is
FreeBSD-7.3-P4 with fully up to date ports.
key items:
astyle-1.24
automake-1.11.1
autoconf-2.68
libtool
ons 2010-12-08 klockan 18:45 +1300 skrev Amos Jeffries:
pico (or the improved fork 'nano') seems to be missing on east.
nano now installed. There is also ee, vi, vim, edit and some more..
Regards
Henrik
On Wed, 08 Dec 2010 19:05:08 +0100, Henrik Nordström wrote:
ons 2010-12-08 klockan 18:45 +1300 skrev Amos Jeffries:
pico (or the improved fork 'nano') seems to be missing on east.
nano now installed. There is also ee, vi, vim, edit and some more..
Regards
Henrik
Thanks Henrik.
Amos
tis 2010-12-07 klockan 16:00 +1300 skrev Amos Jeffries:
A test to make sure it does not add any problems would be good in
advance if possible though.
Sure. A full test can be run on east shortly.
Regards
Henrik
astyle etc. Current status is
FreeBSD-7.3-P4 with fully up to date ports.
key items:
astyle-1.24
automake-1.11.1
autoconf-2.68
libtool-2.4
bzr-2.2.2 + bzrtools-2.2.0
Regards
Henrik
shortly.
east is now ready for testing astyle etc. Current status is
FreeBSD-7.3-P4 with fully up to date ports.
key items:
astyle-1.24
automake-1.11.1
autoconf-2.68
libtool-2.4
bzr-2.2.2 + bzrtools-2.2.0
Regards
Henrik
pico (or the improved fork 'nano') seems to be missing on east.
Updating
.
Sure. A full test can be run on east shortly.
east is now ready for testing astyle etc. Current status is
FreeBSD-7.3-P4 with fully up to date ports.
key items:
astyle-1.24
automake-1.11.1
autoconf-2.68
libtool-2.4
bzr-2.2.2 + bzrtools-2.2.0
Regards
Henrik
pico (or the improved fork 'nano
would be good in
advance if possible though.
Sure. A full test can be run on east shortly.
east is now ready for testing astyle etc. Current status is
FreeBSD-7.3-P4 with fully up to date ports.
key items:
astyle-1.24
automake-1.11.1
autoconf-2.68
libtool-2.4
bzr-2.2.2 + bzrtools-2.2.0
Regards
Looking into upgrading squid-cache.org, and as part of this astyle will
get updated to version 1.24 (1.23 installed today).
Is this ok, or will it screw up the source formatting job?
Regards
Henrik
On 07/12/10 12:50, Henrik Nordström wrote:
Looking into upgrading squid-cache.org, and as part of this astyle will
get updated to version 1.24 (1.23 installed today).
Is this ok, or will it screw up the source formatting job?
Version does not matter hugely beyond the minimum of 1.22. We just
shifted left by astyle and get
fully shuffled by a diff.
Of the rest all I could see was comments being shifted inside { . which
is okay.
dnsserver.cc
HttpHdrRange.cc
snmp_agent.cc
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
tokens
removing the \n placed to make the list human readable.
This is a big issue. The array entries which are properly documented
show up worst.
yep true, if you are using astyle 1.21. I test it with astyle 1.22 too
and looks OK know :-)
gopher.cc - I couldn't find it. But the diff
the prepared array of log format tokens
removing the \n placed to make the list human readable.
This is a big issue. The array entries which are properly documented
show up worst.
yep true, if you are using astyle 1.21. I test it with astyle 1.22 too
and looks OK know :-)
Okay, in that case
think regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code
regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code to untangle
On Sun, 2008-03-16 at 22:01 -0600, Alex Rousskov wrote:
Should not these formatting changes wait for the global astyle+wrapper
application, to minimize the number of times folks need to resolve
conflicts in their branches?
I think it's better to get this cleaned up soon, before there is too
Bundle Buggy has detected this merge request.
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C1205705885.12036.4.camel%40HenrikLaptop%3E
On Sun, 2008-03-16 at 22:19 +, Bundle Buggy wrote:
Bundle Buggy has detected this merge request.
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C1205705885.12036.4.camel%40HenrikLaptop%3E
bb:comment
Should not these formatting changes wait for the global astyle+wrapper
On Sat, 2008-01-05 at 13:05 +0200, Tsantilas Christos wrote:
I spend some time to run the astyle-1.21 on squid3 code. I tried to run
it with the following parameters:
--mode=c -s4 -O --break-blocks -l
I am only seeing the following two problems:
1) The --break-blocks and -l option
view looks that all bit fields are unsigned ints.
Finally, please consider reporting the above bugs to astyle if nobody
has done that already.
The bugs are reported. And many other too :-) . I frightened a little
looking in astyle bugzila:
http://sourceforge.net/tracker/?group_id=2319atid
regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code to untangle
the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code to untangle
Less processing
and after astyle is run.
If we have to go the way of hacking bitfields around astyle, I would
suggest going to a macro (yuck). Like so:
#define BITFIELD(name,bits) unsigned int name : bits
struct {
BITFIELD(name, 1);
BITFIELD(flag, 1);
}
That could work indeed
be auto-performed before and after astyle is run.
If we have to go the way of hacking bitfields around astyle, I would
suggest going to a macro (yuck). Like so:
#define BITFIELD(name,bits) unsigned int name : bits
struct {
BITFIELD(name, 1);
BITFIELD(flag, 1
regret is that I did not do the astyle check yet. If you can
check what the latest astyle does to Squid3, please do that. I think
having common automated format before the big commits would minimize
formatting conflicts.
Do you have a set of test-files to check this easily instead of a whole
On Fri, 2007-12-14 at 23:17 +0100, Henrik Nordstrom wrote:
On fre, 2007-12-14 at 14:36 -0700, Alex Rousskov wrote:
My only regret is that I did not do the astyle check yet. If you can
check what the latest astyle does to Squid3, please do that. I think
having common automated format
On fre, 2007-12-14 at 14:36 -0700, Alex Rousskov wrote:
My only regret is that I did not do the astyle check yet. If you can
check what the latest astyle does to Squid3, please do that. I think
having common automated format before the big commits would minimize
formatting conflicts.
Has
I now have a simple patch for the bitfields issue. It turned out astyle
misread bitfield definitions as labels..
The block issue is not yet identified, but is not as irritating
either.
Regards
Henrik
sön 2003-02-23 klockan 00.33 skrev Robert Collins:
On Sun, 2003-02-23 at 02:12, Henrik
Robert Collins wrote:
Should read:
struct
{
[...]
} Wais;
I don't think this is a biggy: as we get more OOP, anonymous structs
will dissappear almost completely.
Not completely I think. Using anonymous structs is quite handy for
grouping related members.
Here
On Sun, 2003-02-23 at 02:12, Henrik Nordstrom wrote:
Robert Collins wrote:
I don't think this is a biggy: as we get more OOP, anonymous structs
will dissappear almost completely.
Not completely I think. Using anonymous structs is quite handy for
grouping related members.
, in C
31 matches
Mail list logo
