strings: copying but not using a Builder after first use leads to runtime crash (generates heap -> stack pointer)

What version of Go are you using (go version)?

$ go version
go version go1.16.6

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

https://play.golang.org/p/RRI3-srzVrR
package main

import (
	"fmt"
	"strings"
)

func f(myList []string) error {
	const (
		Threshold = 1000
	)

	var (
		builderList = []strings.Builder{}
	)
	var (
		bullder = strings.Builder{}
	)
	var (
		count uint64 = 0
	)
	for _, _ = range myList {
		if count > Threshold {
			builderList = append(builderList, bullder)
			bullder = strings.Builder{}
			count = 0
		}
		bullder.WriteString("123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890")
		count++
	}
	return nil
}

func main() {
	myList := make([]string, 1000000)
	err := f(myList)
	if err != nil {
		panic(err)
	}
	fmt.Println("success")
}

What did you expect to see?
I don't see any error message
What did you see instead?
--
runtime: pointer 0xc035a7bc78 to unused region of span span.base()=0xc0001de000 span.limit=0xc0001dff80 span.state=1
  | 2021-07-19T12:43:00.012+09:00 | runtime: found in object at *(0xc0026a6000+0x0)
  | 2021-07-19T12:43:00.012+09:00 | object=0xc0026a6000 s.base()=0xc0026a6000 s.limit=0xc0026a8000 s.spanclass=36 s.elemsize=256 s.state=mSpanInUse
  | 2021-07-19T12:43:00.012+09:00 | *(object+0) = 0xc035a7bc78 <==
  | 2021-07-19T12:43:00.012+09:00 | *(object+8) = 0xc002700000
  | 2021-07-19T12:43:00.012+09:00 | *(object+16) = 0x113a6c
  | 2021-07-19T12:43:00.012+09:00 | *(object+24) = 0x128000
  | 2021-07-19T12:43:00.012+09:00 | *(object+32) = 0xc035a7bc78
  | 2021-07-19T12:43:00.012+09:00 | *(object+40) = 0xc0017ce000
  | 2021-07-19T12:43:00.012+09:00 | *(object+48) = 0x1100aa
  | 2021-07-19T12:43:00.012+09:00 | *(object+56) = 0x128000
  | 2021-07-19T12:43:00.012+09:00 | *(object+64) = 0xc00008fc78
  | 2021-07-19T12:43:00.012+09:00 | *(object+72) = 0xc002300000
  | 2021-07-19T12:43:00.012+09:00 | *(object+80) = 0x115fcc
  | 2021-07-19T12:43:00.012+09:00 | *(object+88) = 0x128000
  | 2021-07-19T12:43:00.012+09:00 | *(object+96) = 0xc00008fc78
  | 2021-07-19T12:43:00.012+09:00 | *(object+104) = 0xc0018f6000
  | 2021-07-19T12:43:00.012+09:00 | *(object+112) = 0x115de0
  | 2021-07-19T12:43:00.012+09:00 | *(object+120) = 0x128000
  | 2021-07-19T12:43:00.012+09:00 | *(object+128) = 0xc00008fc78
  | 2021-07-19T12:43:00.012+09:00 | *(object+136) = 0xc002992000
  | 2021-07-19T12:43:00.013+09:00 | *(object+144) = 0x114359
  | 2021-07-19T12:43:00.013+09:00 | *(object+152) = 0x128000
  | 2021-07-19T12:43:00.013+09:00 | *(object+160) = 0xc00008fc78
  | 2021-07-19T12:43:00.013+09:00 | *(object+168) = 0xc001a1e000
  | 2021-07-19T12:43:00.013+09:00 | *(object+176) = 0x11aa0e
  | 2021-07-19T12:43:00.013+09:00 | *(object+184) = 0x128000
  | 2021-07-19T12:43:00.013+09:00 | *(object+192) = 0xc00008fc78
  | 2021-07-19T12:43:00.013+09:00 | *(object+200) = 0xc001f80000
  | 2021-07-19T12:43:00.013+09:00 | *(object+208) = 0x113b9b
  | 2021-07-19T12:43:00.013+09:00 | *(object+216) = 0x128000
  | 2021-07-19T12:43:00.013+09:00 | *(object+224) = 0x0
  | 2021-07-19T12:43:00.013+09:00 | *(object+232) = 0x0
  | 2021-07-19T12:43:00.013+09:00 | *(object+240) = 0x0
  | 2021-07-19T12:43:00.013+09:00 | *(object+248) = 0x0
  | 2021-07-19T12:43:00.013+09:00 | fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
  | 2021-07-19T12:43:00.016+09:00 | runtime stack:
  | 2021-07-19T12:43:00.016+09:00 | runtime.throw(0x98583e, 0x3e)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/panic.go:1117 +0x72 fp=0xc000049e28 sp=0xc000049df8 pc=0x435db2
  | 2021-07-19T12:43:00.016+09:00 | runtime.badPointer(0x7f0421f06050, 0xc035a7bc78, 0xc0026a6000, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mbitmap.go:351 +0x235 fp=0xc000049e70 sp=0xc000049e28 pc=0x415335
  | 2021-07-19T12:43:00.016+09:00 | runtime.findObject(0xc035a7bc78, 0xc0026a6000, 0x0, 0x0, 0x0, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mbitmap.go:387 +0x9b fp=0xc000049ea8 sp=0xc000049e70 pc=0x4153fb
  | 2021-07-19T12:43:00.016+09:00 | runtime.scanobject(0xc0026a6000, 0xc000027698)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgcmark.go:1286 +0x24a fp=0xc000049f38 sp=0xc000049ea8 pc=0x42138a
  | 2021-07-19T12:43:00.016+09:00 | runtime.gcDrain(0xc000027698, 0x3)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgcmark.go:1048 +0x22b fp=0xc000049f90 sp=0xc000049f38 pc=0x420b0b
  | 2021-07-19T12:43:00.016+09:00 | runtime.gcBgMarkWorker.func2()
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgc.go:1980 +0x88 fp=0xc000049fd0 sp=0xc000049f90 pc=0x461f28
  | 2021-07-19T12:43:00.016+09:00 | runtime.systemstack(0x0)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/asm_amd64.s:379 +0x66 fp=0xc000049fd8 sp=0xc000049fd0 pc=0x4693e6
  | 2021-07-19T12:43:00.016+09:00 | runtime.mstart()
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/proc.go:1246 fp=0xc000049fe0 sp=0xc000049fd8 pc=0x43b080
  | 2021-07-19T12:43:00.016+09:00 | goroutine 34 [GC worker (idle)]:
  | 2021-07-19T12:43:00.016+09:00 | runtime.systemstack_switch()
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/asm_amd64.s:339 fp=0xc000030f60 sp=0xc000030f58 pc=0x469360
  | 2021-07-19T12:43:00.016+09:00 | runtime.gcBgMarkWorker()
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgc.go:1967 +0x1c7 fp=0xc000030fe0 sp=0xc000030f60 pc=0x41d627
  | 2021-07-19T12:43:00.016+09:00 | runtime.goexit()
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc000030fe8 sp=0xc000030fe0 pc=0x46b061
  | 2021-07-19T12:43:00.016+09:00 | created by runtime.gcBgMarkStartWorkers
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgc.go:1835 +0x37
  | 2021-07-19T12:43:00.016+09:00 | goroutine 1 [runnable]:
  | 2021-07-19T12:43:00.016+09:00 | runtime.Gosched(...)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/proc.go:292
  | 2021-07-19T12:43:00.016+09:00 | runtime.gcAssistAlloc(0xc000000180)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/mgcmark.go:469 +0x1bc fp=0xc00008faa0 sp=0xc00008fa40 pc=0x41f55c
  | 2021-07-19T12:43:00.016+09:00 | runtime.mallocgc(0xbc000, 0x0, 0xc0032c7000, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/malloc.go:961 +0x996 fp=0xc00008fb28 sp=0xc00008faa0 pc=0x40ddb6
  | 2021-07-19T12:43:00.016+09:00 | runtime.growslice(0x8b9ec0, 0xc003100000, 0x95dcc, 0x96000, 0x96199, 0xc0032cd000, 0x3cd, 0x400)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/runtime/slice.go:224 +0x154 fp=0xc00008fb90 sp=0xc00008fb28 pc=0x44d6d4
  | 2021-07-19T12:43:00.016+09:00 | strings.(*Builder).WriteString(...)
  | 2021-07-19T12:43:00.016+09:00 | /usr/local/go/src/strings/builder.go:123
  | 2021-07-19T12:43:00.016+09:00 | git.rarejob.com/rarejob-platform/event-search-polling-batch/src/repositories/eselasticsearch.(*elasticSearch).changeTutor(0xc00000e0c0, 0xc034e46000, 0x9727, 0x9727, 0x9798ab, 0x17, 0x0, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /builds/rarejob-platform/event-search-polling-batch/src/repositories/eselasticsearch/tutors.go:71 +0x392 fp=0xc00008fcc8 sp=0xc00008fb90 pc=0x8666b2
  | 2021-07-19T12:43:00.016+09:00 | git.rarejob.com/rarejob-platform/event-search-polling-batch/src/repositories/eselasticsearch.(*elasticSearch).ChangeAllTutor(0xc00000e0c0, 0xc034e46000, 0x9727, 0x9727, 0x0, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /builds/rarejob-platform/event-search-polling-batch/src/repositories/eselasticsearch/tutors.go:19 +0x5e fp=0xc00008fd18 sp=0xc00008fcc8 pc=0x86623e
  | 2021-07-19T12:43:00.016+09:00 | git.rarejob.com/rarejob-platform/event-search-polling-batch/src/services.(*service).SetEsElasticsearch(0xc000024360, 0xa0aef0, 0xc00001a040, 0xc00006ba00, 0x0, 0x0)
  | 2021-07-19T12:43:00.016+09:00 | /builds/rarejob-platform/event-search-polling-batch/src/services/es_elasticsearch.go:40 +0x439 fp=0xc00008fe18 sp=0xc00008fd18 pc=0x871739
 ```

The example:

incorrectly copies strings.Builder - but shouldn't cause a GC panic
doesn't generate any failures for me on Go 1.16.6 or Go 1.17rc1.

The strack trace was generated from different code (it references git.rarejob.com/rarejob-platform/event-search-polling-batch/ and Elasticsearch). Does the example code fail for you?
I'd recommend running your code with go build -race to try to detect races or unsafe pointer use. See the Go1.14 release notes for more details on checkptr, also go doc unsafe.Pointer.

I can reproduce the crash with the snippet above on 1.16.5 if I set an higher GOMAXPROCS (like 4 or 8).
I also think the crash is caused by the fact that you're copying around non-empty  strings.Builders, which the doc explicitly says it's not allowed. It's also true that the failure mode is a little obscure, but I'm not sure there's an easy way to report a better error.

I'm sorry the stack trace was generated from different code. I tried to show the logic of the code.
Thank you for your kind feedback. I think I should investigate it further by myself.

@ALTree - can you please attach the panic to this issue? What platform?
I haven't been able to reproduce on Linux/amd64. The original report is for Darwin.
@momotaro98 - it looks like this mighty be a real problem since someone has been able to reproduce a crash with the example code.

Cc @mknyszek

it looks like this mighty be a real problem since someone has been able to reproduce a crash with the example code.

But the example code copies around strings.Builders values, which I think it's not allowed.

The runtime still shouldn't throw and crash. That indicates either the runtime, compiler, or strings.Builder might need to be fixed.
@ALTree are you able to provide a failed stack trace from the example code?
        XXXX/other/go/src/strings/builder.go:123
main.f(0xc000180000, 0xf4240, 0xf4240, 0xc000180000, 0xc00001c0b8)
        XXXX/test.go:28 +0x212
main.main()
        XXXX/test.go:36 +0x6a
exit status 2

I think I have a hunch why this happens. The alleged bad pointer in the original post is supposed to be a builder pointing to itself (note that the GC was currently scanning builderList). That extra self pointer is how it detects if it's been copied. Thing is, the copy check never fires because there's never a builder method executed after it is copied (otherwise it would fail).
So the question then is why the GC has any problems with this. I believe the answer is that bullder (sic) is stack-allocated, and the self pointer points into a stack location, however that pointer is copied to the heap. The GC has an invariant that heap objects can't point back into a stack, hence the failure.
The reason why this happens is the tricky noescape used in the strings.Builder self pointer assignment (the copyCheck method). Normally the compiler would force the strings.Builder to escape, so the invariant would be maintained.
As others have said, this is a valid failure mode for copying a strings.Builder. It turns out even if you don't use it, it's never safe to copy a non-zero strings.Builder. But, as @mpx points out, there's a UX issue here (and arguably a bug in strings.Builder), but I'm not sure how to fix it.
One possibility is to make the self pointer a uintptr. I think with care, it would actually make this API safe to copy but not use. It would still be a useful marker for the API, but the GC wouldn't ever try to look at that pointer. I'm almost positive that was already disregarded for a number of reasons back when this was implemented, one issue being the "safe to copy but not use the copy" restriction, another being that uintptr is even less safe, and yet another being that switching GC implementations could break this.
FTR, this is not something can be easily fixed in the runtime: we currently do not carry type information around for any object. Thus GC doesn't have access to type information, and even if it did, checking for strings.Builder and the invariant would add slow special cases to the scan path, the hottest path in the runtime.
I'm going to reopen this and update the title to indicate the UX issue here. I'll dig around too and see if I can find a duplicate.

CC @griesemer @aclements
I think fixing the UX issue here would be nice, but I'm not sure how. Open to suggestions. I couldn't find a similar issue filed anywhere.

The other option is to fix #7921. Then we can remove the noescape annotation.

@mdempsky , any thoughts on fixing #7921 in the context of this issue?

I think fixing #7921 is doable for Go 1.18, but I wouldn't feel comfortable backporting it to 1.16/1.17.

Another option would be to only perform the copyCheck in the first place in race mode, and drop the noescape hack from it. That would cause things to escape (and allocate) in race mode, but at least wouldn't produce invalid pointers in non-race mode.
That wouldn't detect memory corruption as readily in non-race mode, but if users observe possible memory corruption they should be testing in race mode anyway.

Another option might be to use buf itself for the copy check, and make the check opportunistic rather than trying to flag exactly every bad write. That might look like:
type Builder struct {
	buf []byte
}

func (b *Builder) copyCheck() {
	i := len(buf)
	if i == cap(buf) {
		return  // Can't check for copying if the buffer is exactly full.
	}
	if b := buf[:cap(buf)][i]; b != 0 {
		// This builder has not written to buf[i] yet,
		// so if it is nonzero it must have been written through a (disallowed) copy.
		panic("strings: illegal use of non-zero Builder copied by value")
	}
}

Or, we could even combine the above two approaches: use an opportunistic check via buf all the time, and a safe, fully-precise check (that incidentally causes the *Builder to escape) only in race mode.

I did a preliminary experiment of extending the "copylock" checker to check for the copying of "strings.Builder", e.g.
func lockPath(tpkg *types.Package, typ types.Type) typePath {
    ...
    if named, ok := typ.(*types.Named); ok &&
		named.Obj().Name() == "Builder" &&
		named.Obj().Pkg().Path() == "strings" {
		return []types.Type{typ}
	}

Running this extension of a few open-source cloud projects doesn't generate any finding. This may indicate that its frequency is too low to be a vet checker.

See previously:

#26462
#25907

Adding to the 1.24 milestone because this is a pretty bad failure mode.  If nothing else we could at least get "go vet" to complain about this, much as it does for copying a sync.Mutex.

Given that we are in the 1.24 freeze, I think this is not appropriate to start a new vet check. Moving this to 1.25.
The requirements for strings.Builder and sync.Mutex copying are quite similar, but not identical.

The zero value is ready to use. Do not copy a non-zero Builder.

vs.

A Mutex must not be copied after first use.

This does suggest reusing the same analyzer logic. There are operations that could conceivably leave the builder in the zero-value (Len, Cap), but it is really unclear why one would call them on 'a must be zero-value'. And there is a slightly open question about copying a strings.Builder after Reset. Does that return it to the zero-value?
Maybe there is a case for worrying about control-flow and 'must not be zero-ness', but I am a bit doubtful we need more than what copylocks does for sync.Mutex. I think we should just try the existing logic as a gopls check. @findleyr thoughts?

I agree that it is probably sufficient to have the same semantics as copylock. Is there any use case for copying a zero builder?
A reasonable step forward might be to run an ecosystem analysis on the proposed new check, following up on the analysis by @guodongli-google in https://github.com/golang/go/issues/47276#issuecomment-891361602. I suspect that because it is a runtime panic to misuse a strings.Builder in this way, true positives of such a checker are exceedingly rare, but an analysis would also turn up any false positives due to copied zero values.
I am fine with piloting this check in gopls, though I think we should only do so if it will eventually be promoted to vet.


How to train and predict without background ?

Dear author,
We are working on a project that we need to get the mesh of the object without background.   I noticed that , by default, the input of the demo code do not remove the background.  Right now I want to train my object without background. So my question is:  should I fill the backgound region to  black or white after image  matting ?    Should I turn the image into RGBA  and the alpha channal corresponding to the opacity ?
Thanks!
Jiakui

Please see this issue: https://github.com/xxlong0/SparseNeuS/issues/14


cmd/link: ppc64x direct call too far: net(.text).malloc while building kubernetes

Please answer these questions before submitting your issue. Thanks!

Download and install golang1.8 from https://storage.googleapis.com/golang/go1.8.linux-ppc64le.tar.gz
clone latest kubernetes code - https://github.com/kubernetes/kubernetes.git
Make it.

What did you expect to see?
make should pass without any issues but failed to generate one if the binary.
 I thought these were all fixed. Guess not?

@cherrymui This problem is related to the big text problem and I suspect it would happen in arm too unless you did something to fix it.  I need help on this one because there is a lot about golang linking I don't understand.
In this case, the problem occurs because there is a call off to something in glibc, so it gets a call stub in the PLT, but the PLT is getting placed too far in the binary so that the bl to the call stub is too far.
If we use -linkmode=external on this one, the error doesn't occur.  Actually I didn't even realize that you could call something in glibc when using internal linking.
Any suggestions on solutions for this one? Even if the PLT was put up front there could still be code later on in the binary that is too far from the PLT.

@ianlancetaylor  for linker expertise.

@bradfitz I thought they were all fixed too :(
This one is related to a call to something in the PLT which I haven't seen before.
This just started happening when Kubernetes updated to a new beta version.  Didn't happen in 1.6.0-beta.0 but now fails in 1.6.0-beta1.

I tried go build -ldflags=-linkmode=internal k8s.io/kubernetes/federation/cmd/genfeddocs with cgo enabled, for both GOARCH=arm and GOARCH=ppc64le. Both succeeded.
Could you let me know how to reproduce it?

The PLT stubs are generated before the trampoline insertion pass. So the trampoline insertion pass should be able to take care of it. Maybe a relocation case is missing?

The problem happens at the instruction that does the bl to the PLT stub.  At the point of trampoline insertion, it doesn't know where the PLT will be, does it?  That isn't know until the linker links it all together because I believe the PLT stubs are in a separate section.
This only fails with the latest Kubernetes (after v1.6.0-beta1).    I'll look into that.

I found that the problem happens as a result of there being C code calling functions in glibc, where the plt call stub is too far and no trampoline is generated for that case.  For example, this happens in net.a because C code is generated through cgo for the call to C.malloc.  When the C code is processed, the function IsDirectJump() must be true before it will call trampoline(), but that function only checks for Go relocation types and not C relocation types so returns false for C code.  I think this same problem could happen on arm at some point, but since ppc64le is 64 bit the programs are in general larger so we are hitting it first.

Here is a simpler summary:

net.a is read in from ldelf.go.  This generates a symbol called net(.text) which contains various functions such as _cgo_cb4050e05860_Cfunc__Cmalloc, and some of those make calls to functions like malloc which require a call stub.  These symbols are added to Textp first.
All the other packages needed by the program are read in and their symbols are added to Textp.
The call stubs are generated, and one must be created to be used by the function mentioned above, because it does a bl malloc.  It is called net(.text).malloc.  The call stubs are added after all the packages have been added, and since Kubernetes has a very large number of very large packages, the call stubs end up too far for the code in net(.text).  The trampoline processing doesn't handle this because the call stub (target of the bl) hasn't had its code address assigned at the point the code for the bl is processed.

I think the solution would be to just put the call stubs closer to where they are used, and actually I think it should be OK to just put them within the range of the outer sym, i.e., as a sub of net(.text) since the way these call stubs are named, they are unique within the outer sym.  net(.text).malloc can only be called within net(.text).
@cherrymui or @ianlancetaylor I need some direction how to do this.  I've made a few naive attempts at getting the callstubs in a different location but I can't get it to build.

@laboger thank you for looking into it.
Would it be possible to add call stubs to Textp before other packages?
If that doesn't work, maybe you can pre-compute the size of the program before assigning the addresses, and insert trampolines when assigning addresses for functions in 1. I think the size of the text is known except for trampolines inserted when assigning addresses. You could make some conservative estimate of the trampoline sizes.
I'll take a careful look in the weekend or early next week.

Workaround for this is to add -ldflags '-linkmode=external' for the build of nonstatic binaries built by kubernetes.  The static binaries built by kubernetes should not be affected by this problem and should not have this option added.

Yes I will try it.

Is it possible that https://go-review.googlesource.com/c/38131/ can be cherry-picked into the go1.8 release branch? The risk seems to be quite low, and the gain pretty high if it fixes net and os/user problems with external linking for ppc64le and maybe ARM.
WDYT?

Issue #19578 is opened for cherry-picking.

I see this same issue on arm (also building kubernetes; go 1.8; works with -linkmode=external).
Is there a similar patch around for arm?  Can it also be backported to 1.8?

@anguslees Please open a new issue with more details and cc me.
Really want to pin that down if there's an issue; it's not known I think


Add "latest" release link

Please add "latest" link download for the last release. This will make easier to build and automation process for updating the code already on production.  On this moment the link is changing with the last release number and this make the automation process harder and unstable

https://github.com/aionnetwork/aion/releases/tag/latest

Thank you so much!


Added a loading spinner #93

Description
Added a loading spinner #93
Checklist

[x] I am making a proper pull request, not spam.
[x] I've checked the issue list before deciding what to submit.

Related Issues or Pull Requests
Add relevant screenshot or video (if any)
(Add here)

it would be better if you could add the whirly loader
https://github.com/jlong/css-spinners

ok I will change the loader accordingly and will reupload the code @wasimreja


Design About Us Page for the website

Design an 'About Us' page for the website.
It should have a navbar with the following links: HOME, PRACTICE, LOGIN, REGISTER.
The main content should contain details of the project such as Tech Stack used, Contact Us links, etc.
Feel free to style it as you wish.
Note:

Design must be original. DO NOT COPY DESIGNS FROM OTHER WEBSITES!!! You are free to use other websites as a reference, but the design should be your original design.
Site must be RESPONSIVE
If using code, it must be made using Tailwind CSS v3.1.8 or newer

Good to have (but not required):
The page must be its own Vue Component titled AboutUsPage.vue

please assign to me this task. I am vue, django developer

@alkhimch You have already been assigned an issue. Kindly complete that first. Good Luck!

Hey, can you please assign this issue to me?
Also is Tailwind CSS mandatory?

@snowrlax As mentioned in the requirements, if you are going to submit code, then only use Tailwind CSS...
However, if you are going to submit a design instead of code, then feel free to do it using whatever tools you want. However, the design must be original.

okay will do👍

Hey @snowrlax are you still working on this issue? or should I assign this to someone else?

In case @snowrlax is not interested anymore, I'd also love to do this 🙋🏽♂

@snowrlax Since you haven't replied to this issue, I'm assigning this to Dabuk. Let me know when you're done.

Oh you don't want to have it anymore? 🤔


Support colocated components

Added support for colocating the styles.css files in the components directory with the template and js files i.e.
components./my-component.hbs
components/my-component.js
components/my-component.css
No tests have been written because I do not know how to do them properly in an addon. Need to read more but need to fix this first.

Any movement on this?

I have been away from this add-on since before octane dropped, and it changed a number of internals so some things no longer work as expected. The earliest I could look at this would be next week, and I will try to do so.

how's it lookin? the build's red

Does this allow switching to colocated components rather than pods? I'm definitely interested in getting this working!

I'm sorry everyone. Life and work has been crazy. I am sorry for letting this linger so long, and letting you all down. I know OSS is great, and hard at times, but this is a project I have taken on, and sorry for letting you all down.
This is something I will commit to getting done or providing guidance for. Expect to hear back from me soon.

This will let you move from pods to colocated components. We moved everything over.
However, it does not support Octane components, only classic. Not sure how to handle Octane components because they no longer have an outer tag to hang to css  on.

@imagolive tagless and glimmer components should be support by manually adding class={{this.styleNamespace}} to the markup. We've been doing that for tagless for awhile.

Great pickup on the octane components.
In that case, this PR has been working fine for collocated components.
From: Robert Wagner<EMAIL_ADDRESS>Sent: Monday, 18 May 2020 9:34 PM
To: ebryn/ember-component-css<EMAIL_ADDRESS>Cc: Michael Evans<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [ebryn/ember-component-css] Support colocated components (#343)
@imagolivehttps://github.com/imagolive tagless and glimmer components should be supported by manually adding class={{this.styleNamespace}} to the markup. We've been doing that for tagless for awhile.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/ebryn/ember-component-css/pull/343#issuecomment-630186309, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFQ33WXHUP4FTI4MOTOALSTRSE2NHANCNFSM4KLBUDIQ.

spent some time over the weekend getting up to speed with the current state of things, and this PR. Need one more weekend to iron everything out. Will have this merged and altered if needed (or an additional commit or PR merged if needed) early next week.

Template only components have no solution with this iteration. The solution has been to add a "styleNamespace" local variable or helper which can be used to add the namespace where applicable. This is an approach I have been playing around with in the v1 "registry-way" version.
Components that to do not have a wrapping element can manually put in the "styleNamespace" property.

@webark any updates? Anything we can help with?

If we could get that test passed for at least the "unique component paths" test, I'd be fine merging it. I left a comment on what I think is the failing part.
Also, I spend some more time preparing for the 1.0 release, and I think we are all ready to go. It would be nice to get this working so that people can upgrade at their leisure as there are a few breaking changes.

@webark perhaps this is out of scope, but is there any planned support for glimmer components?

@rwwagner90 so for glimmer components, what I have so far, and I'm open to ideas, is what I'm doing is wrapping every template in a let block that adds a local "styleNamespace" variable which you can use. This is what the style file gets namespaced to as well. so you can use those in the components.
Since there is no wrapping element or even a component, that was the best though I had. It would be nice to do that though a helper but wasn't sure how to get a helper to read from where it's being used, so that's, why I went with the wrapping, let block approach.
If you have any suggestions, that would be awesome!

@webark glimmer components can have a JS component. They are not always template only. For template only I think your let block suggestion makes sense, but for ones with JS I would love to keep a similar API to normal with passing this.styleNamespace to class.

@rwwagner90 yea, this is what I'm doing..
https://github.com/ebryn/ember-component-css/blob/60f261f99797864ae5bd730d6d5799dc7a95cac0/lib/scope-templates.js#L15-L19
so it will still be there.

@webark ohhhhh, so you are saying the let is in the library, not a thing we would have to do in our apps? Sorry, I think I misunderstood. It might be helpful to have @chancancode and/or @pzuraq weigh in on how to best work with glimmer, colocated templates, etc in general.

@webark Does this mean that there will be different semantics for template-only glimmer components? i.e. it'll be styleNamespace rather than this.styleNamespace since there's no this without a backing class?

@adambedford yea. I would suggest just always using styleNamespace without the this. It will have to get added as a global for the template lint. If prefer to have it be consistent. I’m going to try the helper again and see if i can get it to work so that it will be consistent

@webark I wonder if rwjblue/ember-template-invocation-location could help in any way, maybe for inspiration or some tips&tricks, with Glimmer components support.
Thank you for looking into this!

@SergeAstapov for the template stuff, this uses a template ast transform. I considered doing that. We could add a fake helper of style-namespace that just gets switched out at build. Doing a dynamic variable name for normal components is handy though cause there have been times where i have inherited that, or pushed it into another component. So giving an actual variable has value.

i guess we could have the ast do the let part and pass in the (this.styleNamespace or "styleNamespace") .. hmm.. that's actually not a terrible idea. I might look into.

might give us the best of both worlds. Handlebars AST's are annoying though.. I might work though that. you'd have to catch the different uses for it.. like it it was passed to another component, or if it was concated, or in a hash helper or whatever

@webark - wrapping every glimmer component in a let block sounds bad for performance I guess? Why not stay only with the helper? That's what I'm currently doing (of course, now I have to manually pass the template's location which must be "fixed"). I can't think of a use-case where the helper wouldn't be enough - even if someone needs a local variable, they could always do a {{#let (style-namespace) as |styleNamespace|}} and use that, right? I would be strongly against wrapping every single component with something that won't be used in 99% of the cases.

@boris-petrov i'm not sure it would be a performance hit, but i agree with the sentiment. It's not ideal, but it's predictable.. I wish every there was an actual story around a finalized identifier for every item (template, component, route, controller, etc) that was part of a public api. I think it would open the door to more possibilities. Even the prevalence of the the use of "_debugContainerKey" in addons (even official addons) implies it's something that would be valuable and is needed.
having a transform of style-namespace to (style-namespace (if this.styleNamespace this.styleNamespace (if this.args.styleNamespace this.args.styleNamespace ${atBuildStyleNamespace})) has its downsides as well.. But i think it could be better.
 But then you'll have some some instances in a code base of style-namespace and others of this.styleNamespace or which isn't great either.
But it's all about trade offs I guess.

@webark - thanks for the discussion and trying to find the best way!
I'm not exactly sure what you want to do with the style-namespace helper but wouldn't it be some compile/runtime thing that will just do something similar to this:
export default class extends Helper {
  compute([componentName]) {
    return podNames[componentName];
  }
}

Just without requiring componentName to be passed?
If that is so, why is there a need for anything else? Can you give me some example where that wouldn't be enough?

No worries! This issue is the main reason this transition has taken so long with not much movement in the codebase. I don't know the best way to do this, so it's helpful to talk it over with someone!! So thanks for discussing!
so, there no "podNames" in the new way. Each style file gets a corresponding "style.js" file that has a "styleNamespace" property on it. the same thing could apply though and you could do an "owner.lookup" with the path to get it's corresponding style file.
But at least in my usage, there are a non insignificant amount of times where i pass in the styleNamespace is n some instances to modify the set of styles that are applied, and would want to accommodate those cases as well.

OK, I'm not familiar with the new way, but are these modifications that you do done in the JavaScript component file or in the template somehow? Because I'm talking only about the template "API" that people will use (that a single style-namespace helper shoild be enough). In the JS they can do anything they want (and ember-component-css could expose all kinds of JS APIs for querying/modifying the CSS I guess). Not sure if what I say makes sense when we're talking about this new implementation though.

@boris-petrov another annoying thing is that the ember parser expects templates to have arguments (which ends up getting added), but the lint rule fails cause it doesn't like a helper with no arguments... :(

wasn't there an RFC about attribute components or something like that?

https://github.com/emberjs/rfcs/pull/353
yea, that hasn't been merged in yet though.. So.. hmm.. :/

@webark there is a new API that was introduced for building the component tree in ember-inspector which might be helpful for finding all the components. We are using it here https://github.com/emberjs/ember-inspector/blob/7f51cab365a275269951057e3ae7ee0278898b77/ember_debug/libs/capture-render-tree.js#L12
I believe it is not on in production by default though and could cause performance issues. If there is something else private that works well, we could talk to Ember Core about making it public.

@webark - element modifiers have been implemented and working in Ember for a while now. Not sure why this RFC is not merged.

ok. I'm going to give these a try.

https://gist.github.com/0366b1f81f1b6c2ae7e086e4709fed4c/45585f8f51d455adf259e447adacf2af18b4962f
this is looking promising.

https://astexplorer.net/#/gist/0366b1f81f1b6c2ae7e086e4709fed4c/latest
This is what is looking promising.

The three parameter names will probably change, but I feel this is the best approach I have yet. It will take an amount of nontrivial migration. :/ But it seems like it is the most sustainable solution.

so this is kind of what the syntax would be.
{{#each this.items as |item|}}

{{/each}}

I'll have to check what setting this on if you can use modifiers on classic invocation style. I don't think so though. At that point you would have to just use the this.styleNamespace I think

so this is kind of what the syntax would be.
{{#each this.items as |item|}}

{{/each}}

Is vairant correct here or should that be variant?

Yes! That was just an example of a string that gets added to the end of the class.. so special meaning

Gotcha, so to be clear the new API would be to use this element modifier in place of this.styleNamespace? Will this work when styles.scss lives in pods or colocated component folders?

@rwwagner90 yea, we got a little off-topic here. It was just where the conversation was happening so I carried it on. But this would be in addition to for mainly template only components.
The co-location stuff I was going to work through next. I already have some preliminary work done on it, but was finishing that up. I'm deciding how much stuff to backport, or to write a legacy bridge, or to modify stuff as is.
if writing a legacy bridge doesn't take too long, I'll pursue that. If it starts to get hairy, I'll just backport the element modifier and co-location work and have this version be octane supportable as well.

@webark please let me know if you need help testing anything.

@rwwagner90 yea. Trying to find the best way to get the namespaces into the handlebars ast. Have a couple of ideas (like adding a temp variable with the ast that gets swapped out later in the post process) but don't see a strait forward way.

ohh.. there's a "meta.moduleName" https://github.com/rwjblue/ember-template-invocation-location/blob/master/lib/ast-transform.js#L207 nice.

so where I am out now.. is currently I am saving a file ```    return `
import EmberObject from '@ember/object';
  export const styleNamespace = "${styleNamespace}"
  export default class extends EmberObject { styleNamespace = styleNamespace };
`;

as a `style.js` file at the same location as the style file. This allows me to look up the file by doing

owner.lookup(style:${stylePath})
The issue with this approach is that with colocation, I can't create a style.js file in the same location as the style file. What I would like to do instead of creating a `style.js` file, is just to take the existing style file and add js to it... so like `style.scss.js` or `index.css.js` or `my-component.less.js`.

However, I want to maintain the same lookup of `owner.lookup(`component:${stylePath}`)` to be analogous to `owner.lookup(`style:${stylePath}`)`. So I need a way to register a `my-component.less.js` file as a "style" namespace based off of the file ending of `(less|css|scss|sass|style).js`.

If I can find a way to register that resolver, then I don't have to do something where during build I look to see if it's a `index.css` and if there is a corresponding `index.(js|hbs)` and if the file path has `/components/` in it to replace that with `/styles/` .. which feels much more brittle.

@webark there are two types of colocation. One is "pod" like where you have a folder for the component with an index.hbs and index.js and another where there is no folder and foo.hbs and foo.js just live in the root component folder. For the nested case, I think looking up paths still works, for the non-nested case, perhaps we treat it like classic, non-pod components?

yea. But since you have an index js and .hbs, the logical thing would be to write a "index.css", but then we can't do another index.js, and will have to name it different. I like the option of importing the "index.css" there, and right now it has the namespace, but could be added with other info. it feels like the best pattern.
i looked into it a little bit, and think i have a way to grab them with the resolver.

ok. @rwwagner90 do not love this... but maybe we can iterate on it.
https://github.com/ebryn/ember-component-css/blob/registry-way/addon/utils/process-style-type.js#L1-L31

@rwwagner90 ok. Added some actual co-location tests, and this is where I am at, which I still don't love this solution.
https://github.com/ebryn/ember-component-css/blob/1b7eea4afa31a7614913ff61cd2a81d8c4872c30/addon/utils/process-style-type.js#L1-L31

and I realized I had forgotten to push the modifier work. So that is not up.
Everything appears to be working now. There are some backward-incompatible changes that I wanted to add an extra optional option to support. But for forward-thinking individuals, who don't mind a small number of renaming somethings, this will suffice.
The breaking changes are listed at the top of #333
I will be releasing a beta soon, and then working on the new documentation before the final 1.0 release

@webark can you clarify what exactly is working now? Does this include colocated components both nested and not? Does it include a way to work with glimmer components, etc? Once I have clarity into which use cases this supports and what changes I need to make, I am happy to give it a try!

@rwwagner90 yep to all! I have a nested test, flat test, and pod test. Also template only and component. I haven't added a "glimmer" component, but either the modifier or the "this.styleNamespace" will work.

and @rwwagner90 if you or anyone else here wouldn't mind helping formulate a "roll out" plan, that would be appreciated. I was going to write one up in #333 later today or tomorrow. Any comments on that would be appreciated. I'll post a link to that once I have it.

it also looks like co-location breaks in 3.12, cause it tries to create a js file from the template, and the name already exists. https://travis-ci.org/github/ebryn/ember-component-css/jobs/711194656

@webark yeah, we should probably only do the co-location bits if Ember >= 3.13.

I think now the lowest common denominator is ember-modifiers. I'm just not sure how to conditionally include the collocated component test.

Well, i want an initial beta, then need to re add back in the various configurations you could have chosen, then a potential backwards compatibility addon, and then splitting up the addon into 3 separate ones and that including them here.

@webark I left a comment here https://github.com/ebryn/ember-component-css/pull/333/files#r460402288 I am not sure if this will work at build time or not, but assuming it will, this would check the Ember version before doing colocated stuff. It uses https://github.com/pzuraq/ember-compatibility-helpers. Maybe give that a try?

yea. The issue isn't with this addon, it's when ember translates the template. It tries to keep the same name and just change the extension.

ok. an "alpha" tag has been published with the version of 1.0.0-alpha.2
https://www.npmjs.com/package/ember-component-css/v/1.0.0-alpha.2
WIll create a new issue with the remaining work to get to a stable 1.0 version soon.

yea. The issue isn't with this addon, it's when ember translates the template. It tries to keep the same name and just change the extension.

Can you say more here? I thought the issue was we wanted to not run colocation stuff if on 3.12 or below?

in the tests dummy app, there is a co located test for an acceptance test. This fails to build on ember 3.12.

there isn't anything logically different it does in order to account for a co located style file.
https://github.com/ebryn/ember-component-css/blob/00b8ba3468754c6978c1e8ba3d0b0c3fc5b4d234/addon/utils/process-style-type.js#L13
and
https://github.com/ebryn/ember-component-css/blob/00b8ba3468754c6978c1e8ba3d0b0c3fc5b4d234/lib/component-names.js#L11
are the only things, but those encompass all.

@webark sorry for the delay in responding, but yeah we should wrap that test in ember-compatibility-helpers.

@webark where are we on this?

@webark 👋 any updates here?

@webark 👋 any updates here?


As this template is writing a config file based on some hashes and ha…

…shes are not meant to be in a certain order,
We need to ensure that the order of the keys are always outputed in the same order.
Otherwise puppet will always update(change) the config file.

Great contribution, thanks a lot. Would you mind having a look at the failed checks? As this modules should be compatible with Puppet 4, it should also pass the future parser tests.

Hi,
The tests are ok now.
Cheers
Marc

great! thanks


Search operation with the exclude option does not work if the workspace is configured in a special way

Type: Bug
Search operation does not work with the exclude option if in the workspace folder configuration the name option is used different from the path option.
.workspace
{
"folders": [
{
"name": "00_program1 (Local)",
"path": "..\00_program1"
}
],
"settings": {}
}
----------------- end .workspace
VS Code version: Code 1.72.2 (d045a5eda657f4d7b676dedbfa7aab8207f8a075, 2022-10-12T22:15:18.074Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz (8 x 2793)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
15.99GB (6.37GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (47)

Extension
Author (truncated)
Version

laravel-extra-intellisense
ami
0.6.2

toolbar-extended-menu
azm
3.0.8

vscode-intelephense-client
bme
1.8.2

turbo-console-log
Cha
2.5.6

quasar-docs
Cod
1.3.1

laravel-goto-view
cod
1.3.7

vscode-eslint
dba
2.2.6

vscode-dash
dee
2.4.0

githistory
don
0.6.19

EditorConfig
Edi
0.16.4

vscode-great-icons
emm
2.1.86

memi-quasar-snippets
fkk
0.0.6

auto-close-tag
for
0.5.14

laravel-ide-helper
geo
1.0.2

laravel-create-view
gli
0.0.6

vscode-drawio
hed
1.6.4

vue-snippets
hol
1.0.4

laravel-blade-wrapper
IHu
1.0.1

cmake-language-support-vscode
jos
0.0.7

i18n-ally
lok
2.8.1

php-namespace-resolver
Meh
1.1.9

git-graph
mhu
1.30.0

dotenv
mik
1.0.1

laravel-intellisense
moh
0.2.0

vscode-language-pack-es
MS-
1.72.10121011

vscode-dotnet-runtime
ms-
1.6.0

vscode-jupyter-cell-tags
ms-
0.1.6

vscode-jupyter-slideshow
ms-
0.1.5

remote-wsl
ms-
0.72.0

laravel-goto-components
nao
1.2.0

printcode
nob
3.0.0

tosnippet
nsf
0.1.3

vetur
oct
0.36.1

laravel-blade
one
1.32.0

laravel-extension-pack
one
1.1.0

laravel5-snippets
one
1.15.0

excalidraw-editor
pom
3.3.3

vscode-thunder-client
ran
1.20.1

LiveServer
rit
5.7.9

laravel-artisan
rya
0.0.28

vscode-blade-formatter
shu
0.20.0

laravel-goto-controller
ste
0.0.15

tinkerun-vscode
tin
0.2.2

pdf
tom
1.2.0

terminal-zoom
try
1.7.1

volar
Vue
1.0.9

zoombar-vscode
wra
1.4.2

(1 theme extensions excluded)

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Update program:
Versión: 1.73.0 (user setup)
Commit: 8fa188b2b301d36553cbc9ce1b0a146ccb93351f
Fecha: 2022-11-01T15:34:06.111Z
Electrón: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19044
En espacio aislado: No
Search operation does not work with the include/exclude option if in the workspace folder configuration the name option is used different from the path option.
--------------------.workspace
{
"folders": [
{
"name": "00_program1 (Local)",
"path": "..\00_program1"
}
],
"settings": {}
}
----------------- end .workspace

Does it work if you remove the parens from the name property?

Yes,
--------------------.workspace
{
"folders": [
{
"path": "..\00_program1"  <-- OK
},
{
"name": "00_program2 (Local)", <-- Not run
"path": "..\00_program2"
},
{
"name": "00_program3_Local", <-- Not run
"path": "..\00_program3"
},
],
"settings": {}
}
----------------- end .workspace

/duplicate - see https://github.com/microsoft/vscode/issues/137914#issuecomment-1296392380
As a workaround you could use <...> instead of (...)

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Issue loading default settings on production server

Just launching a project onto AWS (fargate) servers & we're unable to login due to a missing setting. Although it's one of the axes defaults, so it's not being loaded properly.
This is happening only on the AWS setup, unable to replicate locally or within our docker setup which builds our fargate containers when running docker-compose. Which makes this an awkward issue to raise.
Trying to login via admin results in the following;
AttributeError: 'Settings' object has no attribute 'AXES_PROXY_ORDER'
  File "django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "django/views/decorators/cache.py", line 44, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)
  File "django/contrib/admin/sites.py", line 399, in login
    return LoginView.as_view(**defaults)(request)
  File "django/views/generic/base.py", line 71, in view
    return self.dispatch(request, *args, **kwargs)
  File "django/utils/decorators.py", line 45, in _wrapper
    return bound_method(*args, **kwargs)
  File "django/views/decorators/debug.py", line 76, in sensitive_post_parameters_wrapper
    return view(request, *args, **kwargs)
  File "django/utils/decorators.py", line 45, in _wrapper
    return bound_method(*args, **kwargs)
  File "django/utils/decorators.py", line 142, in _wrapped_view
    response = view_func(request, *args, **kwargs)
  File "django/utils/decorators.py", line 45, in _wrapper
    return bound_method(*args, **kwargs)
  File "django/views/decorators/cache.py", line 44, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)
  File "django/contrib/auth/views.py", line 61, in dispatch
    return super().dispatch(request, *args, **kwargs)
  File "django/views/generic/base.py", line 97, in dispatch
    return handler(request, *args, **kwargs)
  File "django/views/generic/edit.py", line 141, in post
    if form.is_valid():
  File "django/forms/forms.py", line 185, in is_valid
    return self.is_bound and not self.errors
  File "django/forms/forms.py", line 180, in errors
    self.full_clean()
  File "django/forms/forms.py", line 382, in full_clean
    self._clean_form()
  File "django/forms/forms.py", line 409, in _clean_form
    cleaned_data = self.clean()
  File "django/contrib/auth/forms.py", line 205, in clean
    self.user_cache = authenticate(self.request, username=username, password=password)
  File "django/contrib/auth/__init__.py", line 73, in authenticate
    user = backend.authenticate(request, **credentials)
  File "axes/helpers.py", line 459, in inner
    return func(*args, **kwargs)
  File "axes/backends.py", line 44, in authenticate
    if AxesProxyHandler.is_allowed(request, credentials):
  File "axes/handlers/proxy.py", line 82, in is_allowed
    cls.update_request(request)
  File "axes/handlers/proxy.py", line 69, in update_request
    request.axes_ip_address = get_client_ip_address(request)
  File "axes/helpers.py", line 161, in get_client_ip_address
    proxy_order=settings.AXES_PROXY_ORDER,
  File "django/conf/__init__.py", line 80, in __getattr__
    val = getattr(self._wrapped, name)

Looking at django-appconf we assume that the issues comes from this section of code;
        prefix = getattr(meta, 'prefix', getattr(meta, 'app_label', None))
        if prefix is None:
            # Figure out the prefix by looking one level up.
            # For 'django.contrib.sites.models', this would be 'sites'.
            model_module = sys.modules[new_class.__module__]
            prefix = model_module.__name__.split('.')[-2]

Therefore the solution to this would be to set the prefix via the meta in AxesAppConf to avoid sniffing the module name & be explicit about the setting prefix.

So this appears to fix it;
https://github.com/jazzband/django-axes/compare/master...marksweb:fix/585
Running that branch at the moment to watch out for anymore errors. They were happening sporadically since I reported this.

Hi @marksweb! Thanks for reporting. What is the configuration you are running on Fargate? Are you building custom Docker containers and how are you provisioning them? Would you mind posting the Dockerfile with Python and Django version information and the ECS / Fargate configuration if you can?

A fix for this has been released in version 5.3.2 and is now available on PyPI.
https://pypi.org/project/django-axes/

Fantastic @aleksihakli - thank you!
Yeah we're building docker containers with django 2.2.12
Here's our dockerfile (varnish only got added today)
# Pull base image
FROM python:3.7.7-slim-buster AS python-base

ENV PYTHONUNBUFFERED 1
ENV PIP_NO_CACHE_DIR 1

COPY requirements.txt /requirements.txt
RUN apt-get update && \
    apt-get -y upgrade && \
    apt-get install --no-install-recommends -y \
        python3-dev \
        build-essential \
        libmariadb-dev \
        libnss3-dev \
        curl \
        libcurl4-gnutls-dev && \
    pip install --upgrade pip && \
    pip install -r /requirements.txt && \
    pip install --no-cache-dir uwsgi==2.0.18 && \
    apt-get -y remove build-essential && \
    apt-get -y purge --auto-remove && \
    rm -rf /var/lib/apt/lists/*
ENV DOCKER_BUILD 1

# NPM business
FROM node:10 AS frontend-deps-npm
WORKDIR /
COPY ./package.json /package.json
RUN npm install
COPY . /app
WORKDIR /app
RUN /node_modules/gulp/bin/gulp.js

# Build static collection
FROM python-base AS frontend-deps
COPY --from=frontend-deps-npm /app /app
WORKDIR /app
RUN python manage.py collectstatic -v 2 --noinput

# Build nginx frontend
FROM nginx:1.17.8-perl AS frontend
# The final frontend container image from the nginx base image.
# dnsmasq is necessary to work around resolver differences between local docker (for both Mac and Linux),
# and also Fargate. supervisor is required to run both dnsmasq and nginx in the same container.
RUN apt-get update && \
    apt-get -y upgrade && \
    apt-get install --no-install-recommends -y dnsmasq supervisor varnish
COPY --from=frontend-deps /app/static-collection /app/static-collection
COPY ./config/varnish/default.vcl /etc/varnish/default.vcl
COPY ./config/varnish/varnishncsa_format.txt /etc/varnish/varnishncsa_format.txt
COPY ./config/varnish/check-varnish.sh /usr/bin/check-varnish.sh
COPY ./config/nginx/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY ./config/nginx/nginx.conf /etc/nginx/nginx.conf
ENV NGINX_HOST=webapp
ENV NGINX_PORT=9000
ENV DEV_MODE=no

# Check Varnish & Nginx configs
RUN check-varnish.sh && \
	nginx -c /etc/nginx/nginx.conf -t

EXPOSE 6051
CMD ["supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]

# Build final app-container
FROM python-base AS app
COPY . /app
COPY --from=frontend-deps /app/static-collection/staticfiles.json /app/static-collection/staticfiles.json
WORKDIR /app
EXPOSE 8000
EXPOSE 9000

Is there anything specific you're interested in with the ECS setup? I haven't built that side of things, just this side, but have access to the cloud formation scripts.

Since this issue was fixed with the patch, I guess using any further time on this could be considered purely academical. It would be nice to understand why Axes works for most users, but not with the Docker (and Fargate) setup, though.
First off, I don't think Fargate has anything to do with it, and the problem is most likely with the Docker image build.
I don't see anything alarming in the build chain. One thing that might be good to check here is that is your package metadata being transferred correctly through the multi-stage build?
Python saves the installed packages and their stuff under dist-packages (Debian specific) and site-packages (platform agnostic). If the package metadata about installations or other stuff is being dismissed in later stages , then that might cause axes not initializing the prefix string in the Meta class for django-appconf package correctly?
You can debug the build chain with Docker and see what is available in different stages:
https://docs.docker.com/develop/develop-images/multistage-build/#stop-at-a-specific-build-stage
One interesting thing would be to compare the base build with the 1st Python build stage and the final build and what imports and packages they have available in the target environment. I haven't really gotten too deep into multi-stage builds and this is just a gut feeling about the possible cause of the issue.

Just wanted to inform you Axes has been working fine for me with Docker & AWS Fargate.


custom size

I am on cups 2.2.0 I have paper that i need to do borderless printing on. 9x13

That size is not an option on GENERAL/PAPER SIZE drop down.
Can I go into the ppd file and add a line of code that puts that size in the list?
@michaelrsweet
@22350 That really depends on the printer/driver. If the PPD supports custom sizes then you can define a custom size ("Custom.9x13in" at the command-line) without editing the PPD file. Whether the application supports this depends on the OS and GUI environment used...>
sorry if i am using this forum incorrectly, but the subject was closed right away.
I am on a mac. with an epson artisan 1430 currently only certain sizes are supported for "borderless" , although the physical characteristics of the printer have no limitations for this functionality.
Is CUPS using the epson ppd file or can i manually add one with the correct parameters ?

You can continue to post comments on closed issues; I only close them to keep the issue tracker clear of questions - the mailing lists are the preferred method of asking questions...


Vue

Implemented in beta for now.
@sarafischer check if advanced search is working and then mark as done.

Advanced Search:

display input fields again (done)
correct index error (done)
check why after generating a search result the advanced search is unavailable
check why previous inputs from a search are not used to generate rows


cluster membership: user with custom membership in the cluster when tries to add user, console errors are seen

Rancher version: master-head 54d4afc

Create a node driver rke2 DO cluster with 1 node all roles
Create a user - user1 from global --> Users and Auth and add the user in the cluster with custom View Nodes permissions
Login as user1 and from Cluster --> RBAC --> cluster members --> add members --> create page is blank with no warning message and following are the console logs seen:

Expected Result:
Create page should display warning as displayed on ember UI when users with custom permissions in the cluster create a member.
clusterroletemplatebindings.management.cattle.io is forbidden: User "u-ktngj" cannot create resource "clusterroletemplatebindings" in API group "management.cattle.io" in the namespace "c-m-419cc0e6"

https://github.com/rancher/dashboard/issues/2501

In dashboard we're not even supposed to show the resources in the navigation if the user doesn't have access. I'm fixing this so the user doesn't see the resource therefore we won't show this page or an error message.

Verified on master-head 741adaf

Create an rke2 nodedriver DO 1 node all roles cluster.
Once the cluster is active, if we navigate to explorer --> Cluster members, add a user with View Projects only permission in the cluster members.
Log in as the user and verified the user do not have permissions to view the RBAC option.


Access HTTP Body from Web Actions

Provide __ow_meta_body argument that allows access to the content of the HTTP body passed to a Web Action only when the x-ow-raw: true HTTP header is provided.

@csantanapr

@dubeejw when you add a change like this - please add a test with it (or mark it wip with a comment).

PG2 1191, approved.

superseded by #2004.


Add VIM Scala support

Added the vim-scala plugin from
https://github.com/derekwyatt/vim-scala

Please keep this in your fork 👍 I am not willing to add languages that I don't use myself.


Rollup error: Could not resolve './_nuxt/style.de09fa41.js'

Environment

Operating System: Linux
Node Version:     v16.13.2
Nuxt Version:     3.0.0-rc.8
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      app, algolia, content, nitro, extends, github, theme, modules, plausible, colorMode
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
https://codesandbox.io/s/beautiful-perlman-vxjlu0?file=/package.json
Describe the bug
If you run yarn build you get the error.
Additional context
This probably releated also to nuxt/nuxt.js#14667. Since i also get the error if i run yarn dev.
Logs
ERROR  Rollup error: Could not resolve './_nuxt/style.de09fa41.js' from .nuxt/dist/server/server.mjs                                                                                nitro 09:01:08

 ERROR  Could not resolve './_nuxt/style.de09fa41.js' from .nuxt/dist/server/server.mjs                                                                                09:01:08

  at error (node_modules/rollup/dist/es/shared/rollup.js:1858:30)
  at ModuleLoader.handleResolveId (node_modules/rollup/dist/es/shared/rollup.js:22350:24)
  at ModuleLoader.resolveDynamicImport (node_modules/rollup/dist/es/shared/rollup.js:22404:120)
  at async node_modules/rollup/dist/es/shared/rollup.js:22299:32

yarn dev ERROR Logs
[nuxt] [request error] [unhandled] [500] Cannot read properties of undefined (reading 'modules')
  at _sfc_main.setup (./node_modules/nuxt/dist/app/components/nuxt-root.vue:67:16)
  at callWithErrorHandling (./node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:157:22)
  at setupStatefulComponent (./node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:7084:29)
  at setupComponent (./node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:7039:11)
  at renderComponentVNode (./node_modules/@vue/server-renderer/dist/server-renderer.cjs.js:172:17)
  at renderToString (./node_modules/@vue/server-renderer/dist/server-renderer.cjs.js:446:26)
  at Object.renderToString$1 [as renderToString] (./.nuxt/dev/index.mjs:2925:24)
  at Object.renderToString (./node_modules/vue-bundle-renderer/dist/runtime.mjs:173:40)
  at processTicksAndRejections (node:internal/process/task_queues:96:5)
  at async ./.nuxt/dev/index.mjs:2974:21

This isn't just an Algolia  module issue, it happens even if we're importing a CSS file inside of the script part in a template, so I  guess this is worth some investigating.
for example I'm including a style inside of the @/app.vue file following the guide in Nuxt 3 Docs and vue docs as well:
<script>
// Note: the same issue is present even if the import statement was to be used inside of any other page.
import("@/style.css");
</script>

<template>
  <NuxtPage />
</template>

when I run npm run dev everything works as expected, but when I run npm run build it doesn't build, the error log is the following:
PS D:\CODE\X-DASHBOARD> npm run build

> build
> nuxt build

Nuxi 3.5.3                                                                                8:01:31 PM
Nuxt 3.5.3 with Nitro 2.5.1                                                                                8:01:31 PM
ℹ Using default Tailwind CSS file                                                                                nuxt:tailwindcss 8:01:33 PM
ℹ Building client...                                                                                8:01:35 PM
ℹ vite v4.3.9 building for production...                                                                                8:01:35 PM
ℹ ✓ 130 modules transformed.                                                                                8:01:37 PM
ℹ .nuxt/dist/client/manifest.json                        2.91 kB │ gzip:  0.53 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/style.a4ce5984.css             0.33 kB │ gzip:  0.25 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/error-500.b63a96f5.css         2.02 kB │ gzip:  0.75 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/error-404.8bdbaeb8.css         3.70 kB │ gzip:  1.13 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/entry.f2350f0e.css            12.51 kB │ gzip:  3.32 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/auth.db233364.js               0.27 kB │ gzip:  0.23 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/login.8d5ba838.js              1.05 kB │ gzip:  0.63 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/error-component.d703e9c4.js    1.12 kB │ gzip:  0.61 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/error-500.e025afee.js          1.88 kB │ gzip:  0.99 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/index.7ff73429.js              2.28 kB │ gzip:  0.91 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/error-404.43f5cad4.js          6.50 kB │ gzip:  2.88 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/fetch.a9da3656.js             11.44 kB │ gzip:  4.65 kB                                                                                8:01:37 PM
ℹ .nuxt/dist/client/_nuxt/entry.274a5e48.js            155.38 kB │ gzip: 58.25 kB                                                                                8:01:37 PM
ℹ ✓ built in 2.17s                                                                                8:01:37 PM
✔ Client built in 2201ms                                                                                8:01:37 PM
ℹ Building server...                                                                                8:01:37 PM
ℹ vite v4.3.9 building SSR bundle for production...                                                                                8:01:37 PM
ℹ ✓ 81 modules transformed.                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-404-styles.88dd483b.mjs        0.08 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-500-styles.f7652148.mjs        0.08 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/styles.mjs                                 0.35 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/index-e12b288f.js                    0.22 kB │ map:  5.28 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/css-styles-2.mjs-4619f099.js         0.44 kB │ map:  0.11 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/island-renderer-cbbea6bd.js          1.17 kB │ map:  1.39 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/login-34f29fec.js                    1.37 kB │ map:  1.51 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-component-75195197.js          2.04 kB │ map:  2.71 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-500-styles-1.mjs-cf69c072.js   2.23 kB │ map:  0.12 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-dev-styles-1.mjs-a4b72ba9.js   2.59 kB │ map:  0.12 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-500-95744b2c.js                3.16 kB │ map:  3.79 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/index-d716c650.js                    3.37 kB │ map:  3.45 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-404-styles-1.mjs-00a5a0fd.js   3.93 kB │ map:  0.12 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/auth-7afa8e14.js                     6.51 kB │ map: 14.86 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/error-404-5e22edf7.js                9.79 kB │ map: 18.88 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/_nuxt/css-styles-1.mjs-6e20aa38.js        12.35 kB │ map:  0.11 kB                                                                                8:01:38 PM
ℹ .nuxt/dist/server/server.mjs                                32.06 kB │ map: 75.97 kB                                                                                8:01:38 PM
ℹ ✓ built in 1.05s                                                                                8:01:38 PM
✔ Server built in 1061ms                                                                                8:01:38 PM
✔ Generated public .output/public                                                                                nitro 8:01:38 PM
ℹ Building Nitro Server (preset: node-server)                                                                                nitro 8:01:38 PM

 ERROR  RollupError: Could not resolve "./_nuxt/style-15c73386.js" from ".nuxt/dist/server/server.mjs"                                                                                nitro 8:01:44 PM

undefined

 ERROR  Could not resolve "./_nuxt/style-15c73386.js" from ".nuxt/dist/server/server.mjs"                                                                                8:01:44 PM

  at error (/D:/CODE/X-DASHBOARD/node_modules/rollup/dist/es/shared/node-entry.js:2213:30)
  at ModuleLoader.handleInvalidResolvedId (/D:/CODE/X-DASHBOARD/node_modules/rollup/dist/es/shared/node-entry.js:24219:24)
  at ModuleLoader.resolveDynamicImport (/D:/CODE/X-DASHBOARD/node_modules/rollup/dist/es/shared/node-entry.js:24277:58)
  at async /D:/CODE/X-DASHBOARD/node_modules/rollup/dist/es/shared/node-entry.js:24166:32

Op system: Win11 (but this has nothing to do with the issue since i have tested the same code on a Linux machine and everything is the same)
Node version: 18.16.0
My package.json:
{
  "name": "nuxt-app",
  "private": true,
  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare"
  },
  "devDependencies": {
    "@nuxt/devtools": "latest",
    "@nuxtjs/tailwindcss": "^6.8.0",
    "@types/node": "^18",
    "@types/toastify-js": "^1.11.1",
    "nuxt": "^3.5.2"
  },
  "dependencies": {
    "@nuxtjs/harlem": "^1.3.0",
    "toastify-js": "^1.12.0"
  }
}

Note: this isn't really an issue and it can totally be ignored since we can add styles in other methods such as in the nuxt.congif.ts file just as the Nuxt 3 Docs point out
export default defineNuxtConfig({
    css<EMAIL_ADDRESS>})

Would you open a new issue with a reproduction, please? 🙏

added #21803


_strict_response_validation deprecation and Azure content filters

Confirm this is an issue with the Python library and not an underlying OpenAI API

[X] This is an issue with the Python library

Describe the bug
If _strict_response_validation may be deprecated, will the fixed behavior be set to False?
The Azure content filter annotation requires object attribute set to "". It relies on _strict_response_validation=False:
https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/content-filter?tabs=warning%2Cuser-prompt%2Cpython-new#annotations-and-sample-responses
To Reproduce

Enable content filters in Azure OpenAI Service.
Stream chat completions with client:

client = AzureOpenAI(
    azure_endpoint="<azure-endpoint>",
    azure_deployment="gpt-4-turbo",
    api_key="<api-key>",
    api_version="2024-02-01",
    _strict_response_validation=True # This will make strict validations and the request will fail.
)

Error:
Input should be 'chat.completion.chunk' [type=literal_error, input_value='', input_type=str]

Code snippets
No response
OS
Ubuntu 22.04
Python version
v3.10.0
Library version
v1.37.1

Yes if _strict_response_validation is removed, the fixed behaviour will be _strict_response_validation=False.
We also have no plans to support _strict_response_validation=True for the Azure client.
Out of curiosity are you using this flag in the standard client? We haven't heard of anyone actually enabling this behaviour yet.

also cc @kristapratico r.e. azure behaviour here, it's surprising that an empty string is returned in this case but I don't have full context, is this intentional?

Out of curiosity are you using this flag in the standard client?

@RobertCraigie No. I have no application for _strict_response_validation=True.

@kristapratico Reference: https://github.com/mlflow/mlflow/issues/12767


Ray cluster with CPU head + GPUs Workers - No GPUs available

Hi, I'm trying to use the RayShardedPlugin plugin on a CPU head + GPU workers Ray cluster. However, PL currently complains about not having any GPUs available. Is there any workaround for this use case?
pytorch_lightning.utilities.exceptions.MisconfigurationException: Error instantiating 'pytorch_lightning.trainer.trainer.Trainer' : You requested GPUs: [0]
 But your machine only has: []

Thanks,.

@igorgad can you set gpus=0 in your Trainer, but still set use_gpu in the RayPlugin

Thanks @amogkam, it worked great. The documentation needs some update though.


Add timed-out message in Cluster Ping test

Notes for Reviewers
This PR fixes #7671
Signed commits

[x] Yes, I signed my commits.

@8rxn  Could you please add a relevant meshkit error instead of printing the erro

@8rxn  Could you please add a relevant meshkit error instead of printing the error

Will look into it and make the changes.

Hey @Azanul
I couldn't find an existing meshkit error that was relevant. Should I create a new one?

Hey @Azanul
I couldn't find an existing meshkit error that was relevant. Should I create a new one?

Yes

Hey @Azanul
I've added a new Meshkit error with code 2261 and returned that. Could you please review it.

Increase the timeout to 5 secs

@8rxn Read the desired behaviour in the issue and see if after your changes it fits or not

@8rxn Read the desired behaviour in the issue and see if after your changes it fits or not

Sorry for the inconvenience but,
I think it might be lacking in the "connection should not be dropped" part.
I must've over looked that before sending this PR mostly because I lack the understanding of how that works and couldn't figure out a way to test it.
I would appreciate if you could guide me on how I can correct this,
There's 2 references to PingTest() , I think there must be changes made at AssignServerID() and NewK8sContextWithServerID() where the Ping is invoked but correct me if I'm wrong.

@8rxn Go through the code and try to figure out how or from where the notification is being sent to user since that is something that we want to do here as well.

Nice work on including a Meshery Error Code.

@8rxn Go through the code and try to figure out how or from where the notification is being sent to user since that is something that we want to do here as well.

If you're having a hard time doing this then feel free to reach out.

Yeah, For sure. It's just that I haven't been able to work on this issue for the past few days after the last update. Will be working on it now.

Hey @Azanul, Requesting some guidance on this

@8rxn are you working on this?

@8rxn are you working on this?

Ah, I lost track of the PR. The notification is yet to be implemented using Broadcaster.
Currently I cannot work on it for a few more days ( about a week, Out of town and Go is not my
best territory ).
With what I did last, I thought an implementation close to this could be used, got confused in go and lost track working on different things.:
		r.Broadcast.Submit(broadcast.BroadcastMessage{
			Source: broadcast.OperatorSyncChannel,
			Data: operatorStatusK8sContext{
				processing: ErrNilClient,
				ctxID:      ctxID,
			},
			Type: "error",
		})

With that said, if someone is willing to, it may be reassigned to get it done with sooner.

UI tests are failing..., updating the branch.


Decode typed String dictionaries

This adds support for decoding typed dictionaries with a String key, specifically:
[String: JSONObjectConvertible]
[String: JSONRawType]
[String: JSONPrimitiveConvertible]
Includes optional variants and tests

Current coverage is 93.95% (diff: 66.66%)

Merging #8 into master will decrease coverage by 6.04%

@@           master         #8   diff @@
========================================
  Files           5          5
  Lines         149        182    +33
  Methods         0          0
  Messages        0          0
  Branches        0          0
========================================
+ Hits          149        171    +22
- Misses          0         11    +11
  Partials        0          0

Powered by Codecov. Last update ffb76f6...d36fe41

Thanks for the PR.
Would it be possible to add some unit tests for the [String: JSONPrimitiveConvertible] and [String: JSONPrimitiveConvertible]? cases? Also could you rebase this branch onto the latest master since the branch is out-of-date?
Out of curiosity really, I never had a need to use typed dictionaries, what's the use case for this?

Rebased off master, added JSONPrimitiveConvertible tests, and squashed commits 👍
Typed dictionaries are for json structures where the keys are not known up front. For example in this json http://petstore.swagger.io/v2/swagger.json there are a variable number of keys under paths such as paths./pet, so we can create a [String: Endpoint] dictionary where the key is the path


Istio dashboard: Uninstalling istio and re-installing istio missing the install into project option

Rancher Version:
Rancher | v2.5-8d5b3b8d933d04b04e0f0ae3a23d48d0a962c53f-head
User Interface | v2.5-dev
Helm | v2.16.8-rancher1
Machine | v0.15.0-rancher49
Istio version: 1.7.600
Steps:
Create a cluster and enable monitoring and istio [install into project - system]
Once the apps are installed successfully, deploy a few workloads.
Uninstall the istio app and when we try to reinstall the app, we see that the project into which the app has to be installed is missing [installing in the system project without the install in project option]

Install into project option for fresh installation:

Issue seen on v2.5-8d5b3b8d933d04b04e0f0ae3a23d48d0a962c53f-head and master-3ba112acba52c36b87c2bf88c40a64c693fba41d-head

The project being missing indicates that Istio is already installed into that namespace, so we need to add information saying that it already exists so the user knows.

The project being missing indicates that Istio is already installed into that namespace, so we need to add information saying that it already exists so the user knows.

this happens for any app that is uninstalled. I tested with monitoring, longhorn, webhooks and all have this issue:
How to repro:

go to install an app through apps and marketplace

install the app

try to upgrade the app

alternatively, uninstall the app then try and reinstall the app

The user should still have the option to select a project after uninstalling
So would this mean that something isn't being cleaned up on uninstall that should be?

@slickwarren the namespace into which the app is installed under the given project will not be cleaned up. Therefore, it installs in the same namespace every time we try to install it, after uninstalling the app. If we delete the namespace eg., for istio - istio-system under the projects before re-trying, the "install into project" option appears for the app:

It is not really "any" app, but apps that specify that they be installed into a particular namespace, which is mostly just our add-on charts.
Apps go into a namespace.  The project is a property of the namespace, not the app.  When you install an app you choose an existing or create a new namespace (unless the chart requires a particular one, which again ours almost all do).  When you are creating a namespace as part of installing an app, you can choose the project that namespace will be assigned to.
When you remove the app the namespace is not deleted (because we have no good idea if that namespace contains other stuff).
If you subsequently reinstall (or just upgrade without removing) that app, the namespace now already exists, so you do not get a choice of what project it should be in.

Verified on v2.5-41f173ae93c6692f44054fe0b02ce93bd3056a9f-head
Install istio from cluster explorer --> Apps and marketplace --> istio [default project]
Once istio is active, uninstall istio and when tried to install again, select project, warning is displayed

Remove namespace, cluster explorer --> Namespaces --> istio-system, warning is not shown


Fix deploy pages

Also rename the workflow so it's clear which workflow is being ran.
Fixes: #42

@dependabot rebase


Twitter auth

#123

Pull Request Test Coverage Report for Build 634

26 of 30 (86.67%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 98.612%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/app/features/auth/effects/user.effects.ts
1
5
20.0%

Totals

Change from base Build 623:
-0.2%

Covered Lines:
2098

Relevant Lines:
2115

💛  - Coveralls


APIs are needed to cover cases where microservices depend on other microservices

Currently, as of v0.1.0-rc.6, it is impossible to have complex microservice dependencies. If microservice A depends on microservice B, and microservice B depends on microservice C, there is no way for each respective microservice to wait for the microservices that it depends on to be running. There should be APIs to allow for this type of behavior to happen.

On second thought, this might be a code-smell.
Real world scenario:
RoundController() which calls MusicController:PlayMusic(ID), which calls PlayerController:GetSetting("MusicMuted"), which calls DataController:GetData(), which makes the assumption that the player's data has been fully loaded and is available
In this scenario, one could argue that a specific load-order for the initialization and running of microservices are needed to ensure that the DataController is ran first. However, a proper solution to this would to simply have PlayerController:GetSetting() yield until the player's data becomes available.


Compiling without Bullet seems to cause issues.

I have a version of DART built without Bullet, and I am getting the following error when compiling AIKIDO:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
BULLET_INCLUDE_DIR

This might be a configuration issue in the exported DART config, I'm not sure yet.

This was resolved for master. Maybe I should backport this to dart-prl0.

I see, I don't need a fix right now, but it would be useful to address this whenever we next update the DART fork.

I'm not sure if i should keep this open or not since it is an upstream issue.

I simply cherry-picked the commit to personalrobotics/dart so you would be fine if you build and install DART from source.
The reason I don't reupload dart-prl0-dev with the fix is that DART 6.0 will be released any soon once one last PR of DART is finished, which I'm currently working on.
We can leave this open until we get to using DART 6.0 for aikido.

That all sounds good, thanks @jslee02!


Disable docker save with image IDs

Signed-off-by: Shishir Mahajan<EMAIL_ADDRESS>

Fixes #10592
@tiborvass if you are okay with the error message.
I ll add more details in the man page.
Let me know if there are other places I need to add documentation for this.
Shishir

@shishir-a412ed the "Fixes #XXX" has to be in the PR description (first comment in the thread), not in a comment after.

This breaks existing functionality.  This is an issue with load and overwriting existing data, not with saving.


Do not allow send to empty account (Native token balance = 0) on Asset Hub

Describe the task
Do not allow send to empty account (Native token balance = 0) on Asset Hub
Actual: Allow transfer but transaction failed
Expect: Do not allow transfer and show error message

Version test: http://<IP_ADDRESS>:8900/s/bdyzDXn9LXJrrk4

[ ] Update message: "The recipient account has 0 DOT which can lead to your DED being lost. Change recipient account and try again"
@bluezdot please find an account with a DOT locked balance


Linkvertise Bypass appears to no longer work

Domain
https://linkvertise.com/
Link
https://linkvertise.com/449204/tds-auto-farm-status-ud/1
Version
0.0.0
What browsers are you seeing the problem on?
Chrome
What OS are you seeing the problem on?
Windows
Anything else?
Expected result --> Bypass the link
Result --> Refer to image below

I tried
-Reinstalling the extension
Same thing, nothing happened. This was not the case with the previous versions
Result after doing the captcha:

Same here it doesn't auto bypass but click free works (as in dont have to wait/install etc)

Duplicate issue, see #51.


Verify why app cannot connect to sqlite on some devices

Start with this: https://learn.microsoft.com/pl-pl/dotnet/standard/data/sqlite/encryption?tabs=netcore-cli

Fixed by #21


Control interface

Our register interface handles well the block to be hashed, as several tests for different parameters have shown.
What lacks so far is the communication with the core of the algorithm.
It's something to be defined as generic as possible for all components but I will focus on Secure Hash Algorithms for this issue.
I propose to add the following 32-bit  registers to handle communication with the core of the algorithm:

Round counter: at any given cycles, holds the round counter value. For sha1 for example this value would be between 0 and 79. This is a Read Only register.
Hash cycle: at any given cycle, holds the number of time the hash algorithm was performed. This could be compared with the specified message length value hold in the 64 LSBs of the block, so that users know the algorithm situation. Also Read Only.
Control register: The control register could hold three bits as a starting point. One could be something like enable (R/W) and could be a way to start the computation. An other bit could be used to hold the calculation, this is intended for longer messages so that next value to be computed can be written to the registers. One reset bit to stop and reset calculation can be thought of. Finally, one could be initial_state (RO) to inform the user that the algorithm is at its initial point: it could be designed with a FSM in the core of the algorithm.

@FromagePatin if you have time to check this out

I agree with the following 32-bit registers you described.
Please find above my comments :

Hash cycle : what do you mean by hash cycle ? According to the Secure Hash Standard specification (FIPS PUB 180-4), there are N messages blocks M and each message block M has a round counter value (80 for sha1 and 64 for sha256). Do you consider a message block M as a hash cycle ?

Yes a message that requires say N blocks has N hash cycles. So a message that is single block will have 1 hash cycle.

To continue on this, I think we should just support a memory mapped digest, it'll make things much easier.
Proposed description of registers (addresses are not shown since it's all generic):

Register Name
Description
Width
Access Rights

Block Register

Data
Input data block for SHA core computation
Configurable
Read/Write

Control and Status Register

Enable Hash
Enables or disables the hashing algorithm
1 bit
Read/Write

Reset Hash
Resets the state of the hashing algorithm
1 bit
Read/Write

Hold State
Indicates if the SHA core is in the hold state
1 bit
Read Only

Idle State
Indicates if the SHA core is in the idle state
1 bit
Read Only

Digest Valid
Hash output valid
1 bit
Read Only

Hash digest

Digest
Digest output
Configurable
Read Only

Most of this is already supported, the digest valid bit and digest registers must be added.


chore(manifest): simplify load balanced/backend service struct

Simplify BackendService and LoadbalancedWebService by removing fields that are duplicated with the corresponding config struct. Addressing feedback https://github.com/aws/amazon-ecs-cli-v2/pull/970#pullrequestreview-419569244

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@mergifyio refresh


hydrate promise is not resolved on Android, but works on iOS

I had been developing testing on iOS and I noticed that the hydrate promise is not resolved on Android. I'm new to RN so it's probably something I'm doing wrong, but the fact that it's working on iOS is puzzling.
My store is like this:
class User { //UserStore
  @observable id = 0;
  @observable loading = false;
  @action setUser(json) {
    this.clearUser();
    this.id = json.user.id;
    this.authToken = json.user.token;
    this.name = json.user.name;
    this.email = json.user.email;
    this.loading = false;
  }

  ...

  ...

  @action clearUser() {
    this.id = 0;
    this.authToken = '';
    this.name = 'N/A';
    this.email = '';
  }

  @persist @observable authToken = '';
  @persist @observable name = 'Anonymous';
  @observable email = '';

}

And in my starting js file I load it like this:
const hydrate = create({ storage: AsyncStorage });

@observer
class LauchContainer extends Component {
  constructor(props) {
    super(props);
    this.props.token = user.authToken;
  }

  componentDidMount() {
    console.log('hydrating');
    hydrate('user', user)
      .then(() => {
        console.log(user);
        if (user.authToken == '') {
          SplashScreen.hide();
          Actions.login();
        } else {
          console.log('we have token, check if it is valid');
          Api.hello().then(() => {
            ...
            }
          });
        }
      }).catch((e) => {
        console.log('hydration failed');
        alert(e);
      });
}

The above work perfectly on iOS but nothing is logged in Android and nothing runs inside the promise callback.
Am I missing something?

"mobx": "^3.3.1",
"mobx-persist": "^0.4.1",
"mobx-react": "^4.3.4",
"react": "16.0.0",
"react-native": "0.50.1",

Scratch that, now it worked after 20 or so reloads. I guess for some reason it was really slow to resolve but it seems to be working.
Also, thanks for this great lib, it's a lifesaver!


Allow Chef to optionally use SSL for establishing database connections

Description
This change allows Chef services and omnibus cookbooks to be configured to use SSL to connect to the PostgreSQL database. This is necessary when using Azure Database for PostgreSQL as an external database securely, without disabling Enforce SSL.
This change will not actually work until https://github.com/chef/chef_secrets/pull/26 is merged and the dependency is updated here.
Issues Resolved
#1559
Check List

[ ] New functionality includes tests
[ ] All tests pass
[x] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

One thing to note is that this attribute is only useful for external PostgreSQL, it will not configure the internal PostgreSQL instance.
A potential follow up to this might be to either

have a new attribute that sets the sslmode for the internal PostgreSQL instance or
have this attribute also control internal PostgreSQL's sslmode if you are using internal PostgreSQL

@irvingpop Included you in this review for your knowledge of external postgresql usage patterns.

@irvingpop Included you in this review for your knowledge of external postgresql usage patterns.

Thank you very much for your contribution to Chef Infra Server. Our apologies for not being able to pick this up sooner. We are currently testing and including your changes in #1711 and are closing this pr in favor of that.


Sometimes an accidental double module definition puts jsdoc in an infinite loop

I accidentally ended up with a code file
/**
  * @module example/b/c
  **/
/**
  * @module example/b/c
  **/

the strange thing is that this didn't cause a problem until I added an extra jsdoc on a function in a unrelated file. It seemed that no matter what function I added jsdoc for (I tried disabling different functions on or off) once the unrelated file count went over a certain amount, jsdoc hung.
I debugged..

and to my surprise found a unrelated file was causing the problem, spotted the double module definition and fixed it.
I was using the latest master.
It should probably warn or error when you have a double module definition in a file? or that loop above should protect itself against infinite recursion and error with the id causing the problem?
I guess this is low priority unless you know an easy fix.. thought I'd report it anyway.

p.s. to be clear when debugging it was stuck in that while loop with doc === doc.

Fun! Thanks for investigating the cause of this issue. I think the right solution is to prevent the infinite loop.

I couldn't reproduce this, but I put some code in place to guard against the infinite loop. Hopefully that'll prevent others from experiencing the same problem.
If you run into this again, please feel free to file a new issue.

I have been having this issue all day today, using version JsDoc 3.4.0. Presently using grunt to run it as a task. I did manage to get it work once today, but after editing a few file's @property tags it no longer works again. Reverting to the file versions where it worked before did not solve the issue :(

@cppctamber is it definitely the same issue - e.g. an infinite loop in this place, caused by duplicate module tags? If you can get a repro case I think it would be worth sticking into a new issue.


Black screen

I run the project and cant see the real world through camera , its shows black screen with plane object floating and feature points.

Did you get it to work?

No, I didn't get it.
On Thu, Aug 20, 2020 at 2:19 PM aaryanshroff<EMAIL_ADDRESS>wrote:

Did you get it to work?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hanleyweng/iOS-ARKit-Headset-View/issues/7#issuecomment-677459367,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMGPPEFQS5AKJUZFCCUHATSBTNX7ANCNFSM4PYX22CA
.

In ARSCNViewHelperClass.swift, set _HEADSET_IS_PASSTHROUGH_VS_SEETHROUGH = false to use it as an AR glasses

In ARSCNViewHelperClass.swift, set _HEADSET_IS_PASSTHROUGH_VS_SEETHROUGH = false to use it as an AR glasses

Thanks i will try

Thanks i will try


Fix "plugin-git": executable file not found

adapt Dockerfile entrypoint to "shell form"

Does not fix the problem completely


testing backward euler with most of the analytical tests

Closes #499
Backward euler passes all tests, but the robertson tests (the solver fails to converge and seems to get stuck, will be investigated by #498). I don't know how to test backward euler against HIRES, Oregonator, E5, but hopefully that can be fixed with #575

How do you decide the tolerance values? It is interesting to see they vary between each solver type and rate constant type.

it was super duper scientific. I set a value of 1e-8 and when that failed for a particular test I subtracted one from the exponent until it passed.
A more intelligent way would be to play with the solver tolerances to choose values that minimize the error

How do you decide the tolerance values? It is interesting to see they vary between each solver type and rate constant type.

it was super duper scientific. I set a value of 1e-8 and when that failed for a particular test I subtracted one from the exponent until it passed.
A more intelligent way would be to play with the solver tolerances to choose values that minimize the error

Haha I see. Yeah that makes sense but would require a good amount of work to investigate that. I guess we don't need to worry about it for now

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (main@854ca2d). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #576   +/-   ##
=======================================
  Coverage        ?   92.89%
=======================================
  Files           ?       49
  Lines           ?     3477
  Branches        ?        0
=======================================
  Hits            ?     3230
  Misses          ?      247
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Incorrect active_signature count when displaying signature help

Describe the bug
ELP sends an incorrect active_signature count when displaying signature help.
According to https://github.com/helix-editor/helix/issues/11269 it's an off-by-one error.
To Reproduce
Write a self-recursive function where the call has the same number of arguments as the function of that name that takes the most parameters, writing the arguments inside already-complete parentheses. A crash, at least in Helix, only occurs modifying the final argument to a function call when all other arguments are supplied.
i.e.
-module(test).

f(_) -> f(). % this is fine.
f(_) -> f(1). % adding in this 1 post-hoc will crash Helix because of this incorrect count.

Expected behavior
An correct active signature count is sent by elp.
Actual behavior
An incorrect active signature count is sent by elp.
Context

ELP Version (output of elp version): elp 1.1.0+build-2024-07-16
Editor used:

Here is a helix.log output which shows communication with the LSP.