5 ms·

> shows how poor most non-web debugging and logging Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output op

by pdkl95 8y ago

> shows how poor most non-web debugging and logging Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output options. > The ability to mix and match data types and presentation format is extremely useful. That's a common feature of dynamic type languages. > Almost everywhere else we just have printf. Most languages have logging libraries, and many have them built into the stdlib or runtime. Popular languages usually have many logging libraries to choose from. > that’s printf going to stdout Of course - printf(3) by definition "shall place output on the standard output stream stdout"[1]. If you want stderr or any other output stream, use fprintf(3). #include <stdio.h> int main() { fprintf(stderr, "Error: %s\n", "LP0 on fire"); return 0; } Other languages usually handle that for you as part of the logging library. > there isn’t a universally deployed format Sure there is: "text"[2]. > to even allow it to travel easily over the network Copying files to a remote host is easy with scp. There are numerous ways to send data over a network. Web software is often more work as you have to move your debugging data/logs out of the browser first or use a specialized tool that does that for you. Sending program output realtime to a remote host only requires appending "| ssh ${host} \"${remote_cmd}\"" to your command. > advanced viewers That's great if you have specific needs and a viewer for your complex data structures, but the only universal solution is text. Fortunately, there are many tools available to handle structured data as text. > I think part of the problem is that programmers rarely want to get into these supportive details; they just printf and get on with it. I think you might want to explore the work programmers have done in other languages. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/pr... [2] http://www.catb.org/esr/writings/taoup/html/ch05s01.html http://www.catb.org/esr/writings/taoup/html/ch05s01.html

azinman2 8y ago
You're totally missing my point(s). Of course web programming is tied to the browser, but why does that mean debugging via logs has to be tied to whatever particular console is attached to where a program is running? Why can't I have a console.table() equivalent in Python, and Ruby, and C, and Go, and Java that all can render via a common protocol to any viewer that can handle it? By printf I didn't _literally_ mean printf -- I meant any logging type equivalent whether that IS printf or a built-in logging system. The point is there's no inter-op between them with any rich detail, which prohibits universal log viewers. When I say travel over the network, I don't mean scp. I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. That's the kind of portability required when you can't guarantee that complex display can be part of the same system that generated it -- that's a unique quality of web browsers. IT'S ABOUT THE PROTOCOL, NOT THE MECHANISM. Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data. Apple's Console.app is an elementary example of what I'm suggesting I'd like to see. Except I don't want it tied to the syslogs of an Apple device. I want every language/platform to be able to output to it in real-time. And for it's capabilities to be as rich or richer than what we have in the browser. We already have universal text editors like VIM/Emacs -- why can't we have universal log viewers?
- berti 8y ago
  "printf" will always have it's place, because when things are hosed, there's a good chance you can't push stuff to network, but things have to be really hosed to stop you pushing some chars to a UART. > I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. e.g. syslog (RFC5424)? -e- You can even add some extra fields of your choosing if you so desire: https://tools.ietf.org/html/rfc5424#section-6.3 https://tools.ietf.org/html/rfc5424#section-6.3 > But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data. e.g. ELK, Graylog etc?
  - chrisweekly 8y ago
    lnav + mitmdump!
    - berti 8y ago
      lnav looks really neat. Thanks!
- kbenson 8y ago
  > Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for.
kbenson 8y ago
> Of course - printf(3) by definition "shall place output on the standard output stream stdout"[1]. If you want stderr or any other output stream, use fprintf(3). I reject your C-centric world for one of my own making. ;) # perldoc -f printf | head -n3 printf FILEHANDLE FORMAT, LIST printf FILEHANDLE printf FORMAT, LIST # perl -e 'printf STDERR "%0.2f\n", 2;' >/dev/null 2.00
- tincholio 8y ago
  he was quite specific in saying printf(3), which is defined by POSIX
  - kbenson 8y ago
    Yes, the reply was quite specific in rewriting printf to include the man page section, but the original comment did not.
coldtea 8y ago
This response managed to say very little and just give excuses for the current state of things. >Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output options. Web programming includes cli and server side tools (Node for one, JS testing tools, etc), has several first class logging SaaS and locally installed options, and even has stuff like the developer tools protocol, which allows one to debug Chrome running code in VS Code for example... >That's a common feature of dynamic type languages. That's merely an "ability", it's by no means a "common feature" in dynamic languages to have different output options in the example of e.g. console.table() (which itself is limited anyway). >Copying files to a remote host is easy with scp. That manual busywork is not what the parent asks for. >That's great if you have specific needs and a viewer for your complex data structures, but the only universal solution is text. You've just restated the problem -- only with a positive spin.

by pdkl95 8y ago

azinman2 8y ago

You're totally missing my point(s). Of course web programming is tied to the browser, but why does that mean debugging via logs has to be tied to whatever particular console is attached to where a program is running? Why can't I have a console.table() equivalent in Python, and Ruby, and C, and Go, and Java that all can render via a common protocol to any viewer that can handle it? By printf I didn't _literally_ mean printf -- I meant any logging type equivalent whether that IS printf or a built-in logging system. The point is there's no inter-op between them with any rich detail, which prohibits universal log viewers. When I say travel over the network, I don't mean scp. I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. That's the kind of portability required when you can't guarantee that complex display can be part of the same system that generated it -- that's a unique quality of web browsers. IT'S ABOUT THE PROTOCOL, NOT THE MECHANISM. Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data. Apple's Console.app is an elementary example of what I'm suggesting I'd like to see. Except I don't want it tied to the syslogs of an Apple device. I want every language/platform to be able to output to it in real-time. And for it's capabilities to be as rich or richer than what we have in the browser. We already have universal text editors like VIM/Emacs -- why can't we have universal log viewers?

berti 8y ago
"printf" will always have it's place, because when things are hosed, there's a good chance you can't push stuff to network, but things have to be really hosed to stop you pushing some chars to a UART. > I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. e.g. syslog (RFC5424)? -e- You can even add some extra fields of your choosing if you so desire: https://tools.ietf.org/html/rfc5424#section-6.3 https://tools.ietf.org/html/rfc5424#section-6.3 > But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data. e.g. ELK, Graylog etc?
- chrisweekly 8y ago
  lnav + mitmdump!
  - berti 8y ago
    lnav looks really neat. Thanks!
kbenson 8y ago
> Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for.

kbenson 8y ago

> Of course - printf(3) by definition "shall place output on the standard output stream stdout"[1]. If you want stderr or any other output stream, use fprintf(3). I reject your C-centric world for one of my own making. ;) # perldoc -f printf | head -n3 printf FILEHANDLE FORMAT, LIST printf FILEHANDLE printf FORMAT, LIST # perl -e 'printf STDERR "%0.2f\n", 2;' >/dev/null 2.00

tincholio 8y ago
he was quite specific in saying printf(3), which is defined by POSIX
- kbenson 8y ago
  Yes, the reply was quite specific in rewriting printf to include the man page section, but the original comment did not.

coldtea 8y ago

This response managed to say very little and just give excuses for the current state of things. >Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output options. Web programming includes cli and server side tools (Node for one, JS testing tools, etc), has several first class logging SaaS and locally installed options, and even has stuff like the developer tools protocol, which allows one to debug Chrome running code in VS Code for example... >That's a common feature of dynamic type languages. That's merely an "ability", it's by no means a "common feature" in dynamic languages to have different output options in the example of e.g. console.table() (which itself is limited anyway). >Copying files to a remote host is easy with scp. That manual busywork is not what the parent asks for. >That's great if you have specific needs and a viewer for your complex data structures, but the only universal solution is text. You've just restated the problem -- only with a positive spin.