Proposal: Go2: add hygienic macros

In #32437, a proposal is made for error handing based on a built-in function. However all that is proposed is in essence, much like append(), simply a special case macro for code that can be implemented in Go manually.
One problem I often encounter in Go is that there quite a bit of boilerplate to implement certain functionality, not only in error handling, but in general. Generics have been proposed as a solution to this, but, as can be seen from the proposal I mentioned before, if ever implemented, will be unlikely to be powerful enough to allow the go programmer to implement such error handling boilerplate themselves.
Also we have go:generate, which I use often to generate go code from text/template, but is not part of the language itself, and allows me to use all sorts of C-like preprocessors agnd generators that use text/template go code, with all the downsides of this kind of preprocessors and generators.
Therefore I propose that Go would be enhanced with hygienic macros.  They would then also allow to reduce boilerplate many other cases as well. Probably they would have to be based on AST rewriting much like hygienic macros in other languages.
I don't even want to start discussing syntax, but perhaps something like https://github.com/cosmos72/gomacro would be a starting point.
I opened this issue to see if others and the Go designers feel this idea could be useful and acceptable. It seems a better idea to me to introduce a more generally useful hygienic macro feature in Go, than, like has been done before, introduce one off macros for particular cases only. Hygienic macros are a well known feature of many programming languages, for which efficient implementation algorithms exist, which might be more useful than generics to reduce boilerplate in Go considerably, and which can be taught and explained relatively easily. So I think they would have many benefits that would outweigh the cost of implementing them.
Edit: link for more details:
https://en.wikipedia.org/wiki/Hygienic_macro

At least one of these links is a general purpose macro system
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#inlining
@gopherbot add Go2, LanguageChange

Yes, this ...
https://medium.com/@phlatphrog/handling-more-than-just-errors-in-go-f97c5aa2eac4
... Looks like it could fit the ticket, with some refinement. Thanks for
the suggestion.
Op vr 14 jun. 2019 17:07 schreef Liam<EMAIL_ADDRESS>
At least one of these links is a general purpose macro system
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#inlining
@gopherbot https://github.com/gopherbot add Go2, LanguageChange
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/32620?email_source=notifications&email_token=AAARM6OKHW5VLDN7ZZCD4O3P2OX4BA5CNFSM4HYHEYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXXB4ZQ#issuecomment-502144614,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARM6MNC3IHQMVF2QR3OWDP2OX4BANCNFSM4HYHEYTQ
.

If the try builtin proposal can be implemented as a macro, then macros can change control flow.  That does not strike me as a good feature.  A number of people have reasonably objected to try on the grounds that it changes control flow, and therefore makes the program harder to understand.  If macros can change control flow, then macros can similarly make a program harder to understand.  Much harder.  That seems like a problem.

@ianlancetaylor
catch from the draft proposal can also change control flow. There's nothing inherently wrong with that, and as with other language constructs that do the same, I assume people will either learn how they work or not use them.

@ianlancetaylor
Personally I don't think the problem with try is that it changes flow control. Actually, to be useful and save on boilerplate, it should do so. The problem is that we can't implement such flow control changing try, cond, etc, macros ourselves, and customize them to our own liking.
And if flow control changing special case built in macros like try are desirable to reduce boilerplate, then moreso can be said for programmable defined macros, when used judiciously like @urandom suggests. The Go standard library could contain a few standard macros that are well documented
If you read the link to phlatprog's medium you will see how he suggests a macro similar to try could be implemented. He suggests that a macro is like a func, but the body of the macro is inserted hygienically inline in the macro call site with the parameters substituted in the body. I really like this idea, because it is simple to explain, but extremely useful.

Rust implements it's try feature as a macro: https://doc.rust-lang.org/1.9.0/std/macro.try!.html

I personally agree with @ianlancetaylor's sentiment here. Maybe if we had a distinction between macros and functions (such as rust's try! and println!), this would seem a bit better. Then we can at least clearly see where control flow may be happening.

Well, why not? I didn't propose any syntax yet, but maybe some marker like
! or so could be nice. Good to see that try can be implemented as a macro
in a language that has hygienic macros. I'd say that this demonstrates the
advantages of this idea.

I think the advantages of hygienic macros are fairly clear.
What I'm personally concerned about is the disadvantages.  In particular, it seems to me that it can easily become much harder to read Go code written by somebody else using a different set of macros.  I'm concerned that it could become much harder to share Go code, not in the sense that the shared code doesn't run, but in the sense that it is hard to understand and debug the code you didn't write.

I think the advantages of hygienic macros are fairly clear.
What I'm personally concerned about is the disadvantages. In particular, it seems to me that it can easily become much harder to read Go code written by somebody else using a different set of macros. I'm concerned that it could become much harder to share Go code, not in the sense that the shared code doesn't run, but in the sense that it is hard to understand and debug the code you didn't write.

Is there any such precedent in languages with hygienic macros? Granted, that might be hard to observe, but it could be a nice use-case nonetheless.

During the discussion try(), some people also worried that  it makes the code more difficult to read. But that argument was refuted,  because it is not because try() can be abused, or because try() changes the flow control, that it becomes so complex that it cannot be used safely.  People will learn to use this feature correctly and understand how it works.
The same goes for hygienic macros.  While potentially they could make program more difficult to understand, the Go users will learn how to use them, and when use correctly they will provide us with better abstractions and less boilerplate. If you think about it, even a function is an abstraction that hides away details, but that doesn't stop anyone from defining functions. The same goes for macros, we will have to read the documentation of a particular macro to learn how it works, just like for any unfamliar function that we want to use.
As suggested above a way to distinguish them from function calls could make it even more clear to the reader what is going on. Perhaps, simply the convention that any macro that is not builtin to Go, should be defined in a package named macro.  In the source code then the call will look like macro.Foo(), which makes it pretty obvious what is going on.
As @urandom suggests, there are many languages with hygienic macros. We can take a look at large projects in such languages and evaluate the benefits and downsides of macros through them. One example might be Mozilla Servo, which is written in Rust and defines quite some macros: https://github.com/servo/servo/search?q=macro_rules!&unscoped_q=macro_rules!. In that project, the macros are not well documented, but even just by their name, it is often quite obvious what they do, and they cut back on large amounts of boilerplate.  There are many other possible projects in other languages as well we could look.

I agree this, I write a tool use golang AST tree to generate concrete code. If have hygienic macros,I think it will more easy to use and more easy to write

I cheked @fisedee 's tool and his experience with Go is very common. I had a similar experience. It goes a bit like this:

Write everything manually, leading to a lot of boring boilerplate copy pasted everywhere.
Switch to libraries that use interface{} and reflection. These are much more convenient, but have mediocre performance and no type safety, leading to many difficulties.
Switch to code generation using go:generate + a custom tool. Now, we have better performance and type safety, but it comes at the cost of having to use an external tool. These tools often use text/template as a template language for generating go from. While that is OK, now it means that go programmers have to now both Go and text/template's language, and get all the downsides of having to use a text based preprocessor.

What we need is:
4. Use hygienic macros. Like this we can generate code directly in the Go compiler itself, without the need for external tools or preprocessors, and without having to learn additional template languages.

I added a link to this issue on the https://github.com/golang/go/wiki/Go2GenericsFeedback, because hygienic macros are an alternative to generics as well.
I think hygienic macros would be better for go than generics, because experience from other programming languages shows that hygienic macros have all the power of generics, and are furthermore relatively easier to understand, implement and use. Furthermore, they tend to work similarly between different programming languages, making it a "portable skill", which cannot be said about the highly different way in which generics are implemented. Finally hygienic macros are a well understood feature, with well understood implementation algorithms available, making them far less experimental than the dozens of various generics proposals that have been floating around.

What does a macro-defined type look like? Or a macro method?

I'm not proposing any syntax yet, but we can take a look at other languages that have hygienic macros, like Rust, and it looks a bit like this:

Macro defined method in Rust: https://github.com/servo/servo/blob/799490a02e9bea575bf34c39f045ef0883539f05/components/script/dom/macros.rs
Macro defined type in Rust: https://stackoverflow.com/questions/41391522/how-to-use-a-type-ty-within-a-macro-to-construct-a-struct-instance-in-rust

Altough admitted, Rust combines generics and macros, I feel that with powerful enough hygienic macros, generics will not be needed.

@beoran, @networkimprov
To implement generics through macros you could define a defining macro along with an instantiating macro.
Something like:
defineGeneric!(T) {
    func foo(a T) {
      // ...
   }
}

// At call-site
myFoo := instantiate!(int, foo)

This would be similar to C++ templating system.
This is a `80% solution' though because the type system would have no idea about parametric polymorphism.

@jsjolen Yes, although I'd make it so that the macro is "typed", i.e. the definition specifies the AST types that the macro takes as  arguments, and also specifies the AST type of the object that must be injected at the point of invocation. Like this, macros don't only become hygienic but also meta-type safe.
Admitted it is an 80% solution, but Go is the language of good 80% solutions that work well with each other. Hygienic macros are orthogonal to interfaces and other Go language features, something that cannot be said of generics, where concepts such as contracts have to be introduced to make a distinction with interfaces.

I did this as an example in #32620 and #32811
define returnIf(err error, desc string, args ...interface{}) {
	if (err != nil) {
		return fmt.Errorf("%s: %s: %+v", desc, err, args)
	}
}

func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	returnIf(err, "Error opening src", src)
	defer r.Close()

	w, err := os.Create(dst)
	returnIf(err, "Error Creating dst", dst)
	defer w.Close()

	...
}

Also, I dunno, but maybe also add something extra to clarify its a macro usage and not a function call?
func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	:returnIf(err, "Error opening src", src)
	defer r.Close()

	w, err := os.Create(dst)
	:returnIf(err, "Error Creating dst", dst)
	defer w.Close()

	...
}

Yes, a way to mark macros is desirable. However, macros will be defined in packages, so the package name will need to be prefixed when using the macro. So in stead of : or ! As a prefix or suffix, as I said before, just the convention that the package must be named macro is enough. Then above, :returnIf becomes macro.returnIf  which is longer but even more clear.

@beoran
How would importing macros from different packages work in that case?

Like it works now, for packages with the same name, by specifying the name to import. Something like
import (
  "builtin/macro"
  macro2 "github.com/chillance/returnif/macro"
)

func useMacro(){
    macro.try(foo())
    macro2.returnIf(foobar(), "error")
}

Maybe the syntax could be based on text.Template, the users are familiar and is very powerful with conditions and loops
define returnIf(err error, desc string, args ...interface{}) {
	if ({{$err}} != nil) {
		{{if $args}}
		return fmt.Errorf("%s: %s: %+v", {{$desc}}, {{$err}}, {{$args}})
		{{else}}
		return fmt.Errorf("%s: %s", {{$desc}}, {{$err}})
		{{end}}
		}
	}
}

While text/template is very powerful, it is definitely not Go language but
it's own little language. I didn't decide on syntax yet, but I would like
it to be as close as possible to normal Go.

I totally agree with @ianlancetaylor ; one of the great features of go is that it's a carefully defined small set of features that have reliable behaviour, which makes it easy to read and understand. Adding user defined control flow via macro's is a big no for me, since it would let you define different behaviours that people may or may not expect, not to mention the added complexity of dealing with the macro's themselves.

Macros are the worst thing in C and C++. You literally stop writing the language and start writing some other language that is defined by whoever decided they didn't like typing out some boilerplate.  When I was writing those languages I was literally just copying and pasting how other people wrote macros because they were so awful to understand.
I like that any random line of Go code I look at, I can instantly understand its computational complexity purely based on the text in this file.  The most you have to wonder about is if append will have to reallocate an array.
There's never a time when I want to look at a line of code and have to wonder if it's the first part of an if statement, or if it has a return statement inside, or if it's actually a loop....  and then go look at the content of the macro and see some weird other language that isn't go...  No no no, 1000x no.

@natefinch
The proposal here isn't about C style macros, so I'm not sure how relevant your first part is. As for your second part, besides a return statement, the rest would be exactly the same as a regular function. What your are suggesting is that functions be removed then?

There's very little proposal here, since there's no syntax, so I just went off the macros I'm familiar with. You can't say it's not like C macros if you don't actually say what it is like. Sure, it's hygenic, so it won't clash with existing variable names, but that doesn't mean it wouldn't have all the other problems of C-style macros, i.e. you end up with functions that look like this:
func (h *handler) handleUserPOST(w http.ResponseWriter, r *http.Request) {
    DO_SETUP(h, w, r)
    CHECK_AUTH(h, r)
        // log to sentry
        h.sentry.AuthFail(r)
        AUTH_FAIL(w)
    AUTH_FINALIZE(h)
   // now actually do user post stuff
}

Do note that the point here is also to discuss what to do, so we can agree on something that is better than what is macros in other languages. I don't think it's wise to dismiss macros because it has negative impact on other languages. The reason to use macros and why I pasted my code is for the discussion to take place where macros can be made better. This is how Go was created. Take good parts from other languages and make it simpler and easier in Go.

@natefinch
The situation which you describe, where I have to work in a weird language that isn't Go is part of my daily work. I have to use text/template, which isn't Go, to generate my go code, because that is currently the best solution for type safety and performance. Hygienic macros with a correct syntax would allow me to get back to programming Go.
As for your example, this is how it probably would look now, in well factored code:
func (h *handler) handleUserPOST(w http.ResponseWriter, r *http.Request) {
    err := doSetup(h, w, r)
   if err != nil {
       return err // or handle the error somehow.
    }
    err = checkAuth(h, r)
    if err != nil {
         return err
    }
     // log to sentry
     h.sentry.AuthFail(r)
     err = authFail(w)
     if err != nil {
         return err
     }

     err = authFinalize(h)
     if err != nil {
         return err
     }
     // now actually do user post stuff
}

So you still need to lookup what the called functions do to understand what this function is doing. Macros don' t add much more of a difficulty, apart from the fact that they might return. You will have to read the macros to see if they do, which is not more difficult that reading functions to see what they do. Furthermore, thinking about implementation, perhaps we could mandate that a package defines macros can only do that and nothing else, to create a clear separation.
More likely than the example you posted, with macros it would look like this:
import error_macro "example.com/error/macro"

func (h *handler) handleUserPOST(w http.ResponseWriter, r *http.Request) {
   error_macro.Try(doSetup(h, w, r))
   error_macro.Try(checkAuth(h, r))
   h.sentry.AuthFail(r)
   error_macro.Try(authFail(w))
   error_macro.Try(authFinalize(h))
     // now actually do user post stuff
}

Which is more explicit that the current try() proposal. And you'll be able to look up the documentation and definition of the macro easily with go doc example.com/error_macro Try, or through your IDE, something you can't do with C.
As @Chillance says, I don't propose C macros like or C++templates. I think that thanks to all comments above I can home in on the desirable features of  macros  a bit more finely, namely:

They must be hygienic
They must have a definition syntax that is a Go like as possible.
They must be type checked at compile time, both the parameters and the body.
A macro invocation expands to the syntax tree of it's definition with the macro parameters expanded and replaced.
In the call site they will be prefixed by the package name, or maybe also with some kind of sigil like ! or : to make it clear that a macro is invoked.
Macros may only be defined in separate macro packages that may only contain macro definitions.

@natefinch
Indeed, one of the pain points of C style macros that are more or less text expansion, is that expanding a macro might leave you with an invalid syntax. I assume this is what at least I've if the things you wanted to show in your example, and is something I've seen a lot in C.
I'm hoping that if Go ever gets macro support, said macros will not be just some text substitution, and will always produce valid syntax when expanded.

@beoran That handleUserPOST looks rather nice when using macros, don't you think? :) So, with the macro you can get the code smaller and using less rows. If needed, one can always take a look at the macro to understand what it does, and then you know what it does for all the rows.

I've already expressed my reservations about this proposal.  I'm skeptical that this will be adopted.
That said, I don't see how we can fairly evaluate it without a syntax.  Without a syntax we can't tell how hard or easy it is to use or implement, we can't tell what complexities might arise when using it, we can't tell what existing code would be simplified.  I'm going to mark this proposal as being on hold until there is something more complete to examine.
Thanks.

I'd love to have macro in Go. One thing it could solve for me is duplication of code when casting back objects store in a cache as interface{} back to their original type, i.e.:
https://github.com/sylr/prometheus-azure-exporter/blob/v0.5.0/pkg/azure/batch.go#L85-L91
https://github.com/sylr/prometheus-azure-exporter/blob/v0.5.0/pkg/azure/batch.go#L132-L138
https://github.com/sylr/prometheus-azure-exporter/blob/0.5.0/pkg/azure/batch.go#L181-L187
So far that's the only time I felt the urge to have macros and although I would take go over rust any day for code readability reason (far too many symbols for my taste), I'm really envious of rust's macro system.
I'm not very fond of the idea of having to segregate macro in their own package though. I'd like to be free to define right next to where it would be useful.
Would be nice to be able to make them public or private the same way we do with func (first letter capitalization).
So what now ? Here a cheap attempt at porting some of https://doc.rust-lang.org/stable/rust-by-example/macros/designators.html examples go style
macro createFunc($funcName ident) {
	func $funcName() {
		fmt.Println("You called: %s", fmt.__Stringify($funcName))
	}
}

// Not sure about $x.type
macro FindMin($x ...expression) ($x.type) {
	var min $x.type

	for _, y := range $x {
		if min == nil || y < min {
			min = y
		}
	}

	return min
}

func main() {
	macro CreateFunc(foo)
	macro CreateFunc(bar)

	foo()
	bar()

	x, y, z := 2, 0, 4
	i := macro FindMin(x, y, z)
}

@sylr Almost like it's also generics. :)

@ianlancetaylor The reason I did not come up with a syntax yet was exactly because I wanted to test the waters first. If you feel that the feature of hygienc macros itself will be rejected then of course I don't have much incentive to propose a syntax.
On the other hand, whilst the response to this proposal has been modest, in balance it has been more positive than negative, so for the benefit of the people who encouraged me, I will go to the next step and also propose a syntax. Please give me some time to consider which syntax would be best.

I wouldn't expend the time on the basis of 20-some upvotes. You already heard that the Go team isn't interested.

@beoran If your idea of macros rely on built-in go functions then I withdraw my interest.

@beoran As I said, I'm skeptical that this will be adopted.  If you don't want to waste your time devising a syntax, and want to withdraw this proposal instead, that seems like an appropriate choice.
But I'm just one person.  I'm not making the decision here.  And the other things I said are also true.  A proposal like this cannot be fairly evaluated without details of the syntax and a clear understanding of the power of the macros.

Well, I'm not going to quit without trying, so I will work on designing a syntax and specify the exact possibilities I have in mind. I started looking at it but admittedly, it is harder than I thought, so it will probably take a while before I have something that can be reviewed. If anyone else would like to make some suggestions in the mean time,  they would be welcome.

If you have time to burn, use it to build a following. You'll need ~1,000 supporters I'd guess, enough so that "I can has macros?" starts appearing in the annual surveys.
See also Zig, which offers "comptime" blocks -- code that executes at compile time.

@networkimprov I'm not sure if supporters will actually help. What Go team wants (or expects) is a proposal that can help improve the language in the vision that they carry. Even now, when you look at the language, there are dozen of features that the authors could have added (methods on slices come to mind, or data structures like set et al) but they instead elected to keep the very minimum of features that they thought were necessary.
Same more or less goes macros. Just because it's a thing that solves a problem doesn't mean it also aligns with the vision of Go. There are many languages that already have these features, yet a lot of people prefer Go to those languages (this is just conjecture on my part, as I prefer Go over more advanced languages)

The reason for the try() proposal is that, year after year, ~5% of survey respondents identified error handling as a problem. Then, ironically, the community decided that proposal didn't align with the vision of Go :-)
Supporters, and detractors, count.

Yes, and I think it shows that Go now become so widely used that it will be difficult to have everyone agree on how to do error handling. Now try() is just a macro, but it's a one off macro, implemented by the language itself. I think it would be better for the language to have it's own macro system in stead, so everyone can define the error handing, and other similar things, like, e.g. cond() they like.
Go has a certain vision, but in the end practicallity often won out over purity. Look, e.g. to struct tags, or //go: pragmas. Even when hygienic, macros are not a "pure" solution, but they are definitely practical, moreso than ad hoc solutions like try().
If this issue is not accepted, then I will probably end up writing a preprocessor, so devising a syntax is useful anyway. So, in stead of arguing the social issues, I'd like to focus on that in stead. If we work together we might come up with a great syntax for this issue.

@beoran I think that is well said and also why I posted my little quick code sample above. To get syntax and discussion started. We make the macro work the way we want it to work in Go. Possibly use inspiration from other languages, and also what we don't want to do from other languages. Think outside the box.

I think that first I'd like to think about the syntax for invoking a macro. From that we might then understand how macros should be defined.

I propose that the syntax for macro expansion is identical to that of a function call, without a marker, however, as usual, for functions, with a package prefix, but using '[]' in stead of () for the argument list.  So a macro named Foo defined in a package named macro will be called as macro.Foo[arg1, arg2,  ...].  This makes it easy to distinguish macro calls from function calls, and is backwards compatible as currently such a statement leads to a syntax error'.

A macro expansion may be called at the top level of a file, or inside a function. The expansion of the macro is an ast.Node which is inserted at the point of expansion. Macros are expanded at compile time, so their arguments must be fully determinable by the compiler at compile time.

As we can see from the several examples macro above, a macro should be able to take several arguments to be powerful enough to use namely:
3.1. An expression, to allow for things like Try().
3.2. A type.
3.3. An identifier or variable.
3.4. A constant string.
3.5. A constant numeral (int or floating point).
3.6. A block of code.
3.7 ... Anything else I forgot?

Please discuss! :)

How would you distinguish between macro expansion and map/slice indexing?

The arguments are comma separated, while slicing uses : .  Only for a single integer argument there could be some confusion like macro.Foo[1]. But yes, maybe that could make it hard to implement it for the parer, so a better suggestion would be welcome.

Not sure I like the [] usage to distinguish a macro from a normal function call. It might look like an array/map access and be a bit confusing. Especially if you are coming from php/javascript. :)
@beoran What are your thoughts on my idea of prepending with something like a colon like this:
    math.Somefunction()
    :macro.SomeMacro()

to distinguish from a function call? Skimming the code, I kinda like the idea of something prepended like that as it makes it rather clear and easy to see what is a normal function call and a macro usage.

Obviously doesn't have to be a colon, although I don't think this will be confused with labels. Maybe use |?
    math.SomeFunction()
    |macro.SomeMacro()

or ~?
    math.SomeFunction()
    ~macro.SomeMacro()

or \?
    math.SomeFunction()
    \macro.SomeMacro()

Yes, I admit the [] idea is not going to work. A prefix, then would a be nice marker, but it should be backwards compatible, so any of ^!|, which are already accepted by the Go lexer, cannot be used.  One of \#$~could work, since they now give an invalid character error, and they are in the ASCII range, and available on may keyboards. Any one of them would be fine, but I'll just arbitarily go with the \ since that subjectively looks nicest to me, and not to keep bikeshedding a relatively minor issue.
So now, the design becomes:

I propose that the syntax for macro expansion is identical to that of a function call, however, prefixed with a \ marker. So a macro named Foo defined in a package named macro will be called as \macro.Foo(arg1, arg2, ...). This makes it easy to distinguish macro calls from function calls, and is backwards compatible as currently the use of a \ statement leads to a invalid character error.

A macro expansion may be called at the top level of a file, or inside a function. The expansion of the macro is an ast.Node which is inserted at the point of expansion. Macros are expanded at compile time, so their arguments must be fully determinable by the compiler at compile time.

As we can see from the several examples macro above, a macro should be able to take several arguments to be powerful enough to use namely:
3.1. An expression, to allow for things like Try().
3.2. A type.
3.3. An identifier or variable.
3.4. A constant string.
3.5. A constant numeral (int or floating point).
3.6. A block of code.
3.7 A function literal.
3.8 ... Anything else I forgot?

Next would then be how to define a macro. Dine we are already taking \ as a prefix for macro expansion, why not then also use the same prefix for all compile time statements? This would also make it easy to implement this proposal as a preprocessor.
So, a macro definition would then be something like \define Foo(arg1 argType2, arg2 argType2) { .... }.

Although I generally like hygienic macros, I strongly oppose their addition to Go, on the grounds that they harm the readability of code and thereby the ease of its reuse.
As with many proposed language features, macros are understandably appealing to the writer of code, whose effort is saved by their application. Even medium-size programs often contain meta-patterns not easily represented in the syntax (e.g., type dispatch) and therefore feel tedious to write out longhand. For the reader, however, who does not already understand the code, I have found macros make the learning process much worse. I think this depends less on whether or not the macro expander is hygienic, and more on whether the authors have moved on to bigger and better things.
For obvious reasons I can't describe any direct experience with macros in Go, but a couple decades ago I spent about six months doing some heavy-duty maintenance on a large (~20K lines or so) Common Lisp codebase.  It made heavy and very clever use of macros throughout. As you probably know, CL macros are not hygienic by default, but that didn't really matter in this case: The authors made no extensive use of captures, and had carefully inserted gensyms or used naming conventions to avoid problems. For the reader, however, their extensive macrology was disastrous: The program relied on an elaborate library of control-flow constructs—via macros—riddled with subtle and poorly-documented assumptions. It took me nearly a month to gain a rudimentary working understanding of the program's architecture, and much longer to become productive in it. My knowledge of Common Lisp was largely useless in this research: Beyond the bits you could learn in a ten-minute reading of the Hyperspec, this program was effectively a new language of its own.
I acknowledge that my anecdote does not prove anything: You may justly argue that Common Lisp is not Go, and that perhaps I am not the brightest candle in the menorah, and that Lisp programmers are well-known to fetishize cleverness, and that Go programmers would only use such a facility judiciously and with taste. The first three, at least, are probably true. I've had to read and maintain enough complex projects, however, that I do not believe we should privilege the convenience of the writer of the code (typically one person, or a small handful) over the needs of the reader of the code (often many people, over a long period of time).
One of Go's virtues is that it is boring.  The obvious response is that "repetitive boilerplate is also hard to read". That is true, but it has also been my experience that, the majority of cases where there's a lot of boilerplate (and where macros would be useful) can be served as well—and maybe better—by writing a little code generator in the original (boring) language.
Arguably a macro is just a code generator: But it's an implicit one. With explicitly-generated code, the relationship is clear during the build process, and the reader can clearly see the boundary between the code that was "generated by X from Y", and the parts a human wrote out longhand. A minor tweak to an innocent-looking data parameter is less likely to destroy the entire build.
It's easy enough to go look up the provenance of generated code later, if you need to. I have found that archaeology on with the language equivalent of gcc -E or MACROEXPAND to be much more tedious. Plus: It slows down the compiler quite a bit, in ways that can surprise someone who didn't write the macro. And: It makes diagnostics much harder to surface in the UI (a problem familiar to anyone who's built tools around clang).
In summary: While the benefits of macros to the writer of a program are obvious, their costs to the reader seem too great to consider. I do not believe the benefits are sufficient to justify working around the costs.

@creachadair I see where you are coming from but how about thinking of ways to make macros more "boring" for Go? This is also why we are having this discussion, so we can figure out proper ways to do macros. "Anything that can be used, can be missued." is a quote someone said too that came to mind here. Meaning, you can use macros to make things harder for yourself, but that goes with anything really. And, if macros was a bit "dumb down" for Go, it might actually be more harder to complicate things with macros and push using macros for simpler and less convoluted cases.
One thing that could make it annoying would be if macros were overused. For cases like implementing "try" using macros, macros could be quite neat. You learn how that works in your code, and then every time you see it you know what it does (check err and return something if not nil). Obviously, if macros were overused, you would have to keep more in your head, which could make code less readable and annoying with more overhead in your head. But again, this comes down to just using macros for cases where it makes more sense. And use more rarely compared to functions I suppose.

Yes, I'd agree that certainly flow changing macros should be used sparingly, and documented well. But use does not prevent abuse, and perhaps we can think of good ways to limit the putential for abuse.
As for using code generators, that's what I use all the time in my day job. As I stated above, these are normally based on text/template, and the experience is not so comfortable because than stellar, because text/template is not Go, but it's own little language, and does no syntax checking of the Go code it generates. I modify the template, run the generator, then run the compiler and ... I get an error if I made a mistake in the template. A macro system in Go would alleviate that problem.

As for using code generators, that's what I use all the time in my day job. As I stated above, these are normally based on text/template, and the experience is not so comfortable, because text/template is not Go, but it's own little language, and does no syntax checking of the Go code it generates. I modify the template, run the generator, then run the compiler and ... I get an error if I made a mistake in the template. A macro system in Go would alleviate that problem.

It seems clear that you could benefit from a better code generator tool. What is less obvious (to me) is why macros would be the correct solution to this problem, as opposed to (say) a library with better support for the output language—perhaps based on the go/parser package, since it sounds like you are maybe generating Go—with support for writing and checking Go syntax, formatting, type-checking, etc.
It would take some work to get this right, but if Go is the output language much of that work is already well-supported by existing libraries, and a well-designed API for generating Go could be a nicely reusable package. I don't think this needs to be baked into the core syntax of the language, though, which affects all users of the language rather than only those who need to generate Go code.

Yes, I am generating Go. The problem is that I have to use certain tools, such as gqlgen where I don't get to choose the language that is used for the templates. The reason why text/template is used so widely to generate Go code is because it is part of the standard library.
As an alternative to this proposal, perhaps a go/template library could be implemented that works as you suggest, but then it should probably become part of the standard library, otherwise it will not be widely used. That's why I still think it would be nice to have macros in the language in stead of as an external tool. It makes the feature more widely accessible.

Seeing the latest progress with generics, I would like to see what are the results of this endeavour. If successful it could reduce the need for macros.


context directory should not be passed when runtime is changed

Fixes

https://issues.redhat.com/browse/HAC-3203
Description

Create button is not enabled again after switching the runtime from Other to Basic Quarkus when context directory is set in the first step.
Type of change

[x] Bugfix

Screen shots / Gifs for design review

https://user-images.githubusercontent.com/9964343/220329109-9eb71a6f-e0e8-4b1e-82d5-f718fe133e7a.mov
How to test or reproduce?

use https://github.com/RedHat-EMEA-SSA-Team/end-to-end-developer-workshop repo while creating components and set the context directory to /labs.

Switch the detected runtime of a component from Other to  Basic Quarkus component.

Unit tests:
  RuntimeSelector
    ✓ should set the context directory when the provided repo is matching with sample runtime repo (59 ms)
    ✓ should not set the context directory when the runtime is changed (48 ms)

Browser conformance:

[x] Chrome
[x] Firefox
[x] Safari
[ ] Edge

cc: @rohitkrai03

/retest

/retest


Domain Join issues fixed

Got two errors while deploying to Active Directory joined host pool
The first error was :
Unable to process template language expressions for resource '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/XXX/providers/Microsoft.Compute/virtualMachines/XXX-02/extensions/DomainJoin' at line '1' and column '7550'. 'The language expression property 'OUPath' doesn't exist, available properties are 'DomainType, ADOUPath, DomainName, DomainJoinUserName'.' (Code: InvalidTemplate)
After changing the "OUPath": "[[parameters('DomainJoinObject').OUPath]" to "OUPath": "[[parameters('DomainJoinObject').ADOUPath]"
Got the following error
Unable to process template language expressions for resource '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/XXX/providers/Microsoft.Compute/virtualMachines/XXX-02/extensions/DomainJoin' at line '1' and column '7550'. 'The language expression property 'UserName' doesn't exist, available properties are 'DomainType, ADOUPath, DomainName, DomainJoinUserName'.' (Code: InvalidTemplate)
changed "User": "[[format('{0}\{1}', parameters('DomainJoinObject').DomainName, parameters('DomainJoinObject').UserName)]",  to "User": "[[format('{0}\{1}', parameters('DomainJoinObject').DomainName, parameters('DomainJoinObject').DomainJoinUserName)]"
Also changed the CodeDeploy.md where TemplateUri should be used instead of TeamplateFile

@microsoft-github-policy-service agree


Exporting A4 format document doesnt export proper A4 size (big difference)

As in the title

Using a specific example? Exporting in what format, using which browser?


rebase.sh: don't fail if last_rebase.sh didn't change

Addresses scenario when last_rebase.sh and git commit exits with 1 because there were no files to commit
Switched to a new branch 'rebase-4.12.0-0.nightly-2022-12-23-190941'
## updating last_rebase.sh
On branch rebase-4.12.0-0.nightly-2022-12-23-190941
nothing to commit, working tree clean
Script exited with error.
Script exited with error.

/cc @ggiguash

/hold

/unhold

/lgtm


Issue with react-native 0.16.0

Hi - great work, but seems to have an issue with react-native 0.16.0 - hangs when transforming (possibly babel 6 incompatible)

There is a PR that addresses the 0.16.0 upgrade.  I was away for a few days but will start looking at this over the next few days.

Many thanks, much obliged!

To use it with RN 0.16 i removed the .babelrc file in react-native-navbar module and modified the navBar.js file (as in the PR).
Build is OK, Transform is OK
But I think that navLeft and NavRight properties for custom nav component (pass to Route) are broken.

Now that I have time I'll be rounding this out for the latest RN sometime this week.  Thanks everybody!

Pulled in the PR


Playground/Console Documentation Needs to be Updated to v3

What is the current behavior?
Playground/Console Documentation Needs to be Updated to v3. This has been in progress for a couple of weeks, I'm just not super familiar with ELM (the language used for the backend) so the progress is slow.
Steps to reproduce

To make it faster to diagnose the root problem. Tell us how can we reproduce the bug.

Expected behavior

What would you expect to happen when following the steps above?

Please tell us about your environment

We want to make sure the problem isn't specific to your operating system or programming language.

Operating System/Version: Windows 10
Language: [all | TypeScript | Python | PHP | etc]
Browser: Chrome

Other information

Anything else we should know? (e.g. detailed explanation, stack-traces, related issues, suggestions how to fix, links for us to have context, eg. stack overflow, codepen, etc)

The playground-ui PR is ready for review.... finishing up the console-ui PR.

The console-ui PR is up for review internally now

Playground UI changes have been merged

The Console UI change has been merged. We should see this updated next time the console and playground UI get deployed.


Callback url limitation

self.callback_url = 'https://{0}:{1}'.format(
            self.local_server_settings[0],
            str(self.local_server_settings[1])
        )

in salesforce_requ:ests_oauthlib has stricted the callback url to have the https://domain:port format. so urls like https://localhost:4444/oauth/_callback are not possible?

@hossein761 in https://github.com/SalesforceFoundation/salesforce-requests-oauthlib/commit/2683cb8e2a0e561644e1d84b41737bb3b6d8077e I updated this section of salesforce_requests_oauthlib to properly handle non-standard ports.  It should also be clearer now that any url path you want is supported.  (I often use urls like your example!)  If you try something and it doesn't work, please file a new issue or follow up here.


can't resolve consul-1.consul.$(NAMESPACE).svc.cluster.local when join.

I try to follow the guideline to install consul in kubernetes 1.7.5, but it is failure due to can't resolve the hostname consul-0.consul.$(NAMESPACE).svc.cluster.local, I use default namespace
kubectl logs consul-0
...

2017/11/01 12:48:58 [INFO] consul: Adding LAN server consul-0 (Addr: tcp/<IP_ADDRESS>:8300) (DC: dc1)
2017/11/01 12:48:58 [INFO] agent: Started DNS server <IP_ADDRESS>:8600 (udp)
2017/11/01 12:48:58 [INFO] agent: Started DNS server <IP_ADDRESS>:8600 (tcp)    2017/11/01 12:48:58 [INFO] agent: (LAN) joining: [consul-0.consul.default.svc.cluster.local consul-1.consul.default.svc.cluster.local consul-2.consul.default.svc.cluster.local]
2017/11/01 12:48:58 [INFO] agent: Started HTTP server on [::]:8500

2017/11/01 12:48:58 [INFO] agent: Retry join is supported for: aws azure gce softlayer
2017/11/01 12:48:58 [INFO] agent: Joining cluster...
2017/11/01 12:48:58 [WARN] memberlist: Failed to resolve consul-1.consul.default.svc.cluster.local: lookup consul-1.consul.default.svc.cluster.local on <IP_ADDRESS>:53: no such host
2017/11/01 12:48:58 [WARN] memberlist: Failed to resolve consul-2.consul.default.svc.cluster.local: lookup consul-2.consul.default.svc.cluster.local on <IP_ADDRESS>:53: no such host
2017/11/01 12:48:58 [INFO] agent: (LAN) joined: 1 Err: <nil>
2017/11/01 12:48:58 [INFO] agent: Join completed. Synced with 1 initial agents
2017/11/01 12:49:04 [WARN] raft: no known peers, aborting election

Are there anything I missed to configure in kubernetes or I need extra component there.

I made mistake, I forget to create service in advance: kubectl create -f services/consul.yaml
other thing related to my problem

need prepare 3 PV storage in k8s for 3 consul pods

For me everything worked fine where I recreated it, consul members refused to join the cluster, I tried creating services first but it didn't help. @larrycai I followed this link https://testdriven.io/blog/running-vault-and-consul-on-kubernetes/ to create a vault-consul cluster in kubernetes


all: Add support for version command

When doing version it will display the commit and version
Update gitignore with the new files generated by the make
Update the display for when the args are less than 2
Use a util file to store the Version and Commit Hash
Fixes: #477
Signed-off-by: Jordan Jackson<EMAIL_ADDRESS>

With the changes being made in the refactor PR, I will wait before making further changes for that to be merged
Depends on: https://github.com/confidential-containers/cloud-api-adaptor/pull/329

I have updated the code with the latest changes. My plan with the version check was to implement it like:
/usr/local/bin/cloud-api-adaptor version
cloud-api-adaptor, version: unknown, commit: <current-commit-hash>
go: <go version>

I originally thought that adding the code to the top of the function using os.Args that was used before would allow the use across all providers. (Not just the ones moved to the new refactor)
In regards to the current failures, i'm looking into a different way that does not use the make file to generate a version file that gets used. Or atleast uses a file that has the variables defined as unknown.

Thank you for updating the patch.
 Could you update your commit message? Note that at least one of commits needs to have a Fixes line.

I have updated the PR to match the changes you have requested, and got the ldflags working.
This is now the output, without the generated file steps from the previous commit.
/usr/local/bin/cloud-api-adaptor version
cloud-api-adaptor, version: unknown, commit: 3afd0f5bd1bc338dc44213ef300ed3bc05a00b32
go: go1.18.5

@Jordan9500 could you rebase to resolve the conflicts in main.go? Cloud providers for azure and libvirt have been merged.

I have rebased with the latest changes


[3.x] Several minor LSP  issues

Godot version
3.x branch at 8d0b2edfc25dec38fff36e4b198753e570cd4ec9
System information
Arch Linux
Issue description
This ticket is following up on https://github.com/godotengine/godot/issues/53238#issuecomment-931225975. On that issue, #53238, it was determined that one of the underlying causes that made the engine to crash was a buggy LSP client.
For a while now I've been stumbling upon strange errors that seem to be caused by a buggy LSP client, in this case Vim-ALE, and I'm bringing this up in case there are relevant changes that should be made to Godot.
Most of my tests are on 3.x. I am unsure if the issues below affect the master branch.
The errors described below are also not shown in the editor, but in an external terminal emulator that is attached to Godot.
Steps to reproduce
All the cases below assume the user has opened the engine using godot -e at the path where project.godot is at.
Case 1
Hovering over the extends in a GDScript file generates the following LSP event:
{"method": "textDocument/hover", "jsonrpc": "2.0", "id": 2, "params": {"textDocument": {"uri": "file:///home/wilson/game_development/godot/godot-template/src/addons/tiled_importer/custom_property_manager_for_tilesets_template.gd"}, "position": {"character": 0, "line": 1}}}

which generates the following Error:
ERROR: Method failed.
   at: _determine_inheritance (modules/gdscript/gdscript_parser.cpp:5423)

Case 2
Hovering over an empty line generates the following LSP event:
{"method": "textDocument/hover", "jsonrpc": "2.0", "id": 2, "params": {"textDocument": {"uri": "file:///home/wilson/game_development/godot/godot-template/src/addons/tiled_importer/custom_property_manager_for_tilesets_template.gd"}, "position": {"character": 0, "line": 1}}}

Which generates the following error:
ERROR: Index p_position.character = 0 is out of bounds (line.size() = 0).
   at: get_identifier_under_position (modules/gdscript/language_server/gdscript_extend_parser.cpp:490)
ERROR: Index p_position.character = 0 is out of bounds (line.size() = 0).
   at: get_identifier_under_position (modules/gdscript/language_server/gdscript_extend_parser.cpp:490)

Case 3
Opening a GDScript file outside of the Godot project generates a ton of events, but the following seems to be the important one:
{"method": "textDocument/didOpen", "jsonrpc": "2.0", "params": {"textDocument": {"uri": "file:///tmp/outside_of_any_project/Node2D.gd", "version": 1, "languageId": "gdscript3", "text": "extends Node2D\n"}}}

And right after you'll see the following error:
ERROR: Condition "err" is true. Returned: err
   at: load_source_code (modules/gdscript/gdscript.cpp:775)
ERROR: Cannot load source code from file 'file:/tmp/outside_of_any_project/Node2D.gd'.
   at: load (modules/gdscript/gdscript.cpp:2177)
ERROR: Failed loading resource: file:/tmp/outside_of_any_project/Node2D.gd. Make sure resources have been imported by opening the project in the editor at least once.

Minimal reproduction project
A GDScript template will do:
extends Node2D

func _ready() -> void:
	pass

CC @Razoric480

I've tested the steps above with VSCode in Linux and it doesn't seem like these minor issues are caused by a buggy LSP client this time.

Two PRs have been submitted to fix the issue - 2 and 3 exist on 4.0 and so should be cherry-picked in #53308, and 1 only exists in 3.x and is fixed by #53309.

Fixed by #53308 and #53309.


Add throttling option to sqs server

By returning a ErrThrottleServer,
the sqs server can be put to sleep
for the duration passed within the error.
This is useful in cases where receivers
are calling API's which can be rate limited.

Looks like there's a small linting issue @Elyunge


chore: audit the non-audited superblocks

Checklist:

[X] I have read and followed the contribution guidelines.
[X] I have read and followed the how to open a pull request guide.
[X] My pull request targets the main branch of freeCodeCamp.
[X] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Went through crowdin, found some certs that were fully translated.

https://github.com/freeCodeCamp/freeCodeCamp/actions/runs/6112785474/job/16591411884?pr=51431#step:9:2260
FAIL config/superblocks.test.ts
  ● firstNotAuditedSuperBlock › should return a SuperBlock when language is 'chinese'

Might be related to the conflicts. Will take a look.


Publish Code Coverage Results: summary access denied

Troubleshooting
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
Environment

Server - Azure Pipelines or TFS on-premises?
Azure Pipelines

If using Azure Pipelines, provide the account name, team project name, build definition name/build number:

    Account name: Preenr
    Project Name: Preenr MVP
    Build Name: Preenr.Platform - PR Build
    Build ID: 1096

Agent - Hosted or Private:
Hosted

If using Hosted agent, provide agent queue name:
Default

Issue Description
I've created a DockerImage that run reportgenerator to create a code coverage report using these commands in an sh file:
echo "RunTestCoverage.sh: Running test coverage..."
dotnet test "Platform.Tests.sln" "--logger:trx;LogFileName=/results/coveragerun-test-results-core.xml" "/p:CollectCoverage=true" "/p:CoverletOutputFormat=cobertura" "/p:CoverletOutput=/results/coveragerun-coverage-results-core.xml"
echo "RunTestCoverage.sh: Running report creation..."
reportgenerator "-reports:/results/coveragerun-coverage-results-core.xml" "-targetdir:/results/ReportGenerator" "-reporttypes:HtmlInline_AzurePipelines" "-sourcedirs:/src/"

This works great and outputs the following directory:

However when I now try to publish these test results with VSTS:

I keep running into this error:
2018-12-19T15:40:33.4676645Z ##[warning]Error occurred while publishing code coverage files. Error: Access to the path '/home/vsts/work/1/a/tests-results/ReportGenerator/summary1096' is denied.

For some reason it seems to look for a summary1096 file which does not exist. How do I create this file with ReportGenerator? Or is this more of a VSTS issue where it should simply skip this file and just upload the whole directory?
Task logs

2018-12-19T15:53:25.7834550Z ##[debug]Evaluating condition for step: 'Publish code coverage from $(Build.ArtifactStagingDirectory)/tests-results/coveragerun-coverage-results-core.xml'
2018-12-19T15:53:25.7835161Z ##[debug]Evaluating: succeeded()
2018-12-19T15:53:25.7835408Z ##[debug]Evaluating succeeded:
2018-12-19T15:53:25.7835756Z ##[debug]=> True
2018-12-19T15:53:25.7836082Z ##[debug]Result: True
2018-12-19T15:53:25.7837109Z ##[section]Starting: Publish code coverage from $(Build.ArtifactStagingDirectory)/tests-results/coveragerun-coverage-results-core.xml
2018-12-19T15:53:25.7841019Z ==============================================================================
2018-12-19T15:53:25.7841191Z Task         : Publish Code Coverage Results
2018-12-19T15:53:25.7841323Z Description  : Publish Cobertura or JaCoCo code coverage results from a build
2018-12-19T15:53:25.7841449Z Version      : 1.139.2
2018-12-19T15:53:25.7841567Z Author       : Microsoft Corporation
2018-12-19T15:53:25.7841824Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=626485)
2018-12-19T15:53:25.7842052Z ==============================================================================
2018-12-19T15:53:25.9177381Z ##[debug]agent.TempDirectory=/home/vsts/work/_temp
2018-12-19T15:53:25.9201599Z ##[debug]loading inputs and endpoints
2018-12-19T15:53:25.9204627Z ##[debug]loading INPUT_CODECOVERAGETOOL
2018-12-19T15:53:25.9214338Z ##[debug]loading INPUT_SUMMARYFILELOCATION
2018-12-19T15:53:25.9215358Z ##[debug]loading INPUT_REPORTDIRECTORY
2018-12-19T15:53:25.9215927Z ##[debug]loading INPUT_FAILIFCOVERAGEEMPTY
2018-12-19T15:53:25.9217051Z ##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION
2018-12-19T15:53:25.9218040Z ##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION
2018-12-19T15:53:25.9218886Z ##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN
2018-12-19T15:53:25.9225372Z ##[debug]loading SECRET_CONTAINER_USERNAME
2018-12-19T15:53:25.9226783Z ##[debug]loading SECRET_CONTAINER_AUTHENTICATIONTOKEN
2018-12-19T15:53:25.9227840Z ##[debug]loading SECRET_CONTAINER_PASSWORD
2018-12-19T15:53:25.9228170Z ##[debug]loaded 10
2018-12-19T15:53:25.9244829Z ##[debug]Agent.ProxyUrl=undefined
2018-12-19T15:53:25.9247272Z ##[debug]Agent.CAInfo=undefined
2018-12-19T15:53:25.9247619Z ##[debug]Agent.ClientCert=undefined
2018-12-19T15:53:25.9247853Z ##[debug]Agent.SkipCertValidation=undefined
2018-12-19T15:53:26.0671031Z ##[debug]check path : /home/vsts/work/_tasks/PublishCodeCoverageResults_2a7ebc54-c13e-490e-81a5-d7561ab7cd97/1.139.2/task.json
2018-12-19T15:53:26.0671504Z ##[debug]adding resource file: /home/vsts/work/_tasks/PublishCodeCoverageResults_2a7ebc54-c13e-490e-81a5-d7561ab7cd97/1.139.2/task.json
2018-12-19T15:53:26.0671826Z ##[debug]system.culture=en-US
2018-12-19T15:53:26.0684740Z ##[debug]codeCoverageTool=Cobertura
2018-12-19T15:53:26.0685820Z ##[debug]summaryFileLocation=/home/vsts/work/1/a/tests-results/coveragerun-coverage-results-core.xml
2018-12-19T15:53:26.0690082Z ##[debug]reportDirectory=/home/vsts/work/1/a/tests-results/ReportGenerator
2018-12-19T15:53:26.0690525Z ##[debug]additionalCodeCoverageFiles=null
2018-12-19T15:53:26.0690742Z ##[debug]failIfCoverageEmpty=false
2018-12-19T15:53:26.0690963Z ##[debug]System.DefaultWorkingDirectory=/home/vsts/work/1/s
2018-12-19T15:53:26.0781473Z Reading code coverage summary from '/home/vsts/work/1/a/tests-results/coveragerun-coverage-results-core.xml'
2018-12-19T15:53:27.6822360Z ##[debug]Processed: ##vso[codecoverage.publish codecoveragetool=Cobertura;summaryfile=/home/vsts/work/1/a/tests-results/coveragerun-coverage-results-core.xml;reportdirectory=/home/vsts/work/1/a/tests-results/ReportGenerator;]
2018-12-19T15:53:27.6823582Z ##[section]Async Command Start: Publish code coverage
2018-12-19T15:53:27.6823711Z Publishing coverage summary data to TFS server.
2018-12-19T15:53:27.6823811Z  Lines- 1711 of 2316 covered.
2018-12-19T15:53:27.6823907Z  Branches- 740 of 943 covered.
2018-12-19T15:53:27.8417224Z ##[warning]Error occurred while publishing code coverage files. Error: Access to the path '/home/vsts/work/1/a/tests-results/ReportGenerator/summary1097' is denied.
2018-12-19T15:53:27.8434344Z ##[section]Async Command End: Publish code coverage
2018-12-19T15:53:27.8435291Z ##[section]Finishing: Publish code coverage from $(Build.ArtifactStagingDirectory)/tests-results/coveragerun-coverage-results-core.xml

Error logs
2018-12-19T15:40:33.4676645Z ##[warning]Error occurred while publishing code coverage files. Error: Access to the path '/home/vsts/work/1/a/tests-results/ReportGenerator/summary1096' is denied.

Are you running on the "Hosted Ubuntu" VM? This seems like the same issue as https://github.com/Microsoft/azure-pipelines-tasks/issues/8762. Please refer to that for a workaround while we are figuring out the best way to address the bug.
Thanks,
Madhuri

I managed to solve this issue thanks to that thread, I added a bash script that does the following:
mkdir -p $(Build.ArtifactStagingDirectory)/tests-results/ReportGenerator


Library for WiFi-CLOCK

The source for WIFI CLOCK needs these libraries
#include "CRMui.h"
#include "CRM_Time.h"
Where can I download them?

What project is this from?

https://cloud.mail.ru/public/5eHE/dCHUyqrr1 and https://github.com/WonderCRM/wondercrm.github.io

https://cloud.mail.ru/public/5eHE/dCHUyqrr1/WiFi-RELE/Source.rar

Thanks, but it seems the release source is incomplete, there's no clock display or code to do such.

The source code of WiFi-CLOCK 2 is not in the public domain.


register mail err: mail: missing phrase

Hi,
I can't get gogs to send mails. I'm using it on my server and created a new user which works perfectly for sending mail. But goes always logs me the following error message and doesn't send a mail:
[asm_amd64.s:2232 goexit()] [E] Async sent email 0 succeed, not send emails<EMAIL_ADDRESS>info: UID: 10, send register mail err: mail: missing phrase

Ok, I got it I missed the FROM in the Mailer configuration.

Good to hear it! Sorry about confusion, docs is corrected now.


Repository implementation for persistence with MSSQL

Previously the system used an implementation of the repository that stores entities in memory. The system has come to a point where it makes sense to start persisting data in a database.

nice!


fix(api/applications): allowed blank email validation (BOAS-420)

Describe your changes
allowed blank email validation

Issue ticket number and link
BOAS-420 https://pins-ds.atlassian.net/jira/software/projects/BOAS/boards/172?selectedIssue=BOAS-420
Type of change 🧩

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[x] I have double checked this work does not include any hardcoded secrets or passwords
[x] I have made corresponding changes to the documentation
[x] I have provided details on how I have tested my code
[x] I have referenced the ticket number above
[x] I have provided a description of the ticket
[x] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


mstflint: 4.17.0-1 -> 4.25.0-1

Diff: https://github.com/Mellanox/mstflint/compare/None...v4.25.0-1
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 250967 run on x86_64-linux 1

1 package failed to build:

mstflint

Result of nixpkgs-review pr 250967 run on x86_64-linux 1
1 package failed to build:

This is the relevant part of the error as far as I can tell. I havevn't been able to figure out why the file is missing, it present in the source of the uptream here: https://github.com/Mellanox/mstflint/blob/f279c4ce5665a02d4410fa75c698b7c35d427617/tools_layouts/cibfw_layouts.h
Any ideas how to fix this?
mstflint> fs3_ops.h:38:10: fatal error: cibfw_layouts.h: No such file or directory
mstflint>    38 | #include <cibfw_layouts.h>
mstflint>       |          ^~~~~~~~~~~~~~~~~
mstflint> compilation terminated.
mstflint> make[3]: *** [Makefile:536: bluefiled_signature_manager.o] Error 1
mstflint> make[3]: Leaving directory '/build/source/mlxfwops/lib'
mstflint> make[2]: *** [Makefile:421: all-recursive] Error 1
mstflint> make[2]: Leaving directory '/build/source/mlxfwops'
mstflint> make[1]: *** [Makefile:558: all-recursive] Error 1
mstflint> make[1]: Leaving directory '/build/source'
mstflint> make: *** [Makefile:443: all] Error 2
error: builder for '/nix/store/b2vg88rsf265zm6c0vifnp8522fh2r6z-mstflint-4.25.0-1.drv' failed with exit code 2;
       last 10 log lines:
       >    38 | #include <cibfw_layouts.h>
       >       |          ^~~~~~~~~~~~~~~~~
       > compilation terminated.
       > make[3]: *** [Makefile:536: bluefiled_signature_manager.o] Error 1
       > make[3]: Leaving directory '/build/source/mlxfwops/lib'
       > make[2]: *** [Makefile:421: all-recursive] Error 1
       > make[2]: Leaving directory '/build/source/mlxfwops'
       > make[1]: *** [Makefile:558: all-recursive] Error 1
       > make[1]: Leaving directory '/build/source'
       > make: *** [Makefile:443: all] Error 2
       For full logs, run 'nix log /nix/store/b2vg88rsf265zm6c0vifnp8522fh2r6z-mstflint-4.25.0-1.drv'.

FYI: #263149 should fix your build issue.

You may close at your discretion.

Superseded by #263149.


Make initial build process.

Hi @jbthummar.
I appreciate the pull request, however we currently do not need the following scripts as Winterfell is built via the npm scripts found in the package.json. I also have absolutely no idea what one-peace and seems like that it something outside of your Winterfell repository and not part of the Winterfell repo.
Thanks.


Problems with installing adafruit_blinka

Hi,
i need to install the adafruit_blinka libary on Raspberry PI 3. I followed the instructions on their website (https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi).
But when i want to install the libary i get the following error:
`sudo pip3 install adafruit-blinka
Downloading/unpacking adafruit-blinka
Downloading Adafruit-Blinka-0.2.7.tar.gz
Running setup.py (path:/tmp/pip-build-2ur8glrn/adafruit-blinka/setup.py) egg_info for package adafruit-blinka
/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'python_requires'
warnings.warn(msg)
/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'long_description_content_type'
warnings.warn(msg)
error in Adafruit-Blinka setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers
Complete output from command python setup.py egg_info:
/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'python_requires'
warnings.warn(msg)
/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'long_description_content_type'
warnings.warn(msg)
error in Adafruit-Blinka setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers

Cleaning up...
Command python setup.py egg_info failed with error code 1 in /tmp/pip-build-2ur8glrn/adafruit-blinka
Storing debug log for failure /root/.pip/pip.log`
I hope someone can help me!

Try upgrading your setuptools first:
sudo pip3 install setuptools --upgrade

Thanks frankzhao!  I had the same issue and this worked for me!


feat(ControlBar): Add expand/collapse all buttons

What
Closes #196
Description
Adds the ability for applications to show an expand all and collapse all button on the control bar.
The application must handle the callback and call the new Graph method expandAll or collapseAll. If the application is using a pipeline layout with generate spacer nodes and edges, it must recreate the model and relayout the view.
An example of just how this is done can be found in: PipelineGroupsDemo.collapseAllCallback
Note that there are 2 new methods added to the Graph interface and an optional parameter leafOnly to the getAllChildren method on the Node interface. Any application that is current implementing these interfaces without extending the base implementation will need to adjust accordingly.
Type of change

[x] Feature

Screen shots / Gifs for design review

Demo app surge: https://expand-collapse-all.surge.sh/

Preview: https://react-topology-pr-topology-203.surge.sh


Mergable SenseLab 14 add forced alignment

Finish a mergable PR of SenseLab.

[x] Reviewable PR
[ ] Updated PR merged

Linked to wrong issue, correct one: https://github.com/sensein/senselab/pull/89


Are you planning on making a version for Logic Pro X?

Are you planning on making a version of Magenta Studio plugins for Logic Pro X?
I personally don't use Ableton.
https://magenta.tensorflow.org/studio
Here's how you make a audio unit in Logic Pro X:
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/AudioUnit.html#//apple_ref/doc/uid/TP40014214-CH22-SW1

Sorry, but we don't have any plans for this, as it would be non-trivial. You can use the standalone versions however.


[devops:bot] update deps in nix/sources.json (from: rhino-core@37de60f

update nix refernces for rhino-core and|or nixpkgs to match https://github.com/rhinofi/rhino-core/blob/37de60f22e1c1ac3dbf1e5eb3f3daa7008f3cf91/nix/sources.json (branch: dev)

superseded by #129


Event when change current location

FEATURE REQUEST / SUGGESTION
SUMMARY
Please don't skip my question!
DETAILS
In other issues, amay077 help us by Xamarin Geolocator Plugin, but, if Xamarin.Forms.GoogleMaps has not support for current location, what is made Blue point on map move when i change my phone's position?
Please view on image: https://www.flickr.com/photos/145969682@N07/37336803000/in/dateposted-public/
PLATFORMS
which platform do you want?

[x] Android
[x] iOS
[ ] UWP
https://www.flickr.com/photos/145969682@N07/37336803000/in/dateposted-public/

I was also interested and here is the answer:
https://stackoverflow.com/questions/22519847/what-does-map-setmylocationenabledtrue-really-do
TLDR; it is not possible in API v2
po 9. 10. 2017 v 16:55 odesílatel Nguyễn Anh Tuấn Agile <
<EMAIL_ADDRESS>napsal:

(This is template for issue. Please choose from feature request or bug
report or others then write.
If you need realtime communication then you can join our gitter room
https://gitter.im/Xamarin-Forms-GoogleMaps/public.)
FEATURE REQUEST / SUGGESTION SUMMARY
Please don't skip my question!
DETAILS
In other issues, amay077 help us by Xamarin Geolocator Plugin, but, if
Xamarin.Forms.GoogleMaps has not support for current location, what is made
Blue point on map move when i change my phone's position?
Please view on image:
https://www.flickr.com/photos/145969682@N07/37336803000/in/dateposted-public/
// usage of your requested feature to use
PLATFORMS
which platform do you want?

Android
iOS
UWP

BUG / PROBREM REPORT SUMMARY
(write summary of your bug report.)
VERSIONS

Xamarin.Forms.GoogleMaps - x.x.x
Xamarin.Forms - x.x.x

PLATFORMS

Android
iOS
UWP

HOW TO REPRODUCE
(Let me show how to reproduce with steps or codes)

// code for reproduce
ACTUAL IMAGES
(Let me show your actual problem images/stacktrace. If you want to capture
simulator screen to animation GIF, I recomend to LICEcap
http://www.cockos.com/licecap/.)
[image: something_image] http://your_image.png
// paste stacktrace

OTHERS
(free format)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/amay077/Xamarin.Forms.GoogleMaps/issues/392, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AV-OEjaQtQLQmnUyB2Td4i3e7JLBAN5rks5sqjPhgaJpZM4PynVq
.

I found GoogleMap.setLocationSource in Google Maps Android API that can replace the location source of the my-location layer.
But I can't found same feature in Google Maps iOS SDK.

Thank you so much!


Wrong translation in German version of "About milestones"

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

Article: About Milestones (Informationen zu Meilensteinen)
Chapter: Prioritizing issues and pull requests in milestones (Issues und Pull Requests in Meilensteinen priorisieren)
Link: https://docs.github.com/de/issues/using-labels-and-milestones-to-track-work/about-milestones#prioritizing-issues-and-pull-requests-in-milestones

What part(s) of the article would you like to see updated?
The German translation of the above described chapter is wrong, making no sense.
German translation

Du kannst offene Issues und Pull Requests in einem Meilenstein priorisieren, indem du links neben das Kontrollkästchen eines Issues oder Pull Requests klickst, und den Meilenstein so an eine andere Stelle ziehst und dort ablegst.

Translated back to English

You can prioritize open issues and pull requests in a milestone by clicking to the left of an issue or pull request's checkbox, thereby dragging the milestone to a new location, and dropping it.

Additional information
Original English version:

You can prioritize open issues and pull requests in a milestone by clicking to the left of an issue or pull request's checkbox, dragging it to a new location, and dropping it.

@yaSebastian Thanks for reaching out, and flagging this! Since we us an internal, automated solution for our translated docs, I will flag your request for our team 💛
For more information on translations, please see https://github.com/github/docs/blob/main/contributing/types-of-contributions.md#earth_asia-translations ✨

Thank you for your feedback. We will review the issue (ICX ADO Tracking Reference: 1010985).

Thank you for your feedback. We will review the issue (ICX ADO Tracking Reference: 1016987).


FIX: change name from notifyme to rapidnotify

Due to non availaibility of bot name. following step to be taken.


Separate installation steps

I saw the discussion on #17 and while it seems y'all have a plan for going ahead, I figured I'd do something to unblock my own devs. You can use it or not at your discretion.
Basically I separated installation into two distinct steps, which can be run
all at once with an umbrella command (typically by the first developer
adding Committee to a project.)

mix committee.bootstrap

Essentially the old committee.install task in that it both
generates the .committee.exs file, and installs your git hooks.

mix committee.install

A task that solely generates the .committee.exs file. Dunno why
one would use this on their own but I don't ask questions.

mix committee.install_hooks

This command solely installs git hooks, and is therefore the
command that should be placed in your project's README for
developers to get up and running with your codebase.

Hey @cmaggard, really sorry for the late reply, I missed your message and I've been in between jobs so I haven't really paid any attention to my libraries.
I appreciate the PR, but I think separating the installation steps is a little unnecessary and it will open up the API much bigger, whereas if we keep the API to just mix committee.install then users will only ever have to remember one command.
This library is still in development, I'm about to start my new job but I'll try to find pocket of times whenever I can to work on this!

By the way, @thiamsantos has fixed the non-installable for team member issue over with #25. I'm going to push that to production soon.


[spring-xsuaa] NimbusJwtDecoder should be configured with default RestTemplate

Spring tests fail with version 2.2.0, when auto-configuration is disabled and no RestOperations bean is specified in test spring application context.
as this is incompatible we are going to use a fallback restTemplate there...

Workaround:
@SpringBootTest(classes = { OAuthTest.RestTemplateConfig.class, ...}
public class OAuthTest {
   ...

    @TestConfiguration
    public static class RestTemplateConfig {
        @Bean
        public RestOperations restTemplate() {
            return new RestTemplate();
        }
    }
}

root cause: order in classes specified in @SpringBootTest annotation.
It should be


Add a merge scope option

Hi,
Sometimes, it could be needed to consider that dependencies with the same groupId:artifactId:version but different scope are the same dependency.
It would be nice to have an option to merge the scope altogether!

This feature has already been requested a few times. I'll take a look.

A first implementation is available now in the aggregate goal: -DmergeScopes=true/false (Default is true at the moment)

Excellent, is there a reason for not implementing it in graph too?

You will never have multiple scopes with the graph goal. This goal works on a single maven project where dependency resolution is unambiguous.

Done, the mergeScopes option is available in the aggregate and aggregate-by-groupId goals.
I am currently working on Version 1.1 (or maybe version 2.0) of the plugin. So it will take a bit more time until you get a new version on Maven Central.

You will never have multiple scopes with the graph goal. This goal works on a single maven project where dependency resolution is unambiguous.

Of course yes! Thanks for all of this, I already started experimenting the different options you introduced and it is helpful :)


HADOOP-17907. FileUtil#fullyDelete deletes contents of sym-linked directory when symlink cannot be deleted because of local fs fault

Description of PR
As discussed in HADOOP-6536, FileUtil#fullyDelete should not delete the contents of the sym-linked directory when we pass a symlink parameter. Currently we try to delete the resource first by calling deleteImpl, and if deleteImpl is failed, we regard it as non-empty directory and remove all its contents and then itself. This logic behaves wrong when local file system cannot delete symlink to a directory because of faulty disk, local system's error, etc. When we cannot delete it in the first time, hadoop will try to remove all the contents of the directory it pointed to and leave an empty dir.
So, we should add an isSymlink checking before we call fullyDeleteContents to prevent such behavior.
How was this patch tested?
Add a unit test in TestFileUtil
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  5s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
41m 28s

trunk passed

+1 :green_heart:
compile
28m 11s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 56s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m  4s

trunk passed

+1 :green_heart:
mvnsite
1m 33s

trunk passed

+1 :green_heart:
javadoc
1m  4s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 34s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 29s

trunk passed

+1 :green_heart:
shadedclient
16m  3s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 57s

the patch passed

+1 :green_heart:
compile
27m  4s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
27m  4s

the patch passed

+1 :green_heart:
compile
23m  2s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
23m  1s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  7s

the patch passed

+1 :green_heart:
mvnsite
1m 40s

the patch passed

+1 :green_heart:
javadoc
1m 12s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 43s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m  4s

the patch passed

+1 :green_heart:
shadedclient
21m  4s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
19m 10s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 57s

The patch does not generate ASF License warnings.

214m 35s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3431

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 0b4f6aafeab0 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2dd6d25d2cbd9a1e19ce8fb88caa6af0eee8d3dd

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/1/testReport/

Max. process+thread count
1249 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  2s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
32m 13s

trunk passed

+1 :green_heart:
compile
21m 37s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 44s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m  3s

trunk passed

+1 :green_heart:
mvnsite
1m 31s

trunk passed

+1 :green_heart:
javadoc
1m  4s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 37s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 23s

trunk passed

+1 :green_heart:
shadedclient
15m 52s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 54s

the patch passed

+1 :green_heart:
compile
21m  2s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
21m  2s

the patch passed

+1 :green_heart:
compile
18m 42s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
18m 42s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  1s

the patch passed

+1 :green_heart:
mvnsite
1m 32s

the patch passed

+1 :green_heart:
javadoc
1m  2s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 32s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 39s

the patch passed

+1 :green_heart:
shadedclient
16m 17s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m  2s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 52s

The patch does not generate ASF License warnings.

180m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3431

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux c56f8d39c91f 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 172df889a4231369b1fa650e7adcc23d03165cde

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/2/testReport/

Max. process+thread count
1500 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3431/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

LGTM

Thanks for your review.


updated the documentation, waiting for the pymadpl issue to be resolved.

Hi @mcMunich, I finally got back to this example. Sorry it took so long.
The conclusion is we do not run MAPDL in the PyDPF pipelines, so I had to add the result files to the example files.
I started a new PR due to many changes in master.
You can check #224 and let me know what you think.

Closed by #591


Attempt to fix #97

@lifeart not ignoring you on purpose ;) btw. I spoke w/ some of the core team at EmberCamp last week and it's possible the wrapper component + resolver mixin might be implementation details we can remove w/ some new information and help (more to come in the weeks ahead).
While we wait to see what comes of all that^ I'm curious in this PR how we might know the ordering of these function invocations is important. We don't have many tests yet around how the custom resolver functionality works but I'm curious if it would be possible to better document it with some type of test (that proves this is needed/ required to solve the issue you found)

@toranb agreed, I'm interesting, why we return undefined in original logic? I think this fix can be more relevant  - we can check template name for ignoring and return resolved value only for ignored templates.

@lifeart I want to say that returning undefined like we had it was something I found in the ember resolver itself (for resolveOther) as a way to signal that we bailed out early/ with nothing to show for it.


The copilot chat shows language model unavailable error

Copilot Chat Extension Version:v0.22.2
VS Code Version: 1.95.2
OS Version: 14.7.1 (23H222)
Logs:

GitHub Copilot Chat

Extension Version: 0.22.2 (prod)
VS Code: vscode/1.95.2
OS: Mac

Network
User Settings:
  "github.copilot.advanced": {
    "debug.useElectronFetcher": true,
    "debug.useNodeFetcher": false
  }

Connecting to https://api.github.com:

DNS ipv4 Lookup: <IP_ADDRESS> (1 ms)
DNS ipv6 Lookup: ::ffff:<IP_ADDRESS> (3 ms)
Electron Fetcher (configured): HTTP 200 (983 ms)
Node Fetcher: HTTP 200 (948 ms)
Helix Fetcher: HTTP 200 (1268 ms)

Connecting to https://api.individual.githubcopilot.com/_ping:

DNS ipv4 Lookup: <IP_ADDRESS> (38 ms)
DNS ipv6 Lookup: ::ffff:<IP_ADDRESS> (8 ms)
Electron Fetcher (configured): Error: net::ERR_CONNECTION_CLOSED
Node Fetcher: Error: Client network socket disconnected before secure TLS connection was established
Helix Fetcher: Error: Client network socket disconnected before secure TLS connection was established

Documentation
In corporate networks: [Troubleshooting firewall settings for GitHub [

]()
Steps to Reproduce:

Yes as the diagnostics show and the notification shows. Your firewall is not configured properly and needs to be configured to allow this through
https://github.com/microsoft/vscode-copilot-release/issues/2116


/otg export region marking NullPointerException

OTG Plugin or Mod

[x] OTG Mod for Forge
[x] OTG Plugin for Spigot

OTG Version

[ ] 1.12.2_v8_r1
[ ] 1.12.2_v7_DEV_r26
[ ] 1.12.2-v6
[ ] 1.12.2-v5
[ ] 1.11.2-v8
[ ] 1.11.2-v9
[ ] 1.10.2-v21
[x] Other - specify here: 1.16

Forge or Spigot Versions
1.16.5 Forge
What other plugins are you running?
WorldEdit + OTG, Forge build in test environment, built from source.
Description
If you don't set a region, you get a NullPointerException when you try to /otg export an item.
A message saying you need to set a region first and how to do it.
/otg export  w/o /otg mark & /otg mark 2.
Also, I will be fixing this I just wanted to point out that it existed.

Done.


Add ensure=>file to pinning file

Hi
This fix for https://github.com/jenkinsci/puppet-jenkins/issues/465 actually seems too simple.  It works for me, but I suspect I'm missing something! :)
But without an 'ensure' property, what did the file resource actually do?  Chown files if they happened to exist?
Kind Regards,
Alex

@alexjfisher I agree it is odd that file resource doesn't have an ensure param.  I'm not sure if the design intent was to only set the permissions on the .pinned file, if it exists or to pin all managed plugins. Hmm.

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

I think the trouble is this would pin all plugins, not just bundled ones.  Not sure how big of a deal that is.   It may only be an issue if a plugin is not bundled when puppet is applied, but gets added to the bundle on a later Jenkins release.
I suspect the cleanest thing would be to add a "pinned" parameter and let people manually select whether to pin a plugin.  https://github.com/jenkinsci/puppet-jenkins/issues/380, and the result of the fix (https://github.com/jenkinsci/puppet-jenkins/commit/32c015e2c52a96ac08424314f42cc8f0f23d6e85) suggests that it is difficult to detect whether a plugin should be pinned automatically, and have it work on first and subsequent applies.

@sfhardman I've added a new parameter to control the behaviour as you suggested.  I actually called it 'pin' (instead of 'pinned').

Works for me :-)

@rtyler Any thoughts on this?


396 simplify version numbers

Display 'Current'- or 'Out-of-date'-text instead of the timestamp in the version field of the task list for more readability.
According to #396 .
'Current' is displayed as .text-muted and 'Out-of-date' as .text-warning.

Maybe 'Current' should be displayed as normal text and not as .text-muted.
Now the colors are a little bit bumpy in the horizontal line with Status and Updated.

Not sure about the version numbers, we use them for rollbacks. It should at least be possible to somehow get the real value.

You can get the timestamp by mouseover the field by the title-attribute. Is this sufficent?

It should be copyable. Can we maybe add something like: hover over version -> caption = "Click to copy version number" -> version number gets copied to clipboard on click?

Oh and maybe the display could also change from "Current" or "Out-of-date" to the actual timestamp on hover.

"Directly copying to the clipboard via javascript is not permitted by any modern browser for security reasons"
Yeah, that would be a solution, changing the text to the timestamp on hover. Will build an example.

Ok, thanks.

@drexin You can always see the older version numbers in configuration. Isn't that enough?
I can live with click interaction, I'll let @drexin by the jugde of whether it is frustrating that it reverts back whenever the list is repainted (e.g. when number of tasks are scaled up, or down).

Other than that, code looks good :+1:

:100:


Function timeout is not applying

I have a function that I have defined like so:
new sst.aws.Function('MyFunction', {
	environment: {
		...
	},
	handler: './apps/functions/src/MyFunction.handler',
	memory: '128 MB',
	timeout: '1 minute',
	live: false,
})

It deploys the function correctly with all my env var stuff set, but it does not set the timeout.  I have tried 60 seconds, I have tried 1 minute, etc.  I don't think it has anything to do with the service that is triggering the function (eventbridge in this case) because when looking at the function's configuration in the console it shows this:

If I go into the console and change it to a different value than what I have set in code, SST/Pulumi does not update it back to the value I have set in my code.  Seems like this field is not sync'd with SST.

Is this in dev or deploy?

Dev, but also the case if I set live to false.
On Tue, May 28, 2024, 5:43 PM Jay @.***> wrote:

Is this in dev or deploy?
—
Reply to this email directly, view it on GitHub
https://github.com/sst/ion/issues/466#issuecomment-2136226828, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AW3734PJRZBTSINQUMS453LZEUCBZAVCNFSM6AAAAABIIJQ5YGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGIZDMOBSHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

If you deploy it, does it set it?

Just tested deploying it, no it does not.  It's still set at 10 seconds.

If that's the case then run a sst refresh first and then do a deploy. More about it here: https://ion.sst.dev/docs/providers/#how-state-works

Oh interesting.  That's a major shift from how Terraform works.  Terraform runs a refresh/plan prior to apply so didn't make sense to me.
Regardless of that this still does not work.  I just did a refresh then deploy and this function on AWS has a timeout of 10 seconds.  Here's its definition:
new sst.aws.Cron('CheckFailedSubscriptionsCron', {
	schedule: 'rate(1 hour)',
	job: {
		environment: {
			CONDUIT_INDEX: '0',
			APP: $app.name,
			STAGE: $app.stage,
			BUS_ARN: bus.arn,
			BUS: bus.name,
		},
		handler: './apps/functions/src/CheckFailedSubscriptions.handler',
		link: [clientIdSecret, clientSecretSecret, table, apiTable],
		live: false,
		permissions: [
			{
				actions: ['ssm:Get*', 'ssm:PutParameter'],
				resources: ['*'],
			},
		],
		timeout: '2 minutes',
	},
})

If I remove the live: false it still is set at 10 seconds.  I seemingly can never get it to respect the timeout setting.

So if you edit the value in the console and your local state has a different value, a deploy won't update it.
You need to make sure that your state locally matches what you have set in the console.
For the plan part, we have it on the roadmap.

Ah okay, another thing that works different.  I guess I didn't realize there wasn't state drift resolution... that seems super odd having come from the Terraform world.
With that in mind, I created a new function.  I touched nothing in the console.  Its timeout was set at 10 seconds.  I added timeout: "60 seconds" while running sst dev, it noticed the file change and tried to deploy but ultimately changed nothing.
I then tried doing an sst deploy and still the function's timeout is set at 10 seconds.

I see the issue might be specific to how Live handles functions. It isn't deploying your function but a proxy with different set of props. So flipping back and forth between dev and deploy might not be updating it.

@fwang let's take a look?

@thelegendtubaguy hmm.. that's really weird.
I just tried deploying a new app with the Cron job snippet u shared above. And timeout is set to 2 minutes in the console.

Maybe try a new SST app with just a single function?

Ah, I set a default timeout to 10 seconds.  I suppose we can close this... but is there a way to set defaults and then allow us to overwrite that default per function?
For example, here's what I had:
async run() {
		$transform(sst.aws.Function, (args, opts) => {
			args.logging = { retention: '1 month' }
			args.memory = '128 MB'
			args.runtime = 'nodejs20.x'
			args.timeout = '10 seconds'
		})
		await import('./infra')
	},
	```

