[SU-107] Redesign service alerts

Currently, service alerts (production incidents, schedule maintenance notifications, etc) are presented using the notifications system. Once the notification is dismissed, a user has no way to view that information in Terra again. And since (anecdotally) users are accustomed to quickly clicking to close notifications, they are possibly missing important information.
This adds an indicator to the top bar that shows if there are any active service alerts. Details about the active alerts are always available by clicking the indicator.
In the future, other notifications may also be moved into this UI.
Before

After

Testing
To manually test, mock the service alerts response.
window.ajaxOverridesStore.set([
  {
    filter: { url: /alerts\.json$/ },
    fn: window.ajaxOverrideUtils.makeSuccess([
      {
        title: 'The systems are down!',
        message: 'Something is terribly wrong'
      }
    ])
  }
])

You may also want to change the polling frequency in service-alerts-polling.js to avoid having to wait a full minute.
Notes
This adds a global state variable for the service alerts. Because Router renders the page component with a key of the URL's path, the TopBar (along with its children) is unmounted and recreated on each page navigation. This prevents using usePollingEffect in AlertsIndicator or otherwise tying fetching service alerts to the component's lifecycle.
https://github.com/DataBiosphere/terra-ui/blob/4c71dba6556eeccb520dc2038202529f4fa0fae2/src/libs/nav.js#L104

I'm not sure if a ticket exists for this, but this may also partially fix a usability bug with alerts. When more than one is present, I have to wait over a second after dismissing while the animation lumbers away before I can dismiss the next alert.

This should somewhat reduce the probability of multiple notifications being visible by moving some notifications into this popup. I'll file a ticket for dismissing multiple notifications. It looks like the main issue is that the dismiss button on subsequent notifications becomes a moving target during the animation. We could change the animation so that the dismissed notification slides out and then the other notifications quickly move into place.


[Bug Transfer from vscode-dotnettools] Contextual UI for test results doesn't render correctly

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.87.0-insider (user setup)
OS Version: Windows_NT x64 10.0.22631

Original issue:
https://github.com/microsoft/vscode-dotnettools/issues/956
Describe the Issue
See below rendering of right click on the red X icon near LOC 226

Steps To Reproduce

Spin up a codespaces for this repo https://github.com/Azure/bicep
Run the test: TryAddProperty_adds_object_properties

Expected Behavior
You can see the test results in the UI
Environment Information
OS: Host: Windows, Codespace: Linux

For the original repro steps, is the C# Dev Kit extension the only extensions needed to detect the tests? I can't seem to get the test explorer to detect the tests in the Bicep repo

The way to verify this is to have multiple test with a multi-line name on the same line (yes it's weird) on a platform where custom context menus are used (not macOS). In the VS Code repo for example:
test('has\nClass2', () => {}); test('has\nClass3', () => {});


XPage with backing bean requires manual build

Project description:

single XPage (Test.xsp) used in "XAgent" style
simple HelloWorld bean
nsf-odp plugin runs on Domino 9 server (Linux)
deployed to Domino 9 server (Windows) and signed

Tested by calling /Test.xsp?Open
Expected results (log.nsf):
[1E18:009F-1710] 22.10.2019 16:17:16   HTTP JVM: Calling bean
[1E18:009F-1710] 22.10.2019 16:17:16   HTTP JVM: CTOR: HelloWorld
[1E18:009F-1710] 22.10.2019 16:17:16   HTTP JVM: hello()

Actual results:
[1E18:009F-1710] 22.10.2019 16:16:22   HTTP JVM: Calling bean
[1E18:009F-1710] 22.10.2019 16:16:22   HTTP JVM: com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing JavaScript action expression

If the deployed .nsf is manually built after this with Domino Designer, the error disappears and everything works as expected.
Code:
project.zip

Hmm, do you have the full exception? I'm guessing it could be related to having Java source in WEB-INF/src (which I'd like to support, but don't generally use and thus haven't significantly tested), but it'd be helpful to have the full stack, which may show up if you set rendered="true".

I set rendered="true" on the XPage. Nothing appears in the trace and error XML logs.
What would be the supported location for Java sources?
Current output on log.nsf:
[1F84:000A-1E94] 22.10.2019 17:02:05   HTTP JVM: Calling bean, rendered=true
[1F84:000A-1E94] 22.10.2019 17:02:05   HTTP JVM: com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing JavaScript action expression

And the XPage code
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" rendered="true">
	<xp:this.beforeRenderResponse><![CDATA[#{javascript:

	var externalContext = facesContext.getExternalContext();

	var request = externalContext.getRequest();
	var response = externalContext.getResponse();
	print("Calling bean, rendered=true");
	HelloBean.hello(request, response);

	facesContext.responseComplete();

}]]></xp:this.beforeRenderResponse>
</xp:view>

Hmm, maybe if you leave off the facesContext.responseComplete(). Mostly, it'd be good to trigger the default XPages error page so it'll show a full stack trace rather than just "there was some problem".
The normal place for Java is in the Code/Java dir, from the Java design elements. You could try moving the class over there for troubleshooting, though it would be good to get Java in alternate directories working. Off the top of my head, my guess is that, while those classes would be made available during XPage compilation, I may not write the bytecode data back in properly.

It works correctly when the code resides in Code/Java. This gotcha could perhaps be added to the README.
Thanks for your help!


VM deployment fails with an error "XML error: Invalid PCI address 0000:01:01.0. slot must be <= 0" if MACHINE=q35

Description
https://forum.opennebula.io/t/cannot-deploy-virtual-machine-using-q35-chipset-with-pci-passthrough/8832
VM deployment fails with an error "XML error: Invalid PCI address 0000:01:01.0. slot must be <= 0" if MACHINE=q35.
vm.log:
Fri Feb  2 17:22:23 2024 [Z0][VM][I]: New state is ACTIVE
Fri Feb  2 17:22:23 2024 [Z0][VM][I]: New LCM state is PROLOG
Fri Feb  2 17:22:24 2024 [Z0][VM][I]: New LCM state is BOOT
Fri Feb  2 17:22:24 2024 [Z0][VMM][I]: Generating deployment file: /var/lib/one/vms/296699/deployment.0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute transfer manager driver operation: tm_context.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute network driver operation: pre.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute virtualization driver operation: /bin/mkdir -p.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute virtualization driver operation: /bin/cat - >/var/lib/one//datastores/0/296699/vm.xml.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute virtualization driver operation: /bin/cat - >/var/lib/one//datastores/0/296699/ds.xml.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Command execution fail (exit code: 255): cat << 'EOT' | /var/tmp/one/vmm/kvm/deploy '/var/lib/one//datastores/0/296699/deployment.0' 'localhost' 296699 localhost
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: error: Failed to create domain from /var/lib/one//datastores/0/296699/deployment.0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: error: XML error: Invalid PCI address 0000:01:01.0. slot must be <= 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Could not create domain from /var/lib/one//datastores/0/296699/deployment.0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 255
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: ExitCode: 0
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Successfully execute network driver operation: clean.
Fri Feb  2 17:22:25 2024 [Z0][VMM][I]: Failed to execute virtualization driver operation: deploy.
Fri Feb  2 17:22:25 2024 [Z0][VMM][E]: DEPLOY: error: Failed to create domain from /var/lib/one//datastores/0/296699/deployment.0 error: XML error: Invalid PCI address 0000:01:01.0. slot must be <= 0 Could not create domain from /var/lib/one//datastores/0/296699/deployment.0 ExitCode: 255
Fri Feb  2 17:22:25 2024 [Z0][VM][I]: New LCM state is BOOT_FAILURE

Corresponding part of onevm show  -j output

