Matt Sergeant wrote:
That's the beauty of version control - I don't have to. Once we release
0.30, branch the trunk for 0.31, and I'll merge high_perf into trunk
while we carry on with 0.31.
Yeah, that slightly complicates matters for me (since I am branched off
of trunk for my local installs
On 7 Jul 2005, at 04:14, John Peacock wrote:
I was lying in bed thinking about things and I'd like to suggest that
we try and get 0.31 out the door in the next week or so, with all of
the recent activity, before you merge in high_perf. There were a
number of patches that came in after we froz
Matt Sergeant wrote:
On 6 Jul 2005, at 18:14, Ask Bjørn Hansen wrote:
Basically as soon as 0.30 is tagged and shipped I'm going to start
merging high_perf in.
Woah. Fun. Did you get all the infrastructure in place to make it
possible/easy-ish to write plugins that can work under either mo
On Wed, 6 Jul 2005, frank wrote:
On Wed, 6 Jul 2005, Charlie Brady wrote:
On Wed, 6 Jul 2005, Matt Sergeant wrote:
On 6 Jul 2005, at 15:40, Charlie Brady wrote:
That's an added complication, and more code - which usually means
that more things can go wrong. In what circumstances would som
On 6 Jul 2005, at 18:14, Ask Bjørn Hansen wrote:
Basically as soon as 0.30 is tagged and shipped I'm going to start
merging high_perf in.
Woah. Fun. Did you get all the infrastructure in place to make it
possible/easy-ish to write plugins that can work under either model?
Sort of. I'll be
On Jul 6, 2005, at 2:55 PM, Matt Sergeant wrote:
Is the non-sig-handlers change not going into 0.30 then?
For 0.30 I just used the rc2 tag from last week.
Basically as soon as 0.30 is tagged and shipped I'm going to start
merging high_perf in.
Woah. Fun. Did you get all the infrastruct
On 6 Jul 2005, at 17:33, Ask Bjørn Hansen wrote:
Should we plan on packaging up 0.31 in a week or two?
Is the non-sig-handlers change not going into 0.30 then?
Basically as soon as 0.30 is tagged and shipped I'm going to start
merging high_perf in.
Also I really really want you to get the
On Jul 6, 2005, at 1:49 PM, Matt Sergeant wrote:
We already did... But more importantly it's almost identical to the
code I checked in so that when we removed SIGCHLD stuff we would
still call REAPER every now and then. So the code fits in perfectly.
Frankly I'm much happier with not havin
On Wed, Jul 06, 2005 at 03:40:55PM -0400, Charlie Brady wrote:
> That's an added complication, and more code - which usually means that
> more things can go wrong. In what circumstances would someone want more
> than one interface, but not all interfaces?
Anytime you've got it paired with (and s
On 6 Jul 2005, at 16:46, John Peacock wrote:
Charlie Brady wrote:
That's an added complication, and more code - which usually means
that more things can go wrong. In what circumstances would someone
want more than one interface, but not all interfaces?
I was wondering about this myself and t
On Wed, 6 Jul 2005, Charlie Brady wrote:
On Wed, 6 Jul 2005, Matt Sergeant wrote:
On 6 Jul 2005, at 15:40, Charlie Brady wrote:
That's an added complication, and more code - which usually means that
more things can go wrong. In what circumstances would someone want more
than one interface,
Charlie Brady wrote:
That's an added complication, and more code - which usually means that
more things can go wrong. In what circumstances would someone want more
than one interface, but not all interfaces?
I was wondering about this myself and then I thought that someone might
want to run s
On Wed, 6 Jul 2005, Matt Sergeant wrote:
On 6 Jul 2005, at 15:40, Charlie Brady wrote:
That's an added complication, and more code - which usually means that
more things can go wrong. In what circumstances would someone want more
than one interface, but not all interfaces?
You want it list
On 6 Jul 2005, at 15:40, Charlie Brady wrote:
On Tue, 5 Jul 2005, Devin Carraway wrote:
Forkserver can accept a --listen-address switch to listen on a
particular
address/interface instead of 0.0.0.0, but only one. This expands the
handling
of that switch so as to listen on any number of loc
On Tue, 5 Jul 2005, Devin Carraway wrote:
Forkserver can accept a --listen-address switch to listen on a particular
address/interface instead of 0.0.0.0, but only one. This expands the handling
of that switch so as to listen on any number of local addresses, using
IO::Select to manage them. T
Matt Sergeant wrote:
Yes, it makes you have to think before deploying. I like that the
default port is 2525.
Funny, but that was exactly the reason I was going to say I liked the
status quo...
Here's my standard deployment strategy:
1) Check out the machine specific configuration from my
On 5 Jul 2005, at 06:08, Devin Carraway wrote:
And since I was one line away -- is there any remaining good reason
why the
default port for forkserver is 2525? This has the look of development
or
testing leftovers.
Yes, it makes you have to think before deploying. I like that the
default p
Forkserver can accept a --listen-address switch to listen on a particular
address/interface instead of 0.0.0.0, but only one. This expands the handling
of that switch so as to listen on any number of local addresses, using
IO::Select to manage them. The default is a single socket on 0.0.0.0, as
u
18 matches
Mail list logo
