Blueprints-enabled graph over Redis
Erlang client library for Neo4J's REST API
Every Layout with Svelte
A simple and clean theme for Sphinx document generator
BeepBeep is a simple web application for Mochiweb inspired by Rails and Merb
Kubernetes Dashboard with Phoenix LiveView
an Erlang-Gremlin/Blueprints interface (neo4j/sail/etc...)
Simple note-taking for Erlang
erlang xmpp bot
peg.js implementation for erlang
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 
- 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.
 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
- 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 web.dev
- 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
@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.
- 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
Awesome! Thank you @CHOYSEN and @patak-js!
comment created time in 2 months
Describe the bug
Quick steps to reproduce (also see the link to repo below):
- Create an
- In that file, add
- 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)
npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:
System: 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 Binaries: Node: 15.11.0 - /usr/local/bin/node Yarn: 1.22.5 - /usr/local/bin/yarn npm: 7.6.0 - /usr/local/bin/npm Browsers: Chrome: 90.0.4430.212 Safari: 14.0.3 npmPackages: vite: ^2.3.1 => 2.3.1
Used package manager: Reproduced for both
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 https://github.com/vuejs/vue-next instead.
created time in 3 months
commit sha 97ef4c56ae6d73b54972510138483c4b2e410067
Reproduce Vite bug
push time in 3 months
created time in 3 months