the lack of touchscreen support is an odd omission considering both games previously appeared on 3DS and Wii U,
.
the lack of touchscreen support is an odd omission considering both games previously appeared on 3DS and Wii U,
.
Every player I've introduced this game to has looked at me as if to say, "We must be doing something wrong." But no, that game is designed that way.
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.
How is the phrase
including the production of meaning used in this article, yet the word "semantics" does not appear even once?
At least https://en.wikipedia.org/wiki/Meaning_(semiotics) ("semantics" appears exactly 1 time in that article) has a link to the article on semantics.
Seems like a missed opportunity to answer what to me is a very first immediate question that I wonder (and now I wonder if it really is a FAQ or if it's just me who wonders): how is semiotics different from semantics?
But I guess https://en.wikipedia.org/wiki/Semiotics is a better place to look for that answer, and it answers that when it says:
he defined semiotics as grouped into three branches:
Athena is still in production use at MIT. It works as software (currently a set of Debian packages)[2] that makes a machine a thin client, that will download educational applications from the MIT servers on demand
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?
So, despite your code is type safe it is not safe to be used.
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.
@conference_form.submit(conference_params)
Surprised they called it submit, since that could imply that you're triggering an action called submit.
They use other verbs to describe this:
Analogous to Reform's sync / sync_models method.
Actually, the name makes a lot of sense when you see it in context:
@conference_form = ConferenceForm.new(conference)
@conference_form.submit(conference_params)
if @conference_form.save
100vw is 100% of the viewport width not accounting for scrollbars (unless the root element has anything other than overflow: auto set, but auto is the default value). Thus, when the page content overflows the viewport vertically, the browser renders the vertical scroll bar, which reduces the visible viewport area by a few pixels. But the 100vw value doesn't update to account for this, so the selected div retains the same width as before the vertical scrollbar appeared. This results in the horizontal scroll bar rendering.
Now, however, you set width:100vw and that is going to be (in this case) 100% wide (viewport wide) + the vertical scrollbar width. That’s too wide. That induces the HORIZONTAL scrollbar.
This is funny because it’s unexpected. Cache invalidation sounds like a hard thing, while naming sounds more straightforward. The joke works because it violates our expectation that hard things should be technical. It’s also funny because it’s true.
In 2025 we plan to
Surely this is a typo and should have said 2020? Nobody would make such a specific tech plan for 5.5 years in the future ... would they?
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;
Wouldn't expect the solution to "width grows too wide" to be to assign a (seemingly meaningless, since how could it be less than 0) a minimum width of 0.
I would have expected to solve this by applying a max-width to the problem element or one of its ancestors.
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.
But now Chromium is no more available as deb, so what to expect ?
Note that when using sass (Dart Sass), synchronous compilation is twice as fast as asynchronous compilation by default, due to the overhead of asynchronous callbacks.
If you consider using asynchronous to be an optimization, then this could be surprising.
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 came up with this solution by piecing together man pages and random google result. I was surprised at how many incomplete and inaccurate answers were out there. What may have been more surprising was the complete lack of a full intact solution.
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.
Library author here. I'm always fascinated by new ways people can invalidate my assumptions. I mean that in a sincerely positive way, as it results in learning.
My version of https://svelte.dev/repl/9c7d12357a15457bb914705702f156d1?version=3.19.2 from https://github.com/sveltejs/svelte/issues/4586
to try to simplify and help me understand it better.
So the lack of synchronousness is only noticed inside handleClick.
By the time the DOM gets updated, it has a consistent/correct state.
In other words, the console.log shows wrong value, but template shows correct value. So this might not be an actual problem for many/most use cases.
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?
You can imagine how big of a surprise was finding out that model/character being a child of model/node causes an error when we import model/position.
To fix our Svelte version you might think we could use beforeUpdate or afterUpdate, but these lifecycle functions are related to the DOM being updated, not to prop updates. We only want to rerun our fetching when the album prop is changed.
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.
Now I know what you're thinking, "this is an atrocity, what a horrible mess!" and you're right, it's kind of ugly. In fact it's just about impossible to think this is a good idea the first time you see it — you have to actually try it.
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
yup.object.default({ number: 5 }); // object will be cloned every time a default is needed yup.object.default(() => ({ number: 5 })); // this is cheaper
Cloning an object is considered expensive?? Why?
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.
Nevertheless, this is quite confusing and has lead to a recently reported issue on the Webpacker GitHub repository.
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.
How is this okay??
When would it ever be the desired/intended behavior for a raise ActiveRecord::Rollback to have absolutely no effect? What good is the transaction then??
What happened to the principle of least surprise?
Is there any reason we shouldn't just always use requires_new: true?
If, like they say, the inner transaction "become[s] part of the parent transaction", then if anything, it should roll back the parent transaction too — not roll back nothing.
You might not care today, but your approach doesn’t allow you to have multiple spaces (Philippines 6014), leading spaces, trailing spaces, or tabs.
Chances are that you think that you can compile a Ruby binary on a certain OS, and that users using that same OS can use your Ruby binary. Not quite. Not even when they run the same OS version as you do.
If we find that GitLab doesn't work as people expect, the documentation should be updated so this is no longer a surprise. This applies whether we classify it as a feature request or a bug.
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.
Capybara and Webrat use some of the same method names which leads to runtime collisions that reveal themselves in confusing ways.
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 $!.
Legitimate Interest may be used for marketing purposes as long as it has a minimal impact on a data subject’s privacy and it is likely the data subject will not object to the processing or be surprised by it.
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.
"sing aloud," and perhaps because shc diclnot, she crossed the sound barrier long before other women learrrt.rlto fly. Writing for pleasure, she wrote what she pleased
I like how this passage suggests that because Dickinson kept her work private, she was able to progress further than her female contemporaries who, as I read it, were shackled by sociatal expectations of what art is, or how a woman should be writing and therfore could not contend with Dickinson's unfettered imagination--the results of which were largely unrecognized until after her death.
trauma
I love how "disapointment in love" is described as traumatic--it's also interesting how trauma sometimes engenders art--and how lonlieness, heartbreak, and dissatisfaction inspire many to create and can be labled as "traumatic" events or feelings.
WOMEN
I'm amazed at how many words are on this page!