Subscribe
Hello Alexander Williams :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: catching environment during manual (eval)
Hi Alex, wow, thanks for advice! Seems like I misunderstood (throw) purpose. I thought that "thrown" symbols are somewhat similar to custom exception classes in OOP languages. Actually, yeah, working with plain strings for raising logic exception is much more convinient :) > Hmm, sorry, I'm getting confused ;) Many variations of similar pieces of code. > I'm not sure exactly for which purpose you did all these tests. I tried to find edge-case where my manual evaluated function is failing and I'm still not sure why. OK, it does not matter actually now, because you pointed to more simplified solution. Many thanks for your answers and your patience. Soon I will fix this issue in pgint.l . Best regards, Nail. вс, 20 янв. 2019 г. в 19:40, Alexander Burger : > Hi Abel, > > On Sun, Jan 20, 2019 at 02:40:58PM +0300, Abel Normand wrote: > > I did some tests and I am feeling confused atm. > > ... > > (de pg-trans X > >(run X 1) ) > > So 'pg-trans' is equivalent to plain 'run'. > > > > (de execute-eval @ > >(mapcar eval (rest)) ) > > This function evaluates its arguments twice. It is called after *all* > arguments > are evaluated and are available via (next), (rest) etc. It then builds a > list of > all these results with (rest), then maps over this list 'eval'uating the > values > a second time. > > Thus, > >> [execute-eval >>'(assert-throws 'myerr >>(pg-trans (myerr-fun)) ) > > such a value after the first evaluation is the list > >(assert-throws 'myerr (pg-trans (myerr-fun))) > > which upon second evaluation executes (myerr-fun). > > > > (de execute-run X > >(run X 1) ) > > 'execute-run' is a plain 'run' again. > > > Hmm, sorry, I'm getting confused ;) Many variations of similar pieces of > code. > I'm not sure exactly for which purpose you did all these tests. > > > > So its seems like unevaluated fargs always keep track of their > environment > > and work as intended. > > Which part of them did you suspect not to work as intended? > > > > Then I do not understand my issue in tests of pgint.l in one specific > case > > when I have to test exception thrown inside of (pg-trans). When I write > > code that *will* throw and exception and I run it outside of > > aw/picolisp-unit (execute) function it is catched and treated as > intended. > > But when I run corrupted (pg-trans ...) *inside* of (execute) function it > > stops with "pg-db-err -- Tag not found". > > I'm lost a bit where exactly it went wrong. But the reason must surely be > a case > where a (throw 'pg-db-err) is done outside a matching 'catch' environment
Re: catching environment during manual (eval)
Hi Abel,
On Sun, Jan 20, 2019 at 02:40:58PM +0300, Abel Normand wrote:
> I did some tests and I am feeling confused atm.
> ...
> (de pg-trans X
>(run X 1) )
So 'pg-trans' is equivalent to plain 'run'.
> (de execute-eval @
>(mapcar eval (rest)) )
This function evaluates its arguments twice. It is called after *all* arguments
are evaluated and are available via (next), (rest) etc. It then builds a list of
all these results with (rest), then maps over this list 'eval'uating the values
a second time.
Thus,
> [execute-eval
>'(assert-throws 'myerr
>(pg-trans (myerr-fun)) )
such a value after the first evaluation is the list
(assert-throws 'myerr (pg-trans (myerr-fun)))
which upon second evaluation executes (myerr-fun).
> (de execute-run X
>(run X 1) )
'execute-run' is a plain 'run' again.
Hmm, sorry, I'm getting confused ;) Many variations of similar pieces of code.
I'm not sure exactly for which purpose you did all these tests.
> So its seems like unevaluated fargs always keep track of their environment
> and work as intended.
Which part of them did you suspect not to work as intended?
> Then I do not understand my issue in tests of pgint.l in one specific case
> when I have to test exception thrown inside of (pg-trans). When I write
> code that *will* throw and exception and I run it outside of
> aw/picolisp-unit (execute) function it is catched and treated as intended.
> But when I run corrupted (pg-trans ...) *inside* of (execute) function it
> stops with "pg-db-err -- Tag not found".
I'm lost a bit where exactly it went wrong. But the reason must surely be a case
where a (throw 'pg-db-err) is done outside a matching 'catch' environment.
> But when yesterday I tried to rewrite (execute) to use (run) for evaluating
> fargs I met the same error, surprisingly.
I would single step through the code with (debug 'fun) or manually placing '!'
breakpoints and looking at the environments of the breakpoints in the
breakpoint's REPL with (bt) etc.
> Probably Im missing something?
Not sure. I think your setup is too involved and over-abstacted.
Also, in general, I would not recommend
(catch 'sym
...
(throw 'sym ..)
... )
for *error* handling. Traditionally, catch/throw in Lisp is for non-local
*jumps*, not so much for errors or exceptions.
In PicoLisp it is more natural to let the system issue implicit errors, or issue
them explicitly with (quit "Message" Value), and then let the application code
do with them whatever it wants, or to catch them with
(catch '("Message")
...
or
(catch '("Message1" "Message2" "Message3")
...
or even
(catch '("")
...
to catch them *all*.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: picolisp and raspbian
Original Message On Jan 20, 2019, 6:54 PM, PositronPro wrote: You can try M-x Term for a terminal emulator. then run pil + and use the documentaion (works fine with w3m for me) It's M-x term(with lowercase t) PositronPro
Re: picolisp and raspbian
Yes, this and issues with very long line hanging emacs gave up using inferior picolisp mode for anything serious. You can try M-x Term for a terminal emulator. then run pil + and use the documentaion (works fine with w3m for me) choose bash for shell if prompted, fish has some issues... PositronPro Original Message On Jan 20, 2019, 6:28 PM, Jean-Christophe Helary wrote: > My elder son gave (lent?) me a screen so I don't have to ssh to the raspberry > pi anymore. (Which may not be a blessing in the end...) > > So, I have a crappy Buffalo keyboard, a non-x setting on my first generation > RP and I'm using screen/byobu to manage a number of terminal windows. > > For now, I have emacs and an inferior picolisp process. For some reason when > I was running the command from the menu I had an error saying that > /usr/lib/picolisp/bin/plmod did not exist, which was true, but I checked the > elisp code and could not find the place where that was called. So I decided > to run M-x run-picolisp and it was nice enough to ask me which command I > really wanted to run. > > Now, regarding the documentation, there does not seem to be a way to call it > from the picolisp-mode buffer. I tried the menu, I tried M-x picolisp-... to > see if there was a "document function at point" or something, to no avail. So > I'm left to open it in Lynx in a separate terminal, which is sub-optimal, > especially since emacs' w3 has a real weird way to render it... > > I'm currently trying the Picolisp Application Development chapter, which is a > nice way to walk through real picolisp code. > > So far, so good, but running 100% in text mode is, well, interesting, and I > thought I was not a mouse person... > > Jean-Christophe Helary > --- > http://mac4translators.blogspot.com @brandelune > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
picolisp and raspbian
My elder son gave (lent?) me a screen so I don't have to ssh to the raspberry pi anymore. (Which may not be a blessing in the end...) So, I have a crappy Buffalo keyboard, a non-x setting on my first generation RP and I'm using screen/byobu to manage a number of terminal windows. For now, I have emacs and an inferior picolisp process. For some reason when I was running the command from the menu I had an error saying that /usr/lib/picolisp/bin/plmod did not exist, which was true, but I checked the elisp code and could not find the place where that was called. So I decided to run M-x run-picolisp and it was nice enough to ask me which command I really wanted to run. Now, regarding the documentation, there does not seem to be a way to call it from the picolisp-mode buffer. I tried the menu, I tried M-x picolisp-... to see if there was a "document function at point" or something, to no avail. So I'm left to open it in Lynx in a separate terminal, which is sub-optimal, especially since emacs' w3 has a real weird way to render it... I'm currently trying the Picolisp Application Development chapter, which is a nice way to walk through real picolisp code. So far, so good, but running 100% in text mode is, well, interesting, and I thought I was not a mouse person... Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: catching environment during manual (eval)
I did some tests and I am feeling confused atm. ``` (de pg-trans X (run X 1) ) (de execute-eval @ (mapcar eval (rest)) ) (de execute-run X (run X 1) ) (de assert-throws (Type . Prg) (prinl (catch Type (eval Prg))) ) (de assert-throws-q (Type Prg) (prinl (catch Type (eval Prg))) ) (de assert-throws-t Prg (prinl (catch T (eval Prg))) ) (de assert-throws-myerr Prg (prinl (catch 'myerr (eval Prg))) ) (de myerr-fun () (throw 'myerr "EXIT") ) (prinl "EXECUTE EVAL") [execute-eval '(assert-throws 'myerr (pg-trans (myerr-fun)) ) '(assert-throws-q 'myerr '(pg-trans (myerr-fun)) ) '(assert-throws-t (pg-trans (myerr-fun)) ) '(assert-throws-myerr (pg-trans (myerr-fun)) )] (prinl "EXECUTE RUN") [execute-run (assert-throws 'myerr (pg-trans (myerr-fun)) ) (assert-throws-q 'myerr '(pg-trans (myerr-fun)) ) (assert-throws-t (pg-trans (myerr-fun)) ) (assert-throws-myerr (pg-trans (myerr-fun)) )] (bye) ``` ``` -> [abel@abel-pc picolisp-playbook]$ pil uneval-fargs.l + EXECUTE EVAL EXIT EXIT EXIT EXIT EXECUTE RUN EXIT EXIT EXIT EXIT ``` So its seems like unevaluated fargs always keep track of their environment and work as intended. Then I do not understand my issue in tests of pgint.l in one specific case when I have to test exception thrown inside of (pg-trans). When I write code that *will* throw and exception and I run it outside of aw/picolisp-unit (execute) function it is catched and treated as intended. But when I run corrupted (pg-trans ...) *inside* of (execute) function it stops with "pg-db-err -- Tag not found". At first I thought that the cause of this error in quoting requirement for test-cases. So in order to run test cases you have to run: ``` [execute '(assert-t ...) ] ``` Execute function looks like this: ``` [de execute @ (mapcar eval (randomize (rest) ] ``` But when yesterday I tried to rewrite (execute) to use (run) for evaluating fargs I met the same error, surprisingly. Then I thought that the case probably with (assert-throws) function where testbody executed with (eval): ``` [de assert-throws (Type Error Result Message) (let Result (catch Type (eval Result) NIL) (if (= Error Result) (passed Message) (failed Error Result Message) ] ``` But I tested similar behaviour in my test above and it seems correct. After that I played a little with test case itself: ``` '(assert-throws 'pg-db-err NIL '(pg-trans (catch 'pg-data-err (pg-execute "SELECT 1/0;")) '(pg-execute "SELECT 1;") ) ) ``` quoted second farg works well ``` '(assert-throws 'pg-db-err NIL '(pg-trans (catch 'pg-data-err (pg-execute "SELECT 1/0;")) (pg-execute "SELECT 1;") ) ) ``` unquoted fails with "pg-db-err -- Tag not found" ``` '(assert-throws 'pg-db-err NIL '(pg-trans (catch 'pg-data-err (pg-execute "SELECT 1/0;")) (catch 'pg-db-err (pg-execute "SELECT 1;")) ) ) ``` unquoted second farg with (catch) on this specific fun works well ``` '(assert-t (catch 'pg-db-err # or T (pg-trans (catch 'pg-data-err (pg-execute "SELECT 1/0;")) (pg-execute "SELECT 1;") ) ) ) ``` explicit (catch) fails as well. Probably Im missing something? Thanks. Best regards, Nail. сб, 19 янв. 2019 г. в 16:57, Alexander Burger : > On Sat, Jan 19, 2019 at 04:27:53PM +0300, Abel Normand wrote: > > So I have a question, is there a reason to quote functions used as args > for > > functions with manually evaluated arguments? I thought that there is no > > such reason to quote this sub S-expressions because they are not > evaluated > > anyway (due to function declaration like for pg-trans or assert-throws) > > You mean FEXPRs, like > >(de pg-trans X > ... ) > > where 'X' is bound to the unevaluated argument list, right? As this > function > later *does* evaluate the args with (mapc eval X), it is indeed not good to > quote these args, as you *want* them to be evaluated. > > If they are quoted, they evaluate to the expression itself, instead of > being > executed, and this makes no sense here. > > BTW, instead of (mapc eval X) it is better to call (run X) or even > better (run X 1). > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- С уважением, Наиль.
