JavaToolChain should be possible to be restricted to JDK only

Expected Behavior
Added to be restricted on JDK so JRE is not enough
Current Behavior
Now it is possible to filter based on version, vendor and implementation.

I'm not sure whether a toolchain should support this. A toolchain may be used in various tasks and each task needs a different tool from the toolchain. Some need javac but a lot of test tasks may only need java to work properly. So especially when testing against multiple JDK versions, a JRE is good enough. Right now, if multiple toolchains match the required version/vendor, we do prefer a JDK though.
@netbeansuser2019 WDYT?

I'm not sure whether a toolchain should support this. A toolchain may be used in various tasks and each task needs a different tool from the toolchain. Some need javac but a lot of test tasks may only need java to work properly. So especially when testing against multiple JDK versions, a JRE is good enough. Right now, if multiple toolchains match the required version/vendor, we do prefer a JDK though.
@netbeansuser2019 WDYT?

Well, I mentioned that as option. I do not know how it is exactly done such auto-download. So imagine that you need a compile, but such auto-download downloads just JRE. Another case you have dependency on java tools (so JDK) so if it is again downloaded just JRE then you have still issue with compiling I guess.

+1 for being able to configure this (with the default being JDK)
If you decide not to make this configurable, I would say: never download a JRE, otherwise this will cause too many problems.


fix(charts/paperless-ngx): tika and gotenberg endpoints

Hello @FMJdev thank you for this repo / chart - I have some issue with the tika and gothenberg endpoints.
What this PR does / why we need it
The tika and gotenberg templated ENV variables are empty by default because it uses a empty values configuration:
https://github.com/fmjstudios/helm/blob/fea914b264718488c3104292280c9d705bf1c3a1/charts/paperless-ngx/templates/configmap.yaml#L190-L200
https://github.com/fmjstudios/helm/blob/fea914b264718488c3104292280c9d705bf1c3a1/charts/paperless-ngx/values.yaml#L329-L344
The new environment variables for the endpoints (k8s service) will be generated as e.g. follows:
<   PAPERLESS_TIKA_ENDPOINT: ""
<   PAPERLESS_TIKA_GOTENBERG_ENDPOINT: ""
---
>   PAPERLESS_TIKA_ENDPOINT: "http://paperless-ngx-tika:9998"
>   PAPERLESS_TIKA_GOTENBERG_ENDPOINT: "http://paperless-ngx-gotenberg:80"

Which issue this PR fixes
no issue opened
Special notes for your reviewer
This implementation adds two new functions to the helpers for each endpoint.
If desired they can be merged into one - I added two because it was more likely to fit in the other helper functions.
Also currently the uri can not be overwritten by the values file - only the endpoint which will always add http:// and the port (9998/80) to the environment variable.
Checklist

[x] Chart Version bumped
[x] User name added to AUTHORS file
[x] Title of the PR starts with a valid commit scope as detailed in the CONTRIBUTING (e.g.
fix(charts/linkwarden): ...)

Please do not close PR - still valid.

Hey @fty4, first of all sorry for leaving this open for so long. It's been hectic but I'm back now. I will be getting to your PR tomorrow afternoon!

Excuse the wait.. As expected stuff took longer again. What a basic oversight on my part 😄 I actually prefer two separate functions. I'll catch this stuff with better testing soon. Thank you for the fix @fty4 ! Merging 👍🏼


Compile/run for multiple toolchains and multiple targets

This is a feature request.
I want to compile my program and run tests for multiple toolchains (ARM, GCC_ARM, IAR) and targets (K64F, LPC1768, RZ_A1H, etc) with 1 command.
Something like this would really help:
mbed compile -t ARM,GCC_ARM,IAR -m K64F,LPC1768,RZ_A1H

and compile & run tests:
mbed test -t ARM,GCC_ARM,IAR -m K64F,LPC1768,RZ_A1H

Issue header has missing or incorrectly filled in fields! Please fix.

You can already do this by scripting the mbed CLI externally. Alternatively there appear to be various other scripts lurking around that do something similar. I'm closing this one as we're unlikely to implement it.


I2c peripheral trait

Although there is an interface for an i2c blocking master, a corresponding slave interface is missing.
Are there any ideas or work already done on this?

Such a trait might be a bit tricky so set up because essentially this would have to be some sort of callback which gets invoked if some master asserts the bus. I guess the callback is even the easiest part but documenting all the invariants to make sure that HAL implements the I2C slave driver correctly might be a bit hairy...

FWIW, I am building a decoder for smbus protocol that should be agnostic for polling, interrupt, or dma approach. It requires 4 events: Initiated {direction}, RequestedByte{&mut byte}, ReceivedByte{byte}, Stopped. And it requires a command handler trait where functions for read_byte etc. are collected. I want to ultimately export a macro for annotating functions with #[read_byte_data(0x42)] which should generate the custom code for the protocol handling, like derive(smbus) or derive(i2c).
https://github.com/barafael/smbus-slave-state-machine
RTIC based WIP implementation: https://github.com/barafael/stm32f0-rtic-smbus-slave (not up to date with my library though).

I needed this for a project I'm working on and have something that's working well for me. The interface looks like this:
pub trait I2cPeripheral {
    /// Returns the next event that needs to be handled.
    fn next_event(&mut self) -> I2cEvent;

    /// Write a byte to I2C. Should only be called when `I2cEvent::NeedByte` is
    /// received.
    fn write_byte(&mut self, byte: u8);
}

#[derive(Eq, PartialEq, Debug)]
#[non_exhaustive]
pub enum I2cEvent {
    None,

    /// Emitted when the I2C controller addresses us in read mode.
    StartRead,

    /// Emitted when the I2C controller addresses us in write mode.
    StartWrite,

    /// Emitted when the I2C controller sends a stop signal.
    Stop,

    /// Emitted when the next byte is required. Call `write_byte`.
    NeedByte,

    /// Emitted when we receive a byte from the I2C controller.
    ByteReceived(u8),

    /// Emitted when an error occurs on the I2C bus.
    Error(I2cError),
}

#[derive(Eq, PartialEq, Debug)]
pub enum I2cError {
    Overrun,
    Underrun,
    BusError,
}

I've used this interface both for polling and interrupt driven. For interrupt driven, I initially did it without RTIC, then with RTIC.
The i2c interrupt just calls next_event then matches on the result. I have another layer on top of this that builds up a protocol layer, which also returns events (ReadRegister, WriteRegister etc).
I initially tried to use callbacks, but it got pretty nasty with ownership and lifetimes, since you need multiple callbacks, one for each type of event and those callbacks all need access to some shared data. Perhaps there's a way to make it nice with callbacks, but I've found an event driven model to work really well.
If there's interest, I can look to upstream this interface to this crate and at least one implementation (stm32g0xx-hal).
I'm just now reading @barafael's comment above, and the design sounds pretty similar.

Looks neat, I think the event-based communication makes the most sense, though my worry is that it might not be zero-cost (or at least as low-cost as it can be)? There are a few things between y'alls implementations that I think are worth talking about:

I think i like splitting Initiated{Direction} into StartRead and StartWrite is nice, if only because it reduces the number of imports
RequestedByte{&mut u8} seems like the cleaner and more efficient way to do it, though I haven't tried it either way yet
(for @barafael) It seems like SMBusState has a hard-coded buffer. Is this something we could const genericize? Or is it like part of the SMBus specification? Also this seems like something that should be done at the driver level rather than the HAL level.
I think it might be nice to at least explore what a callback-based system might look like, unless your experimentation leads you to believe that it wouldn't be worth looking into.
Are all I2C slave peripherals able to both read and write? The I2C master traits are split into separate Read and Write traits, and I'm not sure if that's something we'd need to do for this as well.

The fact that two people have independently come to the same conclusion is pretty reassuring. Do you have a fork repo of embedded-hal that I could use as a basis for seeing if I can implement this on other chips? Are these lines the only ones you added to the HAL repo?

There is also this pull request on stm32f0xx-hal: https://github.com/stm32-rs/stm32f0xx-hal/pull/124 which also has a similar design.

Regarding the buffer size, we could totally "const genericize" it :) I just wasn't aware at the time, and 32 bytes is the maximum block transfer length of SMBus. I2C is not bounded.
I think with something like the CommandHandler trait it is possible to still use callbacks but to use a static dispatch function by default. As I described above, I really hope it would be possible to implement proc-macros for deriving that trait :)
Regarding Read and Write, in this pdf: https://github.com/barafael/smbus-graph/blob/main/smbus-graph.pdf you can see that the only paths which only need read and not write are "Quick Commmand Read" and "Read Byte".
I think the nice thing about @davidlattimore and my implementations is that they are completely independent of polling/interrupt/DMA and could even work with bitbanged I2C peripherals. We should consider if our implementations really should belong to a HAL. Maybe just the hardware initialization for an I2C peripheral in "slave mode" should be part of the HAL, and any SMBus/I2C slave library can work with that. Just a thought.

Regarding optimisation of an event-based API, I think it might be possible for the compiler to make it close to zero cost. If next_event is inlined into the function that matches on the event, then you have some code that produces a few different values followed by some code that branches on those same values. It seems like it should be possible to collapse the set-enum-variant and the check-enum-variant together. Whether the compiler currently does this in practice, I have no idea.
I currently have the code that I pasted above in a separate, internal crate, but the above code is it for the HAL side.
I'm unsure about RequestedByte{&mut u8}, since the store into the hardware tx register needs to be volatile. I have contemplated having NeedByte hold a ByteRequest struct, which in turn would hold a mutable reference to the I2C peripheral then have a method respond(self, byte: u8). Making this work seems tricky, so I guess the question is whether it's worth the extra complexity.
I avoided buffering at this layer and put my buffer(s) in the protocol layer, since my protocol layer knows how many bytes it expects to send and receive. It should be possible to have a struct BufferedI2cPeriperhal<I: I2cPeriperhal> that wraps an I2cPeriperhal and adds buffering. With no buffers, my struct that implements I2cPeripheral is a zero-sized type. All the state is in the hardware.
Something else worth mentioning is that with a couple of extra methods on the trait (start and stop), I think the trait could become a generic, non-blocking interface for I2C regardless of whether operating as a controller or a peripheral.

Maybe just the hardware initialization for an I2C peripheral in "slave mode" should be part of the HAL, and any SMBus/I2C slave library can work with that. Just a thought.
Are you suggesting splitting this trait into a separate crate? What would be the hypothetical benefit of that? Modularity?
I'm unsure about RequestedByte{&mut u8}, since the store into the hardware tx register needs to be volatile.
Ah, I see, I wasn't thinking about volatility at all. I think I like the ByteRequest struct concept (I'm assuming it works like), but maybe you're right that it might be overly complex

Glad to see y'all thinking about and discussing this. I intended (read: vaguely considered) PRing what I've been using, but it's really silly compared to both of your implementations

Are you suggesting splitting this trait into a separate crate? What would be the hypothetical benefit of that? Modularity?

Not the trait, I think, the "trait" being something like what @davidlattimore is proposing. In my crate, there is no such trait (is hardware-agnostic). It just helps with en/decoding the messages sent over some smbus, because I found myself doing it over and over again manually. The benefit would be flexibility, modularity, and keeping the HAL free of specific implementations.

What do folks think about how errors should be handled in this kind of trait? In the trait I pasted above, I included an explicit error enum in with the trait definition. The existing blocking::i2c::WriteRead and blocking::i2c::Write traits both leave the error type up to the trait implementation. Allowing traits to define their own error types allows full propagation of error information, which does seem desirable, especially if running on an operating system which could have all sorts of weird errors. However, I've found building layers on top of WriteRead and Write traits to be a bit of a pain due to the errors not being concrete types.
I wonder if a happy medium might be allow implementations to supply their own error type, but to require that error type implement Into<embedded_hal::I2cError>.
pub trait I2cPeripheral<E: Into<I2cError>> {
    fn next_event(&mut self) -> I2cEvent<E>;
    ...
}

pub enum I2cEvent<E: Into<I2cError>> {
    ...
    Error(E),
}

That way implementations of the trait can chose whether to just use embedded-hal's I2cError, or their own error type and users of the trait can chose whether to preserve the original error type or convert to embedded-hal's I2cError. Thoughts?

Something else I've been thinking about is how best to handle I2cEvent::StartRead. At least for the hardware I've been using (stm32g071), things work a lot better if I put a byte into the tx buffer as soon as I get a start event. If I wait until the hardware sets the txis bit (the I need a byte bit), then it's much more marginal and I'm likely to end up with an underrun. So I'm inclined to say that StartRead should imply the need to send the first byte. One way we could encode this might be like this:
pub enum I2cEvent {
    ...
    StartRead(ByteRequest),
    ...
    NeedByte(ByteRequest),
}

pub trait I2cPeripheral {
    fn write_byte(&mut self, byte: u8, request: ByteRequest);
}

I'm unsure if there's hardware where sending the first byte when you get a start event isn't the thing to do. If there are, then we could make it StartRead(Option<ByteRequest>). Or perhaps we just say if there's an implementation that doesn't want the first byte straight away, it can buffer the byte.
If we instead say that StartRead doesn't imply a request for a byte, then the implementation will need to produce two events in response to the start condition - a StartRead and a NeedByte. This would require storing some state in order to know that the NeedByte event needs to be sent. It would also mean that interrupt handlers would need to call next_event in a loop until they got I2cEvent::None. Thoughts?

I wonder if a happy medium might be allow implementations to supply their own error type, but to require that error type implement Into<embedded_hal::I2cError>.

Makes sense, maybe this is worth creating a separate issue altogether? One thing that I'm not sure about is how it would work with the Never/! type. I think it's fine since it can be converted into any type, but I'm not an expert.
Also should the error go in a Result? i.e. fn next_event(&mut self) -> Result<I2cEvent, E>;? Most of the other fallible trait functions in the HAL return a Result. Not sure if it introduces any performance issues, but it's nice to not have to manually implement stuff like Try/?.

