(wheresubjects recall “end-of-sentence words” on a series of sentences)
This would also only measure syntactic memorization not an understand of actual semantics.
(wheresubjects recall “end-of-sentence words” on a series of sentences)
This would also only measure syntactic memorization not an understand of actual semantics.
If one user marks a word as bold and another user marks the same word as non-bold, thereis no final state that preserves both users’ intentions and also ensures convergence
Having "bold" mean some semantics, e.g., important.
Then they merge. Alice does not consider it important, Bob does -> render both. E.g., Bob's "importance" expressed as bold, Alices "not important" as grayed text.
If the context has changed
E.g.,
"Ny is a great city."
Alice removes "great".
Bob wonts to replace it with "gorgeous", by removing "reat" and adding "orgeous".
Having merged:
"Ny is a orgeous city."
Begs for semantic intent preservation, such as "reword great to gorgeous".
Fig. 4
Uhh, I'd imagine "remove" would refer to "bold" annotation.
Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.
Syntactic intent is not preserved.
Conflicts occur not only with colors; even simple bold formatting operations canproduce conflicts
Again, let them capture semantics.
Say, "Alice considers "The fox jumped"" as important. Alice changes mind, only "The" is important. Bob considers "jumped" as important.
Result: Alice considers "The" important. Bob considers "jumped" important.
Consider assigning colored highlighting to some text
Color is meant to convey some semantics. Like "accent", or "important". These semantics can coexist, just like italic and bold.
So a solution may be to: 1. Let users express semantics of their annotations 2. Give user-customizable defaults of how they are to be rendered.
Ensuring, that semantics's render is composable. I.e., it conveys originally asigned semantics.
Furthermore, as with plain text CRDTs, this model only preserves low-level syntactic intent,and manual intervention will often be necessary to preserve semantic intent based on a humanunderstanding of the text
Good remark of syntactic vs semantic intent preservation.
Semantics are in the head of a person, that conveys them as syntactic ops. I.e., semantics get specified down to ops.
Merging syntactically may not always preserve semantics. I.e., one wants to "make defs easier to read by converting them to CamelCase", another wants the same but via snake-case. Having merged them syntactically, we get Camel-Snake-Case-Hybrid, which does not preserve any semantic intent. The semantics intent here are not conflict-free in the first case, though.
Make defs readable
| |
as CamelCase as Snake Case
| |
modify to CC modify to SC
They diverged at this point, even before getting to syntactic changes.
The best solution would be to solve original problem in a different way - let defs be user-specific. But that's blue sky thinking. Although done in Unison, we do have syntactic systems around.
So staying in a syntactic land, the best we could do is to capture the original intent: "Make defs readable".
Then we need a smart agent, human or an AI, specify it further.
we were we were taken both by the the idea of of annotation being an important part of education and also by the approach that you've taken and the leadership you've provided
be taken by sth 我們體會到<某事>,也很欣賞<你們的行動>
`.call` is a shortcut for `.new(args).call`
Which... is confusing because Palette technically does have an index signature Palette is a mapped type, and mapped types don't have index signatures. The fact that both use [ ] is a syntactic coincidence.
Fixes #1037 allow slotted components via making <Component> <Inner slot="foo" /> </Component> as a sugar syntax for <Component> <svelte:fragment slot="foo"> <Inner /> </svelte:fragment> </Component>
If you were to check the return status of every single command, your script would look like this:
Illustrates how much boilerplate set -e saves you from.
Update: Oops, if you read a comment further below, you learn that:
Actually the idiomatic code without
set -e
would be justmake || exit $?
True that.
You can use the match method with the :via option to match multiple verbs at once:
Things that I miss most from Vue:
Arguably what is interesting about Svelte’s approach to state management is not the store itself but the auto-subscription that is possible because of the Svelte compiler. By simply appending a $ to a variable inside of a component, e.g. $myVariable, the compiler will know to expect an object with a subscribe method on it and generate the boilerplate of subscribing and unsubscribing for you.
Links are just <a> elements, rather than framework-specific <Link> components. That means, for example, that this link right here, despite being inside a blob of markdown, works with the router as you'd expect
The proposals are mostly sugar
The $name += '!' assignment is equivalent to name.set($name + '!').
Adams, R. C., Sumner, P., Vivian-Griffiths, S., Barrington, A., Williams, A., Boivin, J., Chambers, C. D., & Bott, L. (2017). How readers understand causal and correlational expressions used in news headlines. Journal of Experimental Psychology: Applied, 23(1), 1–14. https://doi.org/10.1037/xap0000100
But that's a lot of code to write, so Svelte gives us an equivalent shorthand — an on:message event directive without a value means 'forward all message events'.
preventDefault — calls event.preventDefault() before running the handler. Useful for client-side form handling, for example. stopPropagation — calls event.stopPropagation(), preventing the event reaching the next element passive — improves scrolling performance on touch/wheel events (Svelte will add it automatically where it's safe to do so) capture — fires the handler during the capture phase instead of the bubbling phase (MDN docs) once — remove the handler after the first time it runs self — only trigger handler if event.target is the element itself
Why don't you allow a range without end, like (1..)? There are two advantages. First, we can write ary[1..] instead of ary[1..-1]. The -1 is one of the most I dislike in Ruby. It is very magical, ugly, redundant, and disappointing. I envy Python's ary[1:]. I know that ary.drop(1) is slightly fast, but too long for such a common operation, IMO. Second, we can write (1..).each {|n| ... }.
Shorthand attributes It's not uncommon to have an attribute where the name and value are the same, like src={src}. Svelte gives us a convenient shorthand for these cases: <img {src} alt="A man dances.">
toSelf().inSingletonScope()
How does this even work? What does it do?
What is missing is a space between the $( and the following (, to avoid the arithmetic expression syntax. The section on command substitution in the shell command language specification actually warns for that:
This is a very good example of why shell scripting does not scale from simple scripts to large projects. This is not the only place where changes in whitespace can lead to scripts that are very difficult to debug. A well-meaning and experienced programmer from another language, but new to bash scripting, might decide to clean up formatting to make it more consistent-- a laudable goal, but one which can lead to unintentional semantic changes to the program.
Flat, short bash scripts are extremely useful tools that I still employ regularly, but once they begin creeping in size and complexity it's time to switch to another language to handle that-- I think that is what (rightly) has driven things likes Python, Puppet, Ansible, Chef, etc.
Despite the syntactic horrors lurking in shell scripts there is still a beautiful simplicity that drives their use which is a testament to the core unix philosophy.