On 10 Dec 2009, at 06:43, D.J. Stachniak wrote:
> with him. char *foo is really the "right" way to do it
How (other than by awkward convention) is it "right"?
int *x;
*x = 1; // makes perfect sense: we declared *x an int!
Just a little bugbear of mine. Goes back to when I first
encount
As a guy who actually likes C++/STL and sees a lot of value in it, I know
already that 99% of this list disagrees with me - AND I've always been a guy
who types char* foo without even thinking and prefer it...but...truth be
told, I can't with good reason argue against John here and have to agree
wi
It should also be noted the Apache httpd, the linux kernel, the BSD
kernel, and GCC all use char *x.
Not that they are necessarily right, but that is something to think about.
What major public C/C++ project uses char* x?
On 12/9/2009 9:24 PM, John Plevyak wrote:
On 12/9/2009 8:22 PM, Leif H
On 12/9/2009 8:22 PM, Leif Hedstrom wrote:
I prefer char* too, +1 on that as the standard notation from me, going
forward at least (we can then decide either if we want to "fix" all
existing code, or just fix as we work on it).
Cheers,
-- leif
Regarding: char *x vs char* x, I am with K&R
That would be great, particularly for a big change like this (of course
it would be nice
to have it automatic and continuous).
I'll build a tracking git branch and post a URL.
john
On 12/9/2009 8:24 PM, Leif Hedstrom wrote:
On 12/09/2009 05:15 PM, John Plevyak wrote:
I would like to
On 12/09/2009 05:15 PM, John Plevyak wrote:
I would like to ask for a vote on whether or not to commit the cache
partition size patch (+1, -1, 0).
Background:
Before I vote, I guess the concern that will come up is how stable this
is? How can we verify that the new cache layout is at least
On 12/09/2009 06:07 PM, Bryan Call wrote:
I personally like camel case on the variables, but a lot of our code uses
underscore (foo_bar). So I vote for saying with underscores.
I'm ok either way, but we should specify which is the "standard" going
forward. Good catch, Manjesh.
*
On Dec 9, 2009, at 4:36 PM, Manjesh Nilange wrote:
> I have a few thoughts:
>
>
>
> * What about non-class member variables? In the code, it seems like they
> are not camel-cased, but underscore separated. Shall we continue to
> follow this? I'm asking this because class member variables will
I have a few thoughts:
* What about non-class member variables? In the code, it seems like they
are not camel-cased, but underscore separated. Shall we continue to
follow this? I'm asking this because class member variables will be
camel-cased.
* From the example, it seems like '*' is assoc
Have one single place to store and lookup remap rules irrespective of type
--
Key: TS-81
URL: https://issues.apache.org/jira/browse/TS-81
Project: Traffic Server
Issue T
[
https://issues.apache.org/jira/browse/TS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manjesh Nilange updated TS-80:
--
Attachment: regex-support-final.patch
Final version of the patch. Changes:
1) Public methods changed to con
I would like to ask for a vote on whether or not to commit the cache
partition size patch (+1, -1, 0).
Background:
In the current cache, the disk is broken up into 8GB partitions where
- objects are hashed to partitions
- an object must fit entirely in a partition effectively limiting
ob
I would like to open up a discussion about coding style...
I updated the coding style wiki because there was some confusion around method
naming and private method naming.
http://cwiki.apache.org/confluence/display/TS/Coding+Style
We are pretty strict on our indentation and we need to be more s
[
https://issues.apache.org/jira/browse/TS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-52:
--
Attachment: TS-52_traffic_cop_patch2.diff
This updated patch replaces TS-52_traffic_cop_patch1.diff and reflects ch
[
https://issues.apache.org/jira/browse/TS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manjesh Nilange updated TS-80:
--
Attachment: regex-support-coding-style.patch
Patch previously attached but with coding style applied - there
[
https://issues.apache.org/jira/browse/TS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788226#action_12788226
]
Andrew Hsu commented on TS-75:
--
>From IRC chat conversation:
andrewhsu: hmm...i notice that files
[
https://issues.apache.org/jira/browse/TS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Hsu reassigned TS-75:
Assignee: Andrew Hsu
> dependencies not always working
> ---
>
> Key
[
https://issues.apache.org/jira/browse/TS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788225#action_12788225
]
George Paul commented on TS-36:
---
The TS-36_patch1.diff patch is *NOT* needed and is covered by
T
[
https://issues.apache.org/jira/browse/TS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-6:
-
Attachment: TS-6_traffic_manager_patch2.diff
This updated patch replaces TS-6_traffic_manager_patch1.diff and reflects
Certainly.
For something like this where the bug is that the regressions don't run
to completion,
I would have 4 different checkins each referencing the same jira issue then?
I started building different jira issues for each "bug", but I ended up
just duping them
to the general "regressions
On Tue, Dec 8, 2009 at 7:16 AM, wrote:
> Author: jplevyak
> Date: Tue Dec 8 15:16:13 2009
> New Revision: 888434
>
> URL: http://svn.apache.org/viewvc?rev=888434&view=rev
> Log:
> TS-73: seg fault during regressions (traffic_server -R1) fix:
> double delete in ParentSelection.cc
> uninitialized
21 matches
Mail list logo
