Content tagged lisp
The heat finally gets at me, melting my circuits. And the fact that in Moscow on average it was much worse gives me shivers. I have to admit, I just hate summer this much.
The research work goes somewhere. Slowly, given the uncertified character of the computational codes that we use in DFT, bugs and errors in formalism are found. Last one we spotted after writing complete tensor representation for an alternative approach to get one heat flux component (one out of five!). Feels like every step towards the goal is harder, and it's rather frustrating than interesting.
The by-time is getting more structured though, converging on the topics I want to explore. My Rust crusade started recently, with help of its native cli to one well-known self-promotion resource (masking itself as a self-educational one).
Meanwhile I'm using Lisp for all things practical: from job submissions at work to scripting over my StumpWM desktop. Realizing now that Common Lisp is to stay with me not only as a primarily ideas-prototyping language, but also as a reliable study companion... for life. Putting aside stupid pathos of claims like "language from out-of-Space" that bears "alien powers", what I see is a well-thought dynamic computing system where many aspects just done right... or can be implemented right by its user. And it is a joy to use and even to discover hidden gems developed with it.
Speaking of which, I'm tempted to spend some time playing with ACL as part of introduction to the computer-aided proofs. Some time after I'm done with The Little Typer book (featuring by the way a Scheme dialect designed for demonstration of a lightweight proover). And then, well, I'll seek an advice on what to pick up further. My trials with aggressive imperative programming show clearly that the future lies clearly in formal verification for computational environments.
So, that's what my leisure thoughts will spin around for the time being: promising imperative (e.g. rust), practical dynamic and meta-programming (e.g. lisp) and mathematical reasoning systems. In a combined interconnected way that will provide a better understanding of computer science - where there is science.
I've recently introduced an issue in my workflow when using Common Lisp's UIOP standard facility for launching asynchronous system calls. It appears to be quite a critical one since I'm planning to use that functionality a lot with my side-effect manager.
The following code will fail after a couple hundred (maybe thousand) of iterations, complaining about "too many open files":
(loop :repeat 1000 :do (let ((proc (uiop:launch-program "cat ~/.bashrc" :output :stream :error-output :stream))) (print (uiop:process-info-pid proc)) ; show PID (uiop:slurp-stream-lines ; collect output lines (uiop:process-info-output proc)) (unless (= 0 (uiop:wait-process proc)) ; wait till end (print "Fail!"))))
Experimentally I found out that
uiop:close-streams should be used to mitigate
the bug. Which is in fact written in the documentation string, saying:
Needs to be run whenever streams were requested by passing :stream to :input, :output, or :error-output.
Which takes place since I do request those outputs as streams.
But how do I know about it in advance? Well, turns out that the corresponding
in the ASDF manual opens with description of
close-streams, because alphabet.
So it's one of the "RTFM" cases.
So this works, as many-many times I want:
(loop :repeat 100000 :do (let ((proc (uiop:launch-program "cat .bashrc" :output :stream :error-output :stream))) (print (uiop:process-info-pid proc)) ; show PID (uiop:slurp-stream-lines ; collect output lines (uiop:process-info-output proc)) (unless (= 0 (uiop:wait-process proc)) ; wait till end (print "Fail!")) (uiop:close-streams proc))) ; <- DAT FIXES
And given that I defined a macro for this most common pattern of program launching,
just not to forget to
close-streams again. A raw anaphora will serve till I
produce something more clever:
(defmacro aproc (command &body body) "Anaphoric process launcher. Refer to process instance as PROC in &BODY." `(let ((proc (uiop:launch-program ,command :output :stream :error-output :stream))) (values ,@body (uiop:close-streams proc))))
Recently I took part in a discussion organized by CECAM on the topic of Digital Learning, a subject which all of a sudden became critical to all the educational institutions. Of course there was a section on adaptation of existing courseware to remote learning formats. With opinions on difficulties to follow, grade and adapt to e-learning. And a traditional certain skepticism expressed on technologies that fail to create revolutions in education.
I agree on that, it's hard to imagine a revolt in internal thinking
process by mere upgrade in the educational media. But certain
can be achieved with modern technologies.
False. They are already present, with help of tech that is decades