Infix notation for function call / invocation.

There doesn't seem to be much support for supporting custom operators (see #818) in Rust. But what about calling normal binary functions as if they were operators, like haskell allows you to?
The syntax would be:
a `dot` b

to convey scalar product of two vectors a and b.
Another option suggested by @bluss:
a \dot b

Or if it possible without parsing conflicts (@thepowersgang: "but probably not dersirable"):
a dot b

Which is converted to
a.dot( b )

or, depending on the function:
dot( a, b )

This is a TIMTOWTDI feature with very little (any?) gain. It doesn't read terribly well either.

Also discussed in: https://github.com/rust-lang/rust/issues/8824

TIMTOWTDI = There's more than one way to do it
There's nothing inherently wrong with having more ways to do one thing.
Some prefer reading a dot b to a.dot( b ) since it gives a more "mathematical" feel to it.

a \dot b is the nicest syntax I have seen proposed for this (taken from the previous discussion).
The idea is to introduce one more operator to end all custom operators. Instead of defining custom operators, we can just use functions for this purpose.
I know the argument that methods are infix, x.dot(y) is infix. The infix binary function call proposal has advantages:

Functions already support: namespacing, importing and renaming. Functions can also use their own traits that they defined for the operands, so we get quite a lot of flexibility by reusing an abstraction we already have (functions are great!).
It staves off parenthesis build up. Methods may result in nested calls like x.dot(y.dot(z.dot(w)))).

x \dot y \dot z \dot w is easier to read and even a parenthesized infix call version is easier to read:  x \dot (y \dot (z \dot w)).

Free functions can coerce or use a conversion trait bound on both arguments, where methods can not do that for the first argument.

:+1:

It doesn't seem beyond the wit of man that someone might reasonably expect a library-defined operator whose return type is the same as that of the first operand to be usable as an augmented assignment. How easy is that to do?

Discussion on fixity from IRC, for future reference...:
151205            vfs | Centril: are those to have some hard-coded precedence?
151242          bluss | Centril: if you want to. You can just say that either one or the other is a possible
                      | implementation
151301          bluss | proposals like this are judged from superficial issues like syntax too
151321        Centril | vfs: it would have to I guess, how high it should bind I don't know yet
151331          bluss | I mean, the syntax is important in the end, but it doesn't decide if the feature is worth
                      | having or not by itself
151357        Centril | bluss: would it be possible to skip the \ alltogether and just have a dot b ?

															[...]

151924            vfs | Centril: what about associativity? bluss comment seems to suggest right associative, but
                      | afaik all rust operators are all left associative.
151942        Centril | vfs: haskell says:
                      | http://stackoverflow.com/questions/8139066/haskell-infix-function-application-precedence
151956        Centril | infixl 7 `dot`
152204          bluss | vfs: wouldn't the comment suggest left associative, if the (x (y  z)) version is the one
                      | needing explict ()'s
152220        Centril | so in haskell, a `plus` b `plus` c == (a `plus` b) `plus` c
152256            vfs | bluss: `x.dot(y.dot(z.dot(w))))` <-- this does if i read it correctly
152353        Centril | vfs is correct that it is right associative because it evaluates z.dot(w) fist
152357          bluss | anyway, it's not intended to suggest anything
152453        Centril | vfs bluss: one could (possibly) add an attribute to a function specifying its fixity if a
                      | default one isnt good
152533            vfs | what if function is in another crate?
152549       oli_obk_ | Centril: and how would that work together with other infix functions?
152636        Centril | vfs: then the fixity information would have to be carried over into the metadata in some
                      | way i guess
152644          bluss | vfs: the attribute should be on the function
152655          bluss | You'd use this with a function intended to be callable infix
152754        Centril | or, maybe you could know if it is left associative or right depending on where \ is, so x
                      | \dot y or x dot\ y
152807        Centril | maybe thats a bad idea, just brainstorming atm
152828        Centril | oli_obk_: ideas :) ?
152842            vfs | bluss: so you would need to external crate metadata to know how to parse an expression?
                      | (maybe it is the case already now, idk)
152917          bluss | vfs: that's a good point, that doesn't sound workable to me
152919        Centril | guess we need someone who knows the compiler better to flesh that out
152931          bluss | even if crates can inject macros etc
152947        Centril | so maybe it a better idea to specify fixity at call site?
153039       oli_obk_ | Centril: you can't decide it globally. So you can say that a function has a higher fixity
                      | than another function. This way you get a tree of rules depending on the crate dependency
                      | tree. Similar to impl orphans
153117       oli_obk_ | Centril: then you can simply force infix to require brackets if you're specifying it at
                      | the call site
