SubpassDescriptionBuilder::resolve_attachments Must null Out the Pointer if Slice Length is 0

Currently the builder for the resolve attachments just takes the pointer of the slice of the resolve attachments. Unfortunately the spec requires this be a true null if there are no resolve attachments.

pResolveAttachments is NULL or a pointer to an array of colorAttachmentCount VkAttachmentReference structures defining the resolve attachments for this subpass and their layouts.

Which means the generated code should look something like:
    pub fn resolve_attachments(mut self, resolve_attachments: &'a [AttachmentReference]) -> Self {
        self.inner.color_attachment_count = resolve_attachments.len() as _;
		if self.inner.color_attachment_count != 0 {
        	self.inner.p_resolve_attachments = resolve_attachments.as_ptr();
		} else {
			self.inner.p_resolve_attachments = 0 as _;
        }
        self
    }

Unfortunately it is just this slice that needs that qualification added.
This has caused a real driver issue on mobile drivers.

Not an ash bug, misread the spec. This is a driver bug, and per precident, will be worked around a layer above ash.

Related: https://github.com/MaikKlein/ash/issues/445


Executing libc++.so through the Run application causes a page fault

Using run to execute /lib/libc++.so causes the kernel to panic. For some reason, Lemon holds the SHIFT key permanently after pressing SHIFT + =, so that's another bug to fix as well!
Steps to Reproduce

Open Run.
Type /lib/libc++ into the dialog box.
Press LSHIFT + TAB to stop Lemon from holding SHIFT.
Type .so to finish the path.
Press Enter.

Screenshot

Serial Output
Windows Hypervisor Platform accelerator is operational

[INFO]    Initializing Lemon...