pub trait I2cPeripheral<E: Into<I2cError>> {

Shouldn't the error type be an associated type rather than generic? Like
pub trait I2cPeripheral {
	type Error: Into<I2cError>;
...

So I'm inclined to say that StartRead should imply the need to send the first byte.

Is there any mechanical difference between StartRead and NeedByte? In terms of what the driver has to do in both those cases, I feel like it's the same. Maybe StartRead allows the driver crate to perform some sort of initialization? But I feel like that could be done by storing state in the driver crate instead. My main point is, what should the driver be doing if it receives a StartRead event?
Also, if you have to call write_byte anyway, what's the point of ByteRequest?

Or perhaps we just say if there's an implementation that doesn't want the first byte straight away, it can buffer the byte.

This seems like something that could be done in write_byte. In fact, the implementation I've been using so far takes an array of bytes, and just polls until they're all through. Would that be a bad idea in this case? Something like
fn write_bytes(&mut self, bytes: &[u8]) -> Result<(), Self::Error> {
	let mut idx = 0;
	loop { // probably better to make this an iterator or something
		if self.i2c.isr.read().txe().is_empty() {
			self.i2c.txdr.write(|w| w.txdata().bits(bytes[idx]));
			idx += 1;
			if idx == bytes.len() { break; }
		}
	}
	Ok(())
}

Regarding errors, there is a lengthy discussion in #229. Proposition 3 here seems like a good candidate but we got lost in details.


Windows 7 32-bit Report an error using nodeusb

environment
node   v16.14.0
npm   8.3.1
"electron": "^20.2.0",
"electron-builder": "^23.3.3"
"usb": "2.4.3"
Windows 10 and 11, Windows 7 64-bit open without any problems, but Windows 7 32-bit open error:
[Window Title]
Error
[Main Instruction]
A JavaScript error occurred in the main process
A JavaScript error occurred in the main process
Uncaught Exception:TypeError: Cannot read properties of undefined (reading 'prototype’)at C:ProgramFiles\NsfocusVPNresourceslapp,asarnode_moduleshusb\distlusb\indexjs:22:38at Array,forEach (sandyymous>)
at Object.sanonymous>(C:ProgramFilesNsfocusVPN\resourceslapp,asarinode_moduleslusbidistlusblindexjs:21:63)at Module. compile (node:internal/modules/'cjs/loader:1120:14)
at Module, extensions..js (node:internal/modules/cjs/loader:1175:10)
at Module.load (node:internal/modules/cis/oader:988:32)at Module, load (node:internal/modules/cis/loader:829:12
at c, load (node:electron/js2c/asar bundle:5:13343)
at Module.require (nede:internal/modules/cjs/loader:1012:19)
at require (node:internal/modules/cjs/helpers:102:18)

Hmm, not much idea at all. Please ensure you have electron set up to not rebuild native packages

I encountered a similar error:

These look like different issues, however I'm aware of shipped products using both electron and Node-usb so this should work!
I think some version bisection is needed here as I'm really keen to find out when this started failing and whether this was due to a node-usb update or electron update.


BUG: special: cast to float before in-place multiplication in orthopoly

Closes gh-6721.

In case anyone was wondering, the cause here is this:
>>> x = np.array([1e18])
>>> np.multiply(x, 2**65)
array([3.6893488147419103e+37], dtype=object)

An in-place multiplication is equivalent to np.multiply(x, 2**65, out=x), so the code tries to shove the array with dtype object into x, a float64 array. This doesn't happen when the integer we're multiplying by can be safely cast to a NumPy integer dtype, e.g.
>>> np.multiply(x, 2**64 - 1)
array([  1.84467441e+37])

Seems like conceivably NumPy could check the dtype of x and realize it's safe to cast 2**65 to a float and then attempt the multiply? Probably subtleties here I'm not thinking of.

It seems like conceivably NumPy could check the dtype of x and realize it's safe to cast 2**65 to a float and then attempt the multiply?

Possibly. Looks like it treats the scalar as it would when you'd put it into an array:
In [12]: np.array([2**64])
Out[12]: array([18446744073709551616L], dtype=object)

LGTM, merged. Thanks @person142


NoMethodError for access_control when used in rails-api

rails-api doesn't have ActionController::Base which is what the controller methods are attached to.

Currently the work around is to add the acl9 helper to the app controller:
class ApplicationController < ActionController::API
  include Acl9::ControllerExtensions
end

Looking forward to an update.
Thanks!

Thanks for bumping this, and the workaround, I'll have something very shortly.

1.2.1 is now out on rubygems

Nice! Thank you!

You're welcome. Thanks again for the bump on this, I had the fix sitting locally and had just forgotten to push it up.


test/gke: refactor test-clusters operations

See individual commits.

test-gke

test-gke

test-gke

test-gke

test-gke

https://jenkins.cilium.io/job/Cilium-PR-K8s-GKE/5284
cilium-ci-14 got selected, properly scaled up to 2 nodes, used, and then deleted at the end. Shortly after the pipeline ended, it got recreated when Flux got around to reinstate containercluster.container.cnrm.cloud.google.com/cilium-ci-14.

Writing down this here while I see it: the cluster creation via ConfigConnector from Flux is painfully slow because the cluster first gets created with a default nodepool, which gets subsequently deleted and replaced by a Flux-managed nodepool, which itself is scaled to 0 nodes.
The way we use clusters, I 100% think we should drop Flux for this and instead just create CRDs on the fly from jobs. That way it would work like it does for workflows on CI 3.0, where a cluster is created specifically for the job and dies with it.

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

test-gke

This change only needs GKE jenkins build to be green.

test-gke

test-gke

test-gke

https://jenkins.cilium.io/job/Cilium-PR-K8s-GKE/5311/ 🎉

gke passed, merging


Supporting all CRDs and switching to NetView based IP allocation

Description: Supporting all CRDs and switching to NetView based IP allocation
Changes Proposed in PR:
Fixes: #Github issue id
General Checklist

[x] Updated Added functionality/ bug fix in release notes
[x] Added examples for new feature
[x] Updated the documentation

CRD Checklist

[x] Updated required CR schema

/azp run

/azp run

/azp run

/azp run


It can't detect QRS when I use this data from http://www.physionet.org/cgi-bin/atm/ATM. And it always return 0.

It can't detect QRS when I use this data from http://www.physionet.org/cgi-bin/atm/ATM. And it always return 0.

I have tested the classifier over a set of several ECG taken from physionet,
I have resampled the ECGs down to 250 sps.
Beats are properly detected. However, the classification looks a little odd to me:
The first beat is always tagged Unknown over the entire test set.
Except very rare situations where the signal looks rather nois that a beat... it shows a result different of N (Normal). So... in general... the first beat is always marked U (Unknown), the following beats are always marked N (Normal) all over the entire set of ECGs.. this is odd because there are all kind of pathologies among the signal. I appreciate your comments... thank you

good day I would like to know how to use this library, Wolfy42 downloaded the example you speak, but do not have the input file, you can provide the same?

i use input file from physiobank atm, download the file as matlab and convert it to csv..then i try to read sample values from csv file in java and put the data values to array.Then the array element values is pass to object method. Something like this...
BeatDetectAndClassifyResult resultClassify = bdac.BeatDetectAndClassify(ecgSampleValue[i]);

Hi, I am trying to add this to my android project. How can I add it.

I am having too silly errori cant find the main method sorry but please can you help me wi
th that

@LPricMJCR7: This is a library and not a running application and therefore this has no main-method.
For a running application see the example linked in https://github.com/MEDEVIT/OSEA-4-Java/issues/1#issuecomment-62296101

Hi Wolfgang,
I always get 90 as a heart rate. I noticed a strange operation. QrsDelay is an interval between two R peaks.
There is it is always assigned with the constant value:
https://github.com/keot/oseawrapper/blob/master/qrsdet.c#L233
QrsDelay =  qrsDetParas.WINDOW_WIDTH + preBlankParas.FILTER_DELAY ;
There are only two places where QrsDelay is assigned, here the second:
https://github.com/keot/oseawrapper/blob/master/qrsdet.c#L277
But I haven't managed to get there.
I checked eplimited original sources, they are the same. Have you managed to get changing values?

Sorry man i just droped that project due to some reasonsorry
with regards
On Monday, November 28, 2016 4:35 PM, vsimankov<EMAIL_ADDRESS>wrote:

Hi Wolfgang,
I always get 90 as a heart rate. I noticed a strange operation. QrsDelay is an interval between two R peaks.
There is it is always assigned with the constant value:
https://github.com/keot/oseawrapper/blob/master/qrsdet.c#L233
QrsDelay = qrsDetParas.WINDOW_WIDTH + preBlankParas.FILTER_DELAY ;
There are only two places where QrsDelay is assigned, here the second:
https://github.com/keot/oseawrapper/blob/master/qrsdet.c#L277
But I haven't managed to get there.
I checked eplimited original sources, they are the same. Have you managed to get changing values?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Release 0.7.0 y1

You should update our repo master branch (or pick a release one) and then on top of that create this one with your commit.
In that way it's easy to compare the change and potentially update by doing a rebase.


Documentation issue: leaf_label_rotation --> leaf_rotation

The keyword argument leaf_rotation is misdocumented as leaf_label_rotation in scipy.cluster.hierarchy.dendrogram.

Further, the documentation of R['dcoords'] seems to be a copy-paste of the documentation of R['icoords'].

@ScottNortonPhD, are you looking at the latest version of the documentation?  I don't see those issues in https://docs.scipy.org/doc/scipy/reference/generated/scipy.cluster.hierarchy.dendrogram.html

My mistake, Warren. Somehow Google brought me to the version 0.14 docs without me noticing.

No problem, it happens.  It turned out to be fixed already, but thanks for taking the time to report the issue.


A error from GCC

I wanted to use Nuitka for compiling. I was reading the user manual. In the manual it was written that:
python -m nuitka --mingw64 hello.py
I replaced hello.py with the name of my own file and typed it. However I got an error like this, this is my CMD:
C:\Users\W7\Desktop\nuitkadeneme>python -m nuitka --mingw64 nuitkadeneme.py
Nuitka:INFO: Starting Python compilation.
Nuitka:INFO: Completed Python level compilation and optimization.
Nuitka:INFO: Generating source code for C backend compiler.
Nuitka:INFO: Running data composer tool for optimal constant value handling.
Nuitka:INFO: Running C level backend compilation via Scons.
Nuitka-Scons:INFO: Backend C compiler: C:\Users\W7\AppData\Local\Nuitka\Nuitka\gcc\x86_64\10.2.0-11.0.0-8.0.0-r5\mingw64\bin\gcc.exe (gcc.exe).
In file included from C:\Users\W7\AppData\Local\Programs\Python\Python39\include/Python.h:8,
                 from C:\Users\W7\AppData\Local\Programs\Python\Python39\lib\SITE-P~1\nuitka\build\include/nuitka/prelude.h:47,
                 from __constants.c:2:
C:\Users\W7\AppData\Local\Programs\Python\Python39\include/pyconfig.h:59:10: fatal error: io.h: No such file or directory
   59 | #include <io.h>
      |          ^~~~~~
compilation terminated.
In file included from C:\Users\W7\AppData\Local\Programs\Python\Python39\include/Python.h:8,
                 from C:\Users\W7\AppData\Local\Programs\Python\Python39\lib\SITE-P~1\nuitka\build\include/nuitka/prelude.h:47,
                 from __helpers.c:4:
C:\Users\W7\AppData\Local\Programs\Python\Python39\include/pyconfig.h:59:10: fatal error: io.h: No such file or directory
   59 | #include <io.h>
      |          ^~~~~~
compilation terminated.
scons: *** [__constants.o] Error 1
scons: *** [__helpers.o] Error 1**

You didn't provide the information asked for in the issue template.


[Q] Clarification on analyze plugin output

I did check in the manual but did not find explanation for the following parameters for the json-output of the analyze plugin (I did check the Normalized output format paragraph)
pids.packet:

af
pcr-leap
dts-leap
pts leap
discontinuities: is this cc-errr?

thanks

af = number of packets with an adaptation field in the header, not necessarily meaningful, just an information.
pcr-leap, dts-leap, pts leap = "leap" in timestamps, meaning consecutive timestamps with suspect distance, typically more than a couple of seconds, probably a symptom of something going wrong. One exception: there is one expected leap every 26 hours when the integer value of the timestamps wraps down to zero.
discontinuities = errors in continuity counters, a symptom of missing or incorrect packets.


frontend sends parallelism of 0 which breaks add_services

What's your CLI version?
0.84.3
Description & steps to reproduce
Try running github.com/galenmarchetti/basic-service-package from the cloud or web ui and you will see it gets stuck as it uses add_services
Do docker logs on the core and you will see parallelism is passed as 0
https://github.com/kurtosis-tech/kurtosis/commit/4af67d5d12af30919afcdf8701432ab6ee92a4ca
this is a stop gap that should be reverted ^
Desired behavior
Parallelism 4 should be passed by frontend to backend by default. CLI should stream logs; core logs should be visible on Cloud
What is the severity of this bug?
Critical; I am blocked and Kurtosis is unusable for me because of this bug.
What area of the product does this pertain to?
Frontend

Believe this is now fixed


Pick up fixes from 'noduino'.

Hi!
It looks like some people used this source, and added some fixes. Might be useful to see what can be merged back?
https://github.com/icamgo/noduino-sdk/tree/master/lib/mqtt

Ahh, nevermind, same fixes seem to be already here.. XD Sorry for not checking :)
Closing :)


[Bug]: Icon on a toolbar moves position based on presence of associated text

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Icon on a toolbar moves position based on presence of associated text
Steps To Reproduce

Drop a toolbar widget
Add/remove text on a button with icon style
Observe the position of the icon

Public Sample App
No response
Environment
Production
Severity
Medium (Frustrating UX)
Issue video log
https://www.loom.com/share/36cb62d476904188a42b0b622e2c7d74
Version
cloud

This is fine, absence of text requires different visual balancing, so IconButton and regular Button have different paddings.


SSL Connection error

Hi all,
the script ran perfectly until the last 2 days. on some content of some models I recieve the following error:
"C:\Users\your_username.local\pipx\venvs\ofscraper\Lib\site-packages\aiohttp\connector.py",
line 988, in _wrap_create_connection
raise client_error(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host cdrm-project.com:443
ssl:<ssl.SSLContext object at 0x00000230D2564440> [Der angegebene Netzwerkname ist nicht mehr
verfügbar]
Anything I could do?

I got it fixed by myself.
I dumped keys for the protected content.
Then I edited my config "key-mode-default" to "manual" and added the path to my keys.
works again with no problems!
there's a good tutorial in the discord!


Fix misplaced blank line in cc-by-sa-4.0

There is no special formatting of these line(s) in the SPDX XML file in the spdx/license-list-XML repository.

Just make a good decision


📣 Update ghcr.io/geek-cookbook/alpine:rolling Docker digest to 7b019e6

This PR contains the following updates:

Package
Type
Update
Change

ghcr.io/geek-cookbook/alpine
final
digest
8a0e46c -> 7b019e6

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Very Confusing

Firstly, kudos on the SDK and Unity Project – impressive work!
Yet, diving into the Unity instructions can be perplexing. I suggest simplifying the initial setup; just extract and add it to Unity Hub.
When duplicating the TemplateMod in the Mods folder, rename it for your new mod. Clear guidance is needed here: Do you keep the old template folder? Yes or No? Inside Unity or Windows Explorer?
Modifying the ModManifest is straightforward, ensuring the Mod Name and Folder match. However, creating custom moons from the SceneBuilder scene seems unclear, especially with different boxes in the manifest for moon selection.
The AssetBundle Builder process needs clearer explanation, avoiding jargon like “WTF DOES THIS MEAN?” Maybe a video tutorial would help. Additionally, specifying the correct location for ThunderStore users is crucial.
Addressing the issue of moons not showing up and the importance of the .lem extension in Unity, a comprehensive tutorial with visuals could be immensely beneficial. Photos hint at the necessity of adding the MAIN prefab – a video tutorial might make this step clearer.
In essence, your project is fantastic, but an improved, step-by-step Unity tutorial with video support would greatly enhance user experience.
Photos show MAIN prefab has to be added also... like... bro xD VIDEO LMAO

I know men i'm sorry xD
I have a plenty of things to fix or change before made a video tutorial, but it's planned

UPDATE: The MODULES folder is inside of CACHE for THunderstore
C:\Users\USERNAME\AppData\Roaming\Thunderstore Mod Manager\DataFolder\LethalCompany\cache\HolographicWings-LethalExpansion\1.1.9\Modules

Ok so like. For example. I wanna use scene builder for your test moon. I edit the test moon, make prefab and than put it where? I just wanna edit the test moon instead of building a new scene. It’s easier.

You have to place the prefab in a moon asset file, as Main Prefab

But if you just edit the test moon it will be saved as the template mod, so will overwrite it and could cause issues with other users
You should create a new moon asset by copy paste the test one or right click in the file explorer to create a new one.


Integrate lookbook for view components

Refer: https://github.com/ViewComponent/lookbook

can u elaborate more on this issue

Hi @YashGupt29
There are a few view components defined in the application. But we don't have any place to preview those components. You'll have to integrate https://github.com/ViewComponent/lookbook to achieve this.

Ok I understood this issue I will try assign me this issue!

Hi @disha1202
Where should we integrate the lookbook in the application code?

@shakthi2003-ice we have to install it

@niladrix719 @disha1202 Is there any documentation available from which we can refer how to integrate lookbook components

@DhairyaMajmudar https://lookbook.build/guide/installation

@YashGupt29 are you working on this?

@DhairyaMajmudar https://lookbook.build/guide/installation

Thank you @niladrix719 for the docs. I went through them and understood the approach to implement the feature. can you pls. assign this issue to me.

if nobody is working on this you can go for it

if nobody is working on this you can go for it

Thank You 🙏

@DhairyaMajmudar  Extremely sorry but I am working on this issue

@DhairyaMajmudar Extremely sorry but I am working on this issue

@shakthi2003-ice can you pls. look for any other issue since I have almost completed the implementation.

@shakthi2003-ice we have to install it

@DhairyaMajmudar i am so sorry but i have been working for the past 2 days. Due to some installation issues I couldn't complete it early.

@shakthi2003-ice we have to install it

@DhairyaMajmudar i am so sorry but i have been working for the past 2 days. Due to some installation issues I couldn't complete it early.

Oh! Okayji no worries 🙂
@niladrix719 can you pls. assign me an another issue in which I can contribute.

@niladrix719 hii
I have installed the lookbook but it is showing this error

@shakthi2003-ice check for errors in routes.rb, you can also join our slack channel if you need more help

@disha1202 I have made the pull request can you please assign me this issue for the PR to get merged

If this issue is still open ,  I would like to work on it!

is this issue still open?

Is this issue still open? I would like to work on it.


Completely separate audio.c from minigbs.c

This will help turning the APU logic used in minigbs into a separate library.

Some work done in 8402f3bf5c03191c2a33c69682098e49c2a79749


Added tx_status to transactions table

Description
Please include a summary of changes and related issue (if any).
Added tx_status as a new column to the transactions table so it would be easier to check if the transaction has succeeded or failed. Solves issue #87.
Tests

[x] Please provide evidence of your successful dbt run / dbt test here

SILVER_TRANSACTIONS
dbt run
root@f82ab8553319:/near/models/silver# dbt run -s silver__transactions+ --full-refresh
18:23:59  Running with dbt=1.0.0
18:24:08  Found 38 models, 605 tests, 0 snapshots, 0 analyses, 628 macros, 1 operation, 1 seed file, 2 sources, 0 exposures, 0 metrics
18:24:08
18:24:22
18:24:22  Running 1 on-run-start hook
18:24:22  1 of 1 START hook: near.on-run-start.0.......................................... [RUN]
18:24:22  1 of 1 OK hook: near.on-run-start.0............................................. [OK in 0.00s]
18:24:22
18:24:22  Concurrency: 4 threads (target='dev')
18:24:22
18:24:22  1 of 31 START incremental model silver.transactions............................. [RUN]
22:47:17  1 of 31 OK created incremental model silver.transactions........................ [SUCCESS 1 in 15774.96s]
22:47:17  2 of 31 START view model core.fact_transactions................................. [RUN]
22:47:17  3 of 31 START view model legacy.transactions.................................... [RUN]
22:47:17  4 of 31 START incremental model metrics.active_wallets.......................... [RUN]
22:47:17  5 of 31 START incremental model metrics.daily_gas............................... [RUN]
22:47:23  2 of 31 OK created view model core.fact_transactions............................ [SUCCESS 1 in 5.74s]
22:47:23  6 of 31 START incremental model metrics.daily_transactions...................... [RUN]
22:47:23  3 of 31 OK created view model legacy.transactions............................... [SUCCESS 1 in 6.20s]
22:47:23  7 of 31 START incremental model silver.actions_events........................... [RUN]
22:47:44  5 of 31 OK created incremental model metrics.daily_gas.......................... [SUCCESS 1 in 26.83s]
22:47:44  8 of 31 START incremental model silver.prices_oracle............................ [RUN]
22:47:46  4 of 31 OK created incremental model metrics.active_wallets..................... [SUCCESS 1 in 28.90s]
22:47:46  9 of 31 START incremental model silver.receipts................................. [RUN]
22:48:12  6 of 31 OK created incremental model metrics.daily_transactions................. [SUCCESS 1 in 49.48s]
22:48:12  10 of 31 START view model core.metrics_daily_gas................................ [RUN]
22:48:16  10 of 31 OK created view model core.metrics_daily_gas........................... [SUCCESS 1 in 3.35s]
22:48:16  11 of 31 START view model legacy.metrics_daily_gas.............................. [RUN]
22:48:19  11 of 31 OK created view model legacy.metrics_daily_gas......................... [SUCCESS 1 in 3.10s]
22:48:19  12 of 31 START view model core.metrics_active_wallets........................... [RUN]
22:48:22  12 of 31 OK created view model core.metrics_active_wallets...................... [SUCCESS 1 in 3.66s]
22:48:22  13 of 31 START view model legacy.metrics_active_wallets......................... [RUN]
22:48:26  13 of 31 OK created view model legacy.metrics_active_wallets.................... [SUCCESS 1 in 3.55s]
22:48:26  14 of 31 START view model core.metrics_daily_transactions....................... [RUN]
22:48:30  14 of 31 OK created view model core.metrics_daily_transactions.................. [SUCCESS 1 in 3.94s]
22:48:30  15 of 31 START view model legacy.metrics_daily_transactions..................... [RUN]
22:48:33  15 of 31 OK created view model legacy.metrics_daily_transactions................ [SUCCESS 1 in 3.25s]
22:50:01  8 of 31 OK created incremental model silver.prices_oracle....................... [SUCCESS 1 in 137.10s]
22:50:01  16 of 31 START view model core.fact_prices...................................... [RUN]
22:50:06  16 of 31 OK created view model core.fact_prices................................. [SUCCESS 1 in 4.61s]
23:23:57  7 of 31 OK created incremental model silver.actions_events...................... [SUCCESS 1 in 2193.48s]
23:23:57  17 of 31 START view model core.fact_actions_events.............................. [RUN]
23:23:57  18 of 31 START view model legacy.actions_events................................. [RUN]
23:23:57  19 of 31 START incremental model silver.actions_events_addkey................... [RUN]
23:24:00  18 of 31 OK created view model legacy.actions_events............................ [SUCCESS 1 in 3.77s]
23:24:00  20 of 31 START incremental model silver.actions_events_function_call............ [RUN]
23:24:01  17 of 31 OK created view model core.fact_actions_events......................... [SUCCESS 1 in 4.13s]
23:24:01  21 of 31 START incremental model silver.transfers............................... [RUN]
23:24:29  19 of 31 OK created incremental model silver.actions_events_addkey.............. [SUCCESS 1 in 31.84s]
23:24:29  22 of 31 START view model core.fact_actions_events_addkey....................... [RUN]
23:24:32  22 of 31 OK created view model core.fact_actions_events_addkey.................. [SUCCESS 1 in 2.95s]
23:24:32  23 of 31 START view model legacy.actions_events_addkey.......................... [RUN]
23:24:34  23 of 31 OK created view model legacy.actions_events_addkey..................... [SUCCESS 1 in 2.91s]
23:39:22  9 of 31 OK created incremental model silver.receipts............................ [SUCCESS 1 in 3096.50s]
23:39:22  24 of 31 START view model core.fact_receipts.................................... [RUN]
23:39:22  25 of 31 START view model legacy.receipts....................................... [RUN]
23:39:27  24 of 31 OK created view model core.fact_receipts............................... [SUCCESS 1 in 4.73s]
23:39:27  25 of 31 OK created view model legacy.receipts.................................. [SUCCESS 1 in 4.91s]
23:40:43  21 of 31 OK created incremental model silver.transfers.......................... [SUCCESS 1 in 1001.79s]
23:40:43  26 of 31 START view model core.fact_transfers................................... [RUN]
23:40:43  27 of 31 START view model legacy.transfers...................................... [RUN]
23:40:47  27 of 31 OK created view model legacy.transfers................................. [SUCCESS 1 in 4.41s]
23:40:47  26 of 31 OK created view model core.fact_transfers.............................. [SUCCESS 1 in 4.61s]
23:49:27  20 of 31 OK created incremental model silver.actions_events_function_call....... [SUCCESS 1 in 1523.44s]
23:49:27  28 of 31 START view model core.fact_actions_events_function_call................ [RUN]
23:49:27  29 of 31 START view model legacy.actions_events_function_call................... [RUN]
23:49:27  30 of 31 START incremental model silver.dex_swaps............................... [RUN]
23:49:31  28 of 31 OK created view model core.fact_actions_events_function_call........... [SUCCESS 1 in 4.72s]
23:49:32  29 of 31 OK created view model legacy.actions_events_function_call.............. [SUCCESS 1 in 4.87s]
23:50:36  30 of 31 OK created incremental model silver.dex_swaps.......................... [SUCCESS 1 in 69.41s]
23:50:36  31 of 31 START view model core.ez_dex_swaps..................................... [RUN]
23:50:39  31 of 31 OK created view model core.ez_dex_swaps................................ [SUCCESS 1 in 3.19s]
23:50:39
23:50:39  Finished running 11 incremental models, 20 view models, 1 hook in 19591.41s.
23:50:39
23:50:39  Completed successfully
23:50:39
23:50:39  Done. PASS=31 WARN=0 ERROR=0 SKIP=0 TOTAL=31

dbt_test
root@f82ab8553319:/near/models/silver# dbt test --select silver__transactions
00:30:36  Running with dbt=1.0.0
00:30:42  Found 38 models, 605 tests, 0 snapshots, 0 analyses, 628 macros, 1 operation, 1 seed file, 2 sources, 0 exposures, 0 metrics
00:30:42
00:30:49
00:30:49  Running 1 on-run-start hook
00:30:49  1 of 1 START hook: near.on-run-start.0.......................................... [RUN]
00:30:49  1 of 1 OK hook: near.on-run-start.0............................................. [OK in 0.00s]
00:30:49
00:30:49  Concurrency: 4 threads (target='dev')
00:30:49
00:30:49  1 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_ATTACHED_GAS__NUMBER__FLOAT [RUN]
00:30:49  2 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_HASH__STRING__VARCHAR [RUN]
00:30:49  3 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_ID__NUMBER__FLOAT [RUN]
00:30:49  4 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_TIMESTAMP__TIMESTAMP_NTZ [RUN]
00:30:54  3 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_ID__NUMBER__FLOAT [PASS in 4.96s]
00:30:54  5 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_GAS_USED__NUMBER__FLOAT [RUN]
00:30:54  1 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_ATTACHED_GAS__NUMBER__FLOAT [PASS in 5.11s]
00:30:54  6 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_NONCE__NUMBER [RUN]
00:30:54  2 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_HASH__STRING__VARCHAR [PASS in 5.19s]
00:30:54  4 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_BLOCK_TIMESTAMP__TIMESTAMP_NTZ [PASS in 5.19s]
00:30:54  7 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_SIGNATURE__STRING__VARCHAR [RUN]
00:30:54  8 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TRANSACTION_FEE__NUMBER__FLOAT [RUN]
00:30:59  5 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_GAS_USED__NUMBER__FLOAT [PASS in 4.78s]
00:30:59  9 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_HASH__STRING__VARCHAR [RUN]
00:30:59  7 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_SIGNATURE__STRING__VARCHAR [PASS in 4.60s]
00:30:59  10 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_RECEIVER__STRING__VARCHAR [RUN]
00:30:59  6 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_NONCE__NUMBER [PASS in 4.94s]
00:30:59  11 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_SIGNER__STRING__VARCHAR [RUN]
00:30:59  8 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TRANSACTION_FEE__NUMBER__FLOAT [PASS in 4.87s]
00:30:59  12 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_STATUS__STRING__VARCHAR [RUN]
00:31:04  10 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_RECEIVER__STRING__VARCHAR [PASS in 4.65s]
00:31:04  13 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX__OBJECT__VARIANT [RUN]
00:31:04  12 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_STATUS__STRING__VARCHAR [PASS in 4.50s]
00:31:04  14 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions__INGESTED_AT__TIMESTAMP_NTZ [RUN]
00:31:04  9 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_HASH__STRING__VARCHAR [PASS in 5.05s]
00:31:04  11 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX_SIGNER__STRING__VARCHAR [PASS in 4.74s]
00:31:04  15 of 34 START test dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions__INSERTED_TIMESTAMP__TIMESTAMP_NTZ [RUN]
00:31:04  16 of 34 START test dbt_expectations_expect_row_values_to_have_recent_data_silver__transactions_BLOCK_TIMESTAMP__day__1 [RUN]
00:31:07  14 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions__INGESTED_AT__TIMESTAMP_NTZ [PASS in 3.10s]
00:31:07  17 of 34 START test dbt_utils_unique_combination_of_columns_silver__transactions_tx_hash [RUN]
00:31:07  13 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions_TX__OBJECT__VARIANT [PASS in 3.49s]
00:31:07  18 of 34 START test not_null_silver__transactions_ATTACHED_GAS.................. [RUN]
00:31:08  15 of 34 PASS dbt_expectations_expect_column_values_to_be_in_type_list_silver__transactions__INSERTED_TIMESTAMP__TIMESTAMP_NTZ [PASS in 4.28s]
00:31:08  19 of 34 START test not_null_silver__transactions_BLOCK_HASH.................... [RUN]
00:31:10  18 of 34 PASS not_null_silver__transactions_ATTACHED_GAS........................ [PASS in 3.33s]
00:31:10  20 of 34 START test not_null_silver__transactions_BLOCK_ID...................... [RUN]
00:31:12  19 of 34 PASS not_null_silver__transactions_BLOCK_HASH.......................... [PASS in 3.71s]
00:31:12  21 of 34 START test not_null_silver__transactions_BLOCK_TIMESTAMP............... [RUN]
00:31:13  20 of 34 PASS not_null_silver__transactions_BLOCK_ID............................ [PASS in 2.93s]
00:31:13  22 of 34 START test not_null_silver__transactions_GAS_USED...................... [RUN]
00:31:15  21 of 34 PASS not_null_silver__transactions_BLOCK_TIMESTAMP..................... [PASS in 2.70s]
00:31:15  23 of 34 START test not_null_silver__transactions_NONCE......................... [RUN]
00:31:16  22 of 34 PASS not_null_silver__transactions_GAS_USED............................ [PASS in 2.82s]
00:31:16  24 of 34 START test not_null_silver__transactions_SIGNATURE..................... [RUN]
00:31:18  23 of 34 PASS not_null_silver__transactions_NONCE............................... [PASS in 2.97s]
00:31:18  25 of 34 START test not_null_silver__transactions_TRANSACTION_FEE............... [RUN]
00:31:19  24 of 34 PASS not_null_silver__transactions_SIGNATURE........................... [PASS in 2.67s]
00:31:19  26 of 34 START test not_null_silver__transactions_TX............................ [RUN]
00:31:21  25 of 34 PASS not_null_silver__transactions_TRANSACTION_FEE..................... [PASS in 3.07s]
00:31:21  27 of 34 START test not_null_silver__transactions_TX_HASH....................... [RUN]
00:31:24  27 of 34 PASS not_null_silver__transactions_TX_HASH............................. [PASS in 3.70s]
00:31:24  28 of 34 START test not_null_silver__transactions_TX_RECEIVER................... [RUN]
00:31:27  28 of 34 PASS not_null_silver__transactions_TX_RECEIVER......................... [PASS in 2.94s]
00:31:27  29 of 34 START test not_null_silver__transactions_TX_SIGNER..................... [RUN]
00:31:29  16 of 34 PASS dbt_expectations_expect_row_values_to_have_recent_data_silver__transactions_BLOCK_TIMESTAMP__day__1 [PASS in 25.24s]
00:31:29  30 of 34 START test not_null_silver__transactions_TX_STATUS..................... [RUN]
00:31:31  29 of 34 PASS not_null_silver__transactions_TX_SIGNER........................... [PASS in 3.48s]
00:31:31  31 of 34 START test not_null_silver__transactions__INGESTED_AT.................. [RUN]
00:31:32  30 of 34 PASS not_null_silver__transactions_TX_STATUS........................... [PASS in 2.99s]
00:31:32  32 of 34 START test not_null_silver__transactions__INSERTED_TIMESTAMP........... [RUN]
00:31:33  17 of 34 PASS dbt_utils_unique_combination_of_columns_silver__transactions_tx_hash [PASS in 25.68s]
00:31:33  33 of 34 START test tx_gaps_silver__transactions_block_id__TX_HASH__tx_count.... [RUN]
00:31:34  31 of 34 PASS not_null_silver__transactions__INGESTED_AT........................ [PASS in 3.11s]
00:31:34  34 of 34 START test unique_silver__transactions_TX_HASH......................... [RUN]
00:31:35  32 of 34 PASS not_null_silver__transactions__INSERTED_TIMESTAMP................. [PASS in 3.31s]
00:33:25  34 of 34 PASS unique_silver__transactions_TX_HASH............................... [PASS in 110.73s]
00:34:15  33 of 34 WARN 283 tx_gaps_silver__transactions_block_id__TX_HASH__tx_count...... [WARN 283 in 162.42s]
00:35:29  26 of 34 PASS not_null_silver__transactions_TX.................................. [PASS in 249.73s]
00:35:29
00:35:29  Finished running 34 tests, 1 hook in 286.61s.
00:35:29
00:35:29  Completed with 1 warning:
00:35:29
00:35:29  Warning in test tx_gaps_silver__transactions_block_id__TX_HASH__tx_count (models/silver/silver__transactions.yml)
00:35:29    Got 283 results, configured to warn if != 0
00:35:29
00:35:29    compiled SQL at target/compiled/near/models/silver/silver__transactions.yml/tx_gaps_silver__transactions_block_id__TX_HASH__tx_count.sql
00:35:29
00:35:29  Done.  [RUN]
00:37:44  1 of 1 OK hook: near.on-run-start.0............................................. [OK in 0.00s]
00:37:44
00:37:44  Concurrency: 4 threads (target='dev')
00:37:44
00:37:44  1 of 1 START view model core.fact_transactions.................................. [RUN]
00:37:47  1 of 1 OK created view model core.fact_transactions............................. [SUCCESS 1 in 2.88s]
00:37:47
00:37:47  Finished running 1 view model, 1 hook in 13.83s.
00:37:47
00:37:47  Completed successfully
00:37:47
00:37:47  Done. PASS=1 WARN=0 ERROR=0 SKIP=0 TOTAL=1

dbt_test
root@f82ab8553319:/near/models/core# dbt test --select core__fact_transactions
00:38:16  Running with dbt=1.0.0
00:38:22  Found 38 models, 605 tests, 0 snapshots, 0 analyses, 628 macros, 1 operation, 1 seed file, 2 sources, 0 exposures, 0 metrics
00:38:22
00:38:30
00:38:30  Running 1 on-run-start hook
00:38:30  1 of 1 START hook: near.on-run-start.0.......................................... [RUN]
00:38:30  1 of 1 OK hook: near.on-run-start.0............................................. [OK in 0.00s]
00:38:30
00:38:30  Concurrency: 4 threads (target='dev')
00:38:30
00:38:30  1 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_ATTACHED_GAS__NUMBER__FLOAT [RUN]
00:38:30  2 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_HASH__STRING__VARCHAR [RUN]
00:38:30  3 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_ID__NUMBER__FLOAT [RUN]
00:38:30  4 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_TIMESTAMP__TIMESTAMP_NTZ [RUN]
00:38:35  4 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_TIMESTAMP__TIMESTAMP_NTZ [PASS in 4.64s]
00:38:35  5 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_GAS_USED__NUMBER__FLOAT [RUN]
00:38:35  2 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_HASH__STRING__VARCHAR [PASS in 4.90s]
00:38:35  6 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_NONCE__NUMBER [RUN]
00:38:35  3 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_BLOCK_ID__NUMBER__FLOAT [PASS in 4.94s]
00:38:35  7 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_SIGNATURE__STRING__VARCHAR [RUN]
00:38:35  1 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_ATTACHED_GAS__NUMBER__FLOAT [PASS in 5.11s]
00:38:35  8 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TRANSACTION_FEE__NUMBER__FLOAT [RUN]
00:38:40  8 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TRANSACTION_FEE__NUMBER__FLOAT [PASS in 5.22s]
00:38:40  9 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_HASH__STRING__VARCHAR [RUN]
00:38:41  6 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_NONCE__NUMBER [PASS in 6.03s]
00:38:41  10 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_RECEIVER__STRING__VARCHAR [RUN]
00:38:41  5 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_GAS_USED__NUMBER__FLOAT [PASS in 6.70s]
00:38:41  11 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_SIGNER__STRING__VARCHAR [RUN]
00:38:42  7 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_SIGNATURE__STRING__VARCHAR [PASS in 6.69s]
00:38:42  12 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_STATUS__STRING__VARCHAR [RUN]
00:38:44  9 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_HASH__STRING__VARCHAR [PASS in 3.33s]
00:38:44  13 of 29 START test dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX__OBJECT__VARIANT [RUN]
00:38:44  10 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_RECEIVER__STRING__VARCHAR [PASS in 3.39s]
00:38:44  14 of 29 START test dbt_expectations_expect_row_values_to_have_recent_data_core__fact_transactions_BLOCK_TIMESTAMP__day__1 [RUN]
00:38:45  11 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_SIGNER__STRING__VARCHAR [PASS in 3.39s]
00:38:45  15 of 29 START test dbt_utils_unique_combination_of_columns_core__fact_transactions_tx_hash [RUN]
00:38:45  12 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX_STATUS__STRING__VARCHAR [PASS in 3.54s]
00:38:45  16 of 29 START test not_null_core__fact_transactions_ATTACHED_GAS............... [RUN]
00:38:48  13 of 29 PASS dbt_expectations_expect_column_values_to_be_in_type_list_core__fact_transactions_TX__OBJECT__VARIANT [PASS in 3.84s]
00:38:48  17 of 29 START test not_null_core__fact_transactions_BLOCK_HASH................. [RUN]
00:38:49  16 of 29 PASS not_null_core__fact_transactions_ATTACHED_GAS..................... [PASS in 3.32s]
00:38:49  18 of 29 START test not_null_core__fact_transactions_BLOCK_ID................... [RUN]
00:38:52  17 of 29 PASS not_null_core__fact_transactions_BLOCK_HASH....................... [PASS in 4.20s]
00:38:52  19 of 29 START test not_null_core__fact_transactions_BLOCK_TIMESTAMP............ [RUN]
00:38:52  18 of 29 PASS not_null_core__fact_transactions_BLOCK_ID......................... [PASS in 3.15s]
00:38:52  20 of 29 START test not_null_core__fact_transactions_GAS_USED................... [RUN]
00:38:52  14 of 29 PASS dbt_expectations_expect_row_values_to_have_recent_data_core__fact_transactions_BLOCK_TIMESTAMP__day__1 [PASS in 8.09s]
00:38:52  21 of 29 START test not_null_core__fact_transactions_NONCE...................... [RUN]
00:38:55  20 of 29 PASS not_null_core__fact_transactions_GAS_USED......................... [PASS in 3.62s]
00:38:55  22 of 29 START test not_null_core__fact_transactions_SIGNATURE.................. [RUN]
00:38:56  21 of 29 PASS not_null_core__fact_transactions_NONCE............................ [PASS in 3.09s]
00:38:56  23 of 29 START test not_null_core__fact_transactions_TRANSACTION_FEE............ [RUN]
00:38:56  19 of 29 PASS not_null_core__fact_transactions_BLOCK_TIMESTAMP.................. [PASS in 3.94s]
00:38:56  24 of 29 START test not_null_core__fact_transactions_TX......................... [RUN]
00:38:59  22 of 29 PASS not_null_core__fact_transactions_SIGNATURE........................ [PASS in 3.47s]
00:38:59  25 of 29 START test not_null_core__fact_transactions_TX_HASH.................... [RUN]
00:38:59  23 of 29 PASS not_null_core__fact_transactions_TRANSACTION_FEE.................. [PASS in 3.62s]
00:38:59  26 of 29 START test not_null_core__fact_transactions_TX_RECEIVER................ [RUN]
00:39:02  26 of 29 PASS not_null_core__fact_transactions_TX_RECEIVER...................... [PASS in 2.96s]
00:39:02  27 of 29 START test not_null_core__fact_transactions_TX_SIGNER.................. [RUN]
00:39:03  25 of 29 PASS not_null_core__fact_transactions_TX_HASH.......................... [PASS in 4.10s]
00:39:03  28 of 29 START test not_null_core__fact_transactions_TX_STATUS.................. [RUN]
00:39:03  15 of 29 PASS dbt_utils_unique_combination_of_columns_core__fact_transactions_tx_hash [PASS in 18.28s]
00:39:03  29 of 29 START test unique_core__fact_transactions_TX_HASH...................... [RUN]
00:39:06  27 of 29 PASS not_null_core__fact_transactions_TX_SIGNER........................ [PASS in 3.63s]
00:39:07  28 of 29 PASS not_null_core__fact_transactions_TX_STATUS........................ [PASS in 3.91s]
00:41:05  29 of 29 PASS unique_core__fact_transactions_TX_HASH............................ [PASS in 121.94s]
00:42:37  24 of 29 PASS not_null_core__fact_transactions_TX............................... [PASS in 221.71s]
00:42:37
00:42:37  Finished running 29 tests, 1 hook in 255.53s.
00:42:38
00:42:38  Completed successfully
00:42:38
00:42:38  Done. PASS=29 WARN=0 ERROR=0 SKIP=0 TOTAL=29

[x] Any comparison between prod and dev for any schema change

added tx_status to transactions table

Checklist

[x] Follow dbt style guide
[x] Tag the person(s) responsible for reviewing proposed changes: @forgxyz
[x] Notes to deployment, if a full-refresh is needed for any table

Need to full-refresh

[x] Run git merge main to pull any changes from remote into your branch prior to merge.

Updated description with the latest dbt run and test @forgxyz

Sorry to crash: this transaction reports a Fail, but is a success on the explorer:
https://explorer.near.org/transactions/8NwX5WyeDi8GKsMHuaF1sVJLAw9ySvtc2X1hVkuLkeAg

Sorry to crash: this transaction reports a Fail, but is a success on the explorer:
https://explorer.near.org/transactions/8NwX5WyeDi8GKsMHuaF1sVJLAw9ySvtc2X1hVkuLkeAg
This is potentially because the method tries to stake, fails, and proceeds anyway.

Okay, I checked this one and from my findings, all transactions succeeded if they have a SuccessReceiptId in their list of receipts. Here's the query I made:
WITH receipts AS (
    SELECT
        tx_hash,
        VALUE :outcome :status AS status_value,
        SUM(
            VALUE :outcome :gas_burnt :: NUMBER
        ) over (
            PARTITION BY tx_hash
            ORDER BY
                tx_hash DESC
        ) AS receipt_gas_burnt,
        SUM(
            VALUE :outcome :tokens_burnt :: NUMBER
        ) over (
            PARTITION BY tx_hash
            ORDER BY
                tx_hash DESC
        ) AS receipt_tokens_burnt
    FROM
        transactions,
        LATERAL FLATTEN(
            input => tx :receipt
        )
),
combined_table AS (
    SELECT
        tx_hash,
        status_value
    FROM
        receipts
    WHERE
        status_value :SuccessReceiptId IS NOT NULL
    UNION ALL
    SELECT
        tx_hash,
        status_value
    FROM
        receipts
    WHERE
        status_value :Failure IS NOT NULL
),
FINAL AS (
    SELECT
        tx_hash,
        arrayagg(status_value) within GROUP (
            ORDER BY
                status_value DESC
        ) AS status_array
    FROM
        combined_table
    GROUP BY
        tx_hash
    ORDER BY
        tx_hash DESC
)
SELECT
    *
FROM
    FINAL
WHERE
    status_array [0] :Failure IS NOT NULL
    AND status_array [1] :SuccessReceiptId IS NOT NULL
LIMIT
    10000

To check if each transaction actually succeeded in the explorer, I wrote a Jupyter Notebook to call the API and retrieve the data for each transaction. All transactions in the said query succeeded even if they had a failure receipt in them, as written in this output csv. Conversely, I replaced the retrieval of SuccessReceiptId to SuccessValue instead and the result was there were transactions that failed.

With that being said, I think the condition in getting the tx_status if the transaction had a SuccessReceiptId, or else it failed.
cc @forgxyz

Interesting @D0R11, so even if a receipt failed the transaction could be a success?

Interesting @D0R11, so even if a receipt failed the transaction could be a success?

Yes, as long as the transaction with a failed receipt also has a SuccessReceiptId in it.

Interesting @D0R11, so even if a receipt failed the transaction could be a success?

Yes, as long as the transaction with a failed receipt also has a SuccessReceiptId in it.

@forgxyz hi forg, apologies if I didn't have any updates the past few days. I was still querying in the past few days but I don't have significant progress on this issue. It turns out that there are also transactions that failed with success_receipt_ids/success_values in them. I am reframing my perspective on how to approach this problem because it's somewhat difficult to draw a line between a successful and failed transaction.
I was wondering where does the transaction status in the Nearblocks API come from? Maybe we can source that one out in our chainwalkers or fetch them separately instead?


[1694] Remove timeline entries for changes made in draft

Context
https://trello.com/c/pkGdZvyW/1694-audit-timeline-entries-being-generated-whilst-records-are-in-draft
Changes proposed in this pull request
Filter out any audits (that aren't the audit representing creating a trainee) that happen before a trainee is submitted for TRN.
What it looks like now:

Guidance to review

Visit a non-draft trainee
Click on the timeline tab
Check that no entries are visible between Record created and Submitted for TRN

 Audit timeline entries being generated whilst records are in draft

All good


Update RE2.

This now uses absl directly in the main branch, no need to reference a particular branch.

CC @junyer

Thanks!

Codecov Report
Patch and project coverage have no change.

Comparison is base (0bcc1e5) 92.85% compared to head (8092f04) 92.85%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1937   +/-   ##
=======================================
  Coverage   92.85%   92.85%
=======================================
  Files         355      355
  Lines       26069    26069
=======================================
  Hits        24206    24206
  Misses       1863     1863

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Too strong restriction for matchers

Seems like the requirement only the 'receive', 'have_received' and 'receive_messages' matchers are supported with 'allow(...).to' is too restrictive.
For example, I provide the matcher, that is sort of semi-transparent extension for the receive
I believe it could work, but it doesn't because of the restriction above. Do we really need it?
Surely, I could just reload the receive method (and actually I did) and then monkey-patch the whole RSpec::Mocks::Matchers::Receive class. But also I do need to reload both the allow and expect to switch client to client.connection. It works, but seems far too messy, not to mention dark sides of monkey patching by itself.
I think, it would be far better way to allow developer to shoot himself :gun:  in the foot, not restricting him so strongly.

Actually I understood that a proposed solution is not sufficient. What I do need is a way to extend receive matcher to make it accessible to both expect and allow (my solution doesn't do this)

Exactly.  Matchers in general don't work with allow.  allow doesn't even use the matcher protocol, because it has to act differently than expect does.  It actually calls setup_allowance on the matcher, but that's not a published public API.
I think you could get allow(client).to receive_request(:get, url) to work if you define receive_request as a method that delegates to receive internally -- which would just return the same kind of object that receive returns which allow would understand.

Hi, @myronmarston, and thank you for the suggestion!
Yes, this is what I've done eventually.
Though this works, still there is one more issue. Seems like the restriction requires exact classes (RSpec::Mocks::Matchers::Receive and so on) for the allowance matchers. If it allowed subclassing too, I could remove all this mess from the #receive_request and just define my own receiver, and do something like this:
module Receiver
  def initialize(method, path = nil)
    # ...
    super # ...
  end

  def where(&block)
    # ...
  end
end

class ReceiveRequest < RSpec::Mocks::Matchers::Receive
  include Receiver
end

class HaveReceivedRequest < RSpec::Mocks::Matchers::HaveReceived
  include Receiver
end

def receive_request(*args)
  ReceiveRequest.new(*args)
end

def have_received_request(*args)
  HaveReceivedRequest.new(*args)
end

Because I've intentionally kept myself from monkey-patching the Receive class, I had to implement the initializer in this weird way outside of the class. It works but not as clean as it could be.

Seems like the restriction requires exact classes (RSpec::Mocks::Matchers::Receive and so on) for the allowance matchers. If it allowed subclassing too

Looking at the implementation, it looks like it does allow subclasses (using classes in a case statement will match on instances of that class or any subclass).
What makes you say it does not allow subclassing?

In the exampe as shown above, I received:
only the `receive`, `have_received` and `receive_messages` matchers are supported with `allow(...).to`, but you have provided: #<Evil::Client::RSpec::ReceiveRequest:0x00000003de14f0>

Can you push up a repo containing a reproducible example?

I'll try doing this a bit later, because its a part of private repo. Need some time to carefully extract it from there

Well, i've decided to provide a simplest one :)
require "rspec"

describe "inheriting", :focus do
  ReceiveRequest = Class.new(RSpec::Mocks::Matchers::Receive)

  def receive_request(method)
    ReceiveRequest.new(method, nil)
  end

  it "works" do
    client = double

    allow(client).to  receive_request(:call)
    expect(client).to receive_request(:call)

    client.call
  end
end

Thanks for the example.  I see the problem now.  The case statement I referred to before is used for a different situation.  The check for this situation is here:
https://github.com/rspec/rspec-mocks/blob/42ef957e0af1813c0933f29588121e78fadb8244/lib/rspec/mocks/targets.rb#L40-L42
...which just looks at the matcher class name (it's a simple way to ask, "is this one of the rspec-mocks matchers?")
That can certainly be changed to a more robust mechanism that allows subclasses.  Also, for now you can just define your subclass as a constant nested under RSpec::Mocks::Matchers:: to work around this issue.

Also, I meant to ask: are you willing to work up a PR to fix this?  It's generally hard for us to find time for things like this that only one user has asked for.


Fix nullpointer exception

ESP-IDFv4 requires rmt_driver_install to be called even if a custom interrupt handler is registered. You may want to add this to your awesome readme file.

What makes you believe that? The documentation seems to say otherwise:
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/rmt.html#configure-driver
"
When calling rmt_driver_install() to use the system RMT driver, a default ISR is being installed. In such a case you cannot register a generic ISR handler with rmt_isr_register().
"
and I am not getting null pointer exceptions in the checked in main.cpp example application or anything else I've written.
So what makes you believe such a thing?

Thanks for testing. You are right this only crashes on the current master branch of esp-idf.

Well, that's still an issue. I will re-open and test with master, it should work. I hope your fix isn't the right one though, it flys in the face of the documentation. I can also raise an issue with upstream.... they may have a bug in master they're not aware of.


[Review] ENH Recipe updates for specific RAPIDS ccache pkg

Ccache must be built from source using a specific version in it's commit history. This modifies the origin ccache-feedstock to build ccache this way.

Using https://gpuci.gpuopenanalytics.com/job/gpuci/job/conda/job/ccache-fork/ to build/upload this conda package


Attributes for step definitions and hooks

PHP 8.0 will have Attributes (https://wiki.php.net/rfc/attributes_v2)
A natural way to use these in Behat is for step definitions.
Before:
/**
 * @beforeScenario
 */
function getStuffReady()
{
   //...
}

/**
 * @Given :user has an idea to :idea
 */
function userHasAnIdeaTo($user, $idea)
{
    //...
}

After:
<< BeforeScenario >>
function getStuffReady()
{
   //...
}

<< Given(':user has an idea to :idea') >>
function userHasAnIdeaTo($user, $idea)
{
    //...
}

This would be slightly less fragile than the current regex approach (although to be fair it's never really bitten me)
Because the attributes will have an FCQN, we could support 'different' step definition classes for different types of pattern (e.g. Gherkin vs Turnip vs future syntaxes).
There are other places in the code we may want to use attributes, not least some of the empty 'tagging' interfaces like SnippetAcceptingContext

There would be some added complexity when generating snippets because we would need to use the classes at head of file

I've been looking into this for a bit, and my first thought would be:

Introduce Attribute classes for the necessary elements (Given, When, Then, BeforeScenario, etc, etc). Using e.g. the call definitions directly would couple them too much to attributes and would need the properties to be public - these properties are now private so that would be a BC break.
Introduce a Behat\Behat\Context\Reader\AttributeContextReader, similar in setup to Behat\Behat\Context\Reader\AttributeContextReader but looking at Attributes rather then at annotations.
Introduce a Behat\Behat\Context\Reader\CompositeContextReader that combines the results from multiple ContextReaders. Specifically here the results of the AnnotationContextReader as well as the AttributeContextReader.
Register this CompositeContextReader in the DI container instead of the AnnotationContextReader so that can read both annotations and attributes.

The CompositeContextReader has the advantage that at some in the (probably far away) future the AnnotationContextReader and reader can be removed and then the AttributeContextReader can be registered as reader directly. At that point the CompositeContextReader can be removed from the code too.
An open question that needs to be handled here: what to do when some method has an attribute as well as an annotation. Will it just accept both? Does need to remove duplicates? Does it need to warn/error when the annotation and attribute say different things about the same method?

what to do when some method has an attribute as well as an annotation

The main reason I can see for this situation arising (aside from forgetting to remove the docblocks) is in a codebase that supports 7.x and 8.x in parallel. In that case maintainers may want to have both attributes and docblocks, and rely on test failures to detect when the two are not in sync.

Does need to remove duplicates?

We'd need to handle it explicitly somehow. The current code has a runtime error if a step can't be matched to exactly one matcher (each step is run against every matcher every time). This is meant to guard against things like:
/**
 * @Given /I have a .*/
 */
function foo(){}

/**
 * @Given I have a cat
 */
function foo(){}

but also has the effect of currently disallowing:
/**
 * @Given I have a cat
 * @Given I have a cat
 */
function foo(){}

The simplest solution is probably that if the attributes are present, the docblock isn't read

Having considered more, I guess we could change the logic to allow duplicate steps at runtime if they:

match the same method
result in the same captured arguments

I think then we'd be able to simply register all the docblocks + all the attributes without disambiguating
This would then be fine:
/**
 * @Given I have :count bananas
 */
#[Given( 'I have :count bananas' )]

The current code has a runtime error if a step can't be matched to exactly one matcher (each step is run against every matcher every time)

That seems to be "further down the line" than the annotation readers. Which it should be, it's a separate concern.
So it seems to me if we just read Attributes and convert them to Call definitions they'll be sent down the same path as the the Call definitions read for Annotations and the whole reading of Attributes is just an infrastructural concern that doesn't need concern itself with those issues at all.
I'll see if I can take a stab at this. Seems fun 🙂

Well, to me, we should just register both definitions, just like we support using multiple annotations on the same method.
I don't think we need to do a special case for the case where you register steps both with annotations and attributes at the same time for the same step definitions. I don't see any need for such complexity: if you need to support PHP 7, use the annotation way. That also works with PHP 8. Duplicating the registration does not simplify anything for context authors (as they now need to keep the duplicates in sync)

Makes perfect sense to me 👍

Should be all covered in v3.9.0 and v3.10.0 thanks to @rpkamp's PRs 🥇

@pamil What hasn't been covered yet is code generation. That will still generate new steps using annotations rather than attributes.
But maybe that would be better off in a new issue?

That probably deserves a separate issue

@rpkamp good catch, we could handle that in a separate issue indeed

I've created an issue: https://github.com/Behat/Behat/issues/1379


2.0 update

Updated plugin to use config files in place of database settings, and to use play nicely with Craft 2.5 styles/conventions. Renamed plugin from LabelEnvironment to EnvironmentLabel.

@michaelrog 👍


Error: no configuration files

Is there an existing issue for this?

[X] I have searched the existing issues

Bootstrap or Starter Module Deployment? (Required)
starter_module
ALZ-PowerShell-Module Version (Required)
1.1.6
alz-terraform-accelerator Version (Required)
1.1.2
Starter Module (Required)
complete
Input arguments of the ALZ-PowerShell-Module (Required)
---
starter_module: "complete"
azure_devops_personal_access_token: "***"
azure_devops_organization_name: "autocloudarc"
bootstrap_location: "centralus"
use_separate_repository_for_pipeline_templates: "true"
bootstrap_subscription_id: "***"
service_name: "alz"
environment_name: "mgmt"
postfix_number: "1"
azure_devops_use_organisation_legacy_url: "false"
azure_devops_create_project: "true"
azure_devops_project_name: "prj-tfm-acc-06"
azure_devops_authentication_scheme: "WorkloadIdentityFederation"
use_self_hosted_agents: "false"
use_private_networking: "false"

# Allow access to the storage account from the current IP address. We recommend this is kept off for security
allow_storage_access_from_my_ip: "true"
apply_approvers<EMAIL_ADDRESS>root_parent_management_group_display_name: "Tenant Root Group"
default_location: "centralus"
default_postfix: "landing-zone"
root_parent_management_group_id: "orgid"
subscription_id_connectivity: "***"
subscription_id_identity: "***"
subscription_id_management: "***"
configuration_file_path: "<base-path>\\v1.1.2\\templates\\complete\\config.yaml"

Contents of the configuration file used for the complete starter module. (Optional)
# This file contains templated variables to avoid repeating the same hard-coded values.
# Templated variables are denoted by the dollar curly braces token. The following details each templated variable that you can use:
# `default_location`: This is an Azure location sourced from the `default_location` variable. This can be used to set the location of resources.
# `default_postfix`: This is a string sourced from the variable `default_postfix`. This can be used to append to resource names for consistency.
# `root_parent_management_group_id`: This is the id of the management group that the ALZ hierarchy will be nested under.
# `subscription_id_identity`: The subscription ID of the subscription to deploy the identity resources to, sourced from the variable `subscription_id_identity`.
# `subscription_id_connectivity`: The subscription ID of the subscription to deploy the connectivity resources to, sourced from the variable `subscription_id_connectivity`.
# `subscription_id_management`: The subscription ID of the subscription to deploy the management resources to, sourced from the variable `subscription_id_management`.
---
archetypes:  # `caf-enterprise-scale` module, add inputs as listed on the module registry where necessary.
  root_name: es
  root_id: Enterprise-Scale
  subscription_id_connectivity: ${subscription_id_connectivity}
  subscription_id_identity: ${subscription_id_identity}
  subscription_id_management: ${subscription_id_management}
  root_parent_id: ${root_parent_management_group_id}
  deploy_corp_landing_zones: true
  deploy_online_landing_zones: true
  default_location: ${default_location}
  disable_telemetry: true
  deploy_management_resources: true
  configure_management_resources:
    location: ${default_location}
    settings:
      security_center:
        config:
          email_security_contact: "security_contact@replace_me"
    advanced:
      asc_export_resource_group_name: rg-asc-export
      custom_settings_by_resource_type:
        azurerm_resource_group:
          management:
            name: rg-management
        azurerm_log_analytics_workspace:
          management:
            name: log-management
        azurerm_automation_account:
          management:
            name: aa-management
connectivity:
  hubnetworking:  # `hubnetworking` module, add inputs as listed on the module registry where necessary.
    hub_virtual_networks:
      primary:
        name: vnet-hub
        resource_group_name: rg-connectivity
        location: ${default_location}
        address_space:
          - <IP_ADDRESS>/16
        firewall:
          name: fw-hub
          sku_name: AZFW_VNet
          sku_tier: Standard
          subnet_address_prefix: <IP_ADDRESS>/24
        virtual_network_gateway:  # `vnet-gateway` module, add inputs as listed on the module registry where necessary.
          name: vgw-hub
          sku: VpnGw1
          type: Vpn
          subnet_address_prefix: <IP_ADDRESS>/24

Debug Output/Panic Output (Optional)
##[debug]addSpnToEnvironment=true
##[debug]<guid-redacted> auth scheme = WorkloadIdentityFederation
##[debug]exec tool: /usr/bin/pwsh
##[debug]arguments:
##[debug]   -NoLogo
##[debug]   -NoProfile
##[debug]   -NonInteractive
##[debug]   -ExecutionPolicy
##[debug]   Unrestricted
##[debug]   -Command
##[debug]   . '/home/vsts/work/_temp/azureclitaskscript1708011041085.ps1'
/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command . '/home/vsts/work/_temp/azureclitaskscript1708011041085.ps1'
Running: terraform plan -out=tfplan -input=false
╷
│ Error: No configuration files
│
│ Plan requires configuration to be present. Planning without a configuration
│ would mark everything for destruction, which is normally not what is
│ desired. If you would like to destroy everything, run plan with the
│ -destroy option. Otherwise, create a Terraform configuration file (.tf
│ file) and try again.
╵
##[debug]$LASTEXITCODE: 1
##[debug]Exit code 1 received from tool '/usr/bin/pwsh'
##[debug]STDIO streams have closed for tool '/usr/bin/pwsh'
##[debug]task result: Failed
##[error]Script failed with exit code: 1
##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1
##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1
##[debug]which 'az'
##[debug]found: '/usr/bin/az'

Expected Behaviour (Required)
The terraform plan task should have executed without an error.
Actual Behaviour (Required)
The "Terraform plan for apply" task failed.

Steps to Reproduce (Optional)
Manually run the 02 Azure Landing Zone Continuous Delivery pipeline from the Azure DevOps pipeline GUI.
Important Factoids (Optional)
No
References (Optional)
None.

Sorry for the false alarm. I noticed that I made a mistake with the root_parent_management_group_id: value and corrected it. Since then, I was not able to reproduce the issue any longer, but not sure if this was a (or the only) contributing factor. Anyway, all set now and closing this issue.

Can you show us the contents of your repository? This error seems to indicate there are no .tf files in there?

@autocloudarc I see you closed this issue, does that mean it is resolved? Thanks

@jaredfholgate Yes, it's resolved now. Thanks for following up, although I can't explain why exactly except that I had a mistake in my input file for the root_parent_management_group_id: "orgid" key/value pari. "orgid" should have been the guid for the tenant id, but after fixing this it works.


Mirror profiler graph shows wrong numbers.

Describe the bug
Mirror profiler graph shows wrong numbers, table shows correct numbers.
Looks likes its showing KB, either way, graph is a few hundred to few thousand off what it should be.
The difference on a joining client is massive, the host graph is not as bad.
Repro project
Latest unchanged mirror profiler.
To Reproduce
Have mirror profiler open, select the gear cog to show bandwidth (bytes /s).
Start a game, join with a client, trigger a network message (sync var or movement).
The bytes amounts in the table, do not match the graph plots.
Screenshots

(joining client)
Screenshot from Maq, take note on the left side of the window, the huge numbers, and the table shows small numbers, they do not match.

8,000 bytes per second showing, when small things in the table around 50 byte sync vars are updated?
(just noticed, i changed the text (bytes /s) to bits, whilst attempting to search for the code that displays the graph results, ignore this, just a text change i forgot to switch back for screenshot)

(host)
The graph and table amounts are not as huge as the joining player, but still not accurate.
Additional context
Its been brought up and discussed in the #watercooler discord thread.

@paulpach when you have a minute, could you take a look and see if it's valid or not please?

@JesusLuvsYooh the reason is that they show different things,  which I understand is very misleading.
the chart is trying to show how many bytes went in the wire,  while the table shows how big the message was.
the chart tries to estimate TCP/IP headers, resends and acks,  while the table does not do that.


Error while inserting Metadata Records through .csv file

I am using latest version of CLI.
While inserting custom metadata records with below command.
sfdx force:cmdt:record:insert --filepath  (path to .csv)  --typename  (Metadata sObj Name)
result:(Error)
Cannot read properties of undefined (reading 'fullName')

Hey @cristiand391 ,
I have tried appending the records through Linux machine  and it worked.
I'm not sure why for windows it's not working. But Currently I'm okay so I'll mark it as close.
If I found any further issue I'll raise a issue in suggested templated format.
Thanks!!!!


🐛 Update manifest.json's start_url to bare root path

Category:

Bugfix

Overview

The "add to homescreen" functionality on Android is broken. When adding your dashboard to your homescreen it points to /index.html which, in some server/proxy configurations, redirects to a 404 page. In my case I'm running a self-hosted Docker container.
Judging by some issue comments, this may also fix an authentication bug but I cannot confirm this.

Issue Number #988 is the main one, but based on comments #1019 may also be resolved. #628 is also related but more for context than anything.
Code Quality Checklist

[x] All changes are backwards compatible
[x] All lint checks and tests are passing
[x] There are no (new) build warnings or errors
[ ] Bumps version, if new feature added

I've confirmed via the netlify deployment URL that adding to homescreen is now successful 👍

It's still valid - just awaiting review

Thank you!


Add logparser to latest

ioBroker Forum Thread: https://forum.iobroker.net/topic/31969/test-adapter-log-parser-v0-x-x-github
All requirements are met, also Compact Mode is successfully tested per https://forum.iobroker.net/topic/32789/anleitung-für-adapter-entwickler-compact-mode-testen

Adapter is ready for Latest! :-)

CHECK!

RE-CHECK!

Automated adapter checker
ioBroker.logparser

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "logparser" in latest repository

Add comment "RE-CHECK!" to start check anew

Thank you @Apollon77 for your review — I have addressed or considered everything you mentioned.

Thank you very much!


Replace recursive-open-struct with OpenStruct

Add tests to ensure that:

Keys of nested hashes are not coerced to other types
Nested hashes are not coerced to OpenStructs

Pardon my ignorance on this one, but why OpenStruct and not plain Struct?

@cesarfigueroa Struct and OpenStruct have different interfaces. Struct.new actually returns a Class:
irb > Point = Struct.new(:x, :y)
=> Point
irb > p = Point.new(1, 2)
=> #<struct Point x=1, y=2>

Which is not really what we want. We want a Hash-like thing that you can dynamically set fields on:
irb > require 'ostruct'
=> true
irb > o = OpenStruct.new
=> #<OpenStruct>
irb > o.foo = 'bar'
=> "bar"
irb > o.foo
=> "bar"

Basically, Struct and OpenStruct are similar in the way that Java and JavaScript are similar :smile:

@mikenichols Thanks for the explanation on that one :sparkles:


feat(deterministic-test): add tests of random writes and consistency

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Related https://github.com/risingwavelabs/risingwave-test/issues/431. See backgroud there.
This is a very first version. I'll try to add more actions, such as triggering compaction and group splitting later.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

@Li0k @zwang28 @Little-Wallace PTAL. We may add more specific workload generators based on this PR for compaction testing we are planning to do as mentioned here.

Decreased the data size a lot to make it finish in reasonable time (now 5 min 10 s)


.gitconfig parser

This PR adds a new config format - again. This time it's based on git's very own "gitconfig" format. Unfortunately it's not entirely trivial and to date there seem to be no git config handlers in pure Go. All I've found were shelling out to the git binary (which does make sense, as most of the options do have default values that only the binary would know about).
But I still think this format is best suited for our use case since it does combine human and machine accessibility with the right amount of flexibility.
WARNING: This will certainly break some things! The current config handling is so deeply wired in and mixed with our (ab-)use of the context package that I'm unlikely to catch every possible breakage on my own. Our users will have to help testing this. Either before it's released or afterwards. But the upshot is that this has the potential to allow us to resolve at least half a dozen outstanding issues and remove quite a bit of legacy from the codebase (more so once we drop the config backwards compatability layer). We could even consider adopting the parser for the secrets themselves in the future.

[x] Describe what this PR is doing here
[x] and in our docs
[x] and add some examples how it can be leveraged
[x] Make unit tests pass
[x] Make integration tests pass
[x] Support read-only mounts, see https://github.com/gopasspw/gopass/issues/1878
[x] Add autosync option, see https://github.com/gopasspw/gopass/issues/2387
[x] Add config.worktree support
[x] Move domain aliases to the config
[x] Review https://github.com/gopasspw/gopass/issues/1819
[x] Review https://github.com/gopasspw/gopass/issues/1798
[x] Review https://github.com/gopasspw/gopass/issues/1567
[x] Support autoclip on show, see https://github.com/gopasspw/gopass/issues/1764

Fixes #1567
Fixes #1764
Fixes #1819
Fixes #1878
Fixes #2387
Fixes #2408
Fixes #2418
Signed-off-by: Dominik Schulz<EMAIL_ADDRESS>

@AnomalRoil Thanks a lot. I'll probably not get to address the open comments until tomorrow anyway. If you could leave any remaining comments today that'd be fantastic.
Maybe we can wrap this up until the end of the week :smiley:

Ah, it seems a few extra documentation places needs updates too:

https://github.com/gopasspw/gopass/blob/dcea35c0c97ead9529da76797eba24d3ed08bdab/docs/usecases/readyonly-store.md (also the name of that file seem wrong, why "ready" and not "read"?)
https://github.com/gopasspw/gopass/blob/dcea35c0c97ead9529da76797eba24d3ed08bdab/docs/setup.md
https://github.com/gopasspw/gopass/blob/dcea35c0c97ead9529da76797eba24d3ed08bdab/docs/config.md (still contains mention of "autoclip")
https://github.com/gopasspw/gopass/blob/dcea35c0c97ead9529da76797eba24d3ed08bdab/docs/commands/create.md (The example uses $(gopass config path))

@AnomalRoil Thanks again. Updated all of these.

The following didn't work for me:
gopass config core.safecontent true
echo """this is a test
on two line""" | gopass insert test
gopass show test

It displayed the two lines instead of hiding the first line.

Ah, it seems the problem is actually in the migration path, since in the old config.yml file, showsafecontent was named safecontent only

I wonder how the migration path would be for old config files that still contain legacy options in their YAML:
check_recipient_hash
concurrency

and others

These old configs will just be caried over with the core. prefix. But they will not be used by anything.


Updated to pay attention to rack 1.3.6 and rails 3.1.3 environment variables and response objects

Updated to pay attention to rack 1.3.6 and rails 3.1.3 environment variables and response objects
response was coming back as an array with an ActionView::OutputBuffer as its only element
env['rack_session_options'] is holding :key and :id values
!!NOTE... removed 'pry' requirement from lib... after pull request

Hi
Thank you for your pull request.
But please be sure, don't change any other things just include your patch to make Cookieless works with new rails, rack.
Thanks.


Broken link to docs for YouTube player URL parameters

Issue reported: https://github.com/mozilla/popcorn-js/issues/468
Reported by: @ghing
The docs for the YouTube media wrapper link to a list of URL parameters to show the player controls. The URL in the link is https://code.google.com/apis/Youtube/2.0/reference.html#Custom_parameters, but this page 404s when visited. I believe the correct, current URL for the YouTube player URL parameter documentation is https://developers.google.com/youtube/player_parameters?hl=en

This needs to be updated in the documentation, see #61

Updated in the popcorn-docs, see this link for further details.


[Bug] alerts are not always displayed on the Sky map

The reason is this piece of code:
https://github.com/astrolabsoftware/fink-science-portal/blob/a78a46c4a53cc2269da2c43361e92ac32cdad52f/apps/explorer.py#L299
that should be instead
if cat not in cats

#110


Enable rulesets (BLE and RUF)

…UF012

Description of the changes being introduced by the pull request:
Fixes #2567

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

10 of 12 (83.33%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.592%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

tuf/api/serialization/json.py
3
4
75.0%

tuf/ngclient/fetcher.py
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1466

Relevant Lines:
1491

💛  - Coveralls

FYI the failure in with-sslib-main is expected at the moment and will not prevent merging

FYI the failure in with-sslib-main is expected at the moment and will not prevent merging

ah gotcha, can you take a look at this pr then, when you get a chance @jku.


Add license

Critical Changes
Changes
Issues Closed

Add license.

adding another comment.

Attempting to merge my own changes.


⚠ Mobitopup has degraded performance

In e13d3c1, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 12395 ms

Resolved: Mobitopup performance has improved in 0f7b59f.