Modify the L1/L2 weight regularization penalty during the training procedure

Hi,
I need to modify the L1/L2 weight regularization penalty during the training procedure. As defined here, it should be useless to modify these values without recompile the model itself. Could I change
self.l1 = K.cast_to_floatx(l1)

to
self.l1 = K.variable(l1)

to make it work?
Best Regards.

I think so: not working and no much usefulness at this moment. For my curiosity, why do you want to change it? Once it is changed, it will be not easy to apply for testing data in general? Do you think adaptive for a adaptive system, that is, over-the-air hyper parameter optimization for the given networks?
--James

Hi, nixingyang
I have a related question. Is regularization working well in your test regardless chasing L1/L2 parameter on the training period? To me, it never works. I get the following warning instead. Could you share some idea on this for me or people who have had the same message?
/home/jamessungjinkim/anaconda3/lib/python3.5/site-packages/keras/backend/theano_backend.py:558: UserWarning: theano.function was asked to create a function computing outputs given certain inputs, but the provided input variable at index 1 is not part of the computational graph needed to compute the outputs: keras_learning_phase.
To make this warning into an error, you can pass the parameter on_unused_input='raise' to theano.function. To disable it completely, use on_unused_input='ignore'.
**kwargs)
--James

Hi @jskDr,
I am trying to replicate the work as described here. I need to train two models simultaneously and I want to modify the penalty coefficients throughout the training procedure. In this specific scenario, there is no validation/testing data set. To address this issue, I defined a new class as follows:
class CustomizedWeightRegularizer(WeightRegularizer):
    def __init__(self, l1=0., l2=0.):
        self.l1 = K.variable(l1)
        self.l2 = K.variable(l2)
        self.uses_learning_phase = True

Afterwards, I called get_value and set_value to get and set the penalty coefficients. I have obtained expected results by using the aforementioned trick.
For the warning message you shared, I have not encountered similar problem. IMHO, the model should work just fine even if one modifies the penalty coefficients throughout the training procedure.
Best Regards.

Hi, @nixingyang
It is a good news to hear that your model is working. For my issue related to regularization of a dense layer, I share my corresponding codes on Gist. So, could you advice me further?
https://gist.github.com/jskDr/f3007817baf54f249e6138fbd384eeea

Hi @jskDr,
In your code, you are using the default class l2 provided by Keras. You may try to change it to
model.add(Dense(n_w_l, W_regularizer = CustomizedWeightRegularizer(l2=0.01)))

During the training procedure, you may change the value in those regularizers by using
model.regularizers[0].l2.set_value(0.005)

Best Regards.

@nixingyang
Worked like a charm, thanks!
PS: In my version of keras I needed to add a blank p property to make it work.
class CustomizedWeightRegularizer(WeightRegularizer):
    def __init__(self, l1=0., l2=0.):
        self.l1 = K.variable(l1)
        self.l2 = K.variable(l2)
        self.uses_learning_phase = True
        self.p = None


RumMonitor.Builder.sampleRumSessions is missing

Describe what happened
The sampleRumSessions  method from RumMonitor.Builder is missing
Steps to reproduce the issue:
try to create a RumMonitor object thru the builder:
val monitor = RumMonitor.Builder()
        .sampleRumSessions(75.0f)
        .build()

Describe what you expected:
The method should be available
Additional context

Datadog SDK version: 1.5.2

Hi @fleficher and thanks for opening this issue;
This method will be available in the upcoming 1.6.0 version, the documentation change have already been merged but we have yet to make a release. A beta version of 1.6.0 will probably be available next week.


Load PhpWeb immediately to improve perceived performance when performing actions

PhpWeb executes scripts when installing a runtime. Clicking "Install" must wait for that to load. We can preemptively load it when the page is loaded.

After #68 this is all done in the web worker


Scroll only works on second click

Hi!
I use this plugin on a FAQ page with on the top of the page a row of anchor links to different sections of the page. But when I click this anchor link, it jumps, without smooth scroll animation, it instantly jumps to the correct section. When I scroll back up and use the anchor link again, the scroll animation is working.
Is there something wrong with my component?
 <p className="tracking-widest text-mainPink-500">
                                    <AnchorLink
                                      to={`/veelgestelde-vragen/#${slice2.primary.title.text}`}
                                      title={slice2.primary.title.text}
                                    >
                                      {slice2.primary.title.text}
                                    </AnchorLink>
                                  </p>

Same. This plugin is consistently broken on the first click everywhere I've used it.

Same here, any solution?


Compressed VNG columns

@mccanne indicated this is needed for the performance research being done by the Berkeley team.

Verified in Zed commit cd75567.
Using an example file from the zed-sample-data, we can see the impact of the compression in the different sizes of the VNG representation before/after compression support was added.
$ zq -version
Version: v1.4.0-12-gba5f74d6

$ zq -f vng -o conn-uncompressed.vng ~/work/zed-sample-data/zeek-default/conn.log.gz

$ zq -f zson -o conn-uncompressed.zson conn-uncompressed.vng

$ zq -version
Version: v1.4.0-14-gcd755677

$ zq -f vng -o conn-compressed.vng ~/work/zed-sample-data/zeek-default/conn.log.gz

$ zq -f zson -o conn-compressed.zson conn-compressed.vng

$ ls -l
total 2868688
-rw-r--r--  1 phil  staff   38502387 Jan 12 12:13 conn-compressed.vng
-rw-r--r--  1 phil  staff  666285497 Jan 12 12:13 conn-compressed.zson
-rw-r--r--  1 phil  staff   81340165 Jan 12 12:12 conn-uncompressed.vng
-rw-r--r--  1 phil  staff  666285497 Jan 12 12:12 conn-uncompressed.zson

$ diff conn-compressed.zson conn-uncompressed.zson

$ echo $?
0

Note that this was a breaking change: I've confirmed we expected to lose backward compatibility with the prior VNG. If we try to read the older/uncompressed VNG with current Zed, it'll crash. However, users aren't expected to be reliant on VNG yet.
$ zq -version
Version: v1.4.0-14-gcd755677

$ zq 'count()' conn-uncompressed.vng
panic: bad uvarint: 0

goroutine 11 [running]:
github.com/brimdata/zed/zcode.(*Iter).Next(0xc000000120?)
	/Users/phil/work/zed/zcode/iter.go:26 +0x219
...

Thanks @nwt!


Remove hardcoded minion count

wowo metal actually contributing
this pr edits the minions_max_uniques constant to automatically calculate how many unique minions a user can craft
it also has a fix for #730

I don't understand why the minion count and the slime slayer are in the same PR but I guess I've done worse

Can we just remove the slime slayer? 🙏

wait it didn't let me add to export const

nvm i see how u did it now


Make navigation in template use Link tags rather then A tags.

Currently, the template uses a tags for its navigation items.
https://github.com/wasp-lang/open-saas/blob/2a4c5e7206d2124d41138da9ce3e600c19f1b057/template/app/src/client/components/AppNavBar.tsx#L47-L54
This causes the page to reload when navigating around items. Example:
https://github.com/user-attachments/assets/76ba1e85-893c-487f-8312-87113ba4af27
My fix is quite a minor one. Replace the a tag used in the navigation mapping with the link tag from react-router-dom. Doing so creates a better nav experience for users (both mobile and nav will need to be updated). Example:

https://github.com/user-attachments/assets/960cf97d-705b-4e26-8fa9-c57e3b9aec00
Currently, Link is being used in this file from the wasp router, which I believe can only point to files defined in the main.wasp file. Are we able to replace the wasp version of Link with the react-router-dom, which will allow links to be defined and used within the nav file?
I would love to work and contribute on this. Its a small improvement, but having to reload pages in a react-app takes away from that seamless SPA experience.

hey @npenza, go for it!
And, yes, if you're not using a route defined in the wasp config file, then you can use react-router-dom's Link component instead.


Patch 6

About

Make commands/client.ts export type PrefixReturnType and update mod.ts
Status

[X] These changes have been tested against Discord API or do not contain API change.
[ ] This PR includes only documentation changes, no code change.
[ ] This PR introduces some Breaking changes.

This PR has been stale, I'll close it in a week if no activity is there.

Closing as stale


feat(parser): add preserveParens option

https://github.com/acornjs/acorn/tree/master/acorn/
preserveParens: If this option is true, parenthesized expressions are represented by (non-standard) ParenthesizedExpression nodes that have a single expression property containing the expression inside parentheses.
This will greatly help with the prettier port.

Parenthesized Expression
Parenthesized expressions are supposed to not have any semantic meanings?
For instance the AST for ((x)) can just be a single IdentifierReference, not ParenthesizedExpression -> ParenthesizedExpression -> IdentifierReference.
And this is the case for JavaScript grammar.
But ... who would have thought it can have run-time meanings.
Found in this estree issue https://github.com/estree/estree/issues/194, it shows that
> fn = function () {};
> fn.name
< "fn"

> (fn) = function () {};
> fn.name
< ''

So eventually acorn and babel added the preserveParens option for compatibility.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.15",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d208b89401e073de986dc891037c5a668f5d5d95"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "d208b89401e073de986dc891037c5a668f5d5d95",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "dm: fix mempool NULL pointer race when completing IO\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15 by commit d208b89401e073de986dc891037c5a668f5d5d95. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1002147


Error Compiling

Hi,
I don't know if you work on this anymore and I'm sorry if this is a stupid question but, when I try to compile your code, I always get this:
In file included from Descriptors.c:1: Descriptors.h:50: error: conflicting types for 'CALLBACK_USB_GetDescriptor' C:/SwitchFightstick/LUFA/LUFA/../LUFA/Drivers/USB/Core/AVR8/../Device.h:133: error: previous declaration of 'CALLBACK_USB_GetDescriptor' was here Descriptors.c:155: error: conflicting types for 'CALLBACK_USB_GetDescriptor' C:/SwitchFightstick/LUFA/LUFA/../LUFA/Drivers/USB/Core/AVR8/../Device.h:133: error: previous declaration of 'CALLBACK_USB_GetDescriptor' was here make: *** [obj/Descriptors.o] Error 1
And also
Joystick.c: In function 'SetupHardware': Joystick.c:120: warning: implicit declaration of function 'clock_prescale_set' Joystick.c:120: error: 'clock_div_1' undeclared (first use in this function) Joystick.c:120: error: (Each undeclared identifier is reported only once Joystick.c:120: error: for each function it appears in.) make: *** [obj/Joystick.o] Error 1
I don't know much about this but it would be great if you could help me.

For the first error, I want to say someone pointed this out before and I haven't had a chance to change it. The newest version of LUFA has a different declaration of CALLBACK_USB_GetDescriptor that uses a uint16_t for the wIndex argument. This is a pretty simple fix: change the wIndex argument in Descriptors.c and Descriptors.h to use uint16_t.
For the second issue, clock_prescale_set and clock_div_1 are components in avr-libc, in avr/power.h . Just to make sure, do you have WinAVR installed or some form of avr-libc available?

Sorry for the late response, but I only had a chance to try it now.
For the first error I was able to solve it and for the second I compiled it via Linux and it went well.
I just have some questions about the initial setup,
When I finished flashing the hex file it appears as a POKKEN CONTROLLER as expected but is always pressing the button 8 on my PC. Also my Switch wont recognize it.
What should I do??

Are you flashing to a development board? If so, which one? (Teensy2, etc.) There's a possibility that the pin that represents pin 8 is being grounded by something else.
As for the Switch not recognizing it, I would have to recompile the code with the latest LUFA and flash to one of my AVR devboards for testing. I haven't made any changes with the descriptors for a year or so.

I'm actually trying to flash to an arduino (it's a UNO R3, I'm using it in the atmega16u2).
Maybe you can tell me which LUFA library you used and the date so I can try to find it on the internet??

That explains why button 8 is pressed; PD7 is held low with a 1k pulldown. Keep in mind that using the 16u2 on an Arduino is going to be limited pin-wise; only 9 of the pins have direct exposure.
Has the target chip in the makefile been updated for the 16u2?

Yes, I changed the makefile according to my needs.
Anything I can do about PD7?
Also I think I have almost all of the pins actually
I've found this diagram:

What do you think?

You could alter the firmware to not read from that pin in the function, or you could try to read from a different pin instead for pin 8. By default it's reading all of ports D and B, but there's no reason why you can't customize this.
Also, I'm trying to find a schematic that matches what's being shown and I'm coming up dry. The Uno SMD schematic and the Uno R3 schematic that I'm finding only show 9 pins mapped to the 16u2 that could be used as data. Two others could be used, but those power the LEDs for serial send/receive.

Regarding the Switch detecting the controller, I recall this problem and it's a simple fix: a button press needs to be actuated first for the Switch to detect it. It has to be a press that occurs after the controller is plugged in, so the button that's being held down won't trigger it.

I'm going to go ahead and close this issue for now, as no other questions/concerns were brought up. Hope everything is working OK!

im facing same issue here. i downloaded avr-libc but still shows same error
[GCC]     : Compiling C file "Joystick.c"
avr-gcc -c -pipe -gdwarf-2 -g2 -mmcu=atmega16u2 -fshort-enums -fno-inline-small-functions -Wall -fno-strict-aliasing -funsigned-char -funsigned-bitfields -ffunction-sections -I. -DARCH=ARCH_AVR8 -DF_CPU=16000000UL -mrelax -fno-jump-tables -x c -Os -std=gnu99 -Wstrict-prototypes -DUSE_LUFA_CONFIG_HEADER -IConfig/   -I. -I./lufa/LUFA/.. -DARCH=ARCH_AVR8 -DBOARD=BOARD_NONE -DF_USB=16000000UL   -MMD -MP -MF obj/Joystick.d Joystick.c -o obj/Joystick.o
Assembler messages:
Fatal error: can't create obj/Joystick.o: No such file or directory
Joystick.c: In function 'SetupHardware':
Joystick.c:120: warning: implicit declaration of function 'clock_prescale_set'
Joystick.c:120: error: 'clock_div_1' undeclared (first use in this function)
Joystick.c:120: error: (Each undeclared identifier is reported only once
Joystick.c:120: error: for each function it appears in.)

@fz3ateam See this comment. This appears to be an issue with certain avr-libc versions, especially within WinAVR.

after updating avr8 win32 in my windows 10.. I'm facing new issue
[GCC] : Compiling C file "Joystick.c"
avr-gcc -c -pipe -gdwarf-2 -g2 -mmcu=atmega16u2 -fshort-enums -fno-inline-small-functions -Wall -fno-strict-aliasing -funsigned-char -funsigned-bitfields -ffunction-sections -I. -DARCH=ARCH_AVR8 -DF_CPU=16000000UL -mrelax -fno-jump-tables -x c -Os -std=gnu99 -Wstrict-prototypes -DUSE_LUFA_CONFIG_HEADER -IConfig/ -I. -I./lufa/LUFA/.. -DARCH=ARCH_AVR8 -DBOARD=BOARD_NONE -DF_USB=16000000UL -MMD -MP -MF obj/Joystick.d Joystick.c -o obj/Joystick.o
Assembler messages:
Fatal error: can't create obj/Joystick.o: No such file or directory
Joystick.c:235:1: fatal error: error writing to -: Invalid argument
}
^
compilation terminated.
make: *** [obj/Joystick.o] Error 1


About multi-channel data generate

The model is capable of generating data with multiple channels. If this is the case, what should the input training data resemble?（n-samples, n-channels, time-steps）

Hi, it should be (n-samples, time-steps, n-channels). Thanks!

Hi, it should be (n-samples, time-steps, n-channels). Thanks!

thanks！

another question if I wanna generate one type data, the input training data should be (n-sample, time-steps) right?, but I can't understand the windows why must equal to serie-length, and what feature-size mean

if I have one dataset (n-sample, time-steps) ->(128, 16) the seq-length should be 16, but the feature-size must = 16 can running code

In fact, the size of your dataset is (n-sample, time-steps, 1).