[INFO]    Initializing System Timer...OK
[INFO]    Initializing ACPI...OK
[INFO]    Initializing PCI...OK
[INFO]    Initializing Local and I/O APIC...OK
[INFO]    Initializing SMP...
[INFO]    [SMP] 2 processors initialized!OK
[INFO]    Used RAM: 1 MB
[INFO]    Initializing Ramdisk...OK
[INFO]    Initializing HID...
[INFO]    OK
[INFO]    Initializing Task Scheduler...
[ERROR]   [PCIDevice] AllocateVector: Device not MSI capable!
[INFO]    [XHCI] Interface version: 0x0, Page size: 1, Operational registers offset: 0x40, Runtime registers offset: 0x1
000, Doorbell registers offset: 0x2000
[WARN]    [ATA] No IDE controller found!
[INFO]    Initializing AHCI Controller...
[WARN]    [SATA] Port Hung
[INFO]    [AHCI] Found 3 partitions!
[INFO]    [Ext2] Initializing Volume    Revision: 1, Block Size: 4096, 791108 KB/914432 KB used, Last mounted on: /mnt/L
emon
[INFO]    [FAT32] Initializing Volume   Signature: 41, OEM ID: mkfs.fat, Size: 128 MB
[INFO]    [i8254x]    Base Address: 0xfebc0000, Base Address (virtual): 0xffffffff7ebc0000, IO Base: 0xc000, EEPROM Pres
ent: true, Base Address 1: 0xc000, Base Address 2: 0x0
[ERROR]   [PCIDevice] AllocateVector: Device not MSI capable!,IRQ: 0x2b
[INFO]    [i8254x] MAC Address: 0xde:0xad:0x69:0xbe:0xef:0x42
[INFO]    [i8254x] Link Up, Speed: 1000
[INFO]    [Network] Initializing network interface layer...
[INFO]    Loading Init Process...OK
[INFO]    (Init): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4527880
[INFO]    (Init): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4526904
[INFO]    (Init): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4525928
[INFO]    (Init): mlibc: Broken mbtowc() called, 4528320
[INFO]    Loading: /system/lemon/lemonwm.lef
[INFO]    Done (took 414000 us)
[INFO]    Loading: /system/bin/shell.lef
[INFO]    (lemonwm.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4662904
[INFO]    (lemonwm.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4661928
[INFO]    (lemonwm.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4660952
[INFO]    (lemonwm.lef): mlibc: Broken mbtowc() called, 4663344
[INFO]    Done (took 1482000 us)
[INFO]    Loading: /system/lemon/netgov.lef
[INFO]    (shell.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4900472
[INFO]    (shell.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4899496
[INFO]    (shell.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4898520
[INFO]    (shell.lef): mlibc: Broken mbtowc() called, 4900912
[INFO]    Done (took 112000 us)[LemonWM] Creating Window:    Pos: (0, 1044), Size: 1920x36, Title:
[LemonWM] Creating Window:    Pos: (0, 0), Size: 36x1044, Title:

[INFO]    Process Init (PID: 5) exiting with code 0
[INFO]    (netgov.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4466296
[INFO]    (netgov.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4465320
[INFO]    (netgov.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4464344
[INFO]    (netgov.lef): mlibc: Broken mbtowc() called, 4466736
[WARN]    SysKernelObjectDestroy: Invalid handle ID 0
[WARN]    SysExitThread is unimplemented! Hanging!Initializing interface e1k0s3!
received dhcp response:
IP Address: <IP_ADDRESS>
Subnet Mask: <IP_ADDRESS>
Default Gateway: <IP_ADDRESS>
DNS Server: <IP_ADDRESS>

[INFO]    Process netgov.lef (PID: 8) exiting with code 0[LemonWM] Creating Window:    Pos: (44, 154), Size: 42x20, Titl
e:

[WARN]    SysExitThread is unimplemented! Hanging!
[INFO]    Loading: /system/bin/fileman.lef
[INFO]    Done (took 514000 us)
[INFO]    (fileman.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4802184
[INFO]    (fileman.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4801208
[INFO]    (fileman.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4800232
[INFO]    (fileman.lef): mlibc: Broken mbtowc() called, 4802624[LemonWM] Creating Window:    Pos: (20, 20), Size: 600x34
8, Title: Fileman

[INFO]    Loading: /system/bin/run.lef
[INFO]    Done (took 533000 us)
[INFO]    (run.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4793992
[INFO]    (run.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4793016
[INFO]    (run.lef): rtdl: DT_FLAGS_1(8) is not implemented correctly!, 4792040
[INFO]    (run.lef): mlibc: Broken mbtowc() called, 4794432[LemonWM] Creating Window:    Pos: (20, 20), Size: 200x78, Ti
tle: Run...

[INFO]    Loading: /lib/libc++.so
[INFO]    Done (took 0 us)
[WARN]    Invalid ELF Header: 0x4e, 0x50, 0x55 (NPU)Page Fault

[INFO]    Page not present
[INFO]    Read Only
[INFO]    RIP:
[INFO]    0xffffffff80110267
[INFO]    Process: run.lef (10)
[INFO]
Fault address:
[INFO]    0x10c0
[INFO]    Register Dump: a: 0x10c0, b:0x0, c:0x0, d:0x6c, S:0x6c, D:0x10c0, sp:0xffffffffc53b0c88, bp:0xffffffffc53b0cb0
[INFO]    0xffffffff80148132
[INFO]    0xffffffff80151dc6
[INFO]    0xffffffff80106b0aPage Fault

[INFO]    Page not present
[INFO]    RIP:
[INFO]    0xffffffff801102ac
[INFO]    Process: run.lef (10)
[INFO]
Fault address:
[INFO]    0xffffff0030633031
[INFO]    Register Dump: a: 0xffffff0030633031, b:0x0, c:0x0, d:0x3c0, S:0xffffffff80110290, D:0xffffff0030633031, sp:0x
ffffffffc53b0850, bp:0xffffffffc53b0860
[INFO]    0xffffffff8010e96b
[INFO]    0xffffffff8013f7cc
[INFO]    0xffffffff8013da79
[INFO]    0xffffffff801065d4
[ERROR]   Fatal Kernel Exception:
[INFO]    0xd
[INFO]    RIP:
[INFO]    0xffffffff801102ac
[INFO]    Error Code:
[INFO]    0x0
[INFO]    Register Dump: a: 0x3030666666666666, b:0x0, c:0x0, d:0x3c0, S:0xffffffff80110290, D:0x3030666666666666, sp:0x
ffffffffc53b0420, bp:0xffffffffc53b0430
[INFO]    Stack Trace:
[INFO]    0xffffffff8010e96b
[INFO]    0xffffffff8013f7cc
[INFO]    0xffffffff8013da79
[INFO]    0xffffffff801065d4

solved!


Github Action suddenly starts to fail: Get<EMAIL_ADDRESS>unsupported protocol scheme ""

One of my Github actions using melange and apko suddenly started to fail:
This is the failed one:
https://github.com/kastl-ars/wolfi-apkrane/actions/runs/10344914408
Status: Downloaded newer image for ghcr.io/wolfi-dev/sdk:latest
2024/08/12 06:01:15 DEBU loading config file: apkrane-image.yaml
2024/08/12 06:01:15 INFO Building images for 1 architectures: [amd64]
2024/08/12 06:01:15 DEBU building tags [ghcr.io/kastl-ars/wolfi-apkrane:latest ghcr.io/kastl-ars/wolfi-apkrane:0.0.1]
2024/08/12 06:01:15 DEBU loading config file: apkrane-image.yaml
2024/08/12 06:01:15 DEBU doing pre-flight checks
2024/08/12 06:01:15 DEBU initializing apk database
2024/08/12 06:01:15 DEBU performing request method=GET<EMAIL_ADDRESS>2024/08/12 06:01:15 ERRO request failed error="Get<EMAIL_ADDRESS>unsupported protocol scheme \"\"" method=GET<EMAIL_ADDRESS>2024/08/12 06:01:15 WARN ignoring missing keys: failed to perform key discovery: Get<EMAIL_ADDRESS>GET @local%20./packages/apk-configuration giving up after 1 attempt(s): Get<EMAIL_ADDRESS>unsupported protocol scheme ""
2024/08/12 06:01:15 DEBU performing request method=GET url=https://packages.wolfi.dev/os/apk-configuration
2024/08/12 06:01:15 DEBU finished initializing apk database
2024/08/12 06:01:15 DEBU setting apk world
2024/08/12 06:01:15 DEBU initializing apk keyring
2024/08/12 06:01:15 DEBU installing key melange.rsa.pub
2024/08/12 06:01:15 DEBU installing key https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
2024/08/12 06:01:15 INFO setting apk repositories: [@local ./packages https://packages.wolfi.dev/os]
2024/08/12 06:01:15 DEBU performing request method=HEAD url=https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
2024/08/12 06:01:15 DEBU performing request method=GET url=https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
Error: failed to build image components: initializing apk: failed to initialize apk keyring: scheme  not supported
2024/08/12 06:01:15 INFO error during command execution: failed to build image components: initializing apk: failed to initialize apk keyring: scheme  not supported
Error: Process completed with exit code 1.

Not sure why it suddenly tries to do a GET on ./packages/apk-configuration (especially with the @local prefix).
This is the last successful run.
Any ideas what is happening here?
Kind Regards,
Johannes

fixed by @imjasonh in #1326 https://github.com/chainguard-dev/apko/commit/b485c095e1047593493746d152766f581c75d951
since this is a pretty significant breakage affecting third party users can we get a new release cut this week


Upgrade vulnerable packages

Found 2 critical vulnerabilities
Growl
Open
found 88 vulnerabilities (32 low, 36 moderate, 18 high, 2 critical)

I have updated rest of packages except for manual review
found 29 vulnerabilities (6 low, 8 moderate, 15 high) in 45180 scanned packages
  29 vulnerabilities require manual review. See the full report for details.

Thanks
Youssef

Did you test with these changes?

@sethyates I ran tests locally
✔ 79 tests completed
ℹ 4 tests skipped

=============================== Coverage summary ===============================
Statements   : 91.17% ( 351/385 ), 15 ignored
Branches     : 85.49% ( 165/193 ), 15 ignored
Functions    : 90.63% ( 58/64 )
Lines        : 89.4% ( 270/302 )
================================================================================
------------------|----------|----------|----------|----------|----------------|
File              |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
------------------|----------|----------|----------|----------|----------------|
 src/             |    91.17 |    85.49 |    90.63 |     89.4 |                |
  postscribe.js   |    85.87 |    82.35 |    81.25 |    83.33 |... 173,174,176 |
  utils.js        |    82.22 |    72.22 |    83.33 |    77.14 |... 78,79,80,82 |
  write-stream.js |    94.76 |    87.94 |    97.22 |    93.53 |... 590,597,598 |
------------------|----------|----------|----------|----------|----------------|
All files         |    91.17 |    85.49 |    90.63 |     89.4 |                |
------------------|----------|----------|----------|----------|----------------|

24 06 2019 15:37:12.196:INFO [coveralls.io]: uploading...
24 06 2019 15:37:12.196:INFO [coveralls.io]: 422 --- {"message":"Couldn't find a repository matching this job.","error":true}
➜  postscribe git:(master) ✗

OK well I was going to merge but looks like I've lost write access to the repo.

@sethyates Thanks cc @krux

@sfdc-jd @pkhetrapal friendly following up status on this pr. Ready to be merged?


Flutter style guide – "Constructor syntax"

I've noticed that at this point, the Flutter Style Guide doesn't mention factory constructors, and const factory isn't explained anywhere on dart.dev.
This is a proposal to update the "constructor syntax" section of the Flutter Style Guide to something like the following:
Constructor syntax
Avoid using static methods to create class instances.
class Foo {
  // BAD
  static Foo fromJsonString(String source) {
    // ...
  }

  // GOOD
  factory Foo.fromJsonString(String source) {
    // ...
  }
}

Static methods are sometimes necessary, e.g. when there's a nullable return type:
class Color {
  static Color? lerp(Color? a, Color? b, double t) {
    // ...
  }
}

Assign a factory constructor using = if the factory creates a class object with a different constructor, using the same parameters.
It can be declared as a const factory if it redirects to a const constructor.
abstract class Foo {
  // BAD
  factory Foo.withFunction(VoidCallback function) => _FooWithFunction(function);

  // GOOD
  factory Foo.withFunction(VoidCallback function) = _FooWithFunction;
}

class _FooWithFunction extends Foo {
  _FooWithFunction(this.function);

  final VoidCallback function;
}

A colon : can be used after the class parameter list to assign class members, make asserts, and/or redirect non-factory constructors to this or super.
All expressions after the colon should be aligned to match the indentation of the first.
class Foo {
  Foo.manyAsserts({
    required Text label,
    Color? color,
  }) : _text = label.data,
       _style = label.style,
       _textOpacity = label.style.color.opacity,
       _colorOpacity = color.opacity,
       assert(
         _text.length < 20,
         'label text is too long to be displayed correctly.',
       ),
       assert(_text == _text.trim()),
       assert(_colorOpacity > 0.5);
       assert(_textOpacity >= _colorOpacity);

  // no need to write out everything a second time!
  Foo.blank(Color color) : this.manyAsserts(label: Text(''), color: color);

  // ...
}

I figured I'd close this issue for a few reasons:

It's a month old with no activity
"constructor syntax" is grouped under "formatting", so it'd be weird to add non-formatting-related stuff to it
There's an overall lack of documentation for redirecting constructors, so dart.dev should probably be updated before/instead of the style guide.


Include npmlist

Came across ipt a few days ago, and found my sever-months-old npmlist is a great fit to it. Would love to see it included to Awesome Workflow

oh yeah 🎉that's awesome 😄 def a great fit!
thanks!

oh yeah 🎉that's awesome 😄 def a great fit!
thanks!

oh yeah 🎉that's awesome 😄 def a great fit!
thanks!

oh yeah 🎉 def a great fit 😄
thanks!

Glad you like it. :) ...(Github was glitching a lot yesterday lol)


Which file has the main decision making process?

Sorry, I know this is a bit lazy, I have crawled through the source and haven't found the "meat" yet.  Where are you calculating spreads and taking into account fees? Thanks!

Hi,
the meat is in TraderImpl.proposeTradingAction(). It is very simple. It does not cancel orders, but only makes new orders or waits for execution (or manual cancel). If a Task is active, then a new order is created after execution.
Henry

Hello,
Thank you for your code contribution, I just deployed and tried your project and got the error at hiting button "Trade", Could you help me do a quick fix.
Thanks a lot,
Tuan Nguyen.
Internal Server Error
com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not deserialize value of type com.binance.api.client.domain.general.RateLimitType from String "REQUEST_WEIGHT": value not one of declared Enum instance names: [REQUESTS, ORDERS] at [Source: okhttp3.ResponseBody$BomAwareReader@1aeb72ab; line: 1, column: 77] (through reference chain: com.binance.api.client.domain.general.ExchangeInfo["rateLimits"]->java.util.ArrayList[0]->com.binance.api.client.domain.general.RateLimit["rateLimitType"])


Specify the python version

For me, this script is fixed Python < 3.10, but unfortunately I would like to use Python 3.11.
Is it possible to specify the python version. E. g., as docker tag or using a conda environment (since venv does not seem to be enough).

Hi there.  I have good news and bad news.  The bad news is this pre-commit image uses the system Python provided with Debian so it won't be possible to parameterize on the Python version.  The good news is debian bookworm has been stabilized, so I've upgraded the docker image to Python 3.11 (provided by bookworm).  Hope this helps!


Yamaha Receiver component does not pass Name to the Web and Mobile UIs

Home Assistant release (hass --version):
0.55.1
Python release (python3 --version):
Python 3.4.2
Component/platform:
Hue
Description of problem:
The Yamaha component doesn't display the name of the receiver in the Web and Mobile App UIs. In a house with multiple receivers, such as mine, they all show up as "Yamaha Receiver"
Clearly the Yamaha component knows the name of the receiver from the receiver. In the known_devices.yaml:
greenbrreceiver:
hide_if_away: false
icon:
mac: 00:A0:...
name: green-br-receiver
picture:
track: true
vendor: YAMAHA CORPORATION
If the name field was presented instead of Yamaha Receiver, this would make these components far more usable.

known_devices.yaml is for the device tracker, and is the hostname of the receiver, it's not actually relevant to what gets displayed in the UI.
By default the yamaha name is whatever the device believes it's name is (you can change that through the mobile app or directly on the webserver running on the receiver). At least on my unit it was coming out as the model+serial number. You can also override that value in the configuration with something like the following:
  platform: yamaha
  host: <IP_ADDRESS>
  name: 'Living Room Stereo'

That will use that definition instead of auto discovery.

If the above doesn't address your concerns, let me know. My guess is that the names embedded in your receiver directly both say Yamaha Receiver.

@sdague I can name the devices myself. The ticket I'm opening here is that it would be ideal if the auto-discovery named the devices instead of forcing me to do. The devices are already named.

Ah also, @sdague I cannot reopen the issue because a collaborator closed it. Can you reopen?


[Feature]: First Semaphore application

Description
Inside a directory named Semaphoc, create a dApp with a minimalist react interface using Semaphore Protocol.
Expected behaviour
Your app must be able to:

[ ] Store a Semaphore identity.
[ ] Create signal & proofs that will be verified ON-chain.
[ ] Detect any signal emitted by the contract.

*next


BlockPuller bug: Node_MessageReceived

Node_MessageReceived threw this exception:

Locals:

Console:

Please let me know if there's any more information I can provide to help troubleshoot this.

More locals:

Thanks wowoo I never expected that exception to throw, map should not be empty.

Ah unless there is a race condition where a node got disconnected and received a block simultaneously.

Maybe. Map is not empty.

Yeah not empty but jas a removed pending vector, would be interesting to know if the node is in a disconnected state

I don't think locking is the solution it's already concurrent the dictionary right?

I belive ConcurrentDictionary.TryRemove() can fail for concurrency reasons, in which case the operation could possibly be retried with success, but I'm not (yet) familiar enough with this process to give any recommendations.

This does look like a concurrency problem to me, noting that at the point of exception, this.pendingDownloads does contain the key {000000000000000000ce3664bac8347ec29a8bcf5fcf004acb04fafef9ba1fef} which was successfully removed.

Looks to me like it was readded after it was removed, and two threads tried to hit map at the same time.

If no objection, I'll at least draft up SemaphoreSlim protection on all node events that fit this pattern.
SemaphoreSlim should incur well less than a microsecond of overhead here.

Just had the same error so here's some more data.
map is empty

state of the console

stack

locals 2

@Derrick- your last print screen is really odd, this suggests the concurrent dictionary didn't remove the item. unused has a value and also the dictionary not sure how that could happen..
Jeremy you got the same bug, that's odd has anything changed recently in this file?

I had been running the node for a few hours when it happened.
Will keep my eyes peeled for attached_node :-)

unused has a value and also the dictionary not sure how that could happen..

I went through this quite a bit. I believe it can happen because once it's removed it allows another thread to begin a pull: re-adding it.
I believe this logic must prevent another thread from checking the pending downloads while the new block is being processed. I think either semaphores or dispatching to a single block processing thread is indicated here.

I agree that NodeConnections can be refactored ideally to be thread agnostic using the async framework.
But thats a really big task (we will get to it one day) and it will still have concurrency.
We are using concurrent dictionaries I believe all our thread logic can be handled that way.
Adding semaphores kind of removed the need to use the ConcurrentDictionary (where locks are used already internally)

I'm also finding that blockpuller eventually stalls, and I my hunch is that it's related to an inconsistency in BlockPuller.map and BlockPuller.pendingDownloads.
And example of the problem is here:
			internal void Release(uint256 blockHash)
			{
				BlockPullerBehavior unused;
				uint256 unused2;
				if(this.puller.map.TryRemove(blockHash, out unused))
				{
					this.pendingDownloads.TryRemove(blockHash, out unused2);
					this.puller.pendingInventoryVectors.Add(blockHash);
				}
			}

			internal void StartDownload(uint256 block)
			{
				if(this.puller.map.TryAdd(block, this))
				{
					this.pendingDownloads.TryAdd(block, block);
					AttachedNode.SendMessageAsync(new GetDataPayload(new InventoryVector(AttachedNode.AddSupportedOptions(InventoryType.MSG_BLOCK), block)));
				}
			}

Where it is possible for 2 threads to be running these functions interleaved in such a way as to create an inconsistent state within the collections, which may result in permanent inability to download a particular block (theorized only because of my experience with stalled IBD).
I think all access to the pendingDownloads and map collections need to be synchronized, or the data within these collections needs to be combined if possible into a single concurrent data object.

New theory.
Looks like BlockPullerBehavior.AttachCore is being called twice.

Yes this is expected behaviour, the behaviours are used both for consensus and store.
Sometimes the nodes stall it can be network or the peer or what ever it very hard to find where the stalling comes from so we cannot be easily sure its the puller. To good out you need to add lots of debug output.
But I think your idea of a shared resource is not bad, we can consider having only one concurrent dictionary that has all the download info and is shared to every behaviour. Then there won't be any race condition between dictionaries.
We need to think carefully of that design.

All these invariants have to be in comments of the properties. For example, BlockPullerBehavior.Node_MessageReceived clearly states that:
IF BlockPullerBehavior.pendingDownloads contains a block hash (C1) AND the node can receive BlockPayload message that contains the hash (C2), THEN BlockPuller.map has to contain the hash as well (R1). This is very non-trivial bind between BlockPuller and BlockPullerBehavior and it is hard to check the code if that always hold.
C1 means we have to examine adding to pendingDownloads and removals from map.
Adding to pendingDownloads happens only in StartDownload(uint256) and StartDownload(GetDataPayload). StartDownload(uint256) satisfies R1 immediately. StartDownload(GetDataPayload) does not satisfy R1, but it is only called from DistributeDownload, which does satisfy R1.
Removing from BlockPuller.map happens in BlockPullerBehavior.Node_MessageReceived, which does not violate R1. Then it happens in BlockPullerBehavior.Release, which does not violate R1.
C2 seems irrelevant in all cases.
As the all code paths respect the invariant, the only possible resolution is the race condition, which is indeed possible. All it takes is for one thread to execute pendingDownloads.TryRemove in BlockPullerBehavior.Node_MessageReceived and once this is done, another thread calls BlockPullerBehavior.Release and executes puller.map.TryRemove.
I'd discourage using Concurrent structures as they tend to produce this kind of problems because you think you are safe because you are using concurrent structure ...
I'm happy to fix this race condition, but to do so, we need to identify all the invariants between all the properties we are using - map, pendingInventoryVectors, DownloadedBlocks and pendingDownloads. These have to be documented properly in the comments so that I can write the fix and not to forget about another relation among those guys. Also the comments should help the reviewer to the check the fix satisfies everything needed.


Add python3-pyopt-pip

Please add the following dependency to the rosdep database.
Package name:
pyotp
Package Upstream Source:
https://github.com/pyauth/pyotp
PIP: https://pypi.org/project/pyotp
Purpose of using this:
This dependency is being used to create one time passwords in python
Distro packaging links:
Links to Distribution Packages
https://pypi.org/project/pyotp

Debian: https://packages.debian.org/

PIP: https://pypi.org/project/pyotp

Ubuntu: https://packages.ubuntu.com/

PIP: https://pypi.org/project/pyotp

Fedora: https://packages.fedoraproject.org/

PIP: https://pypi.org/project/pyotp

macOS: https://formulae.brew.sh/
-PIP: https://pypi.org/project/pyotp

python3-pyotp seems to be available for most of the distros suggested as a system package https://pkgs.org/search/?q=pyotp. As a general rule, when there is a system package we encourage the use of it over the pip dependency and to avoid ABI problems the pip tag is not included in the rosdep files.
You're more than welcome to send a PR adding the system packages to the relevant distros.

Thank you, I  will re-submit with the system packages.


remove thread safety

Per discussion in  elastic/logstash#8830 and new codec instance per udp input worker, see logstash-plugins/logstash-input-udp/pull/32 thread safety is unnecessary in the line codec.

@colinsurprenant - can you just revert https://github.com/logstash-plugins/logstash-codec-line/commit/40a94995f699e3883137d3aa891e35e6b7737c0c then https://github.com/logstash-plugins/logstash-codec-line/commit/3f887fb4229e73d77ead70c1aa79947451f7312e ?

@jakelandis well, we're going to need to bump the version anyway so since my commit is in, I'd prefer to merge this. I also introduced a constant.

LGTM

Added version bump commit, will merge and publish.  Thanks @jakelandis.


[Enhancement] Implement new OpenAPI parser

Description
The change forks and introduces Redocly's loadAndBundleSpec function  for reading in and resolving OpenAPI $refs.
Motivation and Context
The existing method for parsing and resolving refs wasn't capable of handling spec files with $refs in places not supported by the OpenAPI specification. It also didn't support remote URL $refs.
How Has This Been Tested?
Tested in workspace demo against IOT, Petstore, and CWPP APIs, but additional tested with other specs is appreciated.
Screenshots (if appropriate)

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes if appropriate.
[ ] All new and existing tests passed.

Addresses both #117 and some aspects of #111

Also tested support for up-converting Swagger 2.0 to OpenAPI 3.0:
$ yarn workspace demo gen-api-docs all
$ docusaurus gen-api-docs all
[ReDoc Compatibility mode]: Converting OpenAPI 2.0 to OpenAPI 3.0
Successfully created "docs/twitter"
Successfully created "docs/twitter/account-settings-get.api.mdx"
Successfully created "docs/twitter/account-settings-post.api.mdx"
Successfully created "docs/twitter/account-update-delivery-device.api.mdx"
Successfully created "docs/twitter/account-update-profile.api.mdx"
Successfully created "docs/twitter/accounts-update-profile-background-image.api.mdx"
Successfully created "docs/twitter/accounts-update-profile-colors.api.mdx"
Successfully created "docs/twitter/accounts-update-profile-image.api.mdx"
Successfully created "docs/twitter/application-rate-limit-status.api.mdx"
Successfully created "docs/twitter/blocks-create.api.mdx"
Successfully created "docs/twitter/blocks-destroy.api.mdx"
...


Update zio-test, zio-test-sbt to 1.0.4-1

Updates

dev.zio:zio-test
dev.zio:zio-test-sbt

from 1.0.3 to 1.0.4-1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

labels: test-library-update, semver-pre-release

Superseded by #75.


Training Queries

@FateScript  hi thanks for opensourcing your code base i have following queries

can we train yolox s/l/m/x on lower image size ie 400x400 or 544x544 ? if so what is drop in accuracy we can expect on the coco dataset , please share your thoughts
By training yolox-x with 800x1440 i saw better detections compared to yolox-x with 640 so what was the intent of setting the image size to 640
What is the minimum number of images required for training yolox -l/m model for custom class to see promising results the custom class are medium sized objects
Thanks in adavance

We never try, for value like 400 which is not multiples of 32, you should modify code when calling interpolate to make your training works well.
Just to compare with other yolo-like model, and if you are using such a setting, maybe your train time becomes longer with smaller batchsize
For custom dataset, maybe EMA decay value is important and users should tune it carefully.


The link is wrong

The link of CREATE CERTIFICATE is wrong.

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

ID: 6b7218e8-a8de-4d10-0a6f-143180e024d1
Version Independent ID: cb2b90ac-6211-d1ae-8129-9f54ff9402b4
Content: T-SQL statements - Azure Synapse Analytics
Content Source: articles/synapse-analytics/sql-data-warehouse/sql-data-warehouse-reference-tsql-statements.md
Service: synapse-analytics
Sub-service: ****
GitHub Login: @XiaoyuMSFT
Microsoft Alias: xiaoyul

@emshimon Thanks for the feedback and bringing this to our notice. At this time we are reviewing the feedback and will update the document as appropriate.

The PR for the fix has been created and it will be merged soon. Thanks again for pointing this out, I am closing the issue based on this update, please let us know if there is something else that we can help you with.


TEMP: Graph visual

Temporary pull request until the ArrowVisual has been merged into VisPy.
This PR will contain the code for the GraphVisual.

This is starting to look like a graph:


feat(ci): Allow a commiter to run /retest to kick CI

The codecov step is very flaky and PRs are blocked because of this.

With this Github Action, users can comment /retest which should retrigger the Build and Test Workflow

needs some more work https://github.com/envoyproxy/gateway/actions/runs/5116489750/jobs/9198701312


Fix Wrongly parsed the RESP empty/null array (#633)

Now : I only fix like:
echo -e '*-1\r\n*2\r\n$3\r\nget\r\n$3\r\nkey\r\n' | nc <IP_ADDRESS> 6666
echo -e '*2\r\n$3\r\nget\r\n$3\r\nkey\r\n*0\r\n*2\r\n$3\r\nget\r\n$3\r\nkey\r\n' | nc <IP_ADDRESS> 6666
Redis can have "nil" value. like:

kvrocks also behaves the same way.(I didn't modify anything)

Cool, can you add some test cases in protocol.tcl to make sure it has already fixed.

Cool, can you add some test cases in protocol.tcl to make sure it has already fixed?

sure, that's what i should do.

Cool, can you add some test cases in protocol.tcl to make sure it has already fixed?

sure, that's what i should do.

Cool, thanks @willshS

Shall this patch fix #633?

Shall this patch fix #633?

yes


Fixed use-after-free bug in PE module

The bug was triggered by digitally signed malformed PE file (md5: fd6d7a3b087e9a0d6d4abafb47701da0).
To reproduce, run any rule that does import "pe". The bug effects may vary depending on your memory state.

Looks like fuzzing robot is missing packages:
make[1]: Entering directory '/src/yara/libyara'
YACC     hex_grammar.c
../build-aux/ylwrap: line 176: yacc: command not found
Makefile:831: recipe for target 'hex_grammar.c' failed
make[1]: Leaving directory '/src/yara/libyara'
make[1]: *** [hex_grammar.c] Error 127
Makefile:1081: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
2020-05-22 08:04:26,484 - root - ERROR - Building fuzzers failed.
2020-05-22 08:04:26,484 - root - ERROR - Error building fuzzers for project yara with pull request refs/pull/1287/merge.


Make webchimera.js a peer dependency

wcjs-renderer can work along with webchimera.js, but doesn't necessarily need it. What about listing it as a peer dependency instead of an optional dependency? After all, an optional dependency is only a regular dependency that doesn't make the dependent package install fail if its install fails...
In my case I want to use wcjs-renderer with wcjs-prebuilt, and I don't want npm to install webchimera.js as part of the install of wcjs-renderer. Of course I can use npm's --no-optional flag, but that won't go into my package.json and so that info won't be persisted anywhere... I'd be much happier with a simple warning message telling me that peer dependency webchimera.js isn't met.
Just a suggestion. Not sure what the actual best practice is here...

Actually, I feel webchimera shouldn't be a dependency at all... Specifying that the user should provide a mandatory web chimera instance to the renderer should be enough:
init(canvas, wcjs, vlcFlags, options): initiate the renderer:
canvas can be a DOM node or selector (mandatory)
wcjs is a WebChimera.js instance ex: wcjs-prebuilt (mandatory)
vlcFlags is an array of vlc parameters (optional),
options is a object mentioning if the fallback non-WebGL renderer should be used (optional),


New package: StaticRanges v0.1.0

Registering package: StaticRanges
Repository: https://github.com/Tokazama/StaticRanges.jl
Created by: @Tokazama
Version: v0.1.0
Commit: 6d3746c1ed069cc8c12c34b20ae825fb391e2449
Reviewed by: @Tokazama
Reference: https://github.com/Tokazama/StaticRanges.jl/issues/17#issuecomment-546613957

Your new package pull request does not meet all of the guidelines for automatic merging.
Specifically, your pull request does not meet the following guidelines:

The following dependencies do not have a compat entry that has an upper bound: julia, StaticArrays

It is important to note that if your pull request does not meet the guidelines for automatic merging, this does not mean that your pull request will never be merged. It just means that your pull request will require manual review by a human.

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]

Your new package pull request does not meet all of the guidelines for automatic merging.
Specifically, your pull request does not meet the following guidelines:

The following dependencies do not have a compat entry that has an upper bound: StaticArrays

It is important to note that if your pull request does not meet the guidelines for automatic merging, this does not mean that your pull request will never be merged. It just means that your pull request will require manual review by a human.

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]

Your new package pull request met all of the guidelines for automatic merging.
I will automatically merge this pull request after the mandatory waiting period has elapsed.
If you want to prevent this pull request from being auto-merged, simply leave a comment.
(If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.)

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]


Has there been some load testing on the ws-backend?

@kapv89 I did some load testing for a single instance of the ws-backend, where I have tested the operation in 2 cases:

average number of calls(5) to different documents(5) - first peak on the graphs
a large number of connections(35) to one document - the second peak in the graphs

I used a document of 24618 characters, so a large number of messages that need to be exchanged between these sockets.

I am a little concerned:

Why does the load go so heavily up if we all use the very same document? In my opinion the load should be very low, because there is just one state … for everyone.
Also, the vCPU is above 0.6 and memory increase 300 MB for just 35 users ons just one document … which is quite a lot.

A small calculation makes it hard to understand for me: 25 k characters is around 25 kb, so a really small document.
Hence, 35 Users * 25 kb = small load, yet we see such a dramatic jump in memory.
Hence, is there some way to do it more efficiently? 🙂

@kapv89 Many thanks for letting me know 🙂

@kapv89 Did you have some chance already to look into this issue.

Please let me know, if I can be of any help. 🙂

@junoriosity ...   @sbalikondwar on discord was doing some load testing on code from this repo for their company ... don't know where they reached, but if they are using code from this solution they might have some helpful insights for you

@kapv89 Sounds very interesting, could you tell me more?

They were doing some load testing stuff and were observing increasing memory .. u gave suggestion might be because of undo-log, and might clear up after connections close .. didn't connect after that .. probably reach out to him

@sbalikondwar Could you give us some input on that matter?

@junoriosity Hey, I am curious about how you conducted the load testing and which tool you used.
How did you emulate concurrent users sending WebSocket messages to the server?
I tried using k6 for this purpose, but I couldn't succeed in sending the correct message, or at least it didn't work as expected.
Could you suggest an alternative way to perform the testing?

@zyhzsh What I did is the following:

I spun up a K8s cluster
I deployed the Pod in the K8s cluster
I used to connect with many connections to one document
I inserted a large number of of images in that document
I repeated the last two steps.

That was what caused the issues I mentioned.


Optimized for autocomplete+ snippets

https://github.com/atom-community/autocomplete-snippets

note that this branch heavily depends on the package called autocomplete-snippets for it's effectiveness.
every snippet is preceded with "em" for Ember or ds for DS. the reason for that is to Namespace the snippets so they do not collide if another package defines snippets for model,view,.... of backbone or angular.
no need for --help or shorthands, thanks to the autocomplete-snippets package.
try the snippets below:
emView
emArrayController
dsModel
emComputed
,...

Awesome work, but there are still some comments regarding the changes.
I think prefixes needs more work. Some has short hand, some has underscore, some has dashes, some has both, and some had dots
For starters, lets use full names for everything. So using Ember instead of Em, and classNames instead of cleassN`, ...etc and so on for the other cases.
For separating the words, I don't think it's a good idea to use underscores, it's not really a JavaScript convention, so i'm leaning more toward matching syntax with the function itself. That means using CamelCase to call FixureAdapter and so on for the rest of prefixes.
For case that require use of dot, lets use dot. like computed.or
For using DS, and Ember. I don't agree that we have to namespace it. Unless there is a conflict locally, we should use direct function names. For Angular and other users, I think that would be a rare case to stumble upon. And in that instance, they can disable this snippet.
For es6, it should be import-ember instead es6, because it's a snippet for import. import in this case would be custom. Also there is no need to have export default snippet.
So as a rule, lets just match the prefix with the real syntax. And if we can avoid using DS or Ember, that would be even better. It will match people's expectations
Also, there should be maximum of one line spacing between text lines in all files.

On the last commits I changed all of them to _ underscores.
And prefixes are now all uniform and consistent,
em_view_...
em_route_...
...

Awesome, but still. As I said above. It's better to match the prefix to the real sytanx of what people would write.

I too think that em_ is pretty nasty but as a global package, huuum we have to have something special.
For my personal use I remove it without mercy.
but route, view, controller is common in backbone too.
Any way, if you think it is better to remove them, feel free to edit them on your own.

I first tried with the dot syntax em.view.somthing but the auto completion  did not worked with dot properly.
so I chose the underscores.

For webstorm and phpstorm I do change it to dot syntax since it works there,

sorry I forgot to upload the local changes of route.cson file.

I think it is safer to follow the community demand of namespace and provide an optional wrapper.cson file to translate "computed_or" to "em_computed_or" for the users to use. and put the instructions of add wrapper.cson in the README file.
since we live a in crowded world, nowadays, it is likely to have these conflicts around.
And we are forced to use namespaces. ;)

I understand your point of view, but I still think the number of people who are using Ember with other MVC is pretty small, not to change the entire naming for that. If i'm wrong and the number is higher or got higher, people will complain, and then we can add namespacing. But for the majority now. Ember should be first class citizen and should be treated as such

Ok, I upload the em_ removed version on a new branch. in a few minutes.
and Note that I hear Ember experts tell that views are used rarely and apps.

Please don't open another branch

Let's just keep things consistent here

They are ready, I think.
Just forgive me about the extra linebreakes.
I remove them in future commits.
They now cause no overload.

I tried to group all adapters under the adapter keyword,
when the user need an adapter he simply type adap... and him will be offered with 3 types and chooses one.
ok, I also provide the other prefix to.
Good idea.

Again, Happy to have you as a teammate.
your comments drove the project to reach a very good point.
I continue to work on this with the accepted principals.


Update CPack packaging for ROCm release support

Look for ROCM_LIBPATH_VERSION environment variable to patch the CPACK_PACKAGE_VERSION.
Add some status logs to output packaging information.

Thanks for the feedback. I can make these changes in a future update.


How to BCH address By publicKey?

How to BCH address By publicKey?

Ew
Best Regards,
Peter Denton
3.4u Inspection Engineer
+62(0)81236623884

On Oct 31, 2018, at 17:15, QA411<EMAIL_ADDRESS>wrote:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Most stable version

Hi,
I want to build an OCR project on top of your project. Can I know the commit ID of most stable version?
Thanks.

Hey, thanks for your message, I'm happy to know you find it useful. Yes, you can build OCR app, you can add your own services by replacing current sample services under 'services' package.
The current code is stable, I will create a release soon. You can use the current latest version.
We will be using this infra to build ML apps on top of it. I thought it is good to share the infra with the community :)

Hey, thanks for your message, I'm happy to know you find it useful. Yes, you can build OCR app, you can add your own services by replacing current sample services under 'services' package.
The current code is stable, I will create a release soon. You can use the current latest version.
We will be using this infra to build ML apps on top of it. I thought it is good to share the infra with the community :)

It is really helpful indeed. I really love the way you have organised the docker containers

I created release tag, this way is simpler to find stable version: https://github.com/katanaml/katana-skipper/releases/tag/v1.0.0

Hey, thanks for your message, I'm happy to know you find it useful. Yes, you can build OCR app, you can add your own services by replacing current sample services under 'services' package.
The current code is stable, I will create a release soon. You can use the current latest version.
We will be using this infra to build ML apps on top of it. I thought it is good to share the infra with the community :)

It is really helpful indeed. I really love the way you have organised the docker containers

I created release tag, this way is simpler to find stable version: https://github.com/katanaml/katana-skipper/releases/tag/v1.0.0

Awesome. I have started development here https://github.com/gov-ai/thinking


Ambiguous match when there are multiple select2 elements

#37 changed the code which finds the select2 input from using first to using find. Unfortunately Capybara chokes when it can't find a unique element with find - which happens when you have more than one select2 element in the page:
Failure/Error: fill_event_fields_with_valid_data Capybara::Ambiguous: Ambiguous match, found 2 elements matching css ".select2-container"

I don't really understand enough about the issue that #37 fixes to know what the solution should be.
(cc @machisuji)

The code in  "capybara-select2/gem/lib/capybara-select2.rb" has a section with "if options.has_key? :search" that uses only a find command to select the element, no use of first to resolve the ambiguous matches.
Note that if i have "name" and "city name" i am in the case of an ambiguous match.

This can be fixed by having find(..., match: :first)

So would it be fixed by using a more specific selector when you have two select2s? I.e.
select2 'value', css: '#selectid'

@machisuji What you're saying is probably correct. The older first is just better represented as find(.., match: :first) if we want to keep the old behavior.

Hmm. I actually agree with @machisuji - it is an ambiguous match, so the current behaviour is correct.
I guess it's arguable whether this change is breaking or a bugfix ;)
I think if there's a 'fix' to be made at all then it would be to add a message into the error suggesting using the :css or :match options for a more specific match.

I'm having the same issue when I have the search: true option enabled in combination with other select2 instances on the page (with either multiple: true or not). When the code is looking for the search__field, it finds multiple items because it searches the search field on the whole page, instead of the drop container. I get the following error:
Capybara::Ambiguous:
       Ambiguous match, found 3 elements matching css ".select2-search input.select2-search__field"

I think this could be fixed by seaching for the search__field in the select2-container:
select2_container = find(:css, '#select2_enabled_field_id + .select2-container')
select2_container.find(".select2-selection").click
find('body > .select2-container .select2-search input.select2-search__field').set('search_query')
page.execute_script(%|$("body > .select2-container input.select2-search__field:visible").keyup();|)
drop_container = "body > .select2-container .select2-results"
find(:xpath, "//body").find("#{drop_container} li.select2-results__option[role=treeitem]", text: 'search query').click

Note that I have incorporated the fix of abuisman for properly selecting the result items when using optgroups: https://github.com/goodwill/capybara-select2/pull/47

I had the same issue when I had the search: true enabled in conjunction with another select2 element. I got the same error as above:

Capybara::Ambiguous:
Ambiguous match, found 2 elements matching css ".select2-search input.select2-search__field"

I got around this by monkey patching the gem and adding in the extra class .select2-container--open to the find as so
find(:xpath, "//body").find(".select2-container--open .select2-search input.select2-search__field").set(value)

This worked a charm for me, and haven't investigated if this extra class will work for different versions of select2 but might help others


Prepare sample trigger and info on FHIR List for referral

Text of email sent to Jeremy:
See the attached sample of a FHIR List resource that we would like to be used for subscription notifications that you produce from Athena.  This is a very simple example template and fully valid per the FHIR spec:
http://hl7.org/fhir/R4/list.html
JSON file attached and copied inline below.  I included a reference to the Patient (or multiple Patient resources) that are connected with the list of ServiceRequest resources.  Including the Patient ref is optional, but will be helpful in our referral handler to use for sending other queries, e.g. for Condition or MedicationRequest.  If not included, we can extract the Patient from each ServiceRequest.
Let me know if you have any questions.
{
"resourceType": "List",
"id": "821ea3c1-011f-4f70-a8ae-299043b7e0be",
"status": "current",
"mode": "changes",
"date": "2023-10-09T22:17:00+11:00",
"entry": [
{
"item": {
"reference": "Patient/2001157662078660"
}
},
{
"item": {
"reference": "ServiceRequest/2009624124426130"
}
},
{
"item": {
"reference": "ServiceRequest/2008836135127130"
}
}
]
}


[Beta 1.0.3] After creating second calendar set of notes I no longer can open open daily note

I created new set of notes, with daily notes enabled.
My previous note set was still my default. Since that moment I no longer  can oopen daily note, even after I removed the newly selected calendar set; I check the paths and they seem ok, I still can open  weekly notes from this calendar set
Obsidian 0.14.6, Periodic Notes 1.0.3beta
Edit: After reinstalling everything works ok, even the second calendar set creation
BTW I installed it via Brat,  the data file inside plugin folder  shows me "1.0.0-beta1" while in obsidian community menu I see ""1.0.0-beta3"

Hi, I think you did uncover a bug. The plugin was not properly unloading, so when you upgraded, it didn't apply the new version until after the restart. I created a separate ticket just now to make sure that gets fixed in the next version:https://github.com/liamcain/obsidian-periodic-notes/issues/105


pull request for e2e test at 12/05/2016 05:45:07

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Convenience methods for manual derivation

Peeling off the layers of an AttributeValue is not necessarily the best thing in life 😁 Nor is it "functional" in any way. We should aim to make writing custom DynamoFormat instances a breeze.

Yes of course! Let's say one has a simple case class they'd like to derive:
case class A(foo: Int, bar: String)

I'd like to manually write a format using applicative style, something like:
val format: DynamoFormat[A] = DynamoFormat.withObject { obj =>
  obj.int("foo") <*> obj.string("bar") <@> A
} { a =>
  DynamoFormat.int(a.foo) :: DynamoFormat.string(a.bar)
}

It is annoying that we don't have separate DynamoEncoder and DynamoDecoder typeclasses, perhaps we should think about that.
One would have to think about all the cases: default values, derived fields, ADTs, etc. Not an easy task, but we can use this ticket to design the API. The good news is we already provide a hole of base types, all we need is expose them and add some syntactic sugar around it.

This exercise is very much the same as encoding/decoding JSON, so I picked directly from the Aeson playbook. Assuming some convenience types and methods we can elaborate on later, I'm seeing something like this:
object DynamoFormat {
  def derive[A]
    ( d: Option[A],            // ^ default value
    , decode: DynamoDecoder[A] // ^ parser over AttributeValue
    , encode: A => DynamoValue // ^ value encoder
    ): DynamoFormat[A]
    = ???
}

Decoding
DynamoValue is a pure equivalent of AttributeValue:
sealed abstract class DynamoValue { self =>
  def toAttributeValue: AttributeValue = ???
}

object DynamoValue {
  case object DNull extends DynamoValue
  final case class DBool(b: Boolean) extends DynamoValue
  // etc.
}

DynamoDecoder[A] is where most of the fun is, and it has to provide all the usual suspects:
class DynamoDecoder[+A] { self =>
  def map[B](f: A => B): DynamoDecoder[B]
  def flatMap[B](f: A => DynamoDecoder[B]
  def zip[B](that: DynamoDecoder[B]): DynamoDecoder[(A, B)]
  def ap[B](f: DynamoDecoder[A => B]): DynamoDecoder[B]
  // ...
}
object DynamoDecoder {
  def apply[A](value: A): DynamoDecoder[A]
  def fail(error: DynamoReadError): DynamoDecoder[Nothing]
}

I'm not sure yet what its concrete elaboration should be, but probably a function DynamoValue => Either[DynamoReadError, A] would be a good start.
In my previous comment I was using the scalaz syntax, which has been deprecated in cats. Since this package relies on the latter, its more verbose syntax should be adopted instead, i.e.:
val decoder: DynamoDecoder[A] =
  DynamoDecoder.withObject { obj =>
    ( obj.int("foo")
    , obj.string("bar")
    ).mapN(A)
  }

trait DynamoDecoder {
  def withObject(f: DynamoObject => DynamoDecoder[A]): DynamoDecoder[A]
}

Encoding
This part is much easier. Most case classes will be encoded as maps, so we should have a convenience for doing so:
object DynamoFormat {
  type KeyValue = (String, DynamoValue)
  def object(p: KeyValue, ps: KeyValue*): DynamoValue = DObject(Map(p, ps))
}

The missing piece is a function to lift values to dynamo values:
object DynamoFormat {
  implicit def toDynamoValue[A](pair: (String, A))(implicit D: DynamoFormat[A]): (String, DynamoValue) = (pair._1, D.write(pair._2))
}

How does this look?

Thanks for the explanations. I now have a better understanding what we're aiming for but I still need to look into this in more detail. I don't have much experience in this kind of FP tasks, may need some time to get comfortable with it :)

I have started working on this and am close to something that works. The decoding part is ongoing. Will raise a PR soon.

Nice, I'm looking forward to see your solution 😊


Jan 2023 Jazz Master merge

This looks like a big PR, and it's very outdated. Is it important to bring over upstream changes/improvements/security fixes?
I ask because I really want there to be a standard, maintained, and secure JWT package for django-ninja. It would be a shame for it to fall out of date/become insecure. ❤

This looks like a big PR, and it's very outdated. Is it important to bring over upstream changes/improvements/security fixes?
I ask because I really want there to be a standard, maintained, and secure JWT package for django-ninja. It would be a shame for it to fall out of date/become insecure. ❤

This PR is up for the same reason, security updates. I am have been reviewing changes on the PR and it has been all CI action or test improvements or translation file updates. Unless I am missing something. But once there is a security change, I would reflect in master.


make it possible to auto-execute some cells according to a query

Sometimes we hide the import block of notebooks in the rendered web page to improve the tidiness of the page. However, if you're using something like thebelab, this means that users don't have the ability to actually run that code block and thus the code won't run. Is it possible to auto-run some cells (e.g. ones that are hidden) according to a jquery match? (e.g. pre.run)? This might be useful for this use case!

See https://github.com/jupyter/jupyter-book/pull/352 for an implementation of this, in that case I'm actually just simulating "click" events on the thebelab buttons so that the cells have their outputs etc populated


ensure block signal doesn't exceed SIGRTMAX

a runtime check like this is recommended by signal(7)
note: setupsignals() was moved to the top of main to avoid the need for
a cleanup() when erroring out

done. Thanks!

You should be able to delete the check if (block->signal > 0) at the end of the signal setup since you are now checking it above.
Here: https://github.com/ashish-yadav11/dsblocks/blob/master/dsblocks.c#L120


App service in Azure stops responding - libuv reports EOF error

Issue Title
App service in Azure stops responding - libuv reports EOF error
General
I have app services built using dotnet core 2.0 and visual studio 2017 and running on azure. Sometimes they stop responding with the following error in the logs:
2018-01-21 20:53:34.893 +00:00 [Error] Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv: ListenerPrimary.ReadCallback
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.UvException: Error -4095 EOF end of file
at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.LibuvFunctions.ThrowError(Int32 statusCode)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.ListenerPrimary.PipeReadContext.ReadCallback(UvStreamHandle dispatchPipe, Int32 status)
During that time no other transaction is logged, so there is no traffic in the app service at that time.
A restart of the app service fixes the error.

@cgenin7 did you achieve anything regarding this topic?
Ran into the same issue with dotnet core 2.0 and visual studio 2017, just like you.
Would be very helpful :)

Unfortunately no. I submitted the error to the Azure team and they asked for a memory dump. I will provide one if the problem reappears but it did not occur again yet.

Thank you for your answer, your post solved the issue for the moment

You can try moving your app services to local cache, if nothing is stored locally with your application. They seem to have issues moving the app services around when this mode is not enabled:
https://docs.microsoft.com/en-us/azure/app-service/app-service-local-cache

Thank you for your answer, it solved the issue for the moment.
I will try :+1:

@Eilon @muratg

@halter73 @davidfowl @jkotalik - any ideas on this? Kestrel issue? Libuv? Other?

Closing as it looks like the conversation was continued with the Azure folks.


release cleanup

Cleaned up an bug fixes for release;

Portability bug fixes
Refactored both EVMAsm and the CLI
Added instruction LUT
Reviewed and updated documentation
Added support for binary output (not really sure it's useful but it's there)

Nice! What's the story on the read the docs link?

Added, should be generated once it's merged into master. The webhook may need to be setup manually due to permissions. Also added you as a maintainer on rtd.


BindToChainState did not update its ChainTypes.ChainAccountsList component

Summary: Basically, I found the decorator's this.chain_accounts_list is empty at the time some chain store data came in and that it did not update its component leaving the UI empty.

Uncomment BindToChainState's console.log("-- Wrapper.update -->", this.chain_accounts_list)
set DEBUG = true in ChainStore

Create a wallet (or keep your existing one) then goto http://localhost:8080/#/wallet/brainkey and enter a brainkey that will resolve with at least one account.  Observe in the console that in the very end, the ChainStore will log full_account:  and your account(s) then nothing else.  At that point I followed its call to updateSubscribers (enabled a breakpoint) and trapped again in BindToChainState's update.  It receives that event, however its this.chain_accounts_list is be empty to it will not pass along the data to its component.  The accounts do not show up in the browser's UI.
Optional (fyi): trigger a re-render and the accounts will display.  One way to do this is to run:
resolve(WalletManagerStore.onDeleteAllWallets()); iDB.root.deleteDatabase(true);

Sorry, forgot to tell you about additional parameter to the decorator: keep_updating, use it like this:
@BindToChainState({keep_updating: true})
This parameter affects a small optimization - without this parameter decorator stops after it gets all its initial objects resolved, e.g. first time your accounts list is empty or has one account, it retrieves account and marks its state as resolved, later you add more accounts to the list but it won't proceed unless keep_updating is true.
I should have documented this..


Will the site ever work again?

As the title says, I want to know if it is possible to get the site working again. I know it's a short time to ask, but I don't have any information about it and I don't know how to get it either. I used to use this site a lot, it was much easier than using the original program.

Sorry, the domain expired 🥲
You can use this link that points directly to the heroku instance https://creamapidb.herokuapp.com/
I should probably update the readme.


Document API evolution strategy

Uplifting https://github.com/near/near-sdk-rs/pull/366#issuecomment-823984897 to an issue:

This is going to break legacy code. log! serves the purpose.

Do we have our backwards compatibility policy for SDK documented anywhere? Taking a bird's eye view, the current public API of SDK feels like it has a lot of rough edges from Rust API design point of view, and it seems like long term smoothing those out would be beneficial. However, it's unclear to me at least what is the best path towards that.
I can see several options for this particular change, and for this class of changes:

do nothing and consider the API frozen / append only
keep the current major version, but use deprecation to slowly clean-up the API (so, apply #[deprecated] & #[doc(hidden)] attributes to the log function, introduce log_str, re-implement log in terms of log_str)
use release trains: release a point release which deprecates log function now, and release a new semver-incompatible version not-to-far in the future, which adds log with the correct signature.
prepare for "big-bang" style next major version (don't implement this right now, but add a BreakingChange label and release a new version when we accumulate a bunch of those).
re-design the API from the first principles, using the lessons learned, but not the code, from the existing sdk (aka "don't tell Joel Spolsky")

Neither of them is inherently better than the other (even the last one can be beneficial in the exceptional circumstances), but it's unclear which one we use.

My current take:
We have three large classes of consumers of the sdk -- near core contracts, existing folks who already build on near, new folks who are just starting to use near.  Crucially, because of the second group, we just can't change the APIs left and right.
I also feel that the API cleanup work is high-value -- it's not like we need to cleanup a couple of methods, we have entire types which do not make much sense for an abstract well-defined sdk (like gas being just a type alias rather than a newtype, or ValidAccountId existing).
So my proposal would be:
First and foremost, do internal API preserving cleanups first (#372, #373) as, at the moment, it's hard to say what our public API even is. It's unclear what exactly is exposed here, for example:
https://github.com/near/near-sdk-rs/blob/97fc632fcc58eb7ff7faad0be54ea8ec91dbf694/near-sdk/src/lib.rs#L26
Then, I think we should prioritize cleaning up the API in place -- add better APIs, mark old APIs as deprecated, release new semver compatible versions. That way, new users get nice APIs, and existing users can upgrade at their own leisure. To future-proof new API's, we might add them under unstable cargo feature first, and dogfood in the core contracts.
Some time in the future, we probably should cut one major release removing the deprecated cruft, and then commit to supporting that major version for quite some time.

I've just realised that I've conveniently squatted https://crates.io/crates/near, and, in terms of rust API, near::log, near::storage_read etc look sweat. So, if we decide to do a big cleanup some day, rebranding near-sdk as near and rewinding the major version back to 1 is an option!

We should maybe be more explicit with our plan, but it has been shaping up as following this pattern:

keep the current major version, but use deprecation to slowly clean-up the API (so, apply #[deprecated] & #[doc(hidden)] attributes to the log function, introduce log_str, re-implement log in terms of log_str)

For ease of transition from current contracts. There seem to be some fundamental changes that come with needing to minimize contract size and overall structure, but this might need to come with an API redesign, which might make sense to migrate over to the near crate if this happens.

To summarize what happened, we burned a new major version 4.0 and didn't make any state-breaking changes. At all costs we will avoid silently breaking state (like in https://github.com/near/near-sdk-rs/pull/745 which throws an error for breaking pattern). All APIs will aim to maintain Rust's semver. Most APIs migrated slowly with deprecations, even through the major version.
Perhaps it would be valuable to convey this in the README or otherwise


Rogue Dedication backstab damage

The addtional damage for the backstabber feat does not appear to be being rolled.
This appears to be an issue if the player has the "target is flat footed" flag ticketed on the character sheet.  We have not tried with the auto detect flat footed so far

This was fixed in the latest system update.


How should I redevelop the project?

Hello,
I really like this project, but the layout is different from what I want, how should I start debugging locally? I don't see any instructions that can be used.
Thanks.

@AGDholo
Sorry for my late response. Maybe you can redevelop this project by following steps.

git clone this repo
cd example
edit package.json

- "vuepress-theme-blog-vuetify": "^1"
+ "vuepress-theme-blog-vuetify": ".."

npm install
npm run dev
you can see the site at http://localhost:8080
after you modified some theme files, you have to stop dev-server and run npm install each time

Thanks.


PID associated with a packet

Is there way of finding out the process ID associated with the packet?
Thank you.

As far as I know process ids are not included in the .pcap or .pcap-ng file formats. Please provide references if you know they are.


mismatched-arg-count on a compiling code

Cut from #6975.
It is very possible that I am screwing something up (since I am new to Rust and new to rusqlite and its doc is a bit lacking), but nevertheless I get red alert on code which compiles in cargo.
Here's a small compiling version:
use rusqlite::{Connection};
fn main() {

    let conn = Connection::open( "test.sql" ).expect( &format!("Fail to open db") );
    let mut sth = conn.prepare( "SELECT id,a1,a2,a3,a4,a5,a6,a7 FROM table WHERE name=?1" ).unwrap();

    let mut rows = match sth.query( &[ &"joe" ] ) {
        Ok(r) => r,
        Err(e) => { panic!("Cannot retrieve record: {:?}", &e); }
    };

    loop {
        let r = rows.next();
        match r {
            None => break ,
            Some(r) => match r {
                Err(e) => { panic!("Error retrieving row: {}", e) }
                Ok(r) => {
                    println!( "{:20} {:<10}  {:>20}→{:>20} {:15} {:15}⇒{:15} {:15} {:20} (c{})",
                        r.get::<usize,String>(5), r.get::<usize,String>(1),
                        r.get::<usize,String>(2), r.get::<usize,String>(6),
                        r.get::<usize,String>(3), r.get::<usize,String>(4), r.get::<usize,String>(7), r.get::<usize,String>(8), r.get::<usize,String>(9), r.get::<usize,String>(10)
                    );
                }
            }
        }
    }
}

I get complaints for "r.get::<usize".
My fragment behave pretty diferently in playground: in my version Row.next() gives Option<Result<Row, Error>> while playground get the (way more possibly correct) Result<Option<&Row<'_>> and thus fails to build.
[update]
Aww. rusqlite v0.6.0 vs v0.24.0. Former uses the "old bad" result, my code used that. Now I upgraded my local version to the one playground uses and the result magically reversed (result->option->row). So my version worked under 0.6.0 and gave the error there. I'll rewrite to see how it behaves under new one.
(If you happen to be available on Matrix then I'm sitting in the Rust room, if you'd like to do some transient chat/questions.)

This one compiles in the playground and gives the same error in analyzer.

This is a weird one... Here's a reproduction without rustqlite:
struct Row;
impl Row {
    fn get<A, B>(&self, x: usize) -> &str { "" }
}
fn main() {
    let r = Row;
    println!("{}", r.get::<usize,String>(5));
}

It turns out the macro expansion is completely broken:
{
  $crate::io::_print(std::fmt::Arguments::new_v1(&[], &[std::fmt::ArgumentV1::new(&(r.get::<usize),std::fmt::Display::fmt),std::fmt::ArgumentV1::new(&(String>(5)),std::fmt::Display::fmt),]));

}

It's splitting the call along the comma, taking r.get::<usize as one parameter and String>(5) as a second.

Same happens with assert!.


Create function loses content

Elements, created via constructor in elementOpen or elementVoid, lose their text/content:
import { elementVoid, patch } from "incremental-dom";

function render() {
  elementVoid(foo);
}
function foo() {
  let foo = document.createElement("div");
  foo.innerHTML = "foo";
  return foo;
}

let el = document.createElement("div");
patch(el, render);

console.log(el.textContent) // ''

Open in Sandbox.
Is that expected behavior?

Since textContent is really a child Text node, it is cleared by elementClose / elementVoid, since those see that there is a child present that was not declared in the render function. The skip() function can be used to tell Incremental DOM to skip over the children instead of removing them. Adjusting the example above, this would look like:
import { elementOpen, elementClose, skip, patch } from "incremental-dom";

function render() {
  elementOpen(foo);
  skip();
  elementClose(foo);
}
function foo() {
  let foo = document.createElement("div");
  foo.innerHTML = "foo";
  return foo;
}

let el = document.createElement("div");
patch(el, render);

console.log(el.textContent)

Another option, if the browsers you need support have it, is to look into using Shadow DOM.
import { elementVoid, patch } from "incremental-dom";

function render() {
  elementVoid(foo);
}
function foo() {
  const foo = document.createElement("div");
  const sr = foo.attachShadow({mode: 'open'});
  sr.appendChild(document.createTextNode('foo'));
  return foo;
}

let el = document.createElement("div");
patch(el, render);

// Note, since the text is in the Shadow Root, it is not `textContent`

Thank you. That's exhaustive answer.


Run some junit5 tests

C:\Users\yuri\workspace\okhttp>.\gradlew.bat native-image-tests:nativeImage

> Task :native-image-tests:nativeImage
[ConsoleLauncher:868]    classlist:   3,514.88 ms,  0.96 GB
[ConsoleLauncher:868]        (cap):   2,183.82 ms,  0.96 GB
[ConsoleLauncher:868]        setup:   3,632.89 ms,  0.96 GB
[ConsoleLauncher:868]     (clinit):     409.14 ms,  3.26 GB
[ConsoleLauncher:868]   (typeflow):   9,906.87 ms,  3.26 GB
[ConsoleLauncher:868]    (objects):  10,420.79 ms,  3.26 GB
[ConsoleLauncher:868]   (features):     797.63 ms,  3.26 GB
[ConsoleLauncher:868]     analysis:  22,098.08 ms,  3.26 GB
[ConsoleLauncher:868]     universe:     758.45 ms,  3.26 GB
[ConsoleLauncher:868]      (parse):   1,939.70 ms,  4.21 GB
[ConsoleLauncher:868]     (inline):   1,942.67 ms,  6.35 GB
[ConsoleLauncher:868]    (compile):   7,297.82 ms,  6.34 GB
[ConsoleLauncher:868]      compile:  12,698.60 ms,  6.34 GB
[ConsoleLauncher:868]        image:   2,511.73 ms,  6.35 GB
[ConsoleLauncher:868]        write:     344.56 ms,  6.35 GB
[ConsoleLauncher:868]      [total]:  45,725.69 ms,  6.35 GB
native image available at build\graal\ConsoleLauncher.exe (44 MB)

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.


The connection to the server localhost:8080 was refused

when i run helm install alpine,the errors come out:
The connection to the server localhost:8080 was refused - did you specify the right host or port?
[ERROR] Failed to upload manifests: exit status 1
i exec this commad at my own host not in my kubernetes cluster.
any one can help me?

got it ,only to set an env var KUBERNETES_MASTER ,that's it.


Add option to select a subset of GCM-RCM combinations

Currently, the script runs through all GCM-RCM combinations. We want an option to select a subset of these.
#get list of RCMs
RCMLIST=`ls $filedir_EQM`
#RCMLIST=`ls /lustre/storeC-ext/users/kin2100/NVE/EQM/`

echo "Found the following RCMs:"
echo $RCMLIST | tr " " "\n"

for RCM in $RCMLIST; do
...

Oskar og Sigrid fant lur måte å legge inn modeller i argumentet til funksjonen.


operator percona-xtradb-cluster-operator-certified (1.15.1)

/pipeline restart operator-hosted-pipeline


Remember selected tab on the wallet page

Close #590
Updated the wallet detail page to remember the selected tab and navigate to it when the page is revisted

I have updated the Wallets page to track the expanded asset type and expand it on page revisit.


How to change subtitle font family?

It seems mpv.conf does nothing. I can change subtitle size from UI but how to change the font family to another font?

Just figured it out. You need ot add sub-ass=no. Then the settings will work:
mpv.conf:
sub-font='Netflix Sans Medium'
osd-font='Netflix Sans Medium'
osd-font-size=22
sub-font-size=28
sub-color="#FFFFFFFF"
sub-border-color="#FF262600"
sub-border-size=0
sub-shadow-offset=1
sub-shadow-color="#33000000"
sub-spacing=0
sub-ass=no

Thanks! It works


Insertion time recordings

Change structure of playout_config 'interleaves' to use a map keyed by the recording sequence
(recoding sequence is 1-based so the first recording key is "1")
Read target hash info and extract audio and video segment durations (replace hardcoded values).
Bonus:

verify that the target hash is a VoD playable object (by verifying the content type and existence of meta /offerings)

Example live_recording/playout_config:
  "playout_config": {
    "interleaves": {
      "1": [
        {
          "audio_abr_duration": 1.9969160997732427,
          "duration": 100,
          "insertion_time":<PHONE_NUMBER>408722,
          "playout": "/qfab/hq__6Xqy1zQfdy8F3Uead43SEw3hGHkrd5LtdgnYSxc1QbsmLwXWG25NCCZAWnedRYhg4KMDgwozow/rep/playout",
          "video_abr_duration": 2.002
        },
        {
          "audio_abr_duration": 1.9969160997732427,
          "duration": 100,
          "insertion_time":<PHONE_NUMBER>351501,
          "playout": "/qfab/hq__6Xqy1zQfdy8F3Uead43SEw3hGHkrd5LtdgnYSxc1QbsmLwXWG25NCCZAWnedRYhg4KMDgwozow/rep/playout",
          "video_abr_duration": 2.002
        },
        {
          "audio_abr_duration": 1.9969160997732427,
          "duration": 11,
          "insertion_time": 1492.917000055313,
          "playout": "/qfab/hq__6Xqy1zQfdy8F3Uead43SEw3hGHkrd5LtdgnYSxc1QbsmLwXWG25NCCZAWnedRYhg4KMDgwozow/rep/playout",
          "video_abr_duration": 2.002
        }
      ]
    },
    "rebroadcast_start_time_sec_epoch": 0,
    "vod_enabled": false
  }

The help for ad insertion is not correct:
./elv-stream
Eluvio Live Stream CLI

Usage: elv-stream <command>

Commands:
  init <stream>                            Initialize media and DRM
                                           configuration for the stream object.
  create <stream>                          Create a new live stream for this
                                           stream object.
  terminate <stream>                       End the current live stream for this
                                           object.
  start <stream>                           Start or resume current live stream
                                           if not running.
  status <stream>                          Status of the currently active live
                                           stream.
  reset <stream>                           Reset the currently active live
                                           stream.
  stop <stream>                            Pauses the currently active live
                                           stream.
  insertion <stream> <time> <target_hash>  Pauses the currently active live
                                           stream.

Options:
      --version  Show version number                                   [boolean]
  -v, --verbose  Verbose mode                                          [boolean]
      --help     Show help                                             [boolean]


HBASE-25768 Support an overall simple and fast balance strategy for St…

…ochasticLoadBalancer

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 21s
master passed

+1 :green_heart:
compile
3m 47s
master passed

+1 :green_heart:
checkstyle
1m 10s
master passed

+1 :green_heart:
spotbugs
2m 37s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 16s
the patch passed

+1 :green_heart:
compile
3m 45s
the patch passed

-0 :warning:
javac
0m 31s
hbase-balancer generated 4 new + 17 unchanged - 0 fixed = 21 total (was 17)

-0 :warning:
checkstyle
0m 11s
hbase-balancer: The patch generated 2 new + 75 unchanged - 1 fixed = 77 total (was 76)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
15m  6s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
2m 41s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

45m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4252

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 66e7175452ef 5.4.0-96-generic #109-Ubuntu SMP Wed Jan 12 16:49:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0d7638d66d

Default Java
AdoptOpenJDK-1.8.0_282-b08

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-balancer.txt

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-balancer.txt

Max. process+thread count
60 (vs. ulimit of 30000)

modules
C: hbase-balancer hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  5s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 43s
master passed

+1 :green_heart:
compile
1m  1s
master passed

+1 :green_heart:
shadedjars
3m 41s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 42s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 36s
the patch passed

+1 :green_heart:
compile
1m  1s
the patch passed

+1 :green_heart:
javac
1m  1s
the patch passed

+1 :green_heart:
shadedjars
3m 38s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 38s
the patch passed

_ Other Tests _

-1 :x:
unit
11m 27s
hbase-balancer in the patch failed.

-1 :x:
unit
176m 39s
hbase-server in the patch failed.

207m 13s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4252

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 24d79df3bd17 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0d7638d66d

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-balancer.txt

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/testReport/

Max. process+thread count
3089 (vs. ulimit of 30000)

modules
C: hbase-balancer hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  6s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 30s
master passed

+1 :green_heart:
compile
1m 20s
master passed

+1 :green_heart:
shadedjars
5m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 53s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 22s
the patch passed

+1 :green_heart:
compile
1m 19s
the patch passed

+1 :green_heart:
javac
1m 19s
the patch passed

+1 :green_heart:
shadedjars
5m 24s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 49s
the patch passed

_ Other Tests _

-1 :x:
unit
12m 38s
hbase-balancer in the patch failed.

-1 :x:
unit
246m 23s
hbase-server in the patch failed.

284m 15s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4252

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2031b033a1bf 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0d7638d66d

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-balancer.txt

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/testReport/

Max. process+thread count
2284 (vs. ulimit of 30000)

modules
C: hbase-balancer hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4252/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Update typo/bad link on Functionality.md

link to the tutorial was in correct. when clicking on the original value, received 404 error. This checking fixes issue.

thank you!


add subset for 'tigre'/'astra'

Added DataOrder class containing the list of data-order by engine types, and static functions to return the correct order of labels, and to check the order of labels.
closes #773

As discussed with @jakobsj  reorder() now takes one argument order which can be a list of axis names or a string 'astra' or 'tigre'

As discussed with @jakobsj  reorder() now takes one argument order which can be a list of axis names or a string 'astra' or 'tigre'


Add new Client Gateway

Closes #99
This PR:

Adjusts the CGW expected port on the Nginx configuration.
Points the Docker Compose image for the CGW to the new image.
Adds the minimal required configuration and some related documentation in cgw.env.

@hectorgomezv Sorry I introduced a conflict when merging a previous PR.
Also, could you update README information for the hooks on https://github.com/safe-global/safe-infrastructure/blob/main/docs/running_locally.md#step-4-add-your-webhooks ?

@hectorgomezv Sorry I introduced a conflict when merging a previous PR.
Also, could you update README information for the hooks on https://github.com/safe-global/safe-infrastructure/blob/main/docs/running_locally.md#step-4-add-your-webhooks ?

Thank you @Uxio0! The conflict was solved. I've also included some changes in the runnning_locally.sh file regarding the environment variable naming change in the new CGW (AUTH_TOKEN instead of WEBHOOK_TOKEN).

Perfect @hectorgomezv
@mshakeg This new client gateway is ready for arm64 so it should work out the box in your environment

I've detected a problem with the new Client Gateway validation when dealing with a local setup. When uploading a logo image for a chain, the Config Service stores something like:
      "nativeCurrency": {
        "name": "Matic",
        "symbol": "MATIC",
        "decimals": 18,
        "logoUri": "/media/chains/137/currency_logo.png"
      },

This doesn't pass the new CGW validation because the logoUri is not considered a valid URL:
...
 message":{
  "arguments":[],
  "code":42,
  "detail": [{
    "instancePath":"/nativeCurrency/logoUri",
    "message":"must match format \"uri\"",
    "schemaPath":"native-  currency.json/properties/logoUri/format",
  }]
"message":"Validation failed"}
...

What's your take on this? (cc. @fmrsabino @Uxio0) Should we relax the CGW validation checks for this field?

Not a strong opinion here, this was done to allow people without a DNS or S3 to upload and manage images, let's see @fmrsabino take on this

I have an update on this, I tried to use the incoming request data to compose an absolute URL in the Config Service response. This is the branch with the change: https://github.com/safe-global/safe-config-service/compare/main...return-native-currency-absolute-uri
But this also leads to unwanted effects when using Docker, because the request origin is the Nginx container, so the value that the Config Service container sees as origin is http://nginx/, and the composed value get converted to http://nginx/media/chains/137/currency_logo.png. This passes the CGW validation, but the URL is not valid outside the Docker network.
Another workaround might be accessing the correct path (http://localhost:8000/cfg/...) by using environment variables inside the container, but I suspect this path could lead us to code custom logic for running the service with/without Docker, which would add too much complexity and modify the production code to adapt it to the local setup.
Any thoughts? I think the easier way right now is to relax the CGW validation, but I don't have a strong opinion on it. Do you think another path is preferable @Uxio0 @fmrsabino ?

Setting MEDIA_URL to http://localhost:8000/ will not work?

Setting MEDIA_URL to http://localhost:8000/ will not work? (just guessing, never tried that)

I was also planning to try that one (thanks for the suggestion!). But I saw this also breaks links to the static content, but I'm checking and that behavior was already the case in the Docker setup before this PR, at least for me 🤔
But I agree it's the simplest solution. If I'm not wrong we'd need to make the MEDIA_URL configurable in the Config Service (I've created a branch for it: https://github.com/safe-global/safe-config-service/compare/make-media-url-configurable?expand=1), and then include in cfg.env the following:
MEDIA_URL = "http://localhost:8000/cfg/media/"

If it sounds good to you, @Uxio0 , I can do the changes on both sides, but I guess this PR would get blocked until the next release of the Config Service including that change.

If it sounds good to you, @Uxio0 , I can do the changes on both sides, but I guess this PR would get blocked until the next release of the Config Service including that change. (edit: but we could build the latest image tag, which is the one referenced in this project's env.sample, to speed up things)

Sounds good to me, no hurries. Also, for /cfg/media to work we have to expose it on nginx configuration if I'm not wrong

@Uxio0 I've added the MEDIA_URL environment variable to the cfg.env file inAdd MEDIA_URL to cfg.env, update README example versions. We've updated the Config Service image including this optional setting: https://github.com/safe-global/safe-config-service/pull/912
So with this change, we avoid the problems with the validation and all the containers and I think we're good to go.


dylan new dependency

For later... It might be worth having a dylan new [dev] dependency pkg1 [pkg2 ...] subcommand since it could

verify that the dep exists
verify that the dep doesn't conflict
prevent simple syntax errors in the package file

Most things I've seen that have this don't need a separate dependency keyword, they just treat every positional arg after the first one as a dependency.

Are you arguing against the use of multi-level subcommands like new library, new application, and new dependency?
The [dev] in the original description might've been confusing, but the idea was to add two new subcommands to the new subcommand:

dylan new dependency
dylan new dev dependency

This whole multi-level subcommand idea would be a lot nicer with LispM-like completion facilities, or at a minimum, with the ability to abbreviate to anything that uniquely names a full command, like dylan new d d or dylan new app.


Align Typescript & Runtype names

I understand this request is somewhat controversial, so I'm expecting some resistance, and that is totally reasonable. I'm sure you have thought long and hard about your naming conventions, but as I foresee a major release coming up, I thought it's a good time to chuck this spanner in the works and see if there's anyone else that feels the same.
I'm slowly bringing in the runtypes package in to our development process, at my place of work, as I love it's API and the codebase is easy to work with. However, 1 thing that has initially caused some confusion in my team (especially those new to Typescript) is the naming of Record & Dictionary.
Because Typescript has already chosen to use a type Record in a similar way to what you've chosen to name Dictionary, and you've chosen to use Record as a kind of Object validator, it seems there could be something more obvious and consistent.
How would you feel about using Object instead of Record & Record instead of Dictionary?
import { Object, Record, Number, String } from 'runtypes'

const a = Object({ foo: 'bar' })

const b = Record(String, Number) // I've also swapped the key/value parameters here to match typescript

This could well be considered more confusing, now that the community is used to the current naming, however, a part of me thinks it would be easier to get on board with if it was more aligned with Typescript.
Food for thought.

Yeahhh this is what I've been thinking for a long time, I'm glad to see you have provided some momentum. Generally speaking changing names of APIs could be a huge surprise to users and requires intermediate deprecation notices, but this time it would apparently be a quite reasonable change.
There are some remaining tasks which should be done until v7, so we shall wait to seek for any resistive opinions in this issue. If no one comes, we'll introduce this change in v7.

Meaning
Current naming
Proposed naming
TypeScript naming
JavaScript naming
Used in discussionsin our team and between teams

Record with key-value typepairs known at compile-time
Record
Object
Record
Object
Record or Object

Dictionary orassociative arrayor map
Dictionary
Record
Record
Object or Map
Dictionary or Object

I'm voting to keep current naming - it is accurate, comes from Data Structures theory and everyone (at least I have such experience) clearly understands the meaning - this is important additional benefit in communication with non-typescript devs: javascript and java devs, managers.


Remove extra space in Theme example

Type of changes

[ ] Bug fix
[ ] New feature
[x] Documentation / docstrings
[ ] Tests
[ ] Other

Checklist

[ ] I've run the latest black with default args on new code.
[ ] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[x] I accept that @willmcgugan may be pedantic in the code review.

Description
Remove extra space in Theme example.

thanks


AWS v16.2.1 release

ℹ Team Phoenix is drafting AWS v16.2.1 release to switch back to cgroups v1.
Target release date: 2021-12-22
Release PR: ...
Pre-Release

[x] Create release ticket on Releases board
[x] Make an announcement on #sig-product that team is doing a release. Include a link to the ticket from the release board.
[x] Make sure release was tested by creating new cluster, upgrading from older version and with HelloWorld app.
[x] Aggregate release notes from all changed components and add to README.md in the release directory.
[x] Send draft release announcement to #sig-product for review ASAP.
[x] Verify documentation is up to date.

Releasing

[x] Create release PR
Instructions

[x] Define new release in release.yaml file.
[x] Activate new release by setting state to active.
[x] Deactivate old release if it's within same major version (state: deprecated). Verify with PO if you have doubts.
[x] Check versions of all components included. They shouldn't be lower than those in the previous release unless there was a rollback.

Example PR

[x] Release relevant operators.

[x] Tag release branch.
[x] Bump operator version in draft release.

[x] Make sure that WIP releases in releases repo branch are removed and not merged to master since the master branch is deployed automatically after merging PR and that would make WIP releases visible in customers’ installations which should generally not happen.

Post-Release

[ ] Update front-end cluster with the new release.
[x] Verify release is available on all installations. You can use this script.
[ ] Send out release announcement to all customers according to these instructions.
[ ] PO subscribes to release posts on Slack to get notifications if there are follow-up messages.
[ ] Close release task on Releases board.

Superseeded by https://github.com/giantswarm/roadmap/issues/673


Remove Namespaces From UI

We've got a few classes with the same name in our APIs and needed to UseFullTypeNamesInSchemaIds.
We'd prefer not to display model namespaces. Is there any way we can customize the UI as to hide and/or remove the namespace from the model definition?

2 potential approaches ...

Provide you're own strategy for emitting unique SchemaId's (perhaps that don't include the complete namespace) server side via the SchemaId config action - https://github.com/domaindrivendev/Swashbuckle#schemaid
Inject some custom JavaScript that just hides the namespace in the UI (see readme)

Thanks for the feedback.
I had implemented both of these options and each came with their own trade-offs.

Dynamically generating schema ids doesn't result in overly friendly class names.

This was a pretty simple option which works well if you are only working with the enabled swagger UI. Unfortunately, at the moment, we also have a need to create a second custom document so we modify the raw swagger that is generated. Of course, since this option is JavaScript the classes include the fully qualified namespaces.

Ended up renaming the classes.