proposal: all: add bare metal ARM support

Hello,
I'd like to request reconsideration of our previous proposal (declined) as there have been new simplifications in our patch that should solve some, if not all, concerns previously raised.
Small recap: our TamaGo project adds support for vanilla Go runtime and packages execution on ARMv7 bare metal. Please see the original issue which remains valid in its initial description.
The main changes of our most recent integration are as follows:

we completely removed any ARM exception handling or low-level assembly, with the exception of rt0 entry point support (here and here, which is required and included in Go for all supported architectures and a CallOnG0 function to facilitate external integration of exception handlers (which is very similar to existing approaches).

all remaining code is simple "glue" code adapter from other supported architectures and to extend support of a new GOOS keyword

runtime support in os_tamago_arm.go is much reduced compared to the first proposed version and now consists only of stubs and simple "glue" code.

Overall our latest patch has ~4200 insertions over 133 files, however the overwhelming majority of changes are one-liners two add GOOS=tamago support, almost verbatim clones of existing code (lock_js.go > lock_tamago.go,, mem_plan9.go > mem_tamago.go) and os_tamago_arm.go remains the largest newly added file.
We think these changes should address the main concerns that resulted the rejection of our previous proposal.
Our new patch should not raise any longer concerns on chip erratas as it is as agnostic as possible in the low level management of SoC specific, or even ARM, architecture. It allows external packages to provide ARM support.
We demonstrated useful implementation of all Go packages, including os and net, for instance we successfully enable networking with gVisor in our Ethernet over USB driver.
Since our last issue we implemented a full Trusted Execution Environment (GoTEE) with this framework as well as a full OpenPGP/FIDO U2F smartcard (GoKey).
Others have expressed interest for running Go on the bare metal and we also received contributions which extend support to other platforms such as Raspberry PIs using the same original Go distribution patch.
Given the recent refactoring that takes chip errata concerns out of the way, provides a more minimal patch, and the recent demonstrations of what can be developed with this, I kindy ask re-consideration of our proposal.
Thanks!

Hello,
In the discussion of the previous proposal, there was some minimal talk about builders for GOOS=none, e.g. https://github.com/golang/go/issues/37503#issuecomment-592514724 (which basically boils down to "Will there be a builder? Yes, there will be a builder.").
I think it would be useful to have a bit more concrete/detailed conversation about builder support.
To wit: suppose the proposal is accepted, and a GOOS=none builder is set up. Will this builder be capable of running "all.bash"?  Will the builder provide full support for "gomote" operations?  Suppose that someone from the Go team checks in a change to the compiler or linker, and a test fails on the GOOS=none builder.  Who will look at that failure and how?
Thanks.

all.bash currently runs on all tamago-go releases, I think overall builder and linker tests can happen identically to other architectures.
The challenge would only be for runtime tests that are written in a manner that depends on an OS being present, I am not sure how this is currently handled for platforms like plan9 or js. What I can say is that this can run under qemu.

For JS, iOS, and Android, tests are run by having a separate host for builds and invoking the binaries using go_*_exec scripts:
~/go$ find . -name go_*_exec*
./misc/wasm/go_js_wasm_exec
./misc/ios/go_ios_exec.go
./misc/android/go_android_exec.go

Presumably the TamaGo builder would need a similar script.

The challenge would only be for runtime tests that are written in a manner that depends on an OS being present, I am not sure how this is currently handled for platforms like plan9 or js.

Plan 9 can run the actual Go toolchain, albeit slowly.
For JS, Android, and iOS, cmd/dist distinguishes between tests that build and invoke Go subprocesses and tests that should run directly on the builder. (Search for registerHostTest in src/cmd/dist.)
Test binaries that contain a mix of the two can use internal/testenv.MustHaveExec to mark that they need an OS capable of starting subprocesses. If there are other bits of OS functionality that could be missing, they may need additional testenv functions.

Understood, I see no problem in having a similar approach for TamaGo. We could provide use an USB armory as separate host to receive the tests or maybe (easier) just have a script that spawns the test within qemu ?

This may be of interest to @tinygo-org
/cc @deadprogram @aykevl @justinclift

Why is it difficult to maintain this tree as a GitHub fork of golang/go?

It is currently not that difficult, but its inclusion upstream would help ensuring that a GOOS=none support is minded in relation to potentially breaking changes, that its quality is consistent with the rest of the Go distribution code and that it would remain available over time.
Secondarily it would also help promoting, and further develop, this use case among Go user base.
Allowing easier hooks to generic "GOOS=none" within Go can certainly spawn up more interesting uses beyond the specific TamaGo goals and implementation, so I think in general it would help the Go ecosystem.

What you are saying is that it would move the maintenance burden for this code off of your team and onto the Go contributors more generally. Saying "its inclusion upstream would help ensuring that a GOOS=none support is minded in relation to potentially breaking changes" is another way of saying "it would be yet another special case, little-used port that slows down maintenance and development of the primary ports", or perhaps of saying (without realizing it) "we don't intend to keep up with your changes and want you to do it".
Contribution of new ports are "free like a puppy", to use the old Sun line: they are a gift that will require significant time and effort to keep alive. We already have a bunch of those, and inevitably the contributors move on, leaving us responsible for either continued upkeep (which takes away time we could be working on changes that benefit far more users) or removing the port (which makes us the bad guys).
I would much rather figure out what is making it difficult to keep this port out of tree and fix those underlying issues. That would let you maintain the port as you see fit and decouple our development and yours. It would make clear who is responsible for ongoing maintenance and fixing issues. It would scale far better - we can't put every port into the main tree. And it would provide a model for the next niche port.

I don't have a strong opinion either way, but: how does GOOS=none compare to, say, GOARCH=loong64? If the point is to have someone responsible for its maintenance in-tree, perhaps Andrea would be up for that.

My team (more than once) and expressed the firm intention to maintain this. Please stop saying that we want upstream inclusion to offload maintenance because this is simply not true.
This proposal specifically would ease integration of TamaGo like ports in Go, so the way I see it it specifically addresses the current challenges in doing so by acting as a generic ARM template and possibly in the future for other architectures.
This effort is to promote a generic framework and hooks to be accepted upstream with our contribution to maintain it.

Let me be more clear and re-state my thinking. I think our patch specifically helps addressing the challenges in creating new ports of this kind and this is why we think it should be upstreamed (with our firm intention to maintain it at least for ARM).
It is not the intention of our proposal to just "offload" this for our own convenience. We are excited about using Go on the bare metal, promote its use and help make it easy for all while preserving this possibility in the process.

I don't have a strong opinion either way, but: how does GOOS=none compare to, say, GOARCH=loong64? If the point is to have someone responsible for its maintenance in-tree, perhaps Andrea would be up for that.

This is a good question. Empirically, GOARCHes require far less work to maintain than GOOSes. From Go's point of view, architectures vary far less than operating systems do: GOARCH variations essentially never get in the way of new work, while GOOS variations often do. (The variation of "no operating system" would be particularly different. In fact, the current patch assumes a single-CPU system - there is no threading or interrupts or note implementation. This is going to limit its applicability. And of course scaling up to a proper multiprocessor implementation would be significantly more work and more code to maintain.)

My team (more than once) expressed the firm intention to maintain this. Please stop saying that we want upstream inclusion to offload maintenance because this is simply not true.

I appreciate the present intention to maintain the code. I don't doubt at all what you are saying about your current intentions. But suppose five years from now your priorities shift. In that case, we would be left with another port that we must either maintain ourselves or remove from the tree (as I laid out before). This is why we must be willing to take on maintenance of the port in order for it to land in the tree. The current variety of ports (again, especially GOOSes) already creates a real drag on being able to make important changes to, for example, the garbage collector and the scheduler.
For ports that we cannot commit to long-term maintenance of, keeping them out-of-tree would make the responsibility much clearer. For as long as you maintain them, they would work and keep up with Go. And if at some point priorities shift and that project was no longer maintained, it would be clear what was no longer maintained. Either way, again, the responsibilities are much clearer if the port is out-of-tree.
I realize that we don't have great support for out-of-tree ports right now. But again I think it is worth figuring out what we could do to make that better rather than default to continuing to add every possible new port to the main tree. Good support for out-of-tree ports would also provide a better path for ports that do eventually need to be removed from the main tree.

Good support for out-of-tree ports would also provide a better path for ports that do eventually need to be removed from the main tree.

I would like to see that future happen. The closest thing we have right now are first-class ports, but it's not quite the same as it still encourages all possible ports to live in a single place.

On contributors leaving or losing interest...well that can be used as an argument against pretty much any contribution can't it? If any maintainers lose interest on the code they maintain the problem would be identical. If there are others that can pick the work up fine, otherwise the feature would be dropped I guess. Certainly I can see upstream inclusion of a GOOS giving it better chance of getting more manpower than keeping it external. Not sure how anyone is supposed to counteract this argument to be honest...
On multiprocessor support, as the idea is for this GOOS to be a general template I am happy to adapt for easier integration of SMP CPUs, in fact this could be a great exercise on making it closer to what you ask in the first place (easy addition if external architectures in GOOS=none).
On GOOS being harder than a new GOARCH, I am not sure I agree 100%. Some architectures are fairly broad in their scope while this is very a very specific and unique GOOS which actually has no dependency on a specific OS.
So I think this effort, if generalized correctly, should not need too much maintenance in the long term or anyway its maintenance would be quite similar to what plan9/nacl/js are doing...in fact most of the complex bits are 100% cloned from these GOOSes.
If there is interest I am happy to ponder an abstraction that allows SMP to take place as that is a valid concern.

On contributors leaving or losing interest...well that can be used as an argument against pretty much any contribution can't it?

Not really.  It can only be used as an argument against a change that the core Go team is not able to maintain.  Relatively few changes fall into that category.

On GOOS being harder than a new GOARCH, I am not sure I agree 100%.

This isn't hypothetical, it's based on tracking the areas that take the most time for Go's compiler and runtime work over the last couple of years.
I personally don't feel very strongly about this particular proposal.  But I hope we can all agree that it would be better if it were easier to maintain Go ports out of the main repository.  That state is clearly better than where we are today in every respect, and it also addresses this proposal.  So let's try to understand how much work that would be, and whether it is a feasible goal.  Thanks.

I think we are confusing layers a little bit (including myself).
Our proposal is a generic GOOS=none which would create a generic layer to extend the same GOOS to any bare metal SoC/architecture with external packages (like we are doing with tamago).
Bare metal (a.k.a. supervisor/system mode) is different than a generic GOOS in user mode (e.g. linux, macOS) which typically relies on system calls.
While I do think that our work could be somewhat be adapted to be so generic that it would also allow arbitrary user mode GOOS architectures, I probably think it would not be the best or more efficient approach due to this fundamental differences in execution mode.
What I care about is promoting (and preserving) the fact that Go can be a prime language on OS-less embedded systems, and while I'd be pleased if our work could also help Go in achieving cleaner abstraction for arbitrary GOOSes, fundamentally I am not sure this patch would be the right beginning for it, as GOOS=none is likely very different than GOOS=<some_other_os_running_go_in_user_mode>.

So essentially your proposal is to just add a GOOS=none, which is actually a plugin mechanism that would let people implement support for a specific architecture (like ARM) using an external package? And then if you set GOOS=none and provide an external package like the one you linked above for ARM, you would be able to enable support for none/arm as a GOOS/GOARCH couple?
Because this is not very clear by reading this proposal. A few questions:

What does GOOS=none do if you don't provide the external architecture implementation? (I suppose nothing). So a builder would actually target a specific couple like none/arm, pull the third party ARM implementation from github, and run all.bash on that?
os_tamago_arm.go mentioned above (which actually you'd call os_none_arm.go I guess) makes me think that GOOS=none does not provide a completely independent pluggable interface for GOARCHs, you would still need to commit ARM-support stubs in the main Go repo, but they're basically empty, and then the real implementation is in the third party package. Then if we wanted none/riscv64 you'd need a small patch in the Go toolchain (with files like os_none_riscv64.go), and then a third party package would provide the actual riscv64 support. Is that right?
How do people working on the Go toolchain make sure they're not breaking none/whatever? Or they shouldn't care, because it's actually essentially an out-of-tree third-party port? Of course you could argue that out-of-tree ports face the same issue.

TinyGo is both an LLVM-based compiler for Go, and a partial set of replacement stdlibs. So not really a full port as I understand it. If I understand correctly, if a given stdlib, such as runtime, is present in TinyGo's root, the compiler uses that in preference to the upstream version. Otherwise, the compiler uses the upstream version. GOOS=none could simplify TinyGo if it reduced upstream stdlib's dependence on running in user space.

How do people working on the Go toolchain make sure they're not breaking none/whatever?

It would be nice if there was a well defined API boundary, but something is better than nothing, and out-of-tree ports currently have no guarantee about stdlib internals, so Go toolchain developers not working about breaking out-of-tree GOOS=none ports won't be a change from the current status.

What does GOOS=none do if you don't provide the external architecture implementation?

Time will tell, but I think it may be unfair to characterize this as a niche.
I do recall ARM being characterized as a niche by some in the glibc community, including in this famous quote:
"Ulrich Drepper 2007-10-02 04:01:19 UTC
It's working fine everywhere but this carp architectures.  I'm not going to make
the code perform worse just because of Arm.  Providing your own copy of that
file if you care."
and now ARM deployments outnumber x86 deployments by at least 10x. But in the interim this attitude led to a full fork and eglibc.
Is tamago a niche use? Go on a new platform is a niche use by definition. But should tamago become useful in, e.g., silicon root of trust (SROT) applications such as the usbarmory, then tamago might well end up as widely deployed as all other Go platforms combined, since SROT is becoming ubiquitous (SROT is used in all new chromebooks, and will be used in all new servers). Future platforms will include at least one SROT, and some have more. Further, I'm starting to like tamago as a potential stack for Baseboard Management Controllers (BMC), as opposed to the gigantic, and vulnerable, Linux-based stack that is used today. This goes beyond SROT.
I understand your argument for forking golang. The Go team can only do so much. But you may be playing with fire here, because one way this can go is not "fork per unaccepted port", but "one community fork for all unaccepted ports", i.e., a new organization supporting the second-class ports.  If enough momentum forms behind a "community Go fork" that's more friendly to new platforms, a new Go team outside Google might form. It would be friendlier to new ports as, e.g, Rust is, and the momentum and interest could move to community go. This is not a new story. Recall that the most commonly used BSD variant is not the original one.
I understand this is a tough situation, but you're in the enviable situation of having succeeded well enough that people want to use Go. While telling people to "just fork" is an option, forks have a way of diverging -- ref eglibc. Parallel organizations are created that can eventually outshine the original one.
I think you also need to define the rules by which a sufficiently successful/widely used platform can be brought into the upstream tree from community go. It can't look hopeless.
That said, in anticipation that tamago will still not be accepted, I've created this:
https://github.com/community-go/go
The intent is this be a common place to support unaccepted/deprecated ports, or ports not quite ready for upstream but that might make the jump, with the current example being tamago.
From this, we can try to learn how to make fork maintenance easy. Having maintained an out-of-tree port for several years for Harvey-OS, I can tell you it's anything but easy today; with luck we can improve the situation.

@rminnich if I might make a suggestion - best to not name the org "comminity-go", as that can confuse those stumbling upon it. Go as a projecy already has a community contributing to the golang org, after all. Perhaps something more specific like go-extra-ports?

So essentially your proposal is to just add a GOOS=none, which is actually a plugin mechanism that would let people implement support for a specific architecture (like ARM) using an external package? And then if you set GOOS=none and provide an external package like the one you linked above for ARM, you would be able to enable support for none/arm as a GOOS/GOARCH couple?

(taking the liberty to s/tamago/none/ while linking at tamago examples to show how this would look like)
Correct, the external package could then contribute:

the ARM architecture specific parts which are not covered by the standard Go distribution (for example the MMU configuration, these are generic ARM functions that however different projects might decide to implement in a different manner, or simply to add more features such as our support for ARM TrustZone) and which are also prone to errata (a problem highlighted in our previous proposal).

the SoC specific support (e.g. NXP i.MX6 vs Raspberry Pi), including SoC specific drivers.

the various board support packages.

whatever utility might be handy or required, such as DMA access.

Because this is not very clear by reading this proposal. A few questions:

What does GOOS=none do if you don't provide the external architecture implementation? (I suppose nothing). So a builder would actually target a specific couple like none/arm, pull the third party ARM implementation from github, and run all.bash on that?

Without the external packages there are no drivers, so it's impossible to do any meaningful I/O or use anything other then the CPU.

os_tamago_arm.go mentioned above (which actually you'd call os_none_arm.go I guess) makes me think that GOOS=none does not provide a completely independent pluggable interface for GOARCHs, you would still need to commit ARM-support stubs in the main Go repo, but they're basically empty, and then the real implementation is in the third party package. Then if we wanted none/riscv64 you'd need a small patch in the Go toolchain (with files like os_none_riscv64.go), and then a third party package would provide the actual riscv64 support. Is that right?

It's not completely independent, the following files would be GOARCH=arm dependent:

the very initial assembly which acts as entry point: rt0_none_arm.s, sys_none_arm.s. I believe these can be provided externally with a linker script, it would be less clean and convenient imho, but it can be done if desired.

asm_none_arm.s, a quite short syscall wrapper.

zsyscall_none_arm.go and zsysnum_none_arm.go are ARM specific, but would automatically generated from syscall_none.go, here we just copied what GO does for other architectures however I do think I could potentially refactor this to remove any ARM specific bits (as in the end I don't think there should be any).

this stub probably doesn't need to be in asm and ARM specific

os_none_arm.go could be made non ARM specific (it isn't in fact) and be the main hook for external packages to add to the runtime (through go:linkname as we do now)

So I think I could make this completely independent from ARM if we really want to, otherwise even if we keep this scheme the patches for *_none_something else would be relatively simple and small to create and maintain.

How do people working on the Go toolchain make sure they're not breaking none/whatever? Or they shouldn't care, because it's essentially an out-of-tree third-party port? Of course you could argue that out-of-tree ports face the same issue.

I think the two most important pieces would be lock_none.go and mem_none.go (copied almost verbatim from js/wasm and plan9 respectively), however these are fairly self contained, with a clear goal and in my understanding they would entail a substantial change in the way Go works to be broken.
The residual risk  would be for the runtime, or some other vital standard package, to start relying on OS specific (e.g. system calls) aspects to perform basic operations. What allows Go to be so suited to the bare metal is its almost non-existent reliance on system calls for most of its core operations, which is what allows us to bring in almost every package without worries. Unless a testsuite for GOOS=none, with a sample external architecture such as tamago+arm, is included in Go standard build process this is a risk that will always remain. I am not suggesting this should also be addressed, I am just noting it for the sake of discussion.

@rminnich I agree with @mvdan that naming a new project community-go is unhelpful.  It's also premature.
Anyhow, I see two issues here.  The first is whether we can provide a reasonably stable runtime API to support arbitrary ports.  The second is whether we can provide a reasonably stable runtime API to support GOOS=none.  The second seems likely to be easier than the first, given the number of plan9 and windows specific files across the standard library.

I removed community-go. If we do decide to go with a fork, it will likely then be go-extra-ports or something similar.
Also, apologies if the use of the ulrich drepper quote was offensive to anyone, I mainly used it to try and illustrate just how badly things can go wrong. I've been on any number of open source projects which forked when people could not come to agreement, and it's always sad to see. All things considered, I'd rather not see that happen.

The residual risk would be for the runtime, or some other vital standard package, to start relying on OS specific (e.g. system calls) aspects to perform basic operations. What allows Go to be so suited to the bare metal is its almost non-existent reliance on system calls for most of its core operations,

What about multithreading, or preemption? I see nothing in what you described as the latest patch that addresses either one. Those are core OS functionalities that Go does depend on. To the extent that the tamago port does not provide those, it is providing a sub-standard Go experience. In particular, not having the ability to run on multiple CPUs seems like a complete show-stopper to me. That's not going to age well at all. (Also, maybe I missed it but I don't even see how the code puts the CPU into idle mode to save power when there are no goroutines running.)
I understand that you can get something kind of working easily. That was the case when I did GOOS=tiny a long time ago too. But I also understand, from other projects, how much work it is to create and maintain a real operating system capable of actually using bare hardware well. That's a huge amount of added complexity for the Go team to accept ultimate responsibility for maintaining. And it is ultimately why, although it was a fun demo, we also removed GOOS=tiny a long time ago too.
As an administrative note, we are starting two Go team quiet weeks, which means I won't be replying on this issue again until July 12, to avoid having a discussion that others might want to take part in.

There are existing architectures in upstream Go without preemption or multithreading, in fact those architectures provided the very same code that we use right now (NaCl, js/wasm) in parts of our patch.
Regardless of this I already expressed intention in this issue to be explore how to make multithreading hooks possible.
Concerning preemption this is possible for external implementation as external packages can create timed interrupts and supervisors, we plan to demonstrate this in our GoTEE project.
This is not just a fun experiment, we have thousand of units in productions running secure elements using TamaGo.
Lowering frequency is handled externally by the application through functions we expose in our SoC driver, however I am not sure why this would be a concern for this discussion as SoC support and drivers would be an outside concern.
We have created full support for NXP i.MX6UL series and received external contributions for Raspberry Pi, to me this proves the effort in making this usable is not inconceivable.
The topics you are raising fall in what the external packages would require to implement and are not meant to be addressed or cared by the GOOS=none support (intentionally and for the reasons yourself raised initially).
So I guess now you are moving the discussion towards whether the whole Go in bare metal philosophy has merit or not rather then specific GOOS=none patch details?
The very initial concerns to this entire effort was that it would "clutter" upstream Go too much with hardware specific patterns that would be difficult to maintain and now that we moved everything out the concern is (despite one proved example of solid driver/SoC/CPU implementation) that those are external packages would be difficult or a bad experience?
I welcome all questions and clarifications on our proposal as I think this is due process, but I think we are going a little bit all over the place here and the feeling is that the mind is set on rejecting our proposal no matter what.
If the projects we are creating and supporting (listed earlier: GoKey, our bootloader, GoTEE, Armory Drive) created with TamaGo are not sufficient to prove that Go helps tremendously on the bare metal I am honestly not sure what would be.

On "how much work it is to create and maintain a real operating system capable of actually using bare hardware well.".
I think our patch shows how this would not be a concern of the Go team given that all actual hardware use is taken care or externally from the patch.
In fact that's the whole point of it.

I am also interested in such applications. But wouldn't it be better if the entire runtime package as a whole can be replaceable?
That would allow more freedom for the external ports and meanwhile not be at odds with the canonical one.
For many applications (like CLI tools), we don't need a heavyweight runtime supporting the scalability of 100K QPS but rather one with small footprint and fast startup time.

I would much rather figure out what is making it difficult to keep this port out of tree and fix those underlying issues.

A stable (or at least versioned), documented API between the compiler and the runtime and a command-line option of the toolchain to alter the runtime package?

OK, I think everyone is back, and I'd like to get this to some conclusion.
I don't detect acceptance for bare metal go, upstream. Instead, we've been encouraged to fork Go.
There are other ports that have hit a wall over the years, such as Harvey-OS. Rather than a fork-per-unaccepted-port, we're thinking it would be nice to have a common place to collect unaccepted ports. An unaccepted port is one which has never been accepted, or is no longer accepted, upstream, i.e. it has been demoted. The name go-ports has been suggested by several folks.
The rules would look something like this:

go-ports is a downstream fork, and superset of, the latest release
a go-ports port can be promoted to upstream, if it makes sense
an upstream port can be demoted from upstream but remain in go-ports, assuming a maintainer
anything on the main go-ports branch has to build
but there is no requirement that all ports pass all tests, though this is encouraged
ports that don't "just build" will be placed on a branch
ports that lose maintainers will be placed on a branch

The remaining question is where go-ports would live: is it an organization, e.g. github.com/go-ports/... or is it under golang, github.com/golang/go-ports?

For what it's worth, those rules sound good to me. My present area of interest is a not-quite-bare-metal port of Go above seL4. Seeing worked out projects like TamaGo helps me dodge problems that others have seen and coped with.
github.com/go-ports/ would be preferable to avoid any misunderstanding about who provides support.
If the repository also helps the Go team monitor unexpected ways that Go is being used, that's a nice extra.

OK, it's done:
https://github.com/go-ports/go
Please let me know if I've messed anything up. I will try from here on out to do Tamago work on this repo.

Thanks for setting up go-ports/go. That seems like a great place to coordinate.
As I've noted before, if there are general things we can do to make out-of-tree ports easier, I'd be more than happy to see those proposed.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

As i said before on the previous issue, the current code of the Go compiler and runtime is often not structured modularly but relies an conditional compilation.
Support for out-of-tree ports would be a lot easier if a GOARCH or a GOOS would be provided by a (set of) package(s) in stead of conditional compilation all over the code.
Yes, that means more abstraction, but it would make the go compiler and runtime easier to read and easier to work on. That alone would be a significant benefit.

Support for out-of-tree ports would be a lot easier if a GOARCH or a GOOS could be provided by a (set of) package(s), perhaps even a go module, in stead of conditional compilation all over the code.

What does this mean exactly?

No change in consensus, so declined.
— rsc for the proposal review group

Support for out-of-tree ports would be a lot easier if a GOARCH or a GOOS could be provided by a (set of) package(s), perhaps even a go module, in stead of conditional compilation all over the code.

What does this mean exactly?

If I might extend this conversation just a bit, because this is definitely a topic of interest to me: it seems like we're talking about making things more modular such that different GOOS/GOARCH backends can be used, a la GCC and LLVM (which are also not exactly fully pluggable). I think that's a tremendously useful, if perhaps ambitious, concept. It would be decidedly easier to maintain out-of-tree port if the architecture/OS backends didn't need to drag the entirety of the compiler machinery with them.
But that would make it a lot easier for maintaining alternate ports out of tree. For example, I know there is already a sparc64 GOARCH, but it is only enabled for linux, and there is a solaris GOOS, but it is only enabled for amd64. There is an out-of-tree build of Go for Solaris/SPARC64 which I think was last updated around Go 1.8; I had a go at trying to update it a year ago and it seemed like a rather Herculean effort because a lot had changed in the surrounding code for other architectures.
I say this without a deep knowledge of the current compiler backend, of course, but I assume that this would be a pretty substantial change and something to be planned for several versions down the line if it were to happen.  There would need to be, as someone mentioned upthread, a well-defined and versioned API between frontend and backends, which would presumably involve dicing up the current architecture rather more than it is now.
I do have some provisional interest in this, but I'm relatively green at Go contributions. Is there a place I should start if I want to propose an approach after doing further research?

The place to start is to look at the runtime package.  Specifically look at the code that is built for a particular GOARCH, the code that is built for a particular GOOS, and the code that is built for a combination of a particular GOARCH/GOOS.  That will describe a complex set of APIs that need to be implemented for any new target.  Then try to figure out how those APIs could be supplied out of tree.
Actually a seperate GOARCH would be a big job requiring new assembler, compiler, and linker support.  Probably best to focus on just GOOS to start.

Since this is a closed issue, I'd be happy to take the discussion to the golang-dev mailing list if that's a better place.


Why not compile ExpressionNode?

RT, and code is here
    protected String generateSetter(OgnlContext context, CtClass newClass, CtClass objClass, ClassPool pool,
                                    CtMethod valueSetter, Node expression, Object root)
            throws Exception
    {
        if (ExpressionNode.class.isInstance(expression)
            || ASTConst.class.isInstance(expression))
            throw new UnsupportedCompilationException("Can't compile expression/constant setters.");

        ...
        return body;
    }

Not sure if I understand your request, as far I understand the code it prevents changing constants.


Fixed #8526, popup menu width now responds to submenu icon

I'm not a Github veteran.. what does the Travis CI want me to do? :/

Probably format according to clang specs? @AlexHoratio

https://github.com/godotengine/godot/tree/master/misc/hooks
this will help.

Hooray, I've satisfied Travis CI after a bit of flailing

Now you'll need to satisfy @godotengine/pr-mergers with a bit of spring cleaning of this commit history :) http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html#mastering-the-pr-workflow-the-rebase

Since it really didn't need more than one commit, I've stuck them all together. Thanks for your help!!


Could not find com.github.AppDevNext.Logcat:LogcatCoreLib:2.11.2

Could not find com.github.AppDevNext.Logcat:LogcatCoreLib:2.11.2
can you please check this?
this library that i use is dependance to the 2.11.2 version
https://github.com/hannesa2/paho.mqtt.android/blob/master/serviceLibrary/build.gradle

All is there https://jitpack.io/#AppDevNext/Logcat/2.11.2

Which version do you use ?


As a curator, I would like to collapsing properties individually

The changes:

Redesign context triple's property and metadata structure.
Implement expanding/collapsing for individual triple sets.
Restructure the CSS to allow for an acceptable placement of expanding/collapsing icons in a responsive way.
Fix the spelling of 'expand'.

About 1
The backend was sending the properties (and the metadata) as a single depth array of all triples.
The frontend would loop through this entire array (applying a filter each time for a given predicate) for every single predicate.
Instead of doing that, redesign the backend to provide a matrix with the keys being the predicate and the values being the set of all triples with that given predicate.
The frontend then no longer has to apply a filter and it needs only loop through the predicate set once and the subset of triples associated with that predicate once.
About 3
There is no good place for the collapse/expand glyphicon.
The best place I could come up with would be in the middle area between the predicate and its value.
Making this change required adding additional padding.
The exiting responsiveness behavior changes how the predicate label is display and as such the collapse/expand glyphicon must be changed with it.
The predicate label does not play well in its default structure of 'block' with the glyicon next to it and so the predicate label has been forcibly changed to 'inline'.

Coverage decreased (-0.04%) to 47.606% when pulling 6ab51805dedb031fbb91cc77892e0db1703a0dd8 on sprint-tcdl-b036904-collapse_individual into 62b79a9f685a64f35a5a62b73ae9bcf92c947534 on sprint-tcdl-staging.

I have not looked at the PR yet, but I am uncomfortable with the idea of backend changes for this feature. CAP is intended to offer to the components of the DAME a REST API for interacting with our institutional repositories.
The CAP UI should be seen as one of (hopefully) many clients to consume this API.
Given that, this feature seems to be about the display needs of one particular client of CAP's REST API.  As with any client, I do not think we should let its particular display proclivities dictate the structure of the data coming from the backend.
I do see how doing the arranging of these triples on the front end would be less performant, but I think that this is a price worth paying to allow the structure of the data the back end provides to remain neutral. I also think that, from a performance perspective the handling this all in the UI would be negligible.
These are my 2 cents, but I'd be interested in what some of the other developers think.

The front end processing/filtering of the properties and metadata are insignificant and angular provides elegant mechanisms to handle this sort of processing using filters. Alternatively, could simple post process them and create the map front end. Also, scalability would favor client-side processing over server-side processing, as growing number of concurrent requests would eventually slow down the server more so.
One thing I noticed was that the API would hand down redundent data. A list and a map with the same information.

The backend changes don't look like they're  required to complete the card.
A request should be created in version one to describe the desired changes, giving the development team and customers the opportunity to discuss, evaluate, size, etc.

As per our discussion here is an example of a before callback being registered within the client side RepositoryViewContextRepo.
There can be any number of these before callbacks registered, so it would need to be determined if it makes more sense to do an additional callback, or handle the data manipulation within the existing before callback.

Looks good to me!


Remove-DbaAgentSchedule - New feature ScheduleUid

Type of Change

[ ] Bug fix (non-breaking change, fixes # )
[X] New feature (non-breaking change, adds functionality, fixes #5353)
[ ] Breaking change (effects multiple commands or functionality, fixes # )
[X] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] If new file reference added for test, has is been added to github.com/sqlcollaborative/appveyor-lab ?
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose
The command can only remove schedules based on their name. Theoretically it's possible to have multiple schedules with the same name which makes it hard to remove the schedule.
Approach
The command now has the ability to assign the ScheduleUid.
Commands to test
Get-DbaAgentSchedule
Remove-DbaAgentSchedule
Screenshots
Changes to Get-DbaAgentSchedule

Removing the schedules based on the UID

Learning

Fixes #5353

Yall are awesome 🏆! Thanks so much for the screenshots ❤


Add Redbubble

We use Greenhouse.io, so i think that qualifies!

I've just looked at our application page, and it turns out we do ask for more fields than i remember.  I wonder if this still qualifies as easy?

^ that's pretty much the extent of it, though.


Variable connect bug

It only hash "<input.USER><MD5PASS>Mq7$LXmTW#YNjRmr"
instead of "SomeTextHere<input.USER><MD5PASS>Mq7$LXmTW#YNjRmr"

Thank you, this was a big game-breaking issue with ALL interpolated strings due to the recent changes to regex. I reverted the changes in https://github.com/openbullet/OpenBullet2/commit/7638becb6d0eb234bfd579cd82ef51cde6f5aaf3
I will push an urgent update and add some unit tests for this so it doesn't happen again in the future.

Update 0.1.3 pushed, please everyone update your OB2 or most configs will not work.


chore: Renovate/rsa 4.x

Not sure how well this will play with renovatebot.

Change made by some github magic (https://github.com/GoogleCloudPlatform/python-docs-samples/pull/7158/commits/000baf4fb2b4af0fac8d434b98d02cb4966a9cd2), so closing this PR.


:racehorse: Add feature [Maintenance Mode]

The system maintenance mode helps you improve the user experience.
This function can be turned on in the bb-config.php file.
Just set
'maintenance_mode' => true,

to enabled maintenance mode. Once turned on, your users will
receive a maintenance notification when accessing the API and front store.
This process will not interfere with the administrator login and use of the
admin area interface.
For redesign your maintenance page, you can edit template file at:
/bb-themes/boxbilling/html/maintenance.phtml
Issues: https://github.com/boxbilling/boxbilling/issues/1094

Both config file and admin area at the same time is okay? But there will have a priority to ensure that it can still be works fine when the administrator interface is not accessible.

bb-config.php [High Priority]
Admin area [Base Priority]

Why would there be a priority?
Just make it if it's enabled in either location that it'll display the maintenance mode screen

I want to give up making this decision. Therefore I am willing to maintain the use of bb-config.php to manage the maintenance mode. At least, who should be the webmaster or technical engineer to enable this mode, because the operation of bb-config.php should not feel difficult.

I want to give up making this decision. Therefore I am willing to maintain the use of bb-config.php to manage the maintenance mode. At least, who should be the webmaster or technical engineer to enable this mode, because the operation of bb-config.php should not feel difficult.

Well, I think making the option configurable from the web interface can be a future task. But I'd be glad if someone gets tests working before merging this.

@londry I'm okay to have an option in the admin area. Also I think we should move the admin area paths to the config instead of hardcoding them.

Depending on the user's installation path, the Admin Path will change in the future. We can't guess whether the user will change these configurations if in bb-config.php. I think the best way is to hard code currentlly, because it can adapt to changes in the installation directory.

If there are no other objections, we can facilitate the merger process to close this topic. Its time to make a decision. @evrifaessa

If there are no other objections, we can facilitate the merger process to close this topic. Its time to make a decision. @evrifaessa

Well, I already said the tests have to run before I can merge anything.

I implemented Cloudflare's CF-Connecting-IP, used Box_Request to get the visitor's IP and made a few other changes. It seems good to merge, but I still would like to hear some reviews from other maintainers.

Do we need these changes for this PR?
It's good feature, and those changes are what caused the failing tests

Do we need these changes for this PR? It's good feature, and those changes are what caused the failing tests

I've reverted what possibly could break the tests. Now it should be good to go. We can implement Cloudflare's headers later.


Added ShanWan WUP-028 Gamecube Adapter

I set the configuration using AntiMicroX 3.1.5 and the physical switch on the adapter set to "PC" instead of "SWITCH/WIIU".
Micro Center carries this particular model of controller (https://www.microcenter.com/product/606375/ttx-tech-gamecube-controller-adapter-for-wii-u-and-switch).

How have you mapped the GameCube face buttons? Can you confirm (or edit so that) GameCube  B and X are SDL x and b? This is how these are meant to be laid out (matching location, not label). Thanks

@0verk1ll

Yes, I did map the buttons according to the labels on the face of the controller. Thank you for changing my commit.

thanks for confirming!


Need better label in Proteome Comparison

The label "FASTA FILE" in the dialog should explicitly mention fasta of proteins; it's easy to get confused and not understand what should be there. Perhaps a help icon as well would help.

I will go head to update the label. The help icon next to "Comparison Genome" does make it explicitly:

And/or select FASTA file
Select or upload an external genome file in protein FASTA format.


include utility functions to add dq tasks dynamically

Utility functions need to be added to create dq tests dynamically.
this function will pass in a list of yaml paths and create a task for each dq test.
These yaml configurations may also include parameters to configure parts of the dq check (suggested by Drew Ellingson)
alternatively, the function may also pass through the directory path, and walk through to find all yaml tests in that directory.

Example usage:
dq_checks = [
    ('/path/to/dq_check1', {'config_arg1': 'config_val1'}),
    ('/path/to/dq_check2', {'config_arg': 'config_val'}),
    ...
]

dq_checks_tasks = create_dq_checks(dag, dq_checks)

start >> dq_checks_tasks >> end

@rbriski
Thoughts?


Add build from source notes

This adds documentation for building via ninja on OSX and Linux pending FileCheck instructions

@swift-ci please test

Will merge this one and update lit/FileCheck notes in a follow-up commit.


[Umbrella] Add sort connectors which support Flink 1.15

Describe the proposal
Currently there are two sort connectors that can be running on both flink1.13 and flink1.15 which are starrocks and PostGreSQL
We should provide flink 1.15 support on all connectors that can only run on flink 1.13
They are :

mysql-cdc
elasticSearch
hdfs
iceberg
jdbc
kafka
pulsar
tubemq
mongoDb-cdc
sqlServer-cdc
redis
doris
hbase
hudi
kudu
oracle-cdc
hive

How to tackle down
Take hudi connector as an Example

Please make sure that you have read and understand this post : https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sourcessinks/
Please make sure that you have read and understand every line of code in hudi connector on flink 1.13 (If things are not clear to you please present a issue or discussion on https://github.com/apache/inlong)
Most of the systems have their flink connectors on their github page, for instance hudi (https://github.com/apache/hudi/blob/master/hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/table/HoodieTableFactory.java), we will import this dependency and add our inlong-specific features (metric, audit) on them.
Make sure you add license after modify the TableFactory in /licenses/inlong-sort-connectors
Run some tests on flink1.15 and make sure your connector works
Modify inlong-distribution and make sure the connectors will be compiled just fine

Make reference for these two connectors:
https://github.com/apache/inlong/pull/8235
https://github.com/apache/inlong/pull/8193
Task list

[ ] https://github.com/apache/inlong/issues/8241
[ ] https://github.com/apache/inlong/issues/8358

InLong Component
InLong Sort
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@hnrainll thanks, #8358 was assigned to you.

I want add TubeMQ connector on flink 1.15.
The issue I submitted is https://github.com/apache/inlong/issues/8922


Fix HermesExecutorFactory build error

Summary:
https://github.com/facebook/react-native/commit/7af288e5 introduced a breaking change for whoever importing HermesExecutorFactory.h, because the hermes/inspector-modern/chrome/HermesRuntimeTargetDelegate.h is not a public header. Also the nested import is not ideal for CocoaPods or use_frameworks.
I think HermesRuntimeTargetDelegate could be an implementation detail that hide from header. This PR tries to turn the ownership declaration from std::optional to std::unique_ptr, so that we could hide the concrete type.
Changelog:
[IOS] [FIXED] - Fixed HermesExecutorFactory.h build error when importing its private header
Test Plan:
should introduce no breaking change and ci passed

thanks for merging the fix 🙏


ValueError: empty vocabulary; perhaps the documents only contain stop words

Describe the bug
Traceback (most recent call last):
  File "train.py", line 9, in <module>
    cdqa_pipeline.fit(X=df)
  File "E:\Python\cdQA\cdqa\pipeline\cdqa_sklearn.py", line 86, in fit
    self.retriever.fit(self.metadata['content'])
  File "E:\Python\cdQA\cdqa\retriever\tfidf_sklearn.py", line 75, in fit
    self.tfidf_matrix = self.vectorizer.fit_transform(X)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 1652, in fit_transform
    X = super().fit_transform(raw_documents)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 1058, in fit_transform
    self.fixed_vocabulary_)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 989, in _count_vocab
    raise ValueError("empty vocabulary; perhaps the documents only"
ValueError: empty vocabulary; perhaps the documents only contain stop words

To Reproduce
Steps to reproduce the behavior:
import pandas as pd
from ast import literal_eval
from cdqa.pipeline.cdqa_sklearn import QAPipeline
from cdqa.utils.converters import pdf_converter

df = pdf_converter(directory_path='E:/books')

cdqa_pipeline = QAPipeline(model='bert_qa_vGPU-sklearn.joblib')
cdqa_pipeline.fit(X=df)
cdqa_pipeline.predict(X='What is?')

Expected behavior
Prediction
Desktop (please complete the following information):

OS: Windows 10

Hi
This is due to our default implementation of the retriever which is based on sklearn's TfidfVectorizer.
As you can see here, the default value of param max_df is 0.85.
https://github.com/cdqa-suite/cdQA/blob/3c65bffc883b9097e8579c67d3f04caf5879dfab/cdqa/retriever/tfidf_sklearn.py#L57
You can override this parameter directly when casting the QAPipeline() class, for example setting it to 1 should solve your problem:
cdqa_pipeline = QAPipeline(reader='models/bert_qa_vGPU-sklearn.joblib', max_df=1.0)
cdqa_pipeline.fit(X=df)

With your code I get
Traceback (most recent call last):
  File "train.py", line 8, in <module>
    cdqa_pipeline.fit(X=df)
  File "E:\Python\cdQA\cdqa\pipeline\cdqa_sklearn.py", line 86, in fit
    self.retriever.fit(self.metadata['content'])
  File "E:\Python\cdQA\cdqa\retriever\tfidf_sklearn.py", line 75, in fit
    self.tfidf_matrix = self.vectorizer.fit_transform(X)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 1652, in fit_transform
    X = super().fit_transform(raw_documents)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 1058, in fit_transform
    self.fixed_vocabulary_)
  File "E:\Anaconda\envs\frageantwort\lib\site-packages\sklearn\feature_extraction\text.py", line 989, in _count_vocab
    raise ValueError("empty vocabulary; perhaps the documents only"
ValueError: empty vocabulary; perhaps the documents only contain stop words

@ErfolgreichCharismatisch ,
Can you please paste here the output of df.head() ?

Empty DataFrame
Columns: [title, paragraphs]
Index: []

Thanks, we will take a look at it.

@ErfolgreichCharismatisch
Could you please test pdf_converter on a folder with no subfolders and only pdf files (preferably some of the pdf files you already have in the folder)?

To check functionality, I wrote my own pdf to csv-parser and converted each file to a line.
It showed this behaviour
[22/Jul/2019 15:28:28] WARNING - The pre-trained model you are loading is an uncased model but you have set `do_lower_case` to False. We are setting `do_lower_case=True` for you but you may want to check this behavior.
[22/Jul/2019 15:28:29] INFO - loading vocabulary file https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased-vocab.txt from cache at C:\....pytorch_pretrained_bert\26bc1ad6c0ac742e9b52263248f6d0f00068293b33709fae12320c0e35ccfbbb.542ce4285a40d23a559526243235df47c5f75c197f04f37d1a0c124c32c9a084

And it returned to the windows prompt. Without a result and without an error message.
Can you explain?

This warning is expected and I am currently working to avoid that in a next PR.
However, this should not affect inference or performance of the cdqa_pipeline. No output from cdqa_pipeline.predict() is a really strange behaviour, even with this warnings...
Did you make sure the elements in the paragraphs column in your .csv file are written as lists of paragraphs?

Here is an example paragraph from books.csv
date,title,category,link,abstract,paragraphs
"","title.pdf","none","E:/books\title.pdf","","['Volume II','Table of Contents','Message to the Reader','3',....,'']"

Instead of
df = pd.read_csv('books.csv', converters={'paragraphs': literal_eval},encoding='utf-8')
cdqa_pipeline = QAPipeline(**reader**='models/bert_qa_vGPU-sklearn.joblib', max_df=1.0)
cdqa_pipeline.fit(X=df)
cdqa_pipeline.predict(X='What is?')

I tried
df = pd.read_csv('books.csv', converters={'paragraphs': literal_eval},encoding='utf-8')
cdqa_pipeline = QAPipeline(**model**='models/bert_qa_vGPU-sklearn.joblib', max_df=1.0)
cdqa_pipeline.fit(X=df)
cdqa_pipeline.predict(X='What is?')

and got
[22/Jul/2019 20:20:52] INFO - loading archive file https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased.tar.gz from cache at C:\...\.pytorch_pretrained_bert\distributed_-1\9c41111e2de84547a463fd39217199738d1e3deb72d4fec4399e6e241983c6f0.ae3cef932725ca7a30cdcb93fc6e09150a55e2a130ec7af63975a16c153ae2ba
[22/Jul/2019 20:20:52] INFO - extracting archive file C:\...\.pytorch_pretrained_bert\distributed_-1\9c41111e2de84547a463fd39217199738d1e3deb72d4fec4399e6e241983c6f0.ae3cef932725ca7a30cdcb93fc6e09150a55e2a130ec7af63975a16c153ae2ba to temp dir C:\Users\...\AppData\Local\Temp\tmpasnkpknm
[22/Jul/2019 20:20:57] INFO - Model config {
  "attention_probs_dropout_prob": 0.1,
  "hidden_act": "gelu",
  "hidden_dropout_prob": 0.1,
  "hidden_size": 768,
  "initializer_range": 0.02,
  "intermediate_size": 3072,
  "max_position_embeddings": 512,
  "num_attention_heads": 12,
  "num_hidden_layers": 12,
  "type_vocab_size": 2,
  "vocab_size": 30522
}

[22/Jul/2019 20:21:02] INFO - Weights of BertForQuestionAnswering not initialized from pretrained model: ['qa_outputs.bias', 'qa_outputs.weight']
[22/Jul/2019 20:21:02] INFO - Weights from pretrained model not used in BertForQuestionAnswering: ['cls.predictions.bias', 'cls.predictions.transform.dense.weight', 'cls.predictions.transform.dense.bias', 'cls.predictions.decoder.weight', 'cls.seq_relationship.weight', 'cls.seq_relationship.bias', 'cls.predictions.transform.LayerNorm.weight', 'cls.predictions.transform.LayerNorm.bias']
3it [00:00, 176.56it/s]
[22/Jul/2019 20:21:15] WARNING - The pre-trained model you are loading is an uncased model but you have set `do_lower_case` to False. We are setting `do_lower_case=True` for you but you may want to check this behavior.
[22/Jul/2019 20:21:16] INFO - loading vocabulary file https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased-vocab.txt from cache at C:\...\.pytorch_pretrained_bert\26bc1ad6c0ac742e9b52263248f6d0f00068293b33709fae12320c0e35ccfbbb.542ce4285a40d23a559526243235df47c5f75c197f04f37d1a0c124c32c9a084

I uploaded a new version of the GPU model. Can you please download it in the link below and run your script on books.csv ? (Using reader, not model, in the QAPipeline arguments)
https://github.com/cdqa-suite/cdQA/releases/download/bert_qa_vGPU/bert_qa_vGPU-sklearn.joblib
If it doesn't work can you please download the CPU version and run the script below (load CPU version and send it to GPU with the method .cuda())?
df = pd.read_csv('books.csv', converters={'paragraphs': literal_eval},encoding='utf-8')
cdqa_pipeline = QAPipeline(reader='models/bert_qa_vCPU-sklearn.joblib', max_df=1.0)
cdqa_pipeline.cuda()
cdqa_pipeline.fit(X=df)
cdqa_pipeline.predict(X='What is?')

(frageantwort) PS E:\cdQA> python train.py
3it [00:00, 63.99it/s]
[23/Jul/2019 14:46:26] WARNING - The pre-trained model you are loading is an uncased model but you have set `do_lower_case` to False. We are setting `do_lower_case=True` for you but you may want to check this behavior.
[23/Jul/2019 14:46:28] INFO - loading vocabulary file https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased-vocab.txt from cache at C:\...\.pytorch_pretrained_bert\26bc1ad6c0ac742e9b52263248f6d0f00068293b33709fae12320c0e35ccfbbb.542ce4285a40d23a559526243235df47c5f75c197f04f37d1a0c124c32c9a084
(frageantwort) PS E:\cdQA>

Current code
df = pd.read_pickle('E:/books.pkl')
cdqa_pipeline = QAPipeline(reader='models/bert_qa_vCPU-sklearn.joblib', max_df=1.0)
cdqa_pipeline.cuda()
cdqa_pipeline.fit(X=df)
cdqa_pipeline.predict(X='What is?')

The same with cdqa_pipeline = QAPipeline(reader='models/bert_qa_vGPU-sklearn.joblib', max_df=1.0)

@ErfolgreichCharismatisch
I think I understand why your script is not outputting anything. You need to print out the output of cdqa_pipeline.predict() (as shown in our tutorial)
prediction = cdqa_pipeline.predict(X='What is?')

print('query: {}'.format(query))
print('answer: {}'.format(prediction[0]))
print('title: {}'.format(prediction[1]))
print('paragraph: {}'.format(prediction[2]))

Thanks for supporting me all the way.
It gives me interestingly deep answers; I asked: "Who is Sherlock Holmes?" and it answered with "who are you".
Now the question is about ground truth. What should the answer be? How do I realize that the system does not have an answer - apart from the answer being gibberish at first look.

It gives me interestingly deep and somewhat eerie answers; I asked: "Who is Sherlock Holmes?" and it answered with "who are you".
EDIT: I tried more questions. Your software gives quite insightful answers.

Its answers really depends on you the documents on your database actually. Maybe they are insightful because your documents are insightful

How do I realize that the system does not have an answer - apart from the answer being gibberish at first look.

You can use the logits sent with the answer (feature added with PR #203 ) and fine tune a threshold as proposed on #195

Does it work with documents of different languages?

For now, it works only for English. Depending on the language, you can use the BERT version for that specific language as Reader, but you will need to train it on a QA dataset for that language...


Add new param to allow show the migration at the terminal

This PR is related to issue #3.
This PR depends on PR #7

@mauro-oto Thank you. I just updated my PR.


googleearth: init at <IP_ADDRESS>36

Wanted to play with google earth and found #39426.  I took the URL from the AUR PKGBUILD, so it seems like the moving link problem is gone.
I tested it locally and it worked without problems, maybe somebody can test whether it works for them too.
/cc @matthewbauer @woffs as you were involved in the issue to remove the package

If we re-add this (and I'm not saying we should), the release notes entry in<PHONE_NUMBER>695b1ed2f03ec997f8b9db18cd0b16 needs to be reverted.

@xeji Okay I amended the pr.  Do you think it would be better to not add this again? And why? I don't know much about the history apart from the fact that the moving link seemed to be annoying (which is fixed by the new link)

Thanks. I don't know much about the history either. Let's see what people more familiar with the package say.

Are you not getting this issue from @TealG?
https://github.com/NixOS/nixpkgs/pull/37655#issuecomment-375457628
I was under the impression that something was broken (maybe a missing library).

I don't experience the issue mentioned in that issue.  It starts fine and I spent quite some time in it without problems

Can you remove @viric as maintainer, unless they're again interested in maintaining it. Then we can merge this.

Removed @viric for now from maintainers list


[Bug]: Query fails on first request with error - readAddress(..) failed: Connection reset by peer (FaunaDB, Hasura & Supabase)

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

This issue is reported by Confidence and one of our users on intercom. After first failure, the subsequent requests will work as expected.
Error -  readAddress(..) failed: Connection reset by peer.
Steps To Reproduce
Confidence has confirmed that this is reproducible every time. Reference thread - https://theappsmith.slack.com/archives/CGBPVEJ5C/p1641467800027700
Environment
Production
Version
Cloud

Verified with Habitasaurus https://www.loom.com/share/d51d26ae93cd41698d079f79de1d7013


Added bootstrap

What the program do ?
Creates a form
In what programming language it is written?
HTML

This pull request contains conflicts. Please fix it and reopen


Network message monitoring and collection

Set up network message monitoring and collection for the purpose of post-factum analysis and metric collection.
Current idea is based on the parquet data format, f3 observe command and duckdb for parquet processing.

f3 observe to collect messages
maybe improve f3 observe to include message validation
periodically upload the parquet files to S3
build a script to download parquet files for time range, compact and optimize them to ease analysis

Done in #744

Handled by https://github.com/filecoin-project/go-f3/pull/744
Followup happening in https://github.com/filecoin-project/go-f3/issues/745


[fix] export failure with CUDA driver < 526 and pynvml>=11.5.0

There is a bug that was fixed in the 526 driver release. For older driver versions the recommendation is to downgrade the pynvml version to 11.4.0 and use 11.5.0 only for drivers after 526.

Uses the legacy pynvml memory usage function even with pynvml 11.5.0 if the driver version is older than 526.
Mentioned in the issue as well: NVIDIA/TensorRT-LLM#808 (comment)

Thanks for addressing the pynvml issue, relating to a driver version. @CoderHam can I know which doc(or link) you referred to determine the driver version (526)?

@jaedeok-nvidia took a while to dig through it but I followed the thread from https://forums.developer.nvidia.com/t/nvml-bug-nvmldevicegetcomputerunningprocesses-returns-compute-processes-for-all-gpu-devices/222337/2 and https://github.com/NVIDIA/k8s-device-plugin/issues/331#issuecomment-1498616763
This confirmed that the issue with missing symbols in the underlying nvml libraries prevents us from using the v2 api prior to driver 526.

Hi @CoderHam , the changes are integrated in https://github.com/NVIDIA/TensorRT-LLM/pull/1688 and we've credited you as co-author, hence I'm closing this PR now, thanks a lot


[master-rebranch] Merge in master resolving conflicts and compilation failures.

@swift-ci please smoke test


The data for training Mimi

Due diligence

[x] I have done my due diligence in trying to find the answer myself.

Topic
The paper
Question
It seems that Mimi was trained independently of Moshi, but I couldn’t find the dataset used to train Mimi. Did I miss something?

Hi, thanks for the great work Moshi team! I also have the same question, are the data used to train Mimi similar to the 7 million hours used to pre-train Moshi, or similar to data used to train encodec or soundstream? @LaurentMazare @adefossez
Thanks!

Same question! I only saw that training data included 7 million hours of audio, but there is no specific information related to the Mini training dataset.


Add signed bn2bin and bin2bn functions

This adds the functions BN_signed_bin2bn(), BN_signed_bn2bin(),
BN_signed_lebin2bn(), BN_signed_bn2lebin(), BN_signed_native2bn(),
and BN_signed_bn2native(), all essentially doing the same job as
BN_bin2bn(), BN_bn2binpad(), BN_lebin2bn(), BN_bn2lebinpad(),
BN_native2bn(), and BN_bn2nativepad(), except that the 'signed'
ones operate on signed number bins in 2's complement form.
Some amount of refactoring is included.  For example, BN_bin2bn() and
BN_lebin2bn() had the exact same code apart from a couple of minute
details, so they got collapsed into the internal function bin2bn() and
modified to wrap that internal function.
Furthermore, bin2bn() was modified to do its conversion from the least
to most significant bignum chunk instead of the other way around.
This makes it easier to handle 2's complement calculations on negative
numbers.
Documentation and testing is included.

What is the use case for this?

What is the use case for this?

Primarily as a foundation to allow OSSL_PARAM to be assigned negative BIGNUMs.  See #17070, which caused #17074

Still looking for a use case. Please explain which code you think will need this.

Ok.
OSSL_PARAM_set_BN() and OSSL_PARAM_get_BN() are currently limited to handle positive BIGNUMs, i.e. they can only be passed with the data type OSSL_PARAM_UNSIGNED_INTEGER.  This is a limitation directly due to the lack of bn2bin and bin2bn functions that can handle bins in 2's complement form.
The same goes for OSSL_PARAM_BLD_push_BN().
My intention is to modify those functions or add new functions that can handle both positive and negative BIGNUMs, passing them as OSSL_PARAMs with the data type OSSL_PARAM_INTEGER.  That's for an upcoming PR.
See OSSL_PARAM_get_BN() and OSSL_PARAM_set_BN() here:
https://github.com/openssl/openssl/blob/0a10825a009c830125fef94c81d34e41300a24a5/crypto/params.c#L903-L943
See OSSL_PARAM_BLD_push_BN() here:
https://github.com/openssl/openssl/blob/0a10825a009c830125fef94c81d34e41300a24a5/crypto/param_build.c#L193-L230
(my current thinking is that OSSL_PARAM_BLD_push_BN() can't easily be modified to handle negative BIGNUMs, that a new function OSSL_PARAM_BLD_push_signed_BN() will be necessary)

We could used unsigned integer for non-negative BNs and integer for negative ones without breaking backward compatibility.

We could used unsigned integer for non-negative BNs and integer for negative ones without breaking backward compatibility.

Uhmmmmm?  Passing nonnegative BNs when the data type OSSL_PARAM_INTEGER is specified wouldn't break backward compatibility, would it?

Yes, it doesn't work with negative values. But I still fail to see when we'll need them.

Yes, it doesn't work with negative values. But I still fail to see when we'll need them.

Uhmm, pardon for the obvious answer, but that would be whenever a negative value is in the set of possible values to pass between libcrypto and a provider.  This is exactly the case in issue #17070.

Uhmmmmm? Passing nonnegative BNs when the data type OSSL_PARAM_INTEGER is specified wouldn't break backward compatibility, would it?

Simply using OSSL_PARAM_INTEGER breaks backwards compatibility.  Going forwards we'd accept both.

@kroeckx, is there an underlying question behind your questions?  It seems to me like my answers don't quite satisfy you, so I must assume that there's something unsaid that's completely obvious to me, but not to you.  I would very much like to be able to clear that up.

Uhmmmmm? Passing nonnegative BNs when the data type OSSL_PARAM_INTEGER is specified wouldn't break backward compatibility, would it?

Simply using OSSL_PARAM_INTEGER breaks backwards compatibility. Going forwards we'd accept both.

I think that this discussion should be reserved to that upcoming PR

From #17070: This was only during some testing; we don't actually need negative bignums in parameters. You appear to be adding something that nobody needs. I'm against adding things with 0 users. So my question still remains, show me why you need this.

For the OSSL_PARAM APIs, I would like for discussions to move to #17162.
(the description of that PR might already answer some questions?)

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

Needs rebase

Ping

This pull request is ready to merge

Merged
c2cab43574dbb65094d6caf4dc1bf691e826a4fc [refactor] BIGNUM: collapse BN_bin2bn() and BN_lebin2bn() into one
4e26fe508bf18732983212ca4749eabb1f02e142 [refactor] BIGNUM: Modify bn2binpad()'s setup to be more like bin2bn()'s
99d3349d6f4b62c89d0cbcd6200cbc9bda388c52 BIGNUM: Add a comment on chunk order in struct bignum_st
c30de601850f367e4c16ad91c0168a2e0dc647c0 [refactor] BIGNUM: Modify bin2bn() to work from least to most significant chunk
f5e8050fdcf2083825ef450d51bfacac21d2730e Add signed bn2bin and bin2bn functions
5288303da96084b41b062d99eb37177fb4cf471e TEST: Add a test of the new BN_signed set of functions in test/bntest.c

Merged
c2cab43574dbb65094d6caf4dc1bf691e826a4fc [refactor] BIGNUM: collapse BN_bin2bn() and BN_lebin2bn() into one
4e26fe508bf18732983212ca4749eabb1f02e142 [refactor] BIGNUM: Modify bn2binpad()'s setup to be more like bin2bn()'s
99d3349d6f4b62c89d0cbcd6200cbc9bda388c52 BIGNUM: Add a comment on chunk order in struct bignum_st
c30de601850f367e4c16ad91c0168a2e0dc647c0 [refactor] BIGNUM: Modify bin2bn() to work from least to most significant chunk
f5e8050fdcf2083825ef450d51bfacac21d2730e Add signed bn2bin and bin2bn functions
5288303da96084b41b062d99eb37177fb4cf471e TEST: Add a test of the new BN_signed set of functions in test/bntest.c


Timestamp Domain

Hi, I have updated my Intel Realsense SDK vertion to v2.25.0, but when I opened my camera in Intel Realsense viewer, it comes to this red warning :

Is this warning a critical warning? how can I solve it?

Hi @Dontla
This is not a critical warning (it has no effect on depth quality) However, having more accurate timestamps can be beneficial in some applications. Here is the relevant documentation for Windows - installation_windows.md#use-automation-script

@Dontla, please kindly let us know if further help is needed for this ticket. Thank you.

Thank you! The problem has been solved.


Add checkbox to turn of help in the dashboard

There's already an accessibility page this could go on, just need to add a checkbox to modify the config file I think.

@KorvinSzanto just put this checkbox on the accessibility page in the dashboard. Call it "Enable Help" and it make it used whenever the help overlay blue question mark is shown.


Update Get-MailDetailATPReport.md

@chrisda added one more column

Docs Build status updates of commit 8266426:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-MailDetailATPReport.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Some workspace sometimes randomly stays as "background" when using a gesture / bind to change workspaces

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit e1e41e54480282d9bec9957d3c578eb87bc1f2f2 dirty (reenderer: Add 1 border damage to fix number rounding issues (5343)).
Date: Sun Mar 31 15:59:22 2024
Tag: v0.37.1-93-ge1e41e54

flags: (if any)

System Information:
System name: Linux
Node name: dell-xps
Release: 6.8.2-zen2-1.1-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Fri, 29 Mar 2024 03:08:19 +0000

GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:

Bug or Regression?
Bug
Description
Sometimes a glitched version of a workspace remains visible as "background" after switching
How to reproduce
Partially switch to another workspace using gesture (so that 2 workspaces are shown at the same time), e.g 2->3
go to ws 1 using keybinds
Shit breaks (see images)
This doesn't only happen when using this specific combination of gestures/binds, but that's the most reliable way I've found to replicate the issue
Crash reports, logs, images, videos

This is actually an empty workspace

so is this

here I have a terminal open on top of the glitched background
https://github.com/hyprwm/Hyprland/assets/84153269/78bb0a97-547e-4404-950b-0a1c2d5e4fd5

I have 2 monitor setup got this bug on the second monitor when I switch workspace on monitor 1. #5367 fixes my issue


chore: bump aruqillian-cube and fmp to latest versions

Can we update all the examples please @iocanel ?


OLS-1229: refactor Uvicorn runner into its own module

Description
OLS-1229: refactor Uvicorn runner into its own module
Type of change

[x] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)
[ ] CI configuration change
[ ] Konflux configuration change

Related Tickets & Documents

Related Issue #OLS-1229

/retest

/test e2e-ols-cluster-4-15

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

Project coverage is 96.83%. Comparing base (66e334d) to head (89a09e3).
Report is 25 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1932      +/-   ##
==========================================
+ Coverage   94.64%   96.83%   +2.18%
==========================================
  Files          66       69       +3
  Lines        2897     2878      -19
==========================================
+ Hits         2742     2787      +45
+ Misses        155       91      -64

Files with missing lines
Coverage Δ

ols/runners/__init__.py
100.00% <100.00%> (ø)

ols/runners/uvicorn.py
100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

----
🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests

/approve

/override "Red Hat Konflux / ols-enterprise-contract / lightspeed-service"

/test unit

/override "ci/prow/e2e-ols-cluster-4-16"
/override "ci/prow/e2e-ols-cluster-4-17"

/override "ci/prow/4.16-e2e-ols-cluster"
/override "ci/prow/4.17-e2e-ols-cluster"

/override "ci/prow/4.16-e2e-ols-cluster"
/override "ci/prow/4.17-e2e-ols-cluster"

/override "ci/prow/4.15-e2e-ols-cluster"


[AzureMonitor] remove features before stable release

Removing certain logging features before stable release.
These features will be added back for an immediate beta release.
Changes

change LogExporter to internal
remove LogFiltering from Distro
remove AzureLogForwarding from Distro

API change check
API changes are not detected in this pull request.


irmin-pack: introduce Sparse_file abstraction

This PR tries to abstract the mapping/data files coupling behind a Sparse_file module (that we could use to implement the lower volumes?). It's a pretty aggressive refactoring so I would understand if it is not welcomed! It notably gets rid of the dispatcher's accessors because I find it easier to hide the offset computations inside the Sparse/Chunked files blackboxes.
If there's no strong objection, my plan is to add some append-only functions to this Sparse_file that the GC will be able to use to transfer data to the lower. There's also still some refactoring to do in File_manager as it could delegate the opening/closing/etc of the mapping/data file to the new module.

Codecov Report

Merging #2172 (dd6f3f0) into main (ff45092) will decrease coverage by 0.09%.
The diff coverage is 76.15%.

:exclamation: Current head dd6f3f0 differs from pull request most recent head a5ad27c. Consider uploading reports for the commit a5ad27c to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #2172      +/-   ##
==========================================
- Coverage   68.07%   67.98%   -0.09%
==========================================
  Files         134      134
  Lines       16161    16107      -54
==========================================
- Hits        11001    10950      -51
+ Misses       5160     5157       -3

Impacted Files
Coverage Δ

src/irmin-pack/inode.ml
78.96% <0.00%> (ø)

src/irmin-pack/unix/gc_worker.ml
4.41% <0.00%> (+0.06%)
:arrow_up:

src/irmin-pack/unix/import.ml
87.50% <ø> (+5.14%)
:arrow_up:

src/irmin-pack/unix/store.ml
64.11% <ø> (ø)

src/irmin-pack/version.ml
44.44% <ø> (ø)

src/irmin-pack/unix/async.ml
56.60% <40.00%> (+2.75%)
:arrow_up:

src/irmin-pack/unix/dispatcher.ml
58.73% <52.50%> (-17.30%)
:arrow_down:

src/irmin-pack/unix/chunked_suffix.ml
85.58% <60.00%> (-0.27%)
:arrow_down:

src/irmin-pack/unix/sparse_file.ml
82.92% <82.92%> (ø)

src/irmin-pack/unix/pack_store.ml
82.72% <83.33%> (ø)

... and 15 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks for the review! I've made some changes (to be squashed after approval) and simplified a bit the file manager (... I'm trying to expose less and less of the Mapping_file, although the GC worker still need this internal access until the sparse file provides "append" operations)


Adding task's finishing duration

⚠ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description
Similar to https://github.com/obsidian-tasks-group/obsidian-tasks/issues/1649, I think adding spent time on a task (task's duration) is also a valuable addition to be considered.
✔ Solution
Maybe it should be an emoji with time in seconds or HH:MM:SS format.
❓ Alternatives
Personally, I use t: seconds in tasks title.
📝 Additional Context
No response

🔖 Feature description
Similar to #1649, I think adding spent time on a task (task's duration) is also a valuable addition to be considered.

I find it is useful to get as much information as possible about people's ideas at the point when they log them, as they are often not around later if someone picks up the issue.
So, in no particular order:

How does this differ from the existing #179 ?
Why exactly would this feature be useful to you? What would you use the information for, that you cannot do now?
How do you think the information should be added inside Tasks? Are you expecting the user to manually type in the duration?

The answer to this will have a big impact on how much work the feature would be

How do you think the information should be accessed inside Tasks?

Excellent. Thank you @yshalsager, very helpful answers.

I think a lot of people are looking forward to this simple, yet very useful feature. In fact, this can be extended to Timeboxing, a way of managing time. For Timeboxing in particular, an important feature is setting the size of duration. The time recording function has low requirements. A large project has a duration, and each subtask has a duration. If the task's time is up, it requires that the duration not be extended, but that lower level subtasks be deleted. So keeping track of time, maybe with something like pomodora. In addition, if the root task and the subtask can be associated with each other, and each has its own DURATION, then we can easily assign the duration of the task when the task is broken down. Of course, that's another issue.

Yes. There's no automatic tracking, it's only storing a simple time info. But it is also important feature

This request falls within a set of areas that we have decided not to support in Tasks.

https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2721

Closing as not planned.

Actually no - changed to wontfix.


[Exam] Bugfix: exam visibility and disabled input in start page

Checklist

[ ] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.

Motivation and Context

The logic for the check if there is a visible exam was faulty. See: https://github.com/ls1intum/Artemis/issues/1734
For the start page you could still change your name in the input field after you clicked on 'Start Exam'
Description

Adjusted the hasVisibleExams to check if there are really visible exams
Added the server time sync for date checks in the exam overview
Disabled input field when waiting for the exam to start
Steps for Testing

Try to reproduce the behaviour in https://github.com/ls1intum/Artemis/issues/1734 and confirm that it is working as intended
Go to an exam and see if you can still change your name after clicking on 'Start Exam' button

@HanyaElhashemy Is there at least one visible exam in the course?

@HanyaElhashemy Is there at least one visible exam in the course?

Yes here is the course: https://artemistest.ase.in.tum.de/#/courses/46/exercises
And I can see the exam tab if I am logged in as a tutor/instructor but not as a student with artemis_test_1 for example

@HanyaElhashemy Is there at least one visible exam in the course?

Yes there is! Here is the course: https://artemistest.ase.in.tum.de/#/courses/46/exercises
And I can see the exam tab if I am logged in as a tutor/instructor but not as a student with artemis_test_user_1 for example

Sorry for asking such questions but have you registered the

@HanyaElhashemy Is there at least one visible exam in the course?

Yes there is! Here is the course: https://artemistest.ase.in.tum.de/#/courses/46/exercises
And I can see the exam tab if I am logged in as a tutor/instructor but not as a student with artemis_test_user_1 for example

Should be fixed now. It was the same logic mistake as for the client side. Don't know why it didn't appear locally for me


Display year in attachments ui upload time stamp

The time stamp displayed in a user's Settings => Uploaded files interface includes the month, day and time that the file was uploaded, but not the year.
The function absolute_time() in timerender.js builds the time stamp. It can be easily modified to include the year. This function does not appear to be used anywhere else.
This issue was brought up in #3710.

@zulipbot claim


why  Duration adverse loss don't  update

why  Duration adverse loss don't  update? the discrimatepredicton is compelete

I am just thinking if LSTM discriminator is right or some other transformer based discriminator is the way to go. It shouldnt really matter a lot, but just waiting on some feedback. Plus, if you think this LSTM discriminator is ok, please attach it to models.py and change lines in train.py and send a PR, it will be really helpful!

你好，我是邱家洪，邮件已经收到，谢谢。

@elch10 I think the duration predictor is trained for the first 30k steps and then frozen. The overall waveform generation model is trained continuously for 800k steps.

I found such explanation in paper
Our proposed duration predictor and training mechanism allow for a learning duration in short steps, and the duration predictor is separately trained as the last training step, which reduces the overall computation time for training.

I have added durations predictor to train all the way during the training. Will fix to follow the paper's style soon.

I have added durations predictor to train all the way during the training. Will fix to follow the paper's style soon.

The last 30K steps, will we just train the duration predictor with DD (duration discriminator)? or  train the whole model with DD?

你好，我是邱家洪，邮件已经收到，谢谢。


Use package version for OpenAPI

Description
Uses environment variable set by node for the OpenAPI version number.
Motivation
Keeps both version numbers in sync
Changes:

changed from hard coded string to environment variable

@nitrosx This change does not target the OpenAPI version number but the SciCat Version number, aka. the grey box in your picture. It just automatically keeps it in sync.

Thank you for clarifying.


[Feature Request]: Changing the cursor from pointer to a Brush icon on canvas

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Changing the cursor from pointer to a Brush icon on canvas
Use Case
It will enhance the UI
Benefits
It will enhance the UI
Add ScreenShots
https://github.com/singodiyashubham87/Draw-it-out/assets/159264060/767d0952-ba6b-4bb1-9ae7-a2c3c977776e
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a SSOC'24 contributor
[X] I want to work on this issue

@HishitaGupta There is no particular brush type for cursor in browsers, how will you implement that?


SpanishCommands::qualified() must be of the type string, null given

Found by @s1kx
Aug 11 21:13:58 stack-guru run-bot.sh[1475]: TypeError: Argument 1 passed to StackGuru\Services\SpanishCommands::qualified() must be of the type string, null given, called in /home/stackguru/stack-guru/src/Services/SpanishCommands.php on line 30 and defined in /home/stackguru/stack-guru/src/Services/SpanishCommands.php:23

@s1kx suggested fix by converting to ?string.


PlayerView is pushing progressBar offscreen when setting both height and width to match_parent

Using the com.pierfrancescosoffritti.androidyoutubeplayer.core.player.views.YouTubePlayerView in a FrameLayout with height and width at match_parent is pushing the progressbar offscreen. If the webUi is enabled it will center the player and push both the title and progressbar somewhat offscreen.

This can easily be reproduced by using the example app (viewpager).
My intention is to have a viewPager with a player in each page. When the user rotates the phone they should become fullscreen (without using the fullscreen API call).
How can I achieve this? Should I extend the YoutubePlayerView or is it something else I'm missing?
UPDATE!!
In case I use the fullscreen button to toggle, it behaves correctly, so I'm looking at the difference between setting it in XML or setting it in code.

cool, let us know what you find out!

Hey @ChristianoBolla-Appwise @PierfrancescoSoffritti  i'm facing the same issue ... i've added frameLayout with match parent in which YT Player is wrapped with MatchParent.
My Activity orientation is set to Landscape.
and i've tried both fullscreen config 1,0 but video playe is getting out of screen from bottom.
can you help me with that how to fix this issue.
here is my xml code
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:ndroid="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".Admin.Youtube.main.YoutubePlayerActivity">

    <ImageView
        android:id="@+id/btn_toolbar_back"
        android:layout_width="@dimen/size_45"
        android:layout_height="@dimen/icon_large_40dp"
        android:layout_gravity="start"
        android:layout_margin="@dimen/margin_small"
        android:background="?selectableItemBackground"
        android:elevation="@dimen/margin_large"
        android:padding="@dimen/size_10"
        android:visibility="visible"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:srcCompat="@drawable/ic_svg_new_back"
        app:tint="@color/white" />
    <FrameLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"

        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent">

        <com.pierfrancescosoffritti.androidyoutubeplayer.core.player.views.YouTubePlayerView
            android:id="@+id/youtube_player_view"
            android:layout_width="match_parent"
            android:layout_height="match_parent" />
    </FrameLayout>

</androidx.constraintlayout.widget.ConstraintLayout>

**and here is the method to initialize and manage **
 private void startYoutubePlayer(String videoId) {
        YouTubePlayerView youTubePlayerView = findViewById(R.id.youtube_player_view);
        getLifecycle().addObserver(youTubePlayerView);
        youTubePlayerView.setEnableAutomaticInitialization(false);
        youTubePlayerView.wrapContent();
        IFramePlayerOptions iFramePlayerOptions = new IFramePlayerOptions.Builder()
                .controls(1)
                // enable full screen button
                .fullscreen(1)
                .autoplay(1)
                .build();

        AbstractYouTubePlayerListener ytPlayerListener = new AbstractYouTubePlayerListener() {
            @Override
            public void onReady(@NonNull YouTubePlayer youTubePlayer) {

                youTubePlayer.loadVideo(videoId, 0);
            }
        };

        youTubePlayerView.addYouTubePlayerListener(ytPlayerListener);

        youTubePlayerView.initialize(ytPlayerListener, iFramePlayerOptions);

    }


Having trouble calling runSQL on table that implements Policy Contract based access control after burning

This conditional might be disabling the possibility of using Policy Contract based access control https://github.com/tablelandnetwork/eth-tableland/blob/c44c6bd14c29006e8ac397632a352452f0499846/contracts/TablelandTables.sol#L71
The check reverts with an "Unauthorized" error if the call to _exists() returns false.  As far as I can tell using _burn(tableId) results in the tableId no longer "existing".  Which in turn results in the calls to run sql always failing.
I'm able to burn the table and still access it according to the policy contract rules if I transfer to a burn address like 0x000000000000000000000000000000000000dead.
There also might be an error in my code that I'm not seeing.  To reproduce setup and run the example apps chess game locally.

drilling into what burn does and how _exists is evaluated. ERC721a flips a flag indicating if a token has been burned:
// The bit mask of the `burned` bit in packed ownership.
uint256 private constant BITMASK_BURNED = 1 << 224;

that is used in _exists. i can see why they did it like this: burn is the total death of the token : )
suggestion: stop inheriting from the burnable extension and define a new function:
/**
 * @dev Locks table ownership and access control.
 *
 * tableId - the id of the target table
*/
function lock(uint256 tableId) external;

for the error splitting... I thought about doing that but reverted to the REST mentality of not leaking information about the target object. If you're not authorized, you should not even know if the token exists or not. Plus it adds to the contract size.

The lock method would do what you did manually... send the token to some burn address, eg, 0x000000000000000000000000000000000000lock

I like the suggestion of not inheriting from burnable since it doesn't seem to work for our use cases. The lock function sounds perfect.  Do we need to enable it in the contract somehow?

which test are you thinking of? the link above points to your branch afaict.
i can do a quick PR with that lock method and we can upgrade the proxies!

lock sounds awesome!
If you checkout that branch and run the tests you'll see the "Should be able to gate run SQL with controller contract" test fail  because the table doesn't exist. It's possible that is correct, but I was interpreting it as trying to test if the call is authorized.


v1.12: ci: use Ariane to trigger workflows

Please see the main PR at #26237 for full context and discussions.

/ariane-test-backport-1.12

/ariane-test-backport-1.12

/ariane-test-backport-1.12

/ariane-test-backport-1.11

/ariane-test-backport-1.12

Removing temporary test commit.


A start of a PSR 3 Logger implementation.

A start of a PSR 3 Logger implementation.

Closing to treat the conflict locally


I was using flet to build an apk file by the command "flet build apk -vv ". But it threw the following errors:

flet build apk -vv
Flutter bootstrap directory: C:\Users\notar\AppData\Local\Temp\flet_flutter_build_BMvPfRFlpx
Creating Flutter bootstrap project...OK
Customizing app icons and splash images...Copying E:\Shehzad\Programming\Rose Elon\MYapp\assets\icon.png to C:\Users\notar\AppData\Local\Temp\flet_flutter_build_BMvPfRFlpx\images
OK
Generating app icons...Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in run_code
File "F:\Scripts\flet.exe_main.py", line 7, in
File "F:\Lib\site-packages\flet\cli\cli.py", line 83, in main
args.handler(args)
File "F:\Lib\site-packages\flet\cli\commands\build.py", line 518, in handle
icons_result = self.run(
^^^^^^^^^
File "F:\Lib\site-packages\flet\cli\commands\build.py", line 731, in run
r = subprocess.run(
^^^^^^^^^^^^^^^
File "F:\Lib\subprocess.py", line 548, in run
with Popen(*popenargs, **kwargs) as process:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "F:\Lib\subprocess.py", line 1026, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "F:\Lib\subprocess.py", line 1538, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [WinError 193] %1 is not a valid Win32 application

Did you run as a Administrator?

@JustKen-Aristotle did it work when you ran as administrator?

@JustKen-Aristotle did it work when you ran as administrator?

Well, it needed a thing more I found here:
https://github.com/flet-dev/flet/issues/2318#issuecomment-1881506010

Hi @JustKen-Aristotle ! Try first to update flet with pip install --upgrade flet.
After that be sure that you have all required installed with flutter doctor.
If you still have the same problem with the command flet build apk --verbose just :

open the cli build.py file of flet. In you case you can run the command start F:\Lib\site-packages\flet\cli\commands\build.py
edit the method run of the class Command.  Add the parameter shell to subprocess.run() and set it to True in line 820
save the  code and run flet build apk --verbose again.

the method to edit look lik this
    def run(self, args, cwd, capture_output=True):
        if is_windows():
            # Source: https://stackoverflow.com/a/77374899/1435891
            # Save the current console output code page and switch to 65001 (UTF-8)
            previousCp = windll.kernel32.GetConsoleOutputCP()
            windll.kernel32.SetConsoleOutputCP(65001)

        if self.verbose > 0:
            print(f"\nRun subprocess: {args}")

        r = subprocess.run(
            args,
            cwd=cwd,
            capture_output=capture_output,
            text=True,
            encoding="utf8",
            shell=True
        )

Hello, I am reporting that I just ran into this issue today with Python 3.12 on Windows 11, Flet 0.23.2. Renaming the dart and flutter files fixed the problem.

Renaming which Flutter file?

Sorry, I got confused about which thread I was posting too. I had to follow this comment:
https://github.com/flet-dev/flet/issues/2318#issuecomment-1881506010