[AutoPR applicationinsights/resource-manager] Fix AppInsights x-ms-parameter-location

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/2680

(message created by the CI based on PR content)

Codecov Report

Merging #2202 into restapi_auto_applicationinsights/resource-manager will increase coverage by 2.25%.
The diff coverage is 0%.

@@                                  Coverage Diff                                  @@
##           restapi_auto_applicationinsights/resource-manager    #2202      +/-   ##
=====================================================================================
+ Coverage                                              50.71%   52.96%   +2.25%
=====================================================================================
  Files                                                   5595     4798     -797
  Lines                                                 143017   120224   -22793
=====================================================================================
- Hits                                                   72537    63682    -8855
+ Misses                                                 70480    56542   -13938

Impacted Files
Coverage Δ

...cationinsights/operations/components_operations.py
13.45% <ø> (ø)
:arrow_up:

...insights/application_insights_management_client.py
42.85% <0%> (+2.17%)
:arrow_up:

...ork/azure/mgmt/network/v2017_10_01/models/probe.py
33.33% <0%> (-8.78%)
:arrow_down:

...etwork/v2017_11_01/models/packet_capture_result.py
31.25% <0%> (-8.75%)
:arrow_down:

...etwork/v2017_10_01/models/packet_capture_result.py
31.25% <0%> (-8.75%)
:arrow_down:

...17_10_01/models/verification_ip_flow_parameters.py
35.71% <0%> (-8.74%)
:arrow_down:

...17_11_01/models/verification_ip_flow_parameters.py
35.71% <0%> (-8.74%)
:arrow_down:

...re/mgmt/network/v2017_10_01/models/ipsec_policy.py
35.71% <0%> (-8.74%)
:arrow_down:

...re/mgmt/network/v2017_11_01/models/ipsec_policy.py
35.71% <0%> (-8.74%)
:arrow_down:

...rk/v2017_11_01/models/connection_monitor_result.py
26.31% <0%> (-8.47%)
:arrow_down:

... and 1002 more

Continue to review full report at Codecov.

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


amogus

amogus

amogus

@r-ex merge worthy tbh

cry

needs more sus

