Adrián Pérez @aperezdc@mastodon.social

Quick update on content extensions in #WebKitGTK and #WPE: landed a couple of patches upstream in preparation for the actual big patch. The new API bits are looking solid and the MiniBrowser now had a CLI option to load a JSON filter rule set.

Pending: enabling the layout tests and solving another assertion — the one from last week is solved and now I kind of understand the disk format of compiled extensions as a side effect. It looks like next I'll need to dive in the bytecode compiler itself

Also, realizing this, if it is true in reality (so far it's a theory floating in my head), kind of helps explain the demise of Firefox OS — it may have even been doomed from the start!

Also, while possible, restricting what native apps can effectively collect or do requires system modifications: a custom ROM, or some kind of non-stock modifications (for example Xposed on Android). On the other hand, even my dad knows how to install a Firefox extension: getting a Web engine tweaked is much more approachable.

Surveillance capitalism prefers native apps, so they make their websites suck on mobile, even when we had the technology to build good mobile webapps for many years 🧐

It just dawned on me that one reason why webapps have not been doing great compared to native mobile apps is that running on a more sandboxed environment (a Web engine) kind of makes collection of user data and presenting ads kind of more difficult. Many users know that adblockers (and to some extent tracking prevention tools) exist for browsing the Web so they would expect the same or similar for Web apps. Native apps? Users have no previous expectation, and it is more difficult to limit them.

Seriously considering a series of blog posts about reducing the disk and memory footprint of #WPEWebKit.

Recently I have been working on an device which has a 256 MiB memory budget for the embedded Web engine, which is used for the user interface. I have also gotten some report about running WPE on 128 MiB, which is very tight, but definitely doable depending on which Web content one throws at it... I would not recommend 128 MiB for browsing random Internet pages, though! (Tons of JS, anyone?)

It looks as if I might be getting a slight flu, which is something I definitely wasn't looking forward to. Let's see how it goes tomorrow after a good night's rest

Today I have been reminded of that one time when I was allowed to sneak a plain C style cast in the #WebKit code base because C++ is dumb at times, and always full of pitfalls: https://trac.webkit.org/changeset/223416/

Nevertheless, I haven't yet finished the programs for day 3 of the #AdventOfCode but on my defense I can say that now I know how to use a language feature (record types) which so far I had not touched in other functional languages that I know (OCaml, some Haskell, and so).

Scheme feels like one *really* needs to master the standard library and the language conventions to really become fluent in it. Has somebody else had the same impression with #Lisp like languages?

So, I've managed to get the parser combinators from the “(chibi parse)” module to work. I quite don't get it why giving an identifier to the grammar when later it is not used, and what gets referenced to start parsing is one of the functions that implement parsing a non-terminal... but it works and there is a nice “parse-fold” function which applies a parsing function over the input, possibly accumulating it e.g. into a set of records. Also: today I also figured how to use “define-record-type”!

Today in #WebKit development: I got the content extensions support building for the #WPE WebKit port as well, still looking into the release assertion that is hit during evaluation of the extension's bytecode — and learning about how this works internally at the same time, it's being a fun ride

Today's #AdventOfCode is postponed until the evening, as it seems I have some fires to put off at work. Today I'm trying to use Chibi Scheme's parser combinators module to read the input, because it can no longer be read as a stream of plain Scheme values — which was great to avoid parsing. More later!

For the record: day one done, both problems. It took me a bit to arrive to this gem to read *and* parse a stream of integers coming from standard input:

(import
(chibi io)
(scheme read))

(define values
(port->list read (current-input-port)))

This is pretty cool, and turned the solution for the first problem into a one-liner if we don't count the imports.