  I'm interested in what people think.
Background:
Go has two short circuit binary operators, && and ||, that only evaluate their second operand under certain conditions.  There are periodic requests for additional short circuit expressions, often but not only the ?: ternary operator found originally in C; for example: #20774, #23248, #31659, #32860, #33171, #36303, #37165.
There are also uses for short circuit operation in cases like conditional logging, in which the operands to a logging function are only evaluated if the function will actually log something.  For example, calls like
    log.Verbose("graph depth %d", GraphDepth(g))

where log.Verbose only logs a message if some command line flag is specified, and GraphDepth is an expensive operation.
To be clear, all short circuit operations can be expressed using if  statements (or occasionally && or || operators).  But this expression is inevitably more verbose, and can on occasion overwhelm more important elements of the code.
    if log.VerboseLogging() {
        log.Verbose("graph depth %d", GraphDepth(g))
    }

In this proposal I consider a general mechanism for short circuiting.
Discussion:
Short circuiting means delaying the evaluation of an expression until and unless the value of that expression is needed.  If the value of the expression is never needed, then the expression is never evaluated.
(In this discussion it is important to clearly understand the distinction that Go draws between expressions (https://golang.org/ref/spec#Expressions) and statements (https://golang.org/ref/spec#Statements).  I'm not going to elaborate on that here but be aware that when I write "expression" I definitely do not mean "statement".)
In practice the only case where we are interested in delaying the evaluation of an expression is if the expression is a function call.  All expressions other than function calls complete in small bounded time and have no side effects (other than memory allocation and panicking).  While it may occasionally be nice to skip the evaluation of such an expression, it will rarely make a difference in program behavior and will rarely take a noticeable amount of time.  It's not worth changing the language to short circuit the evaluation of any expression other than a function call.
Similarly, in practice the only case where we are interested in delaying the evaluation of an expression is when passing that expression to a function.  In all other cases the expression is evaluated in the course of executing the statement or larger expression in which it appears (other than, of course, the && and || operators).  There is no point to delaying the evaluation of expression when it is going to be evaluated very shortly in any case.  (Here I am intentionally ignoring the possibility of adding additional short circuit operators, like ?:, to the language; the language does not have those operators today, and we could add them without affecting this proposal.)
So we are only interested in the ability to delay the evaluation of a function call that is being passed as an argument to some other function.
In order for the language to remain comprehensible to the reader, it is essential that any delay in evaluation be clearly marked at the call site.  One could in principle permit extending function declarations so that some or all arguments are evaluated lazily, but that would not be clear to the reader when calling the function.  It would mean that when reading a call like Lazy(F()) the reader would have to be aware of the declaration of Lazy to know whether the call F() would be evaluated.  That would be a recipe for confusion.
But at the same time the fact that Go is a compiled type safe language means that the function declaration has to be aware that it will receive an expression that will be evaluated lazily.  If a function takes an bool argument, we can't pass in a lazily evaluated function call.  That can't be expressed as a bool, and there would be no way for the function to request evaluation at the appropriate time.
So what we are talking about is something akin to C++ std::future with std::launch::deferred or Rust futures::future::lazy.
In Go this kind of thing can be done using a function literal.  The function that wants a lazy expression takes an argument of type func() T for some type T, and when it needs the value it calls the function literal.  At the call site people write func() T { return F() } to delay the evaluation of F until the point where it is needed.
So we can already do what we want.  But it's unsatisfactory because it's verbose.  At the call site it's painful to have to write a function literal each time.  It's especially painful if some calls require lazy evaluation and some do not, as the function literal must be written out either way.  In the function that takes the lazy expression, it's annoying to have to explicitly invoke the function, especially if all you want to do is pass the value on to something like fmt.Sprintf.
  This type has a single method Eval() that returns a value of type T.  It is not comparable, except to nil.  The only supported operation, other than operations like assignment or unary & that apply to all types, is to call the Eval method.  This has some similarities to the type
interface {
    Eval() T
}

but it is not the same as regards type conversion.
A value v of type T may be implicitly converted to the type lazy T.  This produces a value whose Eval() method returns v.  A value v of type T1 may be implicitly converted to the type lazy T2 if T1 may be implicitly converted to T2.  In this case the Eval() method returns T2(v).  Similarly, a value v of type lazy T1 may be implicitly converted to the type lazy T2 if T1 may be implicitly converted to T2.  In this case the Eval() method returns T2(v.Eval()).
We introduce a new kind of expression, lazy E.  This expression does not evaluate E.  Instead, it returns a value of type lazy T that, when the Eval method is first called, evaluates E and returns the value to which it evaluates.  If evaluation of E panics, then the panic occurs when the Eval method is first called.  Subsequent calls of the Eval method return the same value, without evaluating the expression again.
For convenience, if the various fmt functions see a value of type lazy T, they will call the Eval method and handle the value as though it has type T.
Some additions will be needed to the reflect package.  Those are not yet specified.
The builtin functions panic, print, and println, will not call the Eval method of a value of type lazy T.  If a value of type lazy T is passed to panic, any relevant recover will return a value of that type.
That is the entire proposal.
Examples:
This permits writing
package log
func Verbose(format string, a ...lazy interface{}) {
    if verboseFlag {
        log.Info(format, a...)
    }
}

Calls to the function will look like
    log.Verbose("graph depth %d", lazy GraphDepth(g))

The GraphDepth function will only be called if verboseFlag is true.
Note that it is also fine to write
    log.Verbose("step %d", step)

without having to write lazy step, using the implicit conversion to lazy T.
If we adopt some form of generics, this will permit writing (edited original proposal to use current syntax):
func Cond[T any](cond bool, v1 lazy T, v2 lazy T) T {
    if cond {
        return v1.Eval()
    }
    return v2.Eval()
}

This will be called as
    v := cond(useTls, lazy FetchCertificate(), nil)

In other words, this is a variant of the ?: operator, albeit one that requires explicit annotation for values that should be lazily evaluated.
Note:
This idea is related to the idea of a promise as found in languages like Scheme, Java, Python, C++, etc.  A promise would look like this (edited original proposal to use current syntax):
func Promise[T any](v lazy T) chan T {
    c := make(chan T, 1)
    go func() { c <- v.Eval() }()
    return c
}

A promise would be created like this:
    F(promise.Promise(lazy F())

and used like this:
func F(c chan T) {
    // do stuff
    v := <-c
    // do more stuff
}

In the implementation of Verbose, don't you need to call Eval on the elements of a before passing them to log.Info? Or are you assuming log.Info will do that? (Does log.Info bottom out at the fmt package at some point?)

Is it safe to Eval from multiple threads simultaneously?
If Eval panics on the first call do future calls panic with the same value?
Since the result of t := lazy v is essentially a function, instead of an Eval method could evaluation be written t()?
Would the Verbose example provided need the lazy declaration? The thunks have to be evaluated somewhere, presumably within fmt, but until then the lazy T would fit in an interface same as any other value.

related: https://github.com/golang/go/issues/36497
I believe what @jimmyfrasche means is like:
func foo(z bool) {
	c := make(chan struct{})
	a, b = 1, 2

	go func() {
		<-c
		a, b = 8, 9
	}()

	f := func(b bool, x lazy int) {
		close(c)
		if b {
			println(x.Eval())
		}
	}

	f(z, a + b)
}

It looks it should be the duty of programmers to avoid data races.
BTW, is it good to reuse the defer keyword as lazy?

@randall77
I'm assuming that log.Info bottoms out in the fmt package, yes.  That is true of the log package in the standard library (although there it is log.Print rather than log.Info).
@jimmyfrasche
Yes, it should be safe to call Eval concurrently from multiple goroutines.
I hadn't thought about calling Eval a second time if the first time panics; I'm not sure what the right approach is.  It could panic again, or it could return the zero value.
Yes, for many uses we could use t() rather than t.Eval().  The main advantage of t.Eval() is that the fmt package can apply it automatically.  But I suppose that if lazy types show up in reflection, then the fmt package can handle them automatically anyhow.  So maybe t() is better.  It does have the advantage of not adding a method to the language spec.
You are probably right that the Verbose example would work without using lazy in the function declaration.
@go101
Using defer rather than introducing a new keyword is a good idea.  Thanks.

There are a number of areas where 'lazy' techniques are beneficial and anything which makes such techniques easier for the Go programmer to use (as this proposal would) is therefore welcome.
As far as passing lazy arguments at the call site is concerned, you make two practical points both of which I agree with:

We're only normally interested in deferred evaluation of function calls as other expressions are usually cheap and quick to evaluate anyway.

Readability is improved enormously if there's some visual indication that such a call will be evaluated lazily.

Despite (2), lazy could be omitted because of the implicit conversion from T to lazy T and one could envisage 'lazy' programmers (pun intended) doing this, even from function calls, though tools could try to enforce best practice in this area.
Rather than rely on tools, I'd like to make a suggestion:

The use of lazy would be obligatory where expressions consisting of or involving function calls were passed as arguments to functions with lazy parameter types. Only the function calls themselves would need to be decorated with lazy, not the rest of the expression (if any). So, for example, you'd pass 1 + lazy f() rather than lazy (1 + f()). This would also seem more natural if defer were used in place of lazy to avoid creating a new keyword.

In all other cases, lazy would not be allowed at all at the call site which I think would reflect what people would prefer to do in practice anyway.

Once we have generics, I think it would probably be easy to have a generic Lazy function that does lazy evaluation. So, while this seems interesting,  I would rather have generics first and then see if we can solve the problem with them instead.

Shouldn't eval be a built-in function rather than a method? Go's built-in types don't have methods so far. It's "len(slice)", not "slice.Len()", so I'd expect "eval(v)".
@beoran Generics don't simplify lazy evaluation. You still have to write a function literal somewhere.

Why not let "lazy E" simply be of type "func() T"?
func Cond(type T)(cond bool, v1 func() T, v2 func() T) T {
    if cond {
        return v1()
    }
    return v2()
}

v := cond(useTls, lazy FetchCertificate(), nil)

Less characters on the use-site (+2 for for each "()" in the parameter list and -5 for each ".Eval" in the body), and it does not require a new type. "lazy E" would just be a shorthand for "func() T { return E }".

@fzipp, while I would personally welcome a shorthand syntax for function literals, and thing it would greatly improve the language itself, it itself will not help create easy-to-use lazy values.
A lazy value would, once invoked, compute the actual value once, store it somewhere in memory, and then provide it. And subsequent invocations will only result in fetching that same computed value.
Yours is but a function call. There is nothing in your syntax that would tell me or the compiler that whatever the function produces will be returned on subsequent calls without computing it again.

I hadn't thought about calling Eval a second time if the first time panics; I'm not sure what the right approach is. It could panic again, or it could return the zero value.

I would argue that one is interested in the result of evaluating the function which is either the return or the panic. I imagine it could be hard to debug if you sent a lazy value to a dozen places and it panic'd in one of them but not the others, especially if concurrency is involved. It would also mean that you'd get the panic if you eval'd in a debugger even if it had been eval'd before and the panic had been recovered and discarded making it hard to see what's gone wrong.
Also, it should be possible to convert a defer T to a func() T for interoperability with older code. This was possible with a method since you could do f((defer g(x, y)).Eval). If this were another implicit conversion you could use f(defer g(x, y)) even when f expects a func() T. I'm not a fan of implicit conversions in general but all the ones here seem appropriate since it's all sugar.
If I write the expression defer f(g()) presumably g is evaluated immediately and the thunk is f(value returned by g) so if you want both to be deferred, you need to write defer func() T { return f(g()) }(). If a func() T could also be implicitly converted to a defer T you could just write func() T { return f(g()) } but then you lose the guarantee that the same result is always returned and that f(g()) is evaluated at most once and is safe to evaluate in parallel, so that seems like a bad idea.

@urandom Right, Ian proposed cached lazy values. The question is if the caching is really needed, certainly not by the given examples. With generics (as @beoran suggested) a cached lazy value implementation could look like this:
func Lazy(type T)(f func() T) *LazyVal(T) {
	return &LazyVal{f: f}
}

type LazyVal(type T) struct {
	f      func() T
	cached bool
	value  T
}

func (z *LazyVal(T)) Eval() T {
	if z == nil {
		var zero T
		return zero
	}
	if !z.cached {
		z.value = z.f()
		z.cached = true
	}
	return z.value
}

A function with lazy parameters:
func Cond(type T)(cond bool, v1 *LazyVal(T), v2 *LazyVal(T)) T {
	if cond {
		return v1.Eval()
	}
	return v2.Eval()
}

Usage:
v := Cond(useTls, Lazy(func() *Certificate { return FetchCertificate(x) }), nil)

The issue is still mainly the verbosity of the function literal:

But it's unsatisfactory because it's verbose. At the call site it's painful to have to write a function literal each time.

With some kind of lambda expression syntax:
v := Cond(useTls, Lazy({FetchCertificate(x)}), nil)
v := Cond(useTls, Lazy(func FetchCertificate(x)), nil)

Thanks for better stating what I meant. It looks like with generics, this issue is reduced to the fact that there is no shorthand lambda syntax in Go. In the past requests for such syntax have been denied, but perhaps it is time to reconsider?

lambda syntax wouldn't help with the main example that requires fmt to know that some functions it sees should be evaluated but others should not be.

@jimmyfrasche The format verb syntax could be extended for functions, e.g.:
log.Verbose("graph depth %{d}", {GraphDepth(g)}) // Lazy

vs.
log.Verbose("graph depth %d", GraphDepth(g) // Non-lazy

Or with the the "lazy" package code I posted above:
package lazy

// ...

type Val(type T) interface {
	Eval() T
	String() string
}

// ...

func (v *val(T)) String() string {
	return fmt.Sprint(v.Eval())
}

// ...
	log.Verbose("graph depth %s", lazy.Of({GraphDepth(g)})

How about a general apply/curry syntax which allows partial application of arguments so :
func f( a int, b int ) int  {
    return a + b
}
g := apply f( 1 )
// type of g func( b T2 ) int
r := g( 2 ) // 3
// and
k := apply g( 3 )
s := k() // 4

On the fmt handling - any reason not to have lazy / apply implement an interface on the function in the same way that HanderFunc is implemented? For type safety this probably either needs code gen or generics. That way fmt could do the right thing.
Final thought - given that taking a pointer or a function is not allowed, we could steal the & to be the apply operator, this starts to look a little like magic but doesn't mean introducing a new keyword.
g := &f(1)
g(2) // 3

@mdcfrancis Can you show how currying solves any of the examples in the proposal? I don't see the connection here.

@fzipp - curry/apply with no unbound args provides the same output as the proposed lazy operator but is more general in form. So lazy f( x ) is identical to apply f(x) for a single argument function.

@mdcfrancis I see, thanks.

The type based hint for fmt would look something like the below where curry/lazy returns a type alias - note you'd need code gen to support (or generics) but fmt could ask isApplied( func() T ) / isLazy( func() T ) for vars of type func() T.
package main

import "fmt"
type Applied interface {
	Applied()
}

func f() string {
	return "hello"
}

type AppliedFunc func() string
func ( f AppliedFunc )Applied() {}

func isApplied( a interface{} ) bool {
	_, ok := a.( Applied )
	return ok
}

func main() {
	a := AppliedFunc( f )
	fmt.Print( isApplied( a ) )
	fmt.Print( a() )
}

How about a general apply/curry syntax which allows partial application of arguments

Although this generalisation is nice from a functional programming perspective, I'm not sure how useful partial application (with some unbound args) is in practice. An easy to grasp operator name like "lazy" that communicates the purpose could be worth more than generality.

The type based hint for fmt would look something like the below where curry/lazy returns a type alias - note you'd need code gen to support (or generics) but fmt could ask isApplied( func() T ) / isLazy( func() T ) for vars of type func() T.

You can do almost all of this today in the existing type system except for where you would want generics.
package main
import "fmt"
type Applied interface {
	Applied()
}
func f(arg string) string {
	return arg
}
func Apply( f func() string ) AppliedFunc {
	return AppliedFunc( f )
}
func Apply1( f func( string ) string, arg string ) AppliedFunc {
	return AppliedFunc( func() string { return f( arg )})
}

type AppliedFunc func() string
func ( f AppliedFunc )Applied() {}

func cond( expr bool, f AppliedFunc, g AppliedFunc ) string {
	if expr {
		if f == nil {
			return ""
		}
		return f()
	}
	if g == nil {
		return ""
	}
	return g()
}

func main() {
	s := func() string { return "hello" }

	fmt.Print( cond( true, s, nil ) )
	fmt.Print( cond( false, s, nil ) )

	g := Apply1( f, "world")

	fmt.Print( cond( true, g, nil ) )
	fmt.Print( cond( false, g, nil ) )
}

Is there ever a need to explicitly use lazy when calling a function?

Idris has declarative laziness without the explicit need to call Delay (aka lazy on calling) or Force (aka Eval). The rules on panic, print & printf might complicate things, but is this type checker enforced laziness a desirable goal?
http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#laziness

In kotlin, a value must be marked as lazy to be lazily initialized:
https://kotlinlang.org/docs/reference/delegated-properties.html
however, further arguments and usages are not marked in any way. the compiler knows that this is an object wrapped in a Lazy class and will expand to a method call of it when used.
to me, that seems like a decent solution. functions like printf/cond don't really need to know that some of its arguments are lazy.

@urandom I agree that that feature is desirable, I just have no idea how to implement it.  Kotlin can do it because every value is an object.  That is not true in Go.  In Go a func(bool) takes a value of type bool.  I don't see any way to pass a lazy value to a function that expects a bool.

Question:
what would the following do?
func f(x lazy interface{]) {}

func main() {
  for {
      f( lazy <- time.After(time.Second))
     ...
     break
   }
}

I was having some issues thinking through this so created an example.
Is this the intent?
https://play.golang.org/p/gerLIiL_Dc0
package main

/*
Playing with laziness.

Currently
time go run main.go
1
1
3
real    0m3.219s
user    0m0.342s
sys     0m0.087s

With laziness
time go run main.go
1
1
1
real    0m0.429s
user    0m0.342s
sys     0m0.087s

*/

import (
	"fmt"
	"time"
)

var doDebug = true

func debug(x /*lazy*/ interface{}) {
	if doDebug {
		fmt.Printf("%v\n", x)
	}
}

func main() {
	debug(1)
	debug( /*lazy*/ expensiveMutating())
	doDebug = false
	debug(expensiveMutating())
	doDebug = true
	debug(expensiveMutating())
}

var counter int

func expensiveMutating() int {
	counter++
	<-time.After(time.Second)
	return counter
}

@urandom I agree that that feature is desirable, I just have no idea how to implement it. Kotlin can do it because every value is an object. That is not true in Go. In Go a func(bool) takes a value of type bool. I don't see any way to pass a lazy value to a function that expects a bool.

yeah, i just wanted to illustrate another implementation, in case when can learn something from it.
i guess decorating the func argument with a lazy would pretty much box the passed value, but then perhaps we might not need to call an Eval method on it.

@ianlancetaylor I think my confusion is whether there are any implicit lazy wrapping of functions. Ie does the use of laziness effect the "scope"?
imo it shouldn't be.
All implicit wrapping (eg as in Idris) would probably create unacceptable backwards compatibility issues.
	debug( lazy expensiveMutating())
	debug(expensiveMutating()) // <-- is this call lazy?

Similar to
f( lazy func() timeTime { return <- time.After(time.Second) }() )

or
x := func() time.Time { return <- time.After(time.Second) }
f( lazy x() )

There is no implicit laziness.

	debug( lazy expensiveMutating())
	debug(expensiveMutating()) // <-- is this call lazy?

No, that call is not lazy.
For this code:
package main

var doDebug = true

func debug(x interface{}) {
	if doDebug {
		fmt.Printf("%v\n", x)
	}
}

func main() {
	debug(1)                        // prints 1
	debug(lazy expensiveMutating()) // counter = 1, sleeps, prints 1
	doDebug = false
	debug(expensiveMutating())      // counter = 2,sleeps, doesn't print anything
	doDebug = true
	debug(expensiveMutating())      // counter = 3, sleeps, prints 3
}

var counter int

func expensiveMutating() int {
	counter++
	<-time.After(time.Second)
	return counter
}

So I think I did misread the code earlier, and it does print 1 1 3.

if fmt.Printf args was defined as lazy and using fmt.Printf("no print verbs in format string", lazy expensiveMutating()), [sic bad format string] would the function get Eval'ed?

Well, it depends on the exact implementation of fmt.Printf, but the current implementation does evaluate extra arguments, so, yes, it would be eval'ed.

does this make sense f( lazy <- time.After(time.Second))?

I don't know why you would do that, but, sure.  When the value is evaluated, it will sleep for a second and return the time when the sleep wakes up.
I think the expressions with a function would do the same.

I would be particularly interested in seeing how a proposal addresses how lazy is supposed to interact with functions that call runtime.Callers and similar.  I realize this is a minor detail, but sometimes enterprise software includes the trappings of such calls for tracing, instrumentation, logging, etc., which often rely on metadata provided by the program counters.

A lazy expression that calls runtime.Callers would show the call stack at the point where the expression was first evaluated.  It would not show the call stack where the lazy expression was created.  I don't see how it could work any other way.

@ianlancetaylor why not a unary ? operator that makes any expression lazy?
log.Printf(“error: %v", ExpensiveFunc()?)

I think that would be unnecessarily cryptic and easy to miss.  Also, it's nice that we use the syntax for both the expression and the function parameter, but writing func F(a? int) would be even more cryptic.

I think that would be unnecessarily cryptic and easy to miss. Also, it's nice that we use the syntax for both the expression and the function parameter, but writing func F(a? int) would be even more cryptic.

Perhaps func F(a int?) (effectively a lazy int)?
What if the caller didn’t need to express the ? at all, similar to how Go’s method syntax doesn’t vary for pointer receivers like C—it’s always .?

I don't see how func F(a int?) is much better.  It's still hard to understand and easy to miss.
It seems to me that making ? the default would be very inefficient in the normal case.  It would mean always passing a function rather than a simple value.
What is wrong with lazy?

You’re right. lazy is better.

If the compiler can prove that lazy and immediate evaluation have no different observable side effect, is it allowed to inline and immediately evaluate it?

I don't like that we'd be adding a keyword and expanding the language just to avoid passing a function literal around.... and even then its main use case is to avoid verbosity and extra work when logging.
That just seems like an incredibly minor benefit for the cost of a language addition.  In my book, it doesn't pass the test for a worthwhile change.

How about
log.VerboseFn("graph depth %s", func() {return GraphDepth(g)})

@natefinch, the func boilerplate erodes readability
doEither(which, func()int { return cheap }, func()int { return expensive() })

doEither(which, lazy cheap, lazy expensive())

But then again, so does error handling boilerplate :-)

Any reason not to have a short form function syntax ?
do(true, ()->cheap, ()->expensive())
If you want more than a single expression in your function you have to write return. Being able to write something like the following
The following would be equivalent
f := func(x string)string->{ return fmt.sprintf( “hello ”, x ) }
f := (x string)->{ return fmt.sprintf( “hello ”, x ) }
f := (x string)->fmt.sprintf( “hello ”, x )

I don't think we need cheap vs. expensive.  Lazy is expensive vs. nothing.
One of my maxims about requests for language additions is that so many of them are adding complexity just to avoid an if statement. This is one of them.
if logging.IsVerbose {
    log.Verbose(expensiveThing())
}

Is that a little verbose? Yes. But most of the time you don't even need to do that. You only need the extra if statement when you're in a hot path AND you're doing something really expensive. Otherwise, you can just log.Verbose(val, val2, val3) which is like 95% of logging. The actual cycles to pass some stuff by value and then not use it is tiny compared to that database lookup you're gonna do at the end of this call.
And when you do need that, it's incredibly boring and simple code and no one will ever misunderstand what it's doing.
I just don't see a giant benefit to this language addition. It's going to get abused and make our code more complicated for very little practical benefit.

@nightlyone

If the compiler can prove that lazy and immediate evaluation have no different observable side effect, is it allowed to inline and immediately evaluate it?

Sure.

Note that passing an explicit function, whether with the existing syntax or a newer one, would not permit the special handling in which the fmt functions evaluate a lazy value.  The fmt functions could not change their behavior when seeing a function literal, as that would break existing code.  But of course that part of the proposal could be dropped.

A simpler syntax for function literals is discussed in #21498.

All expressions other than function calls complete in small bounded time and have no side effects (other than memory allocation and panicking). While it may occasionally be nice to skip the evaluation of such an expression, it will rarely make a difference in program behavior and will rarely take a noticeable amount of time. It's not worth changing the language to short circuit the evaluation of any expression other than a function call.

I'd like to challenge this. I apologize if you'll consider this unrelated, but I'm here to argue that it's actually the allocations that are often the bigger problem (not the allocations caused by the expression evaluation itself, but related ones).
Logging seems to be the big driver of this proposal. CockroachDB has fairly advanced logging practices and libraries. Our major problem with logging is that a log.Infof(args ...interface{}) function causes all its arguments to escape to the heap. I believe this is a well understood problem: log.Infof() bottoms out at a fmt.Sprintf() call, which calls String() through the Stringer interface. Since that String() method could in theory hold on to the receiver (although in practice it never does), the receiver escapes to the heap. https://github.com/golang/go/issues/8618
We jump through great hoops to avoid such allocations. Sometimes we do things like the following to at least only cause allocations when verbose logging is needed:
if ExpensiveLoggingEnabled(ctx) {
  cpy := request.Clone()
  log.Infof("my request: %s", cpy)
}

Other times, we call String() ourselves to force early stringifying in order to have the string escape to the heap, not the original variable.
log.Infof("my request: %s", myFatObject.String())

This goes directly against the purpose of the current proposal, and yet we find ourselves forced to do it.
If you want to improve logging support in Go, please keep the escape analysis angle in mind.

If performance and memory use of logging is the problem, then Zerolog is
the solution. I am currently using that professionally and it's great. No
need for a new language construct.
https://github.com/rs/zerolog
Op wo 25 mrt. 2020 22:28 schreef Andrei Matei<EMAIL_ADDRESS>
All expressions other than function calls complete in small bounded time
and have no side effects (other than memory allocation and panicking).
While it may occasionally be nice to skip the evaluation of such an
expression, it will rarely make a difference in program behavior and will
rarely take a noticeable amount of time. It's not worth changing the
language to short circuit the evaluation of any expression other than a
function call.
I'd like to challenge this. I apologize if you'll consider this unrelated,
but I'm here to argue that it's actually the allocations that are often the
bigger problem (not the allocations caused by the expression evaluation
itself, but related ones).
Logging seems to be the big driver of this proposal. CockroachDB has
fairly advanced logging practices and libraries. Our major problem with
logging is that a log.Infof(args ...interface{}) function causes all its
arguments to escape to the heap. I believe this is a well understood
problem: log.Infof() bottoms out at a fmt.Sprintf() call, which calls
String() through the Stringer interface. Since that String() method could
in theory hold on to the receiver (although in practice it never does), the
receiver escapes to the heap. #8618
https://github.com/golang/go/issues/8618
We jump through great hoops to avoid such allocations. Sometimes we do
things like the following to at least only cause allocations when verbose
logging is needed:
if ExpensiveLoggingEnabled(ctx) {
cpy := request.Clone()
log.Infof("my request: %s", cpy)
}
Other times, we call String() ourselves to force early stringifying in
order to have the string escape to the heap, not the original variable.
log.Infof("my request: %s", myFatObject.String())
This goes directly against the purpose of the current proposal, and yet
we find ourselves forced to do it.
If you want to improve logging support in Go, please keep the escape
analysis angle in mind.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/37739#issuecomment-604097340, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAARM6K3HZXVFA5HLWH4GQLRJJZQXANCNFSM4LDTHJXQ
.

@andreimatei Thanks for the examples.  Honestly, logging is not really the driving issue here.  It's just a convenient example.  This proposal clearly does not help with the escaping to the heap that you mention.
The driving example here is trying to generalize the C trinary ?: operator in a way that will work for Go.

@natefinch

I don't like that we'd be adding a keyword and expanding the language just to avoid passing a function literal around

It's more than that because if you call a function literal twice, the function will be called twice, but with the lazy proposal, calling Eval twice will only evaluate the expression once. That's a significant and important difference.
Using function literals wouldn't allow the convenient assignment compatibility rules that this allows. For example, in this proposal a value of type lazy []string would be assignable to any value with underlying type []string. With function literals, you'd have to make a wrapper function to do that.
In general, I like the thrust of this proposal. It does need to be fleshed out some more though. For example, if lazy T is one of the fundamental types, then it would need to be supported by the reflect package.
I second the reservations about the use of the Eval method name - this would be the first time that the base language has used a name like this - but I can't think of a nice operator for it, and there are other advantages to using a method rather than an operator (see reply to @jimmyfrasche below).
One thought: I think you might want to restrict the use of lazy in some cases. For example, would this be disallowed? If not, what would it do?
func f() (r lazy interface{}) {
	defer func() {
		r = lazy recover()
	}()
	panic("hello")
}

func main() {
	r := f()
	fmt.Println(r)
	fmt.Println(r)
}

@jimmyfrasche

it should be possible to convert a defer T to a func() T for interoperability with older code

I presume you mean lazy T there. AIUI that would be easy: just use a method expression.
func old(f func() string) {
	fmt.Println(f())
}

func main() {
	v := lazy "hello"
	old(v.Eval)
}

The lazy recover() example is nice.  I think you're right that we would have to forbid that.  I think that's OK; we already forbid other built-in functions in various contexts (e.g., https://golang.org/ref/spec#Expression_statements)

If lazy T is shorthand for func() T, then what about calling it directly instead of an Eval method?
func log(v lazy string) {
	fmt.Println(v())
}

func fetch() string {
	// Expensive
	return "hello"
}

func main() {
	v := lazy fetch()
	log(v)
}

Second, could a lazy value be evaluated implicitly when assigned to a non-lazy var? e.g.
func f(v lazy string) {
	var w string
	w = v // Implicitly calls v()
}

Third, could a function that matches func() T be passed through unchanged as an acceptable lazy value? e.g these two would be equivalent:
f1 := fetch
f2 := lazy fetch()

@natefinch if a var v lazy T is forced with v() instead of v.Eval() then there is no method to use in a method expression and hence the question of convertibility to a func() T arises.

@rogpeppe caching a copy of a response is not that hard, either.
type lazyString struct {
   expensive func() string
   exists bool
   val string
}
func (l *lazyString) Eval() string{
   if !l.exists {
       l.val = l.expensive()
       l.exists = true
   }
   return l.val
}

Add a mutex if you need it to be threadsafe.
Yes, that's a lot of code, but... it's also a fairly complex concept, and I still maintain that this is not needed very often. I've written a lot of Go, and haven't ever needed this.
@jimmyfrasche  I think you're responding to @ydnar

@natefinch sorry, I meant to respond to @rogpeppe and not paying enough attention.

Yes, that's a lot of code, but... it's also a fairly complex concept

That could also be said of channels.

I've written a lot of Go, and haven't ever needed this.

I've done so quite a lot - every time I've used sync.Once to initialize an associated value.

This is really interesting to me. I have been overall very happy to be free of the C preprocessor, but I have some macros in C code that look like:
        if (pseudo_util_evlog_flags & (x)) { pseudo_evlog_internal(__VA_ARGS__); } \
} while (0)

which provide this behavior, and you simply can't do this in Go, and it's occasionally a source of pain when there's logging which is (1) expensive to compute the values for, (2) only sometimes useful. (You can compile-time it with tiny mid-stack-inlinable functions which have an if constExpr in them and are defined in files controlled by build tags, but that's not as nice.)
I don't consider the "this is a lot of work to avoid a single if" argument persuasive. Consider the next example in the same header:
#ifndef NDEBUG
#define pseudo_debug(x, ...) do { \
        if ((x) & PDBGF_VERBOSE) { \
                if ((pseudo_util_debug_flags & PDBGF_VERBOSE) && (pseudo_util_debug_flags & ((x) & ~PDBGF_VERBOSE))) { pseudo_diag(__VA_ARGS__); } \
        } else { \
                if ((pseudo_util_debug_flags & (x)) || ((x) == 0)) { pseudo_diag(__VA_ARGS__); } \
        } \
} while (0)
[...]

All of this complexity could certainly be hidden inside a small helper function, which would be inlinable, but that would mean that the expensive computation has to happen every time. If you actually have to put this at every call site, you're starting to see a pretty significant cost.
And what happens if the condition you wanted to use changes?
Being able to put the condition inside the function, and lazy-eval the arguments, is really useful, and while this specific example is logging, I have definitely had other cases where being able to defer the actual computation would have been desireable.
I do like the suggestion of calling it defer rather than lazy to save valuable keywords, and because this is conceptually a very similar thing -- putting a hunk of code execution somewhere that it'll be done later. On the other hand, the function argument should be deferred then, or it feels grammatically wrong.
 If you ignore the caching, you could then turn the proposal into:
When used as an expression rather than a statement,  defer expr is equivalent to
func ()T { return expr }
where T is the type of expr.
I keep wanting to suggest an auto-eval, but the more I think about it, the more i think that feels like a bad fit for Go's usual idiom of making expensive things at all visible. Making the call explicit makes is easier to see that an actual operation is happening.

As @mdcfrancis mentions above in https://github.com/golang/go/issues/37739#issuecomment-603863894, if we had a simpler function literal syntax, as discussed in #21498, then we could write
func Cond(type T)(cond bool, v1 func() T, v2 func() T) T {
    if cond {
        return v1()
    }
    return v2()
}

and
    v := cond(useTls, FetchCertificate, ()->nil)

For the logging case, we could write
    log.Verbose("graph depth %d", fmt.Lazy(()->GraphDepth(g)))

where fmt.Lazy is a type that the formatting functions recognize and call when needed.
So upon reflection I'm not sure this idea adds much that isn't already in #21498.

If a human can almost easily make an optimization then it should be made by a compiler. And at least for a simplest cases this can be made without additional syntax. E.g.
log.Verbose("graph depth %d", GraphDepth(g))

Can be replaced by a compiler with:
if verboseFlag {
    depth := GraphDepth(g) // now it will be evaluated only if verbose enabled
    log.Verbose_body("graph depth %d", depth) // Verbose_body is a generated by compiler function without the log level check
}

I.e. compiler may use a simple heuristic: if first line in a function looks like a pre-condition then inline it.
A lot of functions already have such early return blocks with a simple conditions (compare with constant or field) e.g. without a call for another heavy function. E.g. pow2(n int) { if n == 0 return 0; if n == 1 return 1  ....}
Such optimization may be extremely effective and not needs for additional syntax and even can be backported.
But I see a lot of new problems:
1. It's unclear for a developer what exactly will be inlined
E.g. what if the precondition block uses two args? Then the initial block may have more than 30 instructions and inlining may make program size much bigger.
Basically this is part of a bigger problem with inlining of all functions.
Possible solutions:

Clear rules, or some compiler options or pragma similar to //go:noinline.
Clear syntax for preconditions e.g. contracts (like in Ada). But contacts is different thing (i.e. asserts) so better to call such block "pre-evaluation" .
Pattern matching or something similar. Like in Haskell:

factorial :: Integer -> Integer
factorial 0 = 1
factorial n = n * factorial (n - 1)

2. This may work only for static linking and for library functions we can't apply such optimization.
Again, the similar problem to regular inlining. Also sometimes developer may don't want to inline the call i.e. if I know that in runtime the ERROR level will be almost for sure be enabled. So instead of inlining the log levelel check
3. Most important: the argument evaluation may have side effects
The GraphDepth() function may read file or change cursor so in fact that's the reason why it should be anyway evaluated.
In fact, instead of marking an argument as lazy we may consider them all as lazy and function calls as pure. This is how it made in functional languages.
But if function is not pure then compiler may just break compilation. If a function has side effects then just make its call in a separate line, store the result into variable and only then pass to a function. This will keep code clean.
To summarize
Instead of laziness we may want to express purity and let compiler to do its job. The purity is a big topic but at least in simplest cases it can be detected and all needed optimizations may be applied.

If a human can almost easily make an optimization then it should be made by a compiler. And at least for a simplest cases this can be made without additional syntax. E.g.
log.Verbose("graph depth %d", GraphDepth(g))

Can be replaced by a compiler with:
if verboseFlag {
    depth := GraphDepth(g) // now it will be evaluated only if verbose enabled
    log.Verbose_body("graph depth %d", depth) // Verbose_body is a generated by compiler function without the log level check
}

I.e. compiler may use a simple heuristic: if first line in a function looks like a pre-condition then inline it.
A lot of functions already have such early return blocks with a simple conditions (compare with constant or field) e.g. without a call for another heavy function. E.g. pow2(n int) { if n == 0 return 0; if n == 1 return 1  ....}
Such optimization may be extremely effective and not needs for additional syntax and even can be backported.
But I see a lot of new problems:
1. It's unclear for a developer what exactly will be inlined
E.g. what if the precondition block uses two args? Then the initial block may have more than 30 instructions and inlining may make program size much bigger.
Basically this is part of a bigger problem with inlining of all functions.
Possible solutions:

Clear rules, or some compiler options or pragma similar to //go:noinline.
Clear syntax for preconditions e.g. contracts (like in Ada). But contacts is different thing (i.e. asserts) so better to call such block "pre-evaluation" .
Pattern matching or something similar. Like in Haskell:

factorial :: Integer -> Integer
factorial 0 = 1
factorial n = n * factorial (n - 1)

2. This may work only for static linking and for library functions we can't apply such optimization.
Again, the similar problem to regular inlining. Also sometimes developer may don't want to inline the call i.e. if I know that in runtime the ERROR level will be almost for sure be enabled. So instead of inlining the log levelel check
3. Most important: the argument evaluation may have side effects
The GraphDepth() function may read file or change cursor so in fact that's the reason why it should be anyway evaluated.
In fact, instead of marking an argument as lazy we may consider them all as lazy and function calls as pure. This is how it made in functional languages.
But if function is not pure then compiler may just break compilation. If a function has side effects then just make its call in a separate line, store the result into variable and only then pass to a function. This will keep code clean.
To summarize
Instead of laziness we may want to express purity and let compiler to do its job. The purity is a big topic but at least in simplest cases it can be detected and all needed optimizations may be applied.

In fact, instead of marking an argument as lazy we may consider them all as lazy and function calls as pure. This is how it made in functional languages.

This breaks the Go 1 compatibility promise. It would require significant language changes because it's well-known that arguments to functions are always evaluated before the function is called (in fact, in defer statements, they are evaluated when the defer is reached, not when the function exits). Not only this, but many functions in Go are not made to be pure functions.

In fact, instead of marking an argument as lazy we may consider them all as lazy and function calls as pure. This is how it made in functional languages.

This breaks the Go 1 compatibility promise. It would require significant language changes because it's well-known that arguments to functions are always evaluated before the function is called (in fact, in defer statements, they are evaluated when the defer is reached, not when the function exits). Not only this, but many functions in Go are not made to be pure functions.

Yep, that's why I wrote may. This is not required. The change will be breaking but to avoid unexpected performance pitfalls this is something that may be useful. I'll update my comment,

Yep, that's why I wrote may. This is not required. The change will be breaking but to avoid unexpected performance pitfalls this is something that may be useful. I'll update my comment,

Recently, I let my log functions return a bool, so that I can use bool AND to avoid a if-block:
_= log.VerboseLogging() && log.Verbose("graph depth %d", GraphDepth(g))

It is simpler, though still not perfect.

Following the principle of least surprise and other recent languages like Rust and Julia ( and a long history prior) why not add an explicit macro syntax
   log.Logger!( "graph depth %d, GraphDepth(g)" )
At a glance you know this is not behaving the way other functions are in go. You can build lazy and a plethora of other language features without requiring changes to the core language. Provided the macro syntax is not such a bad thing as long as it is a hygienic macro. Finally, with package scoping of the macros, you only have to deal with the macros that you import.

Hygienic macros would be nice, although they are extremely hard to get right and often times they essentially involve having a second "macro language" which would not be desirable.

Hygienic macros would be nice, although they are extremely hard to get right and often times they essentially involve having a second "macro language" which would not be desirable.

It is - I like the Julia Lang approach which is that the macro is regular julia code that returns the AST of the expansion. Fo go I'd assume you would compile the 'macro' snippet and pass the thunks (or you could use an expression evaluator ) the ast is then checked for escapes etc. It would be fairly easy to prototype using go generate.

I already proposed Hygienic macros in #32620 and they were rejected, partially because I was unable to write a macro preprocessor. If there is enough support perhaps it could be reopened though, although I think generics are likely to be a higher priority.

@mdcfrancis go build is not allowed to execute arbitrary code.

@mdcfrancis go build is not allowed to execute arbitrary code.

I understand the intent.
Rust seems to have a nice solution by taking a template approach to the problem https://doc.rust-lang.org/reference/macros-by-example.html this seems pretty clean and powerful approach.

I just checked and it turns out someone wrote a C like macro preprocessor for use with Go in Rust: https://github.com/Boyux/go_macro. Hook that up with go generate, and you're ready to rock. ;)

As @mdcfrancis mentions above in #37739 (comment), if we had a simpler function literal syntax, as discussed in #21498, then we could write
func Cond(type T)(cond bool, v1 func() T, v2 func() T) T {
    if cond {
        return v1()
    }
    return v2()
}

and
    v := cond(useTls, FetchCertificate, ()->nil)

For the logging case, we could write
    log.Verbose("graph depth %d", fmt.Lazy(()->GraphDepth(g)))

where fmt.Lazy is a type that the formatting functions recognize and call when needed.
So upon reflection I'm not sure this idea adds much that isn't already in #21498.

Even with #21498, there may still be some value in special casing thunks. I do agree that functions are preferable to interfaces here.
Mini counter-proposal follows...
Much like the type/expression duality of * with respect to pointers (and dereferencing), we could introduce @ as a "thunk of" sigil/operator:
log.Verbose("graph depth %d", @GraphDepth(g))

When used in an expression, @ must precede a call (much like go or defer), and @F(x) is equivalent to func() T { return F(x) }.
When used as part of a type descriptor, @T likewise means func() T.
Unwrapping a thunk does not have special syntax, since x := @F(); x() is convenient enough.
Regarding use with fmt: to avoid breaking backwards compatibility, a new format modifier (%@v) could be introduced to indicate that thunks should be unwrapped (perhaps transparently handling non-function values as though the @ modifier were not specified).

A definition of a pure function for Go would supply much of what's needed for this (after Generics). Proven-Pure functions then could be deferred automatically by the linker with no code change (and cached against argument changes).
Things to consider for pure functions:

no writing.
No reading from streams either.
Question:  What about "escaped" arguments & threading? This could require a full Rust-level evaluation regarding the in-context const-ness of an input.

How about a wild impossible idea? (it's Friday)
What about having the ability to inject log.Whatever statements anywhere in code after compiling???  at runtime???
Don't we all want the ability to arbitrarily insert, and later remove, log or print statements anywhere in our code after the code is built and running somewhere?  If I could only just see what that XYZ variable is doing... right... now.  Ha ha!
Does any language in history have the ability to inject or overlay prints in running code? -- like some types of probes do with hardware?
I imagine that if this were actually attempted that an enormous number of NO-OP type instructions would have to first be placed between each compiled line of code -- where each could be toggled with calls to a log. afterwards.
  How much time I spend re-building code just to add and remove debug output!!!

If you use tools like delve, this is precisely what they're for! I used to find debuggers a bit daunting, but they're actually quite simple in most IDEs. Set a breakpoint and you can see whatever data you need! (This is all a bit off-topic though)

@deanveloper Am familiar with delve already, but debuggers and IDEs cannot be used in containerized cloud environments -- only logging is available, where post-deployment logging customization would be very useful.
I am just contemplating the performance hit for typical code -- 5%? 10%? more?  Most code would not care about that level of impact.
Anyhow, I think it would be a truly transformative change in the relationship between the language and its logging functions -- and could be useful for post-deployment performance profiling as well!

@warrenstephens It's an interesting idea but it doesn't really have anything to do with this proposal.  I suggest that you discuss it elsewhere to avoid cluttering up the discussion here.  Thanks.

should lazy be sugar for something like func() (T, error) as opposed to func() T? I feel like if you can't handle an error condition, then it would make folks want to write more Must...() type of functions, which panic instead of returning an error.
Though, I suppose if you could create your own lazy closure, then you could check if the error was set to something.
func FetchCertificate() (string, error) {
    fmt.Println("fetching certificate...")
    return "fetched certificate", nil
}

func main() {
    var err error
    cert = Cond(false, lazy { v, err := FetchCertificate(); return v }, ()->nil)
    if err != nil {
	panic(err)
    }
}

Full working example, caching, short syntax, etc below. This feels totally doable today without changing syntax, however, it does require the explicit support for a Lazy. It would be very nice if it was possible to make laziness transparent (e.g. allow a func(lazy string) to take a string or lazy string).
https://go.dev/play/p/x2zjn0Xdxno

In fact, instead of marking an argument as lazy we may consider them all as lazy and function calls as pure. This is how it made in functional languages.

This breaks the Go 1 compatibility promise. It would require significant language changes because it's well-known that arguments to functions are always evaluated before the function is called (in fact, in defer statements, they are evaluated when the defer is reached, not when the function exits). Not only this, but many functions in Go are not made to be pure functions.

 Otherwise, lazy.Eval is passed into the function instead.

Now that sync.OnceValue() and friends are out, maybe it's time to take another look at this? Personally, I find the APIs for those to be kind of unwieldy when used inside of a struct, as they necessitate the use of a constructor or some kind of init() method, and in the latter case that method needs its own synchronization. I experimented a little and I kind of like this design for just simple lazy values:
type Lazy[T any] struct {
  val T
  ok bool
}

func (lazy *Lazy[T]) Get(f func() T) T {
  if !lazy.ok {
    lazy.val, lazy.ok = f(), true
  }
  return lazy.val
}

By doing it this way, it leaves the initialization to the call site, rather than requiring it up front. This lets it be used with zero values much more easily:
type Example struct {
  someValue Lazy[string]
}

func (e *Example) SomeValue() string {
  return e.someValue.Get(func() string {
    // Do the calculation here.
  })
}

Because of the API, it may make more sense to call this something like Cache instead of Lazy.
An extra function could also be added for when wrapping a function is all that's necessary:
func Memoize[T any](f func() T) func() T {
  var lazy Lazy[T]
  return func() T { return lazy.Get(f) }
}


Allow editing all environment variables in pipeline popups

Closes #3292
Screencast from 02.02.2024 00:15:21.webm

How will this look like for non-empty vars in the config? IIUC #3292 proposes to show/list existing env vars in the config and then allow adding additional ones.
Also, if so, the existing ones from the config should be highlighted somehow so they can be distinguished from the additional ones.

I basically tried to rebuild the functionality of Gitlab because I think that was a good suggestion.
@HerHde is this what you imagined?

I understood #3292 differently that the env var in the field where you enter it was not added with the Add variable  button and thus not added to the pipeline. The issue requests to also respect this env var.

This is what I meant

I basically tried to rebuild the functionality of Gitlab because I think that was a good suggestion.
@HerHde is this what you imagined?

Perfect!


Any new updates about the http proxy support?

Hi, I saw the http proxy branch and I am looking forward to using normal proxies with steamlink, any news on the progress of that branch?  I think I read that you said it doesn't block ads yet, I tried it with a ttvlolpro v2 proxy and it didn't block ads at all.   Just wanted to ask how is it going.   Thank you very much

It is stalled and needs more research.

Thanks for letting me know


Whack a mole game

Aim:
To create the  whack a mole game using HTML, CSS, Javascript.
Details:

Whack a mole is a famous game where a mole appears out in any of the 3x3 pit.
The user has to catch the mole by clicking on it.
The mole disappears in few seconds and appers in some other hole.
This is an interesting game played in various malls and carnivals

I would like to solve this issue undet HCSSoC.
@Ayush7614  Kindly assign me this issue.


Fancy Zones loses Custom layout

Every couple days, I find fancy zones not running correctly where I am unable to snap to zones that I previously could. When I go into the Fancy zones settings, I notice my custom layout is no longer available. I have re-setup my own custom layout a few times now and at some random interval days later, it just is no longer applicable.   What gives?

Hi @alphakry
what you report is unusual. The zone settings are persisted to this file
"C:\Users\%USERNAME%\AppData\Local\Microsoft\PowerToys\FancyZones\zones-settings.json"

The only way to make the custom zoneset to disappear is to delete that file.
I suggest you to create your custom zoneset and then save a copy of the zones-settings.json.
If the problem happens again, please post the save zones-settings.json file along with the one currently in use, so we can try to determine what happened.
Thank you.

Is power toys closing the file after making any changes?  I find that if windows crashes, I have a new empty zones-settings.json when i start up again.

@dankots
can you open a new issue specific for that scenario? Thank you.

This happens to me too.

Me too. Twice in the last two days. :(
Once after a power cut, which resulted in me having to reconfigure my bios (Asus Maximums Ranger VII)
And also after blue screening during a graphics driver update. (MSI GTX 970)
Windows 10 Enterprise, 20H2, 19042.630
A backup and restore feature would be nice.
Or maybe having this layout as one of the defaults..
https://i.imgur.com/1nlus8F.png
Thanks for the awesome app.

I can verify that this is still happening on 20H2 (19042.928) with version 0.37.0.

Same for me.  2 crashes this week and both have wiped out my custom settings.  First time I had two different custom windows settings I would swap between and both of them were gone.  2nd time my newly created main is gone again.

I have the same frustrating issue Windows 10, version 21H1

I too have this issue. With an external monitor. Sometimes after a crash or when my computer wakes from sleep I think this occurs.

Been having this same issue for a year or more (don't remember when I started using FancyZones, and it just happened again, with 0.51.0. Sometimes, it just "forgets" which layout goes where, but this time, all custom layouts are gone.
I'm using Windows 10 Pro, 20H2, and perhaps more interestingly, this is a studio rig with four screens; one 4K main screen, one 4K "big screen" above/behind the main screen, and two 1440p side screens in portrait mode. (That certainly manages to confuse video drivers and applications sometimes, but after the last few nVidia driver updates, it's been fairly solid.)
Also using 6 virtual desktops (the integrated Win10 solution) - and unless I remember incorrectly, some of the cases where FancyZones just forgot which layout goes where, this has only affected some of the virtual desktops.

I just had this happen to me this morning. I had to reboot, and after signing in, all my custom layouts where gone. I checked the files in "C:\Users%USERNAME%\AppData\Local\Microsoft\PowerToys\FancyZones" and noticed that all the various files had touch dates at about the time I signed in. Looking at the json files in VS, they all looked to be default settings files. None of my customizations where present.
I had to restores all of them using file history, which wasn't quite up to date, but better than losing everything.
I'm running v 0.51.1 on Windows 10 21H1 19043.1348.
I run multiple monitors, primary on Thunderbolt 3 and secondary on HDMI. I also use 3 virtual desktops.

I can confirm that this is an issue. Powertoys should keep a 'last known working' version of this file in the event that it's damaged.

Can confirm this is still not fixed.
My PC crashed in the middle of a game. Upon reboot my fancy zones custom layout was gone.

This issue is closed because the author didn't reply.
I am having this issue too, so it is unfair but that is the fault of the automated system and the error handling team that put it in place.
It seems every new update and/or change in number of monitors causes this problem to occur


Unwanted onChangeComplete triggered

When I press down the mouse button on the color palette, the onChangeComplete gets triggered,
then I drag to another color, after some milliseconds (~30-100?), it gets triggered again,
finally, I release the mouse button, nothing get triggered.
Expected :
Mouse down -> nothing
Drag -> onChange
Mouse up -> onChangeComplete

I'm having a similar issue - I think it might be related to this open issue #321 ?: https://github.com/casesandberg/react-color/issues/321
I'm not entirely sure how to fix it, but can try to submit a PR. :)

I'm having the same issue. It is problematic since I want to hide the picker when the color has been selected by the user.


Unnecessary line split

impl Builder {
    fn expr_as_operand(&mut self) {
        debug!("expr_as_operand: category={:?} for={:?}", category, expr.kind);
    }
}

turns into
impl Builder {
    fn expr_as_operand(&mut self) {
        debug!("expr_as_operand: category={:?} for={:?}",
               category,
               expr.kind);
    }
}

We use a heuristic to split long functions even when not necessary. This is because otherwise rustfmt tends to favour really long functions which are hard to read and people don't tend to write themselves. You can customise it by setting fn_call_width to something larger. If you set it to the max-width, it will be ignored. Macros are formatted pretty much like functions.
We could increase the default value, or use a longer value just for macros, or special case macros with string literals (might be worth doing anyway).

Closing for now, as this is basically a configuration issue.


Prefer using the version parameter in examples instead requiring the versioned client

resolves #2099

Codecov Report

Merging #2102 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2102   +/-   ##
=========================================
  Coverage     86.77%   86.77%
  Complexity     5000     5000
=========================================
  Files           450      450
  Lines         19829    19829
  Branches       2095     2095
=========================================
  Hits          17206    17206
  Misses         1904     1904
  Partials        719      719

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4305b7...488fd99. Read the comment docs.

Thanks Joe!


chore(package): update tap to version 10.3.0

Closes #68
https://greenkeeper.io/

Coverage remained the same at 40.0% when pulling f69a4bed51047d473f6e933127b6b4fe7d110dca on greenkeeper/tap-10.3.0 into 9aef7a3f74590ceb5e82985d89596be6e01ed738 on master.


dbeaver/pro#1711 Redesign dictionary value viewer

Now it looks like this.

Also if the max number of pages is known (you are or have been on the last page), it's remembered and shown like page 2/3. We could calculate it and show always, but it requires an additional query. It's not worth it.

Please check at least these (separate and in different combinations) in different databases:

[x] value editing with Value field
[x] search
[x] sorting
[x] pagination

verified


Only one DidChangeTextDocument notification sent during batch edits such as search-and-replace

I am trying to understand the specification for textDocument/didChange from Version 2.x of the spec.
I thought that a separate notification would be sent for each textChange. And that does happen when you edit each file individually. But, when you edit the files in batch (like with a search-and-replace), it only sends notification (for a random  file in the batch).
I have been trying this with Visual Studio Code (Insiders) as the reference client implementation. I am not sure if this is a bug in vscode or if this is the behavior of the spec, hence the question.
Repro steps:

Download https://github.com/Microsoft/vscode-languageserver-node-example
Modify server.ts so that it logs for all the different text/* notifications.
You should be able to see all the log in the debug console in the host window.
In the extension window, open two .txt files side-by-side.
Do a search-and-replace.
Notice that you only get one textDocument/didChange notification, and it seems random which file is picked. In the screenshot below, file1.txt tab seems to be in focused, but it is file2.txt that is sent across.

You can watch the steps at https://vimeo.com/208995328
On the other hand, if you did a Save All, you get two textDocument/didSave notifications.

You can watch the steps at https://vimeo.com/208995307
Questions:

Is this working-as-designed (WAD) or a bug?
If this is WAD, could you shed some light on how the client picks which file out of the batch to report back?
If this is WAD, how would we handle detecting that changes have occurred in multiple files? Would workspace/didChangeWatchedFiles per used here?

The design for this is as follows:

you only get content change events for documents for which you received a open event before
for documents that are not open (no open event is sent) the truth is on the file system and you can get file system events for that.

In our example are you missing any change events for documents for which you received an open event before. If so please open a bug against vscode-languageservernode with steps to reproduce.

Thanks for the explanation.
It does look to be a bug. I do get two open events but only one change event. If you look at the first screenshot above, you see
file:///Users/nchen/Desktop/vscode-example/file2.txt opened.
file:///Users/nchen/Desktop/vscode-example/file1.txt opened.
which comes from the logging I did on
connection.onDidOpenTextDocument(function (params) {
    // A text document got opened in VSCode.
    connection.console.log(params.textDocument.uri + " opened.");
});

I'll file a bug against vscode-languageservernode and link this item to it.

@vazexqi if I understand your comment in https://github.com/Microsoft/vscode-languageserver-node/issues/133 then this is now working for you after updating to the latest version of the library. Right?

Yup, it's working on the latest version of the library.


"Update service reference missing"

After one of the latest Visual Studio updates, I can't find "Update service reference" anymore for WCF services?
Or am I missing something??

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

ID: 89a74dad-9ebf-c219-2ad8-3aefaa7f8127
Version Independent ID: 353c73ea-98dc-b0d9-2a83-fd9af8f6840a
Content: Add, update, or remove a WCF data service reference - Visual Studio (Windows)
Content Source: docs/data-tools/how-to-add-update-or-remove-a-wcf-data-service-reference.md
Product: visual-studio-windows
Technology: vs-data-tools
GitHub Login: @ghogen
Microsoft Alias: ghogen

@AlexHimself -- Alex, thank you for your questions.  Please consider these resources:

Visual Studio on Microsoft Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit

@ghogen -- Gordon, please look into this issue.

@WilliamAntonRohm I've posted there and I'm pretty sure it's simply missing for WCF services after a semi-recent update.

@AlexHimself -- Alex, thank you for your followup.

I'm having trouble following this issue. So am I correct that it's missing now?
I see it's labeled doc-enhancement, does this mean if it is missing, the intent is to just document it or that my "work around" is going to be standard procedure?

@AlexHimself -- Alex, thank you for your comments.  A doc-enhancement label indicates there is new information to add to the article.  Your questions are outside my areas of expertise.
@ghogen -- Gordon, can you help clarify here?

@AlexHimself I've contacted the engineering team with this question. This is a documentation feedback channel; product questions  and feedback are best asked by submitted to Developer Community: https://developercommunity.visualstudio.com/search?space=8

@AlexHimself I've contacted the engineering team with this question. This is a documentation feedback channel; product questions and feedback are best submitted to Developer Community: https://developercommunity.visualstudio.com/search?space=8

Well the documentation is wrong then?

And it looks like it's been addressed - https://developercommunity.visualstudio.com/t/16110:-Update-Service-Reference-missin/1500425?space=8&q=update+service+reference+missing

@AlexHimself This was accepted a product issue, so we will leave the docs as they are, and this will be fixed in the product.


CUDA Out of Memory Error When Running sample.py with a large --num-samples

I'm trying to generate a number of sequences with sample.py, so I set the --num-samples parameter to 100.
However, upon execution, I received the following error message:RuntimeError: CUDA out of memory. Tried to allocate 166.00 MiB (GPU 0; 9.77 GiB total capacity; 8.11 GiB already allocated; 149.81 MiB free; 8.15 GiB reserved in total by PyTorch). My GPU seems to run out of memory during the process.
Has anyone else experienced anything similar, or does anyone have a suggestion on how to get around this memory limitation? Thank you in advance for your time and help!

I got the same. I found I could run ~15 sequences at a time.
But I'm getting repeat sequences (100% ID to sequences from other runs) when I run multiple sets of 15 to get up to 100.

I got the same. I found I could run ~15 sequences at a time.
But I'm getting repeat sequences (100% ID to sequences from other runs) when I run multiple sets of 15 to get up to 100.

Got it, Tks for your advice


Indicate that uv lock --upgrade has updated the lock file

Summary
Resolves #4346, I've gone with the suggested cargo approach here.
Test Plan
cargo test
❯ ../target/debug/uv lock --upgrade
warning: `uv lock` is experimental and may change without warning.
Resolved 11 packages in 41ms
Updating flask v2.3.3 -> v3.0.3
note: pass `--verbose` to see 9 unchanged dependencies
❯ ../target/debug/uv lock --upgrade -vv
    0.002478s DEBUG uv uv 0.2.24
warning: `uv lock` is experimental and may change without warning.
....
Resolved 11 packages in 50ms
    0.103703s DEBUG uv::commands::project::lock Unchanged blinker v1.8.2
    0.103719s DEBUG uv::commands::project::lock Unchanged click v8.1.7
    0.103731s DEBUG uv::commands::project::lock Unchanged colorama v0.4.6
    0.103742s DEBUG uv::commands::project::lock Unchanged flask v3.0.3
    0.103754s DEBUG uv::commands::project::lock Unchanged importlib-metadata v8.0.0
    0.103767s DEBUG uv::commands::project::lock Unchanged itsdangerous v2.2.0
    0.103778s DEBUG uv::commands::project::lock Unchanged jinja2 v3.1.4
    0.103788s DEBUG uv::commands::project::lock Unchanged markupsafe v2.1.5
    0.103798s DEBUG uv::commands::project::lock Unchanged werkzeug v3.0.3
    0.103809s DEBUG uv::commands::project::lock Unchanged zipp v3.19.2

I got this one.

There's one problem here which is that we can have multiple versions in the new and existing lockfile. I'm not sure what the best logic is here...

I'll try something a little different.


[BUG] [HELP ME]

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.
[X] My answer given in the checkbox above is a lie.

What problem did you encounter?
I installed Bloxstrap today and started checking the functions that are in this application, when I checked everything I turned off the functions that I didn’t like and re-logged into Roblox, but these functions remained, I tried to re-login again, I restarted the computer, nothing helps
these functions are the “old oof” and the sounds of walking, running, to the sounds from 2014
I have them turned off in Bloxstrap, but they still work, can you help me?

[X] My answer given in the checkbox above is a lie

[!WARNING]
Please read the preliminary instructions before reading.

Try deleting these modifications by file explorer. There is a button that you directly to the Modifications folder in the Modifications tab in Bloxstrap Menu.

Go into the behaviour tab, enable the "Force Roblox Reinstallation" toggle, relaunch and see if that fixes it

Closed due to inactivity from OP.


Landing data on S3: the good, the bad, and the ugly -  Sergey Ivanychev @Joom Blog at Medium

URL: https://medium.com/joom/landing-data-on-s3-the-good-the-bad-and-the-ugly-ca42a1d4408d
Review (1-2 sentences): The good, the bad, and the ugly about how to consume events from Kafka into Data Platform.

Published in Digest #15


Outdated tutorial "How to Build and Test a Next.js and Shopify Store"

The tutorial https://learn.cypress.io/tutorials - How to Build and Test a Next.js and Shopify Store with its 6 lessons is outdated.

The screenshots and folder structure it describes is for legacy Cypress (version 9.x and lower).
The repo https://github.com/vercel/commerce is based on Next.js 14. There are currently some issues with Cypress (13.6.3) supporting this latest version of Next.js (see https://github.com/cypress-io/cypress/issues/28185).
According to https://github.com/cypress-io/cypress-realworld-testing/issues/325 the Shopify screenshots are out of date.
The GitHub JavaScript Action versions actions/checkout@v2 and cypress-io/github-action@v3 are out of date and rely on using the deprecated Node.js versions node12 and node16 respectively.

The tutorial requires rework to bring it up to date.

Closed due to no feedback.


[WIP] Mesh

The implementation still needs some work but I just want to make sure we agree on the interface.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@0eebf05). Click here to learn what that means.
The diff coverage is 98.81%.

@@            Coverage Diff            @@
##             master     #186   +/-   ##
=========================================
  Coverage          ?   95.73%
=========================================
  Files             ?      386
  Lines             ?    28295
  Branches          ?        0
=========================================
  Hits              ?    27088
  Misses            ?     1207
  Partials          ?        0

Impacted Files
Coverage Δ

packages/Kokkos/src/DTK_MeshBlock_decl.hpp
100% <100%> (ø)

packages/Kokkos/test/tstMesh.cpp
100% <100%> (ø)

packages/Kokkos/test/tstMeshBlock.cpp
100% <100%> (ø)

packages/Kokkos/src/DTK_MeshBlock_def.hpp
100% <100%> (ø)

packages/Kokkos/src/DTK_Mesh_decl.hpp
100% <100%> (ø)

packages/Kokkos/src/DTK_Mesh_def.hpp
94.11% <94.11%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0eebf05...0d04aa5. Read the comment docs.

I just had a discussion with @aprokop and we agree that the current interface looks good if most people only use MeshBlock. If they want something more complicated they can use Mesh. However, we could also force everybody to use Mesh. Then, we would add a constructor similar to the one of MeshBlock for people with simple mesh. In this case, we can gut MeshBlock and make it a struct that we will only use internally. @dalg24 @sslattery  what's your opinion on this?

Closing in lieu of #187


Place an order not working

"Type error: Argument 1 passed to Mage2\Ecommerce\Events\OrderPlaceAfterEvent::__construct() must be an instance of Mage2\Order\Models\Order, instance of Mage2\E ▶"

its on my list. But thanks again for raising most likes it might be fixed in tomorrow commit.

it should be fixed.

product is not adding to database on submitting database


Bottom Bar flashes every time an item is changed.

Everytime I click an item the entire bottom bar flashes. This is on 1.1.9 and 1.2.0

You're right. I'm investigating this.

Should be now fixed in 1.2.1.
Thanks for reporting!


Dynamically add SDFG element properties to be added based on editing actions

When selecting certain values in enums for element properties, certain new information is required. For this new information, the required properties should be dynamically added so the user can fill them in. An example is selecting a schedule for map scopes: when a GPU schedule is selected, the block size should appear as a new property to be filled out/changed.

Closing because it has been duplicated in #156. These issues are both related to what we have been internally referring to as 'enum properties' in DaCe.


xml.etree.ElementTree nodes

The change made for issue #19 may not be 100% yet. There's a slight difference in behaviour: using sign() on an lxml etree node modifies it in-place, whereas using it on a stdlib etree node returns a new signed copy but doesn't modify the original.
I don't see the docs specifically make a promise to sign in-place, but the very first example (signing and then verifying) relies on it.
To build from my previous test case:
x = "<foo><bar></bar></foo>"
root1=xml.etree.ElementTree.fromstring(x)
root2=lxml.etree.fromstring(x)

signxml.xmldsig(root1).sign(key=key, cert=cert)
signxml.xmldsig(root2).sign(key=key, cert=cert)

>>>signxml.xmldsig(root1).verify()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/signxml/__init__.py", line 580, in verify
    signature = self._find(root, "Signature")
  File "/usr/local/lib/python2.7/dist-packages/signxml/__init__.py", line 663, in _find
    raise InvalidInput("Expected to find XML element {} in {}".format(query, element.tag))
signxml.InvalidInput: Expected to find XML element Signature in foo
#no good!

>>>signxml.xmldsig(root2).verify()
<Element foo at 0x7fb4d8c9ca28>
#okay!

#But....
root1 = signxml.xmldsig(root1).sign(key=key, cert=cert)
>>>signxml.xmldsig(root1).verify()
<Element foo at 0x7fb4d8ca0560>
#this actually works!

I have altered the docs. Pray I don't alter them further :)
Thanks for spotting this, @nickcash. Let me know if you see any further inconsistencies.

(I agree in principle it would be good to have the behavior be consistent, but I can't be bothered to figure out how at this moment. PRs welcome.)


When totalCount is 0 (zero), causes UI problem

Hi,
Couldn't find any similar posts. (Apologies if one did exist tho')
I noticed that if [totalCount] is 0, your logic here breaks:
self.isForwardDisabled = ko.computed(function () {
    return self.currentPage() === self.pagesCount();
    // <-- problem, if pagesCount() == 0; where it is, if [totalCount] == 0
    //return self.currentPage() >= self.pagesCount(); <-- solved, or should I put logic to check if [totalCount] is zero, then change [currentPage] to zero?
});

and possible here:
self.isBackDisabled = ko.computed(function () {
    return self.currentPage() === 1;
});

It allows to use [Next] and [Last] -buttons, causing the page numbering to become negative based.
You can test this on your example (http://faulknercs.github.io/Knockstrap/#pagination) - just change [Total items] to 0 (zero) and press [Last] -button.

Duplicate of #46


Automatically detect comment rules in grammar

For #204, we need some way to detect comment rules in grammars. I propose the following solution:
Every terminal that is hidden but does not match a white space string is a comment terminal by default.

This is a bit vague IMO. Is it not possible to compare the terminal rule name with default comment rule names ML_COMMENT and SL_COMMENT?

It's a bit more complicated than that. E.g. users could decide to rename these terminals or simply add a third kind of comment.
This is never a problem during runtime, because we have a GrammarConfig that contains all comment terminal names. However, when generating the textmate grammar, we don't know about this. Therefore, we have to identify all comment terminals while the langium-cli is running.

when generating the textmate grammar, we don't know about this

It must be somehow possible to get the information from GrammarConfig, or maybe the information about "What is a comment" should be placed somewhere else?


Verify API security when host is blank

And do not verify API security in DEBUG mode. See commit message for reasoning.

Do not merge yet

Oh, I overlooked that disabling the check in DEBUG would break the tests. Hmm, maybe the convenience provided isn't enough reason.

We need to be able to test this function, you can't disable it in testing.
Also, definitely need to extend the tests to show that the flag warning will trigger for --api-addr :xxxx

Also, is it really that bad to add the --diable-api-security flag when using a docker container? Definitely not worth it.

Done

Rebased
Removed the commit that skipped security check in DEBUG
Fixed tests
Added an additional message to the error output if the host is blank e.g.

$ siad -d sia_test/ --api-addr 9980
an empty host will listen on all interfaces, did you mean localhost:9980?
you must pass --disable-api-security to bind Siad to a non-localhost address

To do

[ ] Consider special casing the --api-addr argument to default to localhost if the host is not specified.

should x default to localhost:x?
should :x default to localhost:x? This would make it impossible to listen on all interfaces. I'm not aware of a valid use case for this, but there might be.

[ ] Update TestUnitProcessNetAddr, TestUnitProcessConfig, and TestVerifyAPISecurity accordingly.


Swithcing to new dppl name

examples/sycl/svm_batch.py for some reason marked like totally changed in diff... end of lines?
LGTM

yes. end of lines


Updated free-programming-books-langs.md

What does this PR do?
Add resource
For resources
Description
This PR adds C Programming Absolute Beginner's Guide (3rd Edition) book on C language
Checklist:

[✅] Read our contributing guidelines.
[✅ ] Search for duplicates.
[✅] Include author(s) and platform where appropriate.
[✅ ] Put lists in alphabetical order, correct spacing.
[✅ ] Add needed indications (PDF, access notes, under construction).
[✅ ] Used an informative name for this pull request.

@sohansai Please merge this pull request.


⚠ Bofrost.be has degraded performance

In 2ca55eb, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1467 ms

Resolved: Bofrost.be performance has improved in fb563f1 after 20 minutes.


Thumbs up (not a bug)

After searching long and hard for a commenting system I've landed on Isso. Very happy to see there is some movement and engagement from new maintainers.
Just wanted to say thanks to everyone involved.
This is not a bug and may be closed.

That's very kind of you :)


WIP: [ILVerify] Implement delegate creation checks

The verification algorithm should require the creation of delegates to be always done with a specific sequence of IL-instructions. This sequence differs depending on whether ldvirtftn or ldftn is used.
I implemented the checks for this rule in the method CheckDelegateCreation.
I also implemented the IsDelegateAssignable check, which compares the given ftn signature with the signature of the Invoke-Method of the delegate to be created, as defined in ECMA.
These checks also prompted the implementation of the rule defined for calling non-final, virtual methods using the call instruction (which is also checked when loading such a method using ldftn):

When using the call opcode to call a non-final virtual method on an instance other than a boxed
value type, verification checks that the instance reference to the method being called is the result
of ldarg.s 0, ldarg 0 or ldarg.0 and the caller’s body does not contain starg.s 0, starg 0 or
ldarga.s 0, ldarga 0.

(ECMA III.3.19: call)
In other words, when using call to call a non-final, virtual method, the value given as the instance of the method to be called, has to be either a boxed value type, or the this pointer of the calling method, which may not be modified in any other way during the current method.
I implemented this rule in a similar manner as it was implemented in PEVerify, however my implementation reports an error for the following code (hence the WIP title):
C#:
void Method()
{
    int i = 0;
    i.ToString();
}

relevant IL:
ldc.i4.0
stloc.0
ldloca.s  0
call      instance string [System.Runtime]System.Int32::ToString()

Here the method ToString is called on the value type Int32 by passing a managed pointer to an Int32 as the this pointer. This code does not report an error when verified using PEVerify, even though my implementation should perform the same checks.  If I correctly understand the above rule, this should also report a verification error, since the call instruction is used to call a non-final, virtual method (ToString), but the value passed as the this pointer is not the calling method's this pointer (ref int32).
Since this IL-code is generated by the C# compiler, I assume that I am simply missing something here. Do you have any input on this?

@ArztSamuel,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Since this IL-code is generated by the C# compiler, I assume that I am simply missing something here. Do you have any input on this?

Valuetypes are sealed. All methods on sealed types are considered final. The relevant code is here: https://github.com/dotnet/coreclr/blob/master/src/vm/jitinterface.cpp#L6728
I think that the right way to fix this here is to skip this check for methods on valuetypes.

Or skip it for all sealed types just like it is done by PEVerify.

Yes, of course. That makes sense.
Thank you very much!


Proposal: "Headless" mode of the AliyunDrive implementation

While the implementation of Aliyun Drive works end to end. It is different from client-only / non-server workflows, where there's no `refresh_token' provided.
And client-only solution should NOT contain the "client_secret" for security reasons.
Thus, we might need a "headless" mode where the access token is not relying on the refresh token.
Before the actual code changes, I'd like to propose the potential modifications, i.e. the "headless" mode:
let mut aliyun_drive_builder = opendal::services::AliyunDrive::default();

aliyun_drive_builder.access_token(&aliyun_drive_config.access_token, drive_id);
// or:
aliyun_drive_builder.with_headless_mode(&aliyun_drive_config.access_token, drive_id);

let operator = opendal::Operator::new(aliyun_drive_builder)?
    .layer(opendal::layers::LoggingLayer::default())
    .finish();

We might want a different name rather than the headless mode.
In pub async fn get_token_and_drive(&self) -> Result<(Option<String>, String)>, we can check if it is the headless mode. If it is, we just use this configuration rather than requesting new access tokens
https://github.com/apache/opendal/blob/c82dc139e7478ac96a90c49dc8e5326ecc057d75/core/src/services/aliyun_drive/core.rs#L122
Background: https://github.com/apache/opendal/pull/4585#issuecomment-2166698100

Trying to use this in production but this implementation is too different from that of OneDrive and Google Drive.
The major question is that: Why this OpenDAL implement requires refresh_token and client_id?
The AliyunDrive API supports OAuth. IMHO, we can just send an access_token to the operator and let the host app handle the auth part.
Not all users would have the refresh_token. By design, AliyunDrive does not generate refresh_token for non-server applications https://www.yuque.com/aliyundrive/zpfszx/eam8ls1lmawwwksv
Sample token redeem response:
{
  "token_type": "Bearer",
  "access_token": "ey...",
  "refresh_token": null,
  "expires_in": 2592000
}

Seems we can add access_token in config

I agree with you. I overlooked the client side. I prefer to delegate the token generation part to the lib. However, it's crucial to keep the secret confidential for client apps.
IMO, all we need is an extra access_token. Users can configure it with either an access_token or a set of refresh_token, client_id, and client_secret.

thanks for your inputs!
Do you prefer me or yourself to do this? @yuchanns

I plan to submit a PR tomorrow. I'm considering refactoring the Writer part of AliyunDrive to fully support the rapid upload, and then I'll need to add it.

Awesome! Thank you so much!

I plan to submit a PR tomorrow UTC+8. I'm considering refactoring the Writer part of AliyunDrive to fully support the rapid upload, and then I will hitch a ride to add it.

Bravo! Our integration testa failed for https://github.com/apache/opendal/issues/4657, maybe you also want to take a look 🙏


Simplify the implementation of ChatClient-based interfaces

Provide sensible defaults for overloaded methods in PromptUserSpec, PromptSystemSpec, AdvisorSpec, CallResponseSpec, ChatClientRequestSpec, and Builder interfaces.

I'd like to keep the interfaces without any defaults as in WebClient and other spring projects.  This PR also introduces a conflict in that the single implementation of the existing spec classes have different behavior it seems at first glance.  I took a look at PromptUserSpec for example.
@Override
public PromptUserSpec text(String text) {
	Assert.hasText(text, "text cannot be null or empty");
	this.text = text;
	return this;
}

vs.
default PromptUserSpec text(String text) {
	Charset defaultCharset = Charset.defaultCharset();
	return text(new ByteArrayResource(text.getBytes(defaultCharset)), defaultCharset);
}

What is wrong with using the string as supplied?  In anycase, these impls are used in one place, so if there are changes to make in the impl, i'd do it there.

Keeping the interfaces inside ChatClient (and other areas of Spring AI) void of implementation (i.e. without defaults) is reasonable. I actually considered this before submitting the PR and wondered whether I might add abstract base classes instead (Java's own Collection framework is a really good example of providing many abstract base classes supporting implementations.
I tend to provide defaults when:

The default implementation is very simple to implement (only a few lines)
The functionality can be easily and reliably implemented in terms of another method
Reduces effort and promotes consistency across implementations
Enables the use of functional interfaces (aka @FunctionalInterface) as Lambda expressions

NOTER: #4 is not as applicable in this case since the ChatClient interfaces provides several related but distinct methods. For example, in the PromptUserSpec interface (and similar) there is the text(:Resource, :Charset) (here) and params(:Map) methods... related but distinct ops with a couple of "overloaded" variants that do not differ much in implementation and therefore can follow the most complete method signature.

Regarding...

What is wrong with using the string as supplied i the current impl?

Nothing, other than using the given String directly is an implementation detail.
Any implementation is free to still override a default implementation, necessarily based on internal data structure, performance, or all sorts of reasons. But the key is, implementations do not need to override and explicitly implement every overloaded variant, keeping the implementations focused on the key details that matter.
A lot of the methods in the ChatClient interfaces are for "convenience". They are not functionality independent.
Finally, Spring is an excellent example of the Open/Close principle, and making the task of implementation by downstream frameworks or libraries in addition to application's occasional need for extension simpler is generally a good thing.
Food for thought.

FYI, in the process of writing my book, I have thought of many extensions and areas for improvement in Spring AI, while considering all angles, other: libraries, frameworks, applications and tooling implementations.

@markpollack
I should probably add that, in several cases, Spring AI does use default methods on interfaces.
For example, ChatModel and StreamingChatModel both use default methods, as does ChatMemory.
In fact, this is quite common through Spring AI's codebase.

StructuredOutputConverter
DocumentReader & DocumentWriter
Evaluator
And on and on...

1 last comment...
Declaring default methods in interfaces does not change the default implementation/behavior already provided by Spring AI in the DefaultXyz classes, for example DefaultChatClient.
In particular, the text(:String):PromptUserSpec method (source) that you referred to above is still used over the default method provided in the interface.
Finally, the ChatClientBuilder used to build and construct a ChatClient will still build a DefaultChatClient, for which all the "default" sub-interface implementations are maintained.
So, this PR changes nothing, and only provides convenience.


Orders failing to match - Negative spread & orders filling out of order

Issue Description
Our token is xKangaMK1 and currently people are unable to buy on the dex either with market orders or limit orders.
You can place limit orders for higher amounts than the sell orders causing a negative spread.
These buy orders (which can be any amount higher than the sell orders) can be filled buy selling into them.
Steps to Reproduce
Place an order (now 17 Nov 18:50 UTC) on our order book
https://sologenic.org/trade?network=mainnet&market=784B616E67614D4B310000000000000000000000%2BrPwdrA6YFGR6k5rPyT6QPx7MrQAavUtyz5%2FXRP
Try to do a market buy and then do a limit buy for more than the lowest sell orders
Expected Result
The market order should buy at the lowest sell
The limit order should auto fill buying tokens from the lowest sell order up
Actual Result
The market order fails
The limit order is placed as a buy order on the "buy" side of the order book
Environment
This is happening on the live Dex
Supporting Files

This problem should be fixed soon by th amendment described here: https://xrpscan.com/amendment/B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2

Hi,
How long will that take to be propagated to the dex??

@Cadey, as it says on the linked web page, assuming the amendment continues to see support from validators, the change will be enabled at:
Nov 18, 2021, 05:16:31 PM UTC
I see no reason for the amendment to lose support at this point in time.


LUT Speedup

Description
Collection of improvements to the luts.py module to increase the loading speed. Present goals are to reduce the loading speed on any LUT to be less than two minutes for any strategy.
Leaving as a draft while performing ongoing experiments.
Changes

🐛 Fixed a bug with subsetting dimensions that are in reversed order. Subsetting wasn't actually working as intended, often leaving the entire dimension in play. As a result, downstream processing could have significant additional overhead, such as interpolation.

@jammont Have you checked the performance on the cluster? If so, do we see the same improvements as on your local machine?

Data that the cube example uses is currently unavailbale - previous tests passed, and the dask change has been well tested by itself, so merging.


fix: expand the sla_margin to 23 worth of blocks by default

Cherry-picked from v0.2:
Merge pull request #970 from omisego/hotfix_sla_margin
Overview
see #970
Changes
see #970
Testing
see #970

Coverage increased (+0.06%) to 91.344% when pulling e8c41047db08beecf5dc4a05e1c94f616d7046ee on longer_sla_margin into c07675ba6c71799537e1b46965a31091838a4d04 on master.


unreachable code

https://github.com/Spatial-Data-Science-and-GEO-AI-Lab/GreenExp_R/blob/7a52a5d6615088e50a4ba11ee25524cadab8b46d/R/accessibility.R#L79
this should be unreachable due to the conditional tests in lines 65-76.

The redundant line is removed