This is my discussion blog. The way it works is that when any pages in this wiki have a discussion page created for them, the discussion pages show up below. Also, any comments on my blog posts also show up here.

comment 1

Forgot to mention that extensions can be enabled in the cabal file. Since Copilot operates on a per file basis, that will prevent it from realizing that an extension is needed by the code it absorbed.

Comment by joey
Speeding up process discovery

The shell will have started the processes close together in time, so the pids are probably nearby. So look at the previous pid, and the next pid, and fan outward.

The shell will have put all the processes of the pipeline into a single process group, so this can be sped up a bit more by calling getpgid() on a process before examining its fds.

Comment by eual.jp
typed pipes in every shell

Wow, this is really clever!

I think the /proc dancing is a strong argument to implement "typed" as a shell command (in the shell itself), because otherwise performance will probably drop in shell scripts with a lot of simple calls.

Comment by pat_h
Finding the latest article...
% telnet nntp.olduse.net 119
200 Leafnode NNTP Daemon, version 1.11.11 running at kitenet.net (my fqdn: kite.kitenet.net)
NEWNEWS
500 NEWNEWS is meaningless for this server

Would have been pretty useful though, for clearing your last challenge :-)

Comment by julien
comment 1
Since some people were confused by this, it's (currently) fiction.
Comment by joey
possible alternative

I don't think that there is no need to backup content from Github anymore - in contrary, developers are aware that Github can change their policies at any time and if that happens, their content might be gone, so they do make a backup.

Now that you announced github-backup as withdrawn, I can recommend another tool which seems to aim for the same target as yours: python-github-backup. It seems to do the job of backing up the metadata quite nicely.

I use it in conjunction with a more basic approach of cloning/pulling each repository itself like this:

function doBackup {
    URL=$1
    REPO=$(echo $URL | sed -e 's#^.*/##g' -e 's#.git$##')

    if [ -d $TARGET_REPOS/$REPO ]; then
        cd $TARGET_REPOS/$REPO
        git pull --all >/dev/null
    else
        echo "cloning $REPO"
        cd $TARGET_REPOS
        git clone $URL >/dev/null
    fi
}
curl -s 'https://api.github.com/users/mathisdt/repos?type=owner&per_page=500' \
    | grep -Eo '"git_url": "[^"]+"' \
    | sed -e 's#"git_url": ##' -e 's#"##g' \
    | while read url; do doBackup $url; done

Hope to help!

Mathis Dirksen-Thedens

Comment by joeyh-blog
Cool idea
Thanks for showing me a new way to annoy my co-workers. People could probably just create a new clean git repo without any history, but it's still a cool idea!
Comment by chris
it might be a variation of TOCTOU

Hi,

I think what you found might be a variation of TOCTOU - time of creation, time of access.

For example (although slightly different, but it's the same underlying idea):

https://duo.com/decipher/docker-bug-allows-root-access-to-host-file-system

Comment by cwk
comment 3

@alex safe-exceptions and unliftio use uninterruptibleMask in its async safe bracket. Which is ok if the cleanup action is fast, but does risk the program not responding to ctrl-c if the cleanup takes a while for whatever reason.

As well as SIGINT, there's also the possibility that an async exception is thrown for some truely exceptional circumstance, like a segfault. Most code would do well to exit immediately on such an exception, not mask it.

I wonder if there's a way to make an uninterruptibleMask that masks only a specific async exception, eg the AsyncCancelled exception. Probably this would need ghc support, if it's possible at all.

Comment by joey
comment 2
As alex said, safe-exceptions may help. There was a series of blog posts a few years ago about async exceptions: https://tech.fpcomplete.com/blog/2016/06/announce-safe-exceptions/ (I think that is the last post)
Comment by gueux+joeyh
comment 3

@Joey

Sectioning using "article" is helpful, as they provide semantics about the web page layout, but they are not considered to be a navigational landmark, so not all screen readers support navigating by "article" sections. From ARIA: article role

"Articles are not considered a navigational landmark, but many assistive technologies that support landmarks also support a means to navigate among articles. ..."

"header" elements are turned into navigational landmarks when they are descendants of the "body" element and this type of landmark is the "banner". They are the converse of a "footer" element which transform into "content info" landmark when it is directly child of "body". As navigational landmarks they are just meant for the whole page and not for individual sections of the page.

In Section 4.1 of WAI-ARIA Authoring Practices 1.1 is described which HTML semantic region elements get turned into aria landmarks.

Finally, headings are what most screen readers go to first for navigation of a web page. So for those reasons I'd recommend making the article titles headings. If you don't want to literally make them a "h1-6" because it would mess with your CSS then you can just set aria attributes which will change how the page is understood by assisstive tech but not affect any visual rendering of the page. a role="heading" aria-level="2"Lemons/a (using _ instead of angular brackets)

More info on heading role

Comment by samuel.kacer
comment 2

@samuel.kacer, the sections of the blog are inside html article tags, and the heading of each is inside a html header tag. That seems like sufficient semantic information to me..

I guess what I'll suggest is, if there's some reason that's not sufficient, you file a bug report on https://ikiwiki.info which is what the blog uses.

Comment by joey
thanks for the alt text for graphics

Hi,

I just stumbled onto your blog yesterday while searching for information on FRP in Haskell. Really cool stuff using Haskell for home automation in embedded systems!

I just wanted to post a comment because I noticed you include nice alt text on your images, which I greatly appreciate as a blind person. One other note on accessibility is that navigating around your blog would be easier if the article headings were some sort of HTML heading like

. Screen readers give shortcuts for jumping between different headings, so having sections of a webpage of intrest start with headings means as a screen reader user I could very easily switch between them instead of scrolling through the whole article before finding the beginning of the next one.

Just thought I would mention it since it seems you already care about accessibility.

Oh and happy late birthday!

Regards, Sam

Comment by samuel.kacer