Re: Build problem on Mac OS X 10.9.2
Hi Alex, On 9. Apr, 2014, at 16:53, Alexander Burger a...@software-lab.de wrote: Hi Jon, .. I have investigated a bit further, and this build problem (build 32-bit on OSX 10.8 and 10.9) is not as simple to solve as I first thought. It turns out that even gcc is clang/LLVM stuff now. WTF! One may have to “brew install” old gcc, but I am not too eager to do that (yet). I’ll try to build a fresh 32-bit PicoLisp using OSX 10.6 at home, and see if it runs well under 10.8/10.9 … I see. Too bad :( - Alex Building on 10.6 and running under 10.8/10.9 was no problem. However, today I found a solution for building on 10.8/10.9 as well. It involves re-installing the old Apple gcc 4.2. I’ve tested it this far on 10.8, building 32-bit PicoLisp v. 3.1.6.4 C, and it works. Here’s Paul Crawford’s description: https://coderwall.com/p/lqpp8w The sun is shining again. ;-) (Hope this message won’t be base64’ed …) /Jon-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Build problem on Mac OS X 10.9.2
Hi Jon, Building on 10.6 and running under 10.8/10.9 was no problem. However, today I found a solution for building on 10.8/10.9 as well. It involves re-installing the old Apple gcc 4.2. I’ve tested it this far on 10.8, building 32-bit PicoLisp v. 3.1.6.4 C, and it works. Here’s Paul Crawford’s description: https://coderwall.com/p/lqpp8w Cool! :) Still, I can't understand why clang doesn't support variable-sized structures. The sun is shining again. ;-) (Hope this message won’t be base64’ed …) No, it is perfect! :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Would a logging framework make sense for PicoLisp
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
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
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
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
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
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