153129       oli_obk_ | and if you are doing that, you can go the macro way
153212       oli_obk_ | a `$lhs:expr $fun:path $rhs:expr` => { $fun($lhs, $rhs) } rule should do it
153255        Centril | so, umh, rephrase .P ?
153351       oli_obk_ | which part? the one about fixity at the call site or the fixity tree?
153423        Centril | all of the above :P
153555       oli_obk_ | if you want to specify the fixity at the call site, you can simply use brackets and force
                      | them. so it would be something like `\(a dot b)` transforms to `dot(a, b)`, but then you
                      | don't gain much over macros: `i!(a dot b)` might be possible, maybe one needs `i!(a \dot
                      | b)`
153722       oli_obk_ | if you want to specify the fixity at the definition site, you need to specify it for all
                      | infix functions that your infix function can be in the same expression with. That might
                      | not be very feasible, but at least complete.
153724        Centril | well, if you have a default fixity, say infixl, then you can write a \dot b \dot c , or
                      | force it: a \dot (b \dot c)
153822        Centril | oli_obk_: haskell does it at definition site, but it has a default fixity of infixl 9
153902       oli_obk_ | that works if you only have one function
153914       oli_obk_ | but what about `a \foo b \bar c` ?
153921        Centril | problems =)
153932        Centril | or: first come first served
154108       oli_obk_ | Centril: what about `vec \add_each_value vec2 \mul_each_value vec3` ? (in matlab terms:
                      | `vec + vec2 .* vec3`
154206        Centril | well yes, that isnt so nice since that would eval to (vec1 .+ vec2) .* vec3

															[...]

154759        Centril | oli_obk_: but i think that left associative with first-come-first-serve still might be a
                      | good simplification that makes it crystal clear
154831        Centril | otherwise you have to read about the fixity in the documentation, etc.

I like custom infix operator  as long as limited in ascii letter. But I don't like if you can turn any arbitrary function  to infix call. When I create function foo, I expect the function to be used like this: foo(a,b). When I want to create custom infix notation, I expected to implement the necessary trait.
see previous discussion in https://users.rust-lang.org/t/infix-functions/4724

Does it interact with generics? Would we end up with a \dot::<Foo<'a>, Bar> b?

@durka Probably, you'd have to specify it somehow with generics, and what you've come up with seems best. But I guess you'd save \dot for cases when the types can be inferred from the Exprs.

I don't want this in the language. I think it adds a lot of complication, and it's unimportant to me personally. However, I wouldn't be too opposed to this. It seems nice, especially, for mathematical code.

@ubsan You're saying you're against the feature but wouldn't oppose it, if it made it's way into the language?

Infix functions are great in languages like Haskell where operators are more common, but it doesn't seem to give Rust much.

Are there examples of projects where this would result in a decent ergonomic improvement?

@AndrewBrinker I venture a guess that writing mathematics libraries, e.g: linear algebra, and using them, as well as the low level parts of physics engines might benefit from the increased ergonomics.
Essentially, inside and outside anywhere where a lot of math is needed.

@Centril The existing overloadable operators covers 95% of those use cases.

Would this mean we could write obfuscated code that compiled both in Rust and TeX?  ;)
I love the infix operator notation in Haskell, partially because not all mathematical operators to *, +, etc. even when mathematicians write them that way.  I love Haskell's lack of parentheses on function calls too though.  Yet, Rust is a rather different language, so tools like currying do not always fit.
At first blush, I'm thinking one should start with just knowing when to avoid, or argue against, using object . notation around mathematical objects.  If for example, we're doing an action, scalar multiplication, etc. then object notation looks like a left action, which gets annoying if you are not a group theorist from Britain or something.
I fear this proposal makes the left vs right action issue worse.  In other words, a \dot b might be more useful for mathematics as b.dot(a) than as a.dot(b), but that seems confusing in non-mathematical situations.
In the long run, one could probably build a strict functional language with Haskell-like syntax, maybe an Idris fork, that compiles to Rust code, but does not introduce a garbage collector.  I'd suspect that's a better way to build DSLs that compile to Rust.

It strikes me that, although it wouldn't be super pretty, procedural macros could be used to provide as flexible a mathematical notation as is desired, without the introduction of infix function application.
Actually, looking at the IRC log @Centril includes above, it seems this idea has been mentioned previously. It would be some extra work, and would be strictly-speaking less flexible than infix function application, but it is something that would work today without changes to the language.

I was going to post this in #818 but it's more appropriate here.
I'm in favour of infix functions. User definable operators can be a bit tough to wrap your head around depending on how they're defined, but simpler, more rigorous operators like . and $ are very convenient control operators that also eliminate the overhead of parentheses, like @bluss said. Respectively they are function composition, and function application.  It's actually doable with auto-currying which is a topic that has been discussed quite a bit for Rust. This is specifically useful when you're doing higher-order programming, and sending functions around to other functions, or returning functions; like map. And once you have auto-currying you can also partially apply infix functions.
let insertValue = (`mapInsert` value)
let addPair = insertValue(key)
addPair(hashMap)
=
(key `mapInsert` value)(hashMap)
=
mapInsert(key, value, hashMap)

We also have to think about the default associativity and precedence of infix functions. In Haskell they are left associative and have the strongest precedence so they bind tightly. Maybe it would be nicer if they bind weakly instead? And should it be user definable? Assuming it is, how would that be made verbose to the user? It wouldn't be easy to figure out without attaching it to the name of the function itself as far as I can think, so infix functions with different associativity and precedence can be a bit opaque to users, which is alike the argument against user-definable operators.
-- Tight precedence
(10*n+1) `insert` myList
-- Weak precedence
10*n+1 `insert` myList

These are tradeoffs in tightly binding vs weakly binding by default.

@burdges: I fear this proposal makes the left vs right action issue worse. In other words, a \dot b might be more useful for mathematics as b.dot(a) than as a.dot(b), but that seems confusing in non-mathematical situations.

Yes, this seems to be the central problem... It is solvable, but one has to decide which way to go...
The various alternatives seem to be:

Global fixity, either always left or right associativity. So: a \cross b \cross c == (a \cross b) \cross c or: a \cross b \cross c == a \cross (b \cross c). This is likely the worst possible solution.

Definition site precedence and fixity, which how haskell does it. This is problematic, since fixity and precedence must be stored in the crate metadata - and if the library did not store fixity information because the developer omitted it, then you must fall back to a default fixity like haskell does. This also means that this information must be looked up in the documentation, and since we don't have a nice tool like ghci :i to get the fixity this can slow developers down a notch - but I guess this is a problem with function documentation anyways - you still have to read it.

Call site fixity: Left and right is decided by where the infix syntax modifier is located, or how it looks like. For example: vec \add vec2 \mul vec3 == vec.add( vec2.mul( vec3 ) ), while vec /add vec2 \mul vec3 == vec3.mul( vec.add( vec2 ) ). /add could be replaced with add\, or if possible, you could use !add and add!. All in all, this seems a bit arbitrary, so I prefer definition site fixity.

@burdges: In the long run, one could probably build a strict functional language with Haskell-like syntax, maybe an Idris fork, that compiles to Rust code, but does not introduce a garbage collector. I'd suspect that's a better way to build DSLs that compile to Rust.

This sounds like an awesome idea! It could just compile to HIR directly perhaps and let rustc do the rest...

@AndrewBrinker: It strikes me that, although it wouldn't be super pretty, procedural macros could be used to provide as flexible a mathematical notation as is desired, without the introduction of infix function application.
Actually, looking at the IRC log @Centril includes above, it seems this idea has been mentioned previously. It would be some extra work, and would be strictly-speaking less flexible than infix function application, but it is something that would work today without changes to the language.

The problem with procedural macros here is that you have to use the procedural macro, inducing the visual overhead of the macro itself. Having to do: infix!(a \cross b \cross c) is not really pretty.

@Shou: What about functions of >2 arguments, though? It's actually doable with auto-currying which is a topic that has been discussed quite a bit for Rust. This is specifically useful when you're doing higher-order programming, and sending functions around to other functions, or returning functions; like map. And once you have auto-currying you can also partially apply infix functions.

 Rust is both eager and has manual memory management. Thus, every time you partially apply a function, its arguments must be moved to the heap, and then you have to deal with Box, Rc, Arc and so on...
Some developers might start using currying by default as a nice style of writing, but be completely unaware of the massive relative performance penalty.

I think by now, enough has been fleshed out to create an RFC out of this issue... what does @bluss think?
There is one area in particular where some help is needed...
Regarding storing the fixity and precedence in the crate metadata:

does Rust currently store any metadata for anything else?
how difficult + wise/unwise would this be?
what are the potential problems and pitfalls?

Thus, every time you partially apply a function, its arguments must be moved to the heap, and then you have to deal with Box, Rc, Arc and so on...

Some developers might start using currying by default as a nice style of writing, but be completely unaware of the massive relative performance penalty.

Lambdas are not automatically/implicitly moved to the heap, only if you explicitly box them, and with impl Trait it will be possible to avoid that in many more cases than today.  Any partial application syntax would presumably desugar the same way.

(Maybe this discussion is getting off-topic?)

Lambdas are not automatically/implicitly moved to the heap, only if you explicitly box them, and with impl Trait it will be possible to avoid that in many more cases than today. Any partial application syntax would presumably desugar the same way.

True, my bad. However, if you return the function itself, then that function's arguments must be boxed & move:ed, https://doc.rust-lang.org/book/closures.html#returning-closures
It follows that if you want to pass the lambda to another function as an argument that the same logic applies.
In most cases (this is just a hypothesis) where you'd want to partially apply a function, you either want to return the function or pass it to something else. Purely partially applying a function and using it within the same stack frame doesn't seem like a big use case to me.

I like the \dot syntax, especially for mathematical libraries, but I would caution against going too far with it. Porting half of Haskell syntax and semantics into Rust, as @Shou seems to suggest, seems like a horrible idea.
IMHO this syntax should only support binary functions, not methods. A binary function is a much better fit than a method for the concept of a mathematical operator, and with Rust functions, I don't think there would be any loss of functionality.
Additionally, I would recommend against any precedence or associativity declarations, like infixr 9. The reason is that operator precedence bugs are already common enough, no need to introduce additional crate-defined rules into the mix. These "synthesized" operators should all have the same precedence and associativity. I'm personally fond of universal right-associativity, from APL, but left-associativity would probably be more obvious to everybody else.

a library-defined operator whose return type is the same as that of the first operand [should] be usable as an augmented assignment. How easy is that to do?

That's not a bad idea. a =\dot b; or perhaps a \dot= b;

Methods are functions, so &mut v \Vec::push 1 would be allowed if the syntax is \<callable expression of two arguments>.

I want to argue against this or anything even vaguely like this, on legibility grounds.  People are going to write
x = a \dot b \wedge c \dot e \wedge f \hat a \dot g

and nobody, including the original author six months later, is going to have any idea what it means.
As a rule of thumb, a mixed chain of infix operations is illegible unless there is an operator precedence rule that everyone not only agrees on, but has had drummed into their head since elementary school (i.e. a + b * c).  We already have enough trouble with C's punctuation operators (do you remember what a | b & c means? are you sure?) -- I was actually a little disappointed to discover that Rust had adopted them verbatim instead of requiring parentheses.
Declaring that "all such operators have the same precedence and are universally (right|left) associative" does not help, because that rule hasn't been drummed into everyone's head since elementary school, so reading it that way is not automatic.

I want to argue against this or anything even vaguely like this, on legibility grounds.

I thought about this some more, and my concerns can be addressed with a little syntactic salt and a function annotation.
There are two legibility problems with user-defined operators.  One is that the precedence of user-defined infix operators, relative to any other operators (user-defined or not), is unclear: what does a \dot b + c mean? The other is that their associativity is unclear: what does a \dot b \dot c mean?
Now, mathematicians make up operators all the time — how is this not a problem for them?  They always parenthesize, unless both precedence and associativity are unambiguous.  They have a fairly broad idea of "unambiguous precedence"; I suspect a mathematician would say that of course dot product has higher precedence than scalar addition.  However, their idea of "unambiguous associativity" is quite narrow: if a mathematician writes a $ b $ c without parentheses, then there is a theorem or axiom that a $ (b $ c) ≣ (a $ b) $ c ∀ a,b,c, i.e. it doesn't matter whether a $ b or b $ c is evaluated first.
So I propose the following rules:

\foo has no precedence.  That means, it can appear as the sole operator in a complete arithmetic expression:
if a \isgreater b { ... }
x = y \dot z;
but it cannot be combined with any other operator unless parentheses are used to make the precedence clear:
x = (y \dot z) + c; // ok
x = y \dot (z + c); // ok
x = y \dot z + c;    // syntax error

\foo also can't be combined with itself normally, but you can annotate the definition of foo to declare that it's an associative operation in the mathematical sense, and then it's OK:
  // \cross = 3D vector cross product, not associative
  x = (y \cross z) \cross w; // ok
  x = y \cross (z \cross w); // ok
  x = y \cross z \cross w;    // syntax error

  // \mprod = matrix product, _is_ associative
  // #[associative] annotation on the definition of \mprod
  x = y \mprod z \mprod w; // ok

@zackw Thank you for a very well thought-out and reasoned reply!
I really like your solution and would very much like to write an RFC based on it with your (and anyone elses) input.

Bikeshedding:
a \dot b

vs.
a `dot` b

vs.
other syntax
?

Just my opinion: backticks should be reserved for some future hypothetical kind of string literal.

@zackw seams like a reasonable objective reason to prefer:
a \dot b

I like that your reasoning is not just based on subjective taste =)

I have yet to see one really convincing usecase.

People tend to prefer infix notation, rather than function call or method syntax, for dyadic operators.
Operators are pure functions as in, deterministic and side effect-free, but there is no clear definition of which pure functions are operators and which are not. I think the term 'operator' and its distinctive infix notation are used to highlight one or more functions that have some useful algebraic structure over their input domain.
So a dot product is written as an infix operator to remind the reader that the underlying datatype has the useful and rich algebraic structure of an inner product space.
Mathematical beauty is in the eye of the mathematician. Custom operators are neither strictly needed, nor useless bloat. IMHO they fill the same kind of niche as if let: if used properly, they can make stuff easier to read.

@ticki while I don't have any crate to offer as evidence, I think that any library or program that makes heavy use of mathematical operations on non-primitive sets and types such vectors (R^n) will benefit from this in terms of better readability.
So, crates using a lot of linear algebra will probably benefit.
I agree with @tobia that this is as much bloat as if let.

IMHO adding unfamiliar syntax that more or less everyone will have to look up to find out what it means the first time they see it has to meet a really high bar in terms of usefulness, and this does one not have that much advantage over just using method call syntax (which is also infix, and familiar to everyone).

Shouldn't it be possible to just write the functions without operator syntax? (a dot b, not a \dot b)
Since values are in most cases seperated by , or ; or similar, this wouldn't be a problem.
It may also be required to use a single pair of brackets at minimum.
But without precedence rules (which are too complicated anyway), I don't think, they are useful, since you still need the same number of brackets in most cases, and in other cases ((a op b op c op d)), it would be better nicer to be able to write this op(a, b, c, d).

@glaebhoerl I personally see a \dot b as quite intuitive and often very useful, esp. in a situation where I expect mathematical functions (such as in a numeric or linear algebra crate or a use-case for one). I would probably look it up the first time I see it - just to make sure my intuitive understanding is correct - but it would be easy to remember.

How much of an advantage does that have over a.dot(b), though?

@glaebhoerl Not much. Until you consider (a + b) == (a \add b) == a.add(b) (differing rules for parenthesis) which leads to
a \floor_div b \floor_div c \floor_div d == a.floor_div(b).floor_div(c).floor_div(d). This still isn't so bad but a single set of parenthesis suddenly puts a serious wrench in your spokes (metaphorically speaking) for method notation:
a \floor_div (b \floor_div c) \floor_div d == a.floor_div(b.floor_div(c)).floor_div(d). (floor_div is not commutative, so the parenthesis is essential.)
Yet another use-case for infix functions: println!("a ⓧ b == {}", a \cross b) seems slightly more intuitive than println!("a ⓧ b == {}", a.cross(b)), but gets much more intuitive for method notation once  you have
a ⓞ (b ⓧ c) * 2 /*etc*/ == a \dot (b \cross c) \mul 2 /*etc*/ == a.dot(b.cross(c)).mul(2)./*etc*/). (I  mixed operands despite @zackw 's great proposal stating it's illegal since in this case it improves the ease of figuring out WTF is going on in the method notation. Realize, however that using a single operand repeatedly
(a ⓞ b ⓞ c ⓞ d == a \dot b \dot c \dot d == a.dot(b).dot(c).dot(d)) or repeatedly with parenthesis
(a ⓞ (b ⓞ c) ⓞ d == a \dot (b \dot c) \dot d == a.dot(b.dot(c)).dot(d)) makes no difference here for infix notation, while it makes matters worse for method notation, the lot of dots of two different types also doesn't help when you're trying to pronounce the method notation exactly ;-).)
PS. I've realized one minor irritant with the proposed notation: println!("a \\add b == {}", a \add b). Notice the extra backslash on the left but not on the right. I don't think this is too bad however, since we're already used to duplicating backslashes in string literals.
PPS. If we can find a good solution to the problem of custom precedence and association that solves the problem of the ambiguity of a + b ⓧ c, infix functions will be far superior to method notation. I do think I have an idea to solve this, inspired by Scala's Spire community library and Rust's nice approach to inheritance vs composition, procedural macros, custom derive, iterators and Sized. But it's rather complex. Then again, it should add considerable power with very little (if any) downsides for the caller as well as generally little additional complexity (which you only pay for when you need it) with immense power - without the freedom to allow ambiguous or too easily unreadable user code - for the crate designer.
LOL. If I can also use HLists and implement Algebraic Effects, see especially http://goto.ucsd.edu/~nvazou/koka/padl16.pdf, my idea even adds support for something like:
// Normally everything below would be much less verbose due to `use Numeric::api::std::*`

// Notice the low learning curve way to specify exactly what types I work with. Although I'm not
// sure this is currently valid syntax.
fn my_op(left: Numeric.Ring, right: T) -> O
        where T: Numeric.with_op(Numeric.ops.Op::from_symbol("/")),
        // I want to only output a fixed-point real number that can be stored exactly with the fractional
        // part requiring no more than 1_000_000 bits. My code will be automagically specialized
        // to much cheaper types. See more about how this works after the function body.
        O: Numeric.Real.with_format(Numeric.Format::Real{ float = false /*this is the default*/, max_bits_frac = 1_000_000 })
{
    return (1+left) / right
}

// Trivially infers:
// Numeric.Primitives.ArbitraryReal<Numeric.Format.Inference::FromIO(Numeric.Format.ComplexityPriorities::Default)>
let pi = Numeric.math.pi();

// Infers `Numeric.Compatibility.U8` (a zero-cost wrapper for u8)
let a = Numeric.input::<Numeric.Primitives.Int, Numeric.Format::Int(max_decimals = 2)>();

// Infers Numeric.Primitives.Rational<Numeric.Format.Inference::FromIo(...::DefaultPriorities)>, notice `Numeric.Ring::from(1)` is not required.
let x = 1 \my_op pi;

// Infers z: Numeric.ops.const<Numeric.Primitives.Int, ...Inference::Literal>
let z = 0;

// If we didn't provide a type hint, we would've caused a panic here due to division by zero.
// First infers `y: Numeric.primitives.AlgebraicRational<Inference::Let>`
// (`AlgebraicRational: Algebraic + Rational` and Algebraic knows how to use L'Hospital.)
// Next infers y = 1/3: Numeric.primitives.Rational<...Inference::Literal>,
// by using L'Hospital and algebraic elimination.
// Finally infers:
// `y: Numeric.primitives.AlgebraicRational<Inference::FromIoAnd(1..=3, ...::DefaultPriorities)>`.
let y: Numeric.Primitives.Algebraic = (1 \my_op pi / z) / (2 \my_op pi / z);

// prints `1/pi` exactly correct to 20 digits with automagically optimized computational and memory costs. At this stage the compiler has enough information to specialize the type of `pi` to `...ArbitraryReal<Stability::ExactTo(min_int_decimals)>`
println!(x.format(Numeric.Format::Real{min_int_decimals = 2, round_to = 1e-20}, Exactness::Exact))

// Prints "1/3".
println!(y)

// Prints "1.234567890123456789 * 10**100). The compiler actually realizes it can do a lot
// of optimization, since `1 / 3 == 1 && 1 / (1 / n) == n` and some additional optimization since
// I'm only printing the result.
println!(y / 3 as Numeric / (1.0 as Numeric /<PHONE_NUMBER>123456789 as Numeric * 10 \Numeric::ops::pow 100))

// Panics. I need a typehint stating the result is of type
// `....Algebraic` to avoid the panic.
/* let x = y / 3 / z / z*/

// Panics. I need a typehint stating the result is of type
// `Numeric.Primitives.DivisableByZero`
// to avoid the panic.
/* let x = y / 3 / z */

Panics. The literal 0 loses information that L'Hospital needs:
/* let x = y / 3 / 0 / 0 */

I think I should go sleep now. ;-)

@Centril linked to this issue from the operators for Rust 2018 thread. Here is how I would like it to work:
impl Vector3 {
  fn dot (&self, v2: Vector3) -> Vector3 { ... }
}

let value = vec1 dot vec2;
let value = (vec1 dot vec2) dot vec3;
let value = vec1 dot (vec2 dot vec3);

Precedence, associativity: Solved by making parenthesis mandatory. Dropping parenthesis introduces a lot of questions and problems. It makes unfamiliar code hard to read because the code can only be understood when you know the precedence and associativity of each operator and at the end of the day the gain is only the saving of a few characters in each line of code. Keeping the parenthesis makes things straightforward and easy to understand. The infix notation is about making the code more similar to math, not shorter.
No special markers at the call site. IMO these should only be added if they are required either for clarity or to make the feature work. I don't think that's the case.
Fixity: New syntax only for infix operators. E.g. no new notation for sin a (prefix) because normal method calls work good enough for this already a.sin()

Idea that I'm not sure about: Require methods to be annotated with #[infix]

not having anything to signify that "dot" should suddenly be taken as an infix operator is very bad.
I'll fight for enclosing backticks all day, but i'll take a single opening backslash before I accept the idea of not having any signifier at all.

@Lokathor I don't think that a signifier is needed. It's simply three identifiers in a row. The middle one is a method on the first. The enclosing parenthesis make their relationship clear:
let value = (num1 checked_add num2).unwrap()

That said, I could live with a signifier if enough people think it's a good idea. There is no technical reason, but it can still be a matter of taste.
About backticks in particular: The backticks look similar to Rust's lifetimes syntax if there's just one or strings if there are two (JavaScript has strings like this).

Don't one-argument methods already allow infix notation? Why should we add a `op` b, when a.op(b) already exists? Making additional infix operators only causes unnecessary confusion about precedence and associativity without adding any significant value.

@H2CO3 Math formulas would be a lot more readable:
let value = a.dot(b).cross(c.dot(d)); // Old

let value = (a dot b) cross (c dot d); // New

I have to disagree with that. I don't find the "old" way any less readable.

@H2CO3 For me it considerably reduces the time I need to parse the formula in my head. However, the effect of this is probably, at least to an extent, different for different people. It depends a lot on what one's used to.

@MajorBreakfast It may be the case that JS uses backticks for some sort of goofy string, but Haskell uses them for making prefix functions into infix, so that's all the reason I need to want enclosing backticks for rust as well ;P In terms of them potentially looking like something else, it's never confused me if something in backticks might be a string or a character instead of an operator, with or without syntax highlight support. My eyes aren't even the best.

Just to demonstrate how subjective this is, I do find (a dot b) cross (c dot d) to be a lot more readable than a.dot(b).cross(c.dot(d)), but I am strongly against infix operators with no delimeter at all (in fact, how is that even an option? isn't that trivially ambiguous and therefore unimplementable?). Despite some exposure to Haskell, I find enclosing backticks and leading backslash to both be really bizarre choices for the delimeter. I have no strong opinion in favor of any particular delimeter. <dot>, #dot#, *dot*, etc all seem acceptable but ungreat to me.
A bit random, but if we do custom infix operators, I'd prefer to make parenthesis mandatory whenever multiple operators are involved, rather than having a system for specifying the relative precedence of all user-defined operators like in Haskell.

Maybe it would be a good Idea to implement a mini language with infix operators, that compiles to rust, and can be used in a macro.
(or use other languages with support for using functions as infix operators instead of rust)

isn't that [no delimiter] trivially ambiguous and therefore unimplementable?

@lxrec I think there is no problem from a technical standpoint. It's very similar to the notation for a 3-tuple. Minus the commas of course.
let value = a op b; // Top level: No parenthesis
let value = (a op b, 42); // Inside tuple
let value = (a op b) op c; // Nested
let value = func(a op b); // Inside function call

Just for fun the example of my post above with different markings:
let value = (a dot b) cross (c dot d); // No signifier
let value = (a (dot) b) (cross) (c (dot) d); // Parenthesis style
let value = (a `dot` b) `cross` (c `dot` d); // Haskell style
let value = (a \dot b) \cross (c \dot d); // LaTeX style

All of these seem a lot noisier to me. That said, proper syntax highlighting would go a long way in making it readable. The first one without markings is very short. The second one uses parenthesis similar to function calls. Both (1 & 2) are a bit harder to implement for syntax highlighting. The last one, the LaTeX style syntax, is easy to parse for syntax highlighting and has the benefit that it adds only one additional character. If we want markings, then I think I prefer the last one. Similarity to LaTeX is nice, because it's quite popular and it will be familiar to a lot of people.
(<dot> should be reserved for XML, # is for annotations and *dot* is multiplication)

I'd prefer to make parenthesis mandatory

@Ixrec I totally agree!

Maybe it would be a good Idea to implement a mini language with infix operators, that compiles to rust, and can be used in a macro.

@porky11 In the IRC chat log posted by @Centril above the macro i!(a dot b) was mentioned. However, to me, the feature looses a lot of its appeal if it is not generally available.

You can invoke proc macros with attributes, right?
#[linear_algebra_dsl]
fn foo<const n: usize>(x: Matrix<n,n,f64>) -> Matrix<2*n,2*n,f64> {
    ...
    (a dot b) cross (c dot d)
    ...
}

In the longer term, we should encourage functional language researchers to take more interest in Rust, specifically the formal safety properties, ala the memory model, borrowing, lifetimes, etc., the interactions with advanced type system features, ala const generics vs dependent types or ATCs vs HKTs, etc., and Rust's internals like MIR, HIR, and ABI research.  It'd rock if someone built an curried ML-style language that say uses Rust crates without any FFI, but make writing DSLs easier.
There are a few interesting "ideological" hiccups in doing this:  It's possible "big" DSLs could do more from 1ML style modules than traits, but if traits came out as a natural special case then maybe that's fine.  I've forgotten the details but Rust resists currying kinda forcefully, well see past discussions around HKTs, although again maybe that's fine if those restrictions become a special case.

@burdges I like this one very much, and I think that in terms of DSLs, we should probably stick with this direction. By definition, DSLs are domain-specific, so they should certainly not be hard-wired into a general-purpose language. A proc-macro is a very neat tool for creating an EDSL: it's basically the sweet spot between keeping the language minimal and as simple as possible, for the sake of readability from the point of view of a general audience, while still retaining the ability for anyone interested to easily create an EDSL without having to go through a tedious RFC process.
(PS.: I know that the usual argument against proc-macros is that "meh, proc-macros?!", but if one doesn't use a particular EDSL often enough to be worth the effort of writing a proc-macro for it, then probably one shouldn't be using an EDSL at all, and a set of plain old functions would suffice… Besides, with crates such as syn and quote, it's particularly easy to write proc-macros. Currently, they are derive-focused, but I don't see a reason why they couldn't be extended with DSL-friendly features in the near future.)

@burdges Compared to i!(a dot b) this seems a lot more useful and a real alternative.

It's possible "big" DSLs could do more from 1ML style modules than traits, but if traits came out as a natural special case then maybe that's fine.

I don't fully understand your meaning there
Will syntax highlighting work in an RLS environment if it's a proc macro?

@MajorBreakfast

Just for fun the example of my post above with different markings:
let value = (a dot b) cross (c dot d); // No signifier
let value = (a (dot) b) (cross) (c (dot) d); // Parenthesis style
let value = (a dot b) cross (c dot d); // Haskell style
let value = (a \dot b) \cross (c \dot d); // LaTeX style
All of these seem a noisier to me.

How about?:
let value = (a `dot b) `cross ( c `dot d);  // modified/lisp-ish Haskelly style

At little less noise. Should be easy, "like \LaTeX style" for syntax highlighters. I disagree that (for in-fix method call) and ' (for life-time) are easily mixed up. In every reasonable font I've ever used for coding, and ' are clearly/easily distinguishable. Also, with syntax highlighting, it's a non-issue anyway.
Another possibility would be a "block structured for infix notation" like this:
let value = `{ (a dot b) cross (c dot d) }

where `{ ... } is used to denote blocks where method calls will use in-fix notation. Which brings up the question, "Would you ever want to mix in-fix method calls and normal (arity-2) method calls in the same expression?" My take would be No!

At little less noise. Should be easy, "like \LaTeX style" for syntax highlighters. I disagree that (for in-fix method call) and ' (for life-time) are easily mixed up. In every reasonable font I've ever used for coding, and ' are clearly/easily distinguishable. Also, with syntax highlighting, it's a non-issue anyway.

That formatting is the biggest reason I'd rather not use ` for anything in Rust :rofl:

What is wrong with `, even if using ` multiple times?

Yeah, we probably shouldn't use

for the same reason

It could be great to a library with procedural macros for infix notation. If the feature turns out to be sufficiently popular and useful, then it can be added to the language at a later stage. Perhaps it could look like this
#[infix(dot, cross)]
fn foo(... ) -> ... { (a \cross b) \dot c }

I could personally see myself using infix notation, but I am also worried that it will confuse newcomers, and I am slightly worried about the rust syntax budget.

After writing a lot of markdown writing a ` has become rather normal to me. But that is not how it has always been. I remember the first time I learned that there is a difference. For beginners the distinction to ' is not clear. The dream is of course that one day Rust will be the first programming language many people learn. E.g. like C++ (Arduino) and JavaScript (Web) today. The ` character is rather difficult to write because if followed by a compatible letter, it is transformed. E.g. ` + a = à (I've a German keyboard layout, so correct me if that is not the case elsewhere)

@Lokathor I've now checked on how it is on a French° keyboard and on an US keyboard. And they all have different ways for writing accented letters! Interesting! xD
° The German keyboard has those accents only for foreign languages like French

@golddranks The position of the key (to the left of backspace) and how it operates seems to be exactly the same as on the German keyboard.

Apologies for the derail, but..
How would you do infix operators in a curried ML-style language, without using `?  We cannot use \ since that gives lambda expressions, well not without using |..| ... for lambda expressions.  If functions required a declaration prefix, like say fn, then you could use bare words but declare them with op, ala
op<const M: usize, const N: usize> (x: Vector<M>) cross (x: Vector<N>) -> Matrix<M,N> = ...

or
op<const M: usize, const N: usize> Vector<M> cross Vector<N> -> Matrix<M,N>
op x cross y = ...

with the second form being an outer match if multiple forms were provided.  You could still invoke cross function style with (cross) x y.  Except..
I think this bare word makes syntax highlighting not context free, and not necessarily even determined by the file, which complicates editor tooling.  Worse, it creates the same complexity for humans.
Worse still, these languages represent type parameters like value parameters, so more realistic syntax becomes:
fn cross (const M: usize) -> (const N: usize) -> (x: Vector M) -> (y: Vector N) -> Matrix M N = ..

with some early parameters being implicit or inferred when used, which matters when you represent traits with modules.
I'm not even sure if Haskell permits expressions as operators, ala x `semigroup_mult context` y, although presumably that's bad style, if permitted.

@burdges
I can't follow your code examples. Is this Haskell?
Quick recap: The syntax proposed here is intended for method calls. See Add trait as an example. It defines the add() method. With this proposal it's possible to write a add b instead of a.add(b). Rust is not like Swift where operators are functions instead of methods.

I think this bare word makes syntax highlighting not context free

I think syntax highlighting can still be done without type information even if there is no marking like \ or `. In my comment here I list several different examples where the infix operator appears. It's possible to detect an infix operator expression through the shape of it and colorize all items accordingly.

@burdges but... Rust isn't a curried ML language? I'm not sure how any of your statements would apply to Rust. I'm not even sure how most of them would apply to Haskell. In Haskell, you can only make a prefix function into an infix operator if it's a single binding anyway:
> addMul 4 5 6
54

> 5 `addMul 4` 6
<interactive>:6:11: error: parse error on input ‘4’

> let withFour = addMul 4
> 5 `withFour` 6
54

@lokathor fun thing - because haskell is a curried language, you could do
(5 `addMul` 4) 6

@ubsan You could 😆, but you usually don't :) I would consider that bad Haskell style.

@Centril tell that to the wonderful people behind lenses :3

@ubsan  I've never used the lens package that way and I've used it fairly extensively (including the infix operators). I usually first bind x  op  y to a variable and then I use binding z. Besides, my guess is that most of the lens operators are binary.
Tho, cc @ekmett on lens since they made it ;)

@Centril: In lens a lot of the operators are technically ternary, but are used in the fashion @ubsan mentions. With slightly lobotomized type signatures:
(.~) :: Lens s t a b -> b -> s -> t
(%~) :: Lens s t a b -> (a -> b) -> s -> t
(+~) :: Num a => Lens s t a a -> a -> s -> t

The common idiom is to use them like
foo
  & field1 .~ bar
  & field2 .~ baz
  & field3 %~ reverse

The operators are binary operators that return functions, and & is just x & f = f x.
You could also use them in a fashion like
whatever = (field3 %~ reverse) . (field2 .~ baz) . (field1 .~ bar)

to build a pipeline of mutations, but this is a less common form.
As far as Rust is concerned, I have no dog in this fight, but in Haskell it works quite well and I wouldn't consider it unidiomatic to pipeline functions together in a functional language. ;)

I wouldn't consider it unidiomatic to pipeline functions together in a functional language.

Nor do I, it's not about the ability to build function pipelines. My arguments were about the unnecessary nature of infix notation, since one can already to this with existing language features, namely method call syntax.
Also, Rust is still a different language, and it's not an automatic positive or an obvious gain to make it more like Haskell. Haskell's got many things right, but its syntax is certainly not a part I would praise. Most of the good stuff lies in the semantics of the language, and Rust has borrowed many parts of it already, notably type classes. For which I'm glad — but I'm also glad Rust's designers didn't copy over the weird syntax along with it.

@H2CO3

My arguments were about the unnecessary nature of infix notation, since one can already achieve piping with existing language features, namely method call syntax.

Pipe-lining with method call syntax fails in the face of free functions and borrowing.

Haskell's got many things right, but its syntax is certainly not a part I would praise.

But understand that this is purely subjective. I happen to love Haskell's syntax. There are no objective reasons for why Rust's syntax is better or why Haskell's is better. It is all about what you are used to. Haskell's syntax is as it is and not like OCaml's since it was purposefully designed in such a way to not waste the complexity budget on unfamiliar (to C++ programmers) lexical syntax.

One feature I love from OCaml (and Haskell too, if I'm not mistaken?) is that you have a set of characters to build names with, including function names, which is the usual letters-numbers-underscore plus the single quote, and another set of characters to build operator symbols with, which is a subset of the ASCII symbol characters.
So when you see foobar you know it's a function or variable name, but when you see +:* you know it's a custom infix operator. No ambiguity.
Maybe we could solve the issue like this and make math library authors happy as well? I still think custom operators should have a fixed precedence level and no associativity (= forced parentheses.)
Incidentally, I happen to love OCaml syntax, except for a few weird points. To me it's a good middle ground between Haskell and C-like languages. (Yes, I know OCaml came before Haskell, what I mean is that to me the latter is weirder, not easier.)

Yes, I know OCaml came before Haskell, what I mean is that to me the latter is weirder, not easier.

Haskell came before OCaml :)

First appeared | 1990; 28 years ago
https://en.wikipedia.org/wiki/Haskell_(programming_language)

First appeared | 1996; 22 years ago
https://en.wikipedia.org/wiki/OCaml

@Centril

But understand that this is purely subjective.

This seems to be a common misconception among programmers; unfortunately, it's false. There are objective reasons, especially when it comes to robustness and fault tolerance, for why one kind of syntax is superior to another. For example, whitespace sensitivity, and in particular, indentation-based blocks are dangerous since transmission through a channel that doesn't respect whitespace can significantly change the meaning of a program. So, no, syntactic choices are not "purely" subjective.
And even if they were: why do you feel your "I like Haskell's syntax" argument is stronger than my "I don't like Haskell's syntax" viewpoint?

Before things get more fiery, I think y'all are arguing the same point -- to quote H2CO3:

Also, Rust is still a different language, and it's not an automatic positive or an obvious gain to make it more like Haskell.

I don't think anyone is saying their preference matters more, just that there are views on both sides (and both views are partially, if not purely, subjective).

@H2CO3

This seems to be a common misconception among programmers; unfortunately, it's false.

Are there any scientific studies to this effect?

For example, whitespace sensitivity, and in particular, indentation-based blocks are dangerous since transmission through a channel that doesn't respect whitespace can significantly change the meaning of a program.

Personally, I think it is dangerous to rely on lexical syntax for fault tolerance and robustness; I would much rather as much as possible rely on a type system that makes fragile things not well typed.
From my time as a teaching assistant for a beginners course in OOP, I think it is equally easy to misplace braces and parenthesis.
My view is that we really use layout syntax even with braces (based on how we format with rustfmt), and that they mostly are redundant noise in the way of reading, but I understand that this is my subjective preference and not a universal constant.

And even if they were: why do you feel your "I like Haskell's syntax" argument is stronger than my "I don't like Haskell's syntax" viewpoint?

I did not make this claim :)
Rust is certainly not going to get Haskell's syntax.

Please keep off-topic comments about Haskell's syntax out of this Rust thread :)

Please keep off-topic comments about Haskell's syntax out of this Rust thread :)

I'm not a Haskeller, but, it is difficult for me to understand why you would consider the comments about another languages syntax, that clearly falls into the category of "Prior Art", to be off-topic on the discussion thread for a proposed feature/RFC for Rust. Sounds more like trying to silence someone who you disagree with rather than arguing the merits one way or another. Odd thing indeed. I'm highly offended by the smugness of telling someone they should shut-up because you disagree with what they have to say.

@gbutler69 Nobody is telling anyone to be quiet, because this is an RFC issue and the "C" stands for "comment". Also, please read @ubsan comment again and you'll see that there is no malice intended by the words she uses. Objectively there's also nothing wrong with wanting to stay on-topic.
I gave @ubsan comment a thumbs up because the debate about Haskell syntax is really hard to follow. It'd be helpful if the relevant parts were explained, so that a Haskell noob like me could follow. I'm just seeing a bunch of squiggly infix operators xD

It'd be helpful if the relevant parts were explained, so that a Haskell noob like me could follow.

In that case, asking the commenter to clarify is highly desirable and appropriate. Calling it off-topic and saying that the comments don't belong because they are off-topic is not. Again, "Prior-Art" is 100% on-topic in any proposal. I just can't see how it couldn't be.

I'm suspecting @ubsan was half-joking?; I don't mind their comment at all ❤
@MajorBreakfast

It'd be helpful if the relevant parts were explained

Sure thing! (and some bonus parts)
Let's start simple.
-- Equivalent (up to memory representation) to `enum List<a> { Nil, Cons(Box<List<a>>), }`.
--
-- List is a type constructor from  Type -> Type;
-- List Int is applying 'Int' to 'List' giving you back a type.
-- 'a' is a type variable (generic type parameter)
-- 'Nil :: List a' is a data constructor
-- 'Cons :: a -> List a -> List a' as well.
data List a = Nil | Cons a (List a)

length :: List a -> Int   -- A function from List of 'a's to 'Int'
length Nil = 0 -- pattern matching on Nil
length (Cons _ xs) = 1 + length xs -- Pattern matching on Cons.

-- explicit quantification of the type variable 'a'
length :: forall a. List a -> Int
length xs = case xs of  -- similar to 'match'
    Nil -> 0
    Cons _ xs -> 1 + length xs

-- A binary function from 'a' to 'a' to 'a'
-- proviso that 'a' satisfies the 'Num' typeclass (trait);
plusMul2 :: Num a => a -> a -> a
-- This is the same; Haskell functions are curried!
plusMul2 :: Num a => a -> (a -> a)
plusMul2 x y = (x + y) * 2

Rust equivalent of the last one (up to currying, laziness, memory model..):
fn plusMul2<A: Add + Mul>(x: A, y: A) -> A {
    (x + y) * 2
}

With respect to the example lens operators:
(+~) :: Num a => Lens s t a a -> a -> s -> t

-- explicitly quantified type variables and explicitly showing the currying:

(+~) :: forall a s t. Num a => Lens s t a a -> (a -> (s -> t))

This declares (the type of) the infix ternary custom operator +~ which takes a value of type Lens s t a a a value of type a and a value of type s and produces a value of type t. The lower case a, s, and t are type variables (parameters). Lens :: Type -> Type -> Type -> Type -> Type is a type constructor taking 4 types as arguments and returning a type. Again, a must satisfy the Num trait / type class.
whatever = (field3 %~ reverse) . (field2 .~ baz) . (field1 .~ bar)

This defines a top level function whatever; The . are function composition.
More details: https://hackage.haskell.org/package/lens
and: https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial

Here are a few arguments for placing this feature in a library rather than in the core language
The syntax looks slightly alien compared to the rest of rust and it is not very googleable, but if we force the programmer to decorate each funktion with #[linalg_dsl] or something similar, then the reader has a chance to google for the decorator and discover what is going on.
I will probably only be using the feature in a few math-heavy functions, so at least for me it doesn't require a lot of work to decorate each function separately.
If we end up with several competing macro libraries that experiment with syntax, then we have a change to pick the best one.

@nielsle

The syntax looks slightly alien compared to the rest of rust

Certainly no more alien than the operators the language already has?

it is not very googleable,

Haskell uses custom search engines (hoogle) to provide you with much better results than google could ever provide. I believe we could do the same.
Decorating functions with a proc macro such as this has the problem that proc macros are a very heavy weight DSL authoring mechanism; it costs a lot to make such a DSL. Meanwhile, custom operators, or functions with infix function notation such as in Haskell are extremely easy to make new ones of.

Would it be possible to define a macro for defining infix dsls? Something like this could be useful.

Let's experiment ;)

@nielsle In a DSL, the infix call style could just be enabled for all methods (with a self param and one other param)

I'm trying to find a language that I can write vector math and graphics stuff in more easily than in C++, while retaining good performance. With respect to the people that have commented here saying infix operators are useless or nearly so, the ability to define and use infix operators makes quite a significant difference in writing legible math-related code and avoiding mistakes.

@Centril
Why not decide associativity by vararg functions (at definition time) and when they don't exist, then assume by default left associativity.
Note, there are functions which are neither right nor left associative, e.g. the cartesian product:
A*B*C=*(A,B,C) != (A*B)*C /\ *(A,B,C) != A*(B*C)

I would still love to see something like this happen, but there hasn't been activity in this issue for several years, and RFC issues (as opposed to PRs) aren't really a good forum for this kind of thing. I'm going to close this, but I'd encourage people who are interested in it to collaborate on an MCP for it.

If you really want to, you can make infixes like these
x ^pow^ y;
a *dot* b;
a *cross* (b *cross* c *cross* d);

in stable Rust today by abusing operator overloads.
Example code:
use std::ops::Mul;

#[allow(non_camel_case_types)]
struct dot;

struct DotPartial<const N: usize>([f32; N]);

impl<const N: usize> Mul<dot> for [f32; N] {
    type Output = DotPartial<N>;
    fn mul(self, _rhs: dot) -> Self::Output {
        DotPartial(self)
    }
}

impl<const N: usize> Mul<[f32; N]> for DotPartial<N> {
    type Output = f32;
    fn mul(self, rhs: [f32; N]) -> Self::Output {
        self.0.iter().zip(rhs.iter()).map(|(a, b)| a * b).sum()
    }
}

Wow, this is super creative and in my opinion looks pretty good too! While at some point in the future it would be nice to have a prettier way to do this, I think most of the use cases that custom infix functions would be good for can make use of this today (such as the dot product, as you demonstrated!) Since it looks like pretty much every implementation of this would be really similar, I'm wondering if you could make a declarative macro would would write this out for you. I may try my hand at this later.

I have implemented the aforementioned macro and published it in a crate here on crates.io. Any infix operator with a static input type is now a one-liner to define!


CLI cleanup. Do not require client for creating seeds or migrations

Cleanup and improvements after https://github.com/tgriesser/knex/pull/2884/files
fixes https://github.com/tgriesser/knex/issues/1134

@aurium Could you please review?

@elhigu Thanks! It was an insanely bad day of a pretty bad month, really appreciate something positive :D


fix: update jwt vs session user monitoring

Description:
An issue was found when both ENABLE_JWT_VS_SESSION_USER_CHECK and ENABLE_SET_REQUEST_USER_FOR_JWT_COOKIE were enabled at the same time in an ecommerce stage environment for edx.org, that is not reproducible locally. Additionally, the issue killed the requests without providing errors, so potentially caused an infinite loop or some such issue.
The guess is that the code for setting the user behind ENABLE_SET_REQUEST_USER_FOR_JWT_COOKIE, and the code to get the user in the new ENABLE_JWT_VS_SESSION_USER_CHECK check, were somehow in conflict. This update attempts to skip the JWT vs Session check in the case that we have set the user based on the JWT, in which case it would be a JWT vs JWT check, which not only is unnecessary, but also may be the cause of the issue.
Adds custom attributes:

set_user_from_jwt_status
skip_jwt_vs_session_check

Issue:
https://github.com/edx/edx-arch-experiments/issues/429
Merge checklist:

[ ] All reviewers approved
[ ] CI build is green
[ ] Version bump if needed
[ ] Changelog record added
[ ] Documentation updated (not only docstrings)
[ ] Commits are squashed

Post merge:

[ ] Create a tag
[ ] Check new version is pushed to PyPi after tag-triggered build is
finished.
[ ] Delete working branch (if not needed anymore)

@feanil: This is ready for re-review. You can review the three newest commits one-by-one. I made some minor changes and added tests. Thanks.

@feanil: This is ready for re-re-review. I want to see how many approvals I can get for the same PR. :) Please see the latest 3 commits, and reviewing them separately may make things simpler for you.


[solver] find periodic steady state

[x] Use your time domain integration code of choice to show that for sufficiently large t, your problem
settles into a periodic steady-state solution.

[x] How many periods does it take to reach periodic steady state? Is it worth using a periodic steady
state solver? Produce concrete arguments estimating times.

[x] Use your Shooting-Newton code to find the initial state x0 that results in that period steady-state
behavior, i.e., x(0) = x(T) = x0. Implement the state transition function Φ(x0, T) = x(T) using the
same ODE integrator of your choice from t = 0 to t = T, with x0 as the initial condition.

[x] Plot one period of the waveform that corresponds to the initial condition you found. Note that since
your state x is a vector, you may need to plot the components of such vector at different times along
the period [0,T]. Choose which components and which times to plot carefully not to overcrowd your
plot. You should show a sample of waveforms representing well and clearly the evolution of your
state during a period. On the vertical axis always show x. Then you can either:

[x] put time on the horizontal axis and show a family of waveforms each corresponding to a different
state component;

One method (trapezoidal -> newton):

Shooting Method:

Need to extend this to make T another (optional) parameter!


Add --profile and component resources flags

This PR adds a few new install flags:

--profile.
--controller-memory
--controller-cpu
--api-server-memory
--api-server-cpu
--buildkitd-memory
--buildkitd-cpu
--buildkitd-service-cpu
--buildkitd-service-memory
--registry-memory
--registry-cpu

Specifying resources for runtime components
With this update we can now set component resources via their respective install flag. Each component follows this format:
acorn install --<component>-<resource> <req>:<limit>`

