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.eu>wrote: > > > >> 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.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 > >>>>> > >>>> > >>>> > >>> > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >> > > > > > > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >