I can confirm that this is still actual for Rails 7 - jpEg converts to jpg and your production fails.

Ain't it possible that every message I send or forward will just be replaced to the outbox and will be send by Thunderbird in the background ? I really hate it that every message sends itself away, running on top of all other windows, and it makes me wait till it has been sent from reading my other messages...

Personally I don’t find necessary to see the whole progress of how a mail is sent step-by-step, I just want to send the e-mail. Can’t understand why they are showing me all these but anyway

Note that the mere presence of this header causes premailer to be skipped, i.e., even setting skip_premailer: false will cause premailer to be skipped. The reason for that is that the skip_premailer is a simple header and the value is transformed into a string, causing 'false' to become truthy.

It seems that the method is a direct equivalent of a.fdiv(b).ceil, and as such, annoyingly unnecessary, but fdiv, due to floating point imprecision, might produce surprising results in edge cases

No, in Python "[ [] foo [] boo [][]] ".strip(" []") returns "foo [] boo".

dependent: :destroy associations are deleted when performing soft-destroys requiring any dependent records to also be acts_as_paranoid to avoid losing data.

I've worked with and have helped maintain paranoia for a while. I'm convinced it does the wrong thing for most cases. Paranoia and acts_as_paranoid both attempt to emulate deletes by setting a column and adding a default scope on the model. This requires some ActiveRecord hackery, and leads to some surprising and awkward behaviour.

paranoia has some surprising behaviour (like overriding ActiveRecord's delete and destroy)

This still seems like a bug, as the expected behavior doesn't occur and it's difficult (for someone unfamiliar with the inner workings of ActionMailer) to debug. I spent a good half an hour figuring out the work around, so I'm trying to prevent others from experiencing the same thing.

I just spent a day dismantling a model, trying to find the cause of the silent rollback - taking out every association, every validation, every callback, whittling down all the code in the transaction, only to finally discover that it was return true that was the cause of it all. Or yes, an exception!

then two different listeners/renderers switching magically between each other based on the header being present or not, without the end user being informed or clear about this

This is actually the most correct answer, because it explains why people (like me) are suddenly seeing this warning after nearly a decade of using git. However,it would be useful if some guidance were given on the options offered. for example, pointing out that setting pull.ff to "only" doesn't prevent you doing a "pull --rebase" to override it.

This was a surprise to me, since we generally authenticate the record quite well, but then go on to do something like record.file.url in our view, generating a URL that is permanent and unauthenticated.

Explicitly defining the dependency in the reactive declarations

inputValue = updateInputValue(value);

maybe this just comes down to general footguns with reactivity, and being aware of them as a developer.

if you put the reactive statement $: validate(inputValue); after the function updateInputValue declaration, it's working as expected:

So now the question is, why does Session, an interface, not get implicit index signatures while SessionType, an identically-structured typealias, *does*? Surely, you might again think, the compiler does not simply deny implicit index signatures tointerface` types? Surprisingly enough, this is exactly what happens. See microsoft/TypeScript#15300, specifically this comment: Just to fill people in, this behavior is currently by design. Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces. But we'll consider doing it for interfaces as well if that seems to make sense And there you go. You cannot use a Session in place of a WithAdditionalParams<Session> because it's possible that someone might merge properties that conflict with the index signature at some later date. Whether or not that is a compelling reason is up for rather vigorous debate, as you can see if you read through microsoft/TypeScript#15300.

therefore in practice it's a bit academic to worry about which lines inside that block the compiler should be happy or unhappy about. From falsehood, anythihng follows. So the compiler is free to say "if the impossible happens, then X is an error" or "if the impossible happens, then X is not an error". Both are valid (although one might be more or less surprising to developers).

I don't like that I can't really use head? to know it's a HEAD request, but I (think I) understand the reasoning

Note that & is a line terminator like ; (write command& not command&;).

It's strange to me that the text returned is in all caps (how it's styled after CSS), but the matcher is actually testing against the text in the unstyled HTML. I spent a while digging through the source code and I still can't figure out why this works.

If you change a form value to '', Final Form will set the value in its state to undefined. This can be counterintutive, because '' !== undefined in javascript.

I don't get it. Can someone please explain? I've upgraded my Rails project to Sprockets 4, just to get source maps in production. Instead I got sourcemaps in development?

My only concern with this approach is that if someone calls #valid? on the form object afterwards, it would under the hood currently delete the existing errors on the form object and revalidate. The could have unexpected side effects where the errors added by the models passed in or the service called will be lost.

My concern with this approach is still that it's somewhat brittle with the current implementation of valid? because whilst valid? appears to be a predicate and should have no side effects, this is not the case and could remove the errors applied by one of the steps above.

Another problem I found with Reform is the synchronisation with models. The object you passed in argument to reform does not have the same value than the form.

It seems like this should be one of the easiest things to understand in CSS. If you want a block-level element to fill any remaining space inside of its parent, then it’s simple — just add width: 100% in your CSS declaration for that element, and your problem is solved. Not so fast. It’s not quite that easy. I’m sure CSS developers of all skill levels have attempted something similar to what I’ve just described, with bizarre results ultimately leading to head scratching and shruggingly resorting to experimenting with absolute widths until we find just the right fit. This is just one of those things in CSS that seems easy to understand (and really, it should be), but it’s sometimes not — because of the way that percentages work in CSS.

min-width: 0;

It won't work if $HOME is not under /home. Really. Not even if you softlink. You need a bind mount

In my opinion, this single-tab Refresh behavior strongly violates the principle of least surprise, and it doesn’t help us to maintain code consistency or data consistency.

What I think is happening is that instantiating the component is immediately running the $: reactive code, which dispatches the event synchronously, before the parent component attaches the listener.

I also tried to use <!-- svelte-ignore unused-export-let --> before the script tag but still no chance.

This mirrors how classes already work and avoids the issues with introducing an unexpected DOM node.

I debugged docker-compose and docker-py and figured out that you should either use environment variables or options in command. You should not mix these . If you even specify --tls in command then you will have to specify all the options as the TLSConfig object, as now TLSConfig object is created completely from the command options and operide the TFSConfig object created from the environment variable.

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

I only have one set of certs. And I can't see how they can be different because docker commands work using the endpoint. It's just the docker-compose command that fails

docker-compose command you can not mix environment variable and command option. You can specify setting in env variable and then just use docker-compose ps. The connection will be secured with TLS protocol if DOCKER_TLS_VERIFY variable is set.

You dont need to pass --tls or --tlsverify option in the docker-config path as the task already sets DOCKER_TSL_VERIFY environment varaible. I debugged docker-compose and docker-py library and verified that if you pass any flag --tls or --tlsverify flag it tries to create tslConfig object out of options and not from environment

I debugged docker-compose and docker-py and figured out that you should either use environment variables or options in command. You should not mix these . If you even specify --tls in command then you will have to specify all the options as the TLSConfig object, as now TLSConfig object is created completely from the command options and operide the TFSConfig object created from the environment variable.

When using a method in a top-level object to modify its state, such object isn't updated either.

I too have been confused by behavior like this. Perhaps a clearly defined way to isolate atomic units with synchronous reactivity would help those of us still working through the idiosyncrasies of reactivity.

For performance reasons, $: reactive blocks are batched up and run in the next microtask. This is the expected behavior. This is one of the things that we should talk about when we figure out how and where we want to have a section in the docs that goes into more details about reactivity. If you want something that updates synchronously and depends on another value, you can use a derived store:

I expected that the param being passed by reference to have the same reactivity of the variable being created in the script tag.

One would expect the display to be updated, but it is not... WHY is it updated the 2nd time you enter something? What is different?

If the user now clicks Back again, the URL bar will display https://www.mozilla.org/foo.html, and totally bypass bar.html.

There'll be no more warnings. But if you open bundle.js, you'll see something shocking: it contains the entirety of React and React DOM. That's 7000 LoC!

Basically, the idea is that a train tried to start with the caboose brakes stuck on. After releasing the caboose, the train still could not start. The problem was that when the train attempted to start with the caboose brake on, it stretched all the inter-car couplings so that the whole train was just like one big car. At this point, the friction from the engine train wheels was not enough to get the whole thing going. Instead, you need to just get one car moving at a time - this is why there is space between the couplings.

Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.

It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.

I'm just trying out the "Reply to comment" button here. Well, it seems like it doesn't quote the text... that's really the feature I'd like to exposed. When responding to a large message (email or otherwise), I like to quote various parts and respond in line.

The inherent stealth conversion into Sets is not a good idea in my book.

To me the difference between [1,1,2,2,3,3] and [1,2,3] is not []

Code doing surprising and slightly nonsensical things... I'm weary now. And that's with ruby being more consistent than most!

One may expect Array#- to behave like mathematical subtraction or difference when it doesn't. One could be forgiven to expect the following behavior: [1,1,2,2,3,3,4,4] - [1,2,3,4] => [1,2,3,4]

I'll freely admit I was surprised by this behavior myself since I needed to obtain an Array with only one instance of each item in the argument array removed.

However, a ActiveRecord::Rollback within the nested transaction will be caught by the block of the nested transaction, but will be ignored by the outer transaction, and not cause a roll back! To avoid this unexpected behaviour, you have to explicitly tell rails for each transaction to indeed use proper nesting: CopyActiveRecord::Base.transaction(joinable: false, requires_new: true) do # inner code end This is a safer default for working with custom transactions.

transaction calls can be nested. By default, this makes all database statements in the nested transaction block become part of the parent transaction. For example, the following behavior may be surprising: User.transaction do User.create(username: 'Kotori') User.transaction do User.create(username: 'Nemu') raise ActiveRecord::Rollback end end creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed.

You might not care today, but your approach doesn’t allow you to have multiple spaces (Philippines   6014), leading spaces, trailing spaces, or tabs.

Unexpected features “Unexpected” features are those that are unrelated to the add-on’s primary function, and are not likely from the add-on name or description to be expected by a user installing that add-on. Should an add-on include any unexpected feature that falls into one of the following categories: Potentially compromises user privacy or security (like sending data to third parties) Changes default settings like the new tab page, homepage or search engine Makes unexpected changes to the browser or web content Includes features or functionality not related to the add-on’s core function(s) Then the “unexpected” feature(s) must adhere to all of the following requirements: The add-on description must clearly state what changes the add-on makes. All changes must be “opt-in”, meaning the user has to take non-default action to enact the change. Changes that prompt the user via the permissions system don’t require an additional opt-in. The opt-in interface must clearly state the name of the add-on requesting the change.

To be just a bit polemic, your first instinct was not to do that. And you probably wouldn't think of that in your unit tests either (the holy grail of dynamic langs). So someday it would blow up at runtime, and THEN you'd add that safeguard.

As many would guess: ... catch StandardError => e raise $! ... raises the same error referenced by $!, the same as simply calling: ... catch StandardError => e raise ... but probably not for the reasons one might think. In this case, the call to raise is NOT just raising the object in $!...it raises the result of $!.exception(nil), which in this case happens to be $!.

The .ignore file , from what I can tell, needs to exist in the directory you're targeting for it to be recognized, not the current directory. If you're searching in .src, the file would need to be there for it to work.