Re: Would a logging framework make sense for PicoLisp

2014-04-12 Thread Henrik Sarvell
I'm glad they helped you.

Just fixed a bug or two, I had to Google to find out how to always display
the newest version on Bitbucket so finally, here is the link:
https://bitbucket.org/hsarvell/ext/src/tip/log.l?at=default

Apparently one has to replace the revision hash with tip.



On Sat, Apr 12, 2014 at 3:33 AM, andr...@itship.ch wrote:

 Hi guys

  Hi Andreas, can I put this in my ext lib:
  https://bitbucket.org/hsarvell/ext ?
 
  I will of course keep the head with your email and info etc

 Yes surely, I feel honored. Thank you for asking!
 By the way, let me thank you for your database tutorials on your blog,
 they helped a lot in the beginning.

  It seems that the earlier raw link was to that specific revision, this is
  better I hope:
 
 https://bitbucket.org/hsarvell/ext/src/0544acf09a6c162f685f28a2e8f2bef8eba23058/log.l?at=default

 Nice, thanks for the nice namespace example. Will introduce namespaces to
 my code now. Side question: Can namespaces be nested? e.g.
 lib~sublib~symbol?

  Sorry Jakob, I should have been more clear, derivative work with enough
  transformativeness is fair use:
  http://en.wikipedia.org/wiki/Transformativeness
 
  It seems that the earlier raw link was to that specific revision, this is
  better I hope:
 
 https://bitbucket.org/hsarvell/ext/src/0544acf09a6c162f685f28a2e8f2bef8eba23058/log.l?at=default
 
 
 
  On Sat, Apr 12, 2014 at 12:48 AM, Jakob Eriksson
  ja...@aurorasystems.euwrote:
 
  If it is derivative, you should ask.
 
  On April 11, 2014 7:07:25 PM CEST, Henrik Sarvell hsarv...@gmail.com
  wrote:
 
  I feel like I have changed the original now to such an extent that I
  don't have to ask anymore :-) It feels like a derivative work.
 
  However, attribution is kept in the source:
 
 https://bitbucket.org/hsarvell/ext/raw/b2516583e54a97c0e903dcb5b63b0b3cb8c1934a/log.l
 
  And here: https://bitbucket.org/hsarvell/ext
 
  Only difference in behaviour is that if you do for instance (setq
  *LogOn
  T) results will be unpredicable, it needs to be set to NIL or one of
  the
  four values, for instance (setq *LogOn 'debug).
 
  Enjoy!
 
 
 
  On Fri, Apr 11, 2014 at 9:28 PM, Henrik Sarvell
  hsarv...@gmail.comwrote:
 
  Hi Andreas, can I put this in my ext lib:
  https://bitbucket.org/hsarvell/ext ?
 
  I will of course keep the head with your email and info etc.
 
 
 
 
  On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz
  tjol...@gmail.comwrote:
 
  andr...@itship.ch writes:
 
  Hi Andreas,
 
   I'm not sure if I understand you correctly.
   You can use (log) in different ways, e.g.:
   (log just a message)
   (log 'debug variable x is x)
   (log 'warn folder size is reaching 1GB)
   (log 'error a fatal error occured)
  
   If (on *LogOn), all messages get printed.
   If (setq *LogOn 'warn), only warn and error messages (the 2 at
  bottom)
   will be printed.
   If (setq *LogOn 'error), only the last message will be printed.
 
  ok, I see, so its the programmers responsability to put 'warn and
  'error
  level statements in places that are only reached under some error
  condition and nowhere else.
 
   So far this system only handles messages which you explicitly send
   yourself with (log Type any ...). Error ouput from pil isn't
  getting
   handled, as I don't know how I could do that. Pil error messages
  can
  be
   redirected to a file with (err), but I don't see a way to get it
   redirected to a function...
  
   Does this answer your question?
 
  Yes, thanks!
 
   Thorsten Jolitz tjol...@gmail.com
   writes:
  
   after testing a bit more I have one question:
  
   It seems the levels 'warning and 'error unconditionally print
  their
   messages when *LogOn is set to them, but from my understanding
  these
   levels would eventually be turned-on in production code and thus
   should only print something when something goes wrong in the
  program
   execution.
  
   Would it be possible to only log messages from catched error with
  level
   'warning and try to log some system information when there is a
  real
   uncatched error with log-level 'error? So that level 'warning
  would
   become the default level for production code and nothing is
  printed
  as
   long as the program runs smoothly?
  
   --
   cheers,
   Thorsten
  
   --
   UNSUBSCRIBE:
   mailto:picolisp@software-lab.de?subject=Unsubscribe
  
  
  
  
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 
  --
  Sent from my Android device with K-9 Mail. Please excuse my brevity.
 
 
 



 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread Henrik Sarvell
Hi Andreas, can I put this in my ext lib: https://bitbucket.org/hsarvell/ext?

I will of course keep the head with your email and info etc.




On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz tjol...@gmail.com wrote:

 andr...@itship.ch writes:

 Hi Andreas,

  I'm not sure if I understand you correctly.
  You can use (log) in different ways, e.g.:
  (log just a message)
  (log 'debug variable x is x)
  (log 'warn folder size is reaching 1GB)
  (log 'error a fatal error occured)
 
  If (on *LogOn), all messages get printed.
  If (setq *LogOn 'warn), only warn and error messages (the 2 at bottom)
  will be printed.
  If (setq *LogOn 'error), only the last message will be printed.

 ok, I see, so its the programmers responsability to put 'warn and 'error
 level statements in places that are only reached under some error
 condition and nowhere else.

  So far this system only handles messages which you explicitly send
  yourself with (log Type any ...). Error ouput from pil isn't getting
  handled, as I don't know how I could do that. Pil error messages can be
  redirected to a file with (err), but I don't see a way to get it
  redirected to a function...
 
  Does this answer your question?

 Yes, thanks!

  Thorsten Jolitz tjol...@gmail.com
  writes:
 
  after testing a bit more I have one question:
 
  It seems the levels 'warning and 'error unconditionally print their
  messages when *LogOn is set to them, but from my understanding these
  levels would eventually be turned-on in production code and thus
  should only print something when something goes wrong in the program
  execution.
 
  Would it be possible to only log messages from catched error with level
  'warning and try to log some system information when there is a real
  uncatched error with log-level 'error? So that level 'warning would
  become the default level for production code and nothing is printed as
  long as the program runs smoothly?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE:
  mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread Henrik Sarvell
I feel like I have changed the original now to such an extent that I don't
have to ask anymore :-) It feels like a derivative work.

However, attribution is kept in the source:
https://bitbucket.org/hsarvell/ext/raw/b2516583e54a97c0e903dcb5b63b0b3cb8c1934a/log.l

And here: https://bitbucket.org/hsarvell/ext

Only difference in behaviour is that if you do for instance (setq *LogOn T)
results will be unpredicable, it needs to be set to NIL or one of the four
values, for instance (setq *LogOn 'debug).

Enjoy!



On Fri, Apr 11, 2014 at 9:28 PM, Henrik Sarvell hsarv...@gmail.com wrote:

 Hi Andreas, can I put this in my ext lib:
 https://bitbucket.org/hsarvell/ext ?

 I will of course keep the head with your email and info etc.




 On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz tjol...@gmail.comwrote:

 andr...@itship.ch writes:

 Hi Andreas,

  I'm not sure if I understand you correctly.
  You can use (log) in different ways, e.g.:
  (log just a message)
  (log 'debug variable x is x)
  (log 'warn folder size is reaching 1GB)
  (log 'error a fatal error occured)
 
  If (on *LogOn), all messages get printed.
  If (setq *LogOn 'warn), only warn and error messages (the 2 at bottom)
  will be printed.
  If (setq *LogOn 'error), only the last message will be printed.

 ok, I see, so its the programmers responsability to put 'warn and 'error
 level statements in places that are only reached under some error
 condition and nowhere else.

  So far this system only handles messages which you explicitly send
  yourself with (log Type any ...). Error ouput from pil isn't getting
  handled, as I don't know how I could do that. Pil error messages can be
  redirected to a file with (err), but I don't see a way to get it
  redirected to a function...
 
  Does this answer your question?

 Yes, thanks!

  Thorsten Jolitz tjol...@gmail.com
  writes:
 
  after testing a bit more I have one question:
 
  It seems the levels 'warning and 'error unconditionally print their
  messages when *LogOn is set to them, but from my understanding these
  levels would eventually be turned-on in production code and thus
  should only print something when something goes wrong in the program
  execution.
 
  Would it be possible to only log messages from catched error with level
  'warning and try to log some system information when there is a real
  uncatched error with log-level 'error? So that level 'warning would
  become the default level for production code and nothing is printed as
  long as the program runs smoothly?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE:
  mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe





Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread Jakob Eriksson
If it is derivative, you should ask. 

On April 11, 2014 7:07:25 PM CEST, Henrik Sarvell hsarv...@gmail.com wrote:
I feel like I have changed the original now to such an extent that I
don't
have to ask anymore :-) It feels like a derivative work.

However, attribution is kept in the source:
https://bitbucket.org/hsarvell/ext/raw/b2516583e54a97c0e903dcb5b63b0b3cb8c1934a/log.l

And here: https://bitbucket.org/hsarvell/ext

Only difference in behaviour is that if you do for instance (setq
*LogOn T)
results will be unpredicable, it needs to be set to NIL or one of the
four
values, for instance (setq *LogOn 'debug).

Enjoy!



On Fri, Apr 11, 2014 at 9:28 PM, Henrik Sarvell hsarv...@gmail.com
wrote:

 Hi Andreas, can I put this in my ext lib:
 https://bitbucket.org/hsarvell/ext ?

 I will of course keep the head with your email and info etc.




 On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz
tjol...@gmail.comwrote:

 andr...@itship.ch writes:

 Hi Andreas,

  I'm not sure if I understand you correctly.
  You can use (log) in different ways, e.g.:
  (log just a message)
  (log 'debug variable x is x)
  (log 'warn folder size is reaching 1GB)
  (log 'error a fatal error occured)
 
  If (on *LogOn), all messages get printed.
  If (setq *LogOn 'warn), only warn and error messages (the 2 at
bottom)
  will be printed.
  If (setq *LogOn 'error), only the last message will be printed.

 ok, I see, so its the programmers responsability to put 'warn and
'error
 level statements in places that are only reached under some error
 condition and nowhere else.

  So far this system only handles messages which you explicitly send
  yourself with (log Type any ...). Error ouput from pil isn't
getting
  handled, as I don't know how I could do that. Pil error messages
can be
  redirected to a file with (err), but I don't see a way to get it
  redirected to a function...
 
  Does this answer your question?

 Yes, thanks!

  Thorsten Jolitz tjol...@gmail.com
  writes:
 
  after testing a bit more I have one question:
 
  It seems the levels 'warning and 'error unconditionally print
their
  messages when *LogOn is set to them, but from my understanding
these
  levels would eventually be turned-on in production code and thus
  should only print something when something goes wrong in the
program
  execution.
 
  Would it be possible to only log messages from catched error with
level
  'warning and try to log some system information when there is a
real
  uncatched error with log-level 'error? So that level 'warning
would
  become the default level for production code and nothing is
printed as
  long as the program runs smoothly?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE:
  mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe




-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread Henrik Sarvell
Sorry Jakob, I should have been more clear, derivative work with enough
transformativeness is fair use:
http://en.wikipedia.org/wiki/Transformativeness

It seems that the earlier raw link was to that specific revision, this is
better I hope:
https://bitbucket.org/hsarvell/ext/src/0544acf09a6c162f685f28a2e8f2bef8eba23058/log.l?at=default



On Sat, Apr 12, 2014 at 12:48 AM, Jakob Eriksson ja...@aurorasystems.euwrote:

 If it is derivative, you should ask.

 On April 11, 2014 7:07:25 PM CEST, Henrik Sarvell hsarv...@gmail.com
 wrote:

 I feel like I have changed the original now to such an extent that I
 don't have to ask anymore :-) It feels like a derivative work.

 However, attribution is kept in the source:
 https://bitbucket.org/hsarvell/ext/raw/b2516583e54a97c0e903dcb5b63b0b3cb8c1934a/log.l

 And here: https://bitbucket.org/hsarvell/ext

 Only difference in behaviour is that if you do for instance (setq *LogOn
 T) results will be unpredicable, it needs to be set to NIL or one of the
 four values, for instance (setq *LogOn 'debug).

 Enjoy!



 On Fri, Apr 11, 2014 at 9:28 PM, Henrik Sarvell hsarv...@gmail.comwrote:

 Hi Andreas, can I put this in my ext lib:
 https://bitbucket.org/hsarvell/ext ?

 I will of course keep the head with your email and info etc.




 On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz tjol...@gmail.comwrote:

 andr...@itship.ch writes:

 Hi Andreas,

  I'm not sure if I understand you correctly.
  You can use (log) in different ways, e.g.:
  (log just a message)
  (log 'debug variable x is x)
  (log 'warn folder size is reaching 1GB)
  (log 'error a fatal error occured)
 
  If (on *LogOn), all messages get printed.
  If (setq *LogOn 'warn), only warn and error messages (the 2 at bottom)
  will be printed.
  If (setq *LogOn 'error), only the last message will be printed.

 ok, I see, so its the programmers responsability to put 'warn and 'error
 level statements in places that are only reached under some error
 condition and nowhere else.

  So far this system only handles messages which you explicitly send
  yourself with (log Type any ...). Error ouput from pil isn't getting
  handled, as I don't know how I could do that. Pil error messages can
 be
  redirected to a file with (err), but I don't see a way to get it
  redirected to a function...
 
  Does this answer your question?

 Yes, thanks!

  Thorsten Jolitz tjol...@gmail.com
  writes:
 
  after testing a bit more I have one question:
 
  It seems the levels 'warning and 'error unconditionally print their
  messages when *LogOn is set to them, but from my understanding these
  levels would eventually be turned-on in production code and thus
  should only print something when something goes wrong in the program
  execution.
 
  Would it be possible to only log messages from catched error with
 level
  'warning and try to log some system information when there is a real
  uncatched error with log-level 'error? So that level 'warning would
  become the default level for production code and nothing is printed
 as
  long as the program runs smoothly?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE:
  mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe




 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread andreas
Hi guys

 Hi Andreas, can I put this in my ext lib:
 https://bitbucket.org/hsarvell/ext ?

 I will of course keep the head with your email and info etc

Yes surely, I feel honored. Thank you for asking!
By the way, let me thank you for your database tutorials on your blog,
they helped a lot in the beginning.

 It seems that the earlier raw link was to that specific revision, this is
 better I hope:
 https://bitbucket.org/hsarvell/ext/src/0544acf09a6c162f685f28a2e8f2bef8eba23058/log.l?at=default

Nice, thanks for the nice namespace example. Will introduce namespaces to
my code now. Side question: Can namespaces be nested? e.g.
lib~sublib~symbol?

 Sorry Jakob, I should have been more clear, derivative work with enough
 transformativeness is fair use:
 http://en.wikipedia.org/wiki/Transformativeness

 It seems that the earlier raw link was to that specific revision, this is
 better I hope:
 https://bitbucket.org/hsarvell/ext/src/0544acf09a6c162f685f28a2e8f2bef8eba23058/log.l?at=default



 On Sat, Apr 12, 2014 at 12:48 AM, Jakob Eriksson
 ja...@aurorasystems.euwrote:

 If it is derivative, you should ask.

 On April 11, 2014 7:07:25 PM CEST, Henrik Sarvell hsarv...@gmail.com
 wrote:

 I feel like I have changed the original now to such an extent that I
 don't have to ask anymore :-) It feels like a derivative work.

 However, attribution is kept in the source:
 https://bitbucket.org/hsarvell/ext/raw/b2516583e54a97c0e903dcb5b63b0b3cb8c1934a/log.l

 And here: https://bitbucket.org/hsarvell/ext

 Only difference in behaviour is that if you do for instance (setq
 *LogOn
 T) results will be unpredicable, it needs to be set to NIL or one of
 the
 four values, for instance (setq *LogOn 'debug).

 Enjoy!



 On Fri, Apr 11, 2014 at 9:28 PM, Henrik Sarvell
 hsarv...@gmail.comwrote:

 Hi Andreas, can I put this in my ext lib:
 https://bitbucket.org/hsarvell/ext ?

 I will of course keep the head with your email and info etc.




 On Mon, Mar 10, 2014 at 6:06 PM, Thorsten Jolitz
 tjol...@gmail.comwrote:

 andr...@itship.ch writes:

 Hi Andreas,

  I'm not sure if I understand you correctly.
  You can use (log) in different ways, e.g.:
  (log just a message)
  (log 'debug variable x is x)
  (log 'warn folder size is reaching 1GB)
  (log 'error a fatal error occured)
 
  If (on *LogOn), all messages get printed.
  If (setq *LogOn 'warn), only warn and error messages (the 2 at
 bottom)
  will be printed.
  If (setq *LogOn 'error), only the last message will be printed.

 ok, I see, so its the programmers responsability to put 'warn and
 'error
 level statements in places that are only reached under some error
 condition and nowhere else.

  So far this system only handles messages which you explicitly send
  yourself with (log Type any ...). Error ouput from pil isn't
 getting
  handled, as I don't know how I could do that. Pil error messages
 can
 be
  redirected to a file with (err), but I don't see a way to get it
  redirected to a function...
 
  Does this answer your question?

 Yes, thanks!

  Thorsten Jolitz tjol...@gmail.com
  writes:
 
  after testing a bit more I have one question:
 
  It seems the levels 'warning and 'error unconditionally print
 their
  messages when *LogOn is set to them, but from my understanding
 these
  levels would eventually be turned-on in production code and thus
  should only print something when something goes wrong in the
 program
  execution.
 
  Would it be possible to only log messages from catched error with
 level
  'warning and try to log some system information when there is a
 real
  uncatched error with log-level 'error? So that level 'warning
 would
  become the default level for production code and nothing is
 printed
 as
  long as the program runs smoothly?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE:
  mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 
 

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe




 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.






-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-04-11 Thread Alexander Burger
Hi Andreas,

On Fri, Apr 11, 2014 at 08:33:22PM -, andr...@itship.ch wrote:
 Nice, thanks for the nice namespace example. Will introduce namespaces to
 my code now. Side question: Can namespaces be nested? e.g.
 lib~sublib~symbol?

Yes.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-03-10 Thread Thorsten Jolitz
andr...@itship.ch writes:

Hi Andreas,

 I crafted a tiny logging tool consisting of one function and some globals.
 I'm new to picolisp (and its my first lisp), so feedback and advices are
 greatly appreciated.

great, thank you, I just did a quick first test and it worked:

,-
| : (setq *LogOn T)
| - T
| : INFO|Test of new logging framework
`-

I think this will be quite useful for me, even if its not 100pc
compatible with PicoLisp philosophy, and when I first looked at the code
I thought the file must be incomplete because it was so small ;)

-- 
cheers,
Thorsten

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-03-10 Thread Thorsten Jolitz
Thorsten Jolitz tjol...@gmail.com
writes:

 andr...@itship.ch writes:

 Hi Andreas,

 I crafted a tiny logging tool consisting of one function and some
 globals.
 I'm new to picolisp (and its my first lisp), so feedback and advices are
 greatly appreciated.

 great, thank you, I just did a quick first test and it worked:

 ,-
 | : (setq *LogOn T)
 | - T
 | : INFO|Test of new logging framework
 `-

 I think this will be quite useful for me, even if its not 100pc
 compatible with PicoLisp philosophy, and when I first looked at the code
 I thought the file must be incomplete because it was so small ;)

after testing a bit more I have one question:

It seems the levels 'warning and 'error unconditionally print their
messages when *LogOn is set to them, but from my understanding these
levels would eventually be turned-on in production code and thus
should only print something when something goes wrong in the program
execution.

Would it be possible to only log messages from catched error with level
'warning and try to log some system information when there is a real
uncatched error with log-level 'error? So that level 'warning would
become the default level for production code and nothing is printed as
long as the program runs smoothly?

-- 
cheers,
Thorsten

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-03-10 Thread andreas
Hi Thorsten

I'm not sure if I understand you correctly.
You can use (log) in different ways, e.g.:
(log just a message)
(log 'debug variable x is x)
(log 'warn folder size is reaching 1GB)
(log 'error a fatal error occured)

If (on *LogOn), all messages get printed.
If (setq *LogOn 'warn), only warn and error messages (the 2 at bottom)
will be printed.
If (setq *LogOn 'error), only the last message will be printed.

So you can put (log 'debug ...) all over the place in the code, but
deactivate them during production by setting (setq *LogOn 'error) at start
of your program.
You can also reactivate debug just in parts of code, by declaring the
variables locally, e.g.:

(setq *LogOn 'warn)
(setq *LogW +/var/log/pilapp.warning.log)
(setq *LogE +/var/log/pilapp.error.log)
# normal programm, only print warnings and errors
(log 'debug blabla) # ignored, because (= *LogOn 'warn)
..
(let *LogOn T
  (log 'debug currently testing this code) # not ignored
  (somestuff)
  (somemorestuff) )
..
(log 'debug morebla) # ignored again

So far this system only handles messages which you explicitly send
yourself with (log Type any ...). Error ouput from pil isn't getting
handled, as I don't know how I could do that. Pil error messages can be
redirected to a file with (err), but I don't see a way to get it
redirected to a function...

Does this answer your question?
Else join the IRC if you can ( #picolisp on freenode.net), I'm currently
online.

Cheers,
Andreas


 Thorsten Jolitz tjol...@gmail.com
 writes:

 after testing a bit more I have one question:

 It seems the levels 'warning and 'error unconditionally print their
 messages when *LogOn is set to them, but from my understanding these
 levels would eventually be turned-on in production code and thus
 should only print something when something goes wrong in the program
 execution.

 Would it be possible to only log messages from catched error with level
 'warning and try to log some system information when there is a real
 uncatched error with log-level 'error? So that level 'warning would
 become the default level for production code and nothing is printed as
 long as the program runs smoothly?

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe




-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-03-10 Thread Thorsten Jolitz
andr...@itship.ch writes:

Hi Andreas,

 I'm not sure if I understand you correctly.
 You can use (log) in different ways, e.g.:
 (log just a message)
 (log 'debug variable x is x)
 (log 'warn folder size is reaching 1GB)
 (log 'error a fatal error occured)

 If (on *LogOn), all messages get printed.
 If (setq *LogOn 'warn), only warn and error messages (the 2 at bottom)
 will be printed.
 If (setq *LogOn 'error), only the last message will be printed.

ok, I see, so its the programmers responsability to put 'warn and 'error
level statements in places that are only reached under some error
condition and nowhere else. 

 So far this system only handles messages which you explicitly send
 yourself with (log Type any ...). Error ouput from pil isn't getting
 handled, as I don't know how I could do that. Pil error messages can be
 redirected to a file with (err), but I don't see a way to get it
 redirected to a function...

 Does this answer your question?

Yes, thanks!

 Thorsten Jolitz tjol...@gmail.com
 writes:

 after testing a bit more I have one question:

 It seems the levels 'warning and 'error unconditionally print their
 messages when *LogOn is set to them, but from my understanding these
 levels would eventually be turned-on in production code and thus
 should only print something when something goes wrong in the program
 execution.

 Would it be possible to only log messages from catched error with level
 'warning and try to log some system information when there is a real
 uncatched error with log-level 'error? So that level 'warning would
 become the default level for production code and nothing is printed as
 long as the program runs smoothly?

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE:
 mailto:picolisp@software-lab.de?subject=Unsubscribe





-- 
cheers,
Thorsten

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-03-09 Thread andreas
Hi List

I crafted a tiny logging tool consisting of one function and some globals.
I'm new to picolisp (and its my first lisp), so feedback and advices are
greatly appreciated.

The thing is mainly meant for debugging or logging in server apps.

Code: http://beneroth.ch/pil/log.l

Features:
- turn logging on and off (globally or locally)
- different logging levels (debug, info, warning, error)
- output goes to stdout or files (configurable for each log level
individually)
- hook to dynamically change output channel/file
- flavour output with timestamp and/or PID

ToTest:
- not sure if parallel writting to same file could be a problem.
  I would assume with each call of (out +file) the file gets opened,
written, and closed, so first come first served. Didn't test yet.

Other ideas:
- not sure how my function is in spirit with the standard picolisp
- not sure how this is combatible to the builtin logging functions like
(err) and (trace)
- it would be nice if (err) output could be redirected to another function,
  but I think its not possible. maybe if logging would be done in another
process, and stdout from the (debugged) process redirect to the logging
process?

All in all, I was very surprised how short this code turned out.
In other languages this would be much larger, or not even possible easily,
e.g. to reconfigure settings for some local parts of code.

cheers,
Andreas


 Hi List,

 sometimes I start putting a lot of (maybe too many) 'msg calls in my
 code for debugging purposes, what then triggers memories of logging
 frameworks for Java I once read about.

 Would it make sense to add such a logging framework to the language as a
 kind of third debugging tool (besides trace and debug)? I was thinking
 about something along the line of

  - a new global variable *Log
  - two new functions 'log and 'unlog
  - an equivalent to ! as debugging breakpoint (e.g. § or whatever as
logging point)

 *Log would then be NIL or one of several logging levels
 (e.g. 1,2,3). (log func) would then put § before all expressions of a
 function, (unlog func) remove them. Depending on the logging level, §
 would do nothing or, e.g., print the expression and the results of
 what (e) and (d) do during debugging, and maybe all variables with
 their actual values in that expression.

 What do you think?

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe




-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-27 Thread Alexander Burger
Hi Thorsten,

 but it would be nice to have a function pair (log and unlog) that does
 all this: 
 
  - trace the function
  - redirect the output of trace to a file too
  - untrace and go back to default stderr
 
 something like this
 
 #+begin_src picolisp
   (de log (Func)
  (err (tmp log)
 (trace Func)
 (pass Func) ) )  
 #+end_src
 
 but this does not work unfortunately...

How about this?

   (de log (File Funs . Prg)
  (err File
 (prog2
(mapc trace Funs)
(run Prg 1)
(mapc untrace Funs) ) ) )

It can be used like

   (log +myLogFile '(gt0 le0 + - * /)
  (myProgram
 (myFun
(foo (bar ..)) ) ) )

This example traces all calls to the comparison and arithmetic functions
in the list while 'myProgram' is running.

The + is to append the output to the log file. Without it, myLogFile
will be overwritten from scratch each time.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-27 Thread Alexander Burger
Hi Thorsten,

 could it be used to optionally log a whole web-application by wrapping
 the main function as 'myProgram' into the log function?
 
 (de main ()
(call 'mkdir -p *Pool *Blob)
(pool *Pool *Dbs *Jnl)
(unless (seq *DB)
   (load app/init.l) ) ... )
 
 (de logMain ()
(log ...
  (main) ) )
 
 and then start with 
 
 ,---
 | : ./pil app/main.l -main -go +
 `---
 
 or
  
 ,--
 | : ./pil app/main.l -logMain -go +
 `--
 
 for turning logging off or on? 

Yes, this should work fine.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Henrik Sarvell
Sometimes it's also nice to be able to get everything in a file, not
just printed, would be nice if it could have that option.

On Tue, Feb 25, 2014 at 6:50 PM, Thorsten Jolitz tjol...@gmail.com wrote:

 Hi List,

 sometimes I start putting a lot of (maybe too many) 'msg calls in my
 code for debugging purposes, what then triggers memories of logging
 frameworks for Java I once read about.

 Would it make sense to add such a logging framework to the language as a
 kind of third debugging tool (besides trace and debug)? I was thinking
 about something along the line of

  - a new global variable *Log
  - two new functions 'log and 'unlog
  - an equivalent to ! as debugging breakpoint (e.g. § or whatever as
logging point)

 *Log would then be NIL or one of several logging levels
 (e.g. 1,2,3). (log func) would then put § before all expressions of a
 function, (unlog func) remove them. Depending on the logging level, §
 would do nothing or, e.g., print the expression and the results of
 what (e) and (d) do during debugging, and maybe all variables with
 their actual values in that expression.

 What do you think?

 --
 cheers,
 Thorsten

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Joe Bogner
I like the idea of something simple and possibly built-in. However, would
it be possible to implement as a function that wraps definitions with a
redef and adds the logging?

http://software-lab.de/doc/refR.html#redef


On Tue, Feb 25, 2014 at 9:20 AM, Henrik Sarvell hsarv...@gmail.com wrote:

 Sometimes it's also nice to be able to get everything in a file, not
 just printed, would be nice if it could have that option.

 On Tue, Feb 25, 2014 at 6:50 PM, Thorsten Jolitz tjol...@gmail.com
 wrote:
 
  Hi List,
 
  sometimes I start putting a lot of (maybe too many) 'msg calls in my
  code for debugging purposes, what then triggers memories of logging
  frameworks for Java I once read about.
 
  Would it make sense to add such a logging framework to the language as a
  kind of third debugging tool (besides trace and debug)? I was thinking
  about something along the line of
 
   - a new global variable *Log
   - two new functions 'log and 'unlog
   - an equivalent to ! as debugging breakpoint (e.g. § or whatever as
 logging point)
 
  *Log would then be NIL or one of several logging levels
  (e.g. 1,2,3). (log func) would then put § before all expressions of a
  function, (unlog func) remove them. Depending on the logging level, §
  would do nothing or, e.g., print the expression and the results of
  what (e) and (d) do during debugging, and maybe all variables with
  their actual values in that expression.
 
  What do you think?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe



Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Henrik Sarvell
Yes AFAIK all of Thorsten's description should be possible to
implement without touching any code that needs to be compiled. So code
away, no need to ask Alex for anything! ;-)

On Tue, Feb 25, 2014 at 9:35 PM, Joe Bogner joebog...@gmail.com wrote:
 I like the idea of something simple and possibly built-in. However, would it
 be possible to implement as a function that wraps definitions with a redef
 and adds the logging?

 http://software-lab.de/doc/refR.html#redef


 On Tue, Feb 25, 2014 at 9:20 AM, Henrik Sarvell hsarv...@gmail.com wrote:

 Sometimes it's also nice to be able to get everything in a file, not
 just printed, would be nice if it could have that option.

 On Tue, Feb 25, 2014 at 6:50 PM, Thorsten Jolitz tjol...@gmail.com
 wrote:
 
  Hi List,
 
  sometimes I start putting a lot of (maybe too many) 'msg calls in my
  code for debugging purposes, what then triggers memories of logging
  frameworks for Java I once read about.
 
  Would it make sense to add such a logging framework to the language as a
  kind of third debugging tool (besides trace and debug)? I was thinking
  about something along the line of
 
   - a new global variable *Log
   - two new functions 'log and 'unlog
   - an equivalent to ! as debugging breakpoint (e.g. § or whatever as
 logging point)
 
  *Log would then be NIL or one of several logging levels
  (e.g. 1,2,3). (log func) would then put § before all expressions of a
  function, (unlog func) remove them. Depending on the logging level, §
  would do nothing or, e.g., print the expression and the results of
  what (e) and (d) do during debugging, and maybe all variables with
  their actual values in that expression.
 
  What do you think?
 
  --
  cheers,
  Thorsten
 
  --
  UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Alexander Burger
On Tue, Feb 25, 2014 at 09:35:05AM -0500, Joe Bogner wrote:
 I like the idea of something simple and possibly built-in. However, would
 it be possible to implement as a function that wraps definitions with a
 redef and adds the logging?

This might possibly done with 'daemon'. Not really a wrap, as it adds
only to the beginning of a function, but if you want entry _and_ exit
info we have 'trace' already.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Alexander Burger
On Tue, Feb 25, 2014 at 05:01:21PM +0100, Alexander Burger wrote:
 One simple way is to use 'err' around your program to redirect standard
 error
 
(err myLog.txt
   (main) )
 
 and then use the normal 'trace' and 'msg' functions which print to
 standard error.

or, of course, start the whole program with redirection:

   $ pil myProgram.l ... -main ... +  2err
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Would a logging framework make sense for PicoLisp

2014-02-25 Thread Thorsten Jolitz
Alexander Burger a...@software-lab.de writes:

 On Tue, Feb 25, 2014 at 05:01:21PM +0100, Alexander Burger wrote:
 One simple way is to use 'err' around your program to redirect standard
 error
 
(err myLog.txt
   (main) )
 
 and then use the normal 'trace' and 'msg' functions which print to
 standard error.

 or, of course, start the whole program with redirection:

$ pil myProgram.l ... -main ... +  2err

but it would be nice to have a function pair (log and unlog) that does
all this: 

 - trace the function
 - redirect the output of trace to a file too
 - untrace and go back to default stderr

something like this

#+begin_src picolisp
  (de log (Func)
 (err (tmp log)
(trace Func)
(pass Func) ) )  
#+end_src

but this does not work unfortunately...

-- 
cheers,
Thorsten

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe