This was very helpful thanks!
On Wed, Dec 30, 2020 at 10:08 PM Glyph wrote:
> One minor point, if this is within your power: don't marshal data over
> stdout; sometimes libraries scribble on it. Open an arbitrary additional
> file descriptor - say, 7 - and put your marshalled data there.
>
> De
One minor point, if this is within your power: don't marshal data over stdout;
sometimes libraries scribble on it. Open an arbitrary additional file
descriptor - say, 7 - and put your marshalled data there.
Definitely never use stderr for marshaling anything but lines of text - you're
not gonn
I'm not entirely following the question (is the log output intermixed with
other data on stdout?) but I think that you might find the implementation of
twisted.internet.endpoints.ProcessEndpoint a useful example. It relays stderr
to the logging stream:
https://github.com/twisted/twisted/blob/c8
Can anyone point me to some sample code for handling logging with
SpawnProcess? Right now I'm using an EchoProtocol that takes stdout and
resends it to the log. But it's kludgy because some sub-processes use
stdin/stderr for marshaling data. What I'd most like to do is separate data
transfer from l
On 24 Nov, 11:55 pm, jonas.brunsga...@gmail.com wrote:
Does anyone know if there are any plans to update, the logging system
in twistd at some point, so it integrates better with native python
logging
system?
What does "integrates better" mean?
I have to use the following logging scheme (gl
For your Trac'ing pleasure:
https://twistedmatrix.com/trac/ticket/6750
-wsv
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, Jun 17, 2013 at 11:50 PM, Glyph wrote:
> On Jun 17, 2013, at 5:48 PM, James Y Knight wrote:
>
> And having a logging system which doesn't even support a basic log level
> is just silly. Hopefully the new system can at least have that.
>
> +1
> The new system being proposed does have lo
On Jun 18, 2013, at 8:25 AM, Peter Westlake wrote:
> On Tue, Jun 18, 2013, at 4:50, Glyph wrote:
>> On Jun 17, 2013, at 5:48 PM, James Y Knight wrote:
> ...
>>> And having a logging system which doesn't even support a basic
>>> log level is just silly. Hopefully the new system can at least
>>>
On Tue, Jun 18, 2013, at 4:50, Glyph wrote:
> On Jun 17, 2013, at 5:48 PM, James Y Knight wrote:
...
> > And having a logging system which doesn't even support a basic
> > log level is just silly. Hopefully the new system can at least
> > have that.
>
> The new system being proposed does have log
On Jun 17, 2013, at 5:48 PM, James Y Knight wrote:
> I'm surprised that a thread with 32 messages about logging doesn't seem to
> have once mentioned windows events, osx structured syslog, or systemd journal
> as important design points.
As it happens I was discussing exactly that! In a sens
On Mon, Jun 17, 2013 at 7:48 PM, James Y Knight wrote:
> I'm surprised that a thread with 32 messages about logging doesn't seem to
> have once mentioned windows events, osx structured syslog, or systemd
> journal as important design points.
>
> Maybe people are thinking about such things in the
I'm surprised that a thread with 32 messages about logging doesn't seem to have
once mentioned windows events, osx structured syslog, or systemd journal as
important design points.
Maybe people are thinking about such things in the background but it looks a
lot like this is being designed in a
On Sun, Jun 16, 2013 at 4:38 AM, Glyph wrote:
>
> (I was going to say that without a format string I couldn't have my
> stand-in UUID feature, but then I realized that namespace + set of keys is
> probably good enough to generate that too, so never mind. Also it seems
> like I'm the only one who
On Sat, Jun 15, 2013 at 9:38 PM, Glyph wrote:
>
> On Jun 15, 2013, at 9:17 AM, Christopher Armstrong <
> ra...@twistedmatrix.com> wrote:
>
> I think I would just want one more feature:
>
> Logger().emit(dudelog.LogLevel.warn, a="hi")
>
>
> Right now, this doesn't spit out anything into my log fil
On Jun 15, 2013, at 9:17 AM, Christopher Armstrong
wrote:
> I think I would just want one more feature:
>
Logger().emit(dudelog.LogLevel.warn, a="hi")
>
> Right now, this doesn't spit out anything into my log file, with
> default observers. I want it to emit some simple representation of
On Jun 15, 2013, at 8:46 AM, Christopher Armstrong
wrote:
> Yeah... I feel like a lot of the things you say in this email aren't
> related to the point I was trying to get across, which was the
> interface and effect, not the implementation of it.
Even if it's not really what you'd intended, I
On Jun 15, 2013, at 8:33 AM, Christopher Armstrong
wrote:
> It sounds like you're arguing that the human-readable *.log format
> should be closer to the simple key/value representation that we use
> underneath.
>
> Would you also argue that instead of having a log line that looks like:
>
> 20
On Jun 15, 2013, at 5:28 AM, Phil Mayers wrote:
> On 06/15/2013 12:13 PM, Glyph wrote:
>
>> I am really, really puzzled by this reaction. I am wondering if you
>> read my message carefully, or if I didn't express myself well.
>
> Careful re-reading of the very last bit of your message suggest
On Sat, Jun 15, 2013 at 11:09 AM, Christopher Armstrong
wrote:
> On Thu, Jun 13, 2013 at 5:14 PM, Glyph wrote:
>> Hello everybody. Today I'd like to talk about everyone's favorite subsystem
>> within Twisted: logging.
>>
>> There are a number of problems with Twisted's logging system.
>>
>> The g
On Thu, Jun 13, 2013 at 5:14 PM, Glyph wrote:
> Hello everybody. Today I'd like to talk about everyone's favorite subsystem
> within Twisted: logging.
>
> There are a number of problems with Twisted's logging system.
>
> The general theme of these problems is that Twisted log system was designed
>
On Sat, Jun 15, 2013 at 6:37 AM, Glyph wrote:
>
> On Jun 14, 2013, at 11:18 PM, Christopher Armstrong
> wrote:
>
> This conversation has gotten pretty sprawling; time to reel it in with
> some code.
>
> What do you think of this for an API that meets in the middle?
>
> https://gist.github.com/rad
On Sat, Jun 15, 2013 at 2:18 AM, Hynek Schlawack wrote:
>
> Am 15.06.2013 um 08:18 schrieb Christopher Armstrong
> :
>> What do you think of this for an API that meets in the middle?
>>
>> https://gist.github.com/radeex/5787124
>>
>> This example implementation only concerns itself with the point
On 06/15/2013 12:13 PM, Glyph wrote:
I am really, really puzzled by this reaction. I am wondering if you
read my message carefully, or if I didn't express myself well.
Careful re-reading of the very last bit of your message suggests I may
have misunderstood.
I think I understand the "final
On Jun 14, 2013, at 11:18 PM, Christopher Armstrong
wrote:
> This conversation has gotten pretty sprawling; time to reel it in with
> some code.
>
> What do you think of this for an API that meets in the middle?
>
> https://gist.github.com/radeex/5787124
>
> This example implementation only
On Jun 15, 2013, at 3:55 AM, Phil Mayers wrote:
> On 06/15/2013 06:48 AM, Christopher Armstrong wrote:
>
>> There's... a lot here. I'm overwhelmed by how complex this system
>> would be, and I think that end users would be as well. I don't really
>> want to put UUIDs into my source code, whethe
On 06/15/2013 06:48 AM, Christopher Armstrong wrote:
There's... a lot here. I'm overwhelmed by how complex this system
would be, and I think that end users would be as well. I don't really
want to put UUIDs into my source code, whether I type them or paste
them, and I don't want to have to invok
On Jun 14, 2013, at 10:48 PM, Christopher Armstrong
wrote:
> There's... a lot here. I'm overwhelmed by how complex this system
> would be, and I think that end users would be as well. I don't really
> want to put UUIDs into my source code, whether I type them or paste
> them, and I don't want t
On Jun 14, 2013, at 10:43 PM, Christopher Armstrong
wrote:
> I don't think it's worth coming up with some kind of GUID-based
> system, because I don't think anyone's going to go to the trouble to
> use it, and I think it basically offers no practical benefit over
> simple event names.
Here are
Am 15.06.2013 um 08:18 schrieb Christopher Armstrong :
>> As far as actual *proposals* go, I have these ones, that are all independent:
>>
>> 1. include all keyword arguments in log output without requiring
>> specifying the formatting in the string
>> 2. make it really easy to specify the "syst
On Sat, Jun 15, 2013 at 12:43 AM, Christopher Armstrong
wrote:
> On Fri, Jun 14, 2013 at 6:20 PM, Wilfredo Sánchez Vega
> wrote:
>> Christopher Armstrong wrote:
>>
>> logger.msg("scheduled-compaction-failed")
>>
>> I'm confused. You don't want to use English, but… why not change your
>> hyphen
On Fri, Jun 14, 2013 at 6:40 PM, Glyph wrote:
>
> On Jun 14, 2013, at 3:43 PM, Glyph wrote:
>
> I think that we can satisfy all of these requirements by expanding the
> notion of an "identifier" a bit.
>
>
> In our last episode, I mentioned that an identifier should have several
> properties:
>
>
On Fri, Jun 14, 2013 at 6:20 PM, Wilfredo Sánchez Vega
wrote:
> Christopher Armstrong wrote:
>
> logger.msg("scheduled-compaction-failed")
>
> I'm confused. You don't want to use English, but… why not change your
> hyphens to spaces and call it a day? Also, why did it fail?
Because as soon as
On Jun 14, 2013, at 3:43 PM, Glyph wrote:
> I think that we can satisfy all of these requirements by expanding the notion
> of an "identifier" a bit.
In our last episode, I mentioned that an identifier should have several
properties:
human readable (and potentially non-unique) for ease of wr
Christopher Armstrong wrote:
logger.msg("scheduled-compaction-failed")
I'm confused. You don't want to use English, but... why not change
your hyphens to spaces and call it a day? Also, why did it fail?
Here's a fuller example, modified to fit the API I'm using:
from twisted.python.log
On Fri, Jun 14, 2013 at 5:43 PM, Christopher Armstrong
wrote:
> If you're concerned about universal uniqueness, there are two ways I
> can think of doing it, both of which should basically have a similar
> API as far as where concerns are in your code:
>
> - make the event name hierarchical with a
On Jun 13, 2013, at 4:16 PM, Christopher Armstrong
wrote:
> On Thu, Jun 13, 2013 at 5:14 PM, Glyph wrote:
>>
>> Hello everybody. Today I'd like to talk about everyone's favorite subsystem
>> within Twisted: logging.
>>
>> There are a number of problems with Twisted's logging system.
>
> Th
On Fri, Jun 14, 2013 at 4:47 PM, wrote:
> On 07:45 pm, ra...@twistedmatrix.com wrote:
>> I think both of these should be avoided because they require the user
>> to specify string interpolation themselves. I'd prefer to avoid that
>> entirely, by default.
>>
>> log.msg("Foo happened**", bar=bar,
On 07:45 pm, ra...@twistedmatrix.com wrote:
On Fri, Jun 14, 2013 at 1:41 AM, Jamu Kakar wrote:
Hi,
On Thu, Jun 13, 2013 at 6:41 PM, Facundo Batista
wrote:
Mmm... which is the problem with doing:
log.msg("Foo happened. Relevant information includes: "
"bar=%s baz=%s boz=%s", bar
On Fri, Jun 14, 2013 at 1:41 AM, Jamu Kakar wrote:
> Hi,
>
> On Thu, Jun 13, 2013 at 6:41 PM, Facundo Batista
> wrote:
>> Mmm... which is the problem with doing:
>>
>> log.msg("Foo happened. Relevant information includes: "
>> "bar=%s baz=%s boz=%s", bar, baz, boz)
>>
>> Is way more
Hi,
On Thu, Jun 13, 2013 at 6:41 PM, Facundo Batista
wrote:
> Mmm... which is the problem with doing:
>
> log.msg("Foo happened. Relevant information includes: "
> "bar=%s baz=%s boz=%s", bar, baz, boz)
>
> Is way more readable, and in the practice the code will just need to
> do som
On Thu, Jun 13, 2013 at 7:14 PM, Glyph wrote:
> For a long time, there's been consensus among at least a few core Twisted
> developers that log messages ought to be specified in terms of a format
> message and several relevant keyword arguments, so that tools can extract
> the values of the keywo
On Thu, Jun 13, 2013 at 5:14 PM, Glyph wrote:
> Hello everybody. Today I'd like to talk about everyone's favorite subsystem
> within Twisted: logging.
>
> There are a number of problems with Twisted's logging system.
I really need to get out of here and go to dinner, but I really
quickly wanted t
On Thu, Jun 13, 2013 at 5:14 PM, Glyph wrote:
>
> Hello everybody. Today I'd like to talk about everyone's favorite subsystem
> within Twisted: logging.
>
> There are a number of problems with Twisted's logging system.
Thanks for writing up this email. I'd like to help out with this effort.
> F
Hello everybody. Today I'd like to talk about everyone's favorite subsystem
within Twisted: logging.
There are a number of problems with Twisted's logging system.
The general theme of these problems is that Twisted log system was designed
with some intended use-cases in mind, but its implementa
On 01:52 pm, step...@thorne.id.au wrote:
>It's also perfectly fine to use python's logging module from within
>twisted, you don't have to use twisted.log, but you should be aware
>this
>will make your log files hard to correlate (between twistd.log and your
>own
>logfiles).
For posterity: within
It's also perfectly fine to use python's logging module from within
twisted, you don't have to use twisted.log, but you should be aware this
will make your log files hard to correlate (between twistd.log and your own
logfiles).
On Thu, Mar 14, 2013 at 10:05 AM, Sergey Gerasimov wrote:
> I’m imp
On Mar 14, 2013, at 3:05 AM, Sergey Gerasimov wrote:
> I’m implementing some project based on twisted.
>
> I would like to use some logging mechanism in my modules and see both twisted
> generated log records and log records from my modules
> and be able to filter log records by level and sou
I'm implementing some project based on twisted.
I would like to use some logging mechanism in my modules and see both
twisted generated log records and log records from my modules
and be able to filter log records by level and source (generated by
twisted, or subset of my modules).
What s
On 12 Jul, 07:33 pm, tobias.oberst...@tavendo.de wrote:
>>libuv is a giant pile of new, unaudited C code that didn't even have a
>>passing
>>test suite until a month or two ago. Please feel free to write a
>>reactor for it;
>
>> From what I've read, libuv has designed it's API around the pattern
> libuv is a giant pile of new, unaudited C code that didn't even have a passing
> test suite until a month or two ago. Please feel free to write a reactor for
> it;
>From what I've read, libuv has designed it's API around the pattern
A. "do operation and get notified when done"
instead of
B.
Le Jul 12, 2012 à 6:47 AM, exar...@twistedmatrix.com a écrit :
> I think it was a mistake to try to make it possible to use
> twisted.python.log free-threaded. I think we should think about getting
> rid of this claimed feature. Perhaps it could be replaced with a more
> explicit, probably mo
Le Jul 12, 2012 à 8:26 AM, Tobias Oberstein a
écrit :
>> As far as I know, all of the implementations of POSIX AIO are relatively low
>> quality. They include a number of tricky, low-level constraints (eg, char*
>> to
>> write must be page aligned) as well as some sad functional limitations s
> As far as I know, all of the implementations of POSIX AIO are relatively low
> quality. They include a number of tricky, low-level constraints (eg, char* to
> write must be page aligned) as well as some sad functional limitations such as
> blocking instead of being asynchronous if too many AIOs
For logging could we look at implementing posix aio on platforms that
support it? I would be willing to help code that.
Justin
On Jul 12, 2012 8:51 AM, wrote:
> On 11:32 am, ita...@itamarst.org wrote:
> >On 07/12/2012 05:17 AM, Tristan Seligmann wrote:
> >>3) log observers should expect to be i
On 11:32 am, ita...@itamarst.org wrote:
>On 07/12/2012 05:17 AM, Tristan Seligmann wrote:
>>3) log observers should expect to be inovked in non-reactor threads,
>>making this a Mantissa bug.
>In theory this is the case - the logging howto says "The observer needs
>to be thread safe if you anticipat
On 07/12/2012 05:17 AM, Tristan Seligmann wrote:
> 3) log observers should expect to be inovked in non-reactor threads,
> making this a Mantissa bug.
>
In theory this is the case - the logging howto says "The observer needs
to be thread safe if you anticipate using threads in your program." The
A
When an error occurs in a database connection thread, adbapi invokes
log.err from that thread, which in turns causes log observers to be
invoked in this thread. Mantissa's TracebackCollector has a log
observer which logs items as Items in an Axiom store; this means that
the log observer tries to ru
On Tue, Nov 15, 2011 at 11:36 AM, Jeffrey Ollie wrote:
> I'm using twisted.python.log to do some logging in an application.
> It's formatting the output like " [-] ". I've seen
> in some of my other applications that the contents of "[-]" can change
> depending on how the code is reached. Is th
I'm using twisted.python.log to do some logging in an application.
It's formatting the output like " [-] ". I've seen
in some of my other applications that the contents of "[-]" can change
depending on how the code is reached. Is there a way that I can
customize this in my application? I'd like
Thanks. that does the job for me very well.
On Thu, Nov 5, 2009 at 7:18 PM, wrote:
> On 01:20 pm, naman...@gmail.com wrote:
> >I ll try to rephrase it better:
> >
> >I simply want the print statement to appear in both the log file and
> >the
> >console.
> >print("goes in both") -> the log also g
Hi,
Using log.startLogging(open(logname, 'w'), setStdout=False)
very well solves the issue.. of stdout remaining untouched and log.msg()
calls going to log
Can we do this ?:
Log file gets -> both the log.msg() calls , the stdout +stderr
console -> gets stdout +stderr as usual
Regards
Naman
On
naman jain writes:
> I wanted to log in a file and keep the console also going with it.
I can read this as either:
* Keep file logs and stdout/console completely separate, or
* File gets explicit logs and copies of stdout, but stdout also goes to
console as well.
The latter is somethin
Hi,
I wanted to log in a file and keep the console also going with it.
I am using
log.startLogging(open(logname, 'w'))
whatever documentation I could find about this API, it suggested me to pass
setStdout=False(in order to keep stdout away from putting into log)
somewhere in the startlogging fun
63 matches
Mail list logo
