You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Alex Boisvert <al...@gmail.com> on 2010/03/23 17:59:44 UTC
Controlling verbosity
This was brought up in another email but I figured it deserved a separate
thread.
Right now "buildr --trace" turns the verbose fire-hose to full blast. This
means we run "javac -verbose", "ant --trace", "apt -verbose", ... which is
often overwhelming and of little use when you're simply debugging
Rake-related dependency issues.
One solution would be to selectively turn on the trace switch based on the
task so I was thinking of adding a BUILDR_TRACE environment variable that
would contain a list of comma-separated keywords to control tracing
behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
Any better ideas?
alex
Re: Controlling verbosity
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I think we inherit --trace from rake. Might be worth looking if they have
something like that already in place ?
On Tue, Mar 23, 2010 at 15:25, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> I like the idea, but I think the environment variable is a bit clumsy and
> hard to discover. What about a parameter for --trace?
>
> buildr --trace # traces everything
> buildr --trace=tasks # traces just build-related bits -- task executions,
> things logged with `trace` in buildr & extensions
> buildr --trace=ant,javac # ups the verbosity for just ant and javac
>
> Rhett
>
>
> On Mar 23, 2010, at 5:11 PM, Antoine Toulme wrote:
>
> I'm all for that one. I was for turning javac verbose to off by default so
>> this looks more appropriate - more configuration for the ones that need
>> it.
>>
>> On Tue, Mar 23, 2010 at 09:59, Alex Boisvert <alex.boisvert@gmail.com
>> >wrote:
>>
>> This was brought up in another email but I figured it deserved a separate
>>> thread.
>>>
>>> Right now "buildr --trace" turns the verbose fire-hose to full blast.
>>> This
>>> means we run "javac -verbose", "ant --trace", "apt -verbose", ... which
>>> is
>>> often overwhelming and of little use when you're simply debugging
>>> Rake-related dependency issues.
>>>
>>> One solution would be to selectively turn on the trace switch based on
>>> the
>>> task so I was thinking of adding a BUILDR_TRACE environment variable that
>>> would contain a list of comma-separated keywords to control tracing
>>> behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
>>>
>>> Any better ideas?
>>>
>>> alex
>>>
>>>
>
Re: Controlling verbosity
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Alex,
On Mar 23, 2010, at 5:59 PM, Alex Boisvert wrote:
> On Tue, Mar 23, 2010 at 3:25 PM, Rhett Sutphin <rhett@detailedbalance.net
> >wrote:
>
>> I like the idea, but I think the environment variable is a bit
>> clumsy and
>> hard to discover. What about a parameter for --trace?
>>
>> buildr --trace # traces everything
>> buildr --trace=tasks # traces just build-related bits -- task
>> executions,
>> things logged with `trace` in buildr & extensions
>> buildr --trace=ant,javac # ups the verbosity for just ant and javac
>>
>
> Good idea; I'll see what I can do.
>
> My only objection here is that I think --trace to trace everything
> is a bad
> default. I think most people want to trace task execution by
> default and
> then selectively opt-in for more verbosity. I would go for --
> trace=all to
> enable everything.
That is almost what I wrote, but I was overcome by a wave of desire
for backwards compatibility. I'm over it now -- I think what you're
describing is a better plan.
> My other assumption is that we would go and update the documentation
> to
> clearly identify what are the possible trace values, both as
> reference for
> all values and in each relevant sections for task-specific values.
> (I'm
> volunteering for this too).
Don't forget the output from `buildr --help`.
Rhett
Re: Controlling verbosity
Posted by Alex Boisvert <al...@gmail.com>.
On Tue, Mar 23, 2010 at 3:25 PM, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> I like the idea, but I think the environment variable is a bit clumsy and
> hard to discover. What about a parameter for --trace?
>
> buildr --trace # traces everything
> buildr --trace=tasks # traces just build-related bits -- task executions,
> things logged with `trace` in buildr & extensions
> buildr --trace=ant,javac # ups the verbosity for just ant and javac
>
Good idea; I'll see what I can do.
My only objection here is that I think --trace to trace everything is a bad
default. I think most people want to trace task execution by default and
then selectively opt-in for more verbosity. I would go for --trace=all to
enable everything.
My other assumption is that we would go and update the documentation to
clearly identify what are the possible trace values, both as reference for
all values and in each relevant sections for task-specific values. (I'm
volunteering for this too).
alex
Re: Controlling verbosity
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
I like the idea, but I think the environment variable is a bit clumsy
and hard to discover. What about a parameter for --trace?
buildr --trace # traces everything
buildr --trace=tasks # traces just build-related bits -- task
executions, things logged with `trace` in buildr & extensions
buildr --trace=ant,javac # ups the verbosity for just ant and javac
Rhett
On Mar 23, 2010, at 5:11 PM, Antoine Toulme wrote:
> I'm all for that one. I was for turning javac verbose to off by
> default so
> this looks more appropriate - more configuration for the ones that
> need it.
>
> On Tue, Mar 23, 2010 at 09:59, Alex Boisvert
> <al...@gmail.com>wrote:
>
>> This was brought up in another email but I figured it deserved a
>> separate
>> thread.
>>
>> Right now "buildr --trace" turns the verbose fire-hose to full blast.
>> This
>> means we run "javac -verbose", "ant --trace", "apt -verbose", ...
>> which is
>> often overwhelming and of little use when you're simply debugging
>> Rake-related dependency issues.
>>
>> One solution would be to selectively turn on the trace switch based
>> on the
>> task so I was thinking of adding a BUILDR_TRACE environment
>> variable that
>> would contain a list of comma-separated keywords to control tracing
>> behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
>>
>> Any better ideas?
>>
>> alex
>>
Re: Controlling verbosity
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I'm all for that one. I was for turning javac verbose to off by default so
this looks more appropriate - more configuration for the ones that need it.
On Tue, Mar 23, 2010 at 09:59, Alex Boisvert <al...@gmail.com>wrote:
> This was brought up in another email but I figured it deserved a separate
> thread.
>
> Right now "buildr --trace" turns the verbose fire-hose to full blast.
> This
> means we run "javac -verbose", "ant --trace", "apt -verbose", ... which is
> often overwhelming and of little use when you're simply debugging
> Rake-related dependency issues.
>
> One solution would be to selectively turn on the trace switch based on the
> task so I was thinking of adding a BUILDR_TRACE environment variable that
> would contain a list of comma-separated keywords to control tracing
> behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
>
> Any better ideas?
>
> alex
>
Re: changelog encoding
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi,
On Mar 24, 2010, at 10:45 AM, Antoine Toulme wrote:
> It looks ok to me here:
> http://github.com/apache/buildr/blob/trunk/CHANGELOG
>
> I also see the character correctly in Textmate.
>
> Where and how do you see this problem ?
I see it on http://buildr.apache.org/CHANGELOG .
It looks like the file is UTF-8 encoded, but that server is ending it
without the charset parameter on content-type:
$ curl -I http://buildr.apache.org/CHANGELOG
HTTP/1.1 200 OK
Date: Wed, 24 Mar 2010 15:48:12 GMT
Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/
3.2 Python/2.6.5rc2
Last-Modified: Tue, 08 Dec 2009 22:54:40 GMT
ETag: "2180f9b-db49-47a3f7584ac00"
Accept-Ranges: bytes
Content-Length: 56137
Content-Type: text/plain
The default charset for HTTP is ISO-8859-1 (RFC2068, section 3.7.1),
so a browser is going to misinterpret any high-bit / multibyte
characters. I presume this would have to be fixed by configuring
apache. I don't know if you can do charset overrides using .htaccess
(or if apache.org even allows that).
Rhett
>
> Thanks!
>
> Antoine
>
> On Wed, Mar 24, 2010 at 02:14, Peter Schröder <ps...@blau.de> wrote:
>
>> just a sidenote, the changelog (http://buildr.apache.org/CHANGELOG)
>> has an
>> encoding issue :-)
>>
>> "Peter Schröder" --> thats not my name!
>>
Re: changelog encoding
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Cool!
On Wed, Mar 24, 2010 at 13:49, Alex Boisvert <al...@gmail.com>wrote:
> Tweaking .htaccess worked,
>
> boisvert@smudge:~/svn/buildr-trunk$ curl -I
> http://buildr.apache.org/CHANGELOG
>
> HTTP/1.1 200 OK
> Date: Wed, 24 Mar 2010 20:47:47 GMT
>
> Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2
> Python/2.6.5rc2
> Last-Modified: Tue, 08 Dec 2009 22:54:40 GMT
> ETag: "2180f9b-db49-47a3f7584ac00"
> Accept-Ranges: bytes
> Content-Length: 56137
> Vary: Accept-Encoding
> Content-Type: text/plain; charset=utf-8
>
> I updated the release procedure to generate this file for the website.
>
> alex
>
>
> On Wed, Mar 24, 2010 at 10:50 AM, Alex Boisvert <al...@gmail.com>wrote:
>
>> I'm trying to tweak the encoding sent by Apache's server to be UTF-8 using
>> .htaccess. Need to wait for mirrors to pick up the change to see if it
>> works.
>>
>> alex
>>
>>
>>
>> On Wed, Mar 24, 2010 at 8:54 AM, Peter Schröder <ps...@blau.de> wrote:
>>
>>> the github files is ok. but the link on apache has this issue with latest
>>> firefox and safari.
>>>
>>> see the screenshots:
>>>
>>>
>>
>
Re: changelog encoding
Posted by Peter Schröder <ps...@blau.de>.
yeay!
Am 24.03.2010 um 21:49 schrieb Alex Boisvert:
> Tweaking .htaccess worked,
>
> boisvert@smudge:~/svn/buildr-trunk$ curl -I
> http://buildr.apache.org/CHANGELOG
> HTTP/1.1 200 OK
> Date: Wed, 24 Mar 2010 20:47:47 GMT
> Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2
> Python/2.6.5rc2
> Last-Modified: Tue, 08 Dec 2009 22:54:40 GMT
> ETag: "2180f9b-db49-47a3f7584ac00"
> Accept-Ranges: bytes
> Content-Length: 56137
> Vary: Accept-Encoding
> Content-Type: text/plain; charset=utf-8
>
> I updated the release procedure to generate this file for the website.
>
> alex
>
> On Wed, Mar 24, 2010 at 10:50 AM, Alex Boisvert <al...@gmail.com>wrote:
>
>> I'm trying to tweak the encoding sent by Apache's server to be UTF-8 using
>> .htaccess. Need to wait for mirrors to pick up the change to see if it
>> works.
>>
>> alex
>>
>>
>>
>> On Wed, Mar 24, 2010 at 8:54 AM, Peter Schröder <ps...@blau.de> wrote:
>>
>>> the github files is ok. but the link on apache has this issue with latest
>>> firefox and safari.
>>>
>>> see the screenshots:
>>>
>>>
>>
Re: changelog encoding
Posted by Alex Boisvert <al...@gmail.com>.
Tweaking .htaccess worked,
boisvert@smudge:~/svn/buildr-trunk$ curl -I
http://buildr.apache.org/CHANGELOG
HTTP/1.1 200 OK
Date: Wed, 24 Mar 2010 20:47:47 GMT
Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2
Python/2.6.5rc2
Last-Modified: Tue, 08 Dec 2009 22:54:40 GMT
ETag: "2180f9b-db49-47a3f7584ac00"
Accept-Ranges: bytes
Content-Length: 56137
Vary: Accept-Encoding
Content-Type: text/plain; charset=utf-8
I updated the release procedure to generate this file for the website.
alex
On Wed, Mar 24, 2010 at 10:50 AM, Alex Boisvert <al...@gmail.com>wrote:
> I'm trying to tweak the encoding sent by Apache's server to be UTF-8 using
> .htaccess. Need to wait for mirrors to pick up the change to see if it
> works.
>
> alex
>
>
>
> On Wed, Mar 24, 2010 at 8:54 AM, Peter Schröder <ps...@blau.de> wrote:
>
>> the github files is ok. but the link on apache has this issue with latest
>> firefox and safari.
>>
>> see the screenshots:
>>
>>
>
Re: changelog encoding
Posted by Alex Boisvert <al...@gmail.com>.
I'm trying to tweak the encoding sent by Apache's server to be UTF-8 using
.htaccess. Need to wait for mirrors to pick up the change to see if it
works.
alex
On Wed, Mar 24, 2010 at 8:54 AM, Peter Schröder <ps...@blau.de> wrote:
> the github files is ok. but the link on apache has this issue with latest
> firefox and safari.
>
> see the screenshots:
>
>
Re: changelog encoding
Posted by Peter Schröder <ps...@blau.de>.
the github files is ok. but the link on apache has this issue with latest firefox and safari.
see the screenshots:
Re: changelog encoding
Posted by Antoine Toulme <an...@lunar-ocean.com>.
It looks ok to me here:
http://github.com/apache/buildr/blob/trunk/CHANGELOG
I also see the character correctly in Textmate.
Where and how do you see this problem ?
Thanks!
Antoine
On Wed, Mar 24, 2010 at 02:14, Peter Schröder <ps...@blau.de> wrote:
> just a sidenote, the changelog (http://buildr.apache.org/CHANGELOG) has an
> encoding issue :-)
>
> "Peter Schröder" --> thats not my name!
>
changelog encoding
Posted by Peter Schröder <ps...@blau.de>.
just a sidenote, the changelog (http://buildr.apache.org/CHANGELOG) has an encoding issue :-)
"Peter Schröder" --> thats not my name!
Re: Controlling verbosity
Posted by Alex Boisvert <al...@gmail.com>.
Sure.
On Wed, Mar 24, 2010 at 12:50 AM, Peter Schröder <ps...@blau.de> wrote:
> could one set that variable in the .buildr/buildr.rb file, so that it works
> for all builds?
>
> Am 23.03.2010 um 17:59 schrieb Alex Boisvert:
>
> > This was brought up in another email but I figured it deserved a separate
> > thread.
> >
> > Right now "buildr --trace" turns the verbose fire-hose to full blast.
> This
> > means we run "javac -verbose", "ant --trace", "apt -verbose", ... which
> is
> > often overwhelming and of little use when you're simply debugging
> > Rake-related dependency issues.
> >
> > One solution would be to selectively turn on the trace switch based on
> the
> > task so I was thinking of adding a BUILDR_TRACE environment variable that
> > would contain a list of comma-separated keywords to control tracing
> > behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
> >
> > Any better ideas?
> >
> > alex
>
>
Re: Controlling verbosity
Posted by Peter Schröder <ps...@blau.de>.
could one set that variable in the .buildr/buildr.rb file, so that it works for all builds?
Am 23.03.2010 um 17:59 schrieb Alex Boisvert:
> This was brought up in another email but I figured it deserved a separate
> thread.
>
> Right now "buildr --trace" turns the verbose fire-hose to full blast. This
> means we run "javac -verbose", "ant --trace", "apt -verbose", ... which is
> often overwhelming and of little use when you're simply debugging
> Rake-related dependency issues.
>
> One solution would be to selectively turn on the trace switch based on the
> task so I was thinking of adding a BUILDR_TRACE environment variable that
> would contain a list of comma-separated keywords to control tracing
> behavior, e.g., export BUILDR_TRACE="javac,ant,apt".
>
> Any better ideas?
>
> alex