On Mon, 2011-12-19 at 12:50:42 -0700, Warner Losh wrote:
>
> On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote:
>
> >> Using profiled libs and gprof to profile your code has been obsolete
> >> in FreeBSD on i386 and amd64 for over six years now.
> >
> > Funny, it still seems to work on my syste
> > Now all users that want to profile anything need to build their own custom
> > FreeBSD? That seems even more nuts to me.
>
> So that all users that do not want to profile anything need to build
> their own "custom" FreeBSD?
No. It simply means these users will have profiled libraries availa
On Mon, Dec 19, 2011 at 8:46 PM, Warner Losh wrote:
>
> On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote:
>
>> On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
>>>
>>> The most important thing is to have reasonable defaults.
>>> Having WITH_PROFILE by default does not seem to be a reasonable
On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote:
> On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
>>
>> The most important thing is to have reasonable defaults.
>> Having WITH_PROFILE by default does not seem to be a reasonable default to
>> me.
>>
Now all users that want to profile
On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote:
>> Using profiled libs and gprof to profile your code has been obsolete
>> in FreeBSD on i386 and amd64 for over six years now.
>
> Funny, it still seems to work on my systems.
Worked for me last time I tried as well. Was able to find the pro
On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
> David,
>
> On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien wrote:
> > On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
> >> You still failed to name a single compelling reason to leave profiled
> >> libs even in -CURRENT.
> >
> >
On Fri, Dec 2, 2011 at 12:11 PM, Lucas Holt wrote:
> What if it was still included in tinderbox builds and releases. For the
> latter, the profiled versions could be in a separate distribution set much
> like doc or games. The ugly part is freebsd-update..
>
> It could still be off by default i
On 12/02/11 19:39, Lyndon Nerenberg wrote:
Isn't this about user choice, and making sensible defaults?
There are two or three "users" out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you better build hardware, too.
Well
What if it was still included in tinderbox builds and releases. For the latter,
the profiled versions could be in a separate distribution set much like doc or
games. The ugly part is freebsd-update..
It could still be off by default in the buildworld as anyone smart enough to do
source upgrad
On Fri, Dec 2, 2011 at 10:39 AM, Lyndon Nerenberg wrote:
>> Isn't this about user choice, and making sensible defaults?
>
>
> There are two or three "users" out of thousands complaining about the
> default. If the extra build time bugs you that much, I'll contribute
> towards buying you better bu
On Fri, Dec 02, 2011 at 01:12:42PM -0500, Ryan Stone wrote:
> On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg wrote:
> > No, these days 'obsolete' seems to mean 'it does not have a sexy
> > Flash-driven web GUI.'
>
> In this case, 'obsolete' means it's a difficult-to-use tool that
> requires re
Isn't this about user choice, and making sensible defaults?
There are two or three "users" out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you better build hardware, too.
__
On 2 Dec 2011 17:07, "Lyndon Nerenberg" wrote:
>>
>> Obsolete does not mean it doesn't work.
>
>
> No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
Straw man argument. This is irrelevant.
> Profiling is a simple basic tool that makes it easy to quickly fin
In this case, 'obsolete' means it's a difficult-to-use tool that
requires recompiling your application, can't be used in production,
doesn't work when shared libraries are in the picture, offers
limited-to-no visibility into the underlying reasons why a particular
code path is a hotspot and introd
On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg wrote:
> No, these days 'obsolete' seems to mean 'it does not have a sexy
> Flash-driven web GUI.'
In this case, 'obsolete' means it's a difficult-to-use tool that
requires recompiling your application, can't be used in production,
doesn't work wh
Obsolete does not mean it doesn't work.
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
Profiling is a simple basic tool that makes it easy to quickly find code
execution hot-spots. It's not dtrace, or any other plethora of tools that
do a more exten
On 2 Dec 2011 16:54, "Lyndon Nerenberg" wrote:
>>
>> Using profiled libs and gprof to profile your code has been obsolete
>> in FreeBSD on i386 and amd64 for over six years now.
>
>
> Funny, it still seems to work on my systems.
>
>
I wonder if you're either not reading these emails properly or d
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
Something else I forgot to mention ...
The point of -CURRENT is to make sure everything works before it becomes
-STABLE and -RELEASE. Not building significant components of the system
ensures those components don't get tested. This includes the actual build
process, as well as the underlying
On Fri, Dec 2, 2011 at 10:56 AM, Lyndon Nerenberg wrote:
> If you choose not to profile your code, that's entirely your choice.
> Breaking this functionality for everyone else who *does* make the effort to
> profile their code is a non-starter.
Using profiled libs and gprof to profile your code h
Nothing is being broken here, just a default being changed.
Users make up a greater proportion of our userbase than developers, so
sensible defaults for them are more appropriate, right?
This has no impact on non-developer end-users.
For "developer" end-users, this has a huge impact. You are
On Fri, Dec 02, 2011 at 04:23:40PM +, Chris Rees wrote:
> On 2 Dec 2011 15:57, "Lyndon Nerenberg" wrote:
>>
>>
>> If you choose not to profile your code, that's entirely your choice.
>> Breaking this functionality for everyone else who *does* make the effort to
>> profile their code is a non-s
On 2 Dec 2011 15:57, "Lyndon Nerenberg" wrote:
>
> Max, I think a reasonable default is to continue building and shipping
profiled libraries. This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.
>
> If you personally find profiled library builds sl
Max, I think a reasonable default is to continue building and shipping
profiled libraries. This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.
If you personally find profiled library builds slow you down too much, a
one line addition to your /
David,
On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien wrote:
> On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
>> You still failed to name a single compelling reason to leave profiled
>> libs even in -CURRENT.
>
> Sorry Joe, I don't think your reasoning is compelling.
> I'm sure you know
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
> You still failed to name a single compelling reason to leave profiled
> libs even in -CURRENT.
Sorry Joe, I don't think your reasoning is compelling.
I'm sure you know how to stick "NO_PROFILE=true" in your /etc/src.conf.
How far do you
Quick! Martinis for all conversation participants, stat!
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 12/01/2011 23:23, Steve Kargl wrote:
> On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote:
>> On 12/01/2011 22:41, Steve Kargl wrote:
>>
>>> Having a set of profiled libraries in-sync with the static
>>> and shared libraries allows one to run the profiler on their
>>> code when someone
On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote:
> On 12/01/2011 22:41, Steve Kargl wrote:
>
> > Having a set of profiled libraries in-sync with the static
> > and shared libraries allows one to run the profiler on their
> > code when someone changes a library and that change causes
>
On 12/01/2011 22:41, Steve Kargl wrote:
> Having a set of profiled libraries in-sync with the static
> and shared libraries allows one to run the profiler on their
> code when someone changes a library and that change causes
> a dramatic change in the performance of one's code.
And as Max pointed
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
> David,
>
> On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote:
>
> On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> > > I would like to disable building profiled libraries by default. Opinions?
> >
> > On Tue, Nov 29, 2011 a
Steve,
On Fri, Dec 2, 2011 at 1:33 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote:
> > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> > > I would like to disable building profiled libraries by default.
> Opini
On Fri, Dec 02, 2011 at 12:41:00PM +0800, Adrian Chadd wrote:
> On 2 December 2011 09:51, David O'Brien wrote:
>
> > Wow, a single day of discussion in freebsd-current@ was sufficient to
> > invert a 17 year default.
> >
> > I'd like to see the profile libs remain built by default in -CURRENT.
>
On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote:
> On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> > I would like to disable building profiled libraries by default. Opinions?
>
> On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
> > Author: fjoe
> > Date: Tue Nov
David,
On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote:
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> > I would like to disable building profiled libraries by default. Opinions?
>
> On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
> > Author: fjoe
> > Date: Tue Nov 29
On 2 December 2011 09:51, David O'Brien wrote:
> Wow, a single day of discussion in freebsd-current@ was sufficient to
> invert a 17 year default.
>
> I'd like to see the profile libs remain built by default in -CURRENT.
>
> If you like, add it to the list of things to disable on -STABLE creation
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
> Author: fjoe
> Date: Tue Nov 29 19:46:17 2011
> New Revision: 228143
> URL: http://svn.freebsd.org/chang
On 1 December 2011 10:44, Max Khon wrote:
> Are you sure you mean profile support and not CTF data?
Hi Max,
I mean profile support.
Havent tested on 9.0, but definitely the case with prior versions.
Will try & repeat the process & report back if this is not a common
occurrence which has been rep
Sevan,
On Thu, Dec 1, 2011 at 6:56 AM, Sevan / Venture37 wrote:
On 30/11/2011 16:03, Sevan / Venture37 wrote:
>
>> system breaks if you try to add dtrace support to a system built with
>> profile support.
>>
>
> sorry, I meant *without* profile support.
Are you sure you mean profile support and
On 30/11/2011 16:03, Sevan / Venture37 wrote:
system breaks if you try to add dtrace support to a system built with
profile support.
sorry, I meant *without* profile support.
Sevan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.
On 30/11/2011 01:16, Doug Barton wrote:
What does dtrace have to do with profiled libs?
system breaks if you try to add dtrace support to a system built with
profile support. on the other hand it could be argued that the system
currently needs to be rebuilt anyway.
Sevan
__
What does dtrace have to do with profiled libs?
On 11/29/2011 17:14, Paul Ambrose wrote:
> I think dtrace for freebsd userland is close to complete( after
> r227290, at least no more kernel panic). but is not suitable for a
> daily use now.
>
> 在 2011年11月30日 上午5:42，Sevan / Venture37 写道：
>> I
I think dtrace for freebsd userland is close to complete( after
r227290, at least no more kernel panic). but is not suitable for a
daily use now.
在 2011年11月30日 上午5:42，Sevan / Venture37 写道：
> I assume every who responded so far doesn't use dtrace?
>
>
> Sevan
> __
I assume every who responded so far doesn't use dtrace?
Sevan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> I would like to disable building profiled libraries by default.
> Opinions?
Agreed. There are better profiling tools available now that do not
require recompiling the program with special options and statically
linking it. Examples are pm
Doug,
On Tue, Nov 29, 2011 at 7:35 AM, Doug Barton wrote:
>>> Are there any compelling reasons for having profiled libs to be built by
> >>> default?
> >>
> >> Nope. It's been one of the first things I disable after I install a new
> >> system for at least a decade.
> >>
> >> Ideally we could do
On 11/28/2011 16:33, Poul-Henning Kamp wrote:
> In message <4ed4222e.5010...@freebsd.org>, Doug Barton writes:
>> On 11/28/2011 02:38, Max Khon wrote:
>
>>> Are there any compelling reasons for having profiled libs to be built by
>>> default?
>>
>> Nope. It's been one of the first things I disable
In message <4ed4222e.5010...@freebsd.org>, Doug Barton writes:
>On 11/28/2011 02:38, Max Khon wrote:
>> Are there any compelling reasons for having profiled libs to be built by
>> default?
>
>Nope. It's been one of the first things I disable after I install a new
>system for at least a decade.
>
>
On 11/28/2011 02:38, Max Khon wrote:
> Are there any compelling reasons for having profiled libs to be built by
> default?
Nope. It's been one of the first things I disable after I install a new
system for at least a decade.
Ideally we could do this for 9.0.
Doug
--
"We could
49 matches
Mail list logo
