13 Matching Annotations
  1. Apr 2021
    1. They cause completely different behavior for auto margins. If you have a fixed element for example with top/bottom/left/right set to zero and you stick an image in it you want to center wrapped in a div, then in order to center that div with auto margins, you MUST specify a CSS width/height, because specifying an HTML attribute width/height has no effect and the margins remain zero. I have no idea why the difference exists.
    1. unbuffer is able to pass along the return code of a process under normal circumstance, but if the process you are unbuffering is killed, for instance with a segfault, I see $? as 0 while I expect 139. How can I get it to pass along the 139?
  2. Nov 2020
    1. If I use import { createEventDispatcher } from 'svelte/internal'; instead of import { createEventDispatcher } from 'svelte'; then it seems to work because it's loading from the same module.
    2. If current_component is never used outside of svelte/internal, it will be fine.
  3. Oct 2020
  4. Sep 2020
    1. It looks like the issue stems from having "svelte" as a dependency instead of a devDependencies in package.json within the sapper project. This causes import 'svelte' to load the rollup excluded npm package's set_current_component instead of from within the sapper generated server.js.
    1. I’ve seen some version of this conversation happen more times than I can remember. And someone will always say ‘it’s because you’re too used to thinking in the old way, you just need to start thinking in hooks’.

      But after seeing a lot of really bad hooks code, I’m starting to think it’s not that simple — that there’s something deeper going on.

  5. Jul 2020
    1. Arrays are not sets. Trying to treat them as if they are is an error, and will create subtle problems. What should be the result of the following operations? [1, 1] | [1] [1] | [1, 1] Of course, there are more interesting examples. These two are to get you started. I don't care what the results currently are. I don't care what you think they should be. I can present extremely strong arguments for various answers. For this reason, I believe that #| is an ill-defined concept. Generalizing an ill-defined concept is a world of pain. If you insist on treating objects of one class as if they were members of a different class, there should be bumps in the road to at least warn you that maybe this is a bad idea. I'm not going to argue that we should remove or deprecate #|. I don't think of myself as a fanatic. But encouraging this sort of abuse of the type system just creates problems.