Alternatively, you can just pass the req like so.
acorn install --<component>-<resource> <req>

Profile-based defaults
Introducing the ability to set resource flags also encourages having logical defaults for production environments while keeping the default install free of install assumptions (like resource capacity). With this PR, there are two profiles: production and default.
You can specify a profile with the following command.
acorn install --profile production

Checklist

[X] The title of this PR would make a good line in Acorn's Release Note's Changelog
[X] The title of this PR ends with a link to the main issue being address in parentheses, like: This is a title (#1216). Here's an example
[X] All relevant issues are referenced in the PR description. NOTE: don't use GitHub keywords that auto-close issues
[X] Commits follow contributing guidance
[X] Automated tests added to cover the changes. If tests couldn't be added, an explanation is provided in the Verification and Testing section
[X] Changes to user-facing functionality, API, CLI, and upgrade impacts are clearly called out in PR description
[ ] PR has at least two approvals before merging (or a reasonable exception, like it's just a docs change)

@g-linville Also, a question. With how this works, can I specify a profile and then continue to override configuration options on top of it? Say I want to use the production profile but my ingress controller lives in nginx instead of traefik. Could I do acorn install --profile production --ingress-controller-namespace nginx?

Yes! That's the intent here. Basically the way that it is coded is that any default values will be replaced but any user specified ones will be respected. So if a user has not specified anything, all of the profile values will be used. But If you specify -ingress-controller-namespace nginx that will always be respected (even if you change profiles).

Also @tylerslaton I think it would be good to add something to the docs explaining how --profile works.

@g-linville Added some documentation. Let me know what you think!


Not unsubscribing may cause unexpected behaviour/leaks/crashes with long-lived Observables

I stumbled over this when trying to use rxlifecycle for binding event subscriptions. Reading the Unsubscribe section in the Readme explains why it happens, but what is the reason to choose this approach over simply tracking subscriptions?

I'm a bit confused by your question, since the point of RxLifecycle is to prevent leaks/crashes with long-lived Observables. If you're getting those, that may indicate a problem with RxLifecycle.
The reason we don't just track subscriptions is twofold:

There's already CompositeSubscription in the RxJava library which does a good enough job of it already, if you need it in some circumstance. (It's legitimate to run RxLifecycle alongside CompositeSubscription, depending on needs.)

Wrapping is less friendly than just calling compose().

An early version of RxLifecycle did just track subscriptions but it was harder to use.

To clarify I'm using PublishSubject and BehaviourSubject which are exposed by the application model as Observables for event dispatching. I suppose it was rather my fault, as I expected that .bindToLifecycle would kind of magically take care of unsubscribing..
How does a CompositeSubscription help in this scenario?
I resolved this for now by adding this (rather simplified) extension method, which binds the subscription to the lifecycle:
fun Subscription.bindToLifecycle(fragment: RxFragment): Subscription {
    fragment.lifecycle()
            .filter { it == FragmentEvent.DESTROY_VIEW }
            .subscribe {
                this.unsubscribe()
            }
    return this
}

At least for rxlifecycle-kotlin this would be just as easy to use, I suppose..

I think there's some fundamental misunderstanding here. bindToLifecycle() should take care of ending the sequence. While it's not technically the same as unsubscribing, it has the same overall result in terms of cleaning up memory leaks.
Have you taken a look at the sample? It shows how the Observables terminate using RxLifecycle.
CompositeSubscription helps in situations where you have multiple Subscriptions and want to cancel them all at once. If you've only got one Subscription then it doesn't matter, I was just guessing you had multiple because that's usually when people start looking into using RxLifecycle.

Is it supposed to work for the scenario I described? I could prepare a test case for it, but maybe it's something you don't even want to explicitly support. Binding the subscription is totally acceptable for me.

Yes, it should work when you subscribe to an Observable. That's what RxLifecycle is for.

Ok, I found the cause. You're using BehaviourSubject and in my code super.onViewCreated was called after the bindings, breaking the lifecycle. After correcting this it works as it's supposed to.. sorry for the false alarm and thanks for your feedback.


Monthly View (Set as default)

First of all, I want to thank you from the bottom of my heart for developing such an outstanding plugin!
My humble request is very simple. Every time I open the calendar, it defaults to the weekly-view format. I never liked the weekly-view on any calendar, be it google, calendly, etc.
I would like it so every time I open the calendar, it just defaults to the monthly view.
Of course, if someone else doesn't like that idea, they can keep the weekly-view as the default opening. That's why my humble request would be to add some sort of a toggle option where you can choose your default opening layout.
Either -monthly, -weekly, or maybe even daily. This way every time you open your calendar, you're immediately greeted with the format you like the most and you don't have to switch it manually every time.
Again, many many thanks for your hard work. I genuinely appreciate you!

Thanks for the kind words @valiantgenomics! This feature is already covered by issue #124 and there's already a pull request (#149) that adds this functionality. I'll try to get it merged in soon.
Cheers!

Ah, it seems like I've missed that, my apologies for repeating the issue. Thanks for taking the time to point it out!
You're truly awesome!


ADB track_devices to take a callback thats closure friendly

Currently the callback can only take fn pointers. I have an use case to pass the info onto a mpsc channel.
Let me know if there's another way to do it.
IIRC it should require a small change from
pub fn track_devices(&mut self, callback: fn(Device) -> Result<()>) -> Result<()> {
to
pub fn track_devices(&mut self, callback: impl Fn(Device) -> Result<()>) -> Result<()> {

My current use case below.. This gives compliation error: expected fn pointer, found closure
pub async fn adb_track_devices(c: &mut AdbTcpConnexion, tx: tokio::sync::MutexGuard<'_, Sender<String>>) -> Result<(), String> {

    let callback = |device:adb_client::Device| {
        let res = tx
            .send(format!("{}", device))
            .map_err(|e| e.to_string());

        return res;
    };

    let res = c.track_devices(callback);

    match res {
        Err(e) => {
            return Err(e.to_string());
        }
        Ok(_o) => {
            return Ok(());
        }
    }
}

Thanks for the report !
This is fixed in 0.6.0


Implementation of variable blade input properties in OpenFAST

Hello everyone,
@rafmudaf
@DavidSchlipf
I'm working on a project that based on changing of inertia moment of rotor blades of wind turbine by shifting a fluid mass between two accumulators in rotor blade (for more information about the project see the attachment)
Presentation_27_02_2019.pdf
Currently, FAST is not designed for simulating variable blade inertias. I.e. ElastoDyn reads only one blade input file for each blade at the beginning of the simulation, and these input files are not changing during the simulation. If the behaviour of a WT with variable blade inertia is to be simulated, FAST should be able to read different blade input file for each simulation step.
My questions:

Are changing blade properties already addressed in OpenFAST, e.g. lcing etc.?
Are these changes in general feasible?
Anyone have an advice how this should be implemented?
Any help would be really appreciated!

Best Regards
Laurence Alhrshy

Dear @LaurenceWETI,
Without changing the source code, it is not possible in OpenFAST to change the blade mass properties dynamically within a given simulation.  There was a discussion on our forum some time ago about how to implement time-dependent stiffness changes within a given simulation e.g. as a result of ply delamination: https://wind.nrel.gov/forum/wind/viewtopic.php?f=7&t=1441&p=6492 (and this discussion is equally valid to changing blade mass instead of stiffness).
Blade icing is typically modeled in OpenFAST by increasing the blade mass (and perhaps using different masses between the blades to model an imbalance) and modifying the airfoil lift/drag data (modified based on the roughness caused by ice accretion) as discussed briefly in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1064&p=8802.  But this is typically done with different masses and airfoil properties between separate simulations rather than dynamically within a given simulation.
I hope that helps.
Best regards,

@jjonkman @LaurenceWETI I'm closing this issue as the question seems to be answered. Please reopen if needed.

Thank you very much for the quick response. I’ll continue to work on this subject and I’ll keep you update.


Ahk2Exe v<IP_ADDRESS>a0 reported as malware by Windows Defender

https://www.virustotal.com/gui/file/05bba28c3820cd8ee65b22f6ebdac11708f2e79d17f2e8632b6fb229dde5e23a/detection

Algorithm : SHA256
Hash      : 05BBA28C3820CD8EE65B22F6EBDAC11708F2E79D17F2E8632B6FB229DDE5E23A
Path      : C:\Program Files\AutoHotkey\Compiler\Ahk2Exe.exe

This is a false positive from Microsoft. Ahk2Exe has not been changed since 17 May 2024 and you can check the hash against that published in the release notes. In addition, Ahk2Exe (and AutoHotkey) are completely open source and can be checked for problems if necessary.
In the meantime, I recommend that you add an exclusion to Windows Security (or your anti-virus program) for Ahk2Exe.
Cheers


fix: exporting and index files

Enables exporting of library objects and components.

:tada: This PR is included in version 1.5.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't install using Cocoapods

pod 'TaggerKit', '~> 0.4'
error
[!] Unable to find a specification for TaggerKit

Have you checked your podfile and/or your installation?

All good in my end, I am able to install other pods with no problems.

not sure how to explain it but the following made my day:
pod repo update
pod install


Should ThreadPool provide a function which waits until all thread finish?

Dear developer:
I want to add shutdown function that waits until all worker finish. Because I found ThreadPool will deconstructing directly if process exit. I think user have right to choose terminate ThreadPool or wait for finishing.
Are you agree with me? If you do I can submit a PR. Have a good day!

I have forked and modified this ThreadPool for use in log4cplus where I have implemented this functionality. See https://github.com/log4cplus/Threadpool.
I believe the aim of this repository is to provide a starting point thread pool rather than a complete implementation with many features.

I have forked and modified this ThreadPool for use in log4cplus where I have implemented this functionality. See https://github.com/log4cplus/Threadpool.
I believe the aim of this repository is to provide a starting point thread pool rather than a complete implementation with many features.

excellent job, man. I get the help in 2022 from you in 2018, maybe that is the charm of Internet.

@wilx
Could you please add some bit example or comment to understand the usage of
pool.wait_until_empty();
pool.wait_until_nothing_in_flight();

When you are destroying the object that owns the thread pool, you have to wait until the queue is empty and there are no threads running with the queued items. E.g.,
https://github.com/log4cplus/log4cplus/blob/4cd02bb7c513f9ae098ab34bccdaa57340e4531c/src/global-init.cxx#L388-L393


Reported runtime of tests is hugely different with TUnit

When my tests run with xunit v3, the reported runtimes are 35 and 29 seconds for net472 and .NET 8 respectively.

The actual elapsed time for these (when run with dotnet test) is 12.8 s and 11.7 s, respectively.
After migrating to TUnit, the reported runtimes are 5.1 minutes and 5.2 minutes for net472 and .NET 8 respectively.

The actual elapsed time for these (when run with dotnet test) is 12.2 seconds for .NET 8 (slightly slower than xunit v3).
I can't run tests with dotnet test -f net472 because it fails due to #1465.

I think this is an IDE issue. They're totalling the time up, not taking into consideration parallelism

I don't think parallelism explains the vast difference. These tests do not take 5 minutes to run when parallelism is turned off.

Hmm... I still think it's an ide issue. If you set the verbosity to trace, you should see test node update messages on the cli, and it should show start and end times for each test. I think this drives all that


Add py.typed marker file (as defined by PEP 561)

Addresses https://github.com/kazhala/InquirerPy/issues/45
Adds the py.typed file as per PEP 561. This ensures that projects that import InquirerPy can be type checked.

@kazhala Thanks for the quick merge!
Two followups:

Can you close https://github.com/kazhala/InquirerPy/issues/45 ? I don't seem to be able to do that myself.
Merging my PR into master seems to have broken the pyright step of the CI pipeline in a major way. I am not quite sure how my change could cause these errors, can you take a look?

@kazhala Thanks for the quick merge!
Two followups:

Can you close https://github.com/kazhala/InquirerPy/issues/45 ? I don't seem to be able to do that myself.
Merging my PR into master seems to have broken the pyright step of the CI pipeline in a major way. I am not quite sure how my change could cause these errors, can you take a look?

Hi @jonemo ,
Thanks again for doing this. I should have touched up in the issue ticket for this. No not your changes broke the pyright lints, think pyright updated some checks around Optional[XXX] which I need to update the codebase to align with that.
I've been quite busy for the last few months and should have fixed the pyright thing first. I'll merge your PR once I fix the linting and make a quick release.
Thanks


Possible to rebuild metadata from BigTable?

If we were to lose our elasticsearch cluster in the event of catastrophic loss, is there a way to rebuild the metadata indexes in Elasticsearch from the data residing in BigTable? How do you protect against this at Spotify? I can think of two ways:

Backup the actual elasticsearch cluster
Backup from the heroic shell using metadata-fetch and restore with metadata-load

What is the preferred method? I would sleep better at night knowing the indexes could be rebuilt from scratch. Is this possible?

First asked here, but it doesn't look like that part of the question was answered: spotify/heroic#125


Update quick_start_cn.ipynb

跳转的链接不存在，fix跳转到Overview页面

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[QUESTION]

Hi Daniel,
in meanwhile my exploring remote debugging :-D,
I have got an other question - or information.
I cannot use debug console without errors (never happend with RF language server and I am used to check my selectors like that), do you know why is that? You can check the atteched screen
Je zobrazen nadpis - is name of my KW and  Dopňlkové penzijní spoření is value of arguments

And it even does not work with using the native robotframework keywords :-(

It seems that you want to call a keyword in the debug console. This works a bit different in RobotCode.
You can call variables in the Debug Console and Python expressions with these variables, if you want to call a Robot keyword you have to put a !  in front of it. The ! is there to decide if it is a Python expression or a RobotFramework call.
e.g.

${a_variable} or $a_variable returns the contents of the variable

"test" in $var checks if the item test is in the variable var.

! Log Hello World executes the keyword Log with the given parameters

Thank you for your support.
It works with " ! ".
Any chance you will rid of the exclamation mark for debug console in the future or it is not possible?

Not at the moment, there is no way to clearly decide if it should be a python expression or a RobotFramework call.
But I could imagine to make it adjustable, so either python expressions with !  or RobotFramework calls with ! . what do you think?

Me and my team manager (which has been using your tool as well :-) agreed for python let with  " ! " (RF without "!" if it is possilbe then :-) )
We more create tests in RF :-)


.textlintrc should be encoded as UTF-8

Currently, textlint throw error when .textlintrc file is encoded as Shift-JIS.
We should check that the .textlintrc is UTF-8.
Proposal
If .textlintrc is not encoded by UTF-8, show error mesage in console.
Modules

utf-8-validate

It is native module
Previoulsly, it is introduced in #397, but it is reverted in #509

Edit: Re-open by #509

We can use utf-8-validate.
Buffer.from need Node. 5

utf-8-validate
utf-8-validate/test.js at master · websockets/utf-8-validate
Buffer | Node.js v8.2.1 Documentation

alt https://github.com/hcodes/isutf8

https://github.com/shinnn/is-file-utf8

I think utf-8-validate would be better.
I try it on Node.js v4.8.7, it works expected.
> node -e "console.log(require('utf-8-validate')(require('fs').readFileSync('utf8.txt')))"
true
> node -e "console.log(require('utf-8-validate')(require('fs').readFileSync('sjis.txt')))"
false

Currently, textlint throw error when .textlintrc file is encoded as Shift-JIS.

@azu How do I reproduce it ?
I try to reproduce on my blog( https://github.com/Leko/WEB-EGG ).

clone this repo
Run npm i
Convert .textlintrc to Shift-JIS
Run npm run lint:md

It does not throw an error.
But max-kanji-continuous-len.allow not working.
If .textlintrc encoded as UTF8, it works fine.
My .textlintrc is here: https://github.com/Leko/WEB-EGG/blob/master/.textlintrc#L17

This is based on bug report

https://twitter.com/azu_re/status/867662138831130624
https://twitter.com/azu_re/status/867662138831130624

textlint use rc-loader in days past.
But, I've replaced it to rc-config-loader  #39 https://github.com/textlint/textlint/pull/262
Maybe, "throwing error" is caused by rc-loader?

Hmm...
It doesn't throw error even in<EMAIL_ADDRESS>
We can close this issue ?

https://github.com/textlint-ja/textlint-rule-preset-JTF-style/blob/master/src/index.js
JTF preset use multibyte string in the key.
Is it a reason?

It does not throw an error.
But max-kanji-continuous-len.allow not working.

I think that assert this. Silent fail make user confuse.
Bacause, It is not expeceted bahavior for user.

I love loud error rather than silent error.

max-kanji-continuous-len.allow not working.

In this case, if assert .textlintrc encoded as UTF8, markdown should be UTF8.
textlint can support text files encoded as UTF8 only.
It's OK ?
BTW, rc-loader throws error in https://github.com/textlint-ja/textlint-rule-preset-JTF-style/blob/master/src/index.js .

I love loud error rather than silent error.

I think so too.

textlint can support text files encoded as UTF8 only.

Yes.
it looks good that implement the assertion in config-loader.
https://github.com/textlint/textlint/blob/41cae972db08731b797592b24dcd845c0138bec4/packages/textlint/src/config/config-loader.ts#L41

I got it.
I'll try to fix it :)

micnic/uv: Ultrafast UTF-8 data validation looks like good.
require Node.js 6+.
But, we can drop Node.js 4 support in near future #443

hcodes/isutf8: Quick check if a Node.js Buffer is UTF-8

Next Node.js will introduce utf8 checker
https://github.com/nodejs/node/pull/45947

buffer.isUtf8(input) require Node.js  v18.14.0.
textlint 14 treat Node.js 18.14 as the minimal version.

#1200

Hey @azu , is this issue closed or are we still looking for solutions?

https://github.com/textlint/textlint/issues/298#issuecomment-1917210670
is not implemented yet.


Update Developer Guide for new component: Security

Update Developer Guide for new component: Security
Update class diagram

Please wait for Travis CI to stabilise for merging.


kuiper docker image

Hi all,
Issue : Not able docker image ekuiper on target riscv(native build).
Reproduces:
*Git clone https://github.com/lf-edge/ekuiper.git
*Cd ekuiper
*make build_with_edgex
*make pkg_with_edgex
Binary file and package was successful.
but when i am trying for docker image using command
*make docker
Not Working i am getting error:
docker buildx build --no-cache --platform=linux/amd64 -t lfedge/ekuiper:1.4.0-23-g5515a6c -f deploy/docker/Dockerfile . --load
[+] Building 5.4s (3/3) FINISHED
=> [internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 32B                                                                                0.0s
=> [internal] load .dockerignore                                                                                0.2s
=> => transferring context: 2B                                                                                0.1s
=> [internal] load metadata for docker.io/library/golang:1.17.3                                                                         5.2s
error: failed to solve: failed to solve with frontend dockerfile.v0: failed to load LLB: runtime execution on platform linux/amd64 not supported
make: *** [Makefile:72: docker] Error 1
when i changed amd64 to riscv64 in Makefile
then i am facing issue:
docker buildx build --no-cache --platform=linux/riscv64 -t lfedge/ekuiper:1.4.0-23-g5515a6c -f deploy/docker/Dockerfile . --load
[+] Building 5.0s (5/11)
=> [internal] load .dockerignore                                                                                0.2s
=> => transferring context: 2B                                                                                0.1s
=> [internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 32B                                                                                0.0s
=> ERROR [internal] load metadata for docker.io/library/golang:1.17.3                                                                   3.7s
=> [internal] load build context                                                                                0.0s
=> ERROR [1/7] FROM docker.io/library/golang:1.17.3                                                                                1.0s
=> => resolve docker.io/library/golang:1.17.3                                                                                1.0s

[internal] load metadata for docker.io/library/golang:1.17.3:

[1/7] FROM docker.io/library/golang:1.17.3:

error: failed to solve: failed to solve with frontend dockerfile.v0: failed to build LLB: failed to load cache key: no match for platform in manifest sha256:199102125d11c943c927a8a33911ef960ca72c4879e307c7c2e40ceaa72201e3: not found
make: *** [Makefile:72: docker] Error 1
if anything i am missing please guide me.
Thanks,
lavkhush

@Rory-Z Please take a look

hello all,
i am facing issue
when i am using **$ make docker ** on target riscv64
root@lavkhush-3:~/ekuiper# make docker
docker buildx build --no-cache --platform=linux/riscv64 -t lfedge/ekuiper:1.4.0-23-g5515a6c -f deploy/docker/Dockerfile . --load
[+] Building 0.2s (5/11)
=> [internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 32B                                                                                0.0s
=> [internal] load .dockerignore                                                                                0.2s
=> => transferring context: 2B                                                                                0.1s
=> ERROR [internal] load metadata for docker.io/library/golang:1.17.3                                                                   0.0s
=> [internal] load build context                                                                                0.0s
=> ERROR [1/7] FROM docker.io/library/golang:1.17.3                                                                                0.0s
=> => resolve docker.io/library/golang:1.17.3                                                                                0.0s

[internal] load metadata for docker.io/library/golang:1.17.3:

[1/7] FROM docker.io/library/golang:1.17.3:

error: failed to solve: failed to solve with frontend dockerfile.v0: failed to build LLB: failed to load cache key: failed to do request: Head "https://registry-1.docker.io/v2/library/golang/manifests/1.17.3": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:46951->[::1]:53: read: connection refused
make: *** [Makefile:72: docker] Error 1
if anything missing, please guide me.
T&R
Kush Kumar

Hi, @kush930
Apologies for the delay, I've just finished my holiday
It looks like the golang image doesn't support riscv64, so you can't pull it, which causes the build to fail

Hi, @kush930 Apologies for the delay, I've just finished my holiday It looks like the golang image doesn't support riscv64, so you can't pull it, which causes the build to fail You can see this

Hi all,
Issue : Not able docker image ekuiper on target riscv(native build).
root@lavkhush-3:~ekuiper# make docker
docker buildx build --no-cache --platform=linux/riscv64 -t lfedge/ekuiper:1.4.0-14-g2f9bba1 -f deploy/docker/Dockerfile . --load
[+] Building 655.9s (8/13)
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 32B 0.0s
=> [internal] load .dockerignore 0.7s
=> => transferring context: 2B 0.6s
=> [internal] load metadata for docker.io/tonistiigi/xx:golang-riscv 0.0s
=> [internal] load build context 5.1s
=> => transferring context: 797.61kB 3.6s
=> CACHED [1/9] FROM docker.io/tonistiigi/xx:golang-riscv 0.0s
=> [2/9] COPY . /go/kuiper 648.3s
=> [3/9] WORKDIR /go/kuiper 0.3s
=> ERROR [4/9] RUN apt-get update && apt-get install -y pkg-config libczmq-dev 1.4s

[4/9] RUN apt-get update && apt-get install -y pkg-config libczmq-dev:
#8 1.226 {"msg":"exec the container process: Exec format error","level":"error","time":"2022-01-05T11:16:51.000418472Z"}

error: failed to solve: failed to solve with frontend dockerfile.v0: failed to build LLB: executor failed running [/bin/sh -c apt-get update && apt-get install -y pkg-config libczmq-dev]: runc did not terminate sucessfully
make: *** [Makefile:72: docker] Error 1
I have already installed pkg-config and czmq on my target riscv , binary also created, then also i am facing this issue, please guide me, if anything is missing.
T&R
Kush Kumar

It looks like you're using a golang image provided by a third party, I'm not sure what it does, maybe you should ask them

It looks like you're using a golang image provided by a third party, I'm not sure what it does, maybe you should ask them

Thank you Rory-z

Hi all,
Issue:- Not able to  build docker image ekuiper on target riscv(native build).
root@lavkhush-3:~/ekuiper# make docker
docker buildx build --no-cache --platform=linux/riscv64 -t lfedge/ekuiper:1.4.1-4-g45bbea6 -f deploy/docker/Dockerfile . --load
[+] Building 526.7s (8/11)
=> [internal] load build definition from Dockerfile                                                                       4.0s
=> => transferring dockerfile: 1.45kB                                                                                1.0s
=> [internal] load .dockerignore                                                                                5.6s
=> => transferring context: 2B                                                                                3.6s
=> [internal] load metadata for docker.io/tonistiigi/xx:golang                                                            9.8s
=> [internal] load build context                                                                                75.1s
=> => transferring context: 6.61MB                                                                                70.3s
=> CACHED [1/7] FROM docker.io/tonistiigi/xx:golang@sha256:03e312d98f8db5a7adbf403882347ee4cb620a97bd445b0cfdc8e6b47d3b3  0.1s
=> [2/7] COPY . /go/kuiper                                                                                363.8s
=> [3/7] WORKDIR /go/kuiper                                                                                11.3s
=> ERROR [4/7] RUN apt-get update     && yes | apt-get install pkgconfig libczmq-dev wget     && apt-get clean     && r  56.3s

[4/7] RUN apt-get update     && yes | apt-get install pkgconfig libczmq-dev wget     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*:

#8 44.35 executable file not found in $PATH: No such file or directory
error: failed to solve: failed to solve with frontend dockerfile.v0: failed to build LLB: executor failed running [/bin/sh -c apt-get update     && yes | apt-get install pkgconfig libczmq-dev wget     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*]: runc did not terminate sucessfully
make: *** [Makefile:72: docker] Error 1
please guide me guys , if anything is missing.
T&R
lavkhush


Constantly trying to connect on <IP_ADDRESS>

I've noticed my network was getting quite congested lately, so I decided to investigate. Wireshark had show that my PC was constantly trying to connect on this IP, <IP_ADDRESS>. I've searched google for that IP, and I've had many results pointing out it is related to AtmoOrb, and since Aurora last update, it has compatibility with AtmoOrb.
Disabling AtmoOrb in my program doesn't stop it, though, and it keeps congesting my network. A clean reinstallation also did not solve this issue.

Issue related to #342. It was already addressed on the dev build.


Enum Request Table 7604 "Where Used Base Calendar" field 1 "Source Type"

Hi Team,
Please implement field 1 "Source Type" in table 7604 "Where Used Base Calendar" as enum.
Best regards,
Arna Sif

Hello,
we also would like to need a ENUM-transformation of the Source Type of the whole calendar functionality. We needs to add a calendar to items and stockkeeping unit.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


When searching for Adoptium.net release notes, I get access to https://adoptium.net/temurin/release-notes/, and the page stays loading

Describe the bug
Hello, When searching for Adoptium.net release notes, I get access to https://adoptium.net/temurin/release-notes/, and the page stays loading.

To Reproduce
Steps to reproduce the behavior:

Go to adoptium.net relaases note at search engine
Click on https://adoptium.net/temurin/release-notes/
The page does not upload, it stays loading

Expected behavior

This page should display the lastest release page https://adoptium.net/temurin/releases/  where the release notes link is available

Add a message that you need to go to the latest release page and the release note will be available, by supplying the needed version.

Additional context
There is a community chat here https://adoptium.slack.com/archives/CLCFNV2JG/p1727355596754559 with some proposal to be tested.

Step is fixed. I'll try to add the message (point 2)

Step is fixed. I'll try to add the message (point 2)

Thank you it works

Hi @CarmenDelgadoEclipse ,
Can you give the text you would like to have to notice that it is the default version and that the user has to go to the download page to selected another version? Here is my sample (2d line)

thx

:heavy_check_mark:  FIXED

Thank you, @xavierfacq. I missed your comment!


User profiles, mod view and other enhancements

Themed new user profile designs: it was enough to fix three variables (--bg-mod-faint, --bg-surface-overlay, --bg-surface-raised). The result is the same as with the previous design: the popout is --background-floating and the internal cards are completely black.
Themed mod view: some elements have inline styling and others are using mixed colors with the primary/secondary theme colors of the user profile with the CSS variables. This is how Discord themes profiles, whether they are user profiles or the mod view.
Themed a "hidden" popout with the official community announcements profile.
Major variables rework: first of all I did a general cleanup, removing variables that are only used on the mobile app, and variables that have nothing to do with the goal of amoled-cord, such as variables that change the colors of "brand"/"positive"/"warning"/"danger". And the biggest change is mixed colors support: every single variable is now correctly mixed with the variables that Discord uses to make these mixes. This is used with mod view.
Fixed keybinds being all black in places where it shouldn't be.
Fixed the poll votes modal being all black instead of being the color of modals.
Fixed message gifts not having an hover.
Fixed the forum text area where the tip below was grey.
Replaced some parts of the code to use their variables: autocomplete popout with --autocomplete-bg, many elements of onboarding with --home-background, poll answers with --bg-mod-faint and lastly message hovers with --background-message-hover. The latter also fixes the fact that messages should not be hoverable if the app is not in focus.
Moved the sliders file from "app" to "inputs". The sliders are an input together with the buttons, I think it makes more sense that it's in that folder.

LGTM :+1: