Choosing the introductory course(s) and language

Much has been left undecided with regard to what Intro CS is going to look like in v9 of the curriculum.
Not wanting to start from scratch (i.e. from my own intuition) in answering this question, I went looking for what experts had to say. I was lucky enough to encounter a dialogue between Yaron Minsky (an experienced industrial developer) and Matthias Felleisen (one of the top academics in computer science pedagogy, and author of How to Design Programs), underneath a blog post on this very subject.
Yaron Minsky:

The first formal programming class I took was COS 217 at Princeton, taught by the excellent (and at the time, I thought, terrifying) Anne Rogers. The course was (and is) taught in C, and the intellectual approach of the class was to start from the machine. Instead of just learning to program in C, we learned about how the machines we were programming to worked. That was where I first encountered instruction counters, stack frames, registers and the memory hierarchy. It was exhilarating.
Where C encourages you to start with the machine, Scheme wants you to start at the mathematical foundations of computation. You don’t need to know what the lambda calculus is to appreciate Scheme’s slim core, and the way in which you can build a rich and vibrant computational world on top of it. That core is expressive enough that it makes it natural to introduce ideas that come up in multiple different languages, including functional and imperative techniques, object orientation, and logic programming.
The classic course in this vein is MIT’s 6.001, also known as SICP, The Structure and Interpretation of Computer Programming. Sadly, 6.001 has been retired at MIT, but the book lives on, and is a worthwhile read even if you took your last CS course years ago.
MIT replaced SICP with a course based on Python, and this reflects a broader trend. As was highlighted by an informal study by Philip Guo, lots of schools now teach Python, particularly for early introductory courses. I have mixed feelings about this choice. Python is a wonderfully friendly language, but that friendliness is bundled together with some problems.
This was made apparent to me in part by my experience with students who chose to code in their interviews in Python. In many ways, Python is the ideal interview language, since its concise and readable syntax makes the constraints of coding on the whiteboard more bearable. But what I saw was that students who learn Python often walk away with a rather rough model of the semantics of the language. You might be surprised at what fraction of students who have programmed extensively in Python can’t guess how Python lists might be implemented, to say nothing of their ability to explain the semantics of language features like generators or decorators.
This isn’t really a knock on Python. After all, there’s something great about a tool that lets you get things done without fully understanding how it works. But in different ways, both Scheme and C encourage you to understand what’s going on from the ground up, and there’s a certain pedagogical power in that. All in, I think Python is a great choice for an early introductory course, particularly one meant for those who aren’t going to end up as computer scientists or full-time programmers. But I’d be leery of using it outside of those circumstances.

Matthias Felleisen:

Yaron, your question -- as stated -- doesn't denote. It needs context. And Bob Muller's "failure" is indicative of this problem.
Let's assume you really mean "teaching programming to young students in high school or in college at the freeman level" and let's accept that we should not send out kids with one programming course into industry because we also don't send out first-semester pharmacists into pharmacies.
Here is what you will want. First, it needs to be a bit of fun. If your first program is print "hello world", these kids can't relate. They haven't seen consoles. They have seen graphical user interfaces, they have seen interactive games (and may have played them) and they have seen animations. A lecturer should show a rocket taking off or a horse bugging going across the screen as the hello-world program, the very first program you ever show.
Second, you are confronting novices. When they get to touch the keyboard, they are guaranteed to do one and only one thing: make mistakes. ALL (note all caps) off-the-shelf languages are geared to give error feedback assuming "adult" programmers (people who know most of the language) are the actual users. Invariably this feedback is weird and incomprehensible to novices. ERRORS MATTER.
Third, the language should frame the problem-solving method. Ergo, you first pick a method that gradually takes students from an empty screen and a problem statement to a program that solves the problem (probably). Based on that choice, you create the language that frames this design story. I fully agree that (rich) types (as found in ML or Haskell) are the fundamental guiding system for design. (I have taught with types since 1992.) That does NOT mean that you need to check those types from the beginning. Why? See the second point. A type system is likely to give horrible feedback when novices do what they do best: make mistakes.
Fourth, the second and third point suggest that you use more than one language. And the third point means that the languages "grow" on the students with the expansion of the design methodology. Naturally this should end in a typed setting like the ones that you propose. Does it have to be OCaml or SML or Haskell? Bob Muller's experience shows that this is not so. You need to create a language that fits.
Fifth, there is no contradiction between choosing "Scheme" and still teaching about "instruction counters, stack frames, registers and the memory hierarchy." When I taught at Rice, my course started with a Scheme-like language and always ended with us writing a complete simulator of a cpu, an instruction interpreter, a memory. Then students would write a loader, a linker, and hand-translate Fortran (yes, oh well) into the asm of the simulated machine -- all while observing the functional design recipes that they picked up in the first 12 weeks of the course.

With that in mind, below I'm listing some ideals I want to strive towards.

Conceptual simplicity: prefer elegant but robust mathematical models upon which complexity can be built later, rather than "easy" (cf. Python) or "natural" (cf. Ruby) models that are fuzzy or confusing when analyzed deeply
Practical simplicity: prefer tools with beginner-friendly syntax (for heaven's sake, NOT JAVA! NOT SCALA!), usability (avoiding both complex IDEs and complicated interaction models like that of Vim), and error messages
Level-appropriateness: valuable features, like type systems, should only be made explicit once the student is ready for them; yet, the student's prior learning should set up the scaffolding for introducing these features later; ideally, the language/tooling scales with the student's progress
Resource richness: there are freely available textbooks, video lectures, and assignments covering the same material, all available in a self-paced manner year-round

My goal now is to evaluate each of the following resources on a spectrum (🙁, 😐, and 😀) based on the above four criteria. I may need help for this since I haven't done all of these course myself.

Harvard CS50
MIT Intro to CS and Python
GT Computing in Python
MIT SICP: course and book (interactive version)
Berkeley 61A: course and interactive textbook
Systematic Program Design: course 1, course 2, and textbook

I will come back later to start adding my own evaluations, but anyone is free and encouraged to contribute their own, to provide feedback on the criteria I listed, or to suggest other intro courses.

I don't have any comment, but I just want to drop another thing to look at. The author of HtDP wrote a paper comparing SICP to HtDP and talking about intro cs classes https://www2.ccs.neu.edu/racket/pubs/jfp2004-fffk.pdf

Thanks @Alaharon123!
The paper you linked reinforces many of the reasons I have for stating the ideals for an introductory course. Broadly, I think the HtDP approach is more appropriate than the SICP approach because absolute beginners need to be told exactly what to do, which the design recipes do well.
Response to Philip Wadler
The paper also references Philip Wadler's critique of SICP: https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf
I think this paper is worth responding to. He likes SICP a lot but his complaints are on the choice of Scheme as its language. He feels that Scheme not having the following features are a problem:

Pattern-matching.
A syntax close to traditional mathematical notation.
A static type discipline and user-defined types.
Lazy evaluation.

(It is worth noting that his experience is based on teaching SICP to undergraduates and teaching Miranda to Masters of Science graduate students in functional programming. Is it any surprise the MSc students fared better?!)
My commentary on these criticisms, in the context of choosing a language and course material for college-level absolute beginners:

Pattern-matching: Disagree. Pattern matching is syntactic sugar for something more complex going on; this complexity should be added later as a convenience, once the student understands how and why it's useful.
Mathematical notation: Partially agreed. It is the one thing that annoys me about using Scheme/Racket as a language for beginners, who have been using infix functions (+ - / ×) since elementary school. On the other hand, the lambda calculus is all prefixes just like Scheme, so it can be useful if you're teaching them side-by-side.
Static types: Neutral. This can work both ways. You can start with a single static unitype (like JavaScript's "any" type) and then gradually add type refinements until you arrive at static multityping, or you can start with static multityping and build more and more general types as needed (which requires user-defined types). I write more about this below.
Lazy evaluation: Completely disagree. Philip Wadler is ridiculously intelligent and he, by his own admission, has no idea what's hard for normal people. Very smart people often have trouble reasoning about the performance of a program written in a lazy programming language. Why should we inflict this on absolute beginners?

More commentary on a student's first language being dynamically or statically typed
One could argue that starting with static types is theoretically preferable for teaching purposes due to research suggesting that the earlier a student gets feedback, the better. (The "feedback" here is type error messages emitted by the compiler.)
However, in practice, the How to Design Programs team uses a dynamically typed language because those compiler type error messages tend to be very novice-hostile.
I would offer another reason why it's better to start with dynamic types: the original lambda calculus was untyped. It was the most expressive of all lambda calculi at the lowest level. Newer lambda calculi were developed later that were less expressive at lower levels, in order to achieve more expressiveness at higher levels.
It was probably easiest for Church to start with the lowest level and then add higher levels later. I would generalize this to suggest that absolute novices will find it easier to move in a similar progression up the expressiveness ladder. Therefore, we should start with something that looks more like the untyped lambda calculus, and then later move to languages that resemble the typed lambda calculus, then System F, etc.

Below is my evaluation of Harvard CS50.
Conceptual simplicity: 😀. (Assuming we limit the course to C.)

Using C is viable as a simple implementation of a language based on the Turing Machine model of computation. Turing Machines are an alternative model of computation, and not very convenient since they can't be written down as a simple language, but they can simulate the lambda calculus.
Many language runtimes and other softwares are implemented in C, so it could serve as the foundation for a very wide variety of future studies.

Practical simplicity: 🙁.

C is very hard to debug, even with all the friendly tooling that CS50 provides. And you will have to debug it some of the assignments, since it's very unsafe to use with almost no compiler help at all.
C uses a syntax extremely foreign to people who only know high school math.

For example, it needlessly redefines equality (=) to mean "(re-)assign this value to this name". This a is valid C expression: x = x + 1. This may look like math, but if interpreted as a math expression, it's utter nonsense.
They refer to these assignable names as "variables", which is confusing because they have almost nothing to do with variables in math.

Level-appropriateness: 🙁.

Although we regularly receive super-positive feedback on CS50, it seems this often comes from people who already have some experience. Our intro course is meant to include both these people as well as absolute beginners. I tentatively suggest CS50 is exclusionary to absolute beginners.

CS50 introduces many different layers of abstraction, perhaps before the student is ready. I think it would be better for a single course to start at one layer of abstraction and gradually move up. CS50 moves up and down a lot.

Resource richness: 😀.

Harvard seems committed to maintaining this course in the long-term and all materials are available easily and for free.

Below is my evaluation of MIT SICP.
Conceptual simplicity: 😀.

Scheme can be thought of as basically a light syntactic sugar over the lambda calculus, so it forms an excellent starting point.
SICP takes the student through gradually implementing higher-level features using very simple constructs.

Practical simplicity: 🙁.

Deal-breaker: the course/book basically leave it to the student to figure out how to install and run the particular version of Scheme they are using.
Scheme uses a syntax that is based on the lambda calculus, but is different from high school math with its frequent use of infix operators. This can be either good or bad, but all things considered it's probably not a big deal.

Level-appropriateness: 😐.

Scheme in and of itself is level-appropriate for absolute novices, but the exercises require math knowledge way outside the scope of introductory computing.

Resource richness: 😐.

Videos and textbook, and graded exercises are available via the interactive textbook. But it is unknown whether the interactive textbook will always be around, and there are no graded exams.

In issue #530 @Pranaybee suggested that we add a course on introductory logic in Intro CS. I am responding here.
A few points:

You suggested a book from Amazon, which might be a good book, but if we recommend a paid resource it has to be supplementary to free resources. Ideally, we would have freely accessible videos, graded exercises, and texts. If that's impossible, at least one complete resource needs to be free while the others are paid.
We do already have a course on logic in the curriculum. Note that it assumes you know set theory, which is taught in Math for CS.
Logic, Math, and Programming have a correspondence. By learning one, you are implicitly learning another.
With that said, there is tremendous value in directly learning systems of logic. But this value is most apparent at more advanced levels, where it's more convenient to first work in directly in a logic, and then use it to implement some sort of type theory. I plan to include more material on logic in some parts of Advanced CS.
At more rudimentary levels, you only need simple logic, which you are learning along the way as needed. For example, some expression reduction/transformation rules in logic (like De Morgan's law) are useful for optimizing hardware designs, but these simple rules are introduced in Nand2Tetris I. If that's not enough, we can link to some supplementary material in appropriate places.

In summary, I don't think it's necessary at all to include a full course on logic in our introduction. However, I encourage you to open issues for any course where you feel you weren't properly prepared in terms of background knowledge on logic, and we can figure out how to resolve those individual problems. I had already studied logic in college before starting Nand2Tetris I, so I was well-prepared and actually worked out (on paper) much of the homework in the concise logic syntax I was familiar with. It's certainly not impossible that others would need such preparation, but I've so far not heard any feedback indicating as such.

From Minsky, above:

students who learn Python often walk away with a rather rough model of the semantics of the language. You might be surprised at what fraction of students who have programmed extensively in Python can’t guess how Python lists might be implemented, to say nothing of their ability to explain the semantics of language features like generators or decorators.

It's a very tall order to get from "hello world" to "generators and decorators" in a one-semester class in Python, especially a first programming class, and as they're language-specific features (and the official position of OSSU is to not teach a single specific language), I'm not sure that level of inquiry is helpful or necessary in an intro class. It's a valid criticism, one that's on a similar level to "CS grads these days can't even code", but I think it tells more about the state of the industry than the goal of any one class.
To be clear, I don't think that was your intention anyway. You're bringing up the "what first language is best?" debate, and as the authors have alluded, the best answer may be "all of them". I'll write some more thoughts on this under separate cover.

The "perfect CS intro class" is a pretty hard problem to solve, because you're trying to teach several things simultaneously:

how computers work on a basic, fundamental level
how to think in machine logic
how to express those thoughts in a way that's comprehensible to both computer and human
how to speak and understand a literal, brand-new language
how to use these building blocks to accomplish something useful

And from an administrative perspective, you want that class to do several things as part of the overall program:

attract and introduce students to the program
be rigorous enough to teach something of use, so students see the value of the larger program
simultaneously, be attainable such that students complete the class and gain a sense of achievement
set expectations for the rest of the curriculum, giving students an opportunity to funnel in or sieve out ("this is for me" vs "this is definitely not for me")

OSSU has additional challenges and requirements, owing to the fact that the materials have to be freely available and that the students are self-motivated and self-paced. MIT can tell their in-seat students "Endure this pain and get your A, in doing so we will forge you into our image". That works great for the kids who got into MIT and have a lot to lose by failing out. MOOC participants can simply bounce out and find another class (or not).
So the responsibility of having to choose a perfect first class is not an enviable one! I solved this problem for myself by taking several of them. And in my estimation, it was not a waste of time; I gained something different from every class. That's not an ideal solution either (though I didn't mind it); there's duplicated effort, but it exposed me to a different number of teaching styles, coding styles and pedagogical choices.
For your consideration:

CS50's early lectures are the best introduction I've found to how computers work on a basic, fundamental level. They do a great job of teaching how to think in machine logic. They also introduce Linux and git very early, something no other class I've taken does. Malan's a charismatic and engaging instructor, and the first few homework assignments are approachable -- but the class gets very monolithic very quickly. (The CS50 AP variant seems like it stays more approachable for longer, but that's  designed as a 36-week class. I would think that's way too long.)
GTx CS1301 does the best job of teaching a language, providing practice in the language, and making its students feel very confident in the language once the class is over. It's the one class I've taken that does the best job of taking students from "zero" to "pretty darn competent" in a language. It left me with the feeling that I can go somewhere else and write useful programs in other contexts -- while that's not a focus of OSSU, I feel it's a worthy endeavor; it made me feel like I'm really learning something from all this effort, which encourages me to keep going. However, the language is a heavy focus of the course, some important abstractions are hand-waved away early on, and the computer science algorithms are mostly saved til the end. All said, I think this course does the best job of teaching how to speak, understand, and express machine logic to those who haven't ever had to before.
MIT's 6.00.1 is a monolith with a lot of treasure inside. Its biggest downside is it assumes that the student knows Python inside and out by Week 2, which is pretty much unattainable for a first-timer -- especially since the class does little to get you there. But it's one of the best classes in teaching how to use programming to accomplish something useful (6.00.2x does this even more, with specific applications in data science -- which is why it's in the OSSU DS curriculum).
I'm now in the SPD/How To Code series. I would never have chosen to learn a Lisp-like on my own, but the program design paradigms I'm learning are a great addition to the OSSU curriculum (and not something I've noticed explicitly in the traditional CS degrees I've considered earning). I'm still working my way through the classes so I haven't formed a complete opinion yet.

So we've got pieces of classes that are individually excellent. I'm not sure what to do with all this in order to get to a "CS intro mega-master course".
I'll submit to you that my wife is currently taking paid intro to CS classes at our local university. Their approach is to teach the language constructs one semester, computer science basics the second semester, and data structures in the third semester. Maybe the intro class doesn't need to be one class...
(and I feel like I've learned more for free than she's paid to learn!)

Since several courses use Python, and I seem to have been knocking it earlier, I want to add some clarifications on my specific thoughts regarding using Python in an introductory context.
Yaron Minsky wrote:

This was made apparent to me in part by my experience with students who chose to code in their interviews in Python. In many ways, Python is the ideal interview language, since its concise and readable syntax makes the constraints of coding on the whiteboard more bearable. But what I saw was that students who learn Python often walk away with a rather rough model of the semantics of the language. You might be surprised at what fraction of students who have programmed extensively in Python can’t guess how Python lists might be implemented, to say nothing of their ability to explain the semantics of language features like generators or decorators.

My major response to this is that, for the purposes of introductory computing, manner of teaching overrides actual knowledge of a language. (In other words, given a sufficiently good teacher, you can teach introductory computing with basically any language. It's just that some are more convenient than others.)
That some beginning Python users appear not to have a crystal clear understanding of their language's semantics may be an inconvenience with Python itself (with which I am not terribly familiar), or it may be a problem with the way it is taught.
You could make the same mistakes when teaching any other language. Let's take singly-linked lists as an example. I think it would be a mistake to teach them without, in parallel (whether before or after showing list literal syntax), defining them in a precise way, in the same way you define any other compound structure as a composition of atomic structures. For example, some materials might first introduce them like so:
type 'a mylist =
  | Empty
  | Cons of 'a * 'a mylist

They would explain what this means and how to use it using other language primitives, for example:
Cons ('a', (Cons ('b', (Cons ('c', Empty)))))

Then, they might show some intermediate form using more typical list syntax with [] instead of Empty and :: instead of Cons:
'a' :: 'b' :: 'c' :: []

And then finally showing the full list literal syntax: ['a', 'b', 'c'].
This kind of progression is basically what I would hope to see in an introductory course — e.g., clear definitions of very common compound structures using simple primitives. If we choose to start on this layer of abstraction, then we shouldn't be concerned with exactly how this is implemented on a lower-level (e.g. using pointers, understanding of which requires a whole new set of hardware-oriented primitives), only with the abstract mathematical structure.
Back to Python: I have no idea how Python lists are implemented (I'm guessing they are dynamic arrays of pointers to PyObjects?), but this doesn't actually matter. How a language is implemented is completely irrelevant in the context of teaching it; a good teaching language may actually need a very complicated implementation!
What's needed is a good teacher. It is perfectly acceptable to tell "lies" about how something works — perhaps pretending that Python lists are singly-linked lists, and using comments to describe the type of these lists since Python lacks user-defined type syntax. (These aren't necessarily "lies", but rather models, which are always, by definition, a simplification of reality.) Then the teacher can later correct the lie once the student has learned the more advanced topics needed to truly understand what's going on.
Some languages are designed to require as few "lies" as possible, and these are more convenient for guiding the teacher, but these languages may not necessarily overlap with the best overall languages for teaching. We have to weight the benefits and drawbacks in every individual case.

@bradleygrant I didn't see your two posts until I posted mine (it took me a while to write) so don't assume anything I said is a direct response :)

Here's a write-up of GTx's CS1301 Computing in Python series (and the beginning of a generalized discussion of Python).
Discussions of Python's conceptual simplicity are over my head at this stage, and I will defer to others.
Practical simplicity: 😐/😀.

Python environment management is notoriously difficult especially for those new to the language. Those who wish to set up their own development environments on their own machines will need to choose between all-in-one containerized IDEs (like Pycharm, Jupyter or Anaconda,) DIY piecepart solutions (pip/venv/text editor), or cloud IDEs like Cloud9 or CodeAnywhere. You need to know how to manage Python before you can write Python.
GTx classes get around this by providing an in-browser coding/learning environment (Vocareum) for concept checks, problem sets and exams. It's robust and works well, but writing in a local text editor is usually more convenient for larger problems.
MIT classes use an MIT-developed homework checker for coding problems. It has a tendency to lag out and eat homework, so keeping a copy on local is highly recommended. It also limits students to 30 checks on homework and 10 checks on quizzes; students are expected to test and develop before turning in assignments.

Level appropriateness: 😐/😀.
I'll defer to @hanjiexi et. al. on what features of a programming language make it a good first programming language pedagogically, but for me, I wanted to quickly get up to speed in a language in wide use in industry, and Python fit the bill for me.

Python is specifically designed to be easy to read, easy to write, easy to understand and easy to debug, with one obvious "right" way to do things. Why it's the one obvious right way could easily be missed by a newcomer.
Python features strong but dynamic typing and autocasting. The features are great when you understand why they do what they do, but without the benefit of having seen a statically-typed language, casting may seem arcane and pointless when the language does it for you occasionally but not always.
Similarly, function/method overloading can be confusing to a beginner. It's not immediately obvious why c = a + b works equally well (but not with equal meaning!) on integers, floats, strings, lists and bools. It also makes it difficult to understand why 5 + True == 6 or why 5 * False == 0 -- these are Python oddities which aren't representative of languages as a whole.
Mandatory whitespace and enforced style standards make it difficult to write unreadable code. Students are encouraged to make intelligent decisions for variable names (though they may not understand how to do that yet, or what makes a good variable name, or why).
Python handwaves away a lot of complexity very early on. This can be a strength or a weakness. For example, seemingly everything in Python is or can become an iterator. It's really handy to iterate over a list by calling for item in mylist. Editing that list in-place is troublesome and you can't explain why until you cover generators, which doesn't usually come up in a one-semester intro class.
"Pythonic" principles can be at odds with intro-class pedagogy. For example, object-oriented sections need to cover getters and setters, which are a completely un-Pythonic way of changing classes. Instructors must make the choice between teaching the universal method or the Pythonic method.
A feature/complication of Python that's completely optional to cover in an intro class is what constitutes an object in Python (essentially, everything) and how objects can be passed between other objects (essentially, however you want). Of note is the concept of passing a function into another function and returning another function out.
In general, despite these complexities and shortcomings, the language is relatively quick to learn and gets out of its own way so you can stop teaching the language and start teaching CS concepts relatively early on.
Python error messages and stack traces tend to be easier to read and understand than anything I encountered in C or Java (granted, that doesn't mean much).

Resource richness: 😀 (specific to GTx CS1301).

There is an excellent online textbook which is included with the edX course.
There is an excellent MOOC-style course on edX with graded quizzes, graded problem sets, and graded exams. Currently, that's the only delivery system for this course. The course is self-paced and starts on-demand, no waiting for a new section to open.
Class lectures are broken into 5-10 minute chunks, and the course has many interstitial coding problems ranging from 3-10 minutes apiece to solve. This gives you a great deal of targeted practice quickly.

Thanks for your help @bradleygrant! Below is my feedback.

The "perfect CS intro class" is a pretty hard problem to solve, because you're trying to teach several things simultaneously:

how computers work on a basic, fundamental level
how to think in machine logic
how to express those thoughts in a way that's comprehensible to both computer and human
how to speak and understand a literal, brand-new language
how to use these building blocks to accomplish something useful

When we had CS50, the scope was indeed this broad in Intro CS. But what we're discussing as part of the broader changes for v9 is to "refactor" our curriculum such that each section has a more focused scope, even creating sub-sections as needed.
I don't think Intro CS should cover in detail how computers work, if by "computers" you mean modern (von Neumann) machines. Modern machines are merely a historical accident; they could have evolved some other way using a very different mechanism. For example, someone once created a computer in Minecraft.
A "computer" can be anything as long as it is simulating a model of computation. The models came first; the machines came decades later. ("Computer" used to actually mean a "human being performing computations", a.k.a. "doing math".)
So I think the Intro CS class should cover how basic computation works, while splitting out how modern machines work in other coursework (since you do have to know this too, after all). We have Nand2Tetris for providing a simplified model of how most contemporary machines work. And we can have a course in Foundations for getting people up to speed on a much, much more basic level.
Regarding "how to think in machine logic": I am not sure what you mean by this, as there is no one thing called machine logic. There are many logics, and there are many possible machines. Perhaps you meant sequential/imperative logic, but machine architectures have been proposed that operate as networks of parallel reduction machines. But I think I am probably just getting too pedantic about your choice of words; I will assume you meant "some logic of any useful language".
My comment on the above is that, if we want to refine what "some logic" refers to, I would prefer (but not too strongly) that the introductory material chosen focuses on combinational logic / functional programming as this provides the most direct transition from high school math.
I say "not too strongly" because people do use imperative style computation sometimes in their day to day lives, such as when sorting objects on a table. But I think it's more complicated (pedagogically) because it leads immediately to a notion of "side-effects", where you start defining what look like mathematical functions, but such "functions", in the process of mapping inputs to outputs, also "do something". It's hard intuitively to find an analog in the real world for this notion, since students have been accustomed so far to keeping math (pure functions) and "doing stuff" (procedures) totally separate.
You have to understand though that I'm speaking in long time scales. Obviously, you know from experience that learning Python on its own as a beginner is very easy, regardless of its divergences from basic math. I'm talking about the overall journey from novice to master. A student's first language impacts how they think tremendously, and later courses (and their lifelong career) can be easier or harder depending on whether they got a very strong conceptual foundation in the beginning. Concretely speaking, if you've spent years writing programs in an ad hoc way (mixing side-effects freely into functions), you will have much less practice with good architectural practices, like confining I/O to the edges of an application and keeping the core business logic clean and de-coupled. (See this video, The Pits of Success.)
In other words, how much convenience do we want to buy in exchange for knowing that we will need to force students to "unlearn" things down the road? It sucks to unlearn things, especially if you absorbed them a long time ago, but it also totally completely sucks to learn the actual lambda calculus itself on day one. Or to be forced to use a weird text editor from the 60s or solve annoying IT problems when all you wanted to learn was computer science.

And from an administrative perspective, you want that class to do several things as part of the overall program:

attract and introduce students to the program
be rigorous enough to teach something of use, so students see the value of the larger program
simultaneously, be attainable such that students complete the class and gain a sense of achievement
set expectations for the rest of the curriculum, giving students an opportunity to funnel in or sieve out ("this is for me" vs "this is definitely not for me")

Yes, yes, yes, and ... sort of! For the last one, I don't want to deliberately funnel people out. They will funnel out by their own choice, but we should discourage this by having a very friendly and engaging intro course. Talent is relatively irrelevant in the long term; any person in good mental health can learn computer science or mathematics.

[CS50] also introduce[s] Linux and git very early, something no other class I've taken does.
These are strictly of practical importance when applying CS, particularly at scale, but at the intro stage they're not applying it yet, they're learning it just on their own computers. So I would count that against CS50's level appropriateness.

For your (very useful!) feedback on GT Computing in Python, for brevity I'll try to respond in a more general way instead of quoting every specific question.
Per one of my previous comments, what matters is how the course handles the teaching of Python, not necessarily Python itself. For example, it is good that they provide an in-browser environment to work around difficulties with using Python locally.
The issues you pointed out with Python are not necessarily deal-breakers. Does the course do a lot of handwaving, or are you only talking about Python? Does the course provide a simplified (largely OOP-free) model of how everything works before introducing the object/class system? If not, does it provide a heavily simplified model of OO?
Autocasting behavior of Python looks terrifying. I have a reasonable (though rough) understanding of dynamic types, but autocasting is very mysterious to me because it isn't clear at all just from reading what an expression like 5 * False is going to produce. To me that expression is meaningless.
Relatedly, the overloading of + also looks really strange. I understand why 1 + 1.1 would convert 1 to 1.0 (returning 2.1) in a language with this feature, since the right-hand side has more precision than the left, but what is going on with using + on anything but a number?

I just opened a Python3 REPL and typed False + False and I was expecting False (since + means "or" in boolean logic), but I got... 0. I'm not sure how that's intuitive to anyone but C programmers.
Using + with strings and lists yields results that might be intuitive to someone who doesn't know programming, but confusing to someone who does. This is a case of "easy", but not "simple".
So my question for you is, how does the course handle teaching this?

From the above you might be starting to gain an intuition for what I mean by "simple" as opposed to "easy". Easy means there is lots of magic going on, but the magic is inconsistent such that it doesn't seem to form a cohesive logic, at least not until you've grasped the entire language and its implementation. Simple means there is no magic, and/or the "magic" (usually just syntactic sugar) that's there is so well designed that you can understand its logic with minimal effort.

The lambda calculus is simple. Its definition fits on a miniature sticky note!
John McCarthy realized the lambda calculus was too simple to be practical, so he created LISP... whose definition fits on a T-shirt!
Simple languages tend to be self-describing, with a small core upon which all the layers of complexity are built.

So, while I can't comment to much detail on how conceptually simple Python might be (without knowing more about it), my real goal here is to learn how the course handles teaching it. I note that Berkeley 61A uses the Python language to teach concepts from SICP, but I haven't actually looked through the course materials yet to see how they're doing it. It could make for an interesting comparison.

Forgot to mention. You can consider practical simplicity to be 😀. And are all course materials and features available for free? If so, resource richness should also be considered 😀.

Let me dig into the course a little bit, I want to give answers I can back up from actual course materials rather than my own impression or memory.
I'd be interested in looking at the Berkeley 61A course (at least, eventually) to see how they approach the SICP material and teach the Python language at the same time.
As a quick aside,

As a quick aside, your statements around Berkeley 61A and "learning to un-learn later" got me thinking.
In a lot of college programs (at least, in the ten or so I've reviewed), that first class serves a dual purpose. To what extent do you want/envision the OSSU v9 intro class to be a pure computer science class vs. a computer programming class?
How much theory, vs. how much "hello world"?
I realize I may actually be asking about the philosophical overview of the intent of OSSU...but that's probably a valid thing to consider.

That's a great question!
In my view, the purpose of theory is to enhance practice. The purpose of practice is [insert philosophy of life here]. Perhaps you wish to enhance the human race, or make money, or whatever. Regardless, you need to do something, and to do something effectively, you need theory to know what to do. Without theory (i.e. thought) we'd still be living in caves!
By analogy, let's say you want to build spaceships. We need math to figure out how spaceships can fly. We need practice to be good at math. Math is theory. So it all starts with theory, but you need practice to understand it. But that actually wasn't an analogy: programming is math. A program is just a long math formula. You need to program over and over again to understand useful formulas / programming patterns.
With all that context out of the way, it should be clear that I consider a computer programming course to be no different from a math course with a heavy focus on exercises/projects.
And that in a nutshell is my eventual goal for OSSU CS. I want it to be as robust in theory as in practice, but right now we still don't have a robust projects/grading infrastructure. I'm trying to make the content more robust before tackling this huge problem.
For various reasons, most schools focus too much on a very superficial interpretation of "practice" without really requiring strong theory, and a small number of schools go overboard with theory without requiring students to actually use it enough for big and cool projects. There are many incidental, political, economic, and social drivers for this, but none of them are relevant to us. We aren't accountable to anyone nor do we have to worry about making money. We don't even need to be popular. I want our curriculum to be respected, which happens to bring some stable, long-term popularity. Short-term popularity is easy to gain (by watering things down) and easy to lose.
An aside: I think I consider print "hello world" to be a pedagogical anti-pattern for being the first lesson in a course for absolute novices. It assumes you are in a Unix-like environment with a terminal and know what "standard output" means. And it's only really amusing to people who get that it's a reference to K&R.
If you are totally fresh to this world, what might you expect to happen? "Hello world" to appear in a pop-up box on the screen? Should the print command actually talk to your printer, and print out a piece of paper that says Hello world on it? Unless you are in a more verbose language where these things are specified (which brings its own problems), why should it appear in a terminal, when print doesn't say anything about a terminal or "standard output"?
It just raises too many questions for my tastes. You have to start somewhere of course, and I think a REPL environment is better for day 1, especially if it's very clean (no type annotations, etc.).

Hi @szaitseff, thank you for your feedback! Also CCing @bradleygrant and @waciumawanjohi
There is tremendous value for sure in CS50, and in learning about C generally. The main issue, as noted above and in many other issues in this repo, is that it is not level-appropriate for absolute novices. This is our target audience for the Intro CS section, and we have to be ruthless in our selection of the right materials.
The question of whether the first course should be focused on computation (via programming) or on surveying the entire field is something that I haven't been able to find solid answers on from computer science education specialists. I currently believe that the former is the better approach overall because hands-on work might get students interested faster than just learning about a bunch of concepts. And it is based on this assumption that I think the curriculum should be refactored to put CS50's introduction to modern technology in Foundations, leave discussion of low-level systems to another later section, and have Intro CS be focused on beginner-level computation.
At this point, I think MIT SICP and CS50 have been definitively ruled out for Intro CS. I believe that if someone evaluates MIT Intro to CS on the stringent Intro CS criteria I named above, that it would likely also get poor results due to not so much teaching Python, as merely assuming that you can quickly pick it up.
The jury is still out between GT Computing in Python, Berkeley 61A, and Systematic Program Design for Intro CS, and on whether there is still a place in our curriculum for CS50. Tentatively, I don't think Berkeley 61A will make the cut simply because it's based on SICP, upon which HtDP is known to be a substantial improvement for beginners. (Although I think SICP is still worth working through afterwards.)
I may have a solution that should reasonably satisfy most students as well as our own desire for a robust curriculum, it's just a little more work to put together. The fact that I want the next curriculum version to include multiple resources for each section so that students can use what is right for them means we don't have to adopt an all-or-nothing attitude.
We can make two sub-sections under Core Programming: Functional Computation and Imperative Computation, and in these, we integrate appropriate pieces of almost all the great material we're discussing here, since for many of them, level-appropriateness is the biggest problem.
Here's what it could look like:
Intro CS
Systematic Program Design

Book: How to Design Programs
Course: How to Code
Brief video/text explaining wider context of CS

Core CS
Core Programming
Functional Computation
Unit 1: Scheme and the Lambda Calculus

First two chapters of the interactive textbook of SICP (we could consider hosting it ourselves to ensure it never disappears), along with MIT's videos
Brief introduction to Alonzo Church's lambda calculus (tutorial, paper, or blog post). Ensures that students aren't ignorant of history.

Unit 2: Typed languages

Course: Programming Languages, Part A
Text: Programming in Standard ML
Video: Propositions as Types (Philip Wadler). This gives a lot of historical and contemporary context.

Unit 3: Metaprogramming

Course: Programming Languages, Part B, with the (IIRC) optional sections on macros required
Text: some parts of interactive SICP, chapter 4

Imperative Computation
Unit 1: Turing Machines

Some text explaining how imperative computation relates to functional computation
Brief introduction (video and text) to Alan Turing's Turing Machines as an alternative model of computation that is equivalent in power to the lambda calculus. Ensures that students aren't ignorant of history.

Unit 2: High-level imperative languages

Course: GT Computing in Python (first 3 parts)
Text: select relevant pieces of the Pythonized version of SICP (?)

Unit 2: Dynamically-typed imperative OO

Course 1: The final part of GT Computing in Python
Course 2: Programming Languages, Part C (need to verify that this extends material rather than just repeating)
Text: select relevant pieces of the Pythonized version of SICP (?)
A small text or video discussing Smalltalk, so that students aren't ignorant of how object-orientation was originally envisioned by Alan Kay.

Unit 3: Low-level imperative languages

Video-based resource: Harvard CS50 (relevant pieces, or students can take the whole course)
Text-based resource: Helsinki C
A small text summarizing history of Dennis Ritchie, C, Bell Labs, Unix

Unit 4: Statically-typed imperative OO

Introductory Java materials
Note: This unit can be moved to Advanced Programming if Core CS doesn't have any sections using Java

Thanks @hanjiexi !
It makes sense to envision and state the target audience when designing and discussing the Curriculum. Is it boys and girls from high school? Then 'How to code' intro would probably be ok.  Or is it people educated in other fields outside CS? Then something more challenging with broader outlook would suit better.  I personally disliked the very slow pace of 'How to code' with (almost) useless BSL and dropped it. If you target a wider public from the whole spectrum, there should be a wider choice of intro, not just rather specific 'How to code'.

The upcoming Foundations (#531) top-level section is going to act as a fall-back curriculum for any student who needs additional background outside of computer science. It offers (very limited) support for those who haven't yet taken high school math, and moves on from there to fill in gaps as needed through physics and college-level math.
If a student were able to take Intro CS and Core CS without ever backtracking to Foundations, this would mean that they (at least) took calculus in high school, or that they have some limited college including calculus. So that should give you a good idea of what the main curriculum is targeting. (If we were really seriously targeting pre-college, we would include Bootstrap's materials which teach algebra through programming.)
We don't however make too many assumptions about whether a student has ever coded before. How to Code will likely be most appealing to absolute novices, but it is extremely relevant for those who took a so-called "computer science" class in high school. I took such classes — I would call them "coding", not CS. It will also have relevance for some experienced developers, but it can definitely be a bit boring for them.
The answer for those who think they are probably too advanced for any course, but aren't sure, is to go straight to the final course project and see if they can do it. If they can't, the course might have something for them. I myself was too advanced already for most of How to Code when I took it, but the design principles were something I'll always carry with me, and the final project was still a challenge.

(almost) useless BSL

Note that usefulness has different meanings in different contexts. BSL can't be used in the real world for the same reasons that it is exceptionally useful as a teaching language.

Controversial opinion ahead.  I am a computer programmer, self-taught, and I love it.  It's where I find my "flow".  And How To Code: Simple Data is making me hate programming, let alone the course.  I'm about half-way through, and I'm trying to persist as I've been told it gets better, or at least so I can give a more thorough review than just "it makes me want to quit", but I'm not sure it should be offered as a "universal beginning course".

Controversial opinion ahead. I am a computer programmer, self-taught, and I love it. It's where I find my "flow". And How To Code: Simple Data is making me hate programming, let alone the course. I'm about half-way through, and I'm trying to persist as I've been told it gets better, or at least so I can give a more thorough review than just "it makes me want to quit", but I'm not sure it should be offered as a "universal beginning course".

+1, I started looking for alternatives almost immediately after taking it.

Hi @KathrynN, thanks for your feedback! It's interesting how the same material produces such different reactions in people.
Given how you described yourself both here and in #516, it sounds like you may be well beyond taking an introductory course, and that the course therefore isn't right for your level. (If your concern about it is actually quite different, I suggest opening a separate issue about it, seeing as the course is currently part of Core Programming.)
So the key point I want to make is that it matters that SPD (HtC/HtDP) is designed for beginners. Beginners need to be taught in a way that is qualitatively different from how those with experience need to be taught.
Put simply, beginners need to be taught not just exactly what to do, but exactly how to do it. SPD fulfills this by providing the beginner with a set of recipes, where the problem statement determines the structure of the data used to solve it, and the student then matches the structure to the recipes, finding appropriate function templates to use for solving the problem. The amount of cognitive load needed for this is kept to a minimum that is believed appropriate for their level.
Later, these recipes get abstracted as students start to recognize patterns in the problem/data relations. Many of them turn out just to be simple functions like map, filter, and fold, which you use every single day in programming (perhaps in other forms).
In contrast, although more experienced students need to be told what to do, they shouldn't necessarily be told exactly how to do it. This gives them an appropriate level of challenge to maintain their interest. The cognitive load of programming itself is lower at this stage, making room for creativity and problem-solving.
It should therefore be unsurprising that students with programming experience would find a beginner-level course very unpleasant. Without extremely clever course design, it is impossible for one course to satisfy both beginners and everyone else.
I am open to suggestions about placing a non-beginner level Intro CS course alongside SPD as an alternative for those with prior experience, but many of the best such materials (e.g. SICP) might already be going into Core Programming.

Hi @hanjiexi  - I'm afraid that isn't my issue with the course at all!
I enjoyed going over the material in CS50, as it introduced a lot of new concepts, a language I'd always wanted to dabble in (C) and reinforced my thoughts around e.g. good design.
I will open a ticket with my thoughts on How To Code and why I think it teaches bad practices in coding, and does so in a way that I believe will put off beginners, and perhaps @gjergjk71 can contribute there.
Sorry to pollute this thread!

Per this comment, I'm re-thinking my approach to Intro CS.
Up until now, my thinking had evolved to the point of wanting two Intro CS courses, of which only one would be required based on background: one for absolute beginners (never coded before) and one for experienced beginners. So I was planning on introducing a new criterion — "beginner suitability" — to the evaluation criteria I mentioned above.
However reality is just more complicated than dividing the world of OSSU students into these two camps. Everyone is coming to OSSU with different backgrounds. And many of those backgrounds need an emotional hook to get them interested in the field. So that means there would need to be another evaluation criteria — like "emotional impact". CS50 probably scores highest on this due to the extremely physicality of the lectures...
So what I'm mulling over right now as a kind of compromise is to structure the curriculum such that Core CS doesn't make any assumptions about what the student may or may not have learned in Intro CS. All the "proper theory" stuff begins in Core CS, and Intro CS is more to get people motivated.
Intro CS, in this scenario, would contain a reasonable set of recommendations based on the community's experience. It wouldn't be one course, but shouldn't be 10, either. I'm envisioning about three course/material recommendations, each with paragraph(s) contributed from community members explaining why a particular course worked well for them. The student picks the intro course which appears most appropriate to their tastes, background, and interests.
This adds a little bit of complexity but I haven't thought of any major downsides that can't be worked around.

I really like this approach. Having multiple entry points, or multiple "good first course"s, can potentially accommodate people attracted to OSSU for different reasons. You can also entirely sidestep the question of "what's the best first language" by (potentially) supporting introductory courses in (for instance) Python, C, and JS. The candidate can then self-select into the class they think they'll find most relevant in their near future, guided by the testimonials of those who have gone before.
I like this idea. I think it's worth iterating on.

And then of course, once you've convinced them that

they CAN code,
programming helps them solve problems they have,
maybe it's fun,

the hope is from that point, they'll have cultivated a taste for how to code correctly/systematically/intentionally, and see for themselves the value in working through the Core CS set.

Hello, I follow your discussions and I'm wondering when will  the new
curriculum is going to be ready. I want to be a computer scientist , I
didn't manage to go to a university and when I saw the ossu it was very
promising . I have a background in web development and I know is JavaScript
and swift but I still lack the knowledge of the fundamentals like
algorithms, data structures , computer architecture etc.
On Mon, Dec 10, 2018, 7:12 AM Bradley Grant<EMAIL_ADDRESS>wrote:

And then of course, once you've convinced them that

they CAN code,
programming helps them solve problems they have,
maybe it's fun,

the hope is from that point, they'll have cultivated a taste for how to
code correctly/systematically/intentionally, and see for themselves the
value in working through the Core CS set.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ossu/computer-science/issues/540#issuecomment-445688572,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVBvjAqwPULxDaUKWN5oGnF1VWY84tegks5u3e00gaJpZM4Yz55V
.

Hi @TasosPoursaitides, I am hoping to have the new version finished by the end of 2018, though it's a pretty ambitious goal given how little time is left. However, it's not completely new, but rather it's building on what we have now. The algorithms courses aren't going anywhere and neither are the courses they depend on (Calculus 1 + Math for CS), so I encourage you to dive right in. No need to wait on a new curriculum version.

Lots of great thought here. It has led to an RFC on adding Intro to Programming options to the beginning of the curriculum. Comments welcome! https://github.com/ossu/computer-science/issues/589


API referene link is throwing a 404 error on riverpod.dev/docs

Describe what scenario you think is uncovered by the existing examples/articles
API referene link in the last line of "What to read" section is throwing a 404 error.
Link: https://riverpod.dev/docs/concepts/reading#deciding-what-to-read
Describe why existing examples/articles do not cover this case
It's a broken link
Additional context
Tried it on Chrome jus tto make sure and it's still thorwing 404 error.

Thanks for the report!


[POTENTIAL ISSUE] Potential Breaking on 14.0.0 Update.

NOTES
This is more a reminder for me to investigate this potential issue when the latest Atmosphere and Hekate get released...

Tested on Atmosphere 1.3.0 Pre-release (found here), Hekate v5.7.2 (found here) and HOS 14.0.0.
It works. There are a few things which I might need to iron out, but it works.
For now, I recommend downloading boot sounds from Zedge.


Touch up drawing toolbar

[ ] Add undo redo
[ ] Fix experience on iOS

superseded by: https://github.com/lockbook/lockbook/pull/2280


fix dev-dependencies sec issues

Coverage remained the same at 100.0% when pulling 51f1585efb9e5e854a6a7103d50788b4ce184d9e on v2.3.2 into 9f4a16547cbe4e4df461d8d67eb12b06980d42aa on master.

Coverage remained the same at 100.0% when pulling 51f1585efb9e5e854a6a7103d50788b4ce184d9e on v2.3.2 into 9f4a16547cbe4e4df461d8d67eb12b06980d42aa on master.

Coverage remained the same at 100.0% when pulling 51f1585efb9e5e854a6a7103d50788b4ce184d9e on v2.3.2 into 9f4a16547cbe4e4df461d8d67eb12b06980d42aa on master.


Fix the race between configuring cbr0 and restarting static pods

The pr is based on #10153. It doesn't execute any podSpecs until network configuration is done no matter it is master nodes or minion nodes, the detail can be found at  https://github.com/GoogleCloudPlatform/kubernetes/pull/10153#issuecomment-113729964.
Fixed #10122 and fixed  #9822.
Since I couldn't reproduce either  #10122 or #9822 on GCE, I run cluster/kube-down.sh && hack/dev-build-and-up.sh && gcutil ssh kubernetes-master sudo docker ps -a for 10 times, and make sure there are no docker containers (kube-apiserver, etcd, pause...) killed at the booting time.

cc/ @brendandburns @zmerlynn @cjcullen @roberthbailey
GKE folks, I think the last commit I added here: eb3c8ae92c5cbd7a5ab8a097a805302465ca16c2 is good enough to eliminate most of unnecessary restarting of master component pods caused by docker upgrades / flag changes. We could only patch this commit into v0.19.4, and leave rest of to v0.20 for more soaking time. How do you guys think?
Also please note that there is still a potential race between configuring cbr0 and starting static pods by pre-installed kubelet in containervm image on minion nodes until the fixing in this pr is included in our image. The only static pod left on minion nodes on GKE / GCE is fluentd, and I haven't heard any issue on restarting them, so I leave them untouched here.

ok to test

We haven't seen any issues restarting fluentd on the node machines.

We also don't really monitor fluentd restarting on the node machines, do we?

The flip side of this conversation is that if it solves a real problem, eb3c8ae92c5cbd7a5ab8a097a805302465ca16c2 is so surgical that I'm honestly quite willing to take it for a 0.19.4 with very limited qualification.
The rest of this PR, it would be nice to get into HEAD today, and maybe we can let it sit for today before we cut 0.20 tomorrow?

@roberthbailey and @a-robinson I also don't see any issues caused by fast restarting fluentd on the node machines. Also last commit https://github.com/dchen1107/kubernetes-1/commit/eb3c8ae92c5cbd7a5ab8a097a805302465ca16c2 I introduced here will eliminate most of killings at the boot time too. I thought it is worthy mentioning it here since there is still a little chance of killing at minion nodes at boot time. :-)

Addressed all comments, PTAL? Thanks @roberthbailey @zmerlynn!

Revert that unnecessary line. PTAL?

LGTM.

@zmerlynn any further comments?

@alex-mohr or @davidopp or @lavalamp Can I have one more TL lgtm from you guys? We want to include this into v0.20 release and get some soaking time. Thanks!

LGTM

LGTM -- thank you so much dawn!


Joining many-to-many data after an .eager() query

I have 4 tables users, playlists, genres and playlists_genres. playlists_genres is a table that contains playlist_id and genre_id. I'm currently successfully querying a user by their id and returning all their associated playlists:
  User
    .query()
    .where('id', 1)
    .first()
    .eager('playlists')
    .then((user) => {
      console.log(user);
    })

However I'm wondering what would be the best way to then populate the returned playlists with their respective genres that sits in the genres table. I have tried chaining eager queries but to no luck.

If your relationMappings are set up correctly you can simply do this:
  User
    .query()
    .where('id', 1)
    .first()
    .eager('playlists.genres')
    .then((user) => {
      console.log(user);
    })

Since you probably already tried that, there must be something wrong with the Playlist model's realationMappings.genres definition. Can you post the Playlist model here?

Thanks for the speedy reply.
Here is the relationMappings from my Playlist model
  static get relationMappings() {
    return {
      user: {
        relation: Model.BelongsToOneRelation,
        modelClass: User,
        join: {
          from: 'playlists.user_id',
          to: 'users.id'
        }
      },
      genres: {
        relation: Model.ManyToManyRelation,
        modelClass: Genre,
        join: {
          from: 'playlists.id',
          through: {
            from: 'playlists_genres.playlist_id',
            to: 'playlists_genres.genre_id'
          },
          to: 'genres.id'
        }
      }
    };
  }

Looks good to me. The problem is somewhere else. Can you create a simple standalone app I can run that reproduces your problem?

Sure, Ill put something together now

I managed to fix it. The issue was that I was setting a many-to-many relationship within my Genre model too. As soon as i commented out this code within that model it worked as expected. Thanks for your help
static get relationMappings() {
   return {
     playlist: {
       relation: Model.ManyToManyRelation,
       modelClass: Playlist,
       join: {
         from: 'genre.id',
         through: {
           from: 'playlists_genres.genre_id',
           to: 'playlists_genres.playlist_id'
         },
         to: 'playlist.id'
       }
     }
   };
 }

You can define the relation from both directions and you need to if you want to create the query from the other direction. You probably have a circular dependency. Try to move the require('Playlist') inside the relationMappings() getter in Genre.


unit testing fails when define has been proxied/ abstracted, etc

Your environment
OS : macOS 12
Node.js version : 16.13.2
suitecloud-cli version : 1.3.1
Terminal/CMD tool : iTerm
Describe the bug
unit testing module does not support a customized define
To Reproduce
Steps to reproduce the behavior:

create a module like this:

const x = define;
x([], ()=>{
});

test with suitecloud

Actual Behavior
ReferenceError: define is not defined

Expected Behavior
that should work. While this is a contrived example it's based on something real.  we have define conditionally wrapped in node because we were doing unit testing in the past (before suitecloud solution) came along and needed a way to test them
Additional context
how are you executing this if define does not exist?

i opened this issue for you guys.  Can you try it? or how can i try it with your package?

Hi @gillyspy ,
Thanks for reporting this. We will investigate this when we can and get back to you.


icu4c 74.2 php-zts

Update php-zts

:beers: @BrewTestBot has triggered a merge.

:beers: @BrewTestBot has triggered a merge.


cEUR ContractKit support

Description
Adds StableTokenEUR and ExchangeEUR wrappers.

Adds Erc20Wrapper, which wraps the required functions of ERC20 tokens found in the IERC20 interface
Adds CeloTokenWrapper, which extends Erc20Wrapper and wraps functions in the ICeloToken interface. Although ICeloToken itself doesn't extend IERC20, it's intended to be used alongside IERC20, and having CeloTokenWrapper extend Erc20Wrapper is easier to get around TypeScript not supporting multiple inheritance (eg class StableTokenEURWrapper extends CeloTokenWrapper, Erc20Wrapper isn't possible)
Creates BaseStableTokenWrapper, which is a subclass of CeloTokenWrapper, and a superclass of the existing StableTokenWrapper and the new StableTokenEURWrapper
Creates BaseExchangeWrapper, which now contains logic that used to exist in ExchangeWrapper, but now has function names that are currency agnostic-- eg instead of functions having usd or dollar in the name, stable is used. This is a superclass of the existing ExchangeWrapper, which still contains the usd-specific function names that are aliases to the generic "stable" functions. A new class ExchangeEURWrapper was created.
Pulled out common tests for Exchange and StableToken into base files that are now also used for ExchangeEUR and StableTokenEUR
Changed some logic in kit.ts to make adding new stable tokens easier

Other changes

There are a couple exported interfaces that are used by BaseStableTokenWrapper and BaseExchangeWrapper that used to live alongside StableTokenWrapper and ExchangeWrapper (eg InflationParameters and StableTokenConfig). I moved these because it felt like they should live with the base wrappers, which isn't entirely backward compatible, but am open to leaving them for backward compatibility. Looking for input here!
Using a new version of @celo/typechain-target-web3-v1-celo to properly generate TS files for interfaces
Added stableTokenEUR to migration overrides for tests to work

I did not update packages/sdk/base/src/currencies.ts to include cEUR as only Valora relies upon that, and adding cEUR there caused a bunch of build issues that can only be resolved with code changes to support cEUR in Valora.
Tested

Ran tests
Ran against a testnet with cEUR

Related issues

Fixes #6365

Backwards compatibility
See Other Changes

@gastonponti thanks for the review!
Re:
const stable = kit.contracts.getStableToken()
stable.transfer(StableToken.cEUR, to, value)

Personally I like the 1 wrapper instance : 1 contract relationship that (to my understanding) we've kept throughout contractkit. Because StableToken (cUSD) and StableTokenEUR (cEUR) are different contracts, I think it'd be confusing to have a single wrapper be able to reference both contracts. It'd probably involve a bigger refactor due to BaseWrapper having this.contract and things that only make sense for a single contract (like get address(): string). Additionally I think the ERC20 interface of things like transfer(to, value) are pretty standard and modifying that in contractkit to instead be transfer(token, to, value) feels a little weird and could cause devs to misinterpret the wrapper as referencing a single underlying contract that has a function transfer(token, to, value). Overall I think ContractKit should be a friendly wrapper for dealing with contracts as if they were a nice TS objects, and it should generally try to expose functions to consumers directly, with small exceptions like calculating values that must be passed as a parameter correctly (thinking of SortedOracles calculating the lesser/greater for inserting here). Another reason I prefer transfer(to, value) relates to why I included the Erc20Wrapper-- we're already starting to see some small scale ERC20 tokens come to Celo, and it feels appropriate that people can interact with any ERC20 token via contractkit super easily if they want. Having the ability to use contractkit to transfer cUSD/CELO/UBE/MOO/whatever with the same interface is super useful-- thinking about things like arb bots for Ubeswap, or future liquidation bots for Moola, etc
I do really like your suggestion of something like:
const stable = kit.contracts.getStableToken(StableToken.cEUR) // and have StableToken.cUSD be the default for backward compatibility
stable.transfer(to, value)

That way we keep the 1:1 wrapper/contract relationship, and as we add future stabletokens we don't need to add getStableTokenARS, etc. Do you have an opinion if this means we should keep the class StableTokenEURWrapper or if we should keep with the single class StableTokenWrapper and then have cUSD/cEUR/etc be instances of that wrapper? Personally the latter approach feels cleaner, but if we do that then I think it makes sense to do the same for ExchangeWrapper. There's the annoying bit with the Exchange having some USD-specific function names. We could possibly keep those as aliases but encourage people to use the functions using "stable" instead

Agree. I think that we added a lot of methods in these two (stable and exchange) thinking that would be easier to read, instead of thinking about the better solution for N of those stables. I would keep it as aliases, and encourage to use the others, until we could eventually deprecate them.
Also agree on the Wrapper 1:1 but I also keep finding useful a way to handle all the stables at once. Maybe could be a helper or another class, that could keep your selected stable coins, and let you do stuff like show all the balances, or try to pay this X tx with one of these stables in a order [cUsd, cEur, cXXX] and send the tx from the first stable that could be cover the cost (I don't know, there are probably a lot of possible interactions between stables, and we should have something for that)
But I agree that shouldn't be what we use as the concept of wrapper

And even knowing that this could be part of a different feature, I'm already seeing those kind of interactions that you added in the kit. So maybe extract it into some helper could be a really good first step


brew config: output of curl path and version

[X] Confirmed this is a problem with running a brew command and not brew installing or the post-install behaviour of one or more formulae? If it's a formulae-specific problem please file this issue at the relevant tap e.g. for Homebrew/homebrew-core https://github.com/Homebrew/homebrew-core/issues/new
[X] Ran brew update and retried your prior step?
[X] Ran brew doctor, fixed all issues and retried your prior step?
[X] Ran brew config and brew doctor and included their output with your issue?

Output of brew config:
-bash-4.4.12- /Users/miccal [> brew config
HOMEBREW_VERSION: 1.3.6-190-ge300713
ORIGIN: https://github.com/Homebrew/brew
HEAD: e300713f253029ef91a86bc4006d316582fc6d13
Last commit: 31 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 09c4dd5f89931a49fb2679df3ad05d38b96372e1
Core tap last commit: 4 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEVELOPER: 1
HOMEBREW_NO_ANALYTICS: 1
HOMEBREW_NO_AUTO_UPDATE: 1
CPU: quad-core 64-bit broadwell
Homebrew Ruby: 2.3.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.0 build 900
Git: 2.15.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Perl: /usr/local/bin/perl => /usr/local/Cellar/perl/5.26.1/bin/perl
Python: /usr/local/opt/python/libexec/bin/python => /usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/local/bin/ruby => /usr/local/Cellar/ruby/2.4.2_1/bin/ruby
Java: 1.6.0_65-b14-468
macOS: 10.13.1-x86_64
Xcode: N/A
CLT: <IP_ADDRESS>.1.1506734476
X11: 2.7.11 => /opt/X11

Output of brew doctor:
-bash-4.4.12- /Users/miccal [> brew doctor
Your system is ready to brew.

To help us debug your issue please explain:

What you were trying to do (and why)

I was reviewing the output of brew config after noting that the PR https://github.com/Homebrew/brew/pull/3420 added the output of the curl path and version to brew config, as shown below:
Curl: 7.54.0 => /usr/bin/curl

What happened (include command output)

The output of the curl path and version is not correct on my system, as I use a brew'ed curl:
-bash-4.4.12- /Users/miccal [> which curl
/usr/local/opt/curl/bin/curl
-bash-4.4.12- /Users/miccal [> curl --version
curl 7.56.1 (x86_64-apple-darwin17.0.0) libcurl/7.56.1 SecureTransport zlib/1.2.11
Release-Date: 2017-10-23
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets

Note that I have the following added to my .bash_profile:
export PATH="/usr/local/opt/curl/bin:$PATH"

What you expected to happen

Question: Should brew config output the correct curl path and version?

Step-by-step reproduction instructions (by running brew commands)

If you are not using the system curl, check the output of Curl: in brew config.

This is correct, Homebrew does not use the brewed curl unless the system one is too old.

Thanks @MikeMcQuaid. Another question if I may - I have note set either of the environment variables HOMEBREW_PREFIX or HOMEBREW_NO_AUTO_UPDATE, and they do not appear when I printenv. Obviously setting HOMEBREW_PREFIX is automatic, but why is HOMEBREW_NO_AUTO_UPDATE set in my brew config if I have not personally set it?

@miccal Nice spot; that was reuse of a variable and will be fixed in https://github.com/Homebrew/brew/pull/3435.

@MikeMcQuaid I have a related question to this issue - I was reviewing the output of brew config after https://github.com/Homebrew/brew/pull/3482 was merged, as shown below:
HOMEBREW_VERSION: 1.3.8-46-gf50ae44
ORIGIN: https://github.com/Homebrew/brew
HEAD: f50ae449800c85b53910bf294b9271c45c25da01
Last commit: 3 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: fc480fcce726cfbeec342b1323a71f89c2cec4ba
Core tap last commit: 5 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEVELOPER: 1
HOMEBREW_ENV_FILTERING: 1
HOMEBREW_FORCE_BREWED_CURL: 1
HOMEBREW_NO_ANALYTICS: 1
CPU: quad-core 64-bit broadwell
Homebrew Ruby: 2.3.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.0 build 900
Git: 2.13.6 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.56.1 => /usr/local/opt/curl/bin/curl
Perl: /usr/local/bin/perl => /usr/local/Cellar/perl/5.26.1/bin/perl
Python: /usr/local/opt/python/libexec/bin/python => /usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/local/bin/ruby => /usr/local/Cellar/ruby/2.4.2_1/bin/ruby
Java: 1.6.0_65-b14-468
macOS: 10.13.1-x86_64
Xcode: N/A
CLT: <IP_ADDRESS>.1.1508540944
X11: 2.7.11 => /opt/X11

I notice that setting HOMEBREW_FORCE_BREWED_CURL now reports that the brew'ed curl is in use, but I also note the addition of HOMEBREW_ENV_FILTERING: 1 as a consequence of https://github.com/Homebrew/brew/pull/3487, and I also note that now brew config is reporting
Git: 2.13.6 => /Library/Developer/CommandLineTools/usr/bin/git

where before
Git: 2.15.0 => /usr/local/bin/git

and on my system
-bash-4.4.12- /Users/miccal (33) [> which git
/usr/local/bin/git

Is this a consequence of HOMEBREW_ENV_FILTERING: 1, and is this the intended behaviour?
Thanks.

Try export HOMEBREW_GIT=/usr/local/opt/git/bin/git

@ilovezfs thanks, I realise I can do that, but the point is that this has changed very recently, I assume with the merging of https://github.com/Homebrew/brew/pull/3487, and wondered if this was intended.

/usr/local/bin is deliberately filtered out of the PATH, so yes this works as currently designed.

OK, thanks.

@ilovezfs one final question is I may - if /usr/local/bin is bing filtered out of PATH by HOMEBREW_ENV_FILTERING, why are Perl, Python and Ruby not affected in brew config:
Perl: /usr/local/bin/perl => /usr/local/Cellar/perl/5.26.1/bin/perl
Python: /usr/local/opt/python/libexec/bin/python => /usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/local/bin/ruby => /usr/local/Cellar/ruby/2.4.2_1/bin/ruby

Sorry for the query, just curious!

Those requirements use Requirement#which or Requirment#which_all, which use ORIGINAL_PATHS. The git requirement uses Utils::git_available?, which doesn't.

Great, thanks again @ilovezfs.

@miccal: i came across this thread and was wondering:

is it possible to specify custom perl, python, and ruby binaries for brew to use?
if the answer to the previous question is yes, then how it can be done? (maybe something similar to HOMEBREW_GIT)

thanks.

is it possible to specify custom perl, python, and ruby binaries for brew to use?

Yes.

if the answer to the previous question is yes, then how it can be done? (maybe something similar to HOMEBREW_GIT)

Build from source with --env=std. Note that this is not tested and we will not fix any issues that arise using this.


a2ps: fix build

Motivation for this change
https://hydra.nixos.org/build/41788034
https://hydra.nixos.org/build/41788034/nixlog/3
@fpletz there something really weird with this one. Like hydra, I had build breaks with the same error. However, the problem comes and goes and sometimes it built fine. Anyhow, hydra confirmed the build breaks without autoconf and my own runs show it also breaks without yacc (unfortunately considering you went through the trouble of patching both the .y and the .c with that last patch)...
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Also, https://hydra.nixos.org/build/41865001 confirms it comes and goes even for the server.

Does this fix it for good?

Does this fix it for good?

As far as I could tell, yes.
You know how make detects object files needing recompilations or not and reports make: `foobar.o' is up to date.and the likes? I'm guessing* parallel \ prolong builds create a date\time deviation between whatever autotools uses to determine this which leads to a parser recompilation. That is, an m4\yacc dependency.
Anecdotally, I've run the the build 20 times with m4\yacc and haven't seen a failure while doing the same without m4\yacc and seeing failures 9/20 times.
Btw, if you have other packages having parallel builds troubles, it will be worth looking at the logs to see similar yacc\m4 issues and adding those there as well. It can potentially save a lot of hydra compute time assuming I'm right about all of this.
*Stressing the "guess" part here since I haven't looked at the code to verify this.

Thank you :)


Is there any way to disable turbolinks history back behavior for one specific page

I have a complex js application on one page with hash navigation. Everything works fine except when I click browser back button. Whole page is reloaded (or is fetch from popState ), and my app is inited twice. Expected that only hash is changed without page reload.
Are there any way to disable turbolinks "back behavior" for one page, or disable it for whole site?
I've already tried to set

data-no-turbolink to body tag of this page, to link, which follows this page,
data-no-transition-cache to body tag on all pages
Turbolinks.pagesCached(20); in js file for all pages
turbolinks github version instead of gem
It's seems to me, I've managed to disable turbolinks for this page, but history back still reloads page instead of a hash change(

I had the same problem when working with backbone router. No hacks found on blogs/stackoverflow worked for me as the logic was quite complex. Using master branch fixed the issue for me and not routing works out of box, because no unnecessary events get triggered.

I have the same problem too.

For me switching to 3.0 from master fixed the issue, no hacks needed any longer.

Thxs! It works now


Add example file

Posting for reference. Will chop it up and add to the appropriate sections in the docs.

Reviewing this in #9


FEAT: Delete user

Part of https://github.com/mazipan/tanyaaja/issues/3
Description

Add middleware to handle Authorization
Add methods to Archive a Page and Delete Questions by uid
Add endpoint to DELETE user

📝 As stated here,

Native Node.js APIs are not supported

that's why there is a new package added next-firebase-auth-edge as a workaround.

I need to review #129 first ya.
Still not have a time to properly setting up the Firebase Admin.
Maybe next week 🙏


Add migration-like status overview of the tasks

a feature I've been missing in After Party. 🎉

@theSteveMitchell Any reason not to merge this?

absolutely no reason!  Sorry I ignored.  Pushed version 1.10.0 with this change


MAS 1.3.1: Form elements must have labels (.task-list-item-checkbox[type="checkbox"])

Markdown task list has the following accessibility issue that is reported on running the KerosForWeb tool to find the accessibility.

Issue Details
Form elements must have labels
label
Element Path
.task-list-item:nth-child(1) > .task-list-item-checkbox[type="checkbox"]
Snippet

How to fix
Fix any of the following:

aria-label attribute does not exist or is empty
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
Form element does not have an implicit (wrapped)
Form element does not have an explicit
Element has no title attribute or the title attribute is empty

To reproduce
Use K4W to investigate the issue details
Environment
Chrome version 69.0.3497.100
This accessibility issue was found using Keros for Web

Close as not related to this project


Update cs fixer rules

Add the cs fixer rules to add the following:

[x] Change double quotes to single quotes when no escape characters or variables are used within the string.
[x] Single space after cast, ex: (int)$var to become (int) $var
[ ] Implicit else: If an else block contains only a return or throw statement, then it should be executed implicitly.
[x] Prevent rogue empty lines.
[ ] Soft/hard limits on comments
[x] Space around the arrow in array declarations.
[ ] Variable naming conventions to use camel case - i.e. $pageNum instead of $page_num
[ ] Function naming conventions (underscore to divide words) - to be confirmed if isn't already working as expected
[ ] Proper indentation inside functions, loops etc.

Variable naming conventions to use camel case - i.e. $pageNum instead of $page_num
Function naming conventions (underscore to divide words) - to be confirmed if isn't already working as expected
Proper indentation inside functions, loops etc.

Closing this as we are discussing to unify efforts across multiple repos.


[BugFix] Fix bug mysql display large int type in mysql-client 8.x

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #14127
Problem Summary(Required) ：

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[x] 2.5
[x] 2.4
[x] 2.3
[x] 2.2

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

@Mergifyio backport branch-2.5

@Mergifyio backport branch-2.4

@Mergifyio backport branch-2.3

@Mergifyio backport branch-2.2


Document leaf node / parent node configuration semantics

When using Miniconf to set multiple settings at once, this can result in a single value being configured via multiple topics. We need to define which should take priority in the case where multiple Will messages are configured for a single setting value.
Say for example, a will message is set for:
settings/a/b = 5
and settings/a = {"b" = 6}
Which should take precedence?

One question that will be pertinent is to determine which ordering the Will messages are received after connection with the MQTT broker as well. If ordering is undefined, the client may need to maintain a state of "will precedence" in determining the precedence level of the previous will configuration.

I'd rather leave it to the user to implement consistent settings updates.
With precedence you may have to store dirtiness or even old messages as well. E.g. a low precedence larger scope message coming after a high precedence small scope message.

Alternatively, maybe it's better to specify this in the code: Have an attribute that marks a compound item (I think that only applies to arrays and structs) as being terminal. The default would be to only allow primitive leaf updates.
struct Settings {
    a0: X,

    #[terminal]
    a1: X,
}

struct X { b: i32 }

And the allowed updates would be settings/a0/b = 1 and settings/a1 = {"b": 2}

Might be beter to place the terminal at the struct X definition level and not at the Settings field level.


Update upstream dependency paths

code.google.com no longer exists. Use the rsc repository on github
instead.

Thanks!!

Oops, the PR failed to vendor properly...


fix: Scrollbars appear when opening a FluentMenu

🐛 Bug Report
There was a regression when moving from 4.9.3 to 4.10.1. Horizontal scrollbars appear when opening a FluentMenu.
Before:

After:

💻 Repro or Code Sample
This was the change that introduces the regression: https://github.com/dotnet/aspire/pull/5670
Control on the page with the issue: https://github.com/dotnet/aspire/blob/f7f20e4c12dafa5b4b50c2b42f31cc2b1327fa37/src/Aspire.Dashboard/Components/Controls/AspireMenuButton.razor
🤔 Expected Behavior
No scroll bars.
😯 Current Behavior
Scroll bars appear.
💁 Possible Solution

🔦 Context

🌍 Your Environment

OS & Device: [e.g. MacOS, iOS, Windows, Linux] on [iPhone 7, PC]
Browser [e.g. Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox]
.NET and Fluent UI Blazor library Version [e.g. 8.0.2 and 4.4.1]

Probably caused by the position of the <FluentMenuProvider /> which should be in an HTML section containing a overflow-y. Is it possible in your code?
You can disable the usage of this Provider by adding the UseMenuService="false" attribute. In this case, the menu is drawn at the location of your HTML code.

Is being an a section with overflow: auto ok?
I tested more and found the scrollbars only appear when the browser is zoomed in, e.g. 110% size.

So this can be closed?

Scroll bars shouldn’t be appearing.

Have you tried adding UseMenuService=‘ false’ to revert to the previous usage?

Yes: https://github.com/dotnet/aspire/pull/6039. But it is a temporary fix because the menu can be hidden by splitter areas again.
We need fluent menu provider but not have it add scroll bars.

Yes: dotnet/aspire#6039. But it is a temporary fix because the menu can be hidden by splitter areas again.
We need fluent menu provider but not have it add scroll bars.

OK. Let me take a look

The problem is that the body allows overflow, and with the new FluentMenuProvider, a side effect may be the display of this scroll bar.
You can solve that adding this code in the app.css file
body, .body {
    overflow: hidden;
}

I haven't seen a problem disabling scrollbars in body, as it seems that a layout div adds scrollbars if necessary.

I've found another way to avoid displaying this body scrollbar: using display: fixed.
I will create a PR to include these styles by default in the FluentUI Blazor library, but in the meantime, you can use it.
<div style="position: fixed; bottom: 0;">
    <FluentMenuProvider />
</div>

Thanks, that works.


Set Google reminders instead of send emails to self?

Is it possible to somehow hook into Google Reminders and set native reminders instead of emails to yourself? I don't want to clutter up my inbox with self-emails, but I always loved using Inbox as an easy way to manage my reminders.

@theRealPadster If you're talking about the native reminders in Google Calendar (one of the three options when creating an event: Event, Reminder, Task)... this is unlikely, and probably prohibitively difficult.
I just tried creating one of those reminders from the Calendar app, and they just don't show up in Gmail like they did in Inbox 😢 That means someone would need to implement both creating reminders and retrieving them on time.

I mean the Google Assistant ones, but they're probably the same? And yeah, that's a good point, you would have to rewrite the entire reminder functionality, retrieving on time, and writing, since it's not in Gmail to begin with :/


Add Inline Table

Discussed in https://github.com/jheddings/notional/discussions/65

Originally posted by SwingWatcher November  8, 2022
I'm trying to create an inline table(not database table) using the code below but I've got an error. Can someone tell me how to do it?
    table = blocks.Table()
    row = blocks.TableRow["1| test"]
    task += table.append(row)

I encountered the error below.
NotImplementedError                       Traceback (most recent call last)
Input In [64], in <cell line: 71>()
     73 #task.Timeframe = "90M"
     74 #task.Status = "IP"
     75 #task.Parameters = "NATR=3.15\nFract=2.5"
   (...)
     83 #task += blocks.Heading1["Welcome!"]
     84 #task += blocks.Paragraph["Welcome to the matrix."]
     85 table = blocks.Table()
---> 86 row = blocks.TableRow["1| test"]
     87 table.append(row)

File ~\AppData\Local\Programs\Python\Python310\lib\site-packages\notional\core.py:82, in ComposableObject.__getitem__(self, params)
     72 """Return the requested class by composing using the given param.
     73
     74 Types found in `params` will be compared to expected types in the `__compose__`
   (...)
     78 an exception.
     79 """
     81 if not hasattr(self, "__compose__"):
---> 82     raise NotImplementedError(f"{self} does not support object composition")
     84 # XXX if params is empty / None, consider calling the default constructor
     86 compose = self.__compose__

NotImplementedError: <class 'notional.blocks.TableRow'> does not support object composition

As mentioned in the discussion on #65, notional already supports basic tables.

Reopening this after some testing...  There are some bugs in creating table rows from plain text.


What to do when step 3 gives you a dialog with the last 3 options disabled

In Visual Studio:

Create a new ASP.NET Core Web Application.
Select Web Application from the list of templates.
Select the Change Authentication button and select Windows Authentication.

I tried both VS2017 and VS2019
In 2019 The option "Add connected service" also does not show the "Azure AD authentication" option...

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 401ad9a0-9e51-80a2-5846-82e9790d7257
Version Independent ID: fbc36c26-9992-1f4c-66d3-02f898ee7ec4
Content: Configure Windows Authentication in ASP.NET Core
Content Source: aspnetcore/security/authentication/windowsauth.md
Product: aspnet-core
GitHub Login: @scottaddie
Microsoft Alias: riande

I can't reproduce this. Can you supply screen shots and tell me what you expect?

This is the dialog I see

and I expect to see the option for Azure AD as documented here: https://docs.microsoft.com/en-us/azure/active-directory/develop/vs-active-directory-add-connected-service

and this is what I see when creating a new dotnet core web application:

ASP.NET Core 3 is a pre-release. You'll need to use 2.2 for this.


f.getClientRects is not a function

Is anyone else getting this error with jQuery 3.x ?I have the jquery Migrate in as well, but still get:
jquery.min.js?ver=3.0.0:4 Uncaught TypeError:
f.getClientRects is not a functionoffset @ jquery.min.js?ver=3.0.0:4
a.fn.offset @ jquery-migrate.min.js?ver=3.0.0:2t.(anonymous function) @ jquery.waypoints.min.js?ver=4.0.0:7
e.refresh @ jquery.waypoints.min.js?ver=4.0.0:7
e.refreshAll @ jquery.waypoints.min.js?ver=4.0.0:7
window.onload @ jquery.waypoints.min.js?ver=4.0.0:7

n/m. was using it with Vue.js and the this.$el was a node and not an element.


SASS-1003 - Added CreateOrAmendEmploymentExpensesConnector (DES #1669)

Description
Please include a brief summary of the change you've made and the issue that it fixes.
Add a link to the relevant story in Jira
[SASS-CHANGE-ME](ADD URL HERE)
Checklist PR Reviewer
Before Reviewing

[x]  Have you pulled the branch down?
[x]  Have you assigned yourself to the PR?
[x]  Have you moved the task to “in review” on JIRA?
[ ]  Have you checked to ensure all dependencies are up to date?
[x]  Have you checked to ensure its been rebased against the current version of master?

Whilst Reviewing

[x]  Have you run the tests?

[ ]  Have you looked at the JIRA story to make sure all Acceptance Criteria has been met?

After Reviewing

[ ]  Have you checked for merge conflicts or any changes in the current master that may affect the current pull request? i.e. does it need another rebase?
[ ]  Have you checked to make sure there are no builds in the pipeline before you merge?
[ ]  Have you moved the task to “in pipeline” on Jira?

[x]  Have you rebased against the current version of master?
[x]  Have you checked code coverage isn’t lower than previously?

After PRs been raised

[ ]  Have you checked the PR Builder passes?

Could we look into reusing the existing expensesType as described by Ben. Could we also address the following warns :

We are also missing test coverage on the CreateOrAmendEmploymentExpensesService. I think switching the controller over to an integration test should remedy this.

Finally, could we address the following platform dependancies please.

Resolved, and added a unit test for the service to increase the coverage in that area.


Correct the SM2 handling of DIGEST and DIGEST_SIZE parameters

Only SM3 digest should be allowed with SM2.
Fixes #14873
Checklist

[x] tests are added or updated

I'm not sure about this one.  @InfoHunter, is SM2 ever used with a different digest?  Will it ever be?

I'm not sure about this one. @InfoHunter, is SM2 ever used with a different digest? Will it ever be?

The current code will not handle arbitrary digest correctly. So either this is merged or there needs to be a different PR that fixes handling of arbitrary digests with SM2.

I'm concerned about all the hard-coding in sm2sig.c. How do we know that there will not be any acceptable digest other than SM3?
I'm find with having a check in one spot that sets the current limits, but would rather see the major parts of the code be flexible enough to leave room for other digests, so we don't have to revert this change in the future.

OK, fixup pushed that implements this. There is now just one place where the name is checked.

Merged to master. Thank you for the reviews!


Edit Context: Background change on composition requires changing the text color on light and dark contrast themes

Provided we continue going forward with changing the background of the selection during composition, we need to also change the color of the text when in the high and low contrast themes, otherwise it is no longer possible to see the text very well. There would not be enough contrast.
The way it looks now:
https://github.com/user-attachments/assets/2446580d-9b90-43c1-9403-82a11ee6a547
Here the word ni hao should be in black so we can see it clearly.

Another option is to add an outline/dashed outline/etc. to indicate composition?
Inverting the background color is a bit extreme imo, imagine being a user and almost everything you type makes the background of the text flip. Doesn't feel like a good UX to me.

Hmm that is true, I haven't thought about that. Good idea :). Maybe I'll just add an outline then.


Maintainability

Migrate deprecated project style to SDK style, and use latest tooling.

Wow! I have written a number of vs extensions, bit this a much nicer project setup. Thank you!


Update Dependency-Resolution.md

Docs Build status updates of commit bc51a26:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/consume-packages/Dependency-Resolution.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

fixes https://github.com/NuGet/docs.microsoft.com-nuget/issues/1542