I am "go install"ing a static analysis tool in the Kubernetes CI environment. The tool then gets invoked for csi-lib-utils in a PR which updates dependencies to Kubernetes 1.30, which brings in packages with a dependency on Go 1.22.
What did you see happen?
When the static analysis tool has "go 1.20" in it's go.mod file, invoking it fails (from https://prow.k8s.io/log?container=test&id=1788858131263000576&job=pull-kubernetes-csi-csi-lib-utils):
+ go install<EMAIL_ADDRESS>go: downloading github.com/pohly/logtools v0.0.0-20240508074535-63d1e9639914
go: downloading golang.org/x/tools v0.21.0
go: downloading golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842
go: downloading golang.org/x/sync v0.7.0
go: downloading golang.org/x/mod v0.17.0
Verifing logcheck in /home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils: /tmp/tmp.ZyqPi2bZ0Y/logcheck -check-contextual ./...
/home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils/vendor/k8s.io/apimachinery/pkg/api/resource/amount.go:17:1: package requires newer Go version go1.22

/home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils/vendor/k8s.io/apimachinery/pkg/api/resource/amount.go:17:1: package requires newer Go version go1.22

What did you expect to see?
Should have worked because the Go version that was in PATH was recent enough.
Including the actual Go version would have been useful. I've been told on Slack  by @timothy-king that this was already changed.

What did you see happen
When the static analysis tool has "go 1.22" in go.mod, building with 1.22.2 downloads 1.22.3 (from https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-csi_csi-lib-utils/168/pull-kubernetes-csi-csi-lib-utils/1788860954126061568/build-log.txt):
+ go version
go version go1.22.2 linux/amd64
...
+ go install<EMAIL_ADDRESS>go: downloading github.com/pohly/logtools v0.0.0-20240508080454-537c42229236
go<EMAIL_ADDRESS>requires go >= 1.22; switching to go1.22.3
go: downloading go1.22.3 (linux/amd64)
go: downloading golang.org/x/tools v0.21.0
go: downloading golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842
go: downloading golang.org/x/sync v0.7.0
go: downloading golang.org/x/mod v0.17.0

On the plus side, the analysis then worked.
What did you expect to see?
The Go 1.22.2 from PATH should have been good enough. Downloading 1.22.3 causes additional network traffic.
That this solves the problem raises a question: do I need to do a new release of logcheck each time a new Go release comes out where I bump the Go version?
I expected that a user who needs the tool for a code base which depends on, say, Go 1.23 can simply build an existing logcheck release with that newer Go to make it work. Apparently that is not the case?

Using "go 1.22.2" in go.mod led to the same result (from https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-csi_csi-lib-utils/168/pull-kubernetes-csi-csi-lib-utils/1788864329584480256/build-log.txt):
+ go install<EMAIL_ADDRESS>go: downloading github.com/pohly/logtools v0.0.0-20240508115057-a7482e93ef7d
go<EMAIL_ADDRESS>requires go >= 1.22.2; switching to go1.22.3
go: downloading go1.22.3 (linux/amd64)
go: downloading golang.org/x/tools v0.21.0
go: downloading golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842
go: downloading golang.org/x/sync v0.7.0
go: downloading golang.org/x/mod v0.17.0

This makes even less sense because now the tool requires exactly the version of the local toolchain.

I tried with GOTOOLCHAIN=local go install .... That didn't work (from https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-csi_csi-lib-utils/168/pull-kubernetes-csi-csi-lib-utils/1788866768744222720/build-log.txt):
+ go version
go version go1.22.2 linux/amd64
...
+ GOTOOLCHAIN=local
+ GOBIN=/tmp/tmp.FsDmM0x2vE
+ go install<EMAIL_ADDRESS>go: downloading github.com/pohly/logtools v0.0.0-20240508074535-63d1e9639914
go: downloading golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842
go: downloading golang.org/x/tools v0.21.0
go: downloading golang.org/x/sync v0.7.0
go: downloading golang.org/x/mod v0.17.0
Verifing logcheck in /home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils: /tmp/tmp.FsDmM0x2vE/logcheck -check-contextual ./...
/home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils/vendor/k8s.io/apimachinery/pkg/api/resource/amount.go:17:1: package requires newer Go version go1.22

Could you reproduce this on your local machine?  GOTOOLCHAIN=local works for me for all of them as well.

Your CI's local toolchain is 1.21.5
Your version checks are executed within a checkout of your codebase, so the version printed is after a version switch:
<EMAIL_ADDRESS>GOMOD='/home/prow/go/src/github.com/kubernetes-csi/csi-lib-utils/go.mod'

Could you reproduce this on your local machine?

No.

Your CI's local toolchain is 1.21.5

Ah, I see. The cd /tmp/tmp.t47x9PK9Lg in https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-csi_csi-lib-utils/168/pull-kubernetes-csi-csi-lib-utils/1788860954126061568/build-log.txt came after go version and thus that wasn't actually the Go from PATH as I had thought. Well spotted!
So if the Go in PATH had indeed been 1.22.x, that one would have been used for everything and the go.mod "go 1.20" in the static analysis tool would have been fine, right?

So if the Go in PATH had indeed been 1.22.x, that one would have been used for everything and the go.mod "go 1.20" in the static analysis tool would have been fine, right?

If the go command is indeed 1.22.x, it should be used for building everything with a go.mod "go 1.20", "go 1.22", or "go 1.22.2", without downloading.
I'm not familiar with your static analysis tool, so I'm not sure. Now that you've spotted the problem, you could try it after fixing the issue, or simply locally with a Go 1.22 installation, and see if it works. Closing for now. Feel free to reopen if that is still an issue. Thanks.


Documentation

In the documentation, I feel as though it is important to note that the create hull function only returns an array of faces. You are responsible for storing the points somewhere for creating the hull for rendering or other purposes. Or, that could be an improvement for the future. That's for you to decide.

Actually, I was going to ask, can you help me make the documentation? I'm going to start off with a TypeDoc-generated documentation website, but could you help me make it better, @Dannie226?

Yeah. I can do that. Just generate the docs, and I can go through them in my free time and make sure that everything looks correct. Is the repo public, or will you need to add me as a contributor for the repo?

It's public, but I'm going to add you as a contributor as well, since you're going to help with the docs and you're the original math genius behind all this.

Umm... This was just an implementation of the quick hull algorithm originally made by someone else. I took the file, put everything necessary in one file, and created the utils functions so the hull could be created, and I added the convenience method. The actual quickhull math/implementation was done by someone else. I just made it such that you only needed to include one file and added a method for creating a hull very easily.

Oh ok lol

Could you also put the repo under an MIT license? It's part of the original, and I, for one, don't wish to get sued.

Okay

What name should I put it under?

You are the creater of the repo, but if you wish to attribute me, you can

Okay, I added docs and created an action to deploy them
https://github.com/RedstoneWizard08/QuickHull/runs/6329937471?check_suite_focus=true

https://redstonewizard08.github.io/QuickHull

With the auto-generated docs, are we able to add descriptions for everything?

Yes, using JSDoc comments.

Aight. I'll get started on adding those after I refresh myself on the documentation.

I only got the util functions done, but that look right?

Lemme check - sorry I was in a piano lesson xD

That looks right, but since it's typescript, you don't need the type parameters in the JSDoc, so you can change this:
- * @param {number[]} a
+ * @param a


GCP: support specifying Cloud KMS key name for backup storage locations

Adds support for explicitly providing a customer-managed cloud KMS key name to use for encrypting backups in a backup storage location. For more details, see https://cloud.google.com/storage/docs/encryption/using-customer-managed-keys.

alright, testing LGTM here.


fix: docarray3 and type checking

set logger INFO default
add type checking
remove docarray.math dependency

LGTM

No special reason to use 'np.ndarray', I just want to make the code style consistency with Jina core.


[DropdownMenu] [PopoverMenu] Add Overlay component

Feature request
Overview
Implement an Overlay component for DropdownMenu and PopoverMenu (similar to the one found in Dialog) which is displayed behind the popover content.
Examples in other libraries
This would function similarly to the Overlay component found in Dialog and AlertDialog.
Who does this impact? Who is this for?
A stylable overlay would help make the popover content stand out and visually indicate that the user can click outside to dismiss the menu.

Hi @darrylyeo,
It isn't very common to display menus/popover with overlays behind them.
Do you have examples of that in the wild?
If we were to make this happen, they would only be for modal mode, which Popover isn't by default, but DropdownMenu is. The part would be optional regardless I guess.
Thoughts on this @andy-hook?

It’s not particularly common but I have seen it used in the wild, amazon comes to mind:

I also remember this being mentioned as a potential convenience in NavigationMenu.

they would only be for modal mode, which Popover isn't by default

Aside but I sometimes wonder if this default on Popover was the right choice from a consistency perspective.

Agreed, I think this could be added to NavigationMenu and even ContextMenu as well!
Plenty of examples in iOS where context menus dim or blur the background:

I second that. used in plenty of places, would love to see this land <3

is there any progress on this?

is there any progress on this?

Is there a workaround for now?

@jaithirani You can make a custom <Overlay/> component and nest it inside the root component. E.g. for NavigationMenu here's how I'm doing it:
const [isOpen, setIsOpen] = useState<boolean>(false);

return (
  <NavigationMenu
    defaultValue=""
    onValueChange={(val) => (val ? setIsOpen(true) : setIsOpen(false))}
    className={cn(className)}
  >
    {/* other components */}
    {isOpen && <Overlay />}
  </NavigationMenu>
);

Overlay:
export const Overlay = () => {
  return (

  );
};

Another solution for adding a backdrop would be to simply add a shadow that fills the whole background behind the Popover container, like so:
<Popover.Content         style={{           boxShadow: "0 0 0 12000px rgba(0, 0, 0, 0.32)",         }}       >

It’s not particularly common but I have seen it used in the wild, amazon comes to mind:

I need exactly this implementation. For now, I will make the popover a controlled component and create a custom overlay, but it would be nice to have a Popover.Overlay component.

type BackdropOptions = "opaque" | "blur" | "transparent";

interface PopoverContentProps
  extends React.ComponentPropsWithoutRef<typeof PopoverPrimitive.Content> {
  backdrop?: BackdropOptions;
}

const PopoverContent = React.forwardRef<
  React.ElementRef<typeof PopoverPrimitive.Content>,
  PopoverContentProps
>(({ className, align = "center", sideOffset = 4, backdrop, ...props }, ref) => (
  <PopoverPrimitive.Portal>

        <PopoverPrimitive.Content
          ref={ref}
          align={align}
          sideOffset={sideOffset}
          className={cn(
            "z-50 w-72 rounded-md border bg-popover p-4 text-popover-foreground shadow-md outline-none data-[state=open]:animate-in data-[state=closed]:animate-out data-[state=closed]:fade-out-0 data-[state=open]:fade-in-0 data-[state=closed]:zoom-out-95 data-[state=open]:zoom-in-95 data-[side=bottom]:slide-in-from-top-2 data-[side=left]:slide-in-from-right-2 data-[side=right]:slide-in-from-left-2 data-[side=top]:slide-in-from-bottom-2",
            className
          )}
          {...props}
        />

  </PopoverPrimitive.Portal>
))

this works
add backdrop prop to the PopoverContent
        <PopoverContent className="w-[250px] p-0 " backdrop="blur">


restart service service[apparmor] causes ERROR: SSL Validation failure connecting to host: api.opscode.com  on first run

Whenever I bring up a node, the first run of the ntp cookbook failed when it tries to do the restart service service[apparmor] with this error:
    - restart service service[ntp]
[2015-05-13T19:51:35+00:00] INFO: cookbook_file[/etc/apparmor.d/usr.sbin.ntpd] sending restart action to service[apparmor] (delayed)
Recipe: ntp::apparmor
  * service[apparmor] action restart[2015-05-13T19:51:35+00:00] INFO: Processing service[apparmor] action restart (ntp::apparmor line 20)
[2015-05-13T19:51:36+00:00] INFO: service[apparmor] restarted

    - restart service service[apparmor]
[2015-05-13T19:51:36+00:00] ERROR: SSL Validation failure connecting to host: api.opscode.com - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

As far as I can tell, I don't see the SSL Validation failure any other time, so I'm pretty sure there isn't a fundamental issue with certs.
Any idea why it does this or how I can make it stop failing?
Thanks!
I am using:

Hosted Enterprise Chef (whatever they call the SaaS Chef server nowadays)
Chef version 12.3.0 on the clients
ntp cookbook 1.8.2
chef-provisioning / chef-provisioning-fog (not sure if that matters)

@rberger can you let me know how you are setting up apparmor so i can recreate that on my end?  the apparmor supermarket cookbook?

I'm not doing anything that I know of to set up apparmor.  ntp.::apparmor  is the only thing in my system doing anything with apparmor from what I can tell.

I captured the debug output of the failure. Its at https://gist.github.com/rberger/53587485c35df26ad45d

Same problem here, indeed it happens only on the first run

ntp 1.8.6
Ubuntu 12.04
chef-client 11.18.6

Can someone give this a try with the latest version of this cookbook.  We've made changes to the apparmor setup that may resolve these problems.

I'm no longer seeing this issue on the test systems.  I'm going to close this out, but feel free to open it back up if it's still happening.


[MM-60416] Check for the presence of the EXE uninstaller before trying to run it

Summary
Once of the features of the new MSI installer is to basically replace the EXE one, despite the fact that they use different installation methods and thus different ids, making them able to be installed side by side. What we did was to force the uninstallation of the EXE installer if we install via MSI. However, this was throwing an error (which seemed to be ignored most of the time) when the uninstaller was missing for those using a deployment system.
This PR adds a check for the uninstaller before we try to run it, which avoids the error altogether.
Ticket Link
https://mattermost.atlassian.net/browse/MM-60416
Fixed a potential error thrown by the MSI when trying to uninstall the EXE

what command did you ran to generate this patch?

npx patch-package app-builder-lib


Question: How to see command logs in docker logs?

I have jobber configured and running in a docker container.  My jobs  log 100's of JSON lines to stderr/stdout.  If I configure the job to redirect output to a file, everything works nicely except I must attach a shell to inspect logs.
sitemap:
    cmd: /usr/local/bin/generateSitemap.sh >> /var/log/generateSitemap.log
    time: '*/30 0 3'
    onError: Continue

I would like the output of my scripts to be written to container's stdout/stderr (similar to how Jobber's run log is done) so that logs may be inspected using docker logs -f <container_name> or forwarded to ELK stack using Docker syslog log driver.
Result Sinks
Using the resultSinks: with type: stdout is not an option as the output is buffered then wrapped with Jobber status.  If 100's of log entries occur during script execution, the resulting output is too long to send to remote syslog listener (aka logstash).  I would like EACH log entry to be written individually and forwarded to a syslog listener for processing.
Sample Log Entry as received by ELK (SHORTEST OF ALL COMMANDS)
stderr contains four syslog entries prefixed with 2020-10-02T02:29:03+00:00 INFO (6):
{
  "fate": 0,
  "job": {
    "command": "/usr/local/bin/generateSitemap.sh",
    "name": "eventsAll",
    "status": "Good",
    "time": "*/30 0 3"
  },
  "startTime":<PHONE_NUMBER>,
  "stderr": "2020-10-02T02:29:03+00:00 INFO (6): {\"function\":\"generateSitemap\",\"processor\":\"generateSitemap\",\"script\":\"/var/lib/blahblah/generateSitemap.php\",\"eventIds\":\"\",\"excludeEventIds\":\"19,44,74,75,222,1001,1011,1021,2000\",\"msg\":\"START\"}\n2020-10-02T02:29:03+00:00 INFO (6): {\"class\":\"Event_Dispatcher\",\"function\":\"processQueue\",\"processor\":\"processEvents-all\",\"script\":\"/var/lib/blahblah/generateSitemap.php\",\"eventIds\":\"\",\"excludeEventIds\":\"19,44,74,75,222,1001,1011,1021,2000\",\"eliminateDups\":0,\"batchSize\":1000,\"processAll\":0}\n2020-10-02T02:29:03+00:00 INFO (6): {\"class\":\"Event_Dispatcher\",\"function\":\"processQueue\",\"processor\":\"processEvents-all\",\"script\":\"/var/lib/blahblah/generateSitemap.php\",\"eventIds\":\"\",\"excludeEventIds\":\"19,44,74,75,222,1001,1011,1021,2000\",\"eliminateDups\":0,\"batchSize\":1000,\"processAll\":0,\"countEvents\":0,\"countProcessed\":0,\"countSkipped\":0,\"countError\":0,\"msg\":\"PROCESSED ALL EVENTS\"}\n2020-10-02T02:29:03+00:00 INFO (6): {\"function\":\"generateSitemap\",\"processor\":\"processEvents-all\",\"script\":\"/var/lib/blahblah/generateSitemap.php\",\"eventIds\":\"\",\"excludeEventIds\":\"19,44,74,75,222,1001,1011,1021,2000\",\"tt\":7,\"msg\":\"END\"}\n",
  "succeeded": true,
  "user": "jobberuser",
  "version": "1.4"
}

Other options tried:
sitemap:
    cmd: /usr/local/bin/generateSitemap.sh 2>&1
    time: '*/30 0 3'
    onError: Continue

Symlink log file to /dev/stderr
$ ls -l /var/log
lrwxrwxrwx 1 jobberuser jobberuser  11 Oct  2 04:14  generateSitemap.log -> /dev/stderr

Any assistance in how to accomplish the above would be greatly appreciated.

Would it be possible to pass Jobber's logPath file handle to the Command's stdout and stderr instead of creating temporary files which buffer command's output for return in resultSinks?
https://github.com/dshearer/jobber/blob/658675e6fb73986cfae790142f76b8c7202e78c6/common/exec.go#L107
	// make temp files for stdout/stderr
	stdout, err := ioutil.TempFile(TempDirPath(), "")
	if err != nil {
		return nil, err
	}
	stderr, err := ioutil.TempFile(TempDirPath(), "")
	if err != nil {
		cleanUpTempfile(stdout)
		return nil, err
	}

	// give them to cmd
	cmd.Stdout = stdout
	cmd.Stderr = stderr

Then in job file, define Command's log entry such that stdout and/or stderr are directed to same file as prefs.logPath.
prefs:
  logPath: /var/log/jobber/jobber.log
  runLog:
    type: file
    path: /var/log/jobber/jobber-runs.log
    maxFileLen: 100m
    maxHistories: 2

jobs:
  sitemap:
    cmd: /usr/local/bin/generateSitemap.sh
    time: '*/30 0 3'
    onError: Continue
    log:
     - stdout
     - stderr

The above approach still allows use of resultSinks with stdout and/or stderr.  However, to preserve backwards compatibility and avoid breaking existing sinks, resultSink.data should override 'log' entries.

I would need this feature as well

I would need this feature as well


Workaround Safari 9 WebGL bug

Not for 1.13 today.
Discussion: https://twitter.com/pjcozzi/status/638390320619761664
If we need to workaround this, replace all uses of WebGLRenderingContext with the actual constant, e.g.,
WebGLRenderingContext.LESS

becomes
0x0201 // WebGLRenderingContext.LESS

@lilleyse let's discuss.

Should be fixed in https://bugs.webkit.org/show_bug.cgi?id=148449 but doesn't work yet in WebKit r189243 (02 September 2015).

Still broken in r189485 (September 8th).  If iOS 9 does get released tomorrow, I'm assuming Cesium will be broken.

iOS 9 will be released on September 16

@lilleyse can you do this soon?  Unfortunately, we're going to need this workaround.  I think the best approach is to introduce a new static class like ContextLimits with _all _ the constants from the spec (perhaps called ContextConstants or WebGLConstants).

@pjcozzi should we make an announcement on the mailing list ahead of time?  No need to be too negative on Safari, but just mention that it will break existing Cesium apps and people shouldn't upgrade iOS or Safari if they need Cesium until we release a workaround (or Apple releases a fix).

Yes I can start working on this today.

There are many areas that already hard code constants, like https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Renderer/BufferUsage.js#L11-L14
Should I modify all of these to use the new constants class as well?

Should I modify all of these to use the new constants class as well?

Yes, those are very old...before I even knew of WebGLRenderingContext.

@pjcozzi should we make an announcement on the mailing list ahead of time?

Yes, go ahead.


Form value binding not updating fast enough

Say I have a simple component with nothing but a mounted method that does the following:
this.myValue = 'a value'

$(this.$el).parent('form').submit()

My component html looks like this:
<form action="http://…">
    <input type="text" :value="myValue">
</form>

As you can see I'm using jQuery to submit the form and if both assigning the value and submitting the form happen in the same function, empty data is submitted. I can work around this by using a timeout with no delay, but of course that's not ideal.
setTimeout(() => {
    $(this.$el).parent('form').submit()
})

This also happens when it's not in the mounted method, but for instance on blur out, so it has nothing to do with page load or delays. Same goes for :value versus v-model.
I don't know much of the internals of Vue or JS, but I presume it's because it hasn't been able to assign the values yet. Using a timeout, the submit occurs on the next tick.

I thought there is no way to resolve the problem.
In this situation, I manually write param's value for ajax.

Has this issue been posted before then? Couldn't find anything.
Well, in my case, I just want to submit the form automatically including the page refresh, don't want to (and can't) send it via Ajax. If there's no solution, perhaps a mention in the docs would be nice to have?

Use vm.$nextTick
this.myValue = 'a value'

this.$nextTick(function () {
  $(this.$el).parent('form').submit()
})```


Investigate use of SQLite rather than postgres for testing/development.

Pros to using SQLite:

no need for Azure infrastructure
CROP test db requires docker - this wouldn't be needed with SQLite

Cons to using SQLite

some postgres-specific features: UUID, enum) on CROP
possibly need different syntax for connection strings, binding engine to session.. ?

Not going to do this for now - we will use the same Docker setup as with CROP.


First two characters in flag are accepted regardless of what follows

    [Verb ("payments-match", HelpText = "Match unsolicited payments to Wbs")]     public class MatchPaymentsCommand : Command {          [Option ('f', "file", Required = true, HelpText = "The path of the Wbs file")]         public string File { get; set; }          [Option ('s', "submit", Required = false, Default = false, HelpText = "Set to true to create transfers")]         public bool Submit { get; set; } = false;          [Option ('p', "password", Required = false, HelpText = "The password of the WBS file")]         public string Password { get; set; } ...  }
If I enter -submit, it will recognised -s but not the following characters, I would expect it to error/throw in this scenario.

submit should be prefixe by double dash "--"
This is working:
     myapp payments-match --submit  -f wbs_file
     myapp payments-match  -s  -f wbs_file


Copper Ingot Quest is Named "Iron"

The quest for the Copper Ingot has the Title "Iron".
Requirements and Rewards are correct though.
Edit: Same for Nickel.

Known questbook error, will be fixed in 4.6. Thanks!


[zh-cn] sync kubectl_run/_index.md

content/zh-cn/docs/reference/kubectl/generated/kubectl_run/_index.md

Oops, CI is broken due to the prow migration. We need to wait until the migration is fully completed.

/approve


rtl PROBLEM

I HAVE AN ISSUE WITH RTL ARABIC
IT SHOW IN REVERSE CAN YOU FIX THIS PROBLEM?

Thanks, @haydary1986 for bringing this issue to us. I don't know rtl, but I will try to add rtl support ASAP. This repo is open source anyone can contribute.


Fix #112

Fixes #112.
Note: we need to add substantially more tests for fraud proofs in rsmt2d as these cases aren't being tested.

Seems this fails with -tags leopard.

I fixed the failing test, which was failing because when we only return the original shares in the sanity check where we have the full row/col, so I changed it back to returning the whole row/col.
It should be noted that the Shares in ErrByzantineData should be guaranteed to only be shares that we can generate Merkle proofs for; but they may be more shares than necessary to prove fraud. Therefore currently it should be up to the application to strip out extraneous shares.

so I changed it back to returning the whole row/col.

This makes ErrByzantineData ambiguous as now there are two different behaviors for the same error over the same API. Is there any other to fix the issue with the test?

It's not different behaviors, it's actually the same behaviour, and the fix actually makes the behaviour more consistent. The behaviour is that ErrByzantineData always returns all shares in a row or column that Merkle proofs can be generated for (i.e. they are in a fully completed orthogonal row or column).

Ok, I misunderstood your original message. LGTM then

@adlerjohn please review

While technically not necessary since the EDS only includes shares that are provable by the caller, it's not a bad change. Left one code style nit.

Actually, the EDS may include recovered shares that are not in the Merkle tree and thus are not provable by the caller, so this change is necessary. Do you agree? See https://github.com/celestiaorg/celestia-node/issues/1086

The EDS shouldn't (if it does, then that's unintended), since recovered shares are only added to the EDS if they match the Merkle roots.

since recovered shares are only added to the EDS if they match the Merkle roots

But the EDS itself adds recovered shares to itself (via the crossword), which might not match the Merkle root.

Inserting is only done after Merkle roots are matched.
https://github.com/celestiaorg/rsmt2d/blob/76b270f80f0b9ac966c6f6b043e31514574f90f3/extendeddatacrossword.go#L139-L145
https://github.com/celestiaorg/rsmt2d/blob/76b270f80f0b9ac966c6f6b043e31514574f90f3/extendeddatacrossword.go#L160

Hence "the returned EDS does not return those recovered shares" in my original message


Can't get the plugin to work

I can't seem to get this plugin to work. This is my minimal config (not sure if nvim-lspconfig is necessary but I included it just in case):
call plug#begin('~/.config/nvim/packages/')
Plug 'neovim/nvim-lspconfig'
Plug 'kabouzeid/nvim-lspinstall'
Plug 'nvim-treesitter/nvim-treesitter', { 'do': ':TSUpdate' }
call plug#end()

lua << EOF
require('lspinstall').setup()
local servers = require('lspinstall').installed_servers()
for _, server in pairs(servers) do
  require'lspconfig'[server].setup({})
end

require('nvim-treesitter.configs').setup {
  ensure_installed = 'maintained',
  highlight = {
    enable = true,
  },
  context_commentstring = {
    enable = true
  }
}
EOF

Here's a file that I've tested the plugin on:
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Test</title>
    <style>
      h1 {
        color: red;
      }
    </style>
  </head>
  <body>
    <script>
      console.log("hello");
    </script>
  </body>
</html>

On every line in the file, :echo &commentstring outputs <!--%s-->.
:TSInstallInfo says that html, javascript and css are installed.

Hey @Melkster!
It looks like you're not including nvim-ts-context-commentstring with Plug. Another thing that might make it seem like the commentstring updating is not working, is the high default updatetime setting.
Could you try a minimal config like this and see if it fixes the problem for you?
call plug#begin('~/.config/nvim/packages/')
Plug 'nvim-treesitter/nvim-treesitter', { 'do': ':TSUpdate' }
Plug 'JoosepAlviste/nvim-ts-context-commentstring'
call plug#end()

set updatetime=100  " Or some other small value (Vim default is 4000)

lua << EOF
require('nvim-treesitter.configs').setup {
  ensure_installed = 'maintained',
  highlight = {
    enable = true,
  },
  context_commentstring = {
    enable = true
  }
}
EOF

@JoosepAlviste Thank you that solved it. I think it was a combination of me forgetting to include nvim-ts-context-commentstring in my minimal config file and some other plugin causing the autocmd CursorHold to dissapear in my full config for some reason.


Encapsulate batch operations on multiple tables/entities

The previous discussion is available here: https://github.com/scylladb/gocqlx/pull/160

@mmatczuk I deleted my fork accidently. I make this new MR with the changes you suggested.
Any comments would be appreciated.

@mmatczuk any update?

Hi @mmatczuk , it's been a long time since I made this MR.
Would you please tell me whether you are still inested in this MR or not?
If yes, I'd like to resharp my code change.


iPadOS crashed and reboot

Describe the issue
Installed Ubuntu 20.04 ARM with Desktop (I named the VM 20.10 but I did install 20.04). After a random crash caused by switching UTM to the background and switching back, I can't boot the VM anymore - It causes my iPad to reboot every time.
Configuration (required)

UTM Version: 2.4.1
OS Version: iPadOS 15.1
Device Model: 256g M1 iPad Pro 12.9
Is it jailbroken (name jailbreak used)? NO
How did you install UTM?
Connecting to service: <NSNetService 0x28100e460> local. _altserver._tcp. Pingchuan’s Mac mini 65517
Stopped discovering servers.
Stream error Error Domain=NSPOSIXErrorDomain Code=61 "Connection refused" UserInfo={_kCFStreamErrorCodeKey=61, _kCFStreamErrorDomainKey=1}
QMP stream error seen: Error Domain=NSPOSIXErrorDomain Code=61 "Connection refused" UserInfo={_kCFStreamErrorCodeKey=61, _kCFStreamErrorDomainKey=1}
2021-11-25 23:09:21.586 UTM[302:10026] Stream error Error Domain=NSPOSIXErrorDomain Code=61 "Connection refused" UserInfo={_kCFStreamErrorCodeKey=61, _kCFStreamErrorDomainKey=1}
QMP connection failed, retries left: 29
2021-11-25 23:09:21.586 UTM[302:10026] QMP stream error seen: Error Domain=NSPOSIXErrorDomain Code=61 "Connection refused" UserInfo={_kCFStreamErrorCodeKey=61, _kCFStreamErrorDomainKey=1}
2021-11-25 23:09:21.586 UTM[302:10026] QMP connection failed, retries left: 29
Connected to stream 0x28228c990
QMP connection successful! (readStream:1)
2021-11-25 23:09:22.590 UTM[302:10024] Connected to stream 0x28228c990
2021-11-25 23:09:22.590 UTM[302:10024] QMP connection successful! (readStream:1)
Connected to stream 0x28228ce10
QMP connection successful! (readStream:0)
2021-11-25 23:09:22.590 UTM[302:10024] Connected to stream 0x28228ce10
2021-11-25 23:09:22.590 UTM[302:10024] QMP connection successful! (readStream:0)
Debug JSON recieved <- {
    QMP =     {
        capabilities =         (
            oob
        );
        version =         {
            package = "";
            qemu =             {
                major = 6;
                micro = 0;
                minor = 1;
            };
        };
    };
}
2021-11-25 23:09:22.590 UTM[302:10024] Debug JSON recieved <- {
    QMP =     {
        capabilities =         (
            oob
        );
        version =         {
            package = "";
            qemu =             {
                major = 6;
                micro = 0;
                minor = 1;
            };
        };
    };
}
Got QMP handshake: {
    QMP =     {
        capabilities =         (
            oob
        );
        version =         {
            package = "";
            qemu =             {
                major = 6;
                micro = 0;
                minor = 1;
            };
        };
    };
}
Debug JSON send -> {
    execute = "qmp_capabilities";
}
2021-11-25 23:09:22.591 UTM[302:10018] Got QMP handshake: {
    QMP =     {
        capabilities =         (
            oob
        );
        version =         {
            package = "";
            qemu =             {
                major = 6;
                micro = 0;
                minor = 1;
            };
        };
    };
}
2021-11-25 23:09:22.591 UTM[302:10018] Debug JSON send -> {
    execute = "qmp_capabilities";
}
Debug JSON recieved <- {
    return =     {
    };
}
2021-11-25 23:09:22.592 UTM[302:10025] Debug JSON recieved <- {
    return =     {
    };
}
qemuQmpDidConnect
2021-11-25 23:09:22.592 UTM[302:10018] qemuQmpDidConnect
cs_channel_new:164
2021-11-25 23:09:22.608 UTM[302:10018] cs_channel_new:164
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 612559;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.613 UTM[302:10018] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 612559;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: main-1:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
Debug JSON send -> {
    execute = cont;
}
qemu-system: info: main channel: opened
2021-11-25 23:09:22.633 UTM[302:10029] Debug JSON send -> {
    execute = cont;
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 1;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = 5;
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = 5;
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 632906;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.633 UTM[302:10025] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 1;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = 5;
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = 5;
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 632906;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    event = RESUME;
    timestamp =     {
        microseconds = 633559;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    return =     {
    };
}
qemuHasResumed
2021-11-25 23:09:22.633 UTM[302:10024] Debug JSON recieved <- {
    event = RESUME;
    timestamp =     {
        microseconds = 633559;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.633 UTM[302:10024] Debug JSON recieved <- {
    return =     {
    };
}
2021-11-25 23:09:22.633 UTM[302:10025] qemuHasResumed
resizing to (1366.000000, 1024.000000)
2021-11-25 23:09:22.634 UTM[302:5689] resizing to (1366.000000, 1024.000000)
cs_channel_new:173
2021-11-25 23:09:22.635 UTM[302:10029] cs_channel_new:173
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 636906;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 636906;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 636998;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 636998;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637058;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637119;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637058;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: display-2:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637119;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: usbredir-9:2: could not set sockopt TCP_NODELAY: Operation not supported on socket
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637200;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: usbredir-9:1: could not set sockopt TCP_NODELAY: Operation not supported on socket
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637200;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: usbredir-9:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637289;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: playback-5:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
2021-11-25 23:09:22.637 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637289;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637407;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: record-6:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
qemu-system: warning: GSpice: inputs-3:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
2021-11-25 23:09:22.638 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 637407;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 1;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 716457;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.716 UTM[302:10027] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 1;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 716457;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 717165;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.717 UTM[302:10027] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 717165;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: Spice: playback:0 (0x107119930): setsockopt failed, Operation not supported on socket
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 5;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 717843;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.718 UTM[302:10026] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 5;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 717843;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: Spice: record:0 (0x1071199e0): setsockopt failed, Operation not supported on socket
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 6;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 718521;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.718 UTM[302:10027] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 6;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 718521;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 3;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 719189;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.719 UTM[302:10026] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 3;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 719189;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 2;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 719836;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.719 UTM[302:10027] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 2;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 719836;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 2;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 720484;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.720 UTM[302:10026] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 2;
            "channel-type" = 9;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 720484;
        seconds =<PHONE_NUMBER>;
    };
}
-[CSDisplayMetal initWithSession:channelID:monitorID:]:483
cs_channel_new:310
2021-11-25 23:09:22.721 UTM[302:10029] -[CSDisplayMetal initWithSession:channelID:monitorID:]:483
2021-11-25 23:09:22.721 UTM[302:10029] cs_channel_new:310
Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 721849;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: GSpice: cursor-4:0: could not set sockopt TCP_NODELAY: Operation not supported on socket
2021-11-25 23:09:22.721 UTM[302:10026] Debug JSON recieved <- {
    data =     {
        client =         {
            family = unix;
            host = "";
            port = "";
        };
        server =         {
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_CONNECTED";
    timestamp =     {
        microseconds = 721849;
        seconds =<PHONE_NUMBER>;
    };
}
Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 4;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 731701;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:09:22.731 UTM[302:10024] Debug JSON recieved <- {
    data =     {
        client =         {
            "channel-id" = 0;
            "channel-type" = 4;
            "connection-id" = 16807;
            family = unix;
            host = "";
            port = "";
            tls = 0;
        };
        server =         {
            auth = none;
            family = unix;
            host = "";
            port = "";
        };
    };
    event = "SPICE_INITIALIZED";
    timestamp =     {
        microseconds = 731701;
        seconds =<PHONE_NUMBER>;
    };
}
gl_version 30 - es profile enabled
WARNING: running without ARB/KHR robustness in place may crash
Debug JSON recieved <- {
    data =     {
        path = "/machine/peripheral-anon/device[11]/virtio-backend";
    };
    event = "NIC_RX_FILTER_CHANGED";
    timestamp =     {
        microseconds = 790264;
        seconds =<PHONE_NUMBER>;
    };
}
2021-11-25 23:10:22.790 UTM[302:10026] Debug JSON recieved <- {
    data =     {
        path = "/machine/peripheral-anon/device[11]/virtio-backend";
    };
    event = "NIC_RX_FILTER_CHANGED";
    timestamp =     {
        microseconds = 790264;
        seconds =<PHONE_NUMBER>;
    };
}
qemu-system: warning: spice: no gl-draw-done within one second
GLSL feature level 130

VM config plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ConfigurationVersion</key>
	<integer>2</integer>
	<key>Debug</key>
	<dict>
		<key>DebugLog</key>
		<true/>
	</dict>
	<key>Display</key>
	<dict>
		<key>ConsoleFont</key>
		<string>Menlo</string>
		<key>ConsoleFontSize</key>
		<integer>12</integer>
		<key>ConsoleOnly</key>
		<false/>
		<key>ConsoleTheme</key>
		<string>Default</string>
		<key>DisplayCard</key>
		<string>virtio-ramfb-gl</string>
		<key>DisplayDownscaler</key>
		<string>linear</string>
		<key>DisplayFitScreen</key>
		<false/>
		<key>DisplayRetina</key>
		<false/>
		<key>DisplayUpscaler</key>
		<string>linear</string>
	</dict>
	<key>Drives</key>
	<array>
		<dict>
			<key>DriveName</key>
			<string>drive0</string>
			<key>ImagePath</key>
			<string>disk-0.qcow2</string>
			<key>ImageType</key>
			<string>disk</string>
			<key>InterfaceType</key>
			<string>virtio</string>
		</dict>
		<dict>
			<key>DriveName</key>
			<string>drive1</string>
			<key>ImageType</key>
			<string>cd</string>
			<key>InterfaceType</key>
			<string>usb</string>
			<key>Removable</key>
			<true/>
		</dict>
		<dict>
			<key>DriveName</key>
			<string>DD1E6D47-27F0-40D2-840C-2474DC593913</string>
			<key>ImagePath</key>
			<string>efi_vars.fd</string>
			<key>ImageType</key>
			<string>none</string>
			<key>InterfaceType</key>
			<string></string>
		</dict>
	</array>
	<key>Info</key>
	<dict>
		<key>Icon</key>
		<string>ubuntu</string>
		<key>IconCustom</key>
		<false/>
	</dict>
	<key>Input</key>
	<dict>
		<key>InputInvertScroll</key>
		<true/>
		<key>InputLegacy</key>
		<false/>
	</dict>
	<key>Networking</key>
	<dict>
		<key>NetworkCard</key>
		<string>virtio-net-pci</string>
		<key>NetworkCardMAC</key>
		<string>4E:51:78:04:6D:AE</string>
		<key>NetworkMode</key>
		<string>emulated</string>
	</dict>
	<key>Printing</key>
	<dict/>
	<key>Sharing</key>
	<dict>
		<key>ClipboardSharing</key>
		<true/>
		<key>Usb3Support</key>
		<false/>
		<key>UsbRedirectMax</key>
		<integer>3</integer>
	</dict>
	<key>Sound</key>
	<dict>
		<key>SoundCard</key>
		<string>intel-hda</string>
		<key>SoundEnabled</key>
		<true/>
	</dict>
	<key>System</key>
	<dict>
		<key>Architecture</key>
		<string>aarch64</string>
		<key>BootDevice</key>
		<string></string>
		<key>BootUefi</key>
		<true/>
		<key>CPU</key>
		<string>cortex-a72</string>
		<key>JITCacheSize</key>
		<integer>0</integer>
		<key>MachineProperties</key>
		<string>highmem=off</string>
		<key>Memory</key>
		<integer>1024</integer>
		<key>SystemUUID</key>
		<string>0DEF0A70-1F0D-48D0-838B-4D3FF8241C56</string>
		<key>Target</key>
		<string>virt</string>
	</dict>
</dict>
</plist>

Thank you for the detailed issue report.
This looks like a possible duplicate of #2743 or related problem. From the Debug Log I can see we have a GL-related crash. The VM session starts and the GL backend kicks in, logs these two lines and then it crashes:
qemu-system: warning: spice: no gl-draw-done within one second
GLSL feature level 130
To work around the crash, please change the VM config => Display => Emulated Display Card to "virtio-ramfb" (note no -gl at the end), then start your VM again. Should no longer crash, but may slow down graphics a bit.

Workaround is effective, preventing further crashes. Unfortunately, the loss of performance is significant in certain DE using a compositor with 3D acceleration (e.g. compiz). Is there a better solution in the works?

Duplicate of #2743


[doc] Inconsistency regarding fork default

The book says

By default, proptest tests are run in-process

but also

proptest has optional “fork” and “timeout” features (both enabled by default)

This reads inconsistent to me. Shouldn't it say disabled by default?

It's two different concepts of "enabled". The cargo features fork and timeout are "enabled" by default, meaning you don't need to do anything in Cargo.toml if you want to use them and they are available to be set in ProptestConfiguration. But ProptestConfiguration defaults to running in-process without timeouts.


NHS number verification by the sender?

This has probably already has an answer, but is the sender required to verify/cross check the NHS number and demographics against PDS?
Is this automatically performed by the MESH client?

Where the MESH Endpoint Lookup Service is used (as described at https://nhsconnect.github.io/gpconnect-messaging/integration_mesh.html#message-routing-to-registered-practice), the MESH server performs a PDS trace to verify the supplied demographic details and resolve the ODS code of the registered practice.
For the "Send federated consultation summary" use case, the use of the MESH endpoint lookup service is mandated.
Additionally, for the "Send federated consultation summary" use case, the message sender performs the following steps to ascertain whether a message should be sent to the registered practice:

If the patient registration type of the patient record at the appointment hosting practice is Regular (GMS/PMS) then no further action is required. (I.e. the registered practice care record is already up-to-date)
Perform a PDS lookup of the patient to determine the ODS code of the registered practice of the patient.
The system at the appointment hosting practice determines whether the registered practice is in the same federation as the hosting organisation ODS code using the local federation definition. This is consistent with the federation discoverability architectural foundations for the GP Connect Appointment Management capability as set out at https://nhsconnect.github.io/gpconnect/appointments_design.html#responsibilities-in-a-federated-booking-context
If this check passes, a “send encounter summary” message is sent.


Fixes issue with space in repo path. Fixes #2804

Fixes issue #2804, where space in repo path crashes install, due to how _runCommands is implemented. This changes the implementation of _runCommands to take command separately and allow spawnSync to automatically escape it.
This leads the initial yarn install to work as expected with space in path name.
Note This also removes the possibility to run several commands through _runCommands and it's now _runCommand. As far as I could see, there were no usage of it with several commands.

thank you!

You are very much welcome. FYI: This as also a part of a Norwegian live stream. Publishing a Pull Request to an Open Source Project. Thanks for merging.

cool!


Routing: Support for camelCase action names in controllers

If you have say the following controller structure
<?php
namespace app\controllers;
use yii\web\Controller;
class TestController extends Controller
{
    public function actionMyaction(){
       ...  //action logic
    }
    public function actionMyAction(){
       ...  //action logic
    }
}

The first route can be accessed using the path app-root/test/myaction
The second route in Yii 1.x would be accessible from the path app-root/test/myAction
in Yii2.x routing is by hyphenated structure and the action is accessible only from ````app-root/test/my-action``
This breaks all link backward compatibility, links of course all spread over the web, in mails sent previously etc while an app can be rewritten those links cannot be changed.
Can there be a provision to provide the compatibility in the core? or else at least this should be included in the migration guide for people considering migrating to 2.

Mentioning it in the main docs would be a good start!

Should be added to https://github.com/yiisoft/yii2/blob/master/docs/guide/runtime-routing.md

Adding this to docs is definitely a must. I just had to consult people on why their camelCase action does not work and luckily I had remembered something about that and the "-" from reading dev posts and following the Yii 2 development in general. If you just read the Guide  - y'r screwed, have to google it and pray :)

And mentioned in upgrade guide https://github.com/yiisoft/yii2/blob/master/docs/guide/intro-upgrade-from-v1.md

Now I'm using the latest versions...
its was really "brain-f@ck" with this routing names and camel cases...
even the routing ( action name ) must be lower case...
disappointed... why ? if developer wants to use CamelCase or other one...

it is coved in the docs here: http://www.yiiframework.com/doc-2.0/guide-start-hello.html#creating-an-action
and also in http://www.yiiframework.com/doc-2.0/guide-structure-controllers.html#controller-ids and http://www.yiiframework.com/doc-2.0/guide-structure-controllers.html#action-ids


Re-run benchmarks for custom pallets

Closes #496.
Still WIP as running benchmarks for vault-registry pallet results in panic.

What's the error in the panic?

What's the error in the panic?

Error: Input("Error executing and verifying runtime benchmark: Runtime panicked: called Result::unwrap()on anErrvalue: Module(ModuleError { index: 21, error: [1, 0, 0, 0], message: Some(\"ExceedingVaultLimit\") })") Evicting failed runtime instance error=Runtime panicked: calledResult::unwrap()on anErr value: Module(ModuleError { index: 21, error: [1, 0, 0, 0], message: Some("ExceedingVaultLimit") })

I cancelled the CI since there's another one running. I'll rerun it afterwards.


things i put in pan wont show

i put somthing to pan but it wont show

it's happening to me too

It's happened to me too. Zifiv made a post about it in the issues tab, somewhere below this post. The skillet animation is invisible when used as block entity, he says. The bug is ready to-do which I think means ready to be fixed. I don't know, I don't normally use GitHub, so I don't know these things. Hopefully it's fixed in the next few days though.

Hello @happy0catte,
Thank you for reporting the issue, it seems that is the same error than #177. I close this issue and you can add some information of your bug in the original issue I've mentionned just before.


Add a few more features to Random

Namely:

[ ] get_random_element - return a random element from a stl container, exists in AllegroFlare::Useful but should be moved to Random
[ ] get_random_color_exhaustive - would return a random color without repeating a color until all colors have been returned
[ ] shuffle - shuffle an array of elements (could be a template)
[ ] Also, there are a few more random functions in Useful that should be audited to be moved to Random.

All the remaining Useful randoms were added through these changes.  They should be removed from Useful now.


Remove obsolete private_in_public lint in nightly.

RFC 2145 is on nightly now, deprecating the public_in_private lint. https://rust-lang.github.io/rfcs/2145-type-privacy.html
public_in_private has been superceded by three new lints. The first two are warn-by-default and the third is allow-by-default. See the excerpt below for some details.
This change skips this lint in nightly in favor of the new warn-by-default lints.
This change revealed a bug in the 'nightly_features' config option for color-spantrace -- it doesn't exist! The lint it was guarding was never turned on. This adds a minimal build script to check for nightly to color-spantrace. Its functionality is tested in the eyre crate, which seems sufficient to me.
The proof this works is that it builds without the warning in nightly : )
After this change there are only two more build warnings for eyre and color-spantrace, the future-incompat dependency warning and the more serious filename collision.

    Lint private_interfaces is reported when a type with visibility x is
    used in primary interface of an item with effective visibility y and
    x < y. This lint is warn-by-default.
Lint private_bounds is reported when a type or trait with visibility
x is used in secondary interface of an item with effective
visibility y and x < y. This lint is warn-by-default.

Lint unnameable_types is reported when effective visibility of a
type is larger than module in which it can be named, either
directly, or through reexports, or through trivial type aliases
(type X = Y;, no generics on both sides). This lint is
allow-by-default.

Compatibility lint private_in_public is never reported and removed.

Missed rust-fmt! I have blocked myself from making the mistake again : )
vscode settings.json
    "[rust]": {
        "editor.defaultFormatter": "rust-lang.rust-analyzer",
        "editor.formatOnSave": true,
    },


The new host wrapper

After profiling about DLS loading, I found EAS's HW was so slow about file operations. It was designed for twenty years ago.
So I reimplemented it, using CRT and some OS-specific APIs. The old one is preserved as optional.
It works on Linux and Windows now, blazing fast (compared than before).

The CRT file operations are only used when file->readAt is NULL.

Benchmark (not authoritative, for information only):
OmegaGMGS2.dls, ~266 MiB, with 484 insts, 15947 regions, 15944 arts and 2255 waves
Old HW:
./sonivoxrender -d ~/OmegaGMGS2.dls  23.50s user 22.76s system 99% cpu 46.503 total

New HW:
./sonivoxrender -d ~/OmegaGMGS2.dls  0.41s user 0.20s system 99% cpu 0.612 total

Benchmark (not authoritative, for information only):
OmegaGMGS2.dls, ~266 MiB, with 484 insts, 15947 regions, 15944 arts and 2255 waves Old HW:
./sonivoxrender -d ~/OmegaGMGS2.dls  23.50s user 22.76s system 99% cpu 46.503 total

New HW:
./sonivoxrender -d ~/OmegaGMGS2.dls  0.41s user 0.20s system 99% cpu 0.612 total

Where can I find OmegaGMGS2.dls? I can only find the sf2 version of it.

Where can I find OmegaGMGS2.dls? I can only find the sf2 version of it.

It is converted from the sf2 version, using Extreme Sample Converter.
BTW, the eas_mdls limits are increased to make it load.

Where can I find OmegaGMGS2.dls? I can only find the sf2 version of it.

It is converted from the sf2 version, using Extreme Sample Converter.

I've tested Airfont 340.dls, ~80 MiB from this page and the benefit is evident.
Please take a look to my modifications. I want to do more checks before a new release.

Please take a look to my modifications. I want to do more checks before a new release.

EAS's duplicated handle has its own position indicator, but as I know, dup()-ed file descriptors share the same I/O object (so file position is same).
Use dup() to implement DupHandle will not work on Linux (as I tested it), but according to CI it works on FreeBSD.

according to CI it works on FreeBSD and MacOS. Confused about how it works

CI is only proving that the code is compiling, and the unit tests are passing. But unit tests are only testing MIDI file processing without DLS files. Other manual tests with the sonivoxrender program show that FreeBSD reads correctly all DLS files, but macOS doesn't. What is needed:

Unit tests that include DLS. The main problem is having a free and reasonable sized DLS to be included in the repository for testing.
I am not happy with the special Linux implementation. There should be a single DupHandle implementation for all POSIX platforms.

The alternative right now is to enable at configuration time the new host wrapper for some platforms and the old wrapper for others. This doesn't feel right for a release.

I found that even passing ReadAt to the new HW, it is still much faster than the old one:
./sonivoxrender -d ~/OmegaGMGS2.dls  3.19s user 1.80s system 99% cpu 5.022 total

The alternative right now is to enable at configuration time the new host wrapper for some platforms and the old wrapper for others. This doesn't feel right for a release.

For these platforms, fallback to internal ReadAt in the new HW is okay. I will implement it in the next PR.


Support multiple packages in one .spdx

First: a nice and very helpful project. Thanks for that.
The Subject: I have a .spdx (tagged, not json) with multiple packages. The first one is quite large (>200k lines) and doesn't have PURLs. Following packages does contain PURLs.
When I run osv-scanner -S big.spdx I get "No package sources found, --help for usage information."
Then I removed the first package from the .spdx and rerun the command osv-scanner -S small.spdx. Now I get findings.
I suspect, that osv-scanner either does not scan multiple packages successively or stops on the first one that doesn't contain PURLs.

@0x4bit  which tool did you use to create this?

I didn't create the SPDX. I've searched for real world examples and found that Kubernetes releases their SBOM with each release. The one I used is for version 1.26.0 (Link: https://sbom.k8s.io/v1.26.0/source).
The modification I did during testing was removing the '##### Package: kubernetes' part - so everything lines 11-260500

Thanks for filing an issue!
It seems like this might be because our parsing supports SPDX 2.2, but this document is in 2.3 format. IT should be an easy fix on our side, but I wonder if the SPDX 2.3 parser is backwards compatible. i.e. can it parse all SPDX 2.2 documents, or will we have to support it separately?

Looking at https://github.com/spdx/spdx-spec/issues/83#issuecomment-388078634
and https://spdx.github.io/spdx-spec/v2.3/diffs-from-previous-editions/ it looks like it should be backwards compatible.
That said, I did also notice that there are additional package manager types that we don't support (e.g. "npm"). we'll track that in a new bug.


Release16.11  script language problem

hello
we have a problem when generating PDF in Arabic language
the Arabic language shows like ########
i tryed many solutions i could not solve the problem
can you solve it for me plz

Hi,
Please use rather the user ML for such questions, see why here http://ofbiz.apache.org/mailing-lists.html
You will get a better support and it's more fair to share with everybody
The wider the audience the better the answers you might get
Thanks
Jacques


Added light and dark mode toggle along with some changes in CSS.

https://github.com/Suman599/light-and-dark-mode

Kindly design Change mode button

And kindly share the demo website link in this comment section

Kindly design Change mode button

I have done that - https://suman599.github.io/light-and-dark-mode/

Sorry to say your changes affect the Footer part also. So kindly keep footer as it is and work on only dark and light mode features. Design of Change mode button can be better ..

Sorry to say your changes affect the Footer part also. So kindly keep footer as it is and work on only dark and light mode features. Design of Change mode button can be better ..

I have not done anything with the footer part. and i can't see any major differences with the original webpage. I have just changed some text color because they are not visible in the dark mode.


Add overloads for Base functions needed for tracing through matrix exponential from ExponentialUtilities

I am not a 100% confident if this is the right thing to do

Could you add a test-case for the matrix exponential?
I suggest we merge it as a @test_broken under the "Real-world examples"
https://github.com/adrhill/SparseConnectivityTracer.jl/blob/2fcd7308ef628c6bc3852deee75ff83b426020f9/test/runtests.jl#L70-L77
and make it work once #56 is merged.

I tried running this in #65 and ran into issues with in-place updated scalars.
julia> x = rand(2, 2)
2×2 Matrix{Float64}:
 0.548476  0.996494
 0.311785  0.340692

julia> f!(y, x) = exponential!(x)
f! (generic function with 1 method)

julia> J = local_jacobian_pattern(f!, y, x)
ERROR: TypeError: in typeassert, expected Float64, got a value of type SparseConnectivityTracer.Dual{Float64, GradientTracer{BitSet}}
Stacktrace:
  [1] opnorm1(A::Matrix{SparseConnectivityTracer.Dual{Float64, GradientTracer{BitSet}}})
    @ LinearAlgebra /Applications/Julia-1.10.app/Contents/Resources/julia/share/julia/stdlib/v1.10/LinearAlgebra/src/generic.jl:665
  [2] opnorm(A::Matrix{SparseConnectivityTracer.Dual{Float64, GradientTracer{BitSet}}}, p::Int64)
    @ LinearAlgebra /Applications/Julia-1.10.app/Contents/Resources/julia/share/julia/stdlib/v1.10/LinearAlgebra/src/generic.jl:741
  [3] exponential!(A::Matrix{…}, method::ExpMethodHigham2005, _cache::Tuple{…})
    @ ExponentialUtilities ~/.julia/packages/ExponentialUtilities/xLH9y/src/exp_noalloc.jl:85
  [4] exponential!(A::Matrix{SparseConnectivityTracer.Dual{Float64, GradientTracer{BitSet}}}, method::ExpMethodHigham2005)
    @ ExponentialUtilities ~/.julia/packages/ExponentialUtilities/xLH9y/src/exp_noalloc.jl:83
  [5] exponential!(A::Matrix{SparseConnectivityTracer.Dual{Float64, GradientTracer{BitSet}}})
    @ ExponentialUtilities ~/.julia/packages/ExponentialUtilities/xLH9y/src/exp.jl:15
  [6] f!(y::Matrix{SparseConnectivityTracer.Dual{…}}, x::Matrix{SparseConnectivityTracer.Dual{…}})
    @ Main ./REPL[190]:1
  [7] trace_function(::Type{SparseConnectivityTracer.Dual{…}}, f!::typeof(f!), y::Matrix{Float64}, x::Matrix{Float64})
    @ SparseConnectivityTracer ~/Developer/SparseConnectivityTracer.jl/src/pattern.jl:33
  [8] local_jacobian_pattern(f!::Function, y::Matrix{Float64}, x::Matrix{Float64}, ::Type{BitSet})
    @ SparseConnectivityTracer ~/Developer/SparseConnectivityTracer.jl/src/pattern.jl:180
  [9] local_jacobian_pattern(f!::Function, y::Matrix{Float64}, x::Matrix{Float64})
    @ SparseConnectivityTracer ~/Developer/SparseConnectivityTracer.jl/src/pattern.jl:179
 [10] top-level scope
    @ REPL[191]:1
Some type information was truncated. Use `show(err)` to see complete types.

The problem is opnorm1 from LineaAlgebra.jl not being generic enough:
function opnorm1(A::AbstractMatrix{T}) where T
    require_one_based_indexing(A)
    m, n = size(A)
    Tnorm = typeof(float(real(zero(T))))
    Tsum = promote_type(Float64, Tnorm)
    nrm::Tsum = 0
    @inbounds begin
        for j = 1:n
            nrmj::Tsum = 0           # <--- Float64
            for i = 1:m
                nrmj += norm(A[i,j]) # <--- Dual{Float64, GradientTracer{BitSet}}
            end
            nrm = max(nrm,nrmj)
        end
    end
    return convert(Tnorm, nrm)
end

You need the overloads I had defined for real and float to make this work right

Right, they are included in #65. Otherwise the error is already thrown at Tnorm = typeof(float(real(zero(T)))) in line 4.

Basically, the type annotation in LinearAlgebra is the issue:
julia> t = Dual(2.0, GradientTracer(BitSet([1, 2, 3])))
Dual{Float64, GradientTracer{BitSet}}(2.0, GradientTracer{BitSet}(1, 2, 3))

julia> res = 1.0
1.0

julia> res += t
Dual{Float64, GradientTracer{BitSet}}(3.0, GradientTracer{BitSet}(1, 2, 3))

julia> res2::Float64 = 1.0
1.0

julia> res2 += t
ERROR: cannot assign an incompatible value to the global Main.res2.
Stacktrace:
 [1] top-level scope
   @ REPL[218]:1

I'm closing this for now, since I don't see a way to work around it. Code needs to be written in a generic manner compatible with any Number type for it to work with SCT.

I think the solution is overloads at the vector scale, not the number scale

I guess we could start touching both, even though it feels a bit "dirty".
Ideally, we would just use vector overloads when we are out of options, since scalar overloads can be much less conservative (see e.g. https://github.com/adrhill/SparseConnectivityTracer.jl/issues/56#issuecomment-2113138997).

Do ForwardDiff and Measurements add overloads at array scale?

I searched for Array and Vector in https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/dual.jl, turned up nothing, so I guess not


Exercise 2 and 3 are missing links to table of contents.

Table of contents links missing from following exercises:
https://microsoft.github.io/TechExcel-Migrate-Linux-workloads/docs/02_migrate_web_app/02_migrate_web_app.html
https://microsoft.github.io/TechExcel-Migrate-Linux-workloads/docs/03_enable_azure_arc/03_enable_azure_arc.html

@judyer28 fixed for 03: Enable Azure Arc. Please check if all is good on your side.

@tiagocostapt I can confirm Arc section looks fixed.

Exercise 02 is fixed.


Schema editor marks all as invalid symbols

Hello.
I wanted to create a graphql schema in a scratch file. So I'm opening a GraphQL Schema scratch and input a simple Node interface:
interface Node {
    id: ID!
}

But the editor marks all except id and ID as invalid.
Here's the screenshot:

Why is that?
Thank you.

Hi Grigory.
Thanks for using the plugin.
The schema language isn't supported yet for editing scenarios. The schema scratch file option appears to be an unintended side-effect of introducing support for traditional GraphQL scratch files.
Here more background regarding the schema language support from an earlier issue:

As it stands, the .graphqls support is considered read-only and requires that a valid parse tree can be created for syntax highlighting. It was added as a means of showing the currently loaded schema that the plugin uses for completion, error highlighting, and for providing find usages etc.
I logged graphql/codemirror-graphql#14 a short while ago since schema editing would be a useful addition. Until that issue is implemented, you should edit your schema file with another file extension to prevent the errors-as-you-type from popping up the console.

For now, I'll see if the schema scratch file option can be removed until it's fully supported. This should avoid confusing users.
Best regards,
Jim.

Released in v1.3.2.


Difference between Operation and Activity

I cannot find any clear explanation about the right concept to use with Application Insights.
The future .NET Core 3.0 seems to push Activity as a first class citizen (for example in ASP.NET Core). But the doc about queue message processing shows an example with StartOperation() and remarks about Activity class.
So could you explain what it the best practice for a new application?

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

ID: 3286f891-667a-997f-e3c5-53813352a068
Version Independent ID: 6ef51bff-9cb4-ee07-9069-cf1bc9888881
Content: Track custom operations with Azure Application Insights .NET SDK
Content Source: articles/azure-monitor/app/custom-operations-tracking.md
Service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@Yves57, Thanks for the question! We are taking a look into this and will get back to you soon.

@Yves57, am assigning this issue to author for further review.

@lmolkova, can you please take a look?

Activities were first-class citizens from .netcore2.0 time in  ApplicaitonInsights. However, you could not use them alone.  Activities provide the tracing context and a few more things, but ApplicaitonInsights needs to know that there were started/stopped to track telemtery about them.
The libraries and .NET parts use DiagnosticSource to notify ApplicaitonInsights about Activities. This is fairly complex approach that is useful and needed when library has to be fully decoupled from the AppInsights.
So if you just create an Activity - AppInsights doesn't have any ways to know you did it.
StartOperation is a syntax sugar that works on top of Activity and knows how to populate telemetry based on this Activity. You don't need to create Activities yourself and you can always rely on StartOperation to create a new one for you, i.e. you can access Activity.Current within StartOperation scope.

So the article is correct, but I guess it this article needs section 'StartOperation vs Activity'

@lmolkova Thank you for the answer. I agree that a new section is needed.


Add the horizontal scrollbar on top of the result details section.

BUG=https://crosswalk-project.org/jira/browse/CTS-497

LGTM


Drop the "revision" field from the CompilationUnit message. [phab:D1386]

Created by schroederc at 2017-02-27 20:21:57:
This reverts commit 7510fa8de643.

craigbarber accepted this revision at 2017-02-27 21:20:44

schroederc closed via commit fcfbb4367b04d7212fc94e0ebcdd4bd6a0dc0c56 at 2017-02-27 21:29:33


Update go directive to include the patch number

Without the patch number, I hit a "toolchain not available" error from an env where go 1.22 was installed, and this project requires 1.23, and apparently it cannot locate the toolchain.
Similar discussion in: https://github.com/golang/go/issues/62278

To explain this further, starting with Go 1.21, go command line tool will download the toolchain specified in go.mod, if current tool chain is older than the version in go.mod.
So if go.mod says go 1.23 and you try to run it with go 1.22, it will try to download go1.23 and fail as go1.23 doesn't exist.


[TASK] Rlease 1.4.2

What's the task? Please describe.
Action items for releasing v1.4.2
Describe the items of the task (DoD, definition of done) you'd like.

Pre-Release

[x] Regression test plan (manual) - @khushboo-rancher
[x] Run e2e regression for pre-GA milestones (install, upgrade) - @yangchiu
[x] Run security testing of container images for pre-GA milestones - @yangchiu
[x] Verify longhorn chart PR to ensure all artifacts are ready for GA (install, upgrade)  @yangchiu

https://github.com/longhorn/longhorn/tree/v1.4.1-rc2 (longhorn/longhorn)
https://github.com/longhorn/charts/tree/v1.4.x (longhorn/charts)

[ ] Run core testing (install, upgrade) for GA build from the previous patch and the last patch of the previous feature release (1.4.1 & 1.3.3). - @yangchiu

Release

[ ] Release longhorn/chart from the release branch to publish to ArtifactHub
[ ] Release note

[ ] Deprecation note
[ ] Upgrade notes including highlighted notes, deprecation, compatible changes, and others impacting the current users

Post-Release

[ ] ~Create a new release branch of manager/ui/tests/engine/longhorn instance-manager/share-manager/backing-image-manager when creating the RC1~
[ ] Update https://github.com/longhorn/longhorn/blob/master/deploy/upgrade_responder_server/chart-values.yaml @PhanLe1010
[ ] Add another request for the rancher charts for the next patch release (1.4.3) @rebeccazzzz

Rancher charts: verify the chart is able to install & upgrade - @khushboo-rancher

[ ] rancher/image-mirrors update @weizhe0422 (@PhanLe1010 )

https://github.com/rancher/image-mirror/pull/377

[ ] rancher/charts dev-2.6 & 2.7 branches for rancher marketplace @weizhe0422 (@PhanLe1010)

dev-2.6: https://github.com/rancher/charts/pull/2558
dev-2.7: https://github.com/rancher/charts/pull/2555

cc @longhorn/qa @longhorn/dev

Run e2e regression for pre-GA milestones (install, upgrade):
v1.4.2-rc1:
amd64: 2 failures
arm64: 2 failures
amd64 upgrade: 4 failures
arm64 upgrade: 2 failures

Verify longhorn chart PR to ensure all artifacts are ready for GA verified :
For both longhorn/longhorn v1.4.2-rc1 and longhorn/chart v1.4.2-rc1:

Fresh install - Pass
Upgrade from v1.3.3 to v1.4.2-rc1 - Pass
Upgrade from v1.4.1 to v1.4.2-rc1 - Pass
After install/upgrade to v1.4.2-rc1, below test items passed

Create a statefulset and write data
Upgrade to v1.4.2-rc1
Upgrade engine image
Scale down/up workload
Trigger replica rebuilding
Create system backup
Create volume backup and restored
Verify volume data

Uninstall

Run security testing of container images for pre-GA milestones:
v1.4.2-rc1: 70 HIGH, 0 CRITICAL

@weizhe0422 Please help update the test result of the node-not-ready e2e test suite.

Run core testing (install, upgrade) for GA build from the previous patch and the last patch of the previous feature release (1.4.1 & 1.3.3)
amd64: 0 failure
arm64: 0 failure
amd64 upgrade from v1.4.1: 1 failure
amd64 upgrade from v1.3.3: 0 failure
arm64 upgrade from v1.4.1: 0 failure
arm64 upgrade from v1.3.3: 0 failure
Rerun the only failed test case of amd64 upgrade from v1.4.1 for 10 times, they all passed: https://ci.longhorn.io/job/public/job/v1.4.x/job/v1.4.x-longhorn-upgrade-tests-sles-amd64/168/

Post-Release

[ ]  Add another request for the rancher charts for the next patch release (1.4.3) @rebeccazzzz

Rancher charts: verify the chart is able to install & upgrade - @khushboo-rancher

[ ]  rancher/image-mirrors update @weizhe0422 (@PhanLe1010 )

docs(longhorn): Add longhorn 1.3.3 images rancher/image-mirror#377

[ ]  rancher/charts dev-2.6 & 2.7 branches for rancher marketplace @weizhe0422 (@PhanLe1010)

dev-2.6: Add Longhorn 1.3.3 chart with dev-2.6 rancher/charts#2558
dev-2.7: Add Longhorn 1.3.3 chart with dev-2.7 rancher/charts#2555

cc @longhorn/qa @longhorn/dev

@PhanLe1010 @weizhe0422 @rebeccazzzz Please start working on the post-release items.
cc @khushboo-rancher

UPDATE: All PRs which related to Rancher chart generation had been merged already.