Logbook + Scratchpad

Today, while messing around with WriteFreely configuration and logs, I have become aware of the API endpoints. I did know about the API before, but I never set to actually look at what is possible to do.

The most useful open endpoint is probably /api/collections. Every user on a WriteFreely instance has a collection (of posts) associated with its username; in my case, this is /api/collections/nick. Under this path, the /api/collections/nick/posts endpoint retrieves some meta information and the 10 latest posts (if the blog uses the “Blog” display format):

$ curl -s https://blog.nvitucci.social/api/collections/nick/posts

A tool like jq can be useful for a quick inspection from the command line. For example, you can retrieve the title of the blog and the total number of posts with the following command:

$ curl -s https://blog.nvitucci.social/api/collections/nick/posts | jq '.data.title, .data.total_posts'

You can also see the title of the 10 latest posts:

$ curl -s https://blog.nvitucci.social/api/collections/nick/posts | jq '.data.posts[].title'

Since the page size is set to 10 (and apparently it cannot be changed), you can calculate the number of pages and then paginate the result using the page parameter:

$ curl -s https://blog.nvitucci.social/api/collections/nick/posts?page=2 | jq '.data.posts[].title'

The complete documentation of the WriteFreely API is available here.

#TIL #fediverse #API

While reading the docs on Voilà, I've come across Voici, then JupyterLite, and finally Pyodide.

Each projects has its own merits:

• Voici aims to make it easy to build a static Web application from a Jupyter notebook, meaning that a dashboard can be built and deployed without a running Python environment.
• JupyterLite is a Web-native version of JupyterLab, meaning that it is designed to run entirely in the browser without a Python environment.
• Pyodide is a Python distribution based on WebAssembly, meaning it is also designed to run entirely in the browser as a Python environment; in fact, it provides a base for a browser-based kernel that JupyterLite uses.

I've tried Voici right after trying out Voilà, but I couldn't manage to make it run because of bugs I didn't have time to investigate; I'll try again later on. I haven't tried JupyterLite as such yet, but I did try Pyodide and, at a first sight, it really looks powerful. With Pyodide you can run Python code and use external packages in a Web page: how cool is that?

I was thinking of something like Pyodide when I first read about a WebGL port of Panda3D based on Emscripten (a compiler that supports compiling a host of languages into WebAssembly, which Pyodide actually uses), and then I found it by coincidence serendipity! Full example of integration with JavaScript coming soon.

#TIL #tech #python #webassembly

While looking at the latest additions to the Jupyter project, I've come across marimo.

marimo is a different kind of Python notebook, not based on any existing Jupyter components but rebuilt from scratch. Its main strengths are the built-in reactivity of the widgets (which you need to link and coordinate explicitly in Jupyter Widgets with functions like link and observe) and the ease of turning a notebook into a standalone Web application (the objective of projects such as Voilà).

I have installed it and tried the tutorial, which by the way is a nice developer experience: just pip install marimo and then marimo tutorial intro. The interface looks modern and sleek, and the widgets do update at a variable change without any extra code, which is neat when there are many or when several widgets are interconnected. I haven't tried the conversion to a Web app yet, but it is also meant to be easy via the command line – just a marimo run away.

I am not sure I will replace my use of Jupyter with marimo soon, but I'll definitely keep an eye on its development, and will keep experimenting with it.

#TIL #tech #python

In the previous post I mentioned that I have recently discovered Voilà, a Python project whose purpose is to convert Jupyter Notebooks into standalone Web applications. This is particularly useful when a notebook contains a lot of interactive components like Jupyter widgets, and you want users to only see them as a UI without any code.

I've quickly tried it with a notebook I had, and it is quite easy to set up. You just need to make sure that there are no cells that “hang up” with calls to external APIs or processes that require user interaction to be stopped. I'll share a more detailed example when I have a more interesting (interaction-wise) notebook.

There is a dedicated website with a gallery of examples, which are not only useful to discover what is possible with Voilà but also to find other Python tools that may be useful for other things.

#TIL #tech #python

A few times I thought that it would be nice to be able to generate and display LaTeX expressions in a Jupyter notebook (meaning in code, not in Markdown cells), but I never really got to look for a solution.

Today, while looking for something else, I have come across a nice trick in a notebook meant to showcase Voilà (which I will explore in a different post).

The HTML class in IPython.display can display LaTeX expressions interspersed with HTML code and variables, so for example you can generate a few h1 LaTeX headers doing the following:

from IPython.display import HTML

