- Dec 2022
-
www.rfc-editor.org www.rfc-editor.org
-
This can lead to the sending of email to the correct address but the wrong recipient.
-
- May 2022
-
github.com github.com
-
No option is perfect here, but a warning seems like a decent compromise unless there's a whole bunch of other plugins that break
-
- Apr 2022
-
github.com github.com
-
These callbacks are focused on the transactions, instead of specific model actions.
At least I think this is talking about this as limitation/problem.
The limitation/problem being that it's not good/useful for performing after-transaction code only for specific actions.
But the next sentence "This is beneficial..." seems contradictory, so I'm a bit confused/unclear of what the intention is...
Looking at this project more, it doesn't appear to solve the "after-transaction code only for specific actions" problem like I initially thought it did (and like https://github.com/grosser/ar_after_transaction does), so I believe I was mistaken. Still not sure what is meant by "instead of specific model actions". Are they claiming that "before_commit_on_create" for example is a "specific model action"? (hardly!) That seems almost identical to the (not specific enough) callbacks provided natively by Rails. Oh yeah, I guess they do point out that Rails 3 adds this functionality, so this gem is only needed for Rails 2.
-
- Apr 2021
-
stackoverflow.com stackoverflow.com
-
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.
-
-
unix.stackexchange.com unix.stackexchange.com
-
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?
-
- Nov 2020
-
-
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.
-
If current_component is never used outside of svelte/internal, it will be fine.
-
-
github.com github.com
-
When using the exact same Button code, the binding only works for the local Svelte module.
-
-
github.com github.com
-
If I, however, copy the content of index.svelte directly into the other project, it works fine. What can I do to fix that?
-
- Oct 2020
-
github.com github.com
-
docker --tlsverify ps executes just fine, while docker-compose --tlsverify up -d --force-recreate gives me an error: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
-
-
github.com github.com
-
When using a method in a top-level object to modify its state, such object isn't updated either.
-
- Sep 2020
-
github.com github.com
-
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.
-
-
docs.google.com docs.google.com
-
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.
-
- Jul 2020
-
bugs.ruby-lang.org bugs.ruby-lang.org
-
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.
-