Add StarRocks Docs

What type of PR is this：

[ ] bug
[ ] feature
[ ] enhancement
[ ] refactor
[x] others

Problem Summary(Required) ：
Add StarRocks Docs to a subdirectory docs.

Why put the document into source code?

Why put the document into source code?

we want our documents can be sync with our code.


cmd/go: exclude vendor dir from matching ...

There are some closed issues about this, but I'd like to bring it up again.
Any time you're building an application and you make an update to any package in the repo (of which there are often many), you run go test ./... to make sure you haven't broken your program.  This worked fine before vendoring became a thing, but with vendoring, it runs all the tests of vendored code as well.  While you may want to do that once in a while, such as when you update the code in the vendor directory, it's generally not something you want to do every time your code changes (because it shouldn't affect code you depend on at all).
I'd like to suggest that ... ignore the vendor directory by default.  I almost never want to have any command touching the vendor directory directly - not go vet, not go fmt, not go build, not go test, not go install, not go fix.
If the community feels that there is utility in being able to match the vendor directory, I suggest adding a flag called -vendor (or whatever) that indicates ... should match the vendor directory.  But by default, I think almost everyone would prefer it not match the vendor directory.
As we start down the path of having an official package management solution, I think vendoring will get more and more common.... and this will become more and more of a pain.
(and yes, I know you can do the go test $(go list | grep -v vendor) thing, but that's shell and OS-dependent, and ugly, and just bad UX)

I feel similarly about this issue.
vendor could be ignred when walking its parent, so ./... would ignore it but ./vendor/... wouldn't.

I would like to add the votes of 21 people that do not want to have their editor run go test against vendor/ at all https://youtrack.jetbrains.com/issue/GO-2366 and 19 others that don't want gofmt to run against vendor/ as well https://youtrack.jetbrains.com/issue/GO-2412. One could argue that the editor should be smarter and send a list of packages to the tool but then why should users be forced to either have to use  $(go list | grep -v vendor), which mind you is not possible on Windows (WSL does not count as it introduces yet again more work for the user, thus bad UX), or use an editor to achieve this?
Also, please notice tools like glide, one popular dependency management tool, where there's even a dedicated command to list packages and omit the vendor directory in order to make life easier.
This is clearly an UX problem that the users should not have to face.

Previous discussion:

#14417 cmd/go: go test ./... fails on go 1.6 because dependencies are tested
#17497 cmd/go: go generate ./... will recurse into vendor
#17879 Exclude vendor/ from linters

Marking as Go 1.9 for further consideration and decision.

I would also like to add that this is what a Windows user currently has to write when using Windows CMD to work around the vendor issue for /f "" %G in ('go list ./... ^| find /i /v "/vendor/"') do @go test %G which is a lot worse than go test $(go list | grep -v vendor).

@natefinch thanks for raising this again.
Regarding the usual argument that "./... means all sub packages should avoid making vendor a especial case":

vendor is an especial case.
./... already ignores folders with names starting with . or _, so there's a precedent supporting this proposal.

Are there good reasons why the vendor directory cannot simply be renamed
_vendor?
Kind regards,
Paul Reiberhttp://about.me/reiber
On Tue, Feb 14, 2017 at 2:53 PM, Ernesto Jiménez<EMAIL_ADDRESS>wrote:

@natefinch https://github.com/natefinch thanks for raising this again.
Regarding the usual argument that "./... means all sub packages should
avoid making vendor a especial case":

vendor is an especial case.
./... already ignores folders with names starting with . or _, so
there's a precedent supporting this proposal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/19090#issuecomment-279862554, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADlQB4xORqJ5Z9Y1dbkOTD-C4dlEPLxks5rcjBWgaJpZM4MBALL
.

@PaulReiber see this comment: https://github.com/golang/go/issues/11659#issuecomment-173376808

"vendor" is not being renamed. That ship has long sailed.

@ianlancetaylor can you please add https://github.com/golang/go/issues/1165 to the list of related issues as hopefully your comment will be more visible than mine. Thank you

@dlsniper Done, thanks.

This was overwhelmingly mentioned in the tools survey I conducted last year. Combining all feedback I got (individuals, mailing list questions, StackOverflow, etc), this particular problem was one of the top problems that has been mentioned.

A core function like test that would understand vendoring as a dependency and not the target of testing scope would be huge. It's inefficient to write custom regex patterns to include some portions of code and not others. Increasingly so when you want to operate on subsets of the code base. The ./... Operator forces you to glob all go files with the expressed understanding that you will filter out a majority of the results returned wastes cycles during iterative testing. Given this is a solved problem with tools like glide it would seem like a quick win scenario with tangible returns to the go dev community.

This has be discussed at length and rejected.
I think the real solution is #11193.
What people really don't want is to run unneeded tests.
With proper test caching, it doesn't matter go test ./... tests vendored
packages or not.

That doesn't help for all the rest of the tooling. I don't want go vet complaining about problems in vendored code. I definitely do not want go fmt or go fix changing things in vendored code. I don't want go install installing binaries that happen to be in vendored repos.
The root of it is this: without vendoring, ... never matches dependencies that arent't in your repo, because they're not subdirectories. I just want to maintain that functionality while vendoring.

Then don't invoke go fmt or go fix on ./..., which is very problematic even
if there aren't any vendored packages.
The core problem is people tend to overuse the ./... pattern. The vendor
problem is just a red herring.

I've also just got bitten by an issue that go vet complains about code in the vendor/ directory but until the upstream changes that code I can't do anything there thus I'm forced to use the workaround instead of not having to deal with it at all.
And I don't think that go fmt ./... is overused when you want to format the project and make sure it's all consistent inside a pipeline for example.

My proposal (again) is to introduce negative patterns explicitly.
e.g.
go test ./... -./vendor/...  # using - is preferred, but -exclude also
works.
to exclude any packages matching ./vendor/... from the result of ./....
Changing the behavior of ./... today to ignore vendor packages will only
introduce confusion.
(And there are reasonable uses of ./... to match vendor packages.)

Then don't invoke go fmt or go fix on ./..., which is very problematic even
if there aren't any vendored packages.

why is this "problematic"? We've never had any problems with it, and we run it on every commit merged into InfluxDB, Telegraf, & Kapacitor.
and I personally don't care if my dependencies are go fmt'ed properly, I only want to run it on my codebase.

Changing the behavior of ./... today to ignore vendor packages will only
introduce confusion.

My experience has been most people being confused by it not ignoring vendor/.

e.g.
go test ./... -./vendor/...  # using - is preferred, but -exclude also
works.

While this concept could definitely be applied to more use cases, excluding vendor is the real pain IMO. For other use cases go test $(go list | grep -v ...) always does the job.

Changing the behavior of ./... today to ignore vendor packages will only
introduce confusion.
(And there are reasonable uses of ./... to match vendor packages.)

If we don't want to break backward compatibility and therefore prevent potential confusion, could it be tolerable by both sides to introduce a single-character flag for excluding vendor? It would be only 3 keystrokes more to type without any BC break.

What about a .gorc file that can be configured with defaults?

configuration files are out of the question. the go command is designed to
avoid configuration files in the first place.
Also, whether to ignore a package is property of a specific invocation of
the go command.
Please note that we do want to build/install the vendored packages, so only
ignoring them in test, vet, fmt, but not build looks pretty inconsistent to
me.
That's why I propose adding negative patterns to make it explicit.
To put it another way:
should the ./... pattern matching different set of packages in the
following commands?
go install ./...
go test ./...

@minux why would you want to explicitly install vendored packages? If they are vendored, they are dependencies and will already be built if vendor is ignored.

Please note that we do want to build/install the vendored packages

@minux, that's not true, in telegraf I only want to build the packages in vendor/ that telegraf depends on, not every single package in vendor/.
Building every package in vendor/ means that you would have to trim out packages/tests that your project doesn't use.
This is not how it works when the project is in your GOPATH.

Whether to include unnecessary packages under vendor depends on how you
vendor a package (e.g. copy or git submodule), and that's not relevant in
this discussion.
If you vendor only necessary packages, then you could use go install ./....

If you vendor only necessary packages, then you could use go install ./....

True, but it still doesn't explain why you need the vendored packages to be included. This just explains a way for it to not matter.

Rather than expressing incredulity that people want to use the glob operator, I think it is important to recognise that globbing is a straight forward solution to very commonplace questions like _"How can i run the tests for all the packages in my project?", which, until go 1.6, was satisfied by globbing.
Saying that people shouldn't use the glob operator is not helpful as the replacement was non portable (how do you pipe grep on windows?), or relies on an external tool like go test $(glide nv); which also isn't a portable solution.
As @rakyll showed from her research this issue is a major point of confusion for Go developers and that alone should be cause to reexamine the decision.

Another consideration is that the current behaviour requires you to vendor dependencies of your dependency's tests, e.g. packages like testify

Related to the above consideration, go get ./... will not bring in those dependencies automatically so you have to go get ./..., vendor the dependencies, then repeat until no new vendored dependencies show up. While it's easy enough to make a custom tool that does this, it seems like it should be unnecessary for the default go toolchain to cause this problem.
It seems to me like you should be able to call go get ./..., vendor the dependencies identifies and retrieved by the command, and go test ./... would still work. This isn't currently true.

@jsternberg if possible I'd like to leave go get ./... out of this debate. I want everyone to remain laser focused on the usability issue of go test ./... matching vendored code.
There are certainly other issues with the Go 1.6+ behaviour, but for the sake of clarity, can those debates be taken elsewhere.
Thanks

@davecheney I actually don't want to limit this just to go test.  While I agree that go get is a special flower, almost none of the normal go tools would seem to be appropriate to run on the vendor directory.

@natefinch Why not? The list command comes to mind immediately.
@davecheney How can they be separated? Are you suggesting the possibility of making the glob work differently between test and get? Ugh. Is there any precedent for this in the existing code?

I just want people to focus on the problem of go test in this issue.
There are other use cases, they should be argued separately as in my experience if you ask for several things at once, you risk getting none of them.

On 17 Feb 2017, at 06:59, slrz<EMAIL_ADDRESS>wrote:
@natefinch Why not? The list command comes to mind immediately.
@davecheney How can they be separated? Are you suggesting the possibility of making the glob work differently between test and get? Ugh. Is there any precedent for this in the existing code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I would agree that focusing this only on the UX issues faced by go test is the best move for this proposal.
That said, longer term it would be great if the behavior change becomes standard in other places where the ./... syntax is supported.
But i'd like to see us fix the leaky pipe before trying to refinish the basement. I run into this all the time in many different projects and the lack of a simple solution built into the test tool itself has long been a pain point for myself and many others I know.

This is a concern across several tools, not just go test ./.... A holistic solution would be appreciated, even if this serves as a meta-issue with separate issues specific to each tool.
As mentioned previously in @rakyll's survey, my main issue is that there isn't a consistent workaround for ignoring the ./vendor folder with the variety of Go tools.
The gofmt tool requires a list of packages, it doesn't work with a $(go list ./... | grep -v vendor) exclusion.
The result is a Makefile with a bunch of different commands instead of something simple.
GO_PACKAGES = $(shell go list ./... | grep -v vendor)
GO_FILES = $(shell find . -name "*.go" | grep -v vendor | uniq)

gofmt -s -l -w $(GO_FILES)
go vet $(GO_PACKAGES)
go list ./... | grep -v /vendor/ | xargs -L1 golint
go test $(GO_PACKAGES)

It took a good amount of time to find the quirks and come up with commands (we're not all bash experts). Multiply that by every team out there running into this. As pointed out in this thread, it gets even worse, in that these commands are not cross-platform.
Specifying ./... and perhaps a -novendor flag across any tool would be simple.
If there is a flag, what it's named, and whether the default is to include vendor or not, I don't have an opinion right now.

I'm not sure if this has been mentioned already: what about supporting a _vendor directory in addition to vendor?

If we could get the issue addressed in test first, get the behavior correct and make sure it's working as intended, then i'd imagine it would be easier and more palatable to propose rolling the changes to the vet tool and others.
If we get it fixed just in test or globally, however, i'll be happy either way.

First, we've got another special treatment of (yet another) special name the go tool has to handle differently.
Secondly, we saw it has unforeseen consequences.
Thirdly, we propose to fix that by adding another specially treated case.
#Featuritis

Thirdly, we propose to fix that by adding another specially treated case.

I argued at the time, and will do so again that the vendor directory should have been called _vendor/. This would have had less impact on tooling

I don't understand why we can't consider this as a quality of life improvement based on concrete facts and evidence. It's clear that people don't want tools that use ./... to touch  vendor/ at all most of the time.
The question should be: Does it have to be implicit or explicit to omit it? Not if we should do it or it. There's clear evidence that some users have a lot harder time around this missing functionality just by looking at the Windows users and the horrible workaround they have to do.
More evidence this is needed? Hang out long enough in Gophers Slack, read the various mailing lists / issue trackers of various tools or do a Google Search for "go test" exclude vendor to find the 10k+ results around this (can't validate them all but they are there if someone wants to tackle this).
My gut feeling is that this option should be explicit in usage so that the current behavior is not changed for the tools we have and be an opt-in feature, as it should have been from the beginning to include the vendor.

I feel like the issue can be better understood as
"After adding vendor support, there is no easy/cross platform way to test just my code"
./... is not intuitive either, it just happened to be what worked.
Adding the following option to go test would avoid needing to change how ./... works, and would potentially work cross platform.
     -l
         Run the tests on your local files only, excluding the vendor directory.

I agree with @disniper and @ScottBrooks. It's better (less confusing) to add a new flag and keep backwards compatibility than changing default behavior.

just want to re-iterate that this should not only apply to go test. IMO it would be even more confusing if one of the go tools behaved differently than the others, and I don't think the anybody wants to fmt their vendored dependencies either.

I am confused by the arguments against this which object to this on the grounds that it is "yet another special case." vendor is a special directory. It's just incompletely implemented as such today. Some tools treat it as special, others do not.
I think this is a question of consistency in understanding that vendor is a special directory. That's why people get confused and surprised - they expect the special-ness to be consistently handled.
So: this isn't "yet another" special case. This is the same old one, just completing its implementation.

@ianlancetaylor / @rsc et.al. involved in the dev team, could you please help / guide us on this one.
Personally, I'd love to see this landing in time for 1.9 if possible, and judging by the number of voters (according to NoMeToo this should be the way to show support for it), I believe that others would be interested in this sooner rather than later.
Thank you for your time and consideration.

P.S. it doesn't mean the Go dev team has to work on the implementation by all means, just accept / decline it, I'm sure the implementation will follow.

  To preface this:  I love the Go community and the language.  I encourage people to try it out.  I've even presented an intro to Go to my team in hopes we would start writing more Go code.  My background is systems operations, not development.  I have however dealt with dependency hell.
The TL;DR: Basically what @spenczar said above.
Now, on to my $0.02.

The choice of vendor as the directory name means I can no longer have a package named vendor.  It essentially introduced a new reserved word into the language.  I don't foresee needing a package named vendor in my software, but someone might.

The first time using vendor/ and running go test ./... I was met with a slew of errors from my dependencies.  This led to frantic searching for workarounds and advice from the community.  To be 100% honest, I don't care about running vendor tests, they are not code I own, nor are they tests I want to run.  Perhaps I'm naive, I don't write software all day long and generally trust library authors to properly test their code before it is released.

Whatever the fix (there are plenty of good ideas), don't let a desire for 100% backward compatibility  influence the decision.  You've already introduced breaking functionality by using a non-reserved name (vendor), instead of something that the golang toolset would ignore by default (_vendor or .vendor for example)

Trying to encourage people to test drive Go without dependency management (ie vendoring) was difficult.  Now that vendoring has been officially adopted the reluctance to make "non-backward compatible" changes to the tool set is frustrating.  It is one more strange edge-case that needs to be explained to newcomers.

My ideal solution would be to have the location of vendor dependencies be ignored by the golang toolset by default.  The subtree should be treated as if it didn't exist or was read-only.  I shouldn't fear that running go fmt is going to modify the source code of my dependencies.
Thanks.

@dlsniper The golang/dep project is overhauling dependency management, I think when that process is completed we will have a better understanding of how to handle ... and the vendor directory.

Respectfully, dep is an experiment and focused on an entirely different problem; versioning Go packages.
This issue is about ...  matching vendor/ and the effect is has on developers edit/compile/test inner loop.
I would appreciate it if every problem with the Go tool was not kicked down the road by saying "oh dep'll fix it"
Thanks
Dave

On 28 Mar 2017, at 10:31, Ian Lance Taylor<EMAIL_ADDRESS>wrote:
@dlsniper The golang/dep project is overhauling dependency management, I think when that process is completed we will have a better understanding of how to handle ... and the vendor directory.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@ianlancetaylor As per comment here: https://groups.google.com/d/msg/golang-nuts/PaGu2s9knao/Bq4vmFh7AgAJ it seems that golang/dep will not arrive here in 16 months from now as an official tool, and I'm not sure about others, but I'd rather fork the Go frontend and add that option rather than wait that long.
There are clear signs everyone really do not agree with the current situation and we, the community, want to work with you, the Go team, to get this improved for us, all the Go users.
If creating the CL for this issue is what stops us from having a decision on it, then please indicate so, but given how this is a proposal, even if it doesn't follow the normal proposal flow, I think it must be addressed. Go 1.9 cut-off will be here in almost a month from now, at which point it will be too late for us to change anything for the next few months, which can potentially delay it to Go 1.10, that means, 10 more months to get a --no-vendor or --skip-vendor or --omit-vendor flag.
Thank you for your time and consideration.

I wrote in https://github.com/golang/go/issues/11659#issuecomment-171665255:

I think there are two cases:

A package in a vendor tree that is actually used (directly or
indirectly) by the code outside the vendor tree. In this case I think you
would want to test the package, just as you test all your other
dependencies. If code you depend on is broken, you want to find out in the
most precise test possible, not wait until a test of the main program fails
mysteriously.
A package in a vendor tree that is not actually used (directly or
indirectly) by the code outside the vendor tree. In this case, obviously no
one cares and the test need not run. But in this case I don't understand
why tools are bringing that package into the vendor tree in the first
place. I would argue that, for many reasons, dead (unused) code should not
be copied into a vendor tree. Code that is in your vendor tree has to be
maintained, updated, and so on. If it's not needed, it should just be
omitted.

I think it's a mistake to skip the test in (1). And I think (2) indicates a
problem in the vendoring process.
The counter-argument to this is that you can't omit individual packages
when you're using git submodules. But when you're using git submodules I
think you're tying yourself to the target repository quite a bit more and
so it may still be appropriate to test the entire thing.

Obviously from the reactions to the issue lots of people are still running into problems. But why?
Is it because there is dead code in your vendor trees you want to ignore?
Is it because you don't want to test the vendored code you do use?

Is it because you don't want to test the vendored code you do use?

Because you asked: I don't run the tests from the standard library, I don't see why I should run the tests for vendored code either. I want to quickly run my tests, so I can continue developing.

At our company we import vendored code without test files, so go test is not an issue. But we have to explicitly ignore vendoring whenever we run go vet, golint, or other static analysis tools. We even have  some vendored code that isn't gofmted, sadly, so running a project-wide gofmt also requires ignoring vendor.

@cespare, are you running ... wildcard commands for all those, or something else? We're unlikely to change gofmt -r to ignore vendor directories, for example.

Is it because you don't want to test the vendored code you do use?

During development or CI it's faster to run only your tests.
If someone decides to change locally a library that they use, then they still want to test the changes, but probably not as part of every build. The test code might be there because of that, or might be there for legal reasons, or might be there because of company policies.
Test code in vendor/ is not dead code, it's just code that breaks the assumptions on how the tool should behave, slowing down the users by a good margin, making it unfriendly for newcomers and there is no way to override it from within the tool.

I want to easily control when I run tests over vendored code.  The same with gofmt or go vet.  Generally, the code in the vendor directory changes very rarely, so the results of go test or go vet are also going to change very rarely.  Why waste my time running those tests over and over.
And yes, of course we all run wildcard commands.  It's the only reasonable way to run commands over the full repo, and running it over the full repo is the only way to check "have I broken anything with my latest changes?"
There's currently no way to run all the tests in a repo and ignore the vendor directory.  If you made the go tool's interpretation of ... ignore the vendor directory by default, then suddenly it just works.  And if you want to run the go tool over the vendor directory, there's only one extra command you have to perform... cd vendor; go test ./...
At worst, this change would make something that is currently impossible possible, and make the current default into a single extra very obvious command that works on all platforms.

@rsc yes for the static analysis tools.
... isn't really applicable for gofmt, right? (If I run goimports/gofmt manually instead of from my editor, which is rare, I do e.g. gofmt -l -w .).

@cespare, you brought up gofmt. My point was that changing ... to exclude vendor will only help go fmt ./..., not gofmt .. (Sorry about the -r, that was a mistake.)

A package in a vendor tree that is actually used (directly or
indirectly) by the code outside the vendor tree. In this case I think you
would want to test the package, just as you test all your other
dependencies. If code you depend on is broken, you want to find out in the
most precise test possible, not wait until a test of the main program fails
mysteriously.

Respectfully, I disagree that you would want to run tests on the vendor/ tree for this reason. If we ignore vendor for a moment, I'd like to suggest that generally only the public API should be tested. The internal implementation details should be able to be completely rewritten, and as long as the final packages behavior is the same no one should care (and you shouldn't need to ever touch your tests, because behavior is the same). If you aren't touching your public API, and that's the only thing that's tested, you won't have to change your tests even if you completely rewrite your backend.
Similarly, it shouldn't matter what I have vendored or how I'm using it: as long as the behavior of my public API stays the same, I shouldn't have to touch my tests, or worry about tests suddenly failing even though it's an internal detail due to an update that won't affect anything anyways (or, if it does affect something, it should cause my tests to fail, not just its own, otherwise my tests are incomplete).
TL;DR — relying on knowing that a vendored package test fails feels like a crutch that is used to not write complete tests for your own package. This should not be the default.

I don't want to run my vendor/d code's tests because often they do not pass
as they require a more elaborate integration test setup, maybe using
programs which are not available on my operating system.
And also, I don't want to run their tests because I trust they did that
before they released their code.
On Tue, 28 Mar 2017, 13:17 Sam Whited<EMAIL_ADDRESS>wrote:

A package in a vendor tree that is actually used (directly or
indirectly) by the code outside the vendor tree. In this case I think you
would want to test the package, just as you test all your other
dependencies. If code you depend on is broken, you want to find out in the
most precise test possible, not wait until a test of the main program fails
mysteriously.
Respectfully, I disagree that you would want to run tests on the vendor/
tree for this reason. If we ignore vendor for a moment, I'd like to suggest
that generally only the public API should be tested. The internal
implementation details should be able to be completely rewritten, and as
long as the final packages behavior is the same no one should care (and you
shouldn't need to ever touch your tests, because behavior is the same). If
you aren't touching your public API, and that's the only thing that's
tested, you won't have to change your tests even if you completely rewrite
your backend.
Similarly, it shouldn't matter what I have vendored or how I'm using it:
as long as the behavior of my public API stays the same, I shouldn't have
to touch my tests, or worry about tests suddenly failing even though it's
an internal detail due to an update that won't affect anything anyways (or,
if it does affect something, it should cause my tests to fail, not just
its own, otherwise my tests are incomplete).
TL;DR — relying on knowing that a vendored package test fails feels like a
crutch that is used to not write complete tests for your own package. This
should not be the default.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/19090#issuecomment-289642251, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA0REeqecCGQb5ClwemyfMwLFvs_zks5rqG26gaJpZM4MBALL
.

Notably, if Juju moves to use vendoring, including the vendored code with tests would be testing an extra 1.5 million lines of code that you know for sure have not changed since the last time you ran the tests.

@smo921, re your (1), importing "x/vendor" is allowed and works just fine, precisely so that you can have a package (or command!) named vendor. What you can't do is import "x/vendor/y".
@SamWhited, the logical conclusion of your argument is that one should only ever write and run end-to-end (integration) tests, never tests of smaller pieces like individual packages. Obviously, I disagree.
@davecheney and @dlsniper, the point @ianlancetaylor was making (after a brief discussion he and I had) is that once the go command has integrated good dependency management, we hope there just won't be that many vendor directories anymore (the same way you never see vendor directories in, say, Rust projects), so this becomes a much smaller or hopefully nonexistent pain point.
That said, I do appreciate the time scale on that and the significant desire as measured by the emoji reactions to the top post, and I like @bradleyfalzon's analogy.
I think I have found a reasonable semantics and implementation for keeping ... from matching vendor directories (always; no options), and I'll send it out later this week once I clean up the code and the documentation. (It's not trivial. Most people don't realize how powerful ... is: n...t matches not only net but also net/http/httptest.) Depending on how the CL turns out, maybe we can submit it soon and make a final decision on whether to pull it out during the freeze.

Thanks Russ, this is excellent news.
On Tue, 28 Mar 2017, 16:47 Russ Cox<EMAIL_ADDRESS>wrote:

@smo921 https://github.com/smo921, re your (1), importing "x/vendor" is
allowed and works just fine, precisely so that you can have a package
(or command!) named vendor. What you can't do is import "x/vendor/y".
@SamWhited https://github.com/SamWhited, the logical conclusion of your
argument is that one should only ever write and run end-to-end
(integration) tests, never tests of smaller pieces like individual
packages. Obviously, I disagree.
@davecheney https://github.com/davecheney and @dlsniper
https://github.com/dlsniper, the point @ianlancetaylor
https://github.com/ianlancetaylor was making (after a brief discussion
he and I had) is that once the go command has integrated good dependency
management, we hope there just won't be that many vendor directories
anymore (the same way you never see vendor directories in, say, Rust
projects), so this becomes a much smaller or hopefully nonexistent pain
point.
That said, I do appreciate the time scale on that and the significant
desire as measured by the emoji reactions to the top post, and I like
@bradleyfalzon https://github.com/bradleyfalzon's analogy.
I think I have found a reasonable semantics and implementation for keeping
... from matching vendor directories (always; no options), and I'll send it
out later this week once I clean up the code and the documentation. (It's
not trivial. Most people don't realize how powerful ... is: n...t matches
not only net but also net/http/httptest.) Depending on how the CL turns
out, maybe we can submit it soon and make a final decision on whether to
pull it out during the freeze.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/19090#issuecomment-289669785, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA4jjRYnH1YsyneTJLoYI1QXx8D_aks5rqJ7egaJpZM4MBALL
.

@rsc Thank you for this, it's really great news.

the logical conclusion of your argument is that one should only ever write and run end-to-end (integration) tests, never tests of smaller pieces like individual packages. Obviously, I disagree.

That comment got away from me a bit, so I may not have been clear, but I certainly wasn't advocating this. It's both not absolute (what ever is?), sometimes you have to test individual little "fiddly bits" (that's a technical term), and it's often possible to write unit tests against your public API too.

@rsc Thank you for getting the CL done and merged so quickly!
One last small note based on this comment here:

once the go command has integrated good dependency management, we hope there just won't be that many vendor directories anymore (the same way you never see vendor directories in, say, Rust projects), so this becomes a much smaller or hopefully nonexistent pain point.

Currently the committing vendor/ directory fills in a very important role in the software life-cycle: it ensures that the dependencies are always there for building / testing the code on the local machine as well as the CI system (helps with the reproducible builds). It prevents cases like left-pad happening for Go projects.
While I don't know how the future will turn out to be, having the dependencies committed with the application right now is a very important step, especially for companies that want to ensure they are also not dependent on github working or not, or in which their CI doesn't have access to Internet at all.
I can add more but I'd rather not spam others here. Thank you once again.

From the CL comments, on the topic of how to get at the previous behaviour following the merge of this.

You can do something like
go test ./... ./vendor/... ./.../vendor/... ./.../vendor/.../vendor/...
depending on how many vendor directories you have in your tree, where they are, whether there are vendors of vendors, and so on

Ugh. I really dislike this change. Excluding vendor from patterns doesn't make any sense to me, as they're defined in terms of directories in the file system. Also, the previous behaviour is pretty useful sometimes (e.g. with go list) and modifying it in this way is likely to break at least some users' scripts. Considering that a trivial workaround exists to achieve the same thing, is this change really worth it?
The rationale presented in the CL ("by popular vote", basically) is unconvincing and appears especially weak when compared to the careful thought and design that has gone into other decisions concerning Go's tooling.

Did you read this whole thread? There's a lot of valid reasons here.  And there's no trivial workaround that works on all platforms for the old behavior.
Russ's example of a workaround to get the old behavior is overly complex.
Most of the time this will work just fine:
go test ./... ./vendor/...
It's pretty rare for people to have multiple levels of vendor directories.
Unlike the workaround for the old behavior, this one is cross platform and works everywhere.

Yes, I did read all the comments on this issue. I'm not convinced. They mostly boil down to "but it'd be more convenient". That's what shell aliases (or whatever) are for. Adding special cases into the core tooling seems like a way too heavyweight approach for tackling such a problem.
The cross platform argument is a red herring. The workaround doesn't have to function on every system under the sun. It only has to work in the environment it is applied to, be that a developer's shell or that build/test script you're writing.

The cross platform argument is a red herring. The workaround doesn't have to function on every system under the sun. It only has to work in the environment it is applied to, be that a developer's shell or that build/test script you're writing.

But it does have to work on Windows, which are the largest population of Go users, and have neither shell aliases or nice things like grep, or substitution.

This hasn't been true for more than a decade. Any supported Windows variant includes a shell that, while somewhat different from Unix shells, is very well capable of such things. I wouldn't be surprised if it even provides a grep command by default. It certainly does so for many other common Unix programs (generally as an alias for the native Powershell command with roughly equivalent functionality).

So windows users will now have to install a shell they're not familiar with, learn that shell, rewrite their scripts in it, and this is easier than running go test ./... ./vendor/....

@slrz if you could find something simpler than:
for /f "" %G in ('go list ./... ^| find /i /v "/vendor/"') do @go test %G

I'd be happy to hear about it.
Meanwhile, this feature was requested by the Go users, which proved with a fairly good technical evidence that not matching vendor/ in  ... is desired or at least have a way to disable that behavior.
I believe that the current way that's implemented offers a good balance of that while still allowing vendor/ to be matched if so needed.
It will rarely be so that you need to type: ./... ./vendor/... ./.../vendor/... let alone ./... ./vendor/... ./.../vendor/... ./.../vendor/.../vendor/... (vendor flattening should be a thing by now in any package manager).
Most likely you'd need to type: ./... ./vendor/... which is still just one character longer than --no-vendor ./... and one shorter than --skip-vendor ./... but it's definitely easier to type / remember than the current way to do things.
Also, special cases do exist today, afaik testdata is one such case (if not only).
So please, try to understand that there are some of us who are really happy to see this, and per the commend here: https://github.com/golang/go/issues/19090#issuecomment-279870835 that number might actually be bigger than you think. So a quality of life improvement for so many people while still allowing for the current behavior to exist is a welcomed change imho.
I hope this helps seeing "the other side" as well.

Heck, we're talking about programmers here. They will figure out something to exclude items containing a constant substring from a list.
Assuming they even want that particular quirky behaviour instead of the one you'd expect from reading the description of patterns in the help text, without the part about this special case.

@slrz this isn't the quirk. The quirk is that vendor is a special directory for the go build tool. This completes the implementation of the quirk.
We were in a bad state previously when vendor was incompletely implemented. We were in the worst position of all - a quirk that was inconsistent.
If purity doesn't convince you, practicality should: In my experience teaching Go and being a local expert in a large-ish company on Go tools, this was an almost universal stumbling block when people went to lint or test their code. Nobody knew to use go list and grep ahead of time, and most of them wrinkled their nose and made some disparaging comment about go's tools.

@dcheney-atlassian

But it does have to work on Windows, which are the largest population of Go users, and have neither shell aliases or nice things like grep, or substitution.

Can you please cite some source of Windows Go users being "the largest population of Go users"?
Meanwhile, let me refer to a survey of 3,595 respondents:

When asked which operating systems they develop Go on, 63% of respondents say they use Linux, 44% use MacOS, and 19% use Windows, with multiple choices allowed and 49% of respondents developing on multiple systems. The 51% of responses choosing a single system split into 29% on Linux, 17% on MacOS, 5% on Windows, and 0.2% on other systems..

The windows version is the most popular download of windows/dl. This was reported to me in private correspondence a year or so ago, I don't have access to verify this fact directly.

Out of respect for everyone, I think we should stop the bike shedding now and maybe open up an issue if we find a problem in the current implementation as asked by @rsc.
Finally, please note that comments like Heck, we're talking about programmers here. are really not in the spirit of cooperation / Go. Yes, we are all programmers, but that doesn't mean we all share the same opinion.
The fact that vendor/ is special is undeniable and if users really really care about traversing that, then maybe they should have to use special scripts instead of those who don't (I've borrowed this last bit from someone who said it in a private discussion).
Lets not have the team lock down the discussion as I consider that to be a bit unfriendly. Thank you.

But I want to paint it chartreuse!

@dlsniper

if you could find something simpler than:
for /f "" %G in ('go list ./... ^| find /i /v "/vendor/"') do @go test %G
I'd be happy to hear about it.

The following should work in a default Windows system, having installed only the Go MSI package:
go test $(go list ./... | sls -NotMatch '/vendor/')
The sls ("select string") seems to be the Powershell equivalent to grep.

My soln till this mess gets sorted is with npm package.json. Something like the following:
{
  "name": "myapp",
  "version": "1.0.0",
  "scripts": {
    "test:win": "for /f \"\" %G in ('go list ./... ^| find /i /v \"/vendor/\"') do @go test -v %G",
    "test:unix": "go test -v $(go list ./... | grep -v /vendor/)",

    "bench:unix": "go test -bench=. -v $(go list ./... | grep -v /vendor/)",
    "bench:win": "for /f \"\" %G in ('go list ./... ^| find /i /v \"/vendor/\"') do @go test -v -bench=. %G",

    "start:unix": "go run *.go",
    "start:win": "for /f \"\" %G in ('dir /b *.go') do @go run %G"
  }
}

better late than never!


Correct the project's description of redlines' output

I started this library as a quick way to show differences in text in Streamlit. Since my use case was fairly limited at the time (and this was a side project of a side project), the documentation says that the output of redlines is markdown, since this was the primary method of displaying text in Streamlit.
On a technical note, the output is HTML which can be used in some implementations of Markdown.
Since then, we've also introduced rich output in a TUI.
It's probably a good idea to generalise the description of redlines' output in the docs to fit the current capabilities of the library.

Merged in 0.5


Make a Progressive Web Application for the same

Try to make this a progressive web app(PWA) by implementing service worker

Hey, can I work on this as part of CWOC?

Hi @Sloth-Panda, the CrossWoC will start from 13th Feb, and all the PR's after the event starts will be count as s valid contribution (for prizes). So, you can work upon this issue once the Event will start.

@Harshal0902 sir can i work on this issue??

Hi, @Amit366 the CrossWoC will start on13th Feb, after the introductory session and all the PR's after the event starts will be count as a valid contribution (for prizes). And this issue is already been take, so you are requested to work on other issues.

@Sloth-Panda  you can work on this issue. You are requested to join the Discord server using this link. Try to complete it within 5 days and follow the CONTRIBUTION.md for making PR.

Hey got little busy in something will be making pr in atmost 2days

@Harshal0902 can I work on this issue??

@Amit366 lets wait for 2 days, if the assigned person is not able to complete his task, then I will assign it to you.

@Sloth-Panda what's the progress?

@Harshal0902 can I work ??

@Amit366 you can work on this issue. You are requested to join the Discord server using this link. Try to complete it within 5 days and follow the CONTRIBUTION.md for making PR.

Ok

may i work on this issue @Harshal0902

@patelaryan7751 you can work on this issue, but first, complete this #46.

@patelaryan7751 go or it.


Initial commit

I'm randomly using ex20(p) to compile and run mfem codes, and noticed that it breaks with the current master branch due to meshing issues. Not really my area of expertise but apparently my addition in the serial version did the trick. Maybe someone can take a look at the parallel one?

@mlstowell, can you help with this?
I guess we are not testing this example, but I'm pretty sure it used to work 😁
Nice to hear from you @HennesHajduk, thanks for reporting this!

Hi, @HennesHajduk,
I'm glad you caught this. MFEM no longer supports 2D meshes with edges belonging to more than two elements e.g. 'T' shaped junctions.
In the parallel case I split the mesh so that each partition is disjoint from the others. The new vertices lie atop each other so the GLVis images still look the same but topologically they are separate meshes so MFEM won't complain.
Best wishes,
Mark

@mlstowell, should we add a sample run so this is being tested? (Currently it is not, which is why we didn't catch this automatically)

@tzanio, we probably should add sample runs however I don't think this bug would have been caught. The meshes in these examples are only built if GLVis visualization is needed.

we probably should add sample runs however I don't think this bug would have been caught. The meshes in these examples are only built if GLVis visualization is needed.

Ah, that makes sense. It is totally up to you -- we can keep things as is if you prefer.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

we probably should add sample runs however I don't think this bug would have been caught. The meshes in these examples are only built if GLVis visualization is needed.

Ah, that makes sense. It is totally up to you -- we can keep things as is if you prefer.

I suggest we keep this PR as small as possible and keep it as is. Each of these examples does have a single sample run but we should double check that they are been run in the overnight tests. We could add more sample runs if they would test more code. I think the only thing that makes sense would be to test the symplectic solver at higher orders. I'll put together a separate PR to do this.
The reason for two PRs is so that this one can be merged quickly. Changing the sample runs should change the baselines used in the nightly tests which may slow down the second PR.

Makes perfect sense, I agree.

@HennesHajduk, can you confirm that Mark's changes work for you?

@HennesHajduk, can you confirm that Mark's changes work for you?

Yes, it works now. Thanks @mlstowell

Merged in next for testing...

Each of these examples does have a single sample run but we should double check that they are been run in the overnight tests.

I checked, and yes, the 2 sample runs (1 for ex20 and one for ex20p) are run by the nightly tests.

Each of these examples does have a single sample run but we should double check that they are been run in the overnight tests.

I checked, and yes, the 2 sample runs (1 for ex20 and one for ex20p) are run by the nightly tests.

Thanks for checking that, @v-dobrev! I really appreciate that.


Support Metalinks for alternate mirror locations

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
Official download URLs for open source projects may redirect a client to a default mirror, and provide additional fallback mirrors via HTTP Metalink headers.
If the default mirror is down, Brew will automatically use the fallback mirrors to complete the download.
What is the motivation for the feature?
I have experienced failed cask installs from default mirrors being offline, for projects that do provide alternates via Metalink headers.
How will the feature be relevant to at least 90% of Homebrew users?
It will improve the download reliability for any formulae that is delivered via a URL that returns Metalink fallback location headers.
What alternatives to the feature have been considered?
I am not aware of alternative proposals for Brew to implement fallback download URLs.

Can you point to a cask the provides such headers?

LibreOffice is one:
curl -Lv download.documentfoundation.org/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg
*   Trying <IP_ADDRESS>:80...
* Connected to download.documentfoundation.org (<IP_ADDRESS>) port 80 (#0)
> GET /libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg HTTP/1.1
> Host: download.documentfoundation.org
> User-Agent: curl/7.87.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Fri, 14 Apr 2023 14:12:12 GMT
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 426
< Connection: keep-alive
< Server: Apache
< X-Prefix: <IP_ADDRESS>/12
< X-AS: 13335
< X-MirrorBrain-Mirror: cyberbits
< X-MirrorBrain-Realm: AS
< Link: <http://download.documentfoundation.org/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg.meta4>; rel=describedby; type="application/metalink4+xml"
< Link: <http://download.documentfoundation.org/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg.asc>; rel=describedby; type="application/pgp-signature"
< Link: <http://download.documentfoundation.org/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg.torrent>; rel=describedby; type="application/x-bittorrent"
< Link: <https://mirror.cyberbits.asia/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg>; rel=duplicate; pri=1; geo=us
< Link: <https://mirror.usi.edu/pub/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg>; rel=duplicate; pri=2; geo=us
< Link: <https://mirror.fcix.net/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg>; rel=duplicate; pri=3; geo=us
< Link: <https://ftp.wayne.edu/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg>; rel=duplicate; pri=4; geo=us
< Link: <https://mirror.clarkson.edu/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg>; rel=duplicate; pri=5; geo=us
< Digest: MD5=9VEFYdmbV2qEv+e7myKJKg==
< Digest: SHA=duw/wMmJOpuDOIe2uxu3txG+GCA=
< Digest: SHA-256=t18NC4teLCZSaIP4EyBHSJ9TUhP/G2ySOvmrwclaTG8=
< Location: https://mirror.cyberbits.asia/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg
<
* Ignoring the response-body
* Connection #0 to host download.documentfoundation.org left intact
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://mirror.cyberbits.asia/tdf/libreoffice/stable/7.5.2/mac/aarch64/LibreOffice_7.5.2_MacOS_aarch64.dmg'
* Could not resolve host: mirror.cyberbits.asia
* Closing connection 0
curl: (6) Could not resolve host: mirror.cyberbits.asia

Passing on this, sorry.


Dev: error phpstan

The new version settings [v2.1.1] has been released. This problem started from version 2.1.1.
Error: Cannot call method forget() on array|bool|float|int|object|string|void.
 ------ ------------------------------------------------------------------
  Line   tests/Authentication/Authenticators/SessionAuthenticatorTest.php
 ------ ------------------------------------------------------------------
  112    Cannot call method forget() on
         array|bool|float|int|object|string|void.
 ------ ------------------------------------------------------------------

see https://github.com/codeigniter4/shield/actions/runs/4960040688/jobs/8876233138?pr=736
Temporary solution:
-setting()->forget('Cookie.prefix');
+service('settings')->forget('Cookie.prefix');

https://github.com/codeigniter4/shield/blob/812338879b0ebabdc1c46e5fae7b2f429aa70005/tests/Authentication/Authenticators/SessionAuthenticatorTest.php#L82-L113

Sent PR to fix too sketchy @return.
https://github.com/codeigniter4/settings/pull/78


Best practices around non-persistent URIs without using blank nodes

Avoiding blank nodes simplify queries and downstream applications. When we validate data using SHACL, we produce sub-graphs to avoid loading the entire knowledge graph into memory. Having blank nodes complicates this and makes it very hard to scale as each target class for SHACL validation requires modification to the SPARQL query.
Our current solution is to replace all uses of blank nodes with a non-persistent URI. All individuals use the base URI just like persistent and named individuals except their local name is prefixed with an underscore (_).
Example:
http://linked.data.gov.au/dataset/ausplots-rangelands/_bc4a8844-cb51-49f6-837b-d5b8f884af6e
......................................................^....................................

The nice thing with this is that all individuals in our knowledge graph are now named, therefore we can retrieve data from a SPARQL endpoint at any granularity level as we wish (example use case - using a graph viewer like Ontodia). The downside to this practice is that we are using a non-standard way of representing unnamed individuals (blank nodes). And if people are unfamiliar with our practice, they may interpret it as a persistent name.
We need to document this somewhere.

replace all uses of blank nodes with a non-persistent URI

... which I think is how they are handled internally anyway by all triple/graph stores?
Why not just make these URIs persistent?

I think this is no longer relevant as it is an implementation detail.


WebSocket Error: 'NoneType' object has no attribute 'pad_token' using docker setup with Llama

Hi all, newbie here.
I'm trying to get a basic demo instance working using docker and LLama.
I've successively imported documents and I've set the following two configurations:

HF_TOKEN=$HF_TOKEN
LLAMA2-7B-CHAT-HF=True

But when I ask the prompt a question I get the following error:
File "/Verba/goldenverba/server/api.py", line 599, in websocket_generate_stream
verba-verba-1     |     async for chunk in manager.generate_stream_answer(
verba-verba-1     |   File "/Verba/goldenverba/verba_manager.py", line 613, in generate_stream_answer
verba-verba-1     |     async for result in self.generator_manager.selected_generator.generate_stream(
verba-verba-1     |   File "/Verba/goldenverba/components/generation/Llama2Generator.py", line 77, in generate_stream
verba-verba-1     |     if self.tokenizer.pad_token is None:
verba-verba-1     | AttributeError: 'NoneType' object has no attribute 'pad_token'

I'm likely missing something simple, but I'm not sure what it is. Any advice is much appreciated.

I think I resolved. I thought I had access to the Llama model, but I hadn't got approved for access yet.  (I'm sure the lack of the model actually be downloaded is at the root of this problem)

Most likely the initialising of the Llama2Generator failed, so the self.tokenizer was never set. This failure only raises a warning which is easily lost in the docker logs:
https://github.com/weaviate/Verba/blob/1c9d4b49385315883ba0027ac1772a8b448f6204/goldenverba/components/generation/Llama2Generator.py#L26-L52
For me, it was related to the API Key I was using (for a fine-tuned HF Llama2 model), so I saw a message like:

Repository Not Found for url: https://huggingface.co/universeTBD/astrollama-7b-chat-alpha/resolve/main/config.json.
Please make sure you specified the correct repo_id and repo_type.
If you are trying to access a private or gated repo, make sure you are authenticated.

If you can't find the exception in the docker logs, it might be preferable to raise an error rather than just displaying the warning if the model isn't initialised - e.g., by removing the try: except: stuff in Llama2Generator.py:
        if os.environ.get("LLAMA2-7B-CHAT-HF", "").lower() == "true":
            #try:
                import torch
                from transformers import AutoModelForCausalLM, AutoTokenizer

                def get_device():
                    if torch.cuda.is_available():
                        return torch.device("cuda")
                    elif torch.backends.mps.is_available():
                        return torch.device("mps")
                    else:
                        return torch.device("cpu")

                self.device = get_device()

                self.model = AutoModelForCausalLM.from_pretrained(
                    "meta-llama/Llama-2-7b-chat-hf",
                    device_map=self.device,
                )
                self.tokenizer = AutoTokenizer.from_pretrained(
                    "meta-llama/Llama-2-7b-chat-hf",
                    device_map=self.device,
                )
                self.model = self.model.to(self.device)
                msg.info("Loading Llama Model")
            #except Exception as e:
            #    msg.warn(str(e))

Make sure you are "authorised" to use it. https://huggingface.co/meta-llama/Llama-2-70b-chat-hf

Hugging face says I've been authorized:

I think I'm hitting a Docker memory limit when trying to install llama.
Docker Build fro Verba gets this far:

and then it just hangs.
Docker memory usage looks like it is very hight 12gb

And my docker resources setting is set to 12gb

So I think the pad_token error is definitely coming from a failure to successfully install the llama model successfully.
But this brings me to a resource question.
Any ideas what the resources requirements are for running Verba with LLama2? How much memory do I need to allocate. M1 MacBook Pro only has 16GB. :(

I raised Docker to 16
and the build seems to be using all of it:

And still hanging...
Seems like this won't work for me, as it is too memory intensive for my machine. :(
Thanks for your tips and advice.


Error with different Ok types with Async + Filter

I'm trying to make a level filter, but I get the error below. The Ok types of Async and Filter seem to mismatch, but I don't now how to fix it.
Secondly, I have not found any example or explanation how to make a level filter; wouldn't it be nice to provide and example of such a basic task?
pub fn create_logger() -> slog::Logger {
    let decorator = slog_term::TermDecorator::new().build();
    let drain = slog_term::FullFormat::new(decorator).build().fuse();
    let drain = slog_async::Async::new(drain).build().fuse();
    let drain = slog::Filter::new(drain, |record: &slog::Record| {
        record.level().is_at_least(slog::Level::Debug)
    });
    slog::Logger::root(drain, o!())
}

error[E0271]: type mismatch resolving `<slog::Filter<slog::Fuse<slog_async::Async>, [closure@src/lib.rs:25:42: 27:6]> as slog::Drain>::Ok == ()`
  --> src/lib.rs:28:5
   |
28 |     slog::Logger::root(drain, o!())
   |     ^^^^^^^^^^^^^^^^^^ expected enum `std::option::Option`, found ()
   |
   = note: expected type `std::option::Option<()>`
              found type `()`
   = note: required by `slog::Logger::<D>::root`

edit: Alternatively, this has the same problem:
let drain = drain.filter_level(slog::Level::Debug);

Thanks.


Add error return codes to compactCells

Coverage increased (+0.0003%) to 98.991% when pulling 1a608968586dec5e889d2ca6f94e94c14145c644 on isaacbrodsky:error-returns-compact into 456e57d617042a5b3fbc05ae72389acce28ade62 on uber:master.


Clarify foreground deletion behavior of the GC controller in race and sync error conditions

Description
Clarifies the best-effort nature of the garbage collector controller behavior honoring blockOwnerDeletion in sync error and race conditions scenarios.
/sig api-machinery
/assign @deads2k
https://github.com/kubernetes/kubernetes/pull/125796 makes the best-effort nature even more clear in 1.32, but this was always best-effort and subject to races on creation, so we should document that.

/approve

@deads2k and colleagues: you are welcome to LGTM this

/lgtm


Consider adding use_super_parameters

Describe the rule you'd like to see added and to what rule set
Dart 2.17 adds the new super params feature (see additional info for an example), and in https://github.com/flutter/flutter/issues/100575 we're migrating Flutter to use.
I propose we add the use_super_parameters lint, which enforces this style, to recommended.
Additional context
Without super parameters:
class MyWidget extends StatelessWidget {
  const MyWidget({ Key? key }) : super(key: key);
}

With super parameters:
class MyWidget extends StatelessWidget {
  const MyWidget({ super.key });
}

We should make sure that the IDE macros are updated to produce valid code with this lint enabled before making it a recommended one. Work for that is tracked here:

https://github.com/Dart-Code/Dart-Code/issues/3899
https://github.com/flutter/flutter-intellij/issues/6071

WDYT @pq ?

I'm in favor.  I think it does a good job of nudging folks towards using super.  There are a few open issues but luckily they're false-negatives.

I'll just note that false negatives are also somewhat problematic because fixing them is technically a breaking change. The more users of a lint the bigger the impact of the breaking change.
We might want to wait to add the lint until we can address the false negatives (depending on the nature of the false positives).

Thanks Brian.  Agreed!

We might want to wait to add the lint until we can address the false negatives (depending on the nature of the false positives).

If we can prioritize the work, this would be my preference.

This has been approved for the recommended set.

Great to hear! If this is graduating to the recommended set, it might be worth increasing the priority on https://github.com/dart-lang/sdk/issues/51578.


refactor(ES6): upgrade APIPlugin to ES6

What kind of change does this PR introduce?
ES5 => ES6 refactor
Did you add tests for your changes?
refactor, all existing tests pass
If relevant, link to documentation update:
N/A
Summary
Helping in part of the ES6 refactor
Does this PR introduce a breaking change?
Nope

@sokra Can you take a look again, please?

Should be squashed IMO otherwise LGTM

Yes, for sure (good catch @chicoxyzzy ). We shouldn't add broken commits inside master branch. I don't know for now if we are not using squash as standard, but if not it's a good idea add it.

I'll take care of sqash.


⚠ Bofrost.be has degraded performance

In 6364d07, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1105 ms

Resolved: Bofrost.be performance has improved in c86a010.


speech to text parse

parse podcast files and get the full text into the .md files using speech to text

https://cloud.yandex.com/docs/speechkit/pricing#prices
price is 0.01 rub / 1 sec, so 1 hour podcast should cost around 40 rub

with recent lauch of the ya.cloud we can even do this for free for two months

but the hardest part is, of course, splitting the guest and host speech cleanly
we'll try to get around this by first splitting the podcast track into two tracks based on this model https://github.com/faroit/CountNet


downlaoder.py line 172 syntax error

I downloaded fresh, installed the requirements.txt, ran ./scrapingmanass.py and immediately get this error
Traceback (most recent call last):
File "./scrapingmanass.py", line 6, in
import downloader as dl
File "/home/sheep/git/Scraping-Manual-Assistant/downloader.py", line 172
print(f'{index}/{total_queries} ', end='')

I wasn't running the script with Python3.


Double enter password or show password

This site is asserting that double entry lowers conversion (bad) but show password helps.
Might that be a good solution?
http://uxmovement.com/forms/why-the-confirm-password-field-must-die/

I added a Confirm Password field on signup.


Test names pollute student namespace

Currently, tests are on the top-level. This means their names can conflict with student names. For example, the student can't name anything cases since that's the name used to list the test cases.
We could move the tests inside a class or object.
This would require making the test functions shared (ahhh, that's the situation where they have to be shared, I was wondering in #14) - confirm that if moving them to a test class/object.
Currently there is an obstacle: ceylon.language.meta.model.TypeApplicationException "Cannot apply a member declaration with no container type: use memberApply" on an attempt to use parameters on a member. Apparently a fix is planned for 1.3.2 1.3.3 (See https://github.com/ceylon/ceylon-sdk/issues/635), so we may have to wait until then.

Another possible option that may work today: Put the tests in a separate package. I'm a little reluctant to add another package for each exercise just for this, though.

Update. 1.3.2 is released, but issue is still open. It has been bumped to 1.3.3.

1.3.3 was released on August 21, but (I will verify) without the necessary change. So it will have to wait until 1.4.0.

Verified not working in 1.3.3


GO:0004362 glutathione-disulfide reductase (NADPH) activity - remove parent

GO:0004362 glutathione-disulfide reductase (NADPH) activity has four is_a parents (shown below).
The "is_a: GO:0047134 ! protein-disulfide reductase (NAD(P)) activity" should be removed, since glutathione is not a protein.
id: GO:0004362
name: glutathione-disulfide reductase (NADPH) activity
namespace: molecular_function
def: "Catalysis of the reaction: 2 glutathione + NADP+ = glutathione disulfide + NADPH + H+." [EC:<IP_ADDRESS>, ISBN:0198506732]
comment: Note that this function was formerly EC:<IP_ADDRESS>.
xref: EC:<IP_ADDRESS>
xref: MetaCyc:GLUTATHIONE-REDUCT-NADPH-RXN
xref: RHEA:11740
is_a: GO:0015038 ! glutathione disulfide oxidoreductase activity
is_a: GO:0016209 ! antioxidant activity
is_a: GO:0016668 ! oxidoreductase activity, acting on a sulfur group of donors, NAD(P) as acceptor
is_a: GO:0047134 ! protein-disulfide reductase (NAD(P)) activity

Done in #17675


WARNING:absl:SaveArgs.aggregate is deprecated

Hi,
I am receiving this warning WARNING:absl:SaveArgs.aggregate is deprecated, please use custom TypeHandler (https://orbax.readthedocs.io/en/latest/custom_handlers.html#typehandler) or contact Orbax team to migrate before May 1st, 2024. If your Pytree has empty ([], {}, None) values then use PyTreeCheckpointHandler(..., write_tree_metadata=True, ...) or use StandardCheckpointHandler to avoid TypeHandler Registry error. Please note that PyTreeCheckpointHandler.write_tree_metadata default value is already set to T . How to fix this issue?
Below is my code:
#checkpointing
check_options = ocp.CheckpointManagerOptions(max_to_keep=5, create=True)
check_path = Path(os.getcwd(), out_dir, 'checkpoint')
checkpoint_manager = ocp.CheckpointManager(check_path, options=check_options, item_names=('state', 'metadata'))
checkpoint_manager.save(
                    step=iter_num,
                    args=ocp.args.Composite(
                        state=ocp.args.StandardSave(state),
                        metadata=ocp.args.JsonSave((model_args, iter_num, best_val_loss, losses['val'].item(), config))))

orbax-checkpoint   version:          0.5.9

Warning looks to be erroneous, probably has to do with your state containing some empty nodes, or similar. I'd say don't worry about it. We're doing some refactoring that should make erroneous warnings like this go away.


Publish master to 3.1.2-SNAPSHOT repository

It looks like 3.1.2-SNAPSHOT isn't pushed to sonatype.
Could you please do that?

@kongchen ping


EA App - Origin [ Force change app ]

Hello, since the origin application for pc has now forced me to install the EA-app and in order to continue playing the games on that platform, can you update the plug-in or extension with EA-APP? a thousand thanks.

#13


Error running the test for configs/psgtr/psgtr_r50_psg.py

I tried to run the following on (tiny_psg.json dataset):
(/home/openpsg_env) root@c6747fffa95c:/home/BTP/OpenPSG# python tools/test.py --config configs/psgtr/psgtr_r50_psg.py --checkpoint epoch_60_psgr.pth --eval sgdet

I ran into the following error:
load checkpoint from local path: epoch_60_psgr.pth
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 2186/2186, 3.2 task/s, elapsed: 678s, ETA:     0s
Loading testing groundtruth...

[>>>>>                                             ] 231/2186, 121.5 task/s, elapsed: 2s, ETA:    16sTraceback (most recent call last):
  File "tools/test.py", line 245, in <module>
    main()
  File "tools/test.py", line 237, in main
    metric = dataset.evaluate(outputs, **eval_kwargs)
  File "/home/openpsg_env/lib/python3.7/site-packages/cog-0.0.1-py3.7.egg/openpsg/datasets/psg.py", line 383, in evaluate
IndexError: too many indices for array: array is 1-dimensional, but 2 were indexed

Hi，i meet the same problem。Have you solved the problem

Nope. I'm still trying.

Nope. I'm still trying.

I download full datases and use "psg_val_test.json" for test.but i meet the same problem.

Sorry, I was on vacation in the past few days. You could check this part. Also, please use our full-released dataset in the README News.

Thanks,i will try this way!


Properly escape special characters in MVC Areas doc

The MVC Areas doc is displaying http:///products instead of http://<yourApp>/products. This PR addresses the problem by escaping the less than and greater than characters.

Hi @scottaddie, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

@scottaddie  Thanks!


What does PublicKeyCredential is not defined error mean?

Clicking the continue buttons print the error below into the console:
Uncaught (in promise) ReferenceError: PublicKeyCredential is not defined
    at index-b7476a59.js:2:4291
    at f (regeneratorRuntime.js:44:17)
    at Generator.<anonymous> (regeneratorRuntime.js:125:22)
    at Generator.next (regeneratorRuntime.js:69:21)
    at r (asyncToGenerator.js:3:20)
    at s (asyncToGenerator.js:22:9)
    at asyncToGenerator.js:27:7
    at new Promise (<anonymous>)
    at asyncToGenerator.js:19:12
    at Cr (index-b7476a59.js:2:4306)

Version: 1.0.3

@mertyildiran we need more details here.
Exact steps to reproduce.
Project id.

Thanks!
We are looking into this.

hey @mertyildiran
Thanks for the feedback
few follow-up questions: I see you are using chrome 113, may I ask which OS + version are you using?
The reason that I'm asking is because the PublicKeyCredential is a browser API that is used in a dependency of the react sdk  (which is another Descope package) for biometrics authentication support
I see in most of the places, it consider a case where the browser is not support it, but there can be a flaw in the way it is done, or maybe a place that it misses to check that it is support it

hey @mertyildiran
Thanks for the feedback
few follow-up questions: I see you are using chrome 113, may I ask which OS + version are you using?
The reason that I'm asking is because the PublicKeyCredential is a browser API that is used in a dependency of the react sdk (which is another Descope package) for biometrics authentication support
I see in most of the places, it consider a case where the browser is not support it, but there can be a flaw in the way it is done, or maybe a place that it misses to check that it is support it

Browser and OS
Chrome: Version 113.0.5672.92 (Official Build) (64-bit)
Linux distro: Ubuntu 20.04 LTS
Kernel version: 6.0.12-76060012-generic
NPM
react version: 17.0.2
react-scripts version: 5.0.1
@descope/react-sdk: version: 1.0.3
webpack version: 5.83.1
package.json:
"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

tsconfig.json:
{
  "compilerOptions": {
    "outDir": "dist",
    "module": "esnext",
    "lib": [
      "dom",
      "esnext",
      "dom.iterable"
    ],
    "moduleResolution": "node",
    "jsx": "react-jsx",
    "sourceMap": true,
    "declaration": true,
    "allowSyntheticDefaultImports": true,
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "downlevelIteration": true,
    "noFallthroughCasesInSwitch": true,
    "target": "es5",
    "esModuleInterop": true
  },
  "include": [
    "src",
    "src/types"
  ],
  "exclude": [
    "node_modules",
    "dist",
    "example"
  ]
}

By the way, it happens specifically when I build the Docker image:
FROM node:16-alpine as builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build

Maybe related to being node:16-alpine I don't know. The local build does not reproduce the issue.

By the way, it happens specifically when I build the Docker image:

FROM node:16-alpine as builder

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm ci --omit=dev

COPY . .

RUN npm run build

Maybe related to being node:16-alpine I don't know. The local build does not reproduce the issue.

Got it, thanks for the tip

@mertyildiran the fix is available in the latest next version @descope/react-sdk@next version, and will be generally available in the next release
to use latest next version you can install it directly:
npm i --save<EMAIL_ADDRESS>

@mertyildiran the fix is available in the latest next version @descope/react-sdk@next version, and will be generally available in the next release
to use latest next version you can install it directly:
npm i --save<EMAIL_ADDRESS>

Thanks for the update @asafshen!
I have upgraded to<EMAIL_ADDRESS>but it seems like there is a new error now:
Uncaught TypeError: t.get is not a function
    at o (tslib.es6.js:209:23)
    at new n (index-84419228.js:1:5757)
    at n.<anonymous> (createSuper.js:11:24)
    at new n (index-84419228.js:1:12631)
    at rs (react-dom.production.min.js:206:287)
    at Cl (react-dom.production.min.js:251:81)
    at xl (react-dom.production.min.js:250:408)
    at Tl (react-dom.production.min.js:250:278)
    at Sl (react-dom.production.min.js:250:138)
    at ml (react-dom.production.min.js:243:163)

and the login form does not appear.

@mertyildiran thanks fro the quick feedback
I could not reproduce (yet) this error, are you sure that this error comes from the Descope sdk code?
few questions:

Do you have a way to run the application with a sourcemap, so we can see the exception call-stack with proper names/files?
Does the error happen when the code is running both locally and served from a docker container?
I have created a simple application that runs a simple react application inside a docker container (fyi it is running against mine Descope project). can you see if that reproduce there when you run it? can you change the code/create a simple open source example where this reproduces?

I'm here for any questions

@asafshen I have created a new issue here: https://github.com/descope/react-sdk/issues/301


OutOfRangeError (see above for traceback): End of sequence 	 [[node IteratorGetNext (defined at G:\git\CenterNet-tensorflow\CenterNet.py:63) ]]

I met this issue when training on my own dataset. I realize that my " .tfrecord" file has size = 0 bytes on disk. I think that's the reason why my error occurred. Does anyone have the same issue, and how to fix it? Many thanks!!!!!

tfrecord generate failed

thanks!!! I fixed my bug.


Longer date spread

We need to test the edit_times visualization with a longer UTCTime spread, right now it's only a few days variance past a date in 2009. This should look a bit more real, maybe by adding ~ 0-100 arbitrary edit times per year every year since 2009.

This is a few minute fix I will get tomorrow morning.


Plugin not working with nested components

I've got the following:
{{confirmation-button confirmAction=(action "settle")}}
{{confirmation-button confirmAction=(route-action "settle")}}

In the confirmation-button template. I've got another component:
{{loading-button clicked=attrs.confirmAction}}

The loading button component object has:
  click() {
    console.log(this.attrs.clicked);
    this.attrs.clicked();
  }

When the the loading-button component is clicked. There are no issues with {{confirmation-button confirmAction=(action "settle")}}
console.log  returns:
function () {
        var args = arguments;
        if (valuePath && args.length > 0) {
          args = Array.prototype.slice.apply(args);
          args[0] = _emberMetalProperty_get.get(args[0], val…

However, {{confirmation-button confirmAction=(route-action "settle")}} returns:
Uncaught TypeError: this.attrs.clicked is not a function
console.log  returns:
Object {MUTABLE_CELL [id=__ember14546043676981018055021323]: true}MUTABLE_CELL [id=__ember14546043676981018055021323]: trueupdate: (val)value: ()__proto__: Object

Is it because ember-route-action-helper is returning a different attr object?

I'm updating the readme, but you should do:
{{confirmation-button confirmAction=(action (route-action "settle"))}}

This is primarily because the route-action helper doesn't return a closure action, so you have to wrap it in an action subexpression to turn it into one.
As a sidenote, you don't have to use attrs in your template, you can do:
{{loading-button clicked=confirmAction}}

Thanks for that! Seems to work.
Awesome plugin. Keep up the good work!
Closing case for now.

Same issue solved! Thanks for the nice addon. Any way to make this a closure action by default? Seems like most of the actions end up being consumed deeper down.

@brancusi Maybe open up another issue? I agree with closure action by default. Makes more sense

I think we can fix this.

Submitted a PR to help prevent folks from double wrapping.

Sweet! Looking forward to this


chore(dep): bump runwasi to 0.6.0

this will bring the new performance improvement to the spin shim.
re: #41

Closes by #126


Bug(argocdapp): crd isn't a namespaced resource

Describe the Bug

config.yaml
    options:
      # information on the ArgoCD application
      app:
        # name of the ArgoCD application
        name: hello
        # where the ArgoCD application CRD will be created
        namespace: argocd

The CRD can be either namespaced or cluster-scoped, as specified in the CRD's scope field:
https://github.com/merico-dev/stream/issues/259
For argocd app, it's namespace scoped:
https://github.com/argoproj/argo-cd/blob/master/manifests/crds/application-crd.yaml#L18

@IronCore864 That's CR's, not crd, crd is cluster-scoped.

"# where the ArgoCD application CRD will be created" ->
"# where the ArgoCD Application will be created"

/assign @daniel-hutao
I'll fix this problem while submitting the Chinese version of Quick Start tomorrow.


.hidden-sm-down not hiding until viewport is 766px wide

I'm working on a site, where in the header I have a logo in the left and a menu in the right. In small size I want to hide the menu and put in the hambuger menu. I use hidden-sm-down for it, but the class hides the menu one pixel down. So my small size starts at 767px, but the hidden class only effects at 766px. It's a problem because my logo's container is 12 unit wide in small size, therefore in 767px it push the visible menu a row under. Am I using this class wrong or there is a bug in the grid?

That sounds like a bug in the grid. I can't reproduce the misbehavior you're describing though.

Please ensure that you're using either the v4.0.0-alpha.2 release or the v4-dev branch.
What OS and browser are you using?

I'm using v4.0.0-alpha, can this be the source of the problem?
OS: Windows 10
Browser: Mozilla Firefox 42.0

@succli Very much so. Please upgrade and re-test.

This happened in:  v4.0.0-alpha. Due to the this code:
@media (max-width: 47.9em) {
  .hidden-sm-down {
    display: none !important;
  }
}

@media (min-width: 48em) {
  .hidden-md-up {
    display: none !important;
  }
}

767px is 47.9375em. The latest version of v4.0.0-alpha.2 under the v4-dev branch has it changed to: max-width: 767px and min-width: 768px.
Note: I checked the bootstrap.css file under /dist/css. I'm not sure whether this file is generated and the bug may still exist.

Assuming this is a duplicate of #17388.
If upgrading to the 2nd Alpha doesn't fix it, let me know.

For the record, all the files under /dist are generated; this is the purpose of that directory.


color map

How to color a polygon layer based on a variable value? like the thermal map. The polygons can be colored by specifying fillColor in Style, like the example in your tutorial:
style = {
"stroke": True,
"color": "#FFFFFF",
"weight": 1,
"opacity": 0.7,
"fill": True,
"fillColor": "blue",
"fillOpacity": 0.4,
}
Is there a way to make "fillColor" a function of a data field from geopandas dataframe the map plots?
Thank you very much.

See https://github.com/giswqs/leafmap/issues/28#issuecomment-859761849


Hook up TRS validator to build process

Feature Request
Desired behaviour
There's an old version of the TRS validator used as a test.
See whether the new validator can be used as a test.

This involves decoupling the testing portion of the validator from the webservice part.

If I understand correctly, this is to validate the OpenAPI spec? What do you think about moving validation tests to the schemas repository so that it can be used as a test before releasing to dockstore?

@david4096
Hi,
This validator code is to ensure that Dockstore implements the current tool registry schema (version 2) correctly.
Currently, the code for this lives at https://github.com/ga4gh/tool-registry-validator/tree/feature/flask
I gave Gary a shout to get this merged in and the readme updated since I hadn't realized that it wasn't merged.
Specifically in the validator directory it runs the site now deployed at https://ga4gh.github.io/tool-registry-service-schemas/ which if you give it a bit of time, it runs the validator on Dockstore.
This ticket specifically is to see if we can re-use some of that new code and see if we can use it in our Maven build as a test during development.
The validation tests are not, say, tests for whether an individual tool passes validation from a WDL/CWL POV, so it wouldn't be used as a test for them before releasing them on Dockstore, if I understand your question correctly.

Thanks for the details @denis-yuen ! We need a similar validation service for WES and DOS at the schema level, hence my interest ;). It looks pretty cool!


Feature request: start to debug C++/python directly from command line.

This a feature request. Currently, for C++ to debug the exe or attach a process, for python, to debug a py script, I've to setup launch.json, which is very tedious if you just want to do some quick very verification.
Request: start to debug directly from command line, eg
For cpp,
code -e cpp -d ./a.out arg1 arg2, argN: to debug a.out with arg1 and arg2.... argN
code -e cpp -p 12345: attach process 12345.
"-e cpp" means "pass the following parameters to vscode-cpptools extension."
For python:
code -e vspy -d ./a.py arg1 arg2, argN: to debug a.py with arg1 and arg2.... argN
"-e vspy" means "pass the following parameters to vscode-python extension."
As a comparison:
In visual studio, you can devenv.exe /debugexe a.exe
Eclipse has a plugin: https://github.com/eclipse-cdt/cdt/blob/master/debug/org.eclipse.cdt.debug.application/scripts/cdtdebug.sh, which allow you to start debug from command line.
Emacs (which is close to VScode since both VScode and emacs are editors while VS/Eclipse are IDE, you can pass some parameters https://stackoverflow.com/questions/5997309/start-emacs-gdb-from-command-line to start debugging directly.

There is a related one, https://github.com/Microsoft/vscode/issues/10979. However, it's about typescript. So I am not sure if mine is dup or that one.

#3502 and Microsoft/vscode-python#5396 are the related extension request.
I think it needs work from vscode and extension.

yes, this very similar to  #10979.
In general this feature can be implemented as an extension (and at least one extension already exists). It is not on our roadmap.

cpptool guys from https://github.com/Microsoft/vscode-cpptools/issues/3502, said “This would be a feature for VS Code itself. There is no commandline option to pass to the extension at the moment. Please submit an issue at https://github.com/Microsoft/vscode/issues”
Just FYI

The extension https://marketplace.visualstudio.com/items?itemName=fabiospampinato.vscode-debug-launcher proves that this feature can be implemented without directly VS Code support.

Hi @weinand , cpptools folks said "For this feature, this would require implementing VS Code's UriHandler which should call startDebugging with the given parameters.". Please see it here https://github.com/Microsoft/vscode-cpptools/issues/3502#issuecomment-486371241


problem downloading

When I put gdown url --fuzzy it doesn't download, it stays frozen, I don't know how to fix it

Try this code (its for files only): https://gist.github.com/henrych4/1Furfhe8BFbkEhXn1xcYPr8jYAACNpfV7p

@Okami321 Can you provide the URL that doesn't work?


fix: do not create more than 1 assistant projects

Description
There was a bug in getting the assistant integration ID, as when you do terraform apply back to back it won't return assistant integration ID...
that's because if you apply multiple times it will create many projects - hence there will be more than 1 assistance ID...
10281 ± curl -X GET -u "apikey:<apikey>" "https://api.us-south.assistant.watson.cloud.ibm.com/instances/999a9ef2-db68-42d9-bc06-9927883f7be8/v2/assistants?version=2023-06-1
5" | jq -r '.assistants[] | select(.name == "gen-ai-rag-sample-app-assistant") | .assistant_id '

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2931  100  2931    0     0   3192      0 --:--:-- --:--:-- --:--:--  3189
f5b94c74-691f-485b-b09b-783885e31b92
60390afc-b12f-4c88-8fac-94e3aa01e9d6
2a03a7c9-c2bd-4698-9c03-e485eeacb889
31d746c1-e01b-4b5d-ac2c-14c825dbca43
7c1054ba-b4c5-4c61-9dd9-ffc5eaad83ff

But the script assumes only 1 assistant ID to be returned. I discussed with @brendankellyibm and it was concluded to restrict creating more than 1 project.
Release required?

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

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

GitHub release
v1.4.7

Your semantic-release bot :package::rocket:


Remove synexpand and friends

^*#, ^#–^^^^#
Closes #227.

Maybe I can replace some of this with simpler pieces, but that's for later, if ever.


issue-11 Create ad and content layouts

Fix #11
Test URLs:

Before: https://main--channelco-crn-com--hlxsites.hlx.page/
After: https://issue-11-layout--channelco-crn-com--hlxsites.hlx.page/

@mfrisbey @samuelopra Few things that might want to look at before we actually merge this

Apart from the homepage, the side fragment isnt loading. See example here
Order of decoration looks weird as breadcrumb is autoblocked in eager mode, it gets loaded first and then delayed.js comes in..which created duplicated breadcrumbs within the right block
I think Sam is moving all contents from main in respective sections in the universal template but as breadcrumb is autoblocked as the first item under main, after the move it becomes a part of content section whereas it should be full width
The scroll behavior isnt implemented yet (can be done later if need be) but i think the right aside gets fixed position somewhere in the middle while scrolling


Inconsistent use of tabs and spaces

Forgive my python inexperience, I come from the .net world:
I’m trying to use this library in an application of mine. I must use python3. On startup, python complains of an inconsistent use of tabs and spaces in Order.py, line 130.  Is there a workaround or fix for this?
I’ve installed via pip3 if that helps.
Thanks
Traceback (most recent call last):   File "pizza.py", line 10, in <module>     from pizzapi import *   File "/usr/local/lib/python3.5/dist-packages/pizzapi/__init__.py", line 5, in <module>     from .order import Order   File "/usr/local/lib/python3.5/dist-packages/pizzapi/order.py", line 130     return response                   ^ TabError: inconsistent use of tabs and spaces in indentation

So I use Pycharm and it shows me the file from modules that has the indentation error, click on it, and then simply tab the last 'return' statement. Works for me


FPS Tanked w/ Logistics Pipes + Mek Bins

Suffering major FPS drops [like 90%+ drops] when using ultimate logistical transporters + Mekanism bins.
Not sure if it is flooding rendering updates or what but it is only with the bins as the logistics pipes by themselves don't cause it even when transferring insane amounts of items to say... 10 overclocked recyclers. Ran into something like this with Pressure Pipes tanks when using the tank indicator and bdew tracked the problem to his rendering update code firing waaaay too much as the tank indicator was constantly changing as the tank filled and I believe he said something about "complex models" being within a 16x16x16 range around the tank indicator, ie models that have rendering updates often/constantly if that helps.
I don't have this issue using Storage Drawers or any other storage systems.
Mekanism 9.1.1
MC 1.10.2
Forge 2065
Thanks

Additional: Tried setting opaque transmitters and no change in fps. Definitely the bins. Once items stopped transferring to the bin, fps went back to normal immediately.

Cannot reproduce with latest version


Font sizes increase in Gmail on iPhone XS

I have email with two paragraphs (1st paragraph: 1 column and 2nd paragraph: 2 columns) - both paragraphs have the texts with the same font-sizes. When I look into the email on my iPhone XC in Gmail app in portrait view - the font-sizes are fine (both the same). When I rotate the email to look at it in landscape view, then the text in 1 column paragraph is display bigger than the paragraph with 2 columns. The text in 2 columns paragraph is displayed correctly.
When I look on the same email in Mail app on my iPhone XS, then both views looks good - with the good font-sizes.
Portrait view in Gmail app (this is the correct font-size):

Landscape view in Gmail app (1st column has bigger font than it should be):

I tried to google but didn't find anything what can help.
May I kindly ask you to advice me or navigate me where I can find the help?
Thank you very much in advance.

I don't think the behavior come from MJML here.
Can you share some code to reproduce here : https://mjml.io/try-it-live
Message ID: @.***>

Hi iRyusa,
I put the code here - https://mjml.io/try-it-live/OyuYGshWDo
Thank you very much for your advice or help.
Karin

Hi Riusya, I tried to use also:
-webkit-text-size-adjust:none;
but no effect.
Do you have any clues, please?
Thank you very much in advance.

I've reproduced but it seems to be something that come from gmail app and not MJML code as it ignores the inline style.
I don't think we'll be able to fix.

Many thanks for your efforts and the time you put into this!

That's a really weird behavior from that email client :/
I'm closing the issue then 👌


Vickel: Watch +1-800-270-1894

Vickel requests the watch of the watch_number +1-800-270-1894. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Jeff Schaller in Charcoal HQ


Add milvus bulk

Description
This PR adds in bulk ingest functionality, that can be used in a chained set of tasks or as a solo task after the fact. There were some changes made to the schema, because JSON dtypes are not compatible with parquet files. With #179 this closes #164. A large portion of the code reflected here is actually from #179 because it builds and requires that implementation.
Checklist

[x] I am familiar with the Contributing Guidelines.
[ ] New or existing tests cover these changes.
[ ] The documentation is up to date with these changes.

@mpenn If you have time could you take a look at this.

/ok to test


New lines added after Python comments

Is there anyone experiencing the issue that a new line is added after every Python comment? It is just for Python specifically, not other languages. I tried updating the highlight.js to the newest version but it didn't solve the issue.
Markdown:
```py
a_set = {1, 2, 3, 4, 5, 5}
a_set.add(99)
a_set.add(3)

# print {1, 2, 3, 4, 5, 99}
print(a_set)
```

Display:

I see that happening in PHP comments too, but only in my local Windows environment. When building with GitHub actions under a Linux VM, everything is fine, oddly. Both environments use Hugo 0.67.0.

Is this rendering not purely the responsibility of highlight? Or is there some CSS style from the theme bleeding over into rendered code blocks?

As far as I can tell this happens only with a file containing CRLF line breaks, rather than LF (e.g. on Windows).


RDKTV-9120 : No Xcast post FTUE

Reason for change:
No Xcast post FTUE
Test Procedure: None
Risks: Low
Change-Id: Ic97d3044b6850195bb698d8d67985dbbac25cfbb
Signed-off-by:Anooj Cheriyan<EMAIL_ADDRESS>

review comments modified: New PR: https://github.com/rdkcentral/xdialserver/pull/19


Message Grouping Not Respected When Using JMSXGroupID

We are experiencing issues with IBM MQ message grouping. Specifically, when we set the JMSXGroupID property on our messages, the messages do not arrive in the correct sequential order.
Expected Behavior:
When JMSXGroupID is used, messages sharing the same group ID should be delivered in the correct order, maintaining the sequence they were sent in. With multiple consumers (concurrency set to 10), messages from the same group should be directed to the same session/consumer, preserving their order.
Actual Behavior:
Messages are not delivered in the correct sequence, resulting in out-of-order message consumption within the same group.
Additional Information:

We tested the same setup with ActiveMQ, and it correctly maintains the message sequence as intended.
In our scenario, we would expect IBM MQ to route all messages with the same JMSXGroupID to the same session to preserve ordering.
Environment details:

Java Version: 17
Spring Version: 3.4.0
mq-jms-spring-boot-starter: 3.3.5

Here is an example project that demonstrates the issue: https://github.com/patrick-brielmayer/ibm-mq-message-groups

Tying groups to a single consumer is an ActiveMQ extension beyond the JMS specification.
See https://integration-development.ideas.ibm.com/ideas/MESNS-I-123 which is an enhancement request for IBM MQ. You can vote/comment on that. It's not something that can be handled through this repo.


Release v0.22.0

Acceptance Criteria

Release v0.22.0

Security Checklist

[X] Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.

This version was not rolled out because it has not passed the QA.


Strip extra whitespace

When setting up clearance in a recent project I noticed extra whitespace in
some of the generator templates.
This commit removes this whitespace to better conform to the style guide.

I don't run this project, but I want you to know that I personally, morally, ethically etc approve these changes.

Thanks @gabebw!
Do you think I should do what @houndci tells me to do? I know we've said that we shouldn't go back and fix old style violations, but at the same time, that's exactly what this PR does.

Out of context, I'd say yes, fix it, but I don't know the general coding style on this project (Hound can be out of date) so I defer to @derekprior.

Looks good. I'm :+1: on fixing the quoting.

I've fixed the quoting in 68741fd. Should I merge this?

merge away!

Thanks @derekprior! Merging.


Enable container mounts to refer to host path on the UVM

Signed-off-by: Abdul Waheed<EMAIL_ADDRESS>Signed-off-by: Justin Terry (VM<EMAIL_ADDRESS>

@kevpar - I had to carry this so can you take a look. I already signed off but just double check my work

CRI PR here: https://github.com/jterry75/cri/pull/31

Oh and the fix commit: https://github.com/jterry75/cri/commit/f3efc9fa633090d11e5daad011494dd787a0628e

@kevpar - I am merging this so that we can get it in. Please let me know if you see any issue.