onevm show -j [vmid]|jq .VM.TEMPLATE.PCI
{
  "ADDRESS": "0000:41:00:0",
  "BUS": "41",
  "CLASS": "0302",
  "DEVICE": "2236",
  "DOMAIN": "0000",
  "FUNCTION": "0",
  "NUMA_NODE": "-",
  "PCI_ID": "0",
  "SHORT_ADDRESS": "41:00.0",
  "SLOT": "00",
  "VENDOR": "10de",
  "VM_ADDRESS": "01:01.0",
  "VM_BUS": "0x01",
  "VM_DOMAIN": "0x0000",
  "VM_FUNCTION": "0",
  "VM_SLOT": "0x01"
}

Corresponding part of deployment.0
<devices>
...
                <hostdev mode='subsystem' type='pci' managed='yes'>
                        <source>
                                <address  domain='0x0000' bus='0x41' slot='0x00' function='0x0'/>
                        </source>
                                <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0'/>
                </hostdev>
        </devices>
        <devices>
                <controller index='0' type='pci' model='pcie-root'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-root-port'/>
                <controller type='pci' model='pcie-to-pci-bridge'/>
        </devices>

The following manual change helps to deploy VM from deployment.0 file:
diff /var/lib/one/datastores/0/<vmid>/deployment.0 /tmp/<vmid>.deployment.0.orig
43c43
<                               <address type='pci' domain='0x0000' bus='0x01' slot='0' function='0'/>
---
>                               <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0'/>

lspci output from the inside VM:

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
00:01.0 VGA compatible controller: Cirrus Logic GD 5446
00:02.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.3 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.4 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.5 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.6 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.7 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.3 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.4 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.5 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.6 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.7 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 3D controller: NVIDIA Corporation GA102GL [A10] (rev a1)
02:00.0 PCI bridge: Red Hat, Inc. Device 000e
04:00.0 Ethernet controller: Red Hat, Inc. Virtio network device (rev 01)
05:00.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI (rev 01)
06:00.0 USB controller: Red Hat, Inc. QEMU XHCI Host Controller (rev 01)
07:00.0 Communication controller: Red Hat, Inc. Virtio console (rev 01)
08:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon (rev 01)

To Reproduce
Create VM template with PCI device and MACHINE type 'q35'. Try to deploy it.
Expected behavior
VM should be deployed successfully.
Details

Affected Component: [Core]
Hypervisor: [KVM]
Version: [development]

Progress Status

[x] Code committed
[x] Testing - QA
[x] Documentation (Release notes - resolved issues, compatibility, known issues)

Docs commits
Code commits


[discussion] Terminology

In view of the possible future integration of this in vpype, I'd like to raise the point of terminology. It might sound like a bit of nitpicking but I guess these kinds of things are best done earlier than later.
Throughout vpype's code and documentation, the terminology layer (collection of line with, in the future, shared attribute and meant to be plotted with a specific color), line (meaning actually a polyline, eg. linemerge and vpype.LineCollection), and segment (well, one straight segment of a line). In contrast, the terminology used here is layer, block, and the move + line combination. In my opinion, this is less than ideal. In particular, the use of line for something different than the rest of vpype is confusing and there would be benefit to harmonise the terminology. I would probably agree that some of the terminology choices made in vpype weren't the best, but I've always valued coherence more than perfection :)
As a first proposal I submit the following:
header/footer
prelayer/postlayer/layerjoin
preline/postline/linejoin
firstsegment*/segment/lastsegment*/segmentjoin

* firstsegment and lastsegment would default to segment if missing

Opinions?

Yeah. I'm a fan of that. You don't need to worry about breaking changing moving the core idea over. And the firstsegment lastsegment is a good idea.
I don't love segment, not because it's not mapping a segment but because sometimes in some formats you would be exporting an point not a segment. You seem to have the same thing with LineCollection when it's really a collection of points. Lines have start and end points, and the first thing you're given isn't a segment it's a single start point.

Yeah. I'm a fan of that. You don't need to worry about breaking changing moving the core idea over. And the firstsegment lastsegment is a good idea.
I don't love segment, not because it's not mapping a segment but because sometimes in some formats you would be exporting an point not a segment. You seem to have the same thing with LineCollection when it's really a collection of points. Lines have start and end points, and the first thing you're given isn't a segment it's a single start point.

Well LineCollection is a collection of collection of point, to be precise, in the spirit of a "line" being a collection of point. Again, line is ambiguous and I'm not very fan of how I used it, but I think coherence is key here. You could say that in math, segments have end/start points while line are infinite things, so it's all blurry.
I'd be open to an alternative name for segment (it's not used much in the documentation, if at all -- just here and there in the code and not even in the API), but I can't think of anything better.

Well LineCollection is a collection of collection of point, to be precise, in the spirit of a "line" being a collection of point. Again, line is ambiguous and I'm not very fan of how I used it, but I think coherence is key here. You could say that in math, segments have end/start points while line are infinite things, so it's all blurry.
I'd be open to an alternative name for segment (it's not used much in the documentation, if at all -- just here and there in the code and not even in the API), but I can't think of anything better.

Most of the time we'd be doing a series of points from start point to end point. But, I wouldn't call the line (or several lines) in that block of text a line point, etc. Since it's really just a block of text probably describing a point in the series in most cases.  I'd actually ditch the terminology maybe completely, and use the sort of html h1-h6 like tags.
preh1, posth1, joinh1...
preh2, posth2, joinh2....
I get that that's awful, but as an example it would be maybe better to just number the things and have the parts within them. Since you only need a few different parts at each level.

Most of the time we'd be doing a series of points from start point to end point. But, I wouldn't call the line (or several lines) in that block of text a line point, etc. Since it's really just a block of text probably describing a point in the series in most cases.  I'd actually ditch the terminology maybe completely, and use the sort of html h1-h6 like tags.
preh1, posth1, joinh1...
preh2, posth2, joinh2....
I get that that's awful, but as an example it would be maybe better to just number the things and have the parts within them. Since you only need a few different parts at each level.

Well the "line" terminology exists in vpype already (throughout the doc, in command names, etc). so I'd rather stick to it, as inopportune as it might be.

Well the "line" terminology exists in vpype already (throughout the doc, in command names, etc). so I'd rather stick to it, as inopportune as it might be.

And I understand it needs to map the structure. So maybe even just make it refer more specifically to the internal workings of vpype and ditch my terms altogether.
document: header, footer
collection: header, footer, join
segment: header, footer, join
or whatever header and footer might be relevant there. Since the scheme only really works because vpype documents are so clearly organized into the three layer.

And I understand it needs to map the structure. So maybe even just make it refer more specifically to the internal workings of vpype and ditch my terms altogether.
document: header, footer
collection: header, footer, join
segment: header, footer, join
or whatever header and footer might be relevant there. Since the scheme only really works because vpype documents are so clearly organized into the three layer.

But, however it settles my course is pretty easy. Deprecate the module and point to the vpype commit that added similar functionality. So I'm certainly not going to step on your toes with regard to terms. I wrote this module basically to point out you should write this module. I'm not going to jinx that with some stubbornness.
level1, prologue, epilog
level2, prologue, epilog
level3, prologue, epilog
There's a lot of really good things to do there. The important bits is being able to know what each part is and fill it in with the data you need it to have in the way you need it to say that. You need to write this based on a template. Fitting well with vpype terms might be really important and something easy to remember would help. But, I'm kinda drawing blanks. I'm fine with segments. It makes enough sense and I recall what all the parts are.

But, however it settles my course is pretty easy. Deprecate the module and point to the vpype commit that added similar functionality. So I'm certainly not going to step on your toes with regard to terms. I wrote this module basically to point out you should write this module. I'm not going to jinx that with some stubbornness.
level1, prologue, epilog
level2, prologue, epilog
level3, prologue, epilog
There's a lot of really good things to do there. The important bits is being able to know what each part is and fill it in with the data you need it to have in the way you need it to say that. You need to write this based on a template. Fitting well with vpype terms might be really important and something easy to remember would help. But, I'm kinda drawing blanks. I'm fine with segments. It makes enough sense and I recall what all the parts are.

You are right though that once you pick a name that is set in stone. So picking a bad name is an eyesore forever. I'm fine with all of the above. I can't think of better names. I'm apparently pretty good at some worse names.