for char in ['B', 'C', 'D']:
    display(HTML(r"<h1>$f(x, y)=\displaystyle \frac{A}{%s}$</h1>" % char))

The result is this:

$f(x, y)=\displaystyle \frac{A}{B}$ $f(x, y)=\displaystyle \frac{A}{C}$ $f(x, y)=\displaystyle \frac{A}{D}$

If all you need is LaTeX without any formatting, just use the Latex class from IPython.display:

from IPython.display import Latex

for char in ['B', 'C', 'D']:
    display(Latex(r"$f(x, y)=\displaystyle \frac{A}{%s}$" % char))

Another nice option is to use the sympy package and write symbolic formulae that can be converted to LaTeX directly with the latex function:

import sympy

x, y = sympy.symbols('x y')
HTML(r"$f(x,y)= %s$" % sympy.latex(x + y))

The result is this:

$f(x, y)= x + y$

#TIL #tech #python

I have published a GitHub repository with some PDDL experiments I have mentioned in the last posts.

The repository contains domain and problem files that cover different fragments of PDDL (as of now STRIPS, numeric fluents, and durative actions), with some recommendations on the planners to use to solve them.

#tech #AI #planning

In my (re)exploration of PDDL I've understood better not only how different language features drive the decision of what planner to use, but also one more dimension that makes planners different: satisfiability versus optimality.

Numeric and temporal domains

Beyond classical planning based on predicates (using :predicates and :actions in PDDL), it is possible to plan based on numeric quantities (:functions) and actions with a duration (:durative-actions). The two domains can be mixed, for example by expressing durations as functions rather than fixed numbers. Both require the use of a metric (:metric), which can be any numeric function (or just total-time for temporal domains) to be minimized or maximized.

Some planners like LPG-td can cover both domains, but more often than not planners specialize in one of the two (and not many planners cover the temporal domain).

Satisficing vs optimal planners

A planner can not only cover just some construct of PDDL (say, numeric fluents but not durative actions), but also be limited to find solutions that satisfy the domain (satisficing planners) without necessarily be optimal (a task for optimal planners). Some planners such as ENHSP can even do both, but it's necessary to always make sure of the capabilities of a planner with respect to the problem to solve.

#TIL #tech #AI #planning

In the previous post I mentioned the planutils project as an easy way to try several PDDL planners. Today I learned about the planutils server, a simple Flask app that exposes an HTTP API to invoke planners remotely, and I thought it's a brilliant idea. As of now, the API can only be used to get information on installed planners and to invoke each of them with its basic parameters, namely the PDDL domain and problem.

The nice thing about it is that there is a setup script to set up a planutils server Docker container with a few representative planners (among which OPTIC for PDDL3 support, ENHSP-2020 for numeric planning, and TFD for temporal planning) and an exposed port (5555 by default).

With the server container running, the API can be used with any usual tool. An example with curl could be like this:

curl -s -H "Content-Type: application/json" -d "{\"domain\": \"$(cat domain.pddl | tr '\n' ' ')\", \"problem\": \"$(cat problem.pddl | tr '\n' ' ')\"}" localhost:5555/package/enhsp-2020/solve

In this example, the two PDDL files are converted to strings and passed to the ENHSP-2020 planner as JSON values.

I will shortly put all this in a GitHub repo along with some example PDDL files for reference.

#TIL #tech #AI #planning

Prompted by a recent discussion, I went “back to the basics” and took a new look at PDDL.

The language, based on STRIPS (which I know from early courses in robotics), has undergone several improvements to make it more and more expressive. This means that, as it happened with RDFS, OWL, and their reasoners, there are different planners that make use of one version of the language or another, and finding what planner supports what version and what specific features of the language is not always easy.

The Planning.wiki website has a good review of the main versions of the languages as well as a list of (some of) the known planners. Today I also discovered the planutils project that aims to make trying different planners easier by packaging them with Docker. The setup is quite easy and using it is also relatively straightforward.

I began doing some experiments with PDDL myself, which I'll write about in another post.

#TIL #tech #AI #planning

Today I was looking for a way to easily backup data from my Android mobile phone onto a remote server. While there are plenty of apps that can be used to send data to a cloud service (and, obviously, to Google), there aren't many that can be used with one's server, or at least without a certain amount of fiddling (like Termux).

A seemingly good one I've come across is FolderSync.

Pros:

• Supports SFTP both with credentials and with an SSH key.
• It has many scheduling options, so it's easy to “set and forget”.
• It gives some guarantees when it comes to privacy and data collection.

Cons:

• Not open source.
• It cannot generate an SSH key.
• The UI takes a bit to get used to.

#tech