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.
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
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
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
.
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 '
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.
.
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
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
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
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
s 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
ormat 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. Bu
code being 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
hers 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-formatt
do others 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-formatt
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, b
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 g
bb:approve
signature.asc
Description: This is a digitally signed message part
Bundle Buggy has detected this merge request.
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C1205705885.12036.4.camel%40HenrikLaptop%3E
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);
}
That
formed 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);
> BITFIEL
ing 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 untan
gt; }
>
> (This format is awful but considering the hours I spent to merge the
> HEAD in async-calls ... it is the best :-) ! )
What do others think regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on mergin
the conversion?
This is not bad idea. Maybe we can fix other problems too using this method.
With a (very) quick 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. A
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
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.
Using these options the code:
#ifdef SOME
ite easy to back/forwardport, even if a lot has
> >> changed.
> >>
> >> Many of the more difficult bugs is found by testing new things.
> >
> > +1.
> >
> > My only regret is that I did not do the astyle check yet. If you can
> > check what t
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
> >
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 con
tch HEAD
>../branchname.patch"
2. Close the current development branch by using "cvsclosebranch HEAD
2003XXYY" (2003XXYY == todays date)
3. Recreate the branch and apply the changes again.
Using cvsmerge to update branches over the astyle update is both a bit
dangerous due to the very hi
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
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.
Robert Collins wrote:
>
> On Sun, 2003-02-23 at 01:21, Henrik Nordstrom wrote:
> > There seems to be a couple very annoying bugs in the astyle styling...
>
> Urk. Ok.
>
> > 1. bitfields
> >
> > unsigned int transparent:
> > 1; /* transparent p
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 m
More issues:
It sometimes does not deal correctly with multiline comments, each time
indenting the following lines more and more.
Found this when trying to commit changes after activating the astyle
filter.. it repeatedly complained on the file even after styling..
Henrik Nordstrom wrote
On Sun, 2003-02-23 at 01:21, Henrik Nordstrom wrote:
> There seems to be a couple very annoying bugs in the astyle styling...
Urk. Ok.
> 1. bitfields
>
> unsigned int transparent:
> 1; /* transparent proxy */
>
> Issues:
> Broken into multiple lines af
There seems to be a couple very annoying bugs in the astyle styling...
1. bitfields
unsigned int transparent:
1; /* transparent proxy */
Issues:
Broken into multiple lines after the :
Always flushed fully to the left, not indented.
Should read:
unsigned int
Robert Collins wrote:
> > > Henrik, could you get cvs commits to squid3/src/ and below, for *.cc and
> > > *.h to be forced to pass astyle ?
> astyle -cs4 -O --break-blocks -l
>
> Also, we need to add .cci to the list to require formatting on - I forgot about them
Robert Collins wrote:
>
> On Sat, 2003-02-22 at 10:52, Henrik Nordstrom wrote:
>
> > Which exact version of astyle should be used?
>
> Whatever is most available for FreeBSD. I'm using 1.15.3.
Once we set up commit verification of style, all committers must use
this
Ok, this is a heads up warning:
this weekend, I'll run astyle with the draft flags
(http://www.squid-cache.org/~robertc/ has them) over the squid-3 src/,
include/ and lib/ trees.
If anyone objects, speak up before friday, and I won't do that.
Rob
--
GPG key available
40 matches
Mail list logo
