I've been using Ruby and Needle to develop many applications, and in
particular I've found the Needle logger to be very handy indeed, and
use it very often. Well, Gentoo finally rolled Ruby 1.8.3 into Portage
and so I was upgraded, and one thing I noticed is that my log messages
suddenly go broken. Where I used to get log messages that look like
this:
[DEBUG] 2005-10-05T15:28:35.868732 -- core: adding new host
CCODEN38-LUCASG-VPNA-1 to druby://127.0.0.1:8169
I instead get garbage like this:
[DEBUG] 2005-10-05T15:28:35.868732 -- core: core
Every time! Has there been a change in the Ruby logger API in 1.8.3
that did this? I've rolled back to 1.8.2 for the time being.
Yah, Ruby's Logger API changed in a non-backwards-compatible way. This affects Net::SSH, too, because Net::SSH depends on Needle. Anyone using either of these libraries in encouraged to stick with 1.8.2 for the time being.
- Jamis
···
On Oct 5, 2005, at 2:49 AM, Dick Davies wrote:
On 05/10/05, Dido Sevilla <dido.sevilla@gmail.com> wrote:
Where I used to get log messages that look like
this:
[DEBUG] 2005-10-05T15:28:35.868732 -- core: adding new host
CCODEN38-LUCASG-VPNA-1 to druby://127.0.0.1:8169
I instead get garbage like this:
[DEBUG] 2005-10-05T15:28:35.868732 -- core: core
Every time! Has there been a change in the Ruby logger API in 1.8.3
that did this? I've rolled back to 1.8.2 for the time being.
accck! can you elaborate? i use logger in, oh, every single peice of my code
;-(
cheers.
-a
···
On Wed, 5 Oct 2005, Jamis Buck wrote:
Every time! Has there been a change in the Ruby logger API in 1.8.3
that did this? I've rolled back to 1.8.2 for the time being.
Yes, I think so - Rails was affected by this too.
Yah, Ruby's Logger API changed in a non-backwards-compatible way. This affects Net::SSH, too, because Net::SSH depends on Needle. Anyone using either of these libraries in encouraged to stick with 1.8.2 for the time being.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
Yah, Ruby's Logger API changed in a non-backwards-compatible way.
This affects Net::SSH, too, because Net::SSH depends on Needle.
Anyone using either of these libraries in encouraged to stick with
1.8.2 for the time being.
A non-backwards-compatible change in a minor release sounds like a bad
idea. 1.8.3 has been officially released, yeah? But I'd like to know
if this change was made intentionally, and whether such changes will be
made in future.
Well, to be fair, it was a private API that changed. The problem was that, in order to customize the format used by Logger, a programmer's only recourse was to override that private method, which is what both Needle and Rails do.
If you're only using the public Logger API, you should be fine.
- Jamis
···
On Oct 5, 2005, at 7:35 AM, Ara.T.Howard wrote:
On Wed, 5 Oct 2005, Jamis Buck wrote:
Every time! Has there been a change in the Ruby logger API in 1.8.3
that did this? I've rolled back to 1.8.2 for the time being.
Yes, I think so - Rails was affected by this too.
Yah, Ruby's Logger API changed in a non-backwards-compatible way. This affects Net::SSH, too, because Net::SSH depends on Needle. Anyone using either of these libraries in encouraged to stick with 1.8.2 for the time being.
accck! can you elaborate? i use logger in, oh, every single peice of my code
;-(
In message "Re: Ruby 1.8.3 breaks Needle's logger?" on Wed, 5 Oct 2005 23:01:48 +0900, "Gavin Sinclair" <gsinclair@gmail.com> writes:
A non-backwards-compatible change in a minor release sounds like a bad
idea. 1.8.3 has been officially released, yeah? But I'd like to know
if this change was made intentionally, and whether such changes will be
made in future.
See [ruby-talk:159143]. It's a minor internal change, which
_normally_ other libraries are not suppose to depend. Unfortunately
the author did not know there are several programs that depends on the
internal.
the currenl logger hides it's device which is anoying for daemons since the
logs buffer before dumping...
anyhow, thanks for the warning.
cheers.
-a
···
On Wed, 5 Oct 2005, Jamis Buck wrote:
Well, to be fair, it was a private API that changed. The problem was that,
in order to customize the format used by Logger, a programmer's only
recourse was to override that private method, which is what both Needle and
Rails do.
If you're only using the public Logger API, you should be fine.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
If you're only using the public Logger API, you should be fine.
If you are using logger with threads, run do not walk to the newest
version of logger. Get it in 1.8.3 or from the project web site. The log
rotation operation was not thread safe in the old version, causing
deadlocks and unhandled exceptions.
AFAIK, the main internal API change I had to work around was a change in
the order of the progname and msg arguments to the format_message
(internal) API.
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Well, to be fair, it was a private API that changed. The problem was
What is the concept 'private API' here? In general library development, there are 2 APIs for users and developers. For users it can be called 'public API' as you wrote. Is 'private API' you wrote an API for developers who extend a class for implementation inheritance?
Unfortunately Ruby has its small weakness about representing the latter API. Only we can do is writing a document about it. Logger has an inline document (by gsinclair: Thanks) but there's no mention about it because it's a 'final' (Java term) class.
As a library developer, I wish if I were able to write some 'protect'-ness and 'final'-ness explicitly (without writing any document) in Ruby. IIRC Java uses 'final', 'protected' and "This implementation ..." in Javadoc comments though.
Anyway, at this time, developers should not do both removing constants for redefinition and overwriting private methods without explicit permission by documents if they can.
Yup, same for Rails (and I imagine Needle and Nitro.)
Regards,
jeremy
···
On Oct 5, 2005, at 1:30 PM, Joel VanderWerf wrote:
AFAIK, the main internal API change I had to work around was a change in
the order of the progname and msg arguments to the format_message
(internal) API.
Well, to be fair, it was a private API that changed. The problem was
What is the concept 'private API' here? In general library development, there are 2 APIs for users and developers. For users it can be called 'public API' as you wrote. Is 'private API' you wrote an API for developers who extend a class for implementation inheritance?
By 'private', I meant 'hidden via the private method'. Thus, it was obvious the method(s) being altered were not meant for public (or even programmer) consumption, but given that there was no other way to modify the line format used by the logger than to override the method... well, some of us overrode it. And the signature changed.
Unfortunately Ruby has its small weakness about representing the latter API. Only we can do is writing a document about it. Logger has an inline document (by gsinclair: Thanks) but there's no mention about it because it's a 'final' (Java term) class.
As a library developer, I wish if I were able to write some 'protect'-ness and 'final'-ness explicitly (without writing any document) in Ruby. IIRC Java uses 'final', 'protected' and "This implementation ..." in Javadoc comments though.
Anyway, at this time, developers should not do both removing constants for redefinition and overwriting private methods without explicit permission by documents if they can.
I agree. But in this case, there was no other way to achieve the ends of the programmers. And it was less expensive in the long run (even given the the API change) to override the private method than it was to reimplement Logger with the one line changed.
I'm not blaming anyone--the developer of Logger was within their rights to refactor and alter that private method. I just hope (haven't checked yet) that 1.8.3 makes it easier to customize the log format so that moving forward we don't have to mess with Logger's internals.
- Jamis
···
On Oct 5, 2005, at 7:31 PM, NAKAMURA, Hiroshi wrote:
Well, to be fair, it was a private API that changed. The problem was
What is the concept 'private API' here? In general library development, there are 2 APIs for users and developers. For users it can be called 'public API' as you wrote. Is 'private API' you wrote an API for developers who extend a class for implementation inheritance?
I think by 'private API' Jamis means Logger implementation that is not meant to be exposed to either users or developers. So it's not really a part of the API at all.
Anyway, at this time, developers should not do both removing constants for redefinition and overwriting private methods without explicit permission by documents if they can.
Agreed. However, in 1.8.2 logger.rb:
# There is currently no supported way to change the overall format, but you may
# have some luck hacking the Format constant.
Hence we have these hacks to expose internal Logger implementation to add this missing feature. But these hacks had to modify Logger implementation that was not a part of its API, public or private.
It's cool to think of the ability to redefine a private method as part of a library's public API. In fact, I think that Logger documenting that it expects the format_message method to be redefined may be a nicer API than setting a formatter object.
Best,
jeremy
···
On Oct 5, 2005, at 6:31 PM, NAKAMURA, Hiroshi wrote:
Anyway, at this time, developers should not do both removing
constants for redefinition and overwriting private methods without
explicit permission by documents if they can.
Agreed. However, in 1.8.2 logger.rb:
# There is currently no supported way to change the overall format, but
you may
# have some luck hacking the Format constant.
I wasn't aware of that... I had to check well the documentation. Thank
you.
What is the concept 'private API' here? In general library
development, there are 2 APIs for users and developers. For users it
can be called 'public API' as you wrote. Is 'private API' you wrote
an API for developers who extend a class for implementation inheritance?
By 'private', I meant 'hidden via the private method'. Thus, it was
Thank you for the explanation. I felt words 'interface' and 'private'
are conflicting. Maybe I'm wrong.
obvious the method(s) being altered were not meant for public (or even
programmer) consumption, but given that there was no other way to
modify the line format used by the logger than to override the
method... well, some of us overrode it. And the signature changed.
Yes. There was no way to change the format other than breaking in the
implementation.
to refactor and alter that private method. I just hope (haven't checked
yet) that 1.8.3 makes it easier to customize the log format so that
moving forward we don't have to mess with Logger's internals.
You may change the overall format with Logger#formatter= method now.
On Oct 5, 2005, at 6:31 PM, NAKAMURA, Hiroshi wrote:
Jamis Buck wrote:
Well, to be fair, it was a private API that changed. The problem was
What is the concept 'private API' here? In general library
development, there are 2 APIs for users and developers. For users it
can be called 'public API' as you wrote. Is 'private API' you wrote
an API for developers who extend a class for implementation inheritance?
I think by 'private API' Jamis means Logger implementation that is not
meant to be exposed to either users or developers. So it's not really
a part of the API at all.
Anyway, at this time, developers should not do both removing
constants for redefinition and overwriting private methods without
explicit permission by documents if they can.
Agreed. However, in 1.8.2 logger.rb:
# There is currently no supported way to change the overall format, but
you may
# have some luck hacking the Format constant.
Hence we have these hacks to expose internal Logger implementation to
add this missing feature. But these hacks had to modify Logger
implementation that was not a part of its API, public or private.
It's cool to think of the ability to redefine a private method as part
of a library's public API. In fact, I think that Logger documenting
that it expects the format_message method to be redefined may be a
nicer API than setting a formatter object.