ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:72725] [Ruby trunk - Feature #11955] [Open] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
@ 2016-01-05 21:59 ` richard.schneeman
  2016-01-06 16:27 ` [ruby-core:72734] [Ruby trunk - Feature #11955] " richard.schneeman
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-01-05 21:59 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been reported by Richard Schneeman.

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:72734] [Ruby trunk - Feature #11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
  2016-01-05 21:59 ` [ruby-core:72725] [Ruby trunk - Feature #11955] [Open] Expose Object that Receives logs in Logger richard.schneeman
@ 2016-01-06 16:27 ` richard.schneeman
  2016-01-07  5:44 ` [ruby-core:72750] " nobu
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-01-06 16:27 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Richard Schneeman.


Here is a patch to Rails that could benefit from standardizing access to the logger destination object: https://github.com/rails/rails/pull/22933


----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-55983

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:72750] [Ruby trunk - Feature #11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
  2016-01-05 21:59 ` [ruby-core:72725] [Ruby trunk - Feature #11955] [Open] Expose Object that Receives logs in Logger richard.schneeman
  2016-01-06 16:27 ` [ruby-core:72734] [Ruby trunk - Feature #11955] " richard.schneeman
@ 2016-01-07  5:44 ` nobu
  2016-01-08 17:00 ` [ruby-core:72776] " richard.schneeman
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: nobu @ 2016-01-07  5:44 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Nobuyoshi Nakada.

Description updated

Your example doesn't seem to able to get rid of adding `stdout_logger` twice or more, even with `logger.destination`.

Maybe won't it be better to do in `LogDevice` layer?

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-55995

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:72776] [Ruby trunk - Feature #11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (2 preceding siblings ...)
  2016-01-07  5:44 ` [ruby-core:72750] " nobu
@ 2016-01-08 17:00 ` richard.schneeman
  2016-01-19 20:03 ` [ruby-core:72938] " richard.schneeman
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-01-08 17:00 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Richard Schneeman.


> Your example doesn't seem to able to get rid of adding stdout_logger twice or more, even with logger.destination.

It took a long time to write that example to be short, maybe I missed some details. A real world example is in that linked pull request, you can see the comparison I implemented https://github.com/rails/rails/blob/76c385709c873a7105e3a267d84c4e70417a15e2/activesupport/lib/active_support/logger.rb#L8-L17 this is where I would like to use a public interface instead of `instance_variable_get`.

LogDevice already exposes the destination, but Logger does not expose the LogDevice object. I did not know if there was a reason people did not what to provide access to LogDevice. Would you prefer that I submitted a patch to expose the LogDevice instead?


----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-56021

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:72938] [Ruby trunk - Feature #11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (3 preceding siblings ...)
  2016-01-08 17:00 ` [ruby-core:72776] " richard.schneeman
@ 2016-01-19 20:03 ` richard.schneeman
  2016-01-20  0:27 ` [ruby-core:72949] [Ruby trunk - Feature #11955] [Assigned] " shibata.hiroshi
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-01-19 20:03 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Richard Schneeman.

File ruby-changes.patch added

Nobu, I've added a new patch that would expose the `LogDevice` object in a `Logger` instance. This would be acceptable for my needs.

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-56165

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:72949] [Ruby trunk - Feature #11955] [Assigned] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (4 preceding siblings ...)
  2016-01-19 20:03 ` [ruby-core:72938] " richard.schneeman
@ 2016-01-20  0:27 ` shibata.hiroshi
  2016-03-15 16:42 ` [ruby-core:74344] [Ruby trunk Feature#11955] " richard.schneeman
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: shibata.hiroshi @ 2016-01-20  0:27 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Hiroshi SHIBATA.

Status changed from Open to Assigned
Assignee set to Naotoshi Seo

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-56174

* Author: Richard Schneeman
* Status: Assigned
* Priority: Normal
* Assignee: Naotoshi Seo
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:74344] [Ruby trunk Feature#11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (5 preceding siblings ...)
  2016-01-20  0:27 ` [ruby-core:72949] [Ruby trunk - Feature #11955] [Assigned] " shibata.hiroshi
@ 2016-03-15 16:42 ` richard.schneeman
  2016-04-18 13:16 ` [ruby-core:75010] " sonots
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-03-15 16:42 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Richard Schneeman.


Anything else that needs to be done for this patch?

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-57467

* Author: Richard Schneeman
* Status: Assigned
* Priority: Normal
* Assignee: Naotoshi Seo
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:75010] [Ruby trunk Feature#11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (6 preceding siblings ...)
  2016-03-15 16:42 ` [ruby-core:74344] [Ruby trunk Feature#11955] " richard.schneeman
@ 2016-04-18 13:16 ` sonots
  2016-06-20 13:45 ` [ruby-core:76083] " richard.schneeman
  2017-11-09 11:35 ` [ruby-core:83703] " andrew.babichev
  9 siblings, 0 replies; 10+ messages in thread
From: sonots @ 2016-04-18 13:16 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Naotoshi Seo.


I am wondering of the interface yet.

Users pass an io object to Logger constructor as `logdev` as `Logger.new(logdev)`, so getting the io object from `Logger#logdev` seems natural. However,

```
attr_reader :logdev
```

returns a LogDevice instance rather than io object although it is natural from the view of source codes.

----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-58140

* Author: Richard Schneeman
* Status: Assigned
* Priority: Normal
* Assignee: Naotoshi Seo
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:76083] [Ruby trunk Feature#11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (7 preceding siblings ...)
  2016-04-18 13:16 ` [ruby-core:75010] " sonots
@ 2016-06-20 13:45 ` richard.schneeman
  2017-11-09 11:35 ` [ruby-core:83703] " andrew.babichev
  9 siblings, 0 replies; 10+ messages in thread
From: richard.schneeman @ 2016-06-20 13:45 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by Richard Schneeman.


Sorry for the delay, bugs.ruby-lang.org does not send me emails for some reason.

The first patch I attached returned `@logdev.dev` which is the IO object. It was discussed that to do this Logger must know too much about the logdev interface and it would be simpler to expose the logdev instead.

Either approach will work for my use cases. Now that 2.4.0 preview is out is there a feature freeze? Is there any chance this will come out in time for christmas?


----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-59285

* Author: Richard Schneeman
* Status: Assigned
* Priority: Normal
* Assignee: Naotoshi Seo
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [ruby-core:83703] [Ruby trunk Feature#11955] Expose Object that Receives logs in Logger
       [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
                   ` (8 preceding siblings ...)
  2016-06-20 13:45 ` [ruby-core:76083] " richard.schneeman
@ 2017-11-09 11:35 ` andrew.babichev
  9 siblings, 0 replies; 10+ messages in thread
From: andrew.babichev @ 2017-11-09 11:35 UTC (permalink / raw
  To: ruby-core

Issue #11955 has been updated by tensho (Andrew Babichev).


So will **#logdev** will be exposed in Logger or Logger::LogDevice)?


----------------------------------------
Feature #11955: Expose Object that Receives logs in Logger
https://bugs.ruby-lang.org/issues/11955#change-67727

* Author: schneems (Richard Schneeman)
* Status: Assigned
* Priority: Normal
* Assignee: sonots (Naotoshi Seo)
* Target version: 
----------------------------------------
I need to be able to perform logic based on the destination of a current logger, this is currently not possible without `instance_variable_get`. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:


```ruby
def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger = ::Logger.new(STDOUT)
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)
      end
    end)
  end
end

logger = Logger.new(STDOUT)
make_sure_logging_to_stdout(logger)

logger.fatal("An error has occured")
```

We should be able to inspect the destination of a logger, this patch enables this functionality.


---Files--------------------------------
ruby-changes.patch (1.04 KB)
ruby-changes.patch (2.17 KB)


-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-11-09 11:35 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <redmine.issue-11955.20160105215929@ruby-lang.org>
2016-01-05 21:59 ` [ruby-core:72725] [Ruby trunk - Feature #11955] [Open] Expose Object that Receives logs in Logger richard.schneeman
2016-01-06 16:27 ` [ruby-core:72734] [Ruby trunk - Feature #11955] " richard.schneeman
2016-01-07  5:44 ` [ruby-core:72750] " nobu
2016-01-08 17:00 ` [ruby-core:72776] " richard.schneeman
2016-01-19 20:03 ` [ruby-core:72938] " richard.schneeman
2016-01-20  0:27 ` [ruby-core:72949] [Ruby trunk - Feature #11955] [Assigned] " shibata.hiroshi
2016-03-15 16:42 ` [ruby-core:74344] [Ruby trunk Feature#11955] " richard.schneeman
2016-04-18 13:16 ` [ruby-core:75010] " sonots
2016-06-20 13:45 ` [ruby-core:76083] " richard.schneeman
2017-11-09 11:35 ` [ruby-core:83703] " andrew.babichev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).