If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Dmitrii 'Mamut' Dimandt dmitriid Stockholm, Sweden

dmitriid/blueredis 36

Blueprints-enabled graph over Redis

dmitriid/neo4j-erlang 36

Erlang client library for Neo4J's REST API

dmitriid/every 30

Every Layout with Svelte

dmitriid/freja-sphinx 21

A simple and clean theme for Sphinx document generator

dmitriid/beepbeep 17

BeepBeep is a simple web application for Mochiweb inspired by Rails and Merb

dmitriid/phreak 15

Kubernetes Dashboard with Phoenix LiveView

dmitriid/cali 12

an Erlang-Gremlin/Blueprints interface (neo4j/sail/etc...)

dmitriid/noe 8

Simple note-taking for Erlang

dmitriid/exb 7

erlang xmpp bot

dmitriid/pegjs 6

peg.js implementation for erlang

issue commentmozilla/standards-positions

WebHID (Human Interface Device) API


We knew that some of the other browser vendors were not interested in cooperating on a timeframe

What actually happened: The only two remaining competitors have explicitly stated that these poorly thought-out and underspecified "standards" (which are nothing more than Chrome's internal APIs) pose a significant security and privacy risk. Chrome said: we don't care.

It is literally Chrome who's not interested in cooperating.

in WebHID we understood that the web application developer need was strong and established years ago with Chrome Apps.

Translation: we have a bunch of APIs that are: developed by Chrome, enabled by Chrome and that exist only in Chrome that we just enable by default regardless of consequences. Our goals:

  • secure Chrome dominance [1]
  • gaslight other browser vendors and misrepresent their positions

Ah yes, and do so under the guise of "developers want it" and "this is for the better of the web".

I am glad there are so many developers passionate about creating a successful web platform, and encourage as much proactive communication as possible.

Translation: we're busy fracturing the web platform by replacing it with Chrome, and we couldn't be happier doing that.

[1] This is a longer issue than can be effectively put into a GitHub comment. The gist is:

  • Google as a company doesn't exist outside the web
  • The only stack it owns is the web
  • What better way to keep control of the stack if not by subsuming and replacing it?
  • You can achieve it, partly, via platform fatigue (as Rich Harris described it): throw stuff at it until even Microsoft with their unlimited money and resources says "screw this, we cannot sustain developing our own browser anymore"
  • And as Jonathan Nightingale, former VP/VP Engineering of Mozilla, said in hist thread about Google sabotaging Mozilla, "The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional."

The pretence that Chrome "cares for the better web" should just stop.


comment created time in 10 days

issue commentmozilla/standards-positions

WebHID (Human Interface Device) API


  • Asked for position on Dec 1, 2020
  • One month later, on Jan 4, 2021, received input: this is not even close to being even a draft for a standard
  • Two months later, on March 9, 2021, enabled by default and shipped in Chrome 89, and advertised it as fait accompli on
  • Two more months later: added 2669 lines of text, "hey, there's this "standard" that we enabled by default, why don't you take a look at it?"

Is my timeline correct? Why does Chrome team even bother pretending they care about standards and standards processes?


comment created time in 11 days

issue commentmicrosoft/terminal

Extremely slow performance when processing virtual terminal sequences

@AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us to strive for. Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links.

Let's see:

  • the author showed that the terminal is unberably slow under the best of circumstances
  • his suggestions to improve rendering were dismissed out of hand, because as someone put it, "what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple”"
  • he went ahead an implemented it himself, over a fiew days, in as little as 3k lines of code

Something tells me that:

  • he has all the right to do that
  • he has all the right to license his code however he wishes

Also something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:

  • could go ahead an do the same "doctoral research" that Casey Muratori did and retrace his steps
  • could pool together their not insignificant salaries and hire Casey as a consultant
  • ask their managers and let Microsoft spend some of those 15.5 billion dollars of net income on hiring someone like Casey who knows what they are doing

Instead, you complain that his code that he didn't even need to write to prove his point, is GPL v2. I'm afraid you're provinf his point tenfold.


comment created time in a month

issue commentvitejs/vite

In watch mode, changes in @import'ed files don't trigger CSS rebuild

Awesome! Thank you @CHOYSEN and @patak-js!


comment created time in 2 months

issue openedvitejs/vite

In watch mode, changes in @import'ed files don't trigger CSS rebuild

Describe the bug

Quick steps to reproduce (also see the link to repo below):

  • Create an app.css file
  • In that file, add @import "components/card.css" file
  • Run Vite in watch mode


  • If you change anything in app.css, the CSS is rebuilt
  • If you change anything in components/card.css, nothing happens.

Re-running the watch, or rebuilding will properly rebuild the CSS. But when in watch mode, changes in @imported files don't trigger the rebuild.


This repo closely follows my current setup with respect to location of files, but I don't think there's anything out of the ordinary. The README shows how to run and where to look (there are two CSS files and one output file)

System Info

Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:

    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 50.67 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
    Node: 15.11.0 - /usr/local/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 7.6.0 - /usr/local/bin/npm
    Chrome: 90.0.4430.212
    Safari: 14.0.3
    vite: ^2.3.1 => 2.3.1 

Used package manager: Reproduced for both npm and yarn

Before submitting the issue, please make sure you do the following

  • [x] Read the Contributing Guidelines.

  • [x] Read the docs.

  • [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

    Note to the above: perhaps triggered by the same problem: #3108 Styles not being recompiled when using --watch mode

  • [x] Provide a description in this issue that describes the bug.

  • [x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to instead.

  • [x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

created time in 3 months

push eventdmitriid/vite-import-css-reproduction

Dmitrii Dimandt

commit sha 97ef4c56ae6d73b54972510138483c4b2e410067

Reproduce Vite bug

view details

push time in 3 months

create barnchdmitriid/vite-import-css-reproduction

branch : master

created branch time in 3 months

created repositorydmitriid/vite-import-css-reproduction

created time in 3 months