Its a bit tricky because of the ambiguity of how the args get presented. You can see through the little demo the args are presented the same way whether its a straight kwargs or a hash, but the assignment of the args to parameters is different. def foo(*args) puts args.inspect end def bar(x=1, a:2) puts "x:#{x} a:#{a}" end foo(:a => 1) # [{:a=>1}] foo({:a => 1}) # [{:a=>1}] bar(:a => 1). # x:1 a:1 bar({:a => 1}). # x:{:a => 1} a:2

&& nil

BTW to improve the reliability of that test I believe you would need a sleep (smaller, e.g. of 0.1) between the Thread.new and assert M.works?, otherwise it's likely the M.works? runs first and then the other thread will see the constant is autoloading and wait, and anyway that thread does not check what is defined on M. For the test to fail it needs to be the Thread.new running first and defining the constant but not yet the method, before the main thread keeps running and call the method.

A book is defined as a published title with more than 49 pages.

An AI model taught to view racist language as normal is obviously bad. The researchers, though, point out a couple of more subtle problems. One is that shifts in language play an important role in social change; the MeToo and Black Lives Matter movements, for example, have tried to establish a new anti-sexist and anti-racist vocabulary. An AI model trained on vast swaths of the internet won’t be attuned to the nuances of this vocabulary and won’t produce or interpret language in line with these new cultural norms. It will also fail to capture the language and the norms of countries and peoples that have less access to the internet and thus a smaller linguistic footprint online. The result is that AI-generated language will be homogenized, reflecting the practices of the richest countries and communities.

Because I am as interested in the attitudes and assumptions which are implicit in the evidence as in those which were explicitly articulated at the time, I have got into the habit of reading against the grain. Whether it is a play or a sermon or a legal treatise, I read it not so much for what the author meant to say as for what the text incidentally or unintentionally reveals.

This can lead to the sending of email to the correct address but the wrong recipient.

Mailgun, with its permanent failure webhook, is sending a message about a permanent failure of that specific message - it is Campaign that is then making a decision to translate this message, about just that one message, into a permanently bounced (suppressed) contact, and blocking all future emails to that contact - based on, what is clearly quite possibly just a temporary failure. It's really the distinction between a single message level (temporary) problem and a (permanent) contact level problem that is being lost with Campaign's current approach.

replacement glyph missing glyph interpretable but unrenderable character

which failed to work because of the trailing slash before the **. Removing the / made it all spring in to life as intended!

No option is perfect here, but a warning seems like a decent compromise unless there's a whole bunch of other plugins that break

It should be | { fallthrough: true } rather than | { fallthrough: boolean } I think (there's no reason you'd have false)