Right now there isn't. But it's something we should look into.


feat!: boojum integration

What
Needed server changes for the Boojum integration.
Note, that the server integration is not yet final and changes are anticipated
Why ❔
Checklist

[ ] PR title corresponds to the body of PR (we generate changelog entries fom PRs).
[ ] Tests for the changes have been added / updated.
[ ] Documentation comments have been added / updated.
[ ] Code has been formatted via zk fmt and zk lint.

Why do we have changes to bootloader images for 'vm_virtual_blocks_finish_upgrade_fix'?


Terminal transparency (opacity) setting

Hello! I saw different ways to make thew whole VSCode window transparent but couldn't find the way to make the terminal (or at least the whole panel) window transparent. It would be super cool to have such ability in settings!

/duplicate https://github.com/microsoft/vscode/issues/12578

@emil14 we don't support transparency anywhere so the ways you saw for the window are a hack, we won't support this in the terminal until we officially support it in the window.

@Tyriar  Is this a reason to close feature request?

Yes, because it's a duplicate of https://github.com/microsoft/vscode/issues/12578

See https://github.com/microsoft/vscode/issues/169285#issuecomment-1355094227 and https://github.com/microsoft/vscode/wiki/Issue-Grooming. There is no point tracking this for the terminal if it's not going to happen. We would only action this in the terminal if we supported it for the window.

Support for the whole window is harder to implement because that's something outside of CSS scope while it's possible to make terminal transparent using just CSS, that's why. These two features could have very different implementations. Also there could be people (like me) who is not interested in transparent window but instead in transparent terminal. Transparent terminals are pretty common things

what is the point of a transparent terminal of the window has no transparency? I do want the ability of transparency everywhere though.

the same usecase as with regular transparent terminal - ability to work in terminal and see the code (or the whole window) at the same time

the same usecase as with regular transparent terminal - ability to work in terminal and see the code (or the whole window) at the same time

What are you talking about? There is nothing behind the terminal!

Locking this as the ask is to support something that doesn't work without hacking the sources of VS Code which is of course not a recommended or supported scenario.


Upversion to 4.18

Background / Context

Issue / Requirement / Reason for change

Solution / Feature Overview

Implementation Details

Other Information

also fix this file in both branches https://github.com/openshift-kni/lifecycle-agent/blob/main/config/default/manager_auth_proxy_patch.yaml

/retest