You are right though that once you pick a name that is set in stone. So picking a bad name is an eyesore forever. I'm fine with all of the above. I can't think of better names. I'm apparently pretty good at some worse names.

Just as a small input from my side: One question you maybe should answer first would be what this plugin (or the functionality in vpype if integerated there) is supposed to be for.
If you want to do a gcode writer, then for example I don't understand why we need a join part, but maybe I'm overlooking something for the gcode use case.
If this is supposed to be a "generic output plugin" which is fully configurable (to output anything, i.e. json), then at least the name is wrong. Also my gut-feeling tells me that the plugin will not be the right abstraction, there will always be cases of output formats which can not be modeled. So in the end the description language (so the tokens) get more and more complicated until you have approached a bad programming language.
Most likely I'm just not seeing it and there is a sweet spot of languages and output formats that can and should be supported...

Just as a small input from my side: One question you maybe should answer first would be what this plugin (or the functionality in vpype if integerated there) is supposed to be for.
If you want to do a gcode writer, then for example I don't understand why we need a join part, but maybe I'm overlooking something for the gcode use case.
If this is supposed to be a "generic output plugin" which is fully configurable (to output anything, i.e. json), then at least the name is wrong. Also my gut-feeling tells me that the plugin will not be the right abstraction, there will always be cases of output formats which can not be modeled. So in the end the description language (so the tokens) get more and more complicated until you have approached a bad programming language.
Most likely I'm just not seeing it and there is a sweet spot of languages and output formats that can and should be supported...