Caution: + continues the statement but not the string. puts "foo"+"bar".upcase gives you fooBAR, whereas puts ("foo"+"bar").upcase gives you FOOBAR. (Whether or not there's a newline after the +.) But: if you use a backslash instead of the plus sign, it will always give you FOOBAR, because combining lines into one statement, and then combining successive strings into one string, happen before the string method gets called.

These callbacks are focused on the transactions, instead of specific model actions.

If I create a model ActiveRecord sends NULL values for every field that is not defined. Postgres dutifully writes the NULL value into the field instead of the default value. Activerecord should either send nothing (preferable) or send DEFAULT.

Use apt as a first choice, but if you're scripting use apt-get. Apt-get has more stable output (meaning that the output format is left alone as much as possible so as not to break scripts which parse that output automatically). Apt-get also has some low-level commands not available in apt.

"Context" manipulation is one of big topic and there are many related terminologies (academic, language/implementation specific, promotion terminologies). In fact, there is confusing. In few minutes I remember the following related words and it is good CS exam to describe each :p Thread (Ruby) Green thread (CS terminology) Native thread (CS terminology) Non-preemptive thread (CS terminology) Preemptive thread (CS terminology) Fiber (Ruby/using resume/yield) Fiber (Ruby/using transfer) Fiber (Win32API) Generator (Python/JavaScript) Generator (Ruby) Continuation (CS terminology/Ruby, Scheme, ...) Partial continuation (CS terminology/ functional lang.) Exception handling (many languages) Coroutine (CS terminology/ALGOL) Semi-coroutine (CS terminology) Process (Unix/Ruby) Process (Erlang/Elixir) setjmp/longjmp (C) makecontext/swapcontext (POSIX) Task (...)

The callback executed by setTimeout is not expected to return anything, it just ignores the returned value. Since once you enter the promise/async world in JavaScript you cannot escape, I was left to wonder what happens when the setTimeout callback returns a promise?

test2 being marked async does wrap your return value in a new promise:

const rejectedP = Promise.reject('-'); const finallyP = rejectedP.finally(); const result1 = rejectedP; const result2 = new Promise(resolve => { const rejectedP = Promise.reject('-'); const finallyP = rejectedP.finally(); resolve(rejectedP); }); we can see that the first snippet creates two promises (result1 and rejectedP being the same) while the second snippet creates three promises. All of these promises are rejected, but the rejectedP rejection is handled by the callbacks attached to it, both through ….finally() and resolve(…) (which internally does ….then(resolve, reject)). finallyP is the promise whose rejection is not handled in the both examples. In the second example, result2 is a promise distinct from rejectedP that is also not handled, causing the second event.

You basically did var a = promise.then(…); var b = promise.catch(…); creating a branch in the chain. If promise is getting rejected now, the catch callback will be called and b will be a fulfilled promise just fine, but the a promise is getting rejected too and nobody handles that. Instead, you should use both arguments of then and write Requirement.create({id: id, data: req.body.data, deleted: false}) .then(requirement => { res.json(requirement); }, reason => { let err = {'error': reason}; res.json(err); });

The differences are subtle

The use of U+212B 'Angstrom sign', which was encoded due to round-trip mapping compatibility with an East-Asian character encoding, is discouraged, and the preferred representation is U+00C5 'capital letter A with ring above', which has the same glyph.

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.

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?

The expect wait command returns more arguments if the spawned process is killed but unbuffer just always returns the 3rd argument.

Some humor is just funny on a surface level, or incorporates words that sound funny. What makes dry humor unique is that it isn't always obviously funny, especially with a deadpan delivery; you often need to think about it. The humor is entirely within the meaning of the words.

STREAMS originated in Version 8 Research Unix, as Streams (not capitalized).

Unfortunately, unlike what is described in SWdream solution, --ignore-missing-args has no impact on vanished files. It will simply ignore source arguments that doesn't exist.

The central decision of the game is when to play your houses. And you didn't even really talk about that.

Few real decisions to make....Not in my experience, either in tile placement or in disk placement. Of possible interest is the thread:Informal experiment: how easy to find "the optimal disk placement" in various positions?wherein we see that even in the second phase, which people often complain is "automatic" or "obvious", the decisions are not necessarily obvious.

Requirement #2 contains an unwarranted assumption. The body needs to flow not around the sidebar, but around the sidebar's position. That may seem like splitting hairs, but it isn't -- because what if there were something floated where we want to put the sidebar? The body would flow around that space. If we could put the sidebar in that same location, we'd have a solution.

In my opinion, the W3C definition is unnecessarily confusing and restrictive. The dictionary definition of aside is "a temporary departure from a main theme or topic", and the spec should just stick to that, rather than introducing subtle distinctions.

I believe the accepted answer is not quite correct. According to the HTML5 working draft, the <aside> element can be used to mark up side notes in certain, but not all cases:

The distinction in computer programming between classes and objects is related, though in this context, "class" sometimes refers to a set of objects (with class-level attribute or operations) rather than a description of an object in the set, as "type" would.

Sometimes lexicography is considered to be a part or a branch of lexicology, but properly speaking, only lexicologists who write dictionaries are lexicographers.

Not to be confused with lexicography.

The "Pluridisciplinary" or "multidisciplinarity" level The genuine cross-disciplinary level: "interdisciplinarity" The discipline-forming level "transdisciplinarity"

In any case signal handling in shells is one of the least reliable and portable aspects. You'll find behaviours vary greatly between shells and often between different versions of a same shell. Be prepared for some serious hair pulling and head scratching if you're going to try to do anything non-trivial.

Also, this code will fail if $$ is not the process group leader, such as when the script is run under strace. Since a call to setsid(2) is probably tricky from a shell script, one approach might be to ps and obtain the process group ID from that.

you really need #!/bin/sh -m for correct behavior of nested subshells. fg, bg, and wait wont work correctly otherwise

The term encapsulation is often used interchangeably with information hiding. Not all agree on the distinctions between the two though; one may think of information hiding as being the principle and encapsulation being the technique. A software module hides information by encapsulating the information into a module or other construct which presents an interface.

Remix occurs when the original meme is altered in some way, while mimicry occurs when the meme is recreated in a different fashion to the original.

I agree that validation is a process that determines the property of validity of a certain object

Often the term intransitive is used to refer to the stronger property of antitransitivity.

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.

When using the exact same Button code, the binding only works for the local Svelte module.

If I, however, copy the content of index.svelte directly into the other project, it works fine. What can I do to fix that?

This is the kind of bug we don't want to have, since it can be subtle, non-obvious, and hard to reproduce.

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

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

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.

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.

Borgia-like