smh :(

i shall have my vengeance


Importing trained model directly using python opencv

Python: 3.6.9
opencv-python==<IP_ADDRESS>
Rather than trying to build this project with so little documentation, I decided to directly import the model in cv2 python but no success so far.
import cv2
proto_path = 'deploy.prototxt'
model_path = 'face_mask.caffemodel'
model = cv2.dnn.readNetFromCaffe(proto_path, model_path)
image_file = 'sample_images/0000.jpg'
img = cv2.imread(image_file)
image_blob = cv2.dnn.blobFromImage(img)
model.setInput(image_blob)
prediction = model.forward()
Error:
cv2.error: OpenCV(4.2.0) /io/opencv/modules/dnn/src/dnn.cpp:3084: error: (-215:Assertion failed) total(os[i]) > 0 in function 'getLayerShapesRecursively'
Did anyone had any success doing this or what else can be done to use the pre-trained model?

Try
image_blob = cv2.dnn.blobFromImage(img, 1, (224, 224), (127.5, 127.5, 127.5))
deploy.prototxt indicates that the input should be a 224 x 224 image, and I got the 127.5 from here: https://github.com/didi/maskdetection/blob/master/lib/src/FaceMaskDetector.cpp#L72

Try
image_blob = cv2.dnn.blobFromImage(img, 1, (224, 224), (127.5, 127.5, 127.5))
deploy.prototxt indicates that the input should be a 224 x 224 image, and I got the 127.5 from here: https://github.com/didi/maskdetection/blob/master/lib/src/FaceMaskDetector.cpp#L72


Build error for 3.5.0 on Arch Linux

I'm compiling ROCm 3.5.0 on Arch Linux and using hip with its new ROCclr backend. I could compile all ROCm libs (rocblas, rocsparse, rocalution, ...) except hipsparse:
[ 50%] Building CXX object library/CMakeFiles/hipsparse.dir/src/hcc_detail/hipsparse.cpp.o
/build/hipsparse/src/hipSPARSE-rocm-3.5.0/library/src/hcc_detail/hipsparse.cpp:6381:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
In file included from /build/hipsparse/src/hipSPARSE-rocm-3.5.0/library/src/hcc_detail/hipsparse.cpp:24:
In file included from /build/hipsparse/src/hipSPARSE-rocm-3.5.0/library/include/hipsparse.h:41:
In file included from /opt/rocm/hip/include/hip/hip_complex.h:29:
In file included from /opt/rocm/hip/include/hip/hcc_detail/hip_complex.h:26:
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1186:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned char, 2>::HIP_vector_type<unsigned char, unsigned char, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(unsigned char, uchar2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1187:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned char, 3>::HIP_vector_type<unsigned char, unsigned char, unsigned char, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(unsigned char, uchar3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1188:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned char, 4>::HIP_vector_type<unsigned char, unsigned char, unsigned char, unsigned char, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(unsigned char, uchar4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1191:1: note: in instantiation of function template specialization 'HIP_vector_type<char, 2>::HIP_vector_type<signed char, signed char, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(signed char, char2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1192:1: note: in instantiation of function template specialization 'HIP_vector_type<char, 3>::HIP_vector_type<signed char, signed char, signed char, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(signed char, char3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1193:1: note: in instantiation of function template specialization 'HIP_vector_type<char, 4>::HIP_vector_type<signed char, signed char, signed char, signed char, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(signed char, char4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1196:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned short, 2>::HIP_vector_type<unsigned short, unsigned short, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(unsigned short, ushort2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1197:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned short, 3>::HIP_vector_type<unsigned short, unsigned short, unsigned short, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(unsigned short, ushort3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1198:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned short, 4>::HIP_vector_type<unsigned short, unsigned short, unsigned short, unsigned short, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(unsigned short, ushort4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1201:1: note: in instantiation of function template specialization 'HIP_vector_type<short, 2>::HIP_vector_type<short, short, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(signed short, short2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1202:1: note: in instantiation of function template specialization 'HIP_vector_type<short, 3>::HIP_vector_type<short, short, short, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(signed short, short3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1203:1: note: in instantiation of function template specialization 'HIP_vector_type<short, 4>::HIP_vector_type<short, short, short, short, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(signed short, short4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1206:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned int, 2>::HIP_vector_type<unsigned int, unsigned int, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(unsigned int, uint2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1207:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned int, 3>::HIP_vector_type<unsigned int, unsigned int, unsigned int, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(unsigned int, uint3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1208:1: note: in instantiation of function template specialization 'HIP_vector_type<unsigned int, 4>::HIP_vector_type<unsigned int, unsigned int, unsigned int, unsigned int, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(unsigned int, uint4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1211:1: note: in instantiation of function template specialization 'HIP_vector_type<int, 2>::HIP_vector_type<int, int, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(signed int, int2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1212:1: note: in instantiation of function template specialization 'HIP_vector_type<int, 3>::HIP_vector_type<int, int, int, nullptr>' requested here
DECLOP_MAKE_THREE_COMPONENT(signed int, int3);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1156:53: note: expanded from macro 'DECLOP_MAKE_THREE_COMPONENT'
    type make_##type(comp x, comp y, comp z) { type r{x, y, z}; return r; }
                                                    ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1213:1: note: in instantiation of function template specialization 'HIP_vector_type<int, 4>::HIP_vector_type<int, int, int, int, nullptr>' requested here
DECLOP_MAKE_FOUR_COMPONENT(signed int, int4);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1161:14: note: expanded from macro 'DECLOP_MAKE_FOUR_COMPONENT'
        type r{x, y, z, w}; \
             ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:585:17: error: no matching function for call to 'operator new'
                new (&data) Native_vec_{static_cast<T>(xs)...};
                ^~~
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1216:1: note: in instantiation of function template specialization 'HIP_vector_type<float, 2>::HIP_vector_type<float, float, nullptr>' requested here
DECLOP_MAKE_TWO_COMPONENT(float, float2);
^
/opt/rocm/hip/include/hip/hcc_detail/hip_vector_types.h:1152:45: note: expanded from macro 'DECLOP_MAKE_TWO_COMPONENT'
    type make_##type(comp x, comp y) { type r{x, y}; return r; }
                                            ^
note: candidate function not viable: requires 1 argument, but 2 were provided
note: candidate function not viable: requires 1 argument, but 2 were provided

This seem to be an issue in hip_complex.h header when compiling with default C++ compiler, not related to hipSPARSE. As a workaround, can try to compile hipSPARSE using hip-clang compiler (e.g. run CXX=/opt/rocm/bin/hipcc cmake .. <options>?

Thank you for quick reply @ntrost57!
Sorry for not mentioning it.
-- The CXX compiler identification is Clang 11.0.0
-- Check for working CXX compiler: /opt/rocm/hip/bin/hipcc
-- Check for working CXX compiler: /opt/rocm/hip/bin/hipcc - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.27.0")
-- Found HIP: /opt/rocm/hip (found version "3.5.20240-")
-- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS
-- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS - Success
amdhip64: /opt/rocm/hip/lib/libamdhip64.so
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done

Did you successfully compile hipFFT?

Yes:
/opt/
/opt/rocm/
/opt/rocm/include/
/opt/rocm/include/hipfft.h
/opt/rocm/include/rocfft-export.h
/opt/rocm/include/rocfft-version.h
/opt/rocm/include/rocfft.h
/opt/rocm/lib/
/opt/rocm/lib/cmake/
/opt/rocm/lib/cmake/rocfft/
/opt/rocm/lib/cmake/rocfft/rocfft-config-version.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-config.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-targets-release.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-targets.cmake
/opt/rocm/lib/librocfft-device.so
/opt/rocm/lib/librocfft-device.so.0
/opt/rocm/lib/librocfft-device.so.0.1
/opt/rocm/lib/librocfft.so
/opt/rocm/lib/librocfft.so.0
/opt/rocm/lib/librocfft.so.0.1
/opt/rocm/rocfft/
/opt/rocm/rocfft/include/
/opt/rocm/rocfft/include/hipfft.h
/opt/rocm/rocfft/include/rocfft-export.h
/opt/rocm/rocfft/include/rocfft-version.h
/opt/rocm/rocfft/include/rocfft.h
/opt/rocm/rocfft/lib/
/opt/rocm/rocfft/lib/cmake/
/opt/rocm/rocfft/lib/cmake/rocfft/
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-config-version.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-config.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-targets-release.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-targets.cmake
/opt/rocm/rocfft/lib/librocfft-device.so
/opt/rocm/rocfft/lib/librocfft-device.so.0
/opt/rocm/rocfft/lib/librocfft-device.so.0.1
/opt/rocm/rocfft/lib/librocfft.so
/opt/rocm/rocfft/lib/librocfft.so.0
/opt/rocm/rocfft/lib/librocfft.so.0.1

Yes:
/opt/
/opt/rocm/
/opt/rocm/include/
/opt/rocm/include/hipfft.h
/opt/rocm/include/rocfft-export.h
/opt/rocm/include/rocfft-version.h
/opt/rocm/include/rocfft.h
/opt/rocm/lib/
/opt/rocm/lib/cmake/
/opt/rocm/lib/cmake/rocfft/
/opt/rocm/lib/cmake/rocfft/rocfft-config-version.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-config.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-targets-release.cmake
/opt/rocm/lib/cmake/rocfft/rocfft-targets.cmake
/opt/rocm/lib/librocfft-device.so
/opt/rocm/lib/librocfft-device.so.0
/opt/rocm/lib/librocfft-device.so.0.1
/opt/rocm/lib/librocfft.so
/opt/rocm/lib/librocfft.so.0
/opt/rocm/lib/librocfft.so.0.1
/opt/rocm/rocfft/
/opt/rocm/rocfft/include/
/opt/rocm/rocfft/include/hipfft.h
/opt/rocm/rocfft/include/rocfft-export.h
/opt/rocm/rocfft/include/rocfft-version.h
/opt/rocm/rocfft/include/rocfft.h
/opt/rocm/rocfft/lib/
/opt/rocm/rocfft/lib/cmake/
/opt/rocm/rocfft/lib/cmake/rocfft/
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-config-version.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-config.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-targets-release.cmake
/opt/rocm/rocfft/lib/cmake/rocfft/rocfft-targets.cmake
/opt/rocm/rocfft/lib/librocfft-device.so
/opt/rocm/rocfft/lib/librocfft-device.so.0
/opt/rocm/rocfft/lib/librocfft-device.so.0.1
/opt/rocm/rocfft/lib/librocfft.so
/opt/rocm/rocfft/lib/librocfft.so.0
/opt/rocm/rocfft/lib/librocfft.so.0.1

This looks like an issue in hip_complex.h header. Unfortunately, Arch Linux is currently not supported by the ROCm stack. A list of supported operating systems can be found here.

I compared /opt/rocm/hip/include/hip/hcc_detail/hip_complex.h from the official rocm-terminal container with the self-compiled version for Arch Linux and they do not differ:
$ diff container.txt arch.txt
305d304
<

see
arch.txt
container.txt

Could you try to compile a minimal reproducer that includes hip_complex.h?

The build seems to proceed further when passing -std=c++20 to the compiler.
It then fails again at a later point (only when using hipcc and for some reason not with clang++):
hipSPARSE/library/src/hcc_detail/hipsparse.cpp:5739:10: error: 'x' is a private member of 'rocsparse_complex_num<float>'
    rtol.x = tol.x;
         ^
/opt/rocm/include/rocsparse-complex-types.h:212:7: note: declared private here
    T x;

But I don't know if that helps...

Hey @JnCrMx that's a great observation! Obviously this is a bug in hipsparse (or rocsparse). The lines
rocsparse_float_complex rtol;
rtol.x = tol.x;
rtol.y = tol.y;

should read
rocsparse_float_complex rtol{tol.x, tol.y};

With std=c++20 and after search and replace all rtols I can compile hipsparse on my PC.

Can we reopen this issue please @ntrost57? The build problem is not related to Arch Linux.

Thanks @tpkessler @JnCrMx for reporting this. I have raised PR #123 which should fix this issue.

Hey @ntrost57, thank you very much for fixing this error so quickly. As for my initial bug report: It seems like this is due to some templates not working as expected. hipconfig tells me that -std=c++11 is used as the default C++ standard when compiling with hipcc. Could it be that you use some template mechanics only available in a later C++ standard?

@tpkessler is this still observed with ROCm3.9?

No, version 3.9.0 compiles without issues on Arch Linux.


output paths - make sure directories are made

Fixes #279 .  Directories were not being created.  Now this works:
python Python/ogusa/scripts/postprocess.py

Don't merge yet - this needs a little work.

Locally, @jdebacker I am getting:
    def get_resource_stream(self, manager, resource_name):
>       return open(self._fn(self.module_path, resource_name), 'rb')
E       IOError: [Errno 2] No such file or directory: '/Users/psteinberg/miniconda3-4.1.11/envs/py27d/lib/python2.7/site-packages/ogusa-9.99.999+33.g5638ed9.dirty-py2.7.egg/TxFuncEst_policy.pkl'

in
py.test test_parameters.py

@PeterDSteinberg this is looking good to me.  Let me know when it can be merged.


Try to avoid Race conditions in Nomis::Api

Store the @pool instance at class level rather than the instance level

Closing this as we've found out that the issue is related to the recent timebox


Question on Update for Existing X

I didn't see in your example, or in the code, a very clean way to send an update for an already created run and case. I am fairly new to TestRail in general, but am hoping to integrate your client in order to update runs and cases that are established before the execution occurs.
Thanks!!!

Once you get an instance of TestRail class, to update runs, you can use
// get run to be update
Run run = testRail.runs().get(<runId>);

// update run
run.set...

// send update to TestRail
testRail.runs().update(run).execute();

Similarly, you can update cases. Convention is -
testRail.<entity>.<requests>.execute()

Hope this helps you. You can download javadoc.jar artifact from maven (link on project homepage) which has the javadoc and explore TestRail class for all the requests.


[WIP] Update verifyPodfile to catch a mismatch on Podfile.lock

Details
On occasion we encounter situations where a PR author adds/removes/updates an npm package but forgets to reinstall pods. This then creates confusion and wastes time for future devs who install pods and see a diff in the lock file without the context of why it's occurring or what to do with it.
This PR:

Modifies the verifyPodfile CI test to install all dependencies for iOS from scratch and check that there is no diff in ios/Podfile.lock. If there is a diff, the test fails and suggests a few fixes to the PR author.
Locks down cocoapods to a specific version in the Gemfile and updates all instances of pod install to bundle exec pod install so that the specified version of cocoapods gets used

Note that the diff in Gemfile.lock and ios/Podfile.lock here is from running bundle install after updating the cocoapods version, which is following the officially recommended workflow from Bundler.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/211674
Tests
Tested in this PR where I ran npm i<EMAIL_ADDRESS>and committed the changes, but did not run cd ios && bundle exec pod install. The CI check correctly caught the error:

[ ] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[ ] I added steps for Staging and/or Production testing in the QA steps section
[ ] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I included screenshots or videos for tests on all platforms
[ ] I ran the tests on all platforms & verified they passed on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there’s a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I followed proper code patterns (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained “why” the code was doing something instead of only explaining “what” the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named “index.js”. All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I followed the guidelines as stated in the Review Guidelines
[ ] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose and it is

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn’t already exist
[ ] The style can’t be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.

PR Reviewer Checklist

[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there’s a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained “why” the code was doing something instead of only explaining “what” the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named “index.js”. All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn’t already exist
[ ] The style can’t be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.

QA Steps
None

[ ] Verify that no errors appear in the JS console

Screenshots
N/A

Would someone accidentally running pod install end up breaking anything?

No, if pod --version and bundle info cocoapods --version have identical output locally, then running pod install is going to produce the same result as running bundle exec pod install. If the versions aren't identical, then there's a chance for incompatibility issues to arise (though I imagine the versions would have to be significantly different to actually cause problems). But now that discrepancy would be highlighted by the CI check before merging the PR.

Conflicts! :)

What's the latest on this issue?

Sorry for the poor communication here, I should have put this PR on hold following the latest round of feedback that we should avoid switching to bundle exec. I'll move it to back to WIP now. I'll also provide another update on the linked issue explaining the current status

Closing this out until I can prioritize it again, don't want to clutter everyone's K2 dashboards in the meantime 😄


Highlighting should not filter linter messages without column info

Cheers. That's a simple mistake on my part.

If you like, you can add a Vader test for that. If not, I'll add one later. You can call he function with a List and ensure that the List isn't modified.

Sure. I am not really familiar with vader. Will try and get one added.


Source schemas

OPS Build status updates of commit ad8bf60:
:warning: Validation status: warnings

File
Status
Preview URL
Details

enterprise-graph/source-schema-concepts.md
:warning:Warning

Details

enterprise-graph/source-schema-concepts.md

[Warning] Author stflanag cannot be recognized in GitHub.
Line 0: [Warning] Invalid file link:(~/schema-map-concepts).
Line 22: [Warning] Invalid file link:(~/media/creating-your-ontology/1_ontology_config.png).
Line 44: [Warning] Invalid file link:(~/media/creating-your-ontology/create_source_schema.png).
Line 60: [Warning] Invalid file link:(~/media/creating-your-ontology/fields_not_mapped.png).

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


Drools 1180 Migrate QE tests upstream

This is fourth in a series of PRs that migrate some tests from QE regression test suite upstream (there will be more).
Migrated test classes that inherit from ParsersTest class in QE regression test suite.

+1 to merge once the build is green


EKS - Fail to update  existing EKS cluster after upgrading Rancher to v2.2.0-rc2

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

run Rancher 2.1.6
add an EKS cluster
upgrade Rancher to v2.2.0-rc2
Edit the EKS cluster
The first step is to choose the version of K8s, the default value is 1.10, and the only option is 1.11
choose k8s 1.11, and leave the rest unchanged to finish the edit process.

Result:
The cluster is stick in the updateing state, and Rancher shows an error message.
InvalidParameterException: unsupported Kubernetes version update from the current version, 1.11, to 1.11
status code: 400, request id: 923d63af-397e-11e9-beba-59a2fd494d5f

Other details that may be helpful:

the cluser on AWS console is still in active state
no matter changing the k8s version or not, the upgrading always fails on the same error
Editing the cluster in Rancher again will take no effect
This is the k8s version of the EKS cluster on Rancher v2.1.6

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-21T11:46:00Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
upgrade from v2.1.6 to v2.2.0-rc2
Installation option (single install/HA):
single install

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-21T11:46:00Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

17.6.2

It is interesting that even though the UI shows the cluster is updating and has an error message, I can check the cluster, deploy workloads, run Kubectl, etc.

@jiaqiluo before you did the upgrade, was the version (via kubectl) of k8s 1.10 or 1.11?
I mean, I see the version is 1.11, so does that mean it was never actually 1.10 or that it did do the upgrade but then tried again for some reason and failed?
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

@cjellick  This is the k8s version of the EKS cluster on Rancher v2.1.6
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-21T11:46:00Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Also the error message says upgrading from 1.11 to 1.11 which makes no sense, right?

The bug is reproduced when updating Rancher from v2.1.7 to v.2.2.0-rc3 in HA installation mode.

The bugfix is validated on Rancher:v2.16 upgraded to master 3/12
Following the same steps as the issue describes, I get two observations:

when editing the EKS cluster, the default value is 1.11, and the only option is 1.11
The EKS cluster's state will stay active if I change nothing during the editing process


punycode

I have installed nodejs v22.9.0 and try "auto-playwright": "1.16.0",
playwright i use with typescript
when i add auto-playwright into my project, and copy your demo code for test and try run this test, i got everytime this messege:
(node:365986) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
TypeError: Cannot read properties of undefined (reading 'defaults')

    at sanitizeHtml (/app/node_modules/auto-playwright/dist/sanitizeHtml.js:23:46)
    at getSnapshot (/app/node_modules/auto-playwright/dist/getSnapshot.js:7:46)
    at runTask (/app/node_modules/auto-playwright/dist/auto.js:37:19)
    at /app/node_modules/auto-playwright/dist/auto.js:17:24

It's resolved for me, Just replace the sanitizeHTML.js with this
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.sanitizeHtml = void 0;
const sanitize = require("sanitize-html");
/**
 * The reason for sanitization is because OpenAI does not need all of the HTML tags
 * to know how to interpret the website, e.g. it will not make a difference to AI if
 * we include or exclude <script> tags as they do not impact the already rendered DOM.
 *
 * In my experience, reducing HTML only to basic tags produces faster and more reliable prompts.
 *
 * Note that the output of this function is designed to interpret only the HTML tags.
 * For instructions that rely on visual cues (e.g. "click red button") we intend to
 * combine HTML with screenshots in the future versions of this library.
 */
const sanitizeHtml = (subject) => {
    return sanitize(subject, {
        // The default allowedTags list already includes _a lot_ of commonly used tags.
        // https://www.npmjs.com/package/sanitize-html#default-options
        //
        // I don't see a need for this to be configurable at the moment,
        // as it already covers all the layout tags, but we can revisit this if necessary.
        allowedTags: sanitize.defaults.allowedTags.concat([
            "button",
            "form",
            "img",
            "input",
            "select",
            "textarea",
        ]),
        // Setting allowedAttributes to false will allow all attributes.
        allowedAttributes: false,
    });
};
exports.sanitizeHtml = sanitizeHtml;

The problem in this case is that there is no new release built that includes the fixed code in main branch. so, the latest release doesn't contain the current clean main branch status.


SAK-50266 Profile replace HibernateTemplate with modern Session pattern

https://sakaiproject.atlassian.net/browse/SAK-50266

Some little comments. It looks so good! Awesome job

thx Jesus for the review, much appreciated


feat: Add timer to prevent submission of form.

Summary | Résumé
Address #658, without design interaction functionality.
The Submit button will remain disabled until a time of 2 seconds for each form element passes. After that time, it will become enabled, and the user can submit the form.
For any UI changes please include screenshots at different breakpoints. It would also be helpful to include a
before and after comparison for each change i.e.

Before
After

Test instructions | Instructions pour tester la modification
Load a form. The submit button on the form should be disabled for 5 seconds, plus 2 seconds for each required element on the form. Try and quickly submit the form immediately on load.
Unresolved questions / Out of scope | Questions non résolues ou hors sujet

Currently timer will include form elements such as richText that can not be filled out, and potentially would be excluded from the calculation of the delay time.
The design interaction for this is not completed; a message will need to be displayed to the user to let them know the problem with submitting the form.

Pull Request Checklist
Please complete the following items in the checklist before you request a review:

[x] Have you completely tested the functionality of change introduced in this PR? Is the PR solving the problem it's meant to solve within the scope of the related issue?
[x] The PR does not introduce any new issues such as failed tests, console warnings or new bugs.
[ ] If this PR adds a package have you ensured its licensed correctly and does not add additional security issues?
[x] Is the code clean, readable and maintainable? Is it easy to understand and comprehend.
[x] Does your code have adequate comprehensible comments? Do new functions have docstrings?
[x] Have you modified the change log and updated any relevant documentation?
[x] Is there adequate test coverage? Both unit tests and end-to-end tests where applicable?
[x] If your PR is touching any UI is it accessible? Have you tested it with a screen reader? Have you tested it with automated testing tools such as axe?

@jeberhardt I see that you have requested reviews but it is still in a Draft state. Are you still making some adjustments?

@jeberhardt I see that you have requested reviews but it is still in a Draft state. Are you still making some adjustments?

@craigzour - Yes, still making changes. I had it "Ready for Review", but then there were some changes to the requirements, and I marked it as Draft. I'll let everyone know when it's ready.

@jeberhardt found a small bug while testing. If I pressed the submit button and the timer is displayed it gets reset to 5 seconds even if there was 1 second left.

@jeberhardt found a small bug while testing. If I press the submit button and the timer is displayed it gets reset to 5 seconds even if there was 1 second left.

Looks like it is not a bug now that I am looking at the code :)

Sorry for the follow up with the comments.  They were originally all part of my review but by pushing commits during my review (the refactorings) it somehow put my review into an in-between stale state.

It would have probably been better to add this behind a feature flag as discussed. On top of not being able to disable this for local development our github actions will take longer as parallelism will be disabled and the wait commands.

Agreed for the feature flag.  I can quickly add.
Our Cypress tests on github were never actually running in parallel as it requires a Cypress Dashboard account and a matrix strategy to be configured.


User/savoyschuler/pagercontrol

Initial PR for adding PagerControl spec to master.

While testing out the current prototype in the MUXControlsTestApp, I noticed the following behavior:

When hiding/showing a button, it gets collapsed and the size of the pager control changes. However this can get problematic with layouting. If users want to center the control for example, and one of the button hides (e.g. because the end was reached and it was set to auto hide), the pager control will start jumping. Even worse, it might actually not look centered anymore if the next and last button are hidden because the width would only take the left buttons and e.g. the NumberBox into account resulting in an off center NumberBox.
The question would be, what is the expected behavior here. Should those buttons still take space even when set to hide?

@chingucoding I implemented the current behavior because I wanted the control to save as much screen space as it can. That being said, I do agree with your concerns and I think the control should take up as much space in order to avoid this behavior. If we were to do that, it would lead to dead space if there was another ui element to the right or left of the control and one of the buttons hides, right? Would developers mind if this were the case?

Unfortunately, yes that would lead to dead space. I think the million dollar question is, what is better?
Have dead space that might create gaps, or an uneven centered control that might create layout jumps when choosing a different page? I would argue that dead space is fine here, especially has these layout jumps can be irritating to end users.

Yep I agree as well! I'll make some changes to the prototype

Since the space would normally be occupied by a visible [next page] button and a [last page] button, for example, I think its fine to keep the space these buttons would occupy reserved, even if actual buttons might not currently be displayed (if, for example, PagerButtonVisibilityBehavior is set to HiddenOnEdge.) The control should not jump around when these button change their visibility (as that could be quite a frequent occurence) nor should the developer have to account for that when designing the app.
Perhaps we can reserve button space depending on the pager button configuration. For example, when the developer sets the visibility of both the FirstPage button and the LastPage button to none, then we should consider not reserving the space these buttons would occupy. The NumberBox and its PrevPage and NextPage buttons would still be visible so it will look centered and the developer explicitly said they do not want the FirstPage and LastPage buttons to show up. So, if they have custom UI next to the visible PrevPage and NextPage buttons, there should be no additional padding between them enforced by the control here.
What does PagerButtonVisibilityBehavior.None do? The spec.

Yep I agree as well! I'll make some changes to the prototype

Awesome! Looking forward to that.

Since the space would normally be occupied by a visible NextPage button and LastPage button, for example, I think its fine to keep the space these buttons would occupy reserved, even if actual buttons might not currently be displayed (if, for example, PagerButtonVisibilityBehavior is set to HiddenOnEdge.) The control should not jump around when these button change their visibility (as that could be quite a frequent occurence) nor should the developer have to account for that when designing the app.

Perhaps we can reserve button space depending on the pager button configuration. For example, when the developer sets the visibility of both the FirstPage button and the LastPage button to none, then we should consider not reserving the space these buttons would occupy. The NumberBox and its PrevPage and NextPage buttons would still be visible so it will look centered and the developer explicitly said they do not want the FirstPage and LastPage buttons to show up. So, if they have custom UI next to the visible PrevPage and NextPage buttons, there should be no additional padding between them enforced by the control here.

The issues I see here are
a) What if you only set the firstpage visibility to none? Should we then render uneven?
b) What if the dev decides that you want to hide the first and last page if there are less than 3 pages for example, and show them when there are 4 or more pages? We would then be again have this jumping behavior. I am not sure how common that scenario is, but I think it's a valid concern.

@chingucoding
To a) Same as with the current train of thought. If only FirstPage button visibility is set to none (but LastPage button is visible), the space FirstPage button would occupy should be reserved by Pager control. The assumption here is that if the developer thinks displaying the LastPage button is useful, then in the majority of scenarios, the FirstPage button will also be visible at least sometimes and not hidden for the entire life time of the full user interaction with the control.
To b) The assumption here is that a UI where no FirstPage button and LastPage buttons are required is "not a rare one" and as such we should not reserve space here. If the developers face such a scenario you are speaking about they could actively design their app with that in mind (i.e. by manually reserving enough space between custom UI elements and the pager buttons of this control).
Important here: I don't have any data to back up my assumptions how common or uncommon a scenario is. The control should be designed with the most common scenarios in mind.

@chingucoding @Felix-Dev @gvazquez8 I agree that the behavior should be when the button is set to HiddenOnEdge, there will still be space reserved for it. I do agree that for some scenarios I've seen, the pager only had next and last buttons and did not have first and last buttons and I think it would be fairly common to only have next and previous buttons only.
I think @chingucoding's point is an interesting one if the developer chooses to hide and show buttons based on other criteria so I will need to think about that scenario. My initial thinking is when the visibility is set to AlwaysVisible or HiddenOnEdge, we reserve space for the button and if the visibility is set to None then we do not reserve space. That does not handle the case @chingucoding made but I am not sure how often developers would dynamically change the visibility.

Would it make sense to expose a property to modify when the NumberPanel starts working with ellipsis? In some cases, developers might have place for 20 numbers and in other cases, developers might only want to have 4 buttons and most and otherwise use ellipsis. Currently, we would need to hardcode that magic number without letting users modify that.

Also, currently the indicator color is hardcoded into the template. Would it be better to use the users accent color or expose a theme resource for that?

Just like with the NavigationView's selection indicator, a theme resource should be introduced and the default color value should be the user accent color. The theme resource could be named PagerControlSelectionIndicatorForeground to be similar to the NavigationView's selection indicator resource which is named NavigationViewSelectionIndicatorForeground.

@gabbybilka are you the current owner of this while @MarissaMatt is on leave? Asking per @chingucoding's question.


chore(aztec-nr): cleanup context interfaces

Not needed anymore. Part of #5818.

#6799  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

proof_construction_time_sha256_100_ms (16): 6,366 (+17%)
proof_construction_time_sha256_30_ms (16): 1,805 (+31%)
proof_construction_time_sha256_30_ms (32): 1,667 (+17%)
protocol_circuit_witness_generation_time_in_ms (root-rollup): 78.8 (-38%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,819
1,578 (+1%)
717 (+2%)
781 (+4%)
786 (+2%)

proof_construction_time_sha256_30_ms
12,014 (+4%)
3,217 (+4%)
:warning: 1,805 (+31%)
:warning: 1,667 (+17%)
1,593 (+10%)

proof_construction_time_sha256_100_ms
45,186 (+2%)
12,531 (+6%)
:warning: 6,366 (+17%)
6,038 (+12%)
5,949 (+11%)

proof_construction_time_poseidon_hash_ms
78.0 (-1%)
34.0 (-3%)
34.0
57.0
87.0

proof_construction_time_poseidon_hash_30_ms
1,525 (-1%)
421 (-1%)
202
222 (-3%)
274 (+4%)

proof_construction_time_poseidon_hash_100_ms
5,848
1,602
759 (+4%)
797
835 (+3%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,464
9,464
9,476

l1_rollup_execution_gas
616,105
616,105
616,117

l2_block_processing_time_in_ms
1,285 (+2%)
4,817 (+4%)
9,592 (+1%)

l2_block_building_time_in_ms
44,556 (+3%)
174,103 (+2%)
348,102 (+1%)

l2_block_rollup_simulation_time_in_ms
44,360 (+3%)
173,376 (+2%)
346,655 (+1%)

l2_block_public_tx_process_time_in_ms
41,092 (+9%)
170,163 (+3%)
343,374 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
9,634 (+2%)
14,681 (+1%)

node_database_size_in_bytes
14,499,920
21,381,200

pxe_database_size_in_bytes
18,071
29,868

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.4 (+1%)
17.3 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.604 (+1%)
0.518 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.6 (+1%)
76.6 (+1%)
245 (+2%)
479 (+1%)
925 (+3%)
1,849 (+1%)
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.495 (+1%)
0.472 (+1%)
0.445 (+2%)
0.445
0.440 (+3%)
0.441 (+1%)
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
58.4 (+2%)
113 (+2%)
355 (+2%)
704 (+1%)
1,383 (+3%)
2,761
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
106
208
692
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.504 (+2%)
0.505 (+1%)
0.480 (+2%)
0.482
0.479 (+4%)
0.479
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
62.9 (+1%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
107

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.555 (+1%)

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
84,053
665,267

Transaction size based on fee payment method
| Metric |  |
| - |  |

Merge activity

May 31, 11:21 AM EDT: @fcarreiro merged this pull request with Graphite.


Sample jQuery Trigger

Here is a file which shows how to user jQuery Triggers set in Library

@suleman-ML please add this example directly inside readme.md


Stability

Hey, I love what flask-rest-jsonapi is trying to do but is just woefully under-maintained. Just wanted to reach out and check to see what environment you're using this in to see if we should use your branch or just make our own.
Thanks!
Edit: Really should have also included, insanely impressed by the code you've added on to this project and I'd be for sure contributing up-stream if thats something you're legit interested in as well!

Hi @srhinos, yep I'm planning on maintaining my own fork. The master branch is currently up to date with all my PRs, and tests are passing. I'm just having issues with PyPy 3, which I'll likely disable and then I'll publish on PyPi. Feel free to submit and PRs you write here and I'm happy to review/merge them.

Awesome! I know the maintainer killed global decorators for literally no reason and I’ve had it monkey patched in a production environment since so having it hosted on something like pypi where version control can be done would be insanely valuable for me!

On Nov 8, 2019, at 00:12, Michael Milton<EMAIL_ADDRESS>wrote:

Hi @srhinos, yep I'm planning on maintaining my own fork. The master branch is currently up to date with all my PRs, and tests are passing. I'm just having issues with PyPy 3, which I'll likely disable and then I'll publish on PyPi. Feel free to submit and PRs you write here and I'm happy to review/merge them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Were they decorators for routing? like @api.route(/some/url)? Because that's a feature I wanted as well. If you can point out the commit where they removed it I can probably just revert it and add some tests.

Hey, yeah the commit was this
https://github.com/miLibris/flask-rest-jsonapi/commit/0c212bd71e9f46ab633d93703bc29c1009222554
They didn't seem to replace it with anything else from what I could tell, the documentation hasn't been updated yet to reflect it if they did. I've been source diving this and other projects and it seems like theres some alternative in place, its just annoying.


Make all string types non-copy

This was the old behavior which was changed in #1292. We agreed to bring back the old behavior for consistency. So, the compiler now does not differentiate between small strings (<= 8 bytes) and large strings.
Closes #1424.

There are some CI failures that I need to address, which I will do asap.

Maybe make it a draft until CI is ready to go?


Windows support

Hi,
thank you for your work. I was wondering whether the C++wrapper has been tested on Windows. I tried to build a project using just the headers and ran into several compilation issues (missing syslog.h...).
Thank you, Martin.
Visual Studio 2019, toolset v142, C++17

You're right, the C++ wrapper doesn't support windows yet, while it should.
Let me have a try these days. 🙂

@MPeli I just merged a PR which fixed the compilation errors (while still needs more effort to complete the windows CI jobs) Please have a try. Cheers! 😀


Add xfail to ReactiveCocoa 3.0, 3.2, 4.0

Pull Request Description
A few ReactiveCocoa configurations are failing due to SR-7299.
This adds an xfail to the 3.0, 3.2, and 4.0 configurations. (Note: 3.1 has an existing xfail which may or may not still be valid.)

@swift-ci test


Feature request: Convert an Object into dot-delimited paths

Guidelines

[X] Please search other issues to make sure this feature has not already been requested.

Which problem is this feature request solving?
Thanks for the work, very useful library!
One thing I’d love to see added is the ability to convert an Object into dot-delimited paths.
Describe the solution you'd like
Example:
dotate({
  username: 'johndoe',
  profile: { image: 'avatar.jpg', verified: true, views: 5 },
  tags: ['foo', 'bar']
}, { keepArrays })

Result with keepArrays: true:
{
  "username": "johndoe",
  "profile.image": "avatar.jpg",
  "profile.verified": true,
  "profile.views": 5,
  "tags": ["foo", "bar"]
}

Result with keepArrays: false:
{
  "username": "johndoe",
  "profile.image": "avatar.jpg",
  "profile.verified": true,
  "profile.views": 5,
  "tags.0": "foo",
  "tags.1": "bar"
}

Pull request (optional)

[ ] I can submit a pull request.

Hi @maoosi,
Thanks for the request!
Good ideas, let me work on it and reach back. :+1:

This is now available in wild-wild-utils 4.5.0. :tada:
wild-wild-path focuses on CRUD operations, while wild-wild-utils on functional utilities like the one you described, which is why this was added to that other repository.
The new method is named flatten() and is documented here and there.
import { flatten } from 'wild-wild-utils'

const target = {
  username: 'johndoe',
  profile: { image: 'avatar.jpg', verified: true, views: 5 },
  tags: ['foo', 'bar']
}
flatten(target)
// {
//   "username": "johndoe",
//   "profile.image": "avatar.jpg",
//   "profile.verified": true,
//   "profile.views": 5,
//   "tags.0": "foo",
//   "tags.1": "bar"
// }
flatten(target, { sort: true })
// {
//   "profile.image": "avatar.jpg",
//   "profile.verified": true,
//   "profile.views": 5,
//   "tags.0": "foo",
//   "tags.1": "bar",
//   "username": "johndoe"
// }
flatten(target, { shallowArrays: true })
// {
//   "username": "johndoe",
//   "profile.image": "avatar.jpg",
//   "profile.verified": true,
//   "profile.views": 5,
//   "tags": ["foo", "bar"]
// }

As part of this, I also added a new option shallowArrays to both wild-wild-path and wild-wild-utils. When set to true, it prevents recursing on arrays.
I hope this works!

@all-contributors Please add @maoosi for those great ideas.


[Godot 4.0 beta 12] Orphan node count skyrockets when changing scenes.

Godot version
v4.0.beta12.mono.official [3c9bf4bc2]
System information
Windows 10
Issue description
When using GetTree().ChangeScene (or GetTree().ReloadCurrentScene), the orphan node count in Monitors goes up by the number of nodes in the target scene.
This effect is amplified when running a scene that has lots of nodes.
I've also tested this in the previous beta (v4.0.beta11.mono.official [91713ced8]) and confirmed the issue didn't exist there.
Steps to reproduce

Run the included Minimal Reproduction Project.
Open the Debugger/Monitors tab.
Press "Space" to load Scene2.tcsn (2 Nodes).

Orphan nodes increases by 2.

Press "Space" to load Scene1.tcsn (3 Nodes).

Orphan nodes increases by 3.

Minimal reproduction project
MRP.zip

I confirm problem also on debian Linux 64 version without Mono


[WIP] MINOR: jackson upgrade (2.8.5 -> 2.9.0); version forcing for 'jackson-annotations' is deprecated

Prologue: PR #3116
Jackson release notes:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.9

Note: you may want to wait for Jackson 2.9.1 release
@ewencp: FYI

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6596/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6581/
Test PASSed (JDK 8 and Scala 2.12).

By the looks of Jackson 2.8 patch cadence I guess that 2.9.1 is due to in a month or so.
I took the liberty to create related JIRA ticket: https://issues.apache.org/jira/browse/KAFKA-5708

FYI, https://github.com/apache/kafka/pull/3619 includes a number of version bumps including Jackson.

I will remove Jackson from #3619.

Note: my initial intention was to remove version forcing for jackson-annotations; however it seems that jackson-databind 2.9.x still can't resolve correct version for jackson-annotations.
I reported issue here: https://github.com/FasterXML/jackson-databind/issues/1763 (jackson-databind 2.9.1 is using jackson-annotations 2.9.0)
All-in-all: I opt to keep version forcing and just bump jackson version.

@ewencp, @ijuma: please review.


Gsoc2024 Dask Execution Sample Problem

#240

This was a starter problem for GSoC2024 and not meant to be merged.


docs: Corrected some copy writing information in the document.

We can modify the readme file in packages/node at the same time.


Incorrect documentation for GLFW.glfwSetCallback(long window, GLFWCallbackI cbfun)

Version
3.3.2
Module
GLFW
Bug description
The javadoc of set callback methods specifies that it returns previously set callback or null.
However, if we dive deeper to GLFW*Callback#	createSafe we'll see that it returns newly created callback or null if function pointer is null.
Example:
https://github.com/LWJGL/lwjgl3/blob/master/modules/lwjgl/glfw/src/generated/java/org/lwjgl/glfw/GLFW.java#L4117
https://github.com/LWJGL/lwjgl3/blob/master/modules/lwjgl/glfw/src/generated/java/org/lwjgl/glfw/GLFWMouseButtonCallback.java#L43
https://github.com/LWJGL/lwjgl3/blob/master/modules/lwjgl/glfw/src/generated/java/org/lwjgl/glfw/GLFWMouseButtonCallback.java#L34

Hey @SpinyOwl,
LWJGL bindings include the native documentation, mostly as is. There is no "translation" to Java concepts used for wrapping the native functionality, except in rare cases where an technical/implementation detail can be tricky for Java developers. In this sense, the documentation for GLFW Set*Callback functions is accurate.
A new instance may indeed (but not always) be created for the previously set callback, because these functions return an abstract class type, not the corresponding interface type. However, this is a plain Java wrapper (cheap to allocate) over the native callback function (expensive to allocate). The returned instance can be used to free the native callback and there is no need to store callback instances in user code.


Update commands.py

Remove bug where 'design' was not recognized as a valid key in locals() by declaring cli_render_arguments explicitly.
Cli was installed by  pip install rendercv on python 3.11.2 with 24.0.
Full error on image if fix doesn't fits intended purpose

Thank you! Are you sure this fixes the issue?

The issue also surprised me, I tried to find a solution that was more closely related to your code but was unable to find one, locals() did have 'design' as a valid key so maybe it had something to do with the interaction between locals() and the list comprehension.
I was using rendercv render Santiago_Avalloni_CV.yaml without any additional arguments and the change was made based on the expected output of the argument_names variable because default cli arguments are the same always (also because of this same reason it's not necessary to compute it every time)

I figured out the problem, the thing is that locals() is a dict containing all variables of the current scope so when you are doing a dict comprehension locals() is not the full dict, but a dict containing only the keys 'name' and 'argument_names'. It's difficult to see explicitly but if you do
var = 1
a = [locals() for i in range(1)]

a is a list containing only {'.0': <range_iterator object at 0x000001B5D824BD30>, 'i': 1} and not var

The original code works for me. Could you please share the CLI command that caused this error? I cannot reproduce it.


Difference in Scss since 0.28.21 release

Before 0.28.21 was released my beautified Scss (Sass) looked like this:
/* Imports */
@import "imports/_variables";
@import "imports/_mixins";
@import "imports/reset";
@import "imports/_button";

/* Source */
.content {
	background-color: $dark_brown;
}

form {
	height: 100%;

	.content {
		height: 100%;
	}
}

Now it looks like this (double new lines, extra line between @imports):
/* Imports */
@import "imports/_variables";
@import "imports/_mixins";
@import "imports/reset";

@import "imports/_button";
/* Source */
.content {
	background-color: $dark_brown;
}

form {
	height: 100%;

	.content {
		height: 100%;
	}

}

This will create unneeded differences in my commits.

Atom 1.4.0
Atom Beautify 0.28.21

I just updated to version v0.28.21 this morning and I am having trouble reproducing this defect using either Pretty Diff or CssComb as the beautifier.  The only defect I can reproduce is from Pretty Diff with the strangeness of the empty line appearing before the final import when it should be appearing after (before the comment).

I can confirm this now on two different machines (Windows 7 and Windows 8.1) with Atom 1.4.0 and 1.5.0-beta0. No .jsbeautifyrc file. Following Atom settings:
  "atom-beautify":
    _analyticsUserId: random
    css_convert_quotes: "double"
    css_newline_between_rules: true
    css_preserve_newlines: true
    css_selector_separator_newline: true
    js_end_with_newline: true

I am still having trouble reproducing the problem.  I think I have a solution, but I just need you to verify it.  Could you open the concerned file:  ~/.atom/packages/atom-beautify/node_modules/prettydiff/lib/csspretty.js
And then replace https://github.com/prettydiff/prettydiff/blob/master/lib/csspretty.js#L1129-L1140 with:
token[a] = lf + token[a];

If this works for you I can publish the update tonight.

Better, but still two issues:

Two new lines between rules.
Indentation issue before .content {.

Result:
/* Imports */
@import "imports/_variables";
@import "imports/_mixins";
@import "imports/reset";
@import "imports/_button";

/* Source */
.content {
	background-color: $dark_brown;
}

form {
	height: 100%;

.content {
		height: 100%;
	}
}

I will keep looking.

Got it.  It was interference with the css_newline_between_rules: true option.
If the entire block mentioned earlier is replaced with this:
                if (lines[a] > 1 && (types[a] === "start" || types[a] === "end" || (types[a] === "selector" && options.cssinsertlines === false) || types[a] === "comment")) {
                    token[a] = lf + token[a];
                }

An empty line should not be inserted before a selector if the mentioned option is enabled since its going to get an empty line anyways.

Pretty Diff resolution published as v1.16.12.


Adjust arch opam variable for other architectures

At the moment, we only query the opam variables on x86_64 and assume they are the same on other platforms. But we need to override the arch value at least!

Ahh this explains why we get occasional solver failures from the opam invocation itself.

Now included in #241.