Writing template outputs. It might even be able to do all the HPGL files. With join elements, it can do valid JSON, and likely most other formats. So long as they fit in a standardish ascii writing style with number written in a way printf could recognize. It'll work. Mostly it just needed to be broad enough to capture gcode syntax from basically every hobbyist who would have their own thing. Doing that, it makes for a solid enough scheme to let anybody write anything within the criteria that it's purely text based and it tends to accept elements in the right order to print them out in that way.
Even if you just pitched it for gcode and let it write everything from CSV to DXF (there's a pure text dxf), it would be fine. Likely he'd make up some term for it that works. Sure, for gcode, though really I could absolutely write SVG with it.

Writing template outputs. It might even be able to do all the HPGL files. With join elements, it can do valid JSON, and likely most other formats. So long as they fit in a standardish ascii writing style with number written in a way printf could recognize. It'll work. Mostly it just needed to be broad enough to capture gcode syntax from basically every hobbyist who would have their own thing. Doing that, it makes for a solid enough scheme to let anybody write anything within the criteria that it's purely text based and it tends to accept elements in the right order to print them out in that way.
Even if you just pitched it for gcode and let it write everything from CSV to DXF (there's a pure text dxf), it would be fine. Likely he'd make up some term for it that works. Sure, for gcode, though really I could absolutely write SVG with it.

@theomega you raise good points: is the generic functionality really needed if so what should the name be (certainly not "gcode" since this is way too specific). I'm not too worried about either. For the former we'll see if this project gains traction and what are the use case, and it's name can easily be changed upon eventual integration in vpype (ie. it would not break user's config file if we allow for an alias pointing "gcode" top level key to the new one).
Another point you raise is whether the core approach is good or will become cluttered/limited/inadequate if/when the scope grows. For gcode and simple cases, I think it is (especially with #8). If we really wanted full flexibility, then using something like jinja template would probably be a better idea. Again, wait and see is the best attitude IMHO.
@tatarize for a HPGL support equivalent to the existing exporter, a much more refined transformation settings (with translate and rotate) would be needed. Other than that it would work probably fine.

@theomega you raise good points: is the generic functionality really needed if so what should the name be (certainly not "gcode" since this is way too specific). I'm not too worried about either. For the former we'll see if this project gains traction and what are the use case, and it's name can easily be changed upon eventual integration in vpype (ie. it would not break user's config file if we allow for an alias pointing "gcode" top level key to the new one).
Another point you raise is whether the core approach is good or will become cluttered/limited/inadequate if/when the scope grows. For gcode and simple cases, I think it is (especially with #8). If we really wanted full flexibility, then using something like jinja template would probably be a better idea. Again, wait and see is the best attitude IMHO.
@tatarize for a HPGL support equivalent to the existing exporter, a much more refined transformation settings (with translate and rotate) would be needed. Other than that it would work probably fine.

I finished #8 in 0.4.0.

Added in format.
I added in some integer functions that it's easy to misunderstand and create bugs for. Namely the integer dx and dy (idx and idy) need to compound the fractional amounts in order to avoid compounding fractional errors. This happened in a lot of embroidery programs. Imagine you moved right 0.01 mm 1000 times, you traveled 10mm right? But, imagine you wrote these movements in a format that could only properly record movements 1 mm increments. You would naively round and int the value of dx which would go to 0. And do that 1000 times. The end result is that you would move right 0 mm. Which is 10 fewer millimeters than you were supposed to. If the rounding error is one-sided within relative movements, this is a risk.
I removed negate x and negate y as I provided _x and _y and _dx and _dy as well as values for the filename in the header. The index of anything within its relative level.
I added gwrite.isvg which will show the idx idy compounding error: vpype begin grid -o 25 25 10 10 circle 0 0 100 end gwrite --profile isvg test.svg

I finished #8 in 0.4.0.

Added in format.
I added in some integer functions that it's easy to misunderstand and create bugs for. Namely the integer dx and dy (idx and idy) need to compound the fractional amounts in order to avoid compounding fractional errors. This happened in a lot of embroidery programs. Imagine you moved right 0.01 mm 1000 times, you traveled 10mm right? But, imagine you wrote these movements in a format that could only properly record movements 1 mm increments. You would naively round and int the value of dx which would go to 0. And do that 1000 times. The end result is that you would move right 0 mm. Which is 10 fewer millimeters than you were supposed to. If the rounding error is one-sided within relative movements, this is a risk.
I removed negate x and negate y as I provided _x and _y and _dx and _dy as well as values for the filename in the header. The index of anything within its relative level.
I added gwrite.isvg which will show the idx idy compounding error: vpype begin grid -o 25 25 10 10 circle 0 0 100 end gwrite --profile isvg test.svg

Okay.

I added joins. (except segment join, the first/last segment made that one kinda moot.
Shifted the fallback scheme so that move and line now, firstsegment and segment, will use the other if the other isn't there.
Also, though not discussed firstsegment is used rather than lastsegment if there is a single segment.
shifted the terms to as you suggested. with block being replaced with line. And the lines being called segments.

Okay.

I added joins. (except segment join, the first/last segment made that one kinda moot.
Shifted the fallback scheme so that move and line now, firstsegment and segment, will use the other if the other isn't there.
Also, though not discussed firstsegment is used rather than lastsegment if there is a single segment.
shifted the terms to as you suggested. with block being replaced with line. And the lines being called segments.

The goal isn't to add everything and become a crappy programming language. It's just to be able to represent most forms here. Keeping in mind we are exactly limited to vpype's hierarchy. So we will only have these three levels. And we're writing out very specific code. We are limited to ascii and we're doing no calculations on the side of the profiles.
[gwrite.isvg]
header = """<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink">
"""
footer = "</svg>"
prelayer = '<g fill="none" stroke="black">'
preline = '<path d="M '
firstsegment = "{ix:d} {iy:d} l"
segment = "{idx:d} {idy:d} "
postline = '"/>'
postlayer = "</g>"

This is pretty hard to beat. This writes a highly specialized form of svg where we're doing relative integer moves in the mm range. Without losing steps. Which isn't always trivial to write correctly. But, writing svg in a couple lines is actually pretty cool.
I don't know anything else that couldn't be done here. It should capture nearly all ascii descriptions of vpype's structures.
Yes, gcode is a too specific for what it does. Since it can write svg, json, or whatever weird random format you come up with. But, I figure that switch could be made if it makes it into core.
The solutions in #8 really does make it a swiss army knife of writing. Most of the other writing code stuff is just for show. There was a chance somebody would need y then x as part of their code. And it lets us do away with relative and negates. So it's pretty much just a syntax language.
The many changes here have only served to simply it. (though I added some idx and idy values might seem unusual).

The goal isn't to add everything and become a crappy programming language. It's just to be able to represent most forms here. Keeping in mind we are exactly limited to vpype's hierarchy. So we will only have these three levels. And we're writing out very specific code. We are limited to ascii and we're doing no calculations on the side of the profiles.
[gwrite.isvg]
header = """<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink">
"""
footer = "</svg>"
prelayer = '<g fill="none" stroke="black">'
preline = '<path d="M '
firstsegment = "{ix:d} {iy:d} l"
segment = "{idx:d} {idy:d} "
postline = '"/>'
postlayer = "</g>"

This is pretty hard to beat. This writes a highly specialized form of svg where we're doing relative integer moves in the mm range. Without losing steps. Which isn't always trivial to write correctly. But, writing svg in a couple lines is actually pretty cool.
I don't know anything else that couldn't be done here. It should capture nearly all ascii descriptions of vpype's structures.
Yes, gcode is a too specific for what it does. Since it can write svg, json, or whatever weird random format you come up with. But, I figure that switch could be made if it makes it into core.
The solutions in #8 really does make it a swiss army knife of writing. Most of the other writing code stuff is just for show. There was a chance somebody would need y then x as part of their code. And it lets us do away with relative and negates. So it's pretty much just a syntax language.
The many changes here have only served to simply it. (though I added some idx and idy values might seem unusual).

Another terminology point.
Like I could see this as:

document_start, document_end,

layer_start, layer_end, layer_join,

lines_start, lines_end, lines_join,

segment_first, segment, segment_last

<document_start>
     <layer_start>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
          <lines_join>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
     <layer_end>
     <layer_join>
     <layer_start>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
          <lines_join>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
     <layer_end>
<document_end>

There's only the one document. So it doesn't need anything else. And the segments are self contained leaf-nodes. But, the layer and line levels are notably helpful. And to help with the confusion line would be made lines that or it could be made linecollection and shortness be damned.

Another terminology point.
Like I could see this as:

document_start, document_end,

layer_start, layer_end, layer_join,

lines_start, lines_end, lines_join,

segment_first, segment, segment_last

<document_start>
     <layer_start>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
          <lines_join>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
     <layer_end>
     <layer_join>
     <layer_start>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
          <lines_join>
          <lines_start>
               <segment_first>
               <segment>
               <segment>
               <segment_last>
          <lines_end>
     <layer_end>
<document_end>

There's only the one document. So it doesn't need anything else. And the segments are self contained leaf-nodes. But, the layer and line levels are notably helpful. And to help with the confusion line would be made lines that or it could be made linecollection and shortness be damned.

That's actually good enough, I'll go with that. Like zero ambiguity. Even the linecollection thing makes it really clear. Also, if other datatypes were added it would be obvious what their various write parts would be called.

That's actually good enough, I'll go with that. Like zero ambiguity. Even the linecollection thing makes it really clear. Also, if other datatypes were added it would be obvious what their various write parts would be called.

Looks very good to me! This plug-in is becoming very neat. It might not appeal as much people who are on the opposite side of the artsy-nerdy spectrum as we are, but it should certainly serve them well too! :)

Looks very good to me! This plug-in is becoming very neat. It might not appeal as much people who are on the opposite side of the artsy-nerdy spectrum as we are, but it should certainly serve them well too! :)

Hey, I just noticed that "linecollection" made it instead of "line". This is really unfortunate because it directly clashes with vpype.LineCollection, which is the structure used for layers (again, consistently with the terminology of vpype's lines actually being polylines.
Just to clarify the current situation:

vpype doc
API container
vpype.gcode

losely defined as "geometries" or "pipeline's content"
vpype.Document (≈ Dict[int, vpype.LineCollection])
document

"layer"
vpype.LineCollection (≈ List[np.array(N, dtype=complex)])
layer

"line" (and sometimes "path")
np.array(N, dtype=complex)
linecollection !!!!

"segment" (rarely used)
n/a
segment

The term LineCollection referring to something different should be avoided.
(Side note: FWIW, matplotlib also uses LineCollection to refer to a collection of polylines)

Hey, I just noticed that "linecollection" made it instead of "line". This is really unfortunate because it directly clashes with vpype.LineCollection, which is the structure used for layers (again, consistently with the terminology of vpype's lines actually being polylines.
Just to clarify the current situation:

vpype doc
API container
vpype.gcode

losely defined as "geometries" or "pipeline's content"
vpype.Document (≈ Dict[int, vpype.LineCollection])
document

"layer"
vpype.LineCollection (≈ List[np.array(N, dtype=complex)])
layer

"line" (and sometimes "path")
np.array(N, dtype=complex)
linecollection !!!!

"segment" (rarely used)
n/a
segment

The term LineCollection referring to something different should be avoided.
(Side note: FWIW, matplotlib also uses LineCollection to refer to a collection of polylines)

Yeah, okay, I switch it.

Okay, 0.7.0 is live.
Changed it to line.


Task 'default' is not in your gulpfile

When trying to compile a project with 'gulp', there's an error:

[21:37:32] Using gulpfile ~/Dropbox/raconteur-scaffold-master/Gulpfile.js
[21:37:32] Task 'default' is not in your gulpfile
[21:37:32] Please check the documentation for proper gulpfile formatting

Fixed in 21c49b17f3f34e75b0fbd7f3a82060074ba3e090


refactor: expose DatanodeBuilder::build_object_store_manager() and MitoConfig::sanitize()

I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
What's changed and what's your intention?
Some minor refactoring:

Expose DatanodeBuilder::build_object_store_manager()
The scenario is the following code:
...
let object_storage_manager =
         datanode::datanode::DatanodeBuilder::build_object_store_manager(&storage_config)
             .await
             .context(BuildObjectStoreManagerSnafu)?;
...
let compaction_region = open_compaction_region(
                 &open_region_request,
                 &self.mito_config,
                 object_storage_manager.clone(),
             )
...

Expose MitoConfig::sanitize() to initialize Mito config outside the crate;

2. Set default value for intermediate_path instead of empty value(it will failed to create a access layer if using open_compaction_region() with default Mito config) (cc @zhongzc);
Checklist

[ ] I have written the necessary rustdoc comments.
[ ] I have added the necessary unit tests and integration tests.
[ ] This PR requires documentation updates.

Summary by CodeRabbit

New Features

Set a default data home directory for file storage, enhancing ease of configuration.
Updated intermediate path configurations to use the default data home directory across various components.

Documentation

Revised configuration documentation to reflect changes in default paths.

Configuration

Updated example configuration files to include the new default paths for intermediate storage.

@evenyag @zhongzc PTAL


Taking notes of some general websites, ex. blog posts

Is your feature request related to a problem? Please describe.
Sometimes I just want to take some notes when reading something other than a paper, ex. a blog post about a bunch of papers. It would be cool if PaperMemory let me do this.
Describe the solution you'd like
Just enable PaperMemory of general webiste. I know the concern is how to properly format this entry. Actually, we can use misc to create an entry for generic website in bibtex.
Additional context
Let me know what do you think!

Hey!
I can see the usefulness and I agree.
The main blocker so far has been that everything is automated. You cannot change a paper's metadata manually except by exporting your memory, changing the json, importing back.
In other words this suggestion would require me to implement a user interface to let you at least 1/ set the author name and 2/ the website's publication year (title and access date can be parsed automatically).
An easy v0 is to just let you record a website and only its url, title and access date would be stored. Anything else you'd have to input as a note.
As for a v1 with a user-interface, I may do this but it's not a priority.
What do you think?
Thanks for your feedback!

Hey @vict0rsch, thanks for the reply!
I think the roadmap makes perfect sense. Both v0 and v1 looks good to me.
Let me know if there is anything I can help.

Hey @jeasinema I've but a v0/beta together in #161
Would you like to try it out in the PR's branch and tell me if that's useful enough to be merged?

v1's actually done too now, will be part of next release


Vimeo Downloader Unsupported URL

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[x] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Provide a description that is worded well enough to be understood
URLs like https://vimeo.com/event/4734835/embed give unsupported url error.
I can play the video in browser with custom header "referer":"https://annualmeeting.hematology.org/"
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://vimeo.com/event/4734835/embed', '--referer', 'https://annualmeeting.hematology.org/', '-o', 'video.mp4']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [65cf46cdd] (win_exe)
[debug] Python 3.10.11 (CPython AMD64 64bit) - Windows-10-10.0.17763-SP0 (OpenSSL 1.1.1t  7 Feb 2023)
[debug] exe versions: ffmpeg 2024-11-06-git-4047b887fc-full_build-www.gyan.dev (setts)
[debug] Optional libraries: Cryptodome-3.21.0, brotli-1.1.0, certifi-2024.12.14, curl_cffi-0.5.10, mutagen-1.47.0, requests-2.32.3, sqlite3-3.40.1, urllib3-2.3.0, websockets-14.1
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Loaded 1837 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp)
[generic] Extracting URL: https://vimeo.com/event/4734835/embed
[generic] embed: Downloading webpage
WARNING: [generic] Falling back on generic information extractor
[generic] embed: Extracting information
[debug] Looking for embeds
ERROR: Unsupported URL: https://vimeo.com/event/4734835/embed
Traceback (most recent call last):
  File "yt_dlp\YoutubeDL.py", line 1634, in wrapper
  File "yt_dlp\YoutubeDL.py", line 1769, in __extract_info
  File "yt_dlp\extractor\common.py", line 742, in extract
  File "yt_dlp\extractor\generic.py", line 2553, in _real_extract
yt_dlp.utils.UnsupportedError: Unsupported URL: https://vimeo.com/event/4734835/embed

from  https://vimeo.com/event/4734835/embed I extracted following url
https://player.vimeo.com/video/1036872476/config?autopause=0&background=0&badge=0&byline=0&bypass_privacy=1&chromecast=1&collections=0&color=FFFFFF&colors=000000%2CFFFFFF%2Cffffff&context=embed_playlist.4734835&controls=1&default_to_hd=0&external_embed=1&force_embed=1&fullscreen=1&h=a2b2114e78&like=0&logo=0&loop=0&outro_new=0&play_button_position=auto&playbar=1&portrait=0&quality_selector=1&referrer=https%3A%2F%2Fannualmeeting.hematology.org%2F&share=0&title=1&transcript=1&transparent=0&volume=1&watch_later=0&s=1457735f896775057d9bec06cf3df6c839e97395_1735562244
tried to download it with yt-dlp but it falls back to generic and downloads text data instead of parsing playlist
https://github.com/yt-dlp/yt-dlp/issues/11939
yt-dlp.exe -vU "https://player.vimeo.com/video/1036872476" --referer "https://annualmeeting.hematology.org/" -o Video.mp4
gives following output
[debug] Command-line config: ['-vU', 'https://player.vimeo.com/video/1036872476', '--referer', 'https://annualmeeting.hematology.org/', '-o', 'Video.mp4']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [65cf46cdd] (win_exe)
[debug] Python 3.10.11 (CPython AMD64 64bit) - Windows-10-10.0.17763-SP0 (OpenSSL 1.1.1t  7 Feb 2023)
[debug] exe versions: ffmpeg 2024-11-06-git-4047b887fc-full_build-www.gyan.dev (setts)
[debug] Optional libraries: Cryptodome-3.21.0, brotli-1.1.0, certifi-2024.12.14, curl_cffi-0.5.10, mutagen-1.47.0, requests-2.32.3, sqlite3-3.40.1, urllib3-2.3.0, websockets-14.1
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Loaded 1837 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp)
[vimeo] Extracting URL: https://player.vimeo.com/video/1036872476
[vimeo]<PHONE_NUMBER>: Downloading webpage
ERROR: [vimeo]<PHONE_NUMBER>: Cannot download embed-only video without embedding URL. Please call yt-dlp with the URL of the page that embeds this video.
  File "yt_dlp\extractor\common.py", line 742, in extract
  File "yt_dlp\extractor\vimeo.py", line 969, in _real_extract

Duplicate of #1608

vimeo events are not yet supported


Have high resolution regular shape

Be able to have the regular shape in a high resolution.
Visible on a smartphone on the example https://openlayers.org/en/latest/examples/regularshape.html

I like it.
Have you thought about applying the same to ol/style/Icons with the color attribute set?
Would be pretty neat for svg icons.
https://openlayers.org/en/master/examples/icon-color.html

As I see it's not directly possible for the SVG, for the SVG you should create a bigger icon, and use the parameter scale to get the wanted size...

Nice work @sbrunner. I look forward to when this is ready for review.

As I see it's not directly possible for the SVG, for the SVG you should create a bigger icon, and use the parameter scale to get the wanted size...

It should be doable to fix that with this pull request too, because regular shapes and icons go through the same code path in the end. All that needs to be done is modify the replaceColor() method in ol/style/IconImage to multiply the canvas width and height by the pixel ratio, and modify the drawImage call to provide both source and destination size.

OK @ahocevar I will try :-)

Good solution, now it's working like a charm :-)

In which case is it expected to update the pixel ratio? Changing the browser zoom level keeps the original icons, so the icons are blurred when zooming in. Is this expected?

To test it I use the Firefox debugger switch to Mobile device (Galaxy S9), click on take a screenshot, open the given image with Gimp and here we can relay see the details of the hidpi image.
When we change the browser zoom it's also working, but we should reload the page, It's probably also doable but probably deeper in OpenLayers :-)
In fact, it's set here, https://github.com/openlayers/openlayers/blob/main/src/ol/PluggableMap.js#L169-L172
And the DEVICE_PIXEL_RATIO is used in 10 different files...

Changing the pixel ratio dynamically is beyond the scope of this pull request. It is doable (with a listener), but that's a separate issue - and it could be handled on the application level too.

Changing the pixel ratio dynamically when the browser zoom changes is beyond the scope of this pull request. It is doable (with a listener), but that's a separate issue - and I would suggest handling that on the application level.

+1 that's out of the scope of this pull request
But since DEVICE_PIXEL_RATIO is a constant I think that's not possible to do it at application level...

This call should use the canvas width and height. Otherwise only the top-left corner is colored.
https://github.com/openlayers/openlayers/blob/2dd9342a982e14c068cdd8c6492d2c6f79e8f81f/src/ol/style/IconImage.js#L236-L241
And maybe the canvas size should be rounded up if it is not an integer. The circle in Paris looks like it is cut off at the left.

@M393 just changed, thanks.
For the ceil I already tested that, and as I see:

With Firefox I always have an issue...
With Chrome I never have an issue...

Now I added it because it looks like stronger :-)

I just see, I miss some places, now it's working well :-)

@sbrunner I'm adding this to the 6.4.0 milestone. Would be great if you could address my remaining comment.

@sbrunner Any update on this?

Thanks @ahocevar :-)


Send globalClusterLabels as tags in InfluxDBSink

Hi @lukaszkrawiec,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

@seglo Hi Sean, would you mind reviewing when you have the chance? Also it seems like someone else also stumbled into this and raised an issue - #199


Test run times don't make sense

When running tests with pytest-xdist the test run times don't make sense, as can be seen in the following screen shot.

The test was run with pytest -v -l -n10 and the report states a total run time of 36 minutes. However for some of the individual test files a longer run time is reported. For test_orasql.py and test_ul4.py a run time of over two hours is reported.

Yes, that's another thing that might need adjusting when it comes to pytest-xdist. The time displayed is the sum of all test durations which may or may not be what you want. On one hand it doesn't make sense since the actually time to run the tests might be shorter if they are executed in parallell, on the other hand it is probably the best indicator if you want to know which modules take the longest time to execute. If it would be the wall clock time it might vary a lot depending on how the scheduler works. You could also run tests in random order in which case it would be even more misleading.
So I don't really know what to display there. Maybe it is best to just remove it to avoid confusion...


Update svelte package to Svelte v5

Package

[ ] lucide
[ ] lucide-angular
[ ] lucide-flutter
[ ] lucide-preact
[ ] lucide-react
[ ] lucide-react-native
[ ] lucide-solid
[X] lucide-svelte
[ ] lucide-vue
[ ] lucide-vue-next
[ ] Figma plugin
[ ] source/main
[ ] other/not relevant

Version
0.454.0
Can you reproduce this in the latest version?

[X] Yes
[ ] No

Browser

[X] Chrome/Chromium
[ ] Firefox
[ ] Safari
[ ] Edge
[ ] iOS Safari
[ ] Opera
[ ] Other/not relevant

Operating system

[ ] Windows
[ ] Linux
[ ] macOS
[ ] ChromeOS
[ ] iOS
[ ] Android
[ ] Other/not relevant

Description
types are not completely compatible with Svelte 5
Steps to reproduce

create a project with svelte5
try out the Lucide Svelte Typescript Example
ComponentType<Icon> is no longer supported

Checklist

[X] I have searched if someone has submitted a similar issue before and there weren't any. (Please make sure to also search closed issues, as this issue might already have been resolved.)

Perhaps this solution will help you figure out the problem click

idk... If I understand correctly, the changes made to the Svelte components are in the "compiler." This means that the current lucide-svelte components are still compatible with svelte 5 and the real issue is with the types.
In my very amateur opinion, I think a better option would instead be to make the new Component type in the svelte repo backward-compatible with the ComponentType type (i.e. type Component = { /* type stuff */ } | ComponentType). This makes sure that the lib still is compatible with Svelte 3/4 while getting to use the type Component for everything.
But yeah I might be objectively wrong with this. I don't know how this stuff works really.

It would be great if it also was compatible with runes. Right now it throws errors due to $$props deprecation, and it's the only library in my stack that prevents using full rune mode in the Svelte compiler.


fix: Change V2 Swagger API version to 2.0.0

Signed-off-by: Cherry Wang<EMAIL_ADDRESS>PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/master/.github/Contributing.md.
What is the current behavior?

Issue Number:
Closes #3604
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

New Imports

[ ] Yes
[ ] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
Other information

Codecov Report

Merging #3605 (dcec332) into master (e36e7e4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3605   +/-   ##
=======================================
  Coverage   47.13%   47.13%
=======================================
  Files         111      111
  Lines        8142     8142
=======================================
  Hits         3838     3838
  Misses       3937     3937
  Partials      367      367

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e36e7e4...dcec332. Read the comment docs.


Could not load type 'Syste.Security.Cryptography.SHA256Cng'

Running sparrow command on Server 2012 R2 domain joined server from an acount with full Azure admin rights; Powershell 7.1, all needed modules installed, and getting this error:

Could not load type 'Syste.Security.Cryptography.SHA256Cng' from assembly 'System.core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken =
I have no idea idea what this means; found some references to it online from other users doing unrelated projects but no answer; not sure if this is PS malfunction or a permissions error. Any advice?

Can you try using a lower version of PowerShell?

Can you try using a lower version of PowerShell?

Hello, we have not heard back from you regarding this issue.  If no response is given within three days, I will go ahead and close out this issue.

Hello, we have not heard back from you regarding this issue.  If no response is given within three days, I will go ahead and close out this issue.


feat: swagger docs for /customer endpoints

IBM Cloud toolchain: Delivery Pipeline deployed customers to dev, including commit dad590f53c27cce82e5c40bd2d29fd97ec76f6fc


Small layout shift issue when scroll

Hi, thank for great library
I'm starting integrate virtua to my project, everything is fine but I just have small issue with layout shift. I not sure what cause it, I wonder is it related to this issue? https://github.com/inokawa/virtua/issues/65
https://github.com/inokawa/virtua/assets/123083837/f2241877-569a-419d-8f1b-5d34ddcb7de4

Hi @inokawa , I've tested with virtua v0.9.1 and it totally fine 🤣, so this issue only happen with v0.12.0, it seem strange

Thank you for the additional information.
As I mentioned, I changed range detection algorithm in 0.11.0 and now items at the opposite side of scroll direction will be unmounted while scrolling, which is similar to react-window.
I suspect this behavior causes the problem.

I've a suggestion, instead of unmount the item, we can replace them with blank div match exact item's height

Hi @inokawa , I've tested with v0.13.0 and it work really well


Make Crosswalk Optional

Can I remove crosswalk from cordova?
I know that removing crosswalk may cause apps not working on older device. But there might be other consideration such as making smaller footprint by removing crosswalk.

I will add an option to the command, but until then you can remove Crosswalk:
$ quasar wrap plugin remove cordova-plugin-crosswalk-webview

Released Quasar CLI v0.1.3 which adds this option to skip Crosswalk. Read release notes here.
Thanks for the suggestion!


deleteConfirm without alert

Hello,
I am having issues with the deleteConfirm, I want to use the default delete button, but I don't want to use the alert of deleteConfirm. My idea is to open a delete dialog, when the button is clicked.
I try this:
deleteConfirm: function(args) {
     var string = "The user \"" + args.item.Name + "\" will be deleted. Are you sure?";
     $("#deleteDialog").dialog("open");
     $("#deleteDialogText").text(string);
}

But before he open the dialog, the app shows an alert with no text.
It's possible to delete this alert?

Please see comments to this pull request https://github.com/tabalinas/jsgrid/pull/221


OTG: P4rt5.1 fix to get dstMac with "gnmi watch" instead of "gnmi get"

OTG: P4rt5.1 fix to get dstMac with "gnmi watch" instead of "gnmi get"

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 57.219%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1181

Relevant Lines:
2064

💛  - Coveralls

/gcbrun


invalid path issue

Hey, I'm trying to run this, and can't seem to get the tiles to be recognized in the command. I have a subdirectory called 'screens' from where the .py file is
python mosaic.py imgSrc screens
python mosaic.py imgSrc /screens
python mosaic.py imgSrc fullPath
all give me
invalid syntax
Am I missing something obvious here?

Can you let me know the exact command you are running, and the full output that you get (maybe a screenshot?) also, what OS and python version are you using

Fresh install of Python 3.5.

Ok, that explains it - you are using Python 3 and the code in this project is intended for Python 2. You can have both versions installed on your PC together, just make sure you use the right one when you run the code.

Thanks!


Native module is not installed correctly

Hello,
I'm trying to use react-native-device-info lib with react-native-threads on Android. In iOS works perfectly.
So I put on the MainApplication.java the dependency for RNThreadPackage
new RNThreadPackage(
              mReactNativeHost,
              new RNDeviceInfo() <-- here
)

But throws this error:

When i try to use react-native-device-info on main regular thread of the react-native, works perfectly, so i think that the installation of this native module it's ok and has any issue or conflict with react-native-threads.
Somebody has any workaround or tip to help-me to investigate this issue?

The issue is not related with react-native-device-info module, but the native module of react-native called DeviceInfo.
The exception comes from:

Is this issue only reproducible on react native 0.52? There have been many breaking changes between versions of react native, I don't think the current version of this library can support react native 0.52.
For future reference, it is nearly impossible to address issues like this without getting some basic information such as the version of react native you are running and the version of react-native-threads that you are using

Also facing this on 0.48.3. Any suggestions?

@jinxac try use my fork, has some changes that makes compatible with <= 0.52
joaom182/react-native-threads

Same issue RN 0.55.4

Same issue
RN 0.55.4
react-native-threads 0.0.14


RunHostTest: Monitor console on running host commands

Fix OpTestThread: Minor fixes for OpSolMonitorThread3
Patch has the following minor fixes
a) OpSolMonitorThread3 has an unused log_file
b) Use get_console() to re-initiate console access

RunHostTest: Monitor console on running host commands
This patch adds support to monitor console when running host command(s).

Signed-off-by: Harish<EMAIL_ADDRESS>

Thanks @harish-24 for the fixes in OpSolMonitorThread3 and also for adding console monitor support in RunHostTest test.


webpack cjs targetType compile jsPdf show error Can't import the named export 'SVGPathData' (imported as 'SVGPathData') from default-exporting module (only default export is available)

Bug report

What is the current behavior?
i use webpack5 to compile a vue2 component, which use jspdf.when i run webpack compile, it shows error...

when i debug the code, i found that webpack resolve buildMeta of svg-pathdata which is used in jspdf dependence canvg,  to default-only. but i look at the svg-pathdata code in github, svg-pathdata do not have a default export, it use rollup to compile the library...
If the current behavior is a bug, please provide the steps to reproduce.
component code
import { jsPDF } from 'jspdf';
const pdfInstance = new jsPDF(image.width >= image.height ? 'landscape' : 'portrait', 'px', [image.width, image.height]);

webpack code
{
      name: 'cjs',
      target: 'web',
      context: path.join(ctxDir, entry.originalName),
      output: {
        path: path.join(ctxDir, entry.originalName, 'dist/cjs'),
        library: {
          type: 'commonjs2',
        },
      },
}

What is the expected behavior?
it should resolve default-with-named when webpack resolve svg-pathdata

Other relevant information:
webpack version:  5.68.0
Node.js version: v14.18.2
Operating System: mac
Additional tools: vscode

Can you create small reproducible repo?

@alexander-akait https://github.com/wind4gis/test-webpack

@alexander-akait @vankop enter packages/test folder, and run yarn build command

this works fine https://gist.github.com/vankop/cd8e40b78b11808417080dab602a2cd8

i delete lerna and cli, you can checkout test branch, it's a simple repo...
and i found that maybe the image file loader rule cause the problem
{
        test: /\.png|jpg|gif|jpeg|svg/,
        type: 'asset',
        parser: {
          dataUrlCondition: {
            maxSize: 10 * 1024,
          },
        },
        generator: {
          filename: 'images/[base]',
        },
      },

when i run build comand it works ok, run build:svg it works wrong.
you can checkout test branch, it's so strange @vankop

@wind4gis you should put $ in the end of your test option
test: /\.png|jpg|gif|jpeg|svg$/,

with this one should be ok


Allow editing time entries

What does this PR do?
This adds support for editing time-entries.
$ toggl edit # To edit the currently running time-entry.
$ toggl edit -i # To open an interactive picker to select a time-entry to edit.

This opens the time-entry as a text file in the default editor.[^1]
The user can then edit the time-entry and save the file.
The time-entry is then updated with the new values.
The core of this lies in the Parcel trait, which allows us to serialize and
deserialize the time-entry into a sequence of bytes.
pub trait Parcel {
    fn serialize(&self) -> Vec<u8>;
    fn deserialize(&self, data: Vec<u8>) -> Self;

    fn launch_in_editor(&self) -> Result<Self, String>
    where
        Self: Sized,
    {
        let contents = self.serialize();

        let dir = tempdir().expect("Failed to create temp directory");
        let file_path = dir.path().join("toggl.txt");

        let mut file = File::create_new(file_path.clone()).expect("Failed to create file");
        file.write_all(&contents)
            .expect("Failed to write current time-entry to file");

        utilities::open_path_in_editor(&file_path).expect("Failed to open file in editor");
        drop(file);

        let contents =
            fs::read(file_path).expect("Failed to read file time-entry editing in editor");

        dir.close().expect("Failed to clear temp directory");

        Ok(self.deserialize(contents))
    }
}

I'm still ironing out the details of this, but it seems to be working well so
far. And the launch_in_editor method should probably be moved to a separate
trait, as it's not really related to serialization/deserialization.
Changes

🎬 Allow editing time-entries
✍ Use File::write_all to write time-entry
⛷ Serialize directly into bytes instead of json
🌳 Implement project/task deserialization

Gif
TODO
Context
TODO

[^1]:
The default editor is determined by the EDITOR environment variable.
If this is not set, we default to vim. It might be worth to add smarter
fallbacks, like checking for VISUAL or git config core.editor.
In addition to adding our own variable TOGGL_EDITOR in case the user
wants to use their editor with different configuration for toggl.

I haven't done any programming in rust (yet) but I am building from source and will give it a try!

That's great! If you run into any issues feel to reach out.

Would it make sense to also support flags here for non-interactive mode. For instance, toggl edit --description "new description" would change the description.
Only toggl edit --interactive would open the editor in my mind. What do you think?

Yeah at the moment that's the case, and I feel 90% of the time that is how it will end
up being used.
I feel it'd be nice if edit works for for any entry so you could use the cli to list entries
and you if see something out of place you can correct it from within the cli.
Though if you feel strongly in either direction let us know!
I'm quite open to changing how this works.

@wd60622 I've added a Todos list to the PR description, and pushed some changes so editing the running entry now works with the editor of your choice and toggl edit.
You can update description, tags, project, task and start time for now.


nixos-install ignores command line flags depending on order

Issue description
I tried to run from a live CD: nixos-install --chroot --root /mnt/nixos to chroot into an existing nixos installation, as described in here.
It complained installation not finished; cannot chroot into installation directory.
After some code reading I figured that this is because the order of command line flags matters: There is a break in this code that ignores all arguments past --chroot.
Running nixos-install --root /mnt/nixos --chroot instead (with --chroot being the last argument) works.
I suspect that break is wrong.

The idea seems to be to allow passing a command, e.g. nixos-install --root /mnt/nixos --chroot zsh if you despise the idea of using bash — the --chroot will consume the rest of the arguments. So in this case it's trying to chroot into /mnt and run --root /mnt/nixos.

Then maybe this should be explicitly documented, or even better the command would print what it's doing / how it interpreted the arguments.
Alternatively the error message could be improved to make it less confusing, such as echoing installation not finished; cannot chroot into installation directory $mountDir; ensure that --chroot is the last argument.

This is documented in nixos-install(8):

  --chroot
     Chroot into given installation. Any additional arguments passed are going to be executed inside the chroot.

Right, then I propose to change to:
installation not finished; cannot chroot into installation directory $mountDir; did you pass the right --root? Keep in mind that all arguments after --chroot are going to be executed inside the chroot

cc @copumpkin

Before talking about its interface, let's get it working again 😄  #28777

The --chroot option has been removed and superseded by nixos-enter, so I think this issue can be closed?


Make acs engine deployable in AzureChinaCloud

Due to Chinese firewall issue, google and azure CDN is blocked which will cause the acs engine deployment failed. In this PR, I extract some hard coded urls and configurations in parameters so that the users can specify them using Chinese local mirror.

Common changes:

Add "environment" flag in cluster definition with default value "AzurePublicCloud".
Update testdata to avoid test break.

DC/OS changes:

Change dcosprovision.sh by adding Chinese local urls.

Kubernetes changes:

Extract hard code docker download url, kubectl, kubernetes key images urls.
Put the default urls into const.go
Move and gzip hard coded configurations (such as kube-apiserver.yaml...) in kubernetesmastercustomdata.yml to seperate yaml files.
Add "cloud" parameter in azure.json so that when kubernetes start, it can point to the right endpoint.
Change the hard code AzureProdFQDN by adding Chinese custom endpoint "cloudapp.chinacloudapi.cn"
Change the provision.sh writekubconfig function so when user specify the "AzureChinaCloud" the correct FQDN suffix "cloudapp.chinacloudapi.cn" can be written.

Hi @wangtt03, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Tiantian Wang). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@wangtt03 - thank you for these changes, we are prioritizing this for CR.

@amanohar Thanks for reviewing. The changes made in this commit:

Remove 'Environment' flag from the cluster definition json file by reusing the 'Location' inherit from ContainerService (The value of the Location field should be one of the 'AzureCloud/AzureChinaCloud/AzureUSGovernment/AzureGermanCloud').
Update defaults.go, change the SetOrchestratorDefaults function by adding location parameter, so the orchestrator properties can be set according to the location.
Update DCOS related code by extracting hard coded urls.
Update testcases to make go test pass.

cc: @colemickens

@amanohar Thanks for reviewing the code. This commit include changes:

Remove redundant fields from API model.
Merge.
Update testcases.

@amanohar Thanks for reviewing! I updated the code:

Remove redundant KubernetesConfig  from v20160330/types.go,v20160930/types.go, v20170131/types.go
Update KubernetesHyperkubeSpec to KubernetesImageBase in vlab/types.go
Update testcases.
Merge from upstream.

@amanohar Thanks for reviewing! I updated the code:

Remove redundant KubernetesConfig  from v20160330/types.go,v20160930/types.go, v20170131/types.go
Update KubernetesHyperkubeSpec to KubernetesImageBase in vlab/types.go
Update testcases.
Merge from upstream.

@amanohar I made a new commit based on your comments. Could you please review it? Thanks!

@amanohar @colemickens  Thanks for reviewing. I merge the code and also did some small changes to DCOS1.8.8 config file by extracting the hard code download url. Could you please have a look at it? Thanks!

@wangtt03, your changes LGTM. I will wait for @colemickens to take a look as well before signing off.

@amanohar OK. Thanks!

Approved. Please rebase or merge and run tests before integrating. Thanks!

@wangtt03 I've just replied to your responses, and am still waiting for a new push with some of the things we've discussed so far. Thanks again for all the work and patience on this!

@colemickens I did some code changes based on your and Anthony's comments:

Remove the redundant dcosBootstrapURL in DC/OS parameters.
Change the powershell script to generate azureconst.go by adding china east/north location
Remove the explicit defined AzureGermanCloud and AzureUSGovCloud.
Remove KubectlVersion parameter. Extract it from hyperkube image instead.
Interface changes requested by Anthony (properties -> containerService).
Update test cases.
Some minor changes.

@colemickens @anhowe Thanks for your reviewing😊

@colemickens Could you please review this PR? Thanks😊!

@wangtt03 Looks great. One remaining question: https://github.com/Azure/acs-engine/pull/152#discussion_r102846242
Does that need to be fixed? I assume you're testing it and it works, so I guess the extra whitespace must not hurt? Let me know and I'll merge this tomorrow.

@colemickens Thanks for your reviewing. The extra white space doesn't hurt. Actually I just followed the existing coding convention in this file:)

I thought I'd seen it before... thanks for confirming.


[PE-D][Tester B] Edit Course: Able to edit to empty course name

I believer there isn't any validation for the course when editing. I could edit the name to empty and it will allow.

Labels: type.FeatureFlaw severity.Low
original: devanshubisht/ped#4

Same issue as #109


Node connexion failure

Blitz wallet fail to connect to a node at the creation of a wallet (with or without VPN) using Android 7.0 MIUI 11 (Xiaomi).

Edit:
Blitz wallet Android-v0.3.2-beta

Could you try and connect on cell service and not wifi?
Also, was this the first time you loaded the wallet, if so, did you import a seed or use a seed generated by Blitz?

Was this the first time you have loaded the wallet? or has it loaded in the past and now is not loading?

It was my first try ever of your App.

I will have to check on this. I have sometimes noticed an issue connecting to the greenlight node on the initial load from some wifi services because it says "connection reset by peer". I will get back to you if I find anything.

Thanks, no worry, nothing hurry.
I should add that Xiaomi is known to have some proprietary Java implementation that rise compatibility issues; perhaps that Xiaomi get a beter implementation after my Redmi Note 4?
https://www.browserstack.com/test-on-xiaomi

I probably should have said that i don't have Google Play services disabled.

Here is the response I got from the Greenlight team:
I filled out the report based on this issue with my school wifi, but you are running into the same issue as well.
We've had this situation a couple of times before. If the connection to scheduler.gl.blckstrm.com is the only affected connection it is likely that your school is using DPI with a custom root certificate installed on the clients, that allows the firewall to decrypt the traffic between client and server. This strips not only the original server TLS envelope, but also the client authentication we use to identify the client.
We documented this in the FaQ here: https://github.com/Blockstream/greenlight/pull/546/files
Can you check with the network admins to see if they are doing DPI, and maybe ask what would be required for an exemption from it?

It's not an issue with the liquid node its an issue with the greenlight node. Have you tried to log in again since it failed?

Ok.
Yes, and i got the same error message.


Playground: Nightlies stuck on 4.5.0-dev.20210910

If you check out https://www.typescriptlang.org/play?ts=next, you'll get a version that's about 2 weeks old. Not sure what's happening there.

Looks like this button needs to be pressed: https://github.com/microsoft/TypeScript-Make-Monaco-Builds/actions/workflows/nightly.yml


feat(streams): new ExactReader

This pull request adds a new class to @std/streams that takes in a ReadableStream<Uint8Array> and returns a ReadableStreamBYOBReader that guarantees the buffer provided will always be fully filled when it resolves, with the exception of the last value returned.
This class is useful for if you want to consume the stream in changing but exact sizes. Say you want to consume the first byte then the next x bytes, etc.
import { ExactReader } from '@std/streams'
import { assertEquals } from '@std/assert'

const reader = new ExactReader((await Deno.open('./deno.json')).readable)
let x = await reader.read(1)
assertEquals(x.value!.length, 1)
reader.releaseLock()

I feel the same thing can be achieved by using min option of ReadableStreamBYOBReader.read
ref: https://github.com/denoland/deno/pull/20849 and https://github.com/whatwg/streams/pull/1145
const readable = (await Deno.open('./deno.json')).readable
const reader = readable.getReader({ mode: "byob" });
const u8 = new Uint8Array(1024);
const result = await reader.read(u8, { min: 1024 });
console.log(result.value.length)

I did not even know this was a thing. I can't find any info on a second argument for the read method on MDN

The MDN docs makes no mention of the second argument: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStreamBYOBReader/read
But looking at the spec it lists, it does show a min argument: https://streams.spec.whatwg.org/#ref-for-byob-reader-read③


Should initial losses be NaN?

This could be entirely due to my setup and any mods to get it runningn (but also posting in case anyone else runs into it), but the initial losses are NaN due to tensors being empty. During training they have a size, but later on they are empty and so return Nan as loss (so it's not due to underflow or overflow). Maybe you've seen this issue. Trying to get to the bottom of it
actor_loss tensor(nan, device='cuda:0', grad_fn=<NegBackward0>) critic_loss tensor(nan, device='cuda:0', grad_fn=<MaximumBackward0>) entropy_loss tensor(nan, device='cuda:0', grad_fn=<MeanBackward0>) loss tensor(nan, device='cuda:0', grad_fn=<SubBackward0>)

and a few of the tensors being used inside the loss
b_log_pis tensor([], device='cuda:0') mb_advantage tensor([], device='cuda:0') new_mb_log_pis tensor([], device='cuda:0', grad_fn=<SqueezeBackward1>) new_mb_values tensor([], device='cuda:0', size=(0, 1), grad_fn=<AddmmBackward0>) mb_qvalue tensor([], device='cuda:0') mb_values tensor([], device='cuda:0') new_mb_entropies tensor([], device='cuda:0', grad_fn=<NegBackward0>)

initially these actually have a size during every training step.

Ok, I figure it out. For some reason the starting index was going beyond those defined in indices. Fixed in my fork here https://github.com/RezaKakooee/space_layout_gym/compare/SpaceLayoutGym-v0...jloveric:space_layout_gym:SpaceLayoutGym-v0#diff-af26a04a04e22cd3dd1bcf7161a6c39ac8e5347972abc6d83124d48f3d0c7437R88
Added the line
if start > len(indices) :
                    break