Ruby also has it, but there is big difference. Both CS and Ruby has some kind of null and that kind of operator is nice to have as repeated null checks can be irritating. Rust doesn't have this problem.
We should not consider our design choices based on CS or Ruby but rather on Haskell and ML. IIRC Haskell doesn't have ? equivalent, it has 2 different operators (>>) and (>>=) that works like Option::and_then which could ported to Rust in more or less similar syntax but it would look terribly ugly. Instead there can be do like macro, and guess what, there are even 2: mdo and mine PoC named labeouf.
--
Łukasz Jan Niemier
Dnia 7 sty 2016 o godz. 15:06 Stephan Sokolow<EMAIL_ADDRESS>napisał(a):

@Ticki
The question is whether the risk of mis-parsing caused by try! inducing a snarl of parens causes greater harm than the risk of mis-parsing caused by overlooking a ?.
I believe ? is the lesser of two evils. (And, as has been mentioned, Swift and CoffeeScript already have it, which means people coming from either of those languages will be used to looking for it.)
—
Reply to this email directly or view it on GitHub.

@hauleth ? is superior to mdo (I couldn't find yours) or any similarly implemented sugar/macro/library, because it interacts correctly with regular control flow like continue, break, early-return and loops. You say we should look at ML & Haskell, but those languages have none of these constructs. Any do-notation implementation in Rust would have to be either original or less powerful than ?

As evidence of this confusing/nuanced terminology involved here, I submit a slightly modified version of a quote from Ticki :)

Panics are not exceptions. Panics are exceptional states.

Still I see ? as an issue as in most cases I read code, not write one (especially in Rust). And when reading in most cases I look at the beginning of line, not it's end.
I do not see how ? would be better in this case than do as AFAIK requested ? behaviour is exactly the same as try which contain hidden return inside of it. So chained ? calls can be expressed as (using mine crate https://github.com/hauleth/labeouf):
try! {     do_it! {         a <- x.foo();         b <- a.bar();         // …     } }
As it could be quite common pattern there could be try_do macro that would do exactly the same as the above.

You say we should look at ML & Haskell, but those languages have none of these constructs.

This is wrong. Haskell do have do notation (so do F# and OCaml, but under different names), but for Rust to support it (to be supperior to this rfc), we need monads. do without monads does not make any sense.

I would really encourage people to read about monads and do notation to understand it. It's a very neat and powerful concept, and can be used for many things :).
http://book.realworldhaskell.org/read/monads.html
https://en.wikibooks.org/wiki/Haskell/Understanding_monads
https://en.wikipedia.org/wiki/Monad_(functional_programming)
https://en.wikipedia.org/wiki/Monad_(functional_programming)#Syntactic_sugar:_do-notation

@Ticki I understand do-notation perfectly and I know Haskell has it. Maybe I wasn't clear, I meant: Haskell & ML don't have any of early-return, continue, break or loops.
That was what I meant by 'these constructs'.

@cristicbz Ah, okay. Sorry for the misunderstanding.

@hauleth @Ticki Where monadic do-notation falls flat (at least in the way it's done by mdo and Haskell) is in a situation like this:
  fn foo() -> Result<(), String> {
      let x = operation1()?;
      while failable_condition()? {
          let y = operation2()?;
          if y.some_other_failable_condition()? {
              break;
          }
      }
      Ok(())
   }

@hauleth Your example illustrates quite well that do notation won't help at all with the chaining/fluent API issues that ? is, in part, trying to resolve. (See the various examples up thread.) It also tends to impose rightward drift that we currently avoid with try!.

@bluss

try!()'s construction encourages line-by-line style where each line is a separate operation that may error.

That's part of what's so painful about it. Rust is an expression language; you can nest expressions without having to invent a temp variable for the result of each intermediate subexpression. The fact that try! nests awkwardly means you end up feeling the need to do this unnecessarily, which starts to feel like programming in SSA. I don't want to be a compiler, I want to let the compiler be the compiler. ;P
@hauleth

Still I see ? as an issue as in most cases I read code, not write one (especially in Rust). And when reading in most cases I look at the beginning of line, not it's end.

But that's actually the point: ? is optimizing for readers, not for writers, and it's precisely because we read left to right. This is what I was talking about earlier; a function or method call with error propagation is conveying two pieces of information: (1) the actual call and (2) the error propagation; the latter is important to convey but distinctly secondary to the former. This really shows up when chaining because a chain of calls with try! mixed into the middle, or broken up across multiple lines with lots of temp-var declarations, quickly becomes difficult to understand at a broad "what is this pipeline doing?" level.
The beauty of ? is that it hits a sweet spot of explicitness and unobtrusiveness, allowing the function calls to dominate the visuals, while still making the error propagation clear. (In fact, it makes for a much more standard style of indicating error propagation so as it catches on in the ecosystem, it could well end up being easier to detect error propagation logic than with the diversity of styles today -- match, try!, error transformation methods, etc.)

@cristicbz And early returns fall flat inside closures.
The way I see it there are two main ways of dealing with types such as Result and Option.
With the first one, which seems to be the focus of this issue, processing the contents of Result and Option happens after unwrapping it (and introducing an early return, break, or continue when encountering Err or None).
In the second one (which I personally prefer, and which I expect would benefit more from do notation that the syntax proposed here) processing happens 'inside' types such as Result and Option using methods such as map, and and_then. In this case there is usually a series of chained method calls that yield a final Result or Option, which is usually the result of the function.
Both approaches work quite well in practice, and at this time I think neither is encouraged much over the other by the Rust language. But I fear that adding this syntax will lock the language on a path where will fewer nice functional programming features will be added. Once there is special syntax to deal with Result, there will be less need to add proper support for monads (and HKTs, and do) to the language.
Which is why I do not support this feature.

@dherman Exactly. It's bad enough that something like the Clockwise/Spiral Rule is necessary in C and there doesn't always exist a Rust wrapper or alternative for a given C library.

@dherman I see this as a problem with code style that should be fixed with rustfmt not with language and it's syntax. If I see try!(…) then I know that there can be dragons. If I see try!(try!(…)) then I assume that someone try to golf, not to work.
See the @bluss example in link. try! is not highlighted and ? is,thus it is still more readable (at least for me) to use try!. Using try! chain or ? chain would be IMHO very bad code style and should be discouraged anyway.

I accidentally deleted the comment I made earlier, while I was updating it, so I'll repost it here:

While this is a very well written RFC, I have to give it a :-1:, since:

Monads are superior. I know this is subjective, but in my experience they're easier to deal with, less buggy, more clear, and overall better.

'Exception' handling is non-rustic. One of Rust biggest strengths is "when your program compiles, it contains very little bugs". With exception handling this is not the case. You can easily handle a exception without being able to test it. Futhermore, the majority of exceptions are unrecoverable, thus (if "corrected") can lead to unexpected behavior (not UB), due to control paths which is hard to reason about. This do also apply to this RFC, since both catching and propagating exceptions is simple & short by this proposal.

Edit: I know that this RFC does not introduce the classical form of exceptions, but it do introduce a form of exceptions, namely it lets people catch exceptions in an arbitrary place in your code. Although propagation is explicit, it's just a single, simple sigil, encouraging people to blindly propagate exceptions.

The current error handling system do not need to be completely redesigned. It needs improvements, sure. Rust's current error handling system works by explicitly propergating the ADTs made for error handling, either by try! or by handling the case yourself. This works already quite well (though try! needs to be extended with a handler for Option<T>, I believe this can be integrated in the new macro system. Though there are some problems: see [1]). This proposal is somewhat doing this but at the same time not. It introduces syntax for catching "exceptions".

This RFC seems to address too many issues at once, which can easily work independent. First of all, it introduces ? but also try/catch (which is the core of this RFC), but lastly it introduce tagged returns (block returns).

Edit: @glaebhoerl clarified: it do not introduce tagged returns, it's just to help explaining the RFC.

This is not very future-proofed. The integration with HKT, monads, do notations etc. is unclear. This is something that needs to be solved to avoid getting a very ugly beast of a language. I don't currently see a way to integrate HKTs in this RFC without completely rewriting it. Since HKTs are powerful and provide clean API, dismissing them in this proposal can lead to very ugly, TIMTOWTDI API.

Catching exceptions is bad. See Joe Armstrong's thesis and Caneda and Fox's paper. To highlight the problems: It's often buggy and untested. It's slow. It often tries to recover non-recoverable errors (which is bad, since in many cases, due to not being tested properly, will essentially make the rest of the program very buggy, due to unexpected conditions. In some cases this even results in security issues!). Note that this is not a concern about exceptions per se but rather a concern about handling exceptions, since they, by nature, are trying to recover errors which cannot be recovered leading to unexpected states and very buggy behavior.

Edit: To add: the problem is that this RFC adds ability to catch exceptions in arbitrary places. Furthermore, you can easily propagate exceptions.

This syntax seems noisy. Trying to write a bunch of small example programs with this syntax, I easily missed over the ?, because it's hard to skim. My eye (at least) cannot easily tell vec_deq?.push_back() apart from vec_deq.push_back().

Introducing this feature to the language seems overkill. Exception throwing with macros works fine. The only (rather big) issue is macro definitions cannot define cases based on the type of the expression. If this is introduced, try!() could be made to support Option<T>. See [1]

It plays poorly with certain stablized libraries.For example: why would one want indexing to panic, if you were able to throw an exception by a single character. The original rationale behind panicing indexing is that the wide majority of cases, you cannot recover the error anyways. If you've ever coded in C++ or Java, you've runned into these situations, where your program runs fine for a long time, and then at some point, it gets buggy. Then you find out that it was because of an unrecoverable exceptions that you try to handle. People are lazy (and that's fine) leading to trying to do odd things, because "hey, this seems to work".

try! is more explicit than ?. try! is easier to spot and harder to miss than this. Any operators that implies changes to the control flow of a program (and therefore crucial to the behavior of the program) should be very explicit.

Note that my concerns are mostly about the exception handling part, not about the exception throwing part. The difference is big. Being able to easily do an early returns can be neat (whether by using macros or by a syntactic sugar, is a whole other discussion). The actual problem is trying to do impossible stuff by handling exceptions.
*[1] There is a problem with macro expansion happening before type checking. Thus making it hard to detect which version of the macro a given instance is. A possible solution (probably more ergonomical) is to make a trait, say Optional that abstracts over types like Result and Option, providing commonly used methods.
So to sum up: Exceptions are bad and do not belong to such a great language as Rust.
That was my 5 cents. Not sure if any of that makes sense?
edit: Extending, rewording, and correcting.

@hauleth Heh -- rustfmt forcing you never to nest try! would be making the problem worse :) It reminds me of an Andrew Appel quote:

The beauty of FORTRAN—and the reason it was an improvement over assembly language—is that it relieves the programmer of the obligation to make up names for intermediate results.

Let's not go back to assembly! :P

Using try! chain or ? chain would be IMHO very bad code style and should be discouraged anyway.

Again, I contend that it's far better style than introducing temporaries. A primary goal of readability is to ensure that the reader can understand the primary purpose of code before they understand all the details. Excessive boilerplate in prefix position, or excessive use of named temporaries, obscures the primary content of the code.

I agree with @dherman, nesting try!s is bad style. However, in my experience, it is only very rarely needed to do so.

 In particular, nesting ? is good style. In my experience, it happens a whole awful lot!

@Ticki

So to sum up: Exceptions are bad and do not belong to such a great language as Rust.

I'm not sure how this is exactly exceptions, though. Or at least, not in the same way as all of those things are talking about.

IMO the first and foremost mistake of this RFC is the use of 'exception' term. I think many here just
panic!("Rust gonna get exceptions!");

:)
Second, my 5 cents:

Operator '?' isn't bad IMO. I'd rather just make it expand to 'try!()' macro.
try!() should work not just with Result's, but use some trait like Optional, or, more conveniently, Tryable. Or by generalizing any erroneous value to Result.
try ... catch can be done via macro and nested lambda, possibly with some limitations.

Big +1 for '?', it would make much multirust-rs a lot cleaner, but the proposal seems to contradict itself regarding try/catch.
Initially, it says:

If no exception is thrown in the try block, the try..catch evaluates to the value of try block

But later on under the "laws" section:

try { foo() } = Ok(foo())

They can't both be true?
@Ticki

Monads are superior.

Monads on their own don't solve the same problem that this PR addresses, and @cristicbz has already demonstrated the problems with do-notation alone.

It often tries to recover non-recoverable errors

Rust has panics for non-recoverable errors, so I don't really see how this as an issue. I find I run into the opposite problem far more often: I'm plagued by APIs which do not allow me to handle the error cases sufficiently precisely or even at all. Thankfully this is rarer in Rust than certain other languages, but it still happens: often because the error forwarding machinery is unnecessarily verbose at the moment,

encouraging people to blindly propagate exceptions.

It doesn't make it any easier to blindly propagate exceptions. You must still ensure that the Error type of your function matches, or unifies with any exception you wish to propagate, and this makes it very much a conscious decision to propagate an error, whilst also ensuring that the the types of exception you may return is well documented to the caller.

This syntax seems noisy.

It's undeniably much less noisy than having try!s all over the place, and this is in direct contradiction to your complaint that ? is easy to miss.

I think another way to make the point I'm trying to make is: you only get so much room in a program to convey so much information. A reader of code has finite mental capacity to absorb what's going on as they read the code. We can't simply claim "error propagation is important so we have to put it front and center" -- "front and center" is a crowded space with only so much room!
Ultimately, it's an empirical question, but when I actually rewrite my code, it just looks remarkably clearer to me. I don't see the error propagation disappearing, which seems to be the primary fear; it's just less obtrusive.
For a full-sized example, here's:

a recursive-descent parser written with try!
the same parser written with ?

IMO the first and foremost mistake of this RFC is the use of 'exception' term. I think many here just
panic!("Rust gonna get exceptions!");

:)
Second, my 5 cents:

Operator '?' isn't bad IMO. I'd rather just make it expand to 'try!()' macro.
try!() should work not just with Result's, but use some trait like Optional, or, more conveniently, Tryable. Or by generalizing any erroneous value to Result.
try ... catch can be done via macro and nested lambda, possibly with some limitations.

@Diggsey try { ... } and try { ... } catch { ... } are separate constructs (on just the syntactic level, similarly to if { ... } and if { ... } else { ... }). Plain try evaluates to a Result (as there were no occurrences of ? at all in the example you cited, it therefore results in an Ok), while try..catch essentially then does an unwrap_or_else on it.

Personally I prefer to explicitly see any place where branch can occur. This is quite important in safe code as it can leave world in unsafe/unwanted state.
? isn't noise, it is invisible IMHO. And I think there is no good way to make it detectable in nice way. There is IMHO no way, even with syntax colouring, to make me see where branch happen. When using try! it is quite easy as NeoVim + Solarized make it orange and any macro is clearly visible and distinguishable from other code.
@dherman I cannot understand what Parser::peek() do as the only peek I know of is Iterator::peek() and it is returning Option not Result.
About returning to assembly - I do not think about rejectable call return value as temporary variable, I would rather say that this is result of computation (of some sort) and I want to process it later.

Monads on their own don't solve the same problem that this PR addresses, and @cristicbz has already demonstrated the problems with do-notation alone.

No, they do not, but there is a huge overlap between this proposal and monads.

Rust has panics for non-recoverable errors, so I don't really see how this as an issue. I find I run into the opposite problem far more often: I'm plagued by APIs which do not allow me to handle the error cases sufficiently precisely or even at all. Thankfully this is rarer in Rust than certain other languages, but it still happens: often because the error forwarding machinery is unnecessarily verbose at the moment,

What I say is that this proposal makes exception handling and throwing (propagating failing ADTs) easy, and thus encouraging people to try to recover unrecoverable errors (no-one wants their code to panic, right?). This leads to buggy code reached on failures (and thus hardly testable).
This is obviously already possible, but it is more verbose, and that's great! (because we do not want to encourage people to do the impossible). Making it this easy to handle and propagate exceptional cases is just a motivating factor for recovering the unrecoverable.

It's undeniably much less noisy than having try!s all over the place, and this is in direct contradiction to your complaint that ? is easy to miss.

try! isn't really a language build in syntax, but a macro. Furthermore, I do think that try is less noisy and more self-explaining.

It doesn't make it any easier to blindly propagate exceptions. You must still ensure that the Error type of your function matches, or unifies with any exception you wish to propagate, and this makes it very much a conscious decision to propagate an error, whilst also ensuring that the the types of exception you may return is well documented to the caller.

If I can just append ? and then catch it later on, then it is much easier to abuse it for nasty stuff. ? is simpler and less obstructive than try!. It is harder to spot and very easy to misuse. It is less explicit.

It's undeniably much less noisy than having try!s all over the place, and this is in direct contradiction to your complaint that ? is easy to miss.

It is true that ? is less ugly than try!, but with "noisy", I mean "hard to understand, hard to spot, and hard to grep".

Obviously, this proposal is barely as bad as classic, implicit exceptions, but it do still carry many of the classic exception's disadvantages.

@hauleth Yeah, it was just a port of the main module of a full project. The peek method is defined in another module.

@Ticki

try! isn't really a language build in syntax, but a macro. Furthermore, I do think that try is less noisy and more self-explaining.
try! is provided by libstd, so it's about as built-in as something can be. The bar is set really high for things in libstd, precisely because it amounts to the same thing as being part of rustc.

Re: noise, by what metric do you perceive try! to be less noisy than the suffix ??

@tikue from what I understand try! isn't part of language, it is macro, and that makes language more noisy, not syntax.
Again I think that ? make syntax less noisy and that is the issue. It is much harder to spot, grep, highlight, etc. ? than try!. And unexpected branch can sometimes be very, very bad. Also this RFC does not describe how it want to define ? on types? Should it be built in language itself that this works only on Result and Option? There should be additional trait?

@Ticki @tikue I'd also like to know... because, when I'm skimming, I see try! as ugly and easy to miss for the same reason I don't like the BASIC and Ruby convention of using words rather than braces to denote blocks.
Something so fundamental to how you use the language should not blend into the background so readily when you're skimming.

@ssokolow and I think absolutely opposite. Any branching in code should be visible. I want to see where code can break and how it can break.

@hauleth
I think we have different views on the same thing.
I find ? makes it easier to see where it can break because try! is just another macro that blends into all of the others while ? is a distinctive sigil.
I find ? makes it much easier to see how it can break:

I find try! to be easier to mis-read than ? because, for sequences of operations, my mind naturally operates on a narrative/infix notation and it's awkward and error-prone to translate from the prefix notation try! imposes.
Verifying that I'm properly pairing up the braces is slower and more error-prone.

try! is provided by libstd, so it's about as built-in as something can be. The bar is set really high for things in libstd, precisely because it amounts to the same thing as being part of rustc.

This rfc introduce a actual syntactic change.

Re: noise, by what metric do you perceive try! to be less noisy than the suffix ??

I mean "hard to understand, hard to spot, and hard to grep". We might have a different view of what "noise" means.

@Ticki ah, yeah, that's not what I usually interpret noise to mean.

@ssokolow I do not need to pair anything. I see try!, I know that this can diverge. I do not count anything, no need to. 1 try = 1 line, no more. I have even checked Redox source code and there never ever was need verify pairing. I have quickly revived rustc source with the same result. What more I have found that in whole rustc there are 4 uses of nested try! in the same line.
So I would say that these are rare cases when it is needed to nest try!.
And it is even rarer to need to verify braces when trying.

@hauleth of course, the reason it's so rare is likely correlated with the fact that it's so unergonomic... :)

And IMHO it is good. It forces good practices. We do not write oneline ifs.
Also no one even tried (no pun intended) to write how to implement ? operator.
--
Łukasz Jan Niemier
Dnia 7 sty 2016 o godz. 20:35 Tim<EMAIL_ADDRESS>napisał(a):

@hauleth of course, the reason it's so rare is likely correlated with the fact that it's so unergonomic... :)
—
Reply to this email directly or view it on GitHub.

Since this proposal is adding a new feature to the language, how does this interact with nostd programs?

@nixpulvis I think everything relevant is in core.

@hauleth When I say "pairing up the parens", I'm referring to building/refreshing a mental model of what the code actually does.
That means needing to have a clear understanding of what is within what else. Excessive use of parens makes that slower and more error-prone.

@ssokolow but you should not care. See this (example from libsyntax)
return Ok(Some(try!(self.parse_item_foreign_mod(lo, opt_abi, visibility, attrs))));

it looks like Lisp hell at the end of the line, but I don't care. I do not read all these parens, what I "see" is:
return Ok( Some( try!( self.parse_item_foreign_mod( lo, opt_abi, visibility, attrs

All further characters doesn't matter. I do not need to count if I have enough parens as:

I have editor that highlight matching parentheses.

They doesn't matter as I know what they mean (as I've already "parsed" their respective openings)

Excessive use of parens makes that slower and more error-prone.

Last time I've checked, Structure and Interpretation of Computer Programs still use Scheme as it's main language. It aren't parens what makes it bad, but how you use them.

I was thinking of structures more like this (from a previous reply) where they don't pile up at the end and, whether you count parens or fiddle with the cursor to trigger paren-matching highlighting, it's slower either way:
try!(try!(try!(TcpBuilder::new_v4()).bind(some_addr)).listen(some_backlog))

Isn't that a good case for Result::and_then?
try!(TcpBuilder::new_v4().and_then(|tb|tb.bind(some_addr)).and_then(|tb|tb.listen(some_backlog)))

If you find you need three try!s on a single line, there is probably an opportunity to write it differently that you missed.

@ssokolow exactly what @Thiez said. It could be written nicer, but the idea is the same.
What is more, I haven't found such code either in Redox and Rust.

If unicode weren't hard to type, I'd suggest to ? with the  character (U+1F4A9) to symbolize "shit could happen here" :grin:

So, there's been a ton of activity on this thread over the course of the week, but I think there's basic agreement about the "facts on the ground". The disagreement is all about what to value/prioritize. I'd like to try to summarize the state of play by listing the facts as I see them:
The ? notation, by itself, has several properties:

Being a suffix operator, it plays well with method chaining/fluent APIs.

This could also be achieved via method-style macros or, in some cases, adapters like and_then
But ? is clearly the most concise option for chaining.

It makes error handling the secondary, rather than primary, thing that you see when reading code.

In particular, it's easier to ignore or even miss the error handling path on a quick read of code.

Being an actual operator, it makes the control-flow of try! first class within the language.

Regarding do notation:

Given that you need at least HKT, and probably some new research to integrate with Rust's other control-flow operators, the notation is not coming any time soon. (Likely multi-year horizon.)
do notation does not address any of the points above in terms of e.g. chaining APIs. On the contrary, do notation typically works in the opposite way, by forcing you to declare and name temporaries for each monadic action that you wish to chain.

In particular, moving to do would mean that effectively any use of try! has to exist at the top-level of a statement; code like some_fn(try!(other_fn(x, y)) would have to be rewritten to pull out the result of the try! into an explicit temporary.

If we add ? now and do later, it's not entirely clear how they would interact. In particular, being inside a try block or a function yielding Result is a bit akin to being inside a do block for the Result monad. But again, unlike with do, the ?/try! notation is usable anywhere within an expression, not just at the top level of a statement.

Regarding try/match:

This is largely a separate question from whether we want ?

In particular, it's independent of the various properties of ? laid out earlier

There is more overlap between try/match and do notation or other more general control-flow mechanisms, though try is much more flexible than do notation in terms of where monadic effects can appear (as mentioned above)
There's more to say here (e.g. about @Ericson2314 points), but not much that's relevant to the current thrust of the debate, so I'm setting it aside for now.

Finally, it's worth mentioning that while people's experiences with things like try!(try!( have some variance, try! is currently one of the most heavily-used control-flow constructs, in some projects being more common than keywords like match or while.
To focus on ? in particular, it seems like the question really comes down to the desired ergonomics:

If you think that the properties I mentioned about ? are important, then it doesn't make sense to hold out for do notation, because that doesn't provide any of those properties.
On the other hand, if you think that chaining is bad, or that the error handling path should be front-and-center when reading code, then ? is not desirable, and do notation is ultimately just fine.

Do you think that's a reasonable summary of the recent discussion? Did I miss any of the basic tradeoffs here?

@aturon You nailed it. For this discussion to make sense, the RFC should be split up in smaller RFCs, since they have little in common, and some might support one part but not another.
Chaining is not ideal with do, but in my experience, you rarely need long chaining (and when you do, you do not have to sacrifice readability).

I agree with this summary except this one part:

do notation typically works in the opposite way, by forcing you to declare and name temporaries for each monadic action that you wish to chain.

This is not true. You only need to declare temporaries if you need them, like, it's the same situation as try!. There's two variants:
fn write_stuff<T: Write>(w: T) -> io::Result<()> {
    try!(write_fmt!(w, "whatever: {}\n", 5));
    try!(write_fmt!(w, "whatever: {}\n", 5));
    try!(write_fmt!(w, "whatever: {}\n", 5));

    Ok(())
}

fake do:
fn write_stuff<T: Write>(w: T) -> io::Result<()> {
    do {
        write_fmt!(w, "whatever: {}\n", 5);
        write_fmt!(w, "whatever: {}\n", 5);
        write_fmt!(w, "whatever: {}\n", 5);

        Ok(())  // or maybe this could even be elided? depends on how do works exactly
    }
}

vs
try!(try!(try!(TcpBuilder::new_v4()).bind(some_addr)).listen(some_backlog))

fake do:
 do {
    builder < - TcpBuilder::new_v4();
    builder <- builder.bind(some_addr);

    builder.listen(some_backlog)
 }

Yes, that second case still makes you name some temporaries. But not every case of it does; just the ones that are nested.

@steveklabnik
Yeah, I was being a bit too terse there. What I mean is that, if you have a use of a monadic operator buried within an expression, that has to be lifted out to the top level and named. The example I gave was some_fn(try!(other_fn(x, y)) -- the implicit temporary for the result of try! has to be pulled out an named in do notation. Of course if you're already writing top-level statements, there's nothing you need to do.
In Haskell, you work around this to some degree by having a whole bunch of lifting combinators that let you turn functions that accept normal values into ones that accept monadic values, and do the chaining internally. We could potentially do something similar in Rust, but it doesn't cover all cases, and it ends up leaning pretty heavily on Haskell's type system machinery in practice (so unclear how well it would port).

I think underlying this discussion are real philosophical differences about the direction of the language. Philosophical differences are hard to converse about in general, but GitHub issues are especially not a great medium for doing it. I think these are the two main points of contention:

Rust has a very strong functional lineage taking many features from languages like Haskell and SML. But Rust is operating in a space ('systems' programming) traditionally dominated by imperative languages. Should Rust focus on being a "functional language" and emphasize programming in a style and using construct common to existing ML-lineage languages (and especially Haskell), or should it attempt to apply the perceived benefits of functional languages (expressive typing, clear reasoning about state) to constructs that are stylistically and conceptually "more like imperative programming"?
Rust has an advanced macro system, but it also has a fair amount of syntactic sugar for control flow constructs. Is more sugar for common cases such as error handling a good idea, or should this be handled through std library macros?

There's a connection in this regard between this RFC and #1303, which is the other most commented RFC. From my perspective, these philosophical issues seem to be the central disagreement in the Rust community today.
I also think its clear where many commenters on this RFC stand on these questions, and this conversation has started to feel circular to me. I'm not sure how to proceed.

Main reason why I am against this change is that in my opinion we should try to keep language simple. We should not add more sigils and magic operators to language where variable definition confuses people. I think it is much easier to describe what try! do than explain how to implement and use ? operator. I think that we should rather add another macro for Option that would work like None rather than inventing new sigils (we once have a lot of them, why return to that state?).

@withoutboats Thanks for the comment. I think there's some truth to what you're saying, but I also think the framing is unfortunate.
If I can speak for a moment on behalf of both the language team and the core team: what we are most interested in is solving real problems, rather than any underlying philosophical bent.
We have people on these teams with experience across the full spectrum of PL families, from Haskell to C++ to Prolog to Javascript, and understand the benefits and downsides of design decisions in many of these languages. But Rust is now its own language, with many aspects of its core philosophy well established. I think it's much better to focus on practical problems people face in using Rust -- or obstacles that limit where we can take Rust -- than to drive the vision based on following ideas from a certain language family. Not least because concepts like "functional" or "object oriented" are notoriously slippery and hard to define.
Of course, this practical mindset is its own kind of philosophy -- and I know in the past, this has led to accusations of taking a "worse is better" approach to some questions. But, to my mind, being driven by practical concerns is one of the central tenents of Rust.
This is part of why I've tried to refocus the debate on the precise practical tradeoffs between something like do notation and ? for handling errors in Rust.

@aturon I tried not to reduce the disagreement to a conflict between 'functional' vs 'imperative', which I think is usually not a deep discussion, but I may have failed. I think we are applying the term "philosophy" at different levels of evaluation - to me, these divergent positions are about how best to solve the practical problem of programming in Rust.
To be clear, I am very much in favor of this RFC. I think it introduce convenient and lightweight syntax for what have been common cases in my experience. I really disagree with comments to the effect that try! is simpler than ?; there is a certain kind of elegance in keeping the language small, but I don't think there's a pedagogical or use difference that arises from being an operator or being a macro; either way its a control flow construct.

@withoutboats My apologies for misinterpreting. Mostly, I want to push back against the idea that we are reaching a stalemate due to everyone approaching the debate with preconceived philosophical stances. I think we can make a lot of progress by relentlessly focusing on tradeoffs. But it is true that, at the end of the day, it comes down to how you value the various sides in a tradeoff, and that is an essentially philosophical question -- just not one that's necessarily determined by hewing to a particular language family.

@hauleth Having both ? and ?? operators has not given C# a reputation as a sigil-heavy language, so I'm not particularly concerned about that argument. I also disagree that ? would be harder to teach than try!, quite the opposite; newcomers tend to view macros as nothing more than glorified functions, and that mental model doesn't intuitively permit for the possibility that macros can cause an early-return (I personally have observed a great deal of surprise at this notion). Having dedicated language support will make this more intuitive (not to mention it would greatly improve error messages).

@bstrie I hadn't thought about it that way but, now that you mention it, I definitely see that issue with `try!.
Heck, while not as bad as exceptions, early return in macros does make it more difficult to reason about control flow since you can't tell whether an unfamiliar macro may cause early return just by reading through something which calls it.
Was the idea of imposing a distinction between non-returning and returning macros (eg. something in the vein of println! vs. try?) ever considered back during Rust's formative years?

Yeah, but C# is language where everything is Optional and what is more, nothing prevents you from calling methods on None which will blow up your program. This is essential difference between Rust and other languages - Rust will tell you on compile time that you are calling methods on Nullable type in C#, Ruby, CS or almost anything else it will happily compile (or parse) and then throw 💩 in Your face when null dereference error happen.
--
Łukasz Jan Niemier
Dnia 9 sty 2016 o godz. 18:34 Ben Striegel<EMAIL_ADDRESS>napisał(a):

@hauleth Having both ? and ?? operators has not given C# a reputation as a sigil-heavy language, so I'm not particularly concerned about that argument. I also disagree that ? would be harder to teach than try!, quite the opposite; newcomers tend to view macros as nothing more than glorified functions, and that mental model doesn't intuitively permit for the possibility that macros can cause an early-return (I personally have observed a great deal of surprise at this notion). Having dedicated language support will make this more intuitive (not to mention it would greatly improve error messages).
—
Reply to this email directly or view it on GitHub.

@hauleth I'm not convinced that's relevant. C#'s universal nullability could be used as an argument regarding how often sigils are used, but "sigil-heavy language" is more a function of how many sigils there are.

@ssokolow I don't believe it was ever considered, no. Personally I think that macros-that-perform-an-early-return is such a small set (a set of one, AFAIK) that it would be far less invasive to just reify try! in the language than to try to introduce new rules to macros. :P

@bstrle A set of one in the standard library, but any cargo package could define its own and I get the impression that the Rust ecosystem's focus on composing a lot of little packages could exacerbate any potential issues unfamiliar early-return macros might cause while getting up to speed with a new codebase.

I just say why C# was in need of such functionality. Rust is not.
--
Łukasz Jan Niemier
Dnia 9 sty 2016 o godz. 19:34 Stephan Sokolow<EMAIL_ADDRESS>napisał(a):

@hauleth I'm not convinced that's relevant. C#'s universal nullability could be used as an argument regarding how often sigils are used, but "sigil-heavy language" is more a function of how many sigils there are.
—
Reply to this email directly or view it on GitHub.

@hauleth In that case, I don't understand.
From where I'm standing, Rust needs ? more than C# does because, in Rust, you're forced to be more explicit about your handling of potentially nonexistant values.

From where I'm standing, Rust needs ? more than C# does because, in Rust, you're forced to be more explicit about your handling of potentially nonexistant values.

Agreed. foo? isn't any less explicit than try!(foo), it's just less verbose. And if verbosity is what one desires, then match foo's got you covered. :)

Okay, so I just finished re-reading this thread. I think we can unambiguously state that this Request For Comments has been very successful!
It's kind of amusing (but not at all surprising) that many of the concerns which were raised near the beginning of the thread are the same ones that have kept coming up ever since.
The main points of debate I found were:

Whether "do notation" would be preferable
Whether calling these "exceptions" (and relatedly, try/catch) is the right idea
Whether ? is preferable to try!
Whether having try/catch is a good idea
The value of Option compatibility and ResultCarrier

I'm heading out just now, but I'll try to write down my thoughts after.

I change my mind, and I would be for ? probably without try { }, probably with OK(..) required at the end of the function though I could maybe be persuaded otherwise--i.e. just like try! works today. Why? Because it is can be used perfectly with do notation.
Haskell uses <- because most syntactic constructs consciously avoid an sequencing effects. For example:
unsafePerformIO launchNukes + unsafePerformIO openSiloDoors

is an especially bad idea.
Rust however is already monadic/effectful, and we have a well defined order of operations everywhere. Thus, it would be abundantly clear that:
a? + b?

is
 a >>= \a' -> b >>= \b' -> a' + b'

i.e. that a's effects come first.
So if we get do-notation (and that will take a lot of design work because it cannot be closure-based, and Rust is already monadic), expr? will become expr >>= continuation-of-expr. We don't even need <- because let foo = bar? works just fine.

A few more sketch ideas on do-notation. While not strictly on topic, I hope these can alleviate fears people have:

I mention do-notation shouldn't be closure based. That is my preference, not a requirement for ?-as-bind however. It could simply be that certain uses of ? make for arbitrary monadic code, and certain uses fall back on Result (really, "first order monads", but I am not sure how to encode that).

break, return, and other control flow stuff aren't total deal-breakers, It's really the interaction between them and borrowing--add enough lambdas and the control flow will work out, but so many values are going to be moved between so many closures that addresses may changed in unpredictable ways. I've recently become enamored with this http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf intermediate representation. Think of it as a higher-order MIR. Basically I think we can convert something like that---make the control-flow explicit, don't desugar closures into structs and impls---then I think we can re-interpret the resulting syntax as recursive do / mdo (https://wiki.haskell.org/MonadFix) and compile again. It's super heavy-weight, but it just might work. tl;dr, all you people saying that do notation looks like SSA are on to something.

I would describe this whole RFC as:

Do we want operator that has implicit return?

My answer is: no. We don't want that.
How would we implement that? Via Try trait?
impl<V, E> Try for Result<V, E> {
    fn try(self) -> /* what should be here? */ {
        match self {
            Ok(val) => /* and here? */,
            Err(err) => /* and here? */,
        }
    }
}

Does this seems ok with you? I don't like such construct. Even more I don't like special cases in language parser which seems to be matter of this RFC.
For what I see is currently discussion between "we want, because other have" and "we don't want, because we have try!". I am in second team but I have see more impact on the language than just removal of try! macro.
Also if we will get Try implementation on Result and Option then why not on bool? Will it work on comparison operators like in Ruby (I know that Result<T: Eq, E: Eq> and Option<T: Eq> has Eq implementations but former has it only if both are Eq, what if only T is Eq)? There probably is more questions about that.

@hauleth The ? operator would not be overloadable, so there's no question about implementation.
There's also no special cases in the language parser needed to accomodate ?. It's as straightforward as can be.

@hauleth

Do we want operator that has implicit return?
I must say that you're having a very good point. Because it's an operator which doesn't only diverge, but diverges conditionally. Houston, we might have biiiig trouble with this.

@target-san The ? operator does not pose any semantic difficulties over what try! already does.
Also, asking "do we want an operator that has an implicit return" was mooted long ago when we opted to add a macro to the standard library that performs an implicit return. Having an operator that implicitly returns is far, far less confusing than having a macro that does it.

I agree with @Ticki and @aturon that the ? proposal needs to be split out from the try/catch proposal into separate RFCs. The former is zero-risk bikeshedding while the latter involves a lot of new machinery, and it's unfortunate and frustrating to have to discuss both in the same thread seeing as how they're each orthogonal concerns.

@bstrie so how ? operator would know on which type it can be casted? Only on type named Result? Then how it will work with #[no_core]? Or custom Returns? Or completely unrelated type named Return? How it would work with Option? Even more questions and difficulties.

@hauleth The answer to all those questions is: the exact same way that try! works today. It's literally just sugar.

Having an operator that implicitly returns is far, far less confusing than having a macro that does it.

I don't think so. There is already a lot of languages that has macros that can (or are) implementing implicit returns and this is IMHO much easier to:

spot
discuss
modify
reason

with macro than with custom operator that cannot be overloaded and works only on one custom type chosen by "Some Guy From Above".

@hauleth It would be easier to spot than a macro, because it is a unique sigil used nowhere else in Rust code. To a scanning eye, "try!" is Just Another Macro. It is no harder to discuss or modify. It is easier to reason about the operator than the macro, because it is surprising to have a macro that does an early return.
I'm also still confused as to why you say that this would work on fewer types than try!, considering that they would produce the exact same code under hood. if let, while let, and for loops all conceptually become match statements during codegen. This would just become a match statement as well, just as try! currently does, except during codegen instead of during macro expansion (and doing things during macro expansion is inferior to doing them during codegen, because we can avoid codegen by caching (see incremental recompilation) but we can't ever avoid macro expansion).


Add an example of using Dropwizard with Conscrypt

Problem:
Jetty 9.4.8 supports native SSL via Conscrypt, but it's not clear how to use it in Dropwizard.
Solution:
Add an integration test and upgrade the SSL documentation.
Result:
Dropwizard users can see how they can take advantage of native SSL.

It's probably also a good idea to link to that part of the documentation in the configuration section (or to update it).

@GautamGupta Good idea! Would you mind creating a pull request for it?

Sure thing, here you go: #2305


CVPR 2021 paper

Title: Multiple Instance Active Learning for Object Detection
Paper: https://github.com/yuantn/MIAL/raw/master/paper.pdf
Code: https://github.com/yuantn/MIAL
Category: Active Learning, Object Detection

Many thanks!

Now the project has been added, thanks for sharing
https://github.com/amusi/CVPR2021-Papers-with-Code


hiredis Visual Studio 2010

Hi, i m addictive regards redis and how i can boost my app with it.
I'm trying to support also some legacy app that use ( for compatibility reason ) old tool-set ( vs_2010 ).
But after some works on it, i give up. Seems that was not designed to compile with older version of visual studio. Or i m wrong ?
Someone have successfully build on it ?
Thanks in advance for any feedback.
\Andrea E./

@andreae75
thank you for the feedback, please check if the workaround described in the following related issue can help:
https://github.com/MSOpenTech/redis/issues/194

Thanks for reply, but the issue is a linkage problem. I had to fix lot of compilation error ... seems that visual studio 2010 is not compatibly with the given solution.

OK, I'll take a look.

Grazie. Cheers.
----- Messaggio originale -----
Da: "Enrico Giordani"<EMAIL_ADDRESS>Inviato: 01/07/2015 17:47
A: "MSOpenTech/redis"<EMAIL_ADDRESS>Cc: "andreae75"<EMAIL_ADDRESS>Oggetto: Re: [redis] hiredis Visual Studio 2010 (#261)
OK, I'll take a look.
—
Reply to this email directly or view it on GitHub.

I have fixed the problem just avoid to define the getnameinfo redis\src\Win32_Interop\WS2tcpip.h:
#if (NTDDI_VERSION >= NTDDI_WINXPSP2) || (_WIN32_WINNT >= 0x0502)
WINSOCK_API_LINKAGE
INT
WSAAPI
getnameinfo(
In_reads_bytes(SockaddrLength)         const SOCKADDR *    pSockaddr,
In                                socklen_t           SockaddrLength,
Out_writes_opt(NodeBufferSize)    PCHAR               pNodeBuffer,
In                                DWORD               NodeBufferSize,
Out_writes_opt(ServiceBufferSize) PCHAR               pServiceBuffer,
In                                DWORD               ServiceBufferSize,
In                                INT                 Flags
);
#endif

Thanks, good to know.

From now on for hiredis and hiredis issues please visit https://github.com/Microsoft/hiredis.
Thank you.


Appstudio update test-component-pac-vkzm

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-vkzm-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
8 seconds
init

✅ Succeeded
15 seconds
clone-repository

✅ Succeeded
30 seconds
build-container

✅ Succeeded
19 seconds
sanity-inspect-image

✅ Succeeded
1 minute
deprecated-base-image-check

✅ Succeeded
43 seconds
clamav-scan

✅ Succeeded
11 seconds
clair-scan

✅ Succeeded
10 seconds
sbom-json-check

✅ Succeeded
14 seconds
sanity-optional-label-check

✅ Succeeded
12 seconds
sanity-label-check

✅ Succeeded
9 seconds
show-summary


[#99420212] Variabilise the name of the Tsuru PPA

So that we can point it at our own PPA which contains copies of the packages
at the versions we want to use. This is to workaround a limitation of
Launchpad PPAs which only allow you to download the latest version of a
package.
I can't see any nice way (with Ansible) to remove the old repo if you've
specified a custom one, because another playbook (tsuru_api/gandalf/hipache)
may still configure the original repo and both tasks would fight (changing
it back and forth in every run).
So if we use this, we'll also want to either a) remove the old repo as a
custom task outside of these playbooks, or b) specify the package versions
we want so that the old repo is ignored if it presents a later version.

Shout if you have a opinion/preference for a) or b).

I think it is good to parametrise this, but I would rather do something like:
name: Add tsuru repositories
apt_repository: repo="{{ tsuru_repo }}" update_cache=yes
when: tsuru_repo is defined

This would allow you to define any repository string if you need to, not only ppa, and also be able to completely disable the repository management in the playbook, so that we can in the future easily delegate such responsibility to a specific repository management role.

Good idea, updated now.

I've also added it to the README, which I had forgotten.

Works fine, +1


Remove or replace nvm

nvm is a very nice thing to have if you are working with Node.js all the time. However, nvm adds way too much overhead to every single terminal command when it is added to your $PATH, .bashrc, .bash_profile, etc. It looks like nodenv may be a fair compromise: it supports Windows, as well as the fish shell. My goal isn't to add support for every *nix system in existence, but adding Windows is something I have been neglecting for a while.

For reference, nvm is not installed as a part of citrusui/setup. However, it may be added in the future with citrusui/tools.

After further testing, the overhead from adding nvm to $PATH isn’t deal breaking. I can deal with it for now.


Fix python3 encoding issue with data format string

This fixes the python 3 issue found by @gunan in #4411.

Can one of the admins verify this patch?

Thanks @admcrae! @tensorflow-jenkins test this please.

Thank you very much for the Fix @admcrae !


Bug: When you add an image to the editor, it displaces the image and under a different set of elements.

The steps to reproduce.

I created the editor
With no text present in the editor AND without focusing on the editor, I inserted an image.
The image was misplaced into my sidebar on the left hand side of the page.

More information (sorry)
My settings included all the plugins (provided with the import plugins from '{path}' code that the documentation provided.
plugins: plugins,
        buttonList: [
            ['undo', 'redo'],
            ['font', 'fontSize', 'formatBlock'],
            ['paragraphStyle', 'blockquote'],
            ['bold', 'underline', 'italic', 'strike', 'subscript', 'superscript'],
            ['fontColor', 'hiliteColor', 'textStyle'],
            ['removeFormat'],
            // '/', // Line break
            ['outdent', 'indent'],
            ['align', 'horizontalRule', 'list', 'lineHeight'],
            ['table', 'link', 'image', 'video', /** 'math' */], // You must add the 'katex' library at options to use the 'math' plugin.
            ['fullScreen', 'showBlocks', 'codeView'],
            ['preview', 'print'],
        ],
        width:"100%",
        height:"200px",
        showPathLabel: false,
        imageFileInput : false,
        imageWidth: "300px",
        imageHeight: "300px",

Edit 2: The bug does not seem to reproduce if I select any direction other than 'basic'
Edit 3: Upon further experimentation, it seems to happen when there is no focus on the editor itself. It seems to replace an existing image / icon I have on the left side nav

@ZoltanAtFlyte
The issue is not reproduced.
What browser have you tested and editor version?

The 2.28.3 version has been updated.
If this issue has not been resolved, please reopen this issue.
Thank you.


[Enhancement] Take object as an argument for translation

By putting object argument, it gives more choice and readability.
eg.  $t({ locale: "en_US" }); or $t({ locale: "en_US", key: "ui.title.name" });

Included in release: 1.0.8


mvn build issues

I'm not the best maven person, but I'm pretty sure something needs to be added to the README for connecting to the bcgov specific jar files references in the pom.xml file.  Thanks!
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building did-auth-relying-party 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for fi.trustnet:verifiable-credentials-java:jar:0.1-SNAPSHOT is missing, no dependency information available
[WARNING] The POM for decentralized-identity:uni-resolver-client:jar:0.1-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.263 s
[INFO] Finished at: 2018-03-21T16:48:48-04:00
[INFO] Final Memory: 10M/309M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project did-auth-relying-party: Could not resolve dependencies for project ca.bcgov.didauth:did-auth-relying-party:war:0.1-SNAPSHOT: The following artifacts could not be resolved: fi.trustnet:verifiable-credentials-java:jar:0.1-SNAPSHOT, decentralized-identity:uni-resolver-client:jar:0.1-SNAPSHOT: Could not find artifact fi.trustnet:verifiable-credentials-java:jar:0.1-SNAPSHOT -> [Help 1]

Yes this project requires several dependencies that are not yet available in Maven and have to be built manually. I'll add instructions for this to the README.


enableCsrfProtection

Is shaping up to be the neatest forms solution in my view ( I have tried a few). Only snag i found is if you have enableCsrfProtection in the config you cant edit forms in admin. Should be an easy fix.
Cheers for adding honeypot.

oh yes thanks for that, I'll push the fix in the next release.
For now it's a simple fix
add 	{{ getCsrfInput() }} to the top of templates/forms/_edit.html

or if you are not up to messing with the plugin code, turn off csrf while editing the form :P

Thanks... Thats what i had done. Nice plugin


Vickel: Watch ^vape[\W_]*+mode$

Vickel requests the watch of the watch_keyword ^vape[\W_]*+mode$. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

^vape[\W_]*+mode$ has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Update Composer dependencies (2021-07-03-00-04)

Visual regression test passed!
View the visual regression test report


Fails to use with replace

I imported window as suggested in README and have the following beforeModel hook in index.js route:
import Route from '@ember/routing/route';
import { inject as service } from '@ember/service';
import config from '../config/environment';
import isFastBoot from 'ember-simple-auth/utils/is-fastboot';
import UnauthenticatedRouteMixin from 'ember-simple-auth/mixins/unauthenticated-route-mixin';
import window from 'ember-window-mock';

export default Route.extend(UnauthenticatedRouteMixin, {
  session:      service('session'),
   _isFastBoot: isFastBoot(),

  beforeModel: function() {
   this._super(...arguments);
    if (this.get('session.isAuthenticated')) {
      this.transitionTo('dashboard');
    } else {
      if (!this.get('_isFastBoot')) {
        let oauthUrl = config.oauthUrl;
        let clientId = config.clientID;
        let redirectURI = `${window.location.origin}/callback`;
        let responseType = `token`;
        let scope = `profile%20openid`;
        window.location.replace(oauthUrl
                              + `?client_id=${clientId}`
                              + `&redirect_uri=${redirectURI}`
                              + `&response_type=${responseType}`
                              + `&scope=${scope}`
        );
      }
    }
  }
});

Then when running the simple acceptance test:
import { module, test } from 'qunit';
import { visit, currentURL } from '@ember/test-helpers';
import { setupApplicationTest } from 'ember-qunit';
import { authenticateSession } from 'ember-simple-auth/test-support';
import setupMirageTest from 'ember-cli-mirage/test-support/setup-mirage';
import { setupWindowMock } from 'ember-window-mock';

module('Acceptance | Dashboard', function(hooks) {
  setupApplicationTest(hooks);
  setupMirageTest(hooks);
 setupWindowMock(hooks);

  test('Authenticated users can visit /dashboard', async function(assert) {
    let shop = this.server.create('shop');
    this.server.create('user', { shop });

    await authenticateSession({
      access_token: 'abcdDEF',
      token_type: 'Bearer'
    });
    await visit('/dashboard');

    assert.equal(currentURL(), '/dashboard', 'user is on dashboard page');
  });
});

It fails as follows

Why so and what am I missing?
The actual behavior outside tests is as follows:

if a User is not authenticated, he is redirected to the corporate gateway login page
after entering his username and password, he is redirected back to the app as https://myapp/callback#access_token=2YotnFZFEjr1zCsicMWpAA&type=Bearer&expire_in=3600&state=myAppRandomState and ESA (ember-simple-auth) grabs the token.

What is strange, if I change:
assert.equal(currentURL(), '/dashboard', 'user is on dashboard page');

for
assert.equal(window.location.href, '/dashboard', 'user is on dashboard page');

the test fails and displays clearly the difference in the compared URL:

Expected: | "/dashboard"
-- | --

Result: t"https://corporate-gateway-url/as/authorization.oauth2?client_id=decastore&redirect_uri=http://localhost:7357/callback&response_type=token&scope=profile%20openid"

Diff: "https://corporate-gateway-url/ashboar/authorization.oauth2?client_id=decastore&redirect_uri=http://localhost:7357/callback&response_type=token&scope=profile%20openid"

Thank you!

Sorry for the late response, I somehow missed this.
I am not sure how this is supposed to work. window.location.replace() will do nothing in tests (as documented), it will just enable you to assert that the app would  redirect to somewhere without actually doing it (as this would make the browser exit your test suite). But you are not asserting against anything from window.location, so this addon seems to not be involved in this test, or do I miss something?

@simonihmig Thank you for your response. So, as far I understand, using window from ember-window-mock in a route as I do:
# routes/index.js

if (!this.get('session.isAuthenticated')) {
      let oauthUrl = config.oauthUrl;
      let clientId = config.clientID;
      let redirectURI = `${window.location.origin}/callback`;
      let responseType = `token`;
      let scope = `profile%20openid`;
      window.location.replace(oauthUrl
                            + `?client_id=${clientId}`
                            + `&redirect_uri=${redirectURI}`
                            + `&response_type=${responseType}`
                            + `&scope=${scope}`
      );
    }

when running in the test environment, the import will be replaced with a mock.
For that, I'll just have to add this line in a test:
#tests/acceptance/dashboard-test.js

import { setupWindowMock } from 'ember-window-mock';

module('Acceptance | Dashboard', function(hooks) {
  setupWindowMock(hooks);
  setupApplicationTest(hooks);
  setupMirageTest(hooks);
...

And, as you said, the redirect to url in teh above index.js route will be mocked, right ?

Yes, it is mocked. So you could assert that the redirect should have happened:
assert.equal(window.location.href, 'https://corporate-gateway-url/ashboar/authorization.oauth2?client_id=decastore&redirect_uri=http://localhost:7357/callback&response_type=token&scope=profile%20openid');

setupWindowMock() is just necessary to prevent any state on window (like window.location.href) to leak between tests.

@simonihmig OK, thanks a lot. I'll close the issue.


Default

Acceptance Criteria
User clicks the button in order to review:

The amount of cUSD they want to request
The amount of money they want to send to receive the cUSD

Design
https://www.figma.com/file/ERJ7bYyBWdqJw1ID9nZJ2N/Wakala?node-id=3609%3A6602

@Chegemartinx I need your opinion on this.


TrinityConfig: preserve hostname and port in ServerInfo, config secti…

…ons and RemoteStorage.
The IPEndPoint for a comm. instance is only resolved during connection, and failure to resolve results in failure to connect, rather than a failure in an earlier stage (config entry read/write etc.)

@yatli,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

retest this please. PR builder configured to publish test results.


add resource markdown content for anatomies

So, if there is no gtex data for a given uberon, then the gtex widget is blank. See https://github.com/nih-cfde/update-content-registry/issues/20
So, I made a new list of only the uberons sampled by gtex. this does not include the oral cavity.
I confirmed that the widget is working for all the new genes in the list provided. However, the gtex widget is still present in  on the oral cavity page... even though it isn't in the new list. Any ideas what is going on?

note this is on staging see https://app-staging.nih-cfde.org/chaise/record/#1/CFDE:anatomy/nid=1

However, the gtex widget is still present in on the oral cavity page... even though it isn't in the new list. Any ideas what is going on?

I think:
We have to explicitly remove markdown from entries, if we do not update it.
Or, to rephrase it, to remove we have to explicitly push an empty string.

Update

50 anatomies now have GTEx expression widgets
303 anatomies have text that links to the EMBL Ontology search

See https://app-staging.nih-cfde.org/chaise/record/#1/CFDE:anatomy/nid=1


Making IntelliSense work again for Visual Studio 2015

From what I understand from this post : http://stackoverflow.com/a/27671174/128662
And the documentation that reflect it : https://antaris.github.io/RazorEngine/IntellisenseAndResharper.html
The documentation was target to Visual Studio 2013.
It appears that Visual Studio 2015 have changed thing, there is problems arise here and there about Razor not functionning anymore (with MVC), and I guess Razor Engine take his parts too.
I've made small example of dysfunctionning IntelliSense on this repo : https://github.com/cyrilgandon/RazorEngineGenerator/branches
One time it is Linq not availaible, the other, it is C#3+ functionnalities not available, and another : 'The name Context does not exist in the current context'.
Could we have guidelines to start a fresh new project with IntelliSense fully functional for Visual Studio 2015 and RazorEngine? I tried so many things that I give up for now. Web.config, App.config, no config, deleting user, temp files, reinstalling VS..... It seems that error pop up and down in a completely random way.
The best of best should be to have access to a blank solution, or a Demo folder, on GitHub.
Thank you!

That would be great,
the only way I got rid of "... does not exists in the current context" problem is inheriting from a base class (e.g. TemplateBase) but this implies other problems.

Anyone who could do some research on how to do it and publish it here (or via PR for the docs) would be a real hero! Intellisense for RazorEngine always was kind of a hack (sadly).

I am not sure about ASP.NET projects, but have workaround for my Console project:

Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
In app.config (for web.config this should work too, I think):

<system.codedom>
	<compilers>
		<compiler language="c#;cs;csharp" extension=".cs"
		  type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
		  warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
	</compilers>
</system.codedom>

With these steps features like implicit local variables processed (var ...).
Unfortunately, string interpolation does not work. Any suggestions?
P.S. I have ReSharper installed.

@OlegAxenow For C# 6 features like string interpolation, you'll have to use RazorEngine.Roslyn (currently published as a Prerelease) and:
config.CompilerServiceFactory = new RazorEngine.Roslyn.RoslynCompilerServiceFactory();

(more details here)

As for the IntelliSense, I am currently using a class deriving from TemplateBase<T> re-exposing some of the members I need (as described in the current documentation.
It seems to work a bit weird for me too, VS with ReSharper underlines some parts of the line with @inherits and var keywords complaining about "RazorEngine" not being referenced. but Intellisense works.

I've spent some time figuring out the steps needed to have intellisense working and using the C# 6 syntax.
VS Projects
I created three projects to roughly emulate how I want a production setup to look:

Models project. Class library.
Templates project. Class library.
Console project. Console application.

Model Project
Name: RazorEngineRoslyn.Models
Project References: none.
NuGet References: none.
PersonModel.cs
    public class PersonModel
    {
        public string Name { get; set; }
        public string Job { get; set; }
    }

Template Project
Name: RazorEngineRoslyn.Templates
Project References: RazorEngineRoslyn.Models
NuGet References: RazorEngine, Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Create project. (Class Library)
Add RazorEngine nuget package. (Pre-release V4.4.3-rc1)
Update nuget packages.
Add Post Build event commands:
copy "$(TargetDir)RazorEngine.dll" "$(TargetDir)..\RazorEngine.dll" /Y
copy "$(TargetDir)RazorEngine.xml" "$(TargetDir)..\RazorEngine.xml" /Y

At this point you can:

Create using statements for the local project: @using RazorEngineRoslyn.Models
Create using statements for RazorEngine: @using RazorEngine.Templating
Create inherits statements : @inherits TemplateBase
NOTE: There's no need to create a custom TemplateBase class, intellisense correctly resolves it's properties and methods.
Use 'dynamic'.

You can't:

Use interpolated strings, and other C# 6 features. "CS8025 Feature 'interpolated strings' is not available in C# 4.  Please use language version 6 or greater."

Add DotNetCompilerPlatform nuget package. (Microsoft.CodeDom.Providers.DotNetCompilerPlatform)
Update nuget packages. (Restart VS when it asks.)
NOTE:  The DotNetCompilerPlatform DLL is copied to the right directory, but this is done upon install of the nuget package using a powershell script. If the DLL is deleted after install it'll never be copied to the right place again.
Add Post Build event commands:

	copy "$(TargetDir)Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll" "$(TargetDir)..\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll" /Y
	copy "$(TargetDir)Microsoft.CodeDom.Providers.DotNetCompilerPlatform.xml" "$(TargetDir)..\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.xml" /Y

Add to app.config:

  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
    </compilers>
  </system.codedom>

At this point you can:

Use interpolated strings, and other C# 6 features.

NOTE: If your cshtml is showing errors, try closing that file in VS, rebuilding the project, and opening the file again. Steps such as setting the app.config don't seem to affect already open files.
Templates/PersonTemplate.cshtml
@using RazorEngineRoslyn.Models
@using RazorEngine.Templating
@inherits TemplateBase<PersonModel>
@{
    var title = $"{Model.Name}, {Model.Job}";
}
@Raw(title)

NOTE: For this example we'll be loading up the cshtml file directly, so right click the Templates/PersonTemplate.cshtml file in the project, set it's Build Action to Content, and Copy to Output Directory to Copy always. This will make sure that the template ends up in a directory below the console apps output.
Console Project
Name: RazorEngineRoslyn.Cli
Project References: RazorEngineRoslyn.Models, RazorEngineRoslyn.Templates
NuGet References: RazorEngine, Microsoft.AspNetCore.Razor, RazorEngine.Roslyn

Create project. (Cli)
Add RazorEngine nuget package. (Pre-release V4.4.3-rc1)
Update Microsoft.ASpNetCore.Razor nuget package.
Add RazorEngine.Roslyn nuget package. (Pre-release V4.1.0-rc1)
Update nuget packages. (Restart VS when it asks.)
NOTE: Currently fails ... Error Could not install package 'Microsoft.CodeAnalysis.Common 2.0.0-rc2'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework.

Program.cs
using System;
using System.IO;
using System.Reflection;
using System.Security;
using System.Security.Permissions;
using System.Security.Policy;
using RazorEngine.Configuration;
using RazorEngine.Roslyn;
using RazorEngine.Templating;
using RazorEngineRoslyn.Models;

namespace RazorEngineRoslyn.Cli
{
    class Program
    {
        static int Main(string[] args)
        {
            var exitCode = 0;

            if (AppDomain.CurrentDomain.IsDefaultAppDomain())
            {
                var domain = AppDomain.CreateDomain
                (
                    "RazorEngineDomain",
                    null,
                    AppDomain.CurrentDomain.SetupInformation,
                    new PermissionSet(PermissionState.Unrestricted),
                    new StrongName[0]
                );

                exitCode = domain.ExecuteAssembly(Assembly.GetExecutingAssembly().Location);

                AppDomain.Unload(domain);
            }
            else
            {
                var service = RazorEngineService.Create(new TemplateServiceConfiguration()
                {
                    CompilerServiceFactory = new RoslynCompilerServiceFactory()
                });

                var template = File.ReadAllText(@"Templates\PersonTemplate.cshtml");
                var templateKey = "Person";
                var model = new PersonModel() { Name = "Bob", Job = "C# Developer" };
                var output = service.RunCompile(template, templateKey, model: model);

                File.WriteAllText("Output.txt", output);
            }

            return exitCode;
        }
    }
}

Output.txt
Bob, C# Developer

Well it looked good for my small initial test, but as things got more complicated it started falling apart.
I'm currently struggling with intellisense not being able to find ExpandoObject.

Things seem to work significantly better if I use a .Net Core Class Library project.
All I had to do to get it working better than the classic project was:

Create .net core class library project.
Change the framework in project.json to "net46".

This targets DNX and allows other DNX project to consume/to be consumed by this project.

Add two nuget packages:

RazorEngine
Microsoft.AspNetCore.Mvc

After than handful of steps I had intellisense working better than in the original DNX templates project.
e.g. ExpandoObject appears, which is one of the things I was struggling with.

Only a single error remained: CS0115	'_Page_FloodEmail_Body_cshtml.ExecuteAsync()': no suitable method found to override
I checked out the source code for TemplateBase<T> and found that it did have an Execute method which returned a Task, but not ExecuteAsync.
https://github.com/Antaris/RazorEngine/blob/master/src/source/RazorEngine.Core/Templating/TemplateBase.cs#L173
So I made myself a new template base class that has the ExecuteAsync method simply call the Execute method.
    public class TemplateBaseAsync<T> : TemplateBase<T>
    {
        public virtual Task ExecuteAsync()
        {
            return base.Execute();
        }
    }

And that's it, no more errors. No warnings either, other than legit warnings coming from the bad content in one of my test templates.

One thing to note is that the .Net Core Class Library project is targeting .net 4.6.
By default DNX projects are created targeting .net 4.5, meaning your DNX projects can't reference the .Net Core Class Library project.
One option would be to drop the .Net Core Class Library from "dnxcore46" to "dnxcore45", but the "Microsoft.AspNetCore.Mvc" nuget package doesn't support 4.5, so that won't work.
Another option is bumping your DNX projects to 4.6(.1), which will then allow the DNX projects to reference the .Net Core Class Library just fine.
Finally, you could use linked files: https://msdn.microsoft.com/en-us/library/windows/apps/jj714082(v=vs.105).aspx
(The article is aimed at WinPhone 8 devs, but linked files work almost anywhere in VS.)

Another issue is the copying of the template from the template project to the Cli apps binary output.
DNX projects have the option to mark a file as copy always, and that includes when it's being referenced.
Unfortunately the project.json build system only has support for copying files to the output of the containing project. i.e. they'll get copied to templateproject/bin/debug/templates, but not cliproject/bin/debug/templates.
https://github.com/dotnet/cli/issues/2902
It appears this issue won't be fixed in project.json files as the build system is being moved back to MSBuild.
It's good that MSBuild will fix the problem, but support for that won't be included until VS2017.
As with the previous issue, linked files are one option to handle this.
Obviously this isn't an issue if you manually copy around your templates, or otherwise move them around outside of the build system.

The errors appear to be intermittant.
While my earlier work banished them, they're now back, but slightly different.
The classic "_Page_Templates_FloodEmail_Body_cshtml.Execute(): return type must be 'Task' to match overridden member TemplateBase.Execute()" has returned which confuses me as earlier it was complaining about a missing ExecuteAsync method which I fixed.
I "feels" like it's switching between cshtml editor versions. Earlier I got the newer one which produced less errors, and now I'm getting the old one again.


function parsetgen does not generate column nos

function parsetgen does not generate column nos

parsetgen function does not provide nos column. If you need one, use out<-parsetgen() followed by final<-parstgen.cond(out)
The notes section was added to parsegen documentation #6642b31


Find free port if 3123 is in use

Heya!
I've been making extensive use of this library recently, and it's been super useful.
I've been using it so much that I often find myself wanting to run two instance of budo + browserify-hmr at once. Currently this fails with a port in use error.
I've changed it to use find-port to find the next available port.
The only downside I can think of is if you explicitly specify a port that is in use, it will find the next free port, so it might end up running in a different place than you expect.
I would love to write a test for this but I'm not quite sure how to go about it with coroutines and promises. If you have any thoughts I would love to hear them.

This doesn't work. (The parameter to .then must be a function, findPort expects two parameters, and it doesn't write the new port number into the bundle.) The example/ directory depends on the NPM-published version of browserify-hmr; are you sure you weren't testing with that? (I usually replace example/node_modules/browserify-hmr with a symlink to ../.. when manually testing.)
It is a good feature idea though. I was wondering if anyone was going to request this.
I looked at the find-port module and noticed there's a race condition with its design: another process can start listening on the port between the time find-port tells you a free port number, and you start listening on it. This could easily happen when someone starts up a build script that starts multiple browserify-hmr instances. I've just made the listen-on-free-port module which addresses this and I'm going to implement this in the next version of Browserify-HMR along with some other options changes.

Excellent! Thanks for implementing this. I must have indeed testing against the wrong version.


Fix regression: reconcile failing

Reconcile loop failed when changing an image version. This is because
the label version is inferred as k8s label AND selectors, but selectors
are immutable. Hence I removed them from the selector, it doesn't change
the selection logic

/approve


Make an embed for the mdn command

oh and exploit both npm & mdn source code to return the first result in the embed

as a quick improvement the link is returned in an embed, and the command will return an error if there is no arguments

this issue became a duplicate so lemme close it


Reapply "Jupiter 5.7.0"

Reverts vespa-engine/vespa#15054

@bjorncs could you comment on the change in  tenant-cd-api/pom.xml?  Is it OK to bump the version here and in internal repo or does the comment indicate that more needs to be done?

FYI @tokle


Fix crash for web socket in some race conditions

Fixes #21086.
Fixes #6117.
This PR fixes a crash caused by a race condition when webSocket deallocated and NSStream delegate callback, because NSStream's delegate callback be called on RCTSR_networkRunLoop.
This PR mainly changes:

Remove unnecessary nil operation in dealloc method.
Add a new method _scheduleCleanUp to schedule webSocket cleanup also on RCTSR_networkRunLoop.
In stream:(NSStream *)aStream handleEvent:(NSStreamEvent)eventCode delegate method, add a wself to make safe further.

Test Plan:
Reproduce steps:
Run any react-native project, and keep it running, it would crash at some point.
Changelog:
[iOS] [BUGFIX] [RCTSRWebSocket] - Fix crash for web socket in some race conditions.

Thanks for opening this new PR :)

@cpojer Emm, I did try to find a way to test it, but I have no idea currently, because it's a race condition, RCTSRWebSocket is deallocating and another runloop calls its method.

Runloop callback the delegate method, but delegate object already released:

[In environment Xcode10.1 react-native：0.55.4 react:16.3.1 ,I have modified RCTSRWebSocket.m and still crashes，What is the cause?

I can confirm that I'm also seeing this crash in my app. No idea how to repro though.
OS Version: iOS 12.1 (16B92)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: BUS_NOOP at 0x0000000000000010
Crashed Thread: 13

Application Specific Information:
class > respondsToSelector: > stream:handleEvent: > XTUM >
Attempted to dereference garbage pointer 0x10.

Thread 13 Crashed:
0   libobjc.A.dylib                 0x3abb07d70         objc_msgSend
1   libobjc.A.dylib                 0x3abaebe7c         -[NSObject respondsToSelector:]
2   CoreFoundation                  0x3ad5aeed4         _inputStreamCallbackFunc
3   CoreFoundation                  0x3ad5db030         _signalEventSync
4   CoreFoundation                  0x3ad5d8134         _cfstream_solo_signalEventSync
5   CoreFoundation                  0x3ad5d7f14         _CFStreamSignalEvent
6   CFNetwork                       0x3ae3ade98         SocketStream::dispatchSignalFromSocketCallbackUnlocked(SocketStreamSignalHolder*)
7   CFNetwork                       0x3ae3b3768         SocketStream::socketCallback(__CFSocket*, unsigned long, __CFData const*, void const*)
8   CFNetwork                       0x3ae3af4a0         SocketStream::_SocketCallBack_stream(__CFSocket*, unsigned long, __CFData const*, void const*, void*)
9   CoreFoundation                  0x3ad5cf5a8         __CFSocketPerformV0
10  CoreFoundation                  0x3ad5c81cc         __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
11  CoreFoundation                  0x3ad5c814c         __CFRunLoopDoSource0
12  CoreFoundation                  0x3ad5c7a30         __CFRunLoopDoSources0
13  CoreFoundation                  0x3ad5c28fc         __CFRunLoopRun
14  CoreFoundation                  0x3ad5c21cc         CFRunLoopRunSpecific
15  Foundation                      0x3aea4a404         -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
16  th3rdwave                       0x202fe523c         _ZN5folly6detail8function14FunctionTraitsIKFbRKNS_7dynamicES5_EE10uninitCallERNS1_4DataES5_S5_
17  Foundation                      0x3aeb7d1ac         __NSThread__start__
18  libsystem_pthread.dylib         0x3acf7f2ac         _pthread_body
19  libsystem_pthread.dylib         0x3acf7f20c         _pthread_start

@janicduplessis we have been using this patch in our prod app for months now (more or less) and it's working super well for us.
And yes I don't have a way to repro either, it's a weird prod edge case.

[In environment Xcode10.1 react-native：0.55.4 react:16.3.1 ,I have modified RCTSRWebSocket.m and still crashes，What is the cause? @zhongwuzw

Emm, seems it's the apple's internal bug? maybe it's not related to this issue?


SASS: Unable to compile SCSS variables and media queries

Problem
I am just getting started with Shopify/Slate so i would do my best to explain my problem. Please do ask if you need any specific information with regards to the description or the replication of my problem. Now,
Uncompiled variables:
I am trying to declare SASS variables in the file called variables.scss.liquid but its not getting compiled to valid css values. For example, if i have a variable called $black: #333 in the aforementioned file and i use it in my scss files as color: $black; the dev tools, after compiling shows color: $black instead of color: #333.
I have the variables.scss.liquid file imported into the theme.scss file like so: @import url('settings/variables.scss.liquid'); and i have included the theme.scss file in my theme.liquid file like so {{ 'theme.scss' | asset_url | stylesheet_tag }}
Uncompiled media queries:
.navbar {
	z-index: 6;
	// ERROR TODO: sass like syntax doesnt compile to valid css
	// @media (min-width: 992px) {
	// 	.navbar {
	// 		display: block;
	// 		padding: 40px 15px;
	// 		transition: all .25s ease;
	// 	}
	// }

        // ERROR TODO: sass like syntax doesnt compile to valid css
       @include media-query($medium-up) {
	.navbar {
		padding: 40px 15px;
		transition: all .25s ease;
	     }
      }
	&.is-scrolled {
		padding: 15px;

		.navbar-brand {
			a {
                               // DOESNT WORK
				@media(min-width: $sm) {
					width: 150px;
				}}}}
          } // END OF .navbar css block

// media queries defined outside of class blocks
// ERROR TODO: sass like syntax doesnt compile to valid css
@include media-query($medium-up) {
	.navbar {
		padding: 40px 15px;
		transition: all .25s ease;
	}
}
// Normal css way of writing media queries. WORKS!
@media (min-width: 992px) {
	.navbar {
		// display: block;
		padding: 40px 15px;
		transition: all .25s ease;
	}
}

in the console, the above code shows up like so:
.navbar {
    display: block;
    background: $black;
    color: #fff;
    padding: 30px 15px;
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    z-index: 6;
    @media (min-width: 992px) {;
    .navbar {: ;
    display: block;
    padding: 40px 15px;
    transition: all .25s ease;
    }: ;
    }: ;
    &.is-open {: ;
    .navbar-links {: ;
    transform: translate(0, 0);
    }: ;
    .nav-pages {: ;
    display: block;
    @media(min-width: $md) {;
    display: flex;
    }: ;
    }: ;
    }: ;
    &.is-scrolled {: ;
    padding: 15px;
    .navbar-brand {: ;
    a {: ;
    @media(min-width: $sm) {;
    width: 150px;
    }: ;
    @media(min-width: $md) {;
    width: 180px;
    }: ;
    }: ;
    }: ;
    @media(min-width: $md) {;
    padding: 20px 15px;
    }: ;
    }: ;
}

I am running the regular slate commands in vscode terminal: slate watch, slate start.
Any help will be much appreciated.

Hey @binarytrance -- if you are using the .scss.liquid extension, the styles are compiled on Shopify servers since we can't compile liquid files locally. Basically, shopify servers compile scss.liquid to .scss and then to .css -- this is why things don't look compiled when you build locally.
If you wish compile locally (and we encourage you to do so), use .scss files. Please rease the Styles with Liquid for all the info you should need.


Add a benchmark suite to GPflow.

Add a benchmark suite to monitor regressions.

Have some "minimal" set of benchmarks for continuously monitoring regression.
Should be extensible to make it easy to test/benchmark new features, (but without adding them to the set of minimal benchmarks).

It would be nice with integration into CI.

The current solution doesn't work, because the CircleCI worker cannot push to develop because that branch has special protections...


no saveModel function?

Hi,
Your implementation is good. There is a function gcf.fit(X_train, y_train) for training and gcf.predict(X_test) for testing.
Is there a function like saveModel() for saving  gcf.fit(X_train, y_train)'s result,and a function like lodelModel() for loading gcf.fit(X_train, y_train)'s result ?

Hi,
There is not yet such functions, obviously meaning that as soon as you close the python session you lose everything.
That is definitely something I will consider including in the next update!

Thanks for replying.
I have an other question.when my own dataset has 50,000 rows,your code run well,however ,when my own dataset has 500,000 rows,00B error happens.
I have tried increased  the number of trees and re-running the training,but still get the error.I have tried  gcf = gcForest(shape_1X=16, window=8, tolerance=0.0, min_samples_mgs=30, min_samples_cascade=30),
gcForest(shape_1X=16, window=8, tolerance=0.0, min_samples_mgs=80, min_samples_cascade=80),
gcForest(shape_1X=16, window=8, tolerance=0.0, min_samples_mgs=120, min_samples_cascade=120),
even gcForest(shape_1X=16, window=8, tolerance=0.0, min_samples_mgs=200, min_samples_cascade=200)!but still get 00B error...
How to solve it?

The OOB error is almost expected.
According to the line of codes you copied you have changed the stopping criterion when building trees and not the number of trees. So just to make things clear :
min_samples_mgs and min_sample_cascade control the construction of each tree and more precisely the stopping criteria. If at a node you have reached the minimum of samples no further spli will be done.
If you want to change the number of trees per forest you need to use : n_cascadeRFtree and n_mgsRFtree
Anyway, you can increase the number of trees and see if the error disappear or it is also possible to remove the OOB score function and use a 3-fold cross validation which will not return any error but will take (much) longer to compute.
Is the answer satisfying?

Thanks.I will try again.

Thanks again.Your code runs well after increasing n_cascadeRFtree and n_mgsRFtree .

Code has run 2 more days for training 500,000 rows datas(still training). So  a saveModel function is very important.If you finish updating  your saveModel function,please contact me.Thanks.

@dingtiandu I'm a little bit busy this week but you can look at this link on how to save models outside python :
http://machinelearningmastery.com/save-load-machine-learning-models-python-scikit-learn/
It looks pretty straightforward (...) and will definitely include it in the next update. Let me know if make it work or if you have any problems.

Hi,I used joblib function(http://machinelearningmastery.com/save-load-machine-learning-models-python-scikit-learn/),and the code  worked well.Thanks.

@dingtiandu I have updated the README and added a note in the notebook on how to use sklearn.joblib properly to save and load models.
Thanks for your contribution!


eventhandling

Hi,
I successfully integrated PopMenu to my project. Are there any eventhandlers for the buttons?
thx

*Please correct me if I'm wrong.
For @mpnguyenreply question, I think it could be answered by the PopMenuExample.
You will find this code as below:
_popMenu.didSelectedItemCompletion = ^(MenuItem *selectedItem) {
NSLog(@"%@",selectedItem.title);  <-- Here is where you receive the event handlers from buttons.
};

@baby03201 _popMenu.didSelectedItemCompletion = ^(MenuItem *selectedItem) {
NSLog(@"%@",selectedItem.title);
};    how to swift?

@pengleyang FYI
popMenu.didSelectedItemCompletion = { selectedItem in
print(selectedItem.title)
}


Task 1089 font awesome

Changes in this Pull Request:

Added font-awesome to ivy-build.
Included in branding-package.
Local URL in .xhtml pages instead of CDN.

Mandatory checks:

[X] Branch is up to date (latest changes were fetched from the upstream branch before creating this PR)
[X] Changes were tested manually
[ ] Java code changes are unit tested
[ ] Webtests are successful

To be checked by the reviewer:

[ ] Clean Java code and unit tested changes
[ ] UI customizablity is preserved: No hard-coded styling and URL references in JSF views

To be checked by the pull request owner:

[ ] .MASTER/job/BES_MASTER_IT/
[ ] .MASTER/job/OSCM_WS_Tests_INTERNAL/
[ ] .MASTER/job/OSCM_WS_Tests_OIDC/
[ ] .MASTER/job/OSCM_Integration_Tests_INTERNAL/
[ ] .MASTER/job/OSCM_Integration_Tests_OIDC/

Cross repository and core changes:

[ ] Interdependent changes have been communicated to the team (if applicable)
[ ] This pull request includes high risk modifications or core changes (e.g API, datamodel, authentication...). Mandatory reviewers: @goebell or @kowalczyka.

OSCM Build References:

<CI node number>: <tag>, example: ci10:goebell
-est6

Screenshot (if applicable):

add a screenshot illustrating your change

This change is

oscm-portal/WebContent/marketplace/templates/errorcontent.xhtml, line 17 at r3 (raw file):
Previously, GoebelL (Lorenz Goebel) wrote…
This is not customizable? Why not ?

Done.

oscm-portal/javasrc/org/oscm/ui/beans/SessionBean.java, line 377 at r4 (raw file):
Previously, GoebelL (Lorenz Goebel) wrote…
I am missing a JUnit test in your change set, that covers the bootstrapBrandBaseUrl check when getMarketplaceId() is null.

There is already a unit test implemented.


Add control parameters to TextSummaryTask

Is your feature request related to a problem? Please describe.
TextSummaryTask is a great way to quickly summarize input text without needing to use COT. At the moment there isn't much control provided to the developer on how the given text should be summarized.
Describe the solution you'd like
It would be great to have some additional parameters (names TBD) such as:

length
target audience
format

This would let us summarize with a specifc length (3 sentences, 2 paragraphs, etc) or for an audience (child, executive summary) or in a format (bullet points, yaml, json) etc.

Implemented in https://github.com/griptape-ai/griptape/issues/342


using document and adding a more helpful error

This uses Document instead of tokenize, per @chrisjsewell 's latest comments about improvements to that class.
It also adds a simple try/except block to capture any errors associated with parsing the notebook and display a message that includes the notebook cell and path. @chrisjsewell do you think this is a reasonable way to handle this? Know of a better way to get the error message to display? I know it's not idea because the errors won't propagate past this step in Sphinx, but as a stopgap is it the right improvement?

updated this PR with (I think) a better error reporting mechanism (now using self.reporter)


Fix the embedded map in 'CONTACT SECTION' which is out of box when viewed in small screen❗

Description

When the embedded map location viewed in small screen size like mobile, is not fixed in the layout properly.
It comes out of the current layout. Please fix this map appropriately
Screenshots

Points to be noted
-- Please give the brief desciption of the PR with required screenshots
-- Pull the repo properly and then make required changes:)
-- We will review it soon and would be very happy to merge your PR 😃

I am here to fix it. :)

Thanks @Git21221 , Please open a PR . We will soon review and merge it:)

please assign me this issue