Failed to read ... bytes of file, Failed to read ... from input cabinet file, Failed to extract file

I'm getting Failed to read ... bytes of file, Failed to read ... from input cabinet file, Failed to extract file errors for 2 files. The 3000+ other files are being extracted without issues. No luck with the -O option either. When I'm using the same files to actually run the setup executable, everything gets installed without errors - including the files that unshield fails to extract. So it seems like the files themselves are fine.
I'm using the latest build from the repository:
$ ./unshield -V
Unshield version 1.4.3. MIT License. (C) 2003-2021 David Eriksson.
$ ./unshield -D 3 -d output x data1.cab >logfile 2>&1
$

Here is an excerpt from logfile:
[unshield_read_headers:227] Reading header from .hdr file 1.
[unshield_read_headers:294] Version 0x01007000 handled as major version 7
[unshield_get_cab_descriptor:77] Cabinet descriptor: 0000828e 00059631 00059631 000001a8
[unshield_get_cab_descriptor:84] Directory count: 106
[unshield_get_cab_descriptor:85] File count: 3806
[unshield_file_group_new:15] File group descriptor offset: 00000be4
[unshield_file_group_new:29] File group 00000be4 first file = 19, last file = 19
...
[unshield_reader_open_volume:417] First file offset = 00000000, last file offset = 0eb74537
[unshield_reader_open_volume:443] previous data offset = 0x080
[unshield_reader_open_volume:451] Index 1695 is last file in cabinet file 2
[unshield_reader_open_volume:477] Will read 0x00007ac9 bytes from offset 0x0eb74537
[unshield_reader_read:526] unshield_reader_read start: bytes_left = 0xf40b, volume_bytes_left = 0xf40b
[unshield_reader_read:538] Trying to read 0xf40b bytes from offset 0eb74537 in volume 2
[unshield_reader_read:549] Failed to read 0x0000f40b bytes of file 1695 (card18.p3d) from volume 2. Current offset = 0x0eb7c000
[unshield_file_save:866] Failed to read 62475 bytes from input cabinet file 2
Failed to extract file 'card18.p3d'.
[unshield_read_file_descriptor:106] File descriptor offset: 0002c696
[unshield_reader_open_volume:319] Open volume 3
[unshield_reader_open_volume:415] First file index = 1695, last file index = 3787
[unshield_reader_open_volume:417] First file offset = 00000200, last file offset = 1d57d073
[unshield_reader_read:526] unshield_reader_read start: bytes_left = 0x10000, volume_bytes_left = 0x12718
[unshield_reader_read:538] Trying to read 0x10000 bytes from offset 00007b42 in volume 3
...
[unshield_reader_read:538] Trying to read 0x10000 bytes from offset 289cd073 in volume 3
[unshield_reader_read:560] bytes_left = 0, volume_bytes_left = 39340032
[unshield_reader_read:526] unshield_reader_read start: bytes_left = 0x10000, volume_bytes_left = 0x2584800
[unshield_reader_read:538] Trying to read 0x10000 bytes from offset 289dd073 in volume 3
[unshield_reader_read:549] Failed to read 0x00010000 bytes of file 3787 (music02.rcf) from volume 3. Current offset = 0x289e7000
[unshield_file_save:866] Failed to read 65536 bytes from input cabinet file 3
Failed to extract file 'music02.rcf'.
[unshield_read_file_descriptor:106] File descriptor offset: 00058d8a
[unshield_reader_open_volume:319] Open volume 4
[unshield_reader_open_volume:415] First file index = 3787, last file index = 3805
[unshield_reader_open_volume:417] First file offset = 00000200, last file offset = 00000000
[unshield_reader_read:526] unshield_reader_read start: bytes_left = 0x10000, volume_bytes_left = 0xd7f8800
[unshield_reader_read:538] Trying to read 0x10000 bytes from offset 0257aa73 in volume 4
...

(This whole file is >8 MB.)

You can download the CAB files in question here: myabandonware.com/game/the-simpsons-hit-run-bg6 The game is abandonware.

It's a great tool, by the way. Thanks for doing this! :+1:

Thanks for the report! Could this be the same as #124?

Thanks for the report! Could this be the same as #124?

Thanks for getting back to me! :+1: Yes, maybe you're right and it is the same as #124.
Is there anything I can do to help? It seems like a good idea to fix this issue. However, unfortunately, I couldn't come up with anything. Like I said, you can just run the regular setup program to extract the files, if it helps to have the two missing desired output files.

I'd love to fix this but it will take some time debugging etc and I also have paid work to do and that goes first...


MRG: FIX: Remove regularize from examples

Takes care of the 0.9 part of #1989 so we can hopefully release soon.
This will require an update to the sample dataset :( But in the meantime people can manually add the file from here:
http://staff.washington.edu/larsoner/sample_audvis-shrunk-cov.fif

Ready for review/merge from my end

did you check if it has any impact on the example outputs?

There are some minor changes but they all look reasonable to me. It would be good if you checked, too, though, since I'm not 100% sure if the changes are all good. I couldn't check the lcmv volume one because plotting no longer works with latest nibabel and latest nilearn.

Coverage decreased (-10.48%) to 79.81% when pulling 31aa17f751e1584643865c9e58765a2e2c052473 on Eric89GXL:no-reg into c57294a50d7516733f53bb265470d3ae05437418 on mne-tools:master.

It would be good to add a comment. So people still get reminded of the reg topic.

I'll pull and build docs to see where we are.

Comments addressed. @agramfort feel free to merge once you double-check the examples I touched.

Coverage decreased (-10.48%) to 79.81% when pulling bb938187eb2d94ffdd28d4e4e389bc7afae33d01 on Eric89GXL:no-reg into c57294a50d7516733f53bb265470d3ae05437418 on mne-tools:master.

I have no time to check. Can somebody help? especially the results on the
sparse solvers...

Is it good enough if I post before and after images here?

(so that you can look and decide)

yes

master on top, PR below
plot_gamma_map_inverse.py:

plot_lcmv_beamformer.py:

can't run plot_lcmv_beamformer_volume.py
plot_make_inverse_operator.py:

plot_mixed_norm_inverse.py:

plot_tf_lcmv.py:

plot_time_frequency_mixed_norm_inverse.py:

thx
so the Gamma-MAP looks very different and worse than in master.
The regularization should be maintained only for this example.
btw I am not surprised.

How is it worse? I don't really know what to expect as correct -- but my impression is that it finds the one primary source and a couple of other secondary ones in both cases...?

it misses the secondary ventral sources that peak later

Thanks -- reverted that example. Okay if I merge once Travis is happy?

fine with me. thanks @Eric89GXL !

The mixed-norm example actually looks better imo ...

Coverage decreased (-0.01%) to 90.31% when pulling 5b62909c664c722618c334de0cd16b6b7aceaecc on Eric89GXL:no-reg into 826e4f44370ed41109255bffe0173dfa8799879e on mne-tools:master.

The mixed-norm example actually looks better imo ...

;)

The gamma map should incorporate our cov estimation into it's hyperparameter estimation ....
;)

On 07 May 2015, at 21:24, Alexandre Gramfort<EMAIL_ADDRESS>wrote:

The mixed-norm example actually looks better imo ...

;)
—
Reply to this email directly or view it on GitHub.


[FR] editor.scrollBeyondLastLine : support integer value

I like the scrollBeyondLastLine feature but it scrolls too much to my state and i often find myself beeing scared to have cleared my file :s
That would be great if editor.scrollBeyondLastLine could be a boolean or an integer that would represent the maximium of lines it would overscroll.
Thanks

To keep the number of issues in our inbox at a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: we look at the number of votes the issue has received and the number of duplicate issues filed. Thank you for your time and understanding.
P.S. If you disagree and feel that this issue is crucial: we're happy to listen and to reconsider.

@alexandrudima I wouldn't call it crucial, but personally I still disagree.
If you search for scrollBeyondLastLine in this repo you'll find many people getting regularly confused by the default behavior of VSCode of allowing to scroll down until only one line is visible.
This tells me that having just a binary switch between two extreme states is not sufficient. Being able to configure how much space to leave in lines (#30499) or percentage of screen height would be much more convenient and allow for a saner default. For example, PyCharm shows only 5-6 empty lines after the last line of a file.

I also would like this feature. Do you think it should be percentage of height or number of lines then?

I would also like this feature.
In it's current state (a boolean setting with just one line of over-scroll), the feature makes little sense. Every text file (POSIX, at least) is supposed to end with a new line, so if you scroll all the way down, you always end with one blank line at the top of the screen. At the very least it would be nice if there were 2-3 lines showing so it was more visually obvious.

A duplicate of this was just closed, which reminded me of this. I think a percentage would probably make the most sense, personally. I'd set it to, say, 70% - so that when scrolling all the way down, 70% of my lines are code and 30% is empty space. As I recall, that's approximately how I had Webstorm configured when I used it a couple of years ago.

This seems to be overlapping with "editor.padding.bottom". Working example:
  "editor.scrollBeyondLastLine": false,
  "editor.padding.bottom": 100,


Support custom log4j2 config from user-provided ConfigMap

Fixes: https://github.com/apache/lucene-solr-operator/issues/192
SolrCloud controller now looks for the presence of a log4j2.xml key in the instance.Spec.CustomSolrKubeOptions.ConfigMapOptions.ProvidedConfigMap
The only tricky aspect of this PR is we don't save the md5 in an annotation if the provided Log4j2 config includes monitorInterval= as we don't need to trigger a restart of the Solr pods as Log4j2 will reload the config at runtime. If the config does not include monitorInterval, then we save the md5 hash of the XML in an annotation on the pod spec to trigger a restart as we do for solr.xml
Also, cleaned up some constant string usage around solr.xml and log4j2.xml

Now with docs! ;-)

Now with docs! ;-)


Refactoring: fix issue #126

Description
Fixes #126
Type of change

Bug fix (non-breaking change which fixes an issue)

Codecov Report

Merging #137 into master will decrease coverage by 0.19%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #137      +/-   ##
==========================================
- Coverage   70.14%   69.94%   -0.20%
==========================================
  Files          12       12
  Lines         710      712       +2
==========================================
  Hits          498      498
- Misses        208      210       +2
  Partials        4        4

Impacted Files
Coverage Δ

ioc.go
34.94% <0.00%> (-0.38%)
:arrow_down:

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 eccaf7d...92d98a6. Read the comment docs.


v1alpha2 Laundry List

Some recent customer feedback has exposed some deficiencies in our interface.

Expose PodSpec features (perhaps revision spec?)
Clarify frameworks tensorrt/triton
Explore alternate Canarying implementations (single resource vs multiple resources)

Multi Model Serving APIs: https://github.com/kubeflow/kfserving/issues/773

Another usecase for podspec features #794

/close


Support pronto 0.7.1

Can we update pronto version to 0.7.1 ?

Thanks for the suggestion, I'll do this week.

I've published a new version of this gem 💥

Thanks, github_status works as well!


Recognize ${env:}

Is this a similar or duplicate feature request?

[ ] I don't know. I will go check it.
[x] No.

Describe the solution you'd like
It should be great that sftp recognize variable substitution like ${workspaceFolder} and more ${env:xxx} in it's sftp.json file like tasks & debuggers do.
we are working on small embedded devices that change their IP, and each time the IP is changing, we have to change all configs. With ${env:IP_ADDRESS} we should avoid doing that, just changing environment variable to the new IP address.
Does this project help you?

[x] Yes. SFTP IS AWESOME!
[ ] Yes. I want to support you.

I also encountered such a problem. Have you solved it?

This would be really useful in combination with direnv.
As it is, we don't have good place to put our credentials, putting them in sftp.json is not a good idea.

I strongly support this issue.
Do you plan do to this?


Floyds triangle

Hello @nakul-19 @plazzy99 @rudrakshi99 I want to implement a code in C++ that prints the Floyd's triangle upto n rows.
My code will have proper test cases and comments to make it understandable. I will be very happy if you assign me this issue.

I want to work on this issue. Please assign to me.

This is not a DSA problem, rather an implementation based problem.


Add macOS Terminal.app theme

Signed-off-by: Daniel Bayley<EMAIL_ADDRESS>

Hey @danielbayley. this is awesome. I had a couple of things related to this that I wanted to publish at some point, and this was a good catalyst.
Instead of shipping this with the Sublime Text theme, I thought we could compile all "shell" related things in a different repo. Hence predawn-shell. I made a few minor changes to your Terminal colors to coincide with some decisions I'd made creating the iTerm one.
Let me know what you think. Thanks for the contribution to this!

Cool 👍 Set as my default! You should check out zplug too btw… beats OMZsh!


Apache httpd NixOS module can no longer serve up content from the store

Back in the day, we had a super-cute example in the manual that served up valgrind documentation with something like the following configuration:
{ pkgs, ... }:

{
  services.httpd = {
    enable = true;
    adminAddr =<EMAIL_ADDRESS>    documentRoot = "${pkgs.valgrind}/share/doc/valgrind/html";
  };
  networking.firewall.allowedTCPPorts = [ 80 ];
}

Now something appears to have changed in the httpd module that causes httpd to fail at startup:
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal systemd[1]: Starting Apache HTTPD...
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal httpd-pre-start[3259]: mkdir: cannot create directory ‘/nix/store/ns640dwilpd8d8irlc5mycc661gyan02-valgrind-3.11.0/share’: Read-only file system
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal systemd[1]: httpd.service: Control process exited, code=exited status=1
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal systemd[1]: Failed to start Apache HTTPD.
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal systemd[1]: httpd.service: Unit entered failed state.
Jan 05 18:19:12 ip-172-29-89-171.ec2.internal systemd[1]: httpd.service: Failed with result 'exit-code'.
Jan 05 18:19:17 ip-172-29-89-171.ec2.internal systemd[1]: httpd.service: Service hold-off time over, scheduling restart.
Jan 05 18:19:17 ip-172-29-89-171.ec2.internal systemd[1]: Stopped Apache HTTPD.

I see a few instances of other people encountering this but no obvious fix: https://groups.google.com/forum/#!topic/nixops-users/vDE67k480uM and https://github.com/NixOS/nixops/issues/391
I'm guessing someone added a wrapper to httpd that tries to modify the documentRoot directory? That seems unfortunate, and I love to serve up content from the store (so I can build it with nix and revert/restore like I do with everything else).

I have used this technique before and I'm sorry to hear that it's broken. We should fix it.

This is useful!

It works fine with "${pkgs.valgrind.doc}/share/doc/valgrind/html" 😊

Oh! I guess it's this stuff then:
            ${optionalString (mainCfg.documentRoot != null)
            ''
              # Create the document root directory if does not exists yet
              mkdir -p ${mainCfg.documentRoot}
            ''
            }

Is that really necessary? How often do you want to point your server at a directory that doesn't exist and have the server create it? @svanderburg

Yes it is, I thought it wasn't conditional, then I figured out that the directory doesn't exist.

So I guess this isn't a real bug and I can close it, but I still don't see why it should need to mkdir -p that directory. It should just check that it exists and complain if not?

Yes, since it's supposed to have content.


Add new options to the CLI entrypoint definition.

What does this PR do?
Add missing option in entrypoint CLI parser:

auth.*
redirect.permanent

Motivation
Easy CLI configuration.
More

[x] Added/updated tests
[x] Added/updated documentation

Additional Notes
~The documentation will be updated when #2798 is merged.~

The auth.{basic,digest}.usersFile option is missing here. Or am I missing something here?


WireGuard-rtd1296-1.0.20200401.spk has  v1.0.20200319 binary

hi ,
after installation from Release  WireGuard-rtd1296-1.0.20200401.spk
Version of binary is shows as follows
 wg --version
wireguard-tools v1.0.20200319 - https://git.zx2c4.com/wireguard-tools/
pre-compiled package source : https://github.com/runfalk/synology-wireguard/releases
filename : WireGuard-rtd1296-1.0.20200401.spk**

Hi,
This is expected since the userland tools actually use separate versions. You can see here (https://git.zx2c4.com/wireguard-tools/refs/) that there is no 20200401 version of wireguard-tools. The kernel module itself should be the correct version.
I'll close this for now, let me know if it should be reopened.


REALTED: RAIL-1531 fix IDateFilterRelativePreset types

Currently destined for release R182.
This release is zero downtime release.
Code drop: 2019-05-18 00:00.

Story RAIL-1531 Loading Date Filter Configuration from Project Metadata
Status: Hacking
Priority: Major
Assignee: Dan Homola

Build in pipeline check aborted.

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/client-libs/job/gooddata-typings-pull-request-compliance-check/18/ : SUCCESS in 8s
https://checklist.intgdc.com/job/client-libs/job/gooddata-typings-unit-tests-zuul-docker-el7/87/ : SUCCESS in 51s

Build succeeded (gate pipeline).

https://checklist.intgdc.com/job/client-libs/job/gooddata-typings-pull-request-compliance-gate/9/ : SUCCESS in 11s
https://checklist.intgdc.com/job/client-libs/job/gooddata-typings-unit-tests-zuul-docker-el7/88/ : SUCCESS in 59s


Replace embObjInertial w/ embObjIMU

embObjIMU is the latest device we've been using for dealing with IMU sensing.
The previous version, aka embObjInertial is still employed by a bunch of robots though.
We should then clean up the repo and finalize the upgrade.
cc @marcoaccame @Nicogene @traversaro

Alongside @marcoaccame, yesterday we traced back the development of embObjInertials and embObjIMU and we checked what are the differences between the two.
embObjInertials is the old device that was written some time ago originally for publishing acc and gyro data of imu of ems and mtb3 via AnalogServer; it has been adapted for publishing also via MultipleAnalogSensorsServer.
embObjIMU on the other hand is more recent and supports only publishing via  MultipleAnalogSensorsServer, and it is used for publishing the data from the boards that basically mounts the bno055 imu:

mtb4
rfe

They rely on two different firmware services:

eomn_serv_AS_inertials is used by embObjInertials
eomn_serv_AS_inertials3  is used by embObjIMU

On FW-side eomn_serv_AS_inertials3 has been designed for covering all the functionalities of its predecessor, but for completely substitute it we need first some changes on icub-main.
At the end of this refactoring, we would have only eomn_serv_AS_inertials3, saving some memory in our boards.
In particular, we need:

embObjIMU should handle also eth boards (gyro and acc of ems, see ref)
Add in serviceParser the handle of the cases handled by embObjInertials (see ref we need these cases)
Right now embObjIMU make the convertion raw->metric using one conversion factor (see ref). This was fine until the only imu used was the bno055 unit, but if it has to support also the one in ems and mtb3 this conversion factor has to change in function on the type of the board

cc @pattacini @valegagge @traversaro

Here is the PR on robots-configuration side:

https://github.com/robotology/robots-configuration/pull/540

Note that this is an important step in the analogServer removal.
cc @randaz81 @traversaro

Today w/ the help of @sgiraz and @davidetome I managed to build up a setup for testing the changes of these PRs.
I found and fixed a bug:

robotology/icub-main@ae34a68 (#894)

And I used these xml files for testing it

https://github.com/Nicogene/robots-configuration/commit/7447c443b462bb4e075b14bb7cf207485ffb8d82

Unfortunately, it is not working, I get this log
[DEBUG] Reading file C:\Users\ngenesio\robotology\robots-configuration\experimentalSetups\ems_mtb\.\new_forearm-no_hand.xml
[DEBUG] yarprobotinterface: using xml parser for DTD v3.x
[DEBUG] Reading file C:\Users\ngenesio\robotology\robots-configuration\experimentalSetups\ems_mtb\.\new_forearm-no_hand.xml
[INFO] Yarprobotinterface was started using the following enable_tags:
[INFO] Yarprobotinterface was started using the following disable_tags:
[DEBUG] List of all enable attributes found in the include tags:
[DEBUG] List of all disable attributes found in the include tags:
[DEBUG] Preprocessor complete in:  0.0400258 s
[INFO] |yarp.os.Port|/nfa/yarprobotinterface| Port /nfa/yarprobotinterface active at tcp://<IP_ADDRESS>:10002/
[INFO] startup phase starting...
[INFO] Opening device left_arm-eb2-j4_15-inertials with parameters [("robotName" = "/nfa"), ("GENERAL" [group] = "(skipCalibration false) (useRawEncoderData false) (useLimitedPWM false) (verbose false)"), ("PC104" [group] = "(PC104IpAddress <IP_ADDRESS>) (PC104IpPort 12345) (PC104TXrate 1) (PC104RXrate 5)"), ("ETH_BOARD" [group] = "(ETH_BOARD_PROPERTIES (IpAddress <IP_ADDRESS>) (IpPort 12345) (Type ems4) (maxSizeRXpacket 768) (maxSizeROP 384)) (ETH_BOARD_SETTINGS (Name "wrist-eb2-j0_2") (RUNNINGMODE (period 1000) (maxTimeOfRXactivity 400) (maxTimeOfDOactivity 300) (maxTimeOfTXactivity 300) (TXrateOfRegularROPs 5))) (ETH_BOARD_ACTIONS (MONITOR_ITS_PRESENCE (enabled true) (timeout 0.020) (periodOfMissingReport 60.0)))"), ("SERVICE" [group] = "(type eomn_serv_AS_inertials3) (PROPERTIES (CANBOARDS (type eobrd_mtb) (PROTOCOL (major 0) (minor 0)) (FIRMWARE (major 0) (minor 0) (build 0))) (SENSORS (id on_eb2_gyros l_upper_arm_4) (type eoas_gyros_st_l3g4200d eoas_accel_mtb_int) (boardType ems4 mtb) (location ETH:0 CAN2:10))) (SETTINGS (acquisitionRate 50) (enabledSensors on_eb2_gyros l_upper_arm_4))")]
[DEBUG] |yarp.dev.PolyDriver|left_arm-eb2-j4_15-inertials| Parameters are (ETH_BOARD (ETH_BOARD_PROPERTIES (IpAddress "<IP_ADDRESS>") (IpPort 12345) (Type ems4) (maxSizeRXpacket 768) (maxSizeROP 384)) (ETH_BOARD_SETTINGS (Name wrist-eb2-j0_2) (RUNNINGMODE (period 1000) (maxTimeOfRXactivity 400) (maxTimeOfDOactivity 300) (maxTimeOfTXactivity 300) (TXrateOfRegularROPs 5))) (ETH_BOARD_ACTIONS (MONITOR_ITS_PRESENCE (enabled true) (timeout 0.02) (periodOfMissingReport 60.0)))) (GENERAL (skipCalibration false) (useRawEncoderData false) (useLimitedPWM false) (verbose false)) (PC104 (PC104IpAddress "<IP_ADDRESS>") (PC104IpPort 12345) (PC104TXrate 1) (PC104RXrate 5)) (SERVICE (type eomn_serv_AS_inertials3) (PROPERTIES (CANBOARDS (type eobrd_mtb) (PROTOCOL (major 0) (minor 0)) (FIRMWARE (major 0) (minor 0) (build 0))) (SENSORS (id on_eb2_gyros l_upper_arm_4) (type eoas_gyros_st_l3g4200d eoas_accel_mtb_int) (boardType ems4 mtb) (location "ETH:0" "CAN2:10"))) (SETTINGS (acquisitionRate 50) (enabledSensors on_eb2_gyros l_upper_arm_4))) (device embObjIMU) (id left_arm-eb2-j4_15-inertials) (robotName "/nfa")
[DEBUG] eth::parser::print(pc104Data) for PC104:
[DEBUG] PC104/PC104IpAddress:PC104IpPort =  <IP_ADDRESS>:12345
[DEBUG] PC104/PC104TXrate =  1
[DEBUG] PC104/PC104RXrate =  5
[DEBUG] EthSender is a PeriodicThread with txrate = 1 ms
[DEBUG] EthReceiver is a PeriodicThread with rxrate = 5 ms
[WARNING] in EthReceiver::config() the config socket has queue size =  1048576 ; you request ETHRECEIVER_BUFFER_SIZE=
[DEBUG] eth::parser::print(boardData) for BOARD wrist-eb2-j0_2
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES:
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES/IpAddress =  <IP_ADDRESS>
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES/IpPort =  12345
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES/Type =  ems4
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeRXpacket =  768
[DEBUG] ETH_BOARD/ETH_BOARD_PROPERTIES/maxSizeROP =  384
[DEBUG] ETH_BOARD/ETH_BOARD_SETTINGS:
[DEBUG] ETH_BOARD/ETH_BOARD_SETTINGS/Name =  wrist-eb2-j0_2
[DEBUG] ETH_BOARD/ETH_BOARD_SETTINGS/RUNNINGMODE/(period, maxTimeOfRXactivity, maxTimeOfDOactivity, maxTimeOfTXactivity, TXrateOfRegularROPs) =  1000 400 300 300 5
[DEBUG] ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE
[DEBUG] ETH_BOARD/ETH_BOARD_ACTIONS/MONITOR_ITS_PRESENCE/(enabled, timeout, periodOfMissingReport) =  true 0.02 60
[DEBUG] eth::EthMonitorPresence::config(): monitoring of presence is ON for BOARD <IP_ADDRESS> (wrist-eb2-j0_2) with timeout = 0.02 sec and period of missing report = 60 sec
[DEBUG] TheEthManager::requestResource2(): has just succesfully created a new EthResource for board of type ems4 with IP =  <IP_ADDRESS>
[WARNING] ServiceParser::check_analog() cannot find PROPERTIES.SENSORS.sensorName
[DEBUG] EthResource::verifyBoardPresence() found BOARD wrist-eb2-j0_2 with IP <IP_ADDRESS> after 0.0029291 seconds
[DEBUG] EthResource::verifyBoardTransceiver() has validated the transceiver of BOARD wrist-eb2-j0_2 with IP <IP_ADDRESS>
[DEBUG] EthResource::cleanBoardBehaviour() has cleaned the application in BOARD wrist-eb2-j0_2 with IP <IP_ADDRESS> : config mode + cleared all its regulars
[DEBUG] EthResource::setTimingOfRunningCycle() for BOARD wrist-eb2-j0_2 with IP <IP_ADDRESS> has succesfully set: cycletime = 1000 usec, RX DO TX = ( 400 300 300 ) usec and TX rate = 5  every cycle
[INFO] EthResource::askBoardVersion() found BOARD wrist-eb2-j0_2 @ IP <IP_ADDRESS> of type ems4 with FW = ver 3.69 built on 2023 Jul 03 12:20
[INFO]  from BOARD <IP_ADDRESS> (0#∞NΘ☺) @ 18s 282m 698u: CAN discovery has started for 1 eobrd_mtb boards on (can1map, can2map) = (0x0000, 0x0400) with target can protocol ver 0.0 and application ver 0.0.0.
[WARNING]  from BOARD <IP_ADDRESS> (0#∞NΘ☺) @ 18s 282m 869u: CAN discovery is OK but FAKE (without any control on CAN w/ get-fw-version<> message) for 1 eobrd_mtb boards with target can protocol ver 0.0 and application ver 0.0.0. Search time was 0 ms
[DEBUG]  from BOARD <IP_ADDRESS> (0#∞NΘ☺), src LOCAL, adr 0, time 18s 282m 994u: (code 0x05000030, par16 0x0000 par64 0x0000000000000000) -> CFG: EOtheInertial3 can be correctly configured. tbd + .
[INFO] |yarp.dev.PolyDriver|left_arm-eb2-j4_15-inertials| Created device <embObjIMU>. See C++ class yarp::dev::embObjIMU for documentation.
[INFO] Opening device left_arm-inertials_wrapper with parameters [("robotName" = "/nfa"), ("period" = "10"), ("name" = "/icub/left_hand/inertialMTB")]
[DEBUG] |yarp.dev.PolyDriver|left_arm-inertials_wrapper| Parameters are (device multipleanalogsensorsserver) (id left_arm-inertials_wrapper) (name "/icub/left_hand/inertialMTB") (period 10) (robotName "/nfa")
[INFO] |yarp.dev.PolyDriver|left_arm-inertials_wrapper| Created wrapper <multipleanalogsensorsserver>. See C++ class MultipleAnalogSensorsServer for documentation.
[INFO] Entering action level 5 of phase startup
[INFO] Executing attach action, level 5 on device left_arm-inertials_wrapper with parameters [("networks" = "(SetOfInertials)"), ("SetOfInertials" = "left_arm-eb2-j4_15-inertials")]
[INFO] left_arm-inertials_wrapper is not an IWrapper. Trying IMultipleWrapper
[INFO] |yarp.os.Port|/icub/left_hand/inertialMTB/measures:o| Port /icub/left_hand/inertialMTB/measures:o active at tcp://<IP_ADDRESS>:10003/
[INFO] |yarp.os.Port|/icub/left_hand/inertialMTB/rpc:o| Port /icub/left_hand/inertialMTB/rpc:o active at tcp://<IP_ADDRESS>:10004/
[INFO] All actions for action level 5 of startup phase started. Waiting for unfinished actions.
[INFO] All actions for action level 5 of startup phase finished.
[INFO] startup phase finished.
[INFO] run phase starting...
[DEBUG] yarprobotinterface running happily
[WARNING]  from BOARD <IP_ADDRESS> (0#∞NΘ☺), src LOCAL, adr 0, time 19s 301m 912u: (code 0x00000039, par16 0x0005 par64 0x0000000000000400) -> SYS: a service has detected that some CAN boards are not broacasting anymore. In par16 the type of service, in par64 LS 32 bits the bit mask of lost board (CAN1 in MS 16 bits and CAN2 in LS 16 bits) + .

to be investigated
cc @marcoaccame

[WARNING]  from BOARD <IP_ADDRESS> (0#∞NΘ☺) @ 18s 282m 869u: CAN discovery is OK but FAKE (without any control on CAN w/ get-fw-version<> message) for 1 eobrd_mtb boards with target can protocol ver 0.0 and application ver 0.0.0. Search time was 0 ms

you should avoid a fake discovery in testing. it may be that the mtb does not work and you don't know.
Luckily, there is

[WARNING]  from BOARD <IP_ADDRESS> (0#∞NΘ☺), src LOCAL, adr 0, time 19s 301m 912u: (code 0x00000039, par16 0x0005 par64 0x0000000000000400) -> SYS: a service has detected that some CAN boards are not broacasting anymore. In par16 the type of service, in par64 LS 32 bits the bit mask of lost board (CAN1 in MS 16 bits and CAN2 in LS 16 bits) + .

telling you that. I suggest to add a proper application and protocol version in teh xml and try again. Also, using the CAN sniffer can help.

Alongside @marcoaccame, today we did an in-deep analysis of the situation of service support for the boards.
The reason of

WARNING] from BOARD <IP_ADDRESS> (0#∞NΘ☺), src LOCAL, adr 0, time 19s 301m 912u: (code 0x00000039, par16 0x0005 par64 0x0000000000000400) -> SYS: a service has detected that some CAN boards are not broacasting anymore. In par16 the type of service, in par64 LS 32 bits the bit mask of lost board (CAN1 in MS 16 bits and CAN2 in LS 16 bits) + .

is that eomn_serv_AS_inertials3 sends can messages for start/stop broadcasting different to the one of eomn_serv_AS_inertials.
Right now w/ the current version of the FW of the ems is not possible to use eomn_serv_AS_inertials3 w/ mtb gyro/acc and ems gyro.
We also tested if the boards we are using are functional and using eomn_serv_AS_inertials and embObjInertials everything works fine.
The next action point is to copy/paste in eomn_serv_AS_inertials3 the messages that mtb expect and test embObjIMU. If everything works fine we should merge eomn_serv_AS_inertials in eomn_serv_AS_inertials3 for handling the 2 different protocols in function of the type of the board. This latter step will be done/tracked in a separate issue since requires important changes

Today alongside @marcoaccame we did more tweaks/fixes for using embObjIMU w/ mtb:

robotology/icub-main@8478238 (#894)
https://github.com/robotology/icub-firmware/commit/d50044c9e2f9549dca904ff57977fc262dfb9a1c
https://github.com/robotology/icub-firmware/commit/55061a1f984f4460c80939b6ca88f94a7f77ce7c

Now the yarprobotinterface starts fine but no data is published by the multipleanalogsensorsserver, this is due to the fact we are falling in this if:

https://github.com/robotology/icub-main/blob/6cdeaf1b8ff245dcf5b03cd7cdbb59bc6d0a2633/src/libraries/icubmod/embObjIMU/embObjIMU.cpp#L307-L321

Probably there is something to be checked in the eo_inertials3_Tick function because we are receiving from the board "strange" id and board types:
[ERROR] NOT VALID value[0] is: seq = 0, timestamp = 2131344, type = eoas_gyros_mtb_ext, id = 26, v= ((0), -1, -1, -1), status = 0

We are configuring eoas_acc_mtb_int and id 26 is off.
To be further investigated

Let's revive this task. I have rebased and pushed all the dev branches, here are the PRs:

https://github.com/robotology/robots-configuration/pull/540
https://github.com/robotology/icub-main/pull/894
https://github.com/robotology/icub-firmware/pull/439

On icub-main side make consider also eoas_accel_mtb_int, eoas_accel_mtb_ext, eoas_gyros_mtb_ext, eoas_gyros_st_l3g4200d as a type of data ok to be published by MASServer

It has been done in this commit:

https://github.com/robotology/icub-main/pull/894/commits/e27411818a63f9b8307ffd17510289d79fc5b9f6

On the low level I didn't change anything, I added a logic to remap the sens_index on the different types of gyros and acceleration (legacy and "new").
It works both w/ ems firmware modified + gyro ems + acc mtb and ems firmware @ devel + accel mtb4.
I will try to read both mtb and mtb4 gyro/acc after the merge of inertials2 and inertials3 is completed

"Merge" of eo_inertials2_TxStart/Stop and eo_inertials_3_TxStart/Stop, now we are invoking the 2 for this test

Alongside @marcoaccame we managed to accomplish this task, and in the latest commit in icub-main I refactored embObjIMU in order to remove the class imuMeasureConverter, now the factor is handled as a simple double of sensorInfo_t class.
We managed to run a yarprobotinterface that published both rfe imu data, mtb accel and ems gyro all togheter just using the inertial3 service 🚀

Today I tried to make it possible to configurate and activate the EOInertials3 service without can boards attached and only the ems gyro, since the old service allowed to do it.
Here is the commit that should do it, but it fails:

https://github.com/robotology/icub-firmware/pull/439/commits/a63cb5e0519be5e9ce7e649ce4109a55c37af5b1

On icub-main side I get just this error that is not very informative:
[ERROR] embObjIMU: BOARD wrist-eb2-j0_2 (IP <IP_ADDRESS>)  open() fails to start as service.... cannot continue
[ERROR] |yarp.dev.PolyDriver|left_arm-eb2-j4_15-inertials| Driver <embObjIMU> was found but could not open

I can have a look at that

Today I tried to make it possible to configurate and activate the EOInertials3 service without can boards attached and only the ems gyro, since the old service allowed to do it.
Here is the commit that should do it, but it fails:

robotology/icub-firmware@a63cb5e

On icub-main side I get just this error that is not very informative:
[ERROR] embObjIMU: BOARD wrist-eb2-j0_2 (IP <IP_ADDRESS>)  open() fails to start as service.... cannot continue
[ERROR] |yarp.dev.PolyDriver|left_arm-eb2-j4_15-inertials| Driver <embObjIMU> was found but could not open

Having just one can board enabled make yarprobotinterface run happily

Hi @Nicogene, this commit should have fixed. Will you pls test it?

Today I tried to make it possible to configurate and activate the EOInertials3 service without can boards attached and only the ems gyro, since the old service allowed to do it.
Here is the commit that should do it, but it fails:

robotology/icub-firmware@a63cb5e

On icub-main side I get just this error that is not very informative:
[ERROR] embObjIMU: BOARD wrist-eb2-j0_2 (IP <IP_ADDRESS>)  open() fails to start as service.... cannot continue
[ERROR] |yarp.dev.PolyDriver|left_arm-eb2-j4_15-inertials| Driver <embObjIMU> was found but could not open

Having just one can board enabled make yarprobotinterface run happily

Hi @Nicogene, this commit should have fixed. Will you pls test it?

Yes sure! I will test it on wednesday!
/remind Wednesday 22 November

Today I tested the only-ems case w/ this configuration:
the yarprobotinterface runs smoothly and I got this output:
(((-33.0 16.0 -142.0)<PHONE_NUMBER>7989998)) () () () () () () () () ()

The firmware of the rfe, mtb3, mtb4 has not been changed, the only thing that could potentially introduce regression is the refactoring on icub-main layer for the conversion factor of the different sensors (acc, gyro, mag, eul etc).
For this reason I tried to acquire from the rfe using icub-main @ devel and icub-main w/ our refactoring and as you can see the result is ~ identical
icub-main@devel
(((0.125 0.0 -0.0625)<PHONE_NUMBER>4559998)) (((-0.68999999999999995 1.6699999999999999 -9.6300000000000008)<PHONE_NUMBER>4479997)) (((4.125e-05 3.2499999999999997e-05 7.5375000000000003e-05)<PHONE_NUMBER>4539998)) (((170.0 3.5 -117.4375)<PHONE_NUMBER>4579998)) () () () () () ()

icub-main@refactorEmbObjIMU
(((-0.0625 0.0 0.0)<PHONE_NUMBER>1950002)) (((-0.68000000000000005 1.6899999999999999 -9.6400000000000006)<PHONE_NUMBER>1900001)) (((4.125e-05 3.2874999999999999e-05 7.5500000000000006e-05)<PHONE_NUMBER>1930001)) (((170.0 3.4375 -117.4375)<PHONE_NUMBER>1970002)) () () () () () ()

cc @marcoaccame @pattacini

All the PRs

https://github.com/robotology/icub-main/pull/894
https://github.com/robotology/icub-firmware/pull/439
https://github.com/robotology/icub-firmware-build/pull/117
https://github.com/robotology/robots-configuration/pull/540

Are ready to be merged except the one on robots-configuration because while working on this activity w/ @marcoaccame we noticed that eoas_accel_st_lis3x is not handled either in EoInertial2 and EoInertials3 but it is in several xml files, see:

icub-firmware: https://github.com/search?q=repo%3Arobotology%2Ficub-firmware eoas_accel_st_lis3x     &type=code
robots-configuration: https://github.com/search?q=repo%3Arobotology%2Frobots-configuration eoas_accel_st_lis3x     &type=code

The first 3 PR can be safely merged, I will fix the one on robots-configuration and mark it as ready asap
cc @pattacini @marcoaccame

The first 3 PR can be safely merged, I will fix the one on robots-configuration and mark it as ready asap

Everything should be now good to go 🚀


Publishing broken on trunk

Gradle 8 failing on broken task dependency between webpack and compilation.
Example: https://github.com/cashapp/redwood/actions/runs/4815788034/jobs/8575162000

This also happens locally for me because I run a full build a lot. Very annoying.

Okay the problem is that two modules with js { binaries.executable() } both depend on the repo-local projects being installed (via npm) into reporoot/build/js/packages/ folder.
Going to try and make a quick minimal repro to file an issue. I don't quite know how to work around it.


[WIP] add state to distributions using enum

making the changes requested in https://github.com/rubyforgood/diaper/pull/1075
I'm setting as a work in progress because at the moment it only switches from scheduled to complete, I'm not sure where exactly to add the started to scheduled state change to a distribution.

Since the feature here is adding the state changes, let's say that scheduled and complete are enough. We can add additional state(s) as necessary later on.
Thank you!

sorry for the delay guys, now scheduled and complete are the only states on distribution.

@GabrielRMuller Is this ready to be reviewed?

hey, sorry for the delay, I'll try to get this stuff done by today!

Ok, this PR is currently an orphan branch because I've deleted my old fork and forgot about this open PR I had. So to make the changes I had to make them in a new PR, you can take a look here #1213. So sorry about this mess up :(

@GabrielRMuller Not a problem!
I'll take a look

Completed by #1213


Textures are looks abnormal in Android export.

Godot version
4.0 beta 3
System information
Zorin OS,GLES3, intel i3 5005U
Issue description
In editor which I assign textures are looks good in editor and pc export but when i export for Android so it's look abnormal.
Steps to reproduce
i have tried to change the render settings of Android as pc render settings but that's not work, so please if you are reading this and you have solution so send me as soon as possible.
Minimal reproduction project
3d runner game

Have you tried setting compression mode to Lossless in import settings? At this point that is the only mode that works on the Quest 2 (Android)

@sohamgamedev or @alcomposer Please upload a minimal reproduction project to make this easier to troubleshoot.

update
Swizzling the texture of VRAM-Compressed with bgr fixes the color issue in Quest 2 builds. But obviously shows the wrong color in game Godot editor.

Duplicate of https://github.com/godotengine/godot/issues/65127.


fix: adjust custom err from cert-check due to libgit2 1.8 change

What does this PR try to resolve?
libgit2 disallows overriding errors from certificate check since v1.8.0,
so we store the error additionally and unwrap it later.
How should we test and review this PR?
I believe it is due to this change: https://github.com/libgit2/libgit2/commit/9a9f220119d9647a352867b24b0556195cb26548
Actually, in the doc of git_error_set it does state that the custom message might be overridden by libgit2 internals.
I am not sure if this should be fixed in upstream libgit2 or by our own,
but it's better to do it now then waiting for libgit2 1.8.2
Additional information
r? ehuss

This commit shows that the code change are compatible with both libgit2 1.7 and 1.8: https://github.com/rust-lang/cargo/commit/aa2ad97a77fcf126bdd7ceb73a0c5fbf936a2abb. I believe this is good to merge now without waiting for a new git2-rs release.

Yea, it was a little precarious how the error was getting shuttled around. Thank you very much for looking into this and getting it fixed!
@bors r+

:pushpin: Commit 0978162ebe032e803dab4bc3e2094a51fc717f84 has been approved by ehuss
It is now in the queue for this repository.

:hourglass: Testing commit 0978162ebe032e803dab4bc3e2094a51fc717f84 with merge ef56deb2687c5bcf249c16a8fb86dbbe5d78f271...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing ef56deb2687c5bcf249c16a8fb86dbbe5d78f271 to master...


[SPARK-25221][DEPLOY] Consistent trailing whitespace treatment of conf values

What changes were proposed in this pull request?
Stop trimming values of properties loaded from a file
How was this patch tested?
Added unit test demonstrating the issue hit in production.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@jerryshao here is my new take on the problem that should be more acceptable. The premise is that since JDK has already parsed out natural line delimiters '\r' and '\n', the remaining ones are user-provided escaped line delimiters.
@steveloughran would you mind taking a look as well?

This actually makes sense. We always forget this, but java properties file format is more complex than any of us remember
At the time of this trim taking place, all CR/LF chars in the source file will have been stripped through one of

being the end of an entry: property contains all chars up to that line break (or line skipped if empty/comment)
being proceeded by a backslash, in which case the following line will have its initial whitespace stripped then joined to the subsequent line.

Whoever did the wikipedia article did some good examples
What this means is: by the time the spark trim() code is reached, the only CR and LF entries in a property are those from expanding \r and \n character pairs in the actual property itself. All of these within a property, e.g p1=a\nb already get through, this extends it to propertlies like p2=\r.

should be able to easy to write some tests for trimExceptCRLF() directly, e.g. how it handles odd strings (one char, value == 0), empty string, ...
There's an XML format for properties too, which should also be tested to see WTF goes on there.

PS, looking up for the properties spec highlights that Java 9 uses UTF-8 for the properties encoding. Don't know of any implications here.

@steveloughran Regarding XML format, java.util.Properties has its dedicated storeTo/loadFromXML methods which Spark does not use, so we don't need to check this

code LGTM. Clearly its a tangible problem, especially for some one-char option like "myapp.line.separator"

rebased

ok to test

adding @vanzin as well.

Test build #95782 has started for PR 22213 at commit 9e4ac10.

Test build #95782 has finished for PR 22213 at commit 9e4ac10.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95782/
Test FAILed.

Test build #95786 has started for PR 22213 at commit 01d0904.

Test build #95786 has finished for PR 22213 at commit 01d0904.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95786/
Test PASSed.

Test build #95819 has started for PR 22213 at commit d341dae.

Test build #95820 has started for PR 22213 at commit 603fdc9.

Test build #95820 has finished for PR 22213 at commit 603fdc9.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95820/
Test FAILed.

Test build #95819 has finished for PR 22213 at commit d341dae.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

retest this please

Test build #95826 has started for PR 22213 at commit 603fdc9.

Test build #95826 has finished for PR 22213 at commit 603fdc9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95826/
Test PASSed.

Seems fine to me too.

Test build #95920 has started for PR 22213 at commit 76635ce.

Test build #95920 has finished for PR 22213 at commit 76635ce.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95920/
Test FAILed.

retest this please

Test build #95934 has started for PR 22213 at commit 76635ce.

Test build #95934 has finished for PR 22213 at commit 76635ce.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95934/
Test PASSed.

Merging to master / 2.4.

Thank you for reviews @vanzin @steveloughran @jerryshao @HyukjinKwon


Revert "Revert "Add silent, show-error, fail and retries to curl commands""

Reverts DataDog/test-infra-definitions#668 adding tests for the docker environment

/merge

/merge

/merge


Make basic cleaning kata

a new kata on cleaning the workspace

Hi Tom!
Thank you for your contribution, I'm so happy to see the katas improve.
Great work in an area that we've not gotten covered already ❤


change height or number of visible options in optionsList

Is your feature request related to a problem? Please describe.
I would like to be able to see more than 3 options without scrolling. Is this possible ? optionsListStyle height does not work. Otherwise it would be nice to be able to specify the height or the number of visible options 🙂
Describe the solution you'd like
Either a style prop or a prop to control number of visible elements if the height is calculated based on visible options.
Let me know if this is already possible or i missed something 🙂
Thanks for this awesome plugin, its really nice !

Hi @AlexanderLindkjaer
could you try to set maxHeight instead height please?

optionsListStyle={{maxHeight:300}} is work

leaving an example
`
return (
  <SelectProvider>
   <Text style = {{ height: 200 }}>
    Peter Schiff was right
   </Text>

    <View style={{ flex: 1, alignItems: 'center',  maxWidth: '90%',  padding: 20 }}>
      <Select

      styles = {
          {
            select: {
              container: { backgroundColor: 'yellow'}
            },
            optionsList: { minHeight: 300 }
          }
       }

       options={datum}
       placeholderTextColor="red"
       hasBackdrop={false}
       hideArrow={true}
        />

    </View>
  </SelectProvider>
);

`


Redesign diagrams section

The design is great!
I see where you're going with the tone, but I don't dig it :(
But again there's a lot of good new ideas in there.
I'll probably suggest some stuff based on it later today

@aeplay I will also revisit this later today

@aeplay Let's make this PR just a redesign for now, as I'm out of ideas at the moment. Also, I force pushed because it was easier to resolve conflicts this way.

Makes sense, thank you!


Cannot search this from Visual Studio Code Extentions,I hope the author can publish this to the vscode as soon as possible

VSCode is completely different from VS's technology stack and is not what I'm good at, so hopefully someone else can do it.


how to except last layers in SensitivityPruner

Describe the issue:
I use config_list set the op_names which I want to prune. but it seems not work because last layer is also pruned.
the config_list is
config_list = [
    {
      'sparsity': args.sparsity,
      'op_types': ['Conv2d'],
      'op_names': ['backbone_2d.blocks.0.1',
                  'backbone_2d.blocks.0.4',
                  'backbone_2d.blocks.0.7',
                  'backbone_2d.blocks.0.10',
                  'backbone_2d.blocks.1.1',
                  'backbone_2d.blocks.1.4',
                  'backbone_2d.blocks.1.7',
                  'backbone_2d.blocks.1.10',
                  'backbone_2d.blocks.1.13',
                  'backbone_2d.blocks.1.16',
                  'backbone_2d.blocks.2.1',
                  'backbone_2d.blocks.2.4',
                  'backbone_2d.blocks.2.7',
                  'backbone_2d.blocks.2.10',
                  'backbone_2d.blocks.2.13',
                  'backbone_2d.blocks.2.16']
  }]

and the output is
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.0.1 remain/total: 47/64
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.0.4 remain/total: 50/64
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.0.7 remain/total: 53/64
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.0.10 remain/total: 47/64
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.1 remain/total: 95/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.4 remain/total: 108/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.7 remain/total: 95/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.10 remain/total: 85/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.13 remain/total: 95/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.1.16 remain/total: 95/128
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.1 remain/total: 165/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.4 remain/total: 127/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.7 remain/total: 159/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.10 remain/total: 161/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.13 remain/total: 151/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune backbone_2d.blocks.2.16 remain/total: 130/256
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune dense_head.conv_cls remain/total: 34/162
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune dense_head.conv_box remain/total: 21/126
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) simulated prune dense_head.conv_dir_cls remain/total: 6/36
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) Model state_dict saved to ./experiment_data_l2/pruned.pth
[2021-06-11 03:16:54] INFO (nni.compression.pytorch.compressor/MainThread) Mask dict saved to ./experiment_data_l2/mask.pth

and I found exclude param in this doc Compression/Tutorial
but it seems not work for SensitivityPruner？
Environment:

NNI version: 2.0
Training service (local|remote|pai|aml|etc):local
Client OS: ubuntu18.04
Server OS (for remote mode only):
Python version:3.7.9
PyTorch/TensorFlow version:1.5.0
Is conda/virtualenv/venv used?:conda
Is running in Docker?:no

Configuration:

Experiment config (remember to remove secrets!):
Search space:

Log message:

nnimanager.log:
dispatcher.log:
nnictl stdout and stderr:

How to reproduce it?:

@chasingw If you want to use exclude, you can modify the validate code for a workaround, this pr is for your reference: https://github.com/microsoft/nni/pull/3815

as the reference has been provided and there are no responds so far, closing the issue. feel free to reopen if it is still an issue.


Bratseth/enforce block order

@mpolden please review

(Read the commit message of the second commit)


[SPARK-34745][SQL] Unify overflow exception error message of integral types

What changes were proposed in this pull request?

Current, the overflow exception error messages of integral types are different.
For Byte/Short type, the message is "... caused overflow"
For Int/Long, the message is "int/long overflow" since Spark is calling the "*Exact"(e.g. addExact, negateExact) methods from java.lang.Math.
We should unify the error message by changing the message of Byte/Short as "tinyint/smallint overflow"
Why are the changes needed?

Standardize exception messages in Spark
Does this PR introduce any user-facing change?

Yes, change the error message.
How was this patch tested?

Unit tests.

Test build #136069 has started for PR 31840 at commit ff16782.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40652/


OVLW-DETR Source Code

Dear Author,
First of all let me congratulation you on the two fantastic work LW-DETR and OVLW-DETR.
I'm very much intreseted in OVLV-DETR and would like to have a view on the source code.
Any idea when this source code will be made available.
Thanks
Amit

+1

+2


Failed to load package Cannot find module 'fs-plus'

[Enter steps to reproduce below:]

...
...

Atom Version: 1.10.0
Electron Version: 0.37.8
System: Mac OS X 10.11.1
Thrown From: nvatom package, v0.11.0
Stack Trace
Failed to load the nvatom package
At Cannot find module 'fs-plus'

Error: Cannot find module 'fs-plus'
    at Module._resolveFilename (module.js:339:15)
    at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Object.<anonymous> (/Users/jimlantay/.atom/packages/nvatom-master/lib/notational-velocity.coffee:2:6)
    at Object.<anonymous> (/Users/jimlantay/.atom/packages/nvatom-master/lib/notational-velocity.coffee:1:1)
    at Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
    at Object.defineProperty.value [as .coffee] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
    at Package.module.exports.Package.requireMainModule (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:718:27)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/package.js:117:28
    at Package.module.exports.Package.measure (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:92:15)
    at Package.module.exports.Package.load (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:106:12)
    at PackageManager.module.exports.PackageManager.loadPackage (/Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:457:14)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:402:19
    at Config.module.exports.Config.transact (/Applications/Atom.app/Contents/Resources/app.asar/src/config.js:312:16)
    at PackageManager.module.exports.PackageManager.loadPackages (/Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:397:19)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/atom-environment.js:754:28

Commands

Config
{
  "nvatom": {
    "directory": "/Users/jimlantay/Dropbox/nvatom"
  }
}

Installed Packages
# User
nvatom, v0.11.0 (inactive)
atom-dark-syntax, v0.27.0 (inactive)
atom-dark-ui, v0.52.0 (inactive)
atom-light-syntax, v0.28.0 (inactive)
atom-light-ui, v0.44.0 (inactive)
base16-tomorrow-dark-theme, v1.1.0 (inactive)
base16-tomorrow-light-theme, v1.1.1 (inactive)
one-dark-ui, v1.5.0 (inactive)
one-light-ui, v1.5.0 (inactive)
one-dark-syntax, v1.3.0 (inactive)
one-light-syntax, v1.3.0 (inactive)
solarized-dark-syntax, v1.0.2 (inactive)
solarized-light-syntax, v1.0.2 (inactive)
about, v1.5.3 (inactive)
archive-view, v0.61.1 (inactive)
autocomplete-atom-api, v0.10.0 (inactive)
autocomplete-css, v0.11.2 (inactive)
autocomplete-html, v0.7.2 (inactive)
autocomplete-plus, v2.31.1 (inactive)
autocomplete-snippets, v1.11.0 (inactive)
autoflow, v0.27.0 (inactive)
autosave, v0.23.1 (inactive)
background-tips, v0.26.1 (inactive)
bookmarks, v0.41.0 (inactive)
bracket-matcher, v0.82.1 (inactive)
command-palette, v0.38.0 (inactive)
deprecation-cop, v0.54.1 (inactive)
dev-live-reload, v0.47.0 (inactive)
encoding-selector, v0.22.0 (inactive)
exception-reporting, v0.39.0 (inactive)
find-and-replace, v0.201.0 (inactive)
fuzzy-finder, v1.3.0 (inactive)
git-diff, v1.1.0 (inactive)
go-to-line, v0.31.0 (inactive)
grammar-selector, v0.48.1 (inactive)
image-view, v0.58.2 (inactive)
incompatible-packages, v0.26.1 (inactive)
keybinding-resolver, v0.35.0 (inactive)
line-ending-selector, v0.5.0 (inactive)
link, v0.31.1 (inactive)
markdown-preview, v0.158.0 (inactive)
metrics, v0.53.1 (inactive)
notifications, v0.65.0 (inactive)
open-on-github, v1.2.0 (inactive)
package-generator, v1.0.0 (inactive)
settings-view, v0.241.2 (inactive)
snippets, v1.0.2 (inactive)
spell-check, v0.67.1 (inactive)
status-bar, v1.4.1 (inactive)
styleguide, v0.47.0 (inactive)
symbols-view, v0.113.0 (inactive)
tabs, v0.100.2 (inactive)
timecop, v0.33.2 (inactive)
tree-view, v0.208.2 (inactive)
update-package-dependencies, v0.10.0 (inactive)
welcome, v0.34.0 (inactive)
whitespace, v0.33.0 (inactive)
wrap-guide, v0.38.1 (inactive)
language-c, v0.52.1 (inactive)
language-clojure, v0.21.0 (inactive)
language-coffee-script, v0.47.2 (inactive)
language-csharp, v0.12.1 (inactive)
language-css, v0.37.1 (inactive)
language-gfm, v0.88.0 (inactive)
language-git, v0.15.0 (inactive)
language-go, v0.42.1 (inactive)
language-html, v0.45.1 (inactive)
language-hyperlink, v0.16.0 (inactive)
language-java, v0.23.0 (inactive)
language-javascript, v0.119.0 (inactive)
language-json, v0.18.2 (inactive)
language-less, v0.29.5 (inactive)
language-make, v0.22.2 (inactive)
language-mustache, v0.13.0 (inactive)
language-objective-c, v0.15.1 (inactive)
language-perl, v0.35.0 (inactive)
language-php, v0.37.2 (inactive)
language-property-list, v0.8.0 (inactive)
language-python, v0.45.0 (inactive)
language-ruby, v0.69.0 (inactive)
language-ruby-on-rails, v0.25.0 (inactive)
language-sass, v0.56.0 (inactive)
language-shellscript, v0.22.4 (inactive)
language-source, v0.9.0 (inactive)
language-sql, v0.23.0 (inactive)
language-text, v0.7.1 (inactive)
language-todo, v0.28.0 (inactive)
language-toml, v0.18.0 (inactive)
language-xml, v0.34.9 (inactive)
language-yaml, v0.26.0 (inactive)

# Dev
No dev packages

Originally tried downloading file from github and putting it in packages folder, but issue was resolved when deleted that file then installed from Atom's install menu. Thanks!


When code for the TSR will be released?

When will code for TR task  be released？ Do you have a plan? #132

Any update on this?


[Bug]: mv allows invalid values

/mv version -p output
4.3.2-SNAPSHOT-b870
Server Version
This server is running Paper version git-Paper-408 (MC: 1.17.1) (Implementing API version 1.17.1-R0.1-SNAPSHOT) (Git: cc43ba7 on ver/1.17.1)

Bug Description
Example pvp (but that may affect everything):
set mv modify set pvp on allow and the result is success although allow will not work at all

Steps to reproduce

use "mv modify set pvp test"
the confirmation is successful

Agreements

[X] I have searched for and ensured there isn't already an open or resolved issue(s) regarding this.
[X] I was able to reproduce my issue on a freshly setup and up-to-date server with the latest version of Multiverse plugins with no other plugins and with no kinds of other server or client mods.

This affects all Boolean values (I cannot edit the title, If someone else could that could be appreciated)


SPIKE: Separate the client/server test suites on Travis

no issue

add separate grunt tasks for validating all/client/server test suites
modify grunt validate to respect the TEST_SUITE env var if present
default to TEST_SUITE=server on Travis
add an individual build to the Travis matrix that tests the client

Previously we were duplicating the client tests for every node and database version in our build matrix. Duplicating client tests is now a waste of time/resources as the tests are now completely isolated from the server and so different node/database versions have no effect. This PR is an attempt at removing the duplication to speed up our Travis runs.
Other things that would be nice to implement:

[ ] Run the linting as a separate build - the files won't change between builds so re-running linting for every build in the matrix is wasteful (it may also give more visibility when it's just linting that has failed?)
[ ] Skip the ember build tasks for the server-only test suite

I think the above would dramatically speed up our Travis runs - the build and lint steps typically mean our actual test suites don't start until 2+ minutes for every matrix build.

@ErisDS would like to get your thoughts on this. It was a brief detour whilst I was banging my head against an ember issue but I should have some time on Sunday to take another look at it and get it working

May I ask, what is the advantage of faster travis builds? I'm all for speeding up builds as they take a rather long time even when run locally, but I'm not sure if adding complexity to the travis builds is a very good idea.

@jgillich The complexity added to the travis setup is minimal and the separation of client and server tests will need to be done at some point anyway as we eventually want to use something like SauceLabs so that we can test the client against multiple browser environments. Faster/more focused tests on travis also have the benefit or highlighting random failures faster and when we have multiple PRs being submitted/re-tested (quite typical when leading up to a release) the queue doesn't get quite so backed up.

I feel bad for having taken a few days to respond to this because all I have to say is :tada: :balloon: :cookie: when can I merge it? :stuck_out_tongue:

Linting moved out to its own job, client/lint jobs now run on 0.10, and squashed. Should be ready to go unless there are some other quick-wins to be made?

:tada: :confetti_ball: :balloon: this one I am excited about :grin:


Process fail install step

Hi been getting error on install and run step. It worked fine until this week. I attempted to update submodule to latest version too for a fix but seems same issue.
Anyone have similar issue at this step in past week? Seems logs limited
https://github.com/trustswiftly/trustswiftly.github.io/runs/2071444777?check_suite_focus=true#step:7:35

Got the same problem. I tried to change the ubuntu-latest, ubuntu-20.04, ubuntu-18.04. But all fail. Have no idea what to do. @artxia Could you please suggest anything?
Run cd ${GITHUB_WORKSPACE}/loconotion
Collecting beautifulsoup4==4.9.1
  Downloading beautifulsoup4-4.9.1-py3-none-any.whl (115 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 115.1/115.1 kB 6.5 MB/s eta 0:00:00
Collecting certifi==2<IP_ADDRESS>
  Downloading certifi-2<IP_ADDRESS>-py2.py3-none-any.whl (157 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 157.0/157.0 kB 21.9 MB/s eta 0:00:00
Collecting chardet==3.0.4
  Downloading chardet-3.0.4-py2.py3-none-any.whl ([13](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:14)3 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 133.4/133.4 kB 46.8 MB/s eta 0:00:00
Collecting chromedriver-autoinstaller==0.2.0
  Downloading chromedriver_autoinstaller-0.2.0-py3-none-any.whl (5.8 kB)
Collecting colorama==0.4.3
  Downloading colorama-0.4.3-py2.py3-none-any.whl (15 kB)
Collecting cssutils==1.0.2
  Downloading cssutils-1.0.2-py3-none-any.whl (406 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 406.3/406.3 kB 49.6 MB/s eta 0:00:00
Collecting html5lib==1.1
  Downloading html5lib-1.1-py2.py3-none-any.whl (112 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 112.2/112.2 kB 13.1 MB/s eta 0:00:00
Collecting idna==2.9
  Downloading idna-2.9-py2.py3-none-any.whl (58 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 58.4/58.4 kB 19.0 MB/s eta 0:00:00
Collecting requests==2.23.0
  Downloading requests-2.23.0-py2.py3-none-any.whl (58 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 58.4/58.4 kB 21.7 MB/s eta 0:00:00
Collecting selenium==3.[14](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:15)1.0
  Downloading selenium-3.141.0-py2.py3-none-any.whl (904 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 904.6/904.6 kB 82.4 MB/s eta 0:00:00
Collecting six==1.[16](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:17).0
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting soupsieve==1.9.6
  Downloading soupsieve-1.9.6-py2.py3-none-any.whl (33 kB)
Collecting toml==0.10.1
  Downloading toml-0.10.1-py2.py3-none-any.whl ([19](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:20) kB)
Collecting urllib3==1.25.9
  Downloading urllib3-1.25.9-py2.py3-none-any.whl (126 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 126.7/126.7 kB 46.9 MB/s eta 0:00:00
Collecting webencodings==0.5.1
  Downloading webencodings-0.5.1-py2.py3-none-any.whl (11 kB)
Installing collected packages: webencodings, toml, soupsieve, cssutils, chardet, certifi, urllib3, six, idna, colorama, chromedriver-autoinstaller, beautifulsoup4, selenium, requests, html5lib
Successfully installed beautifulsoup4-4.9.1 certifi-[20](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:21)<IP_ADDRESS> chardet-3.0.4 chromedriver-autoinstaller-0.2.0 colorama-0.4.3 cssutils-1.0.2 html5lib-1.1 idna-2.9 requests-2.23.0 selenium-3.141.0 six-1.16.0 soupsieve-1.9.6 toml-0.10.1 urllib3-1.25.9 webencodings-0.5.1

Notice:  A new release of pip available: [22](https://github.com/RizhaoCai/RizhaoCai.github.io/runs/7623963314?check_suite_focus=true#step:6:23).2 -> 22.2.1
Notice:  To update, run: pip install --upgrade pip
Error: Process completed with exit code 1.


Error when hidden field is updated by server

I'm getting an error when updating a second field in a nested form:
session
# This works
|> fill_in("First Name", with: "Some")
# This fails:
|> fill_in("Last Name", with: "Contact")

** (ArgumentError) value for hidden "form[involved][0][_touched]" must be one of ["_form_type,_persistent_id,_touched,contact,involved_how"], got: "_form_type,_touched,contact"
code: |> fill_in("Last Name", with: "Contact")
     stacktrace:
       (phoenix_live_view 0.20.17) lib/phoenix_live_view/test/live_view_test.ex:1102: Phoenix.LiveViewTest.call/2
       (phoenix_test 0.3.1) lib/phoenix_test/live.ex:172: PhoenixTest.Live.fill_form/4
       test/features/enquiry_test.exs:32: (test)

I've been unable to replicate this with a test unfortunately. I'll have another crack later this week hopefully

I've reproduced the issue here: https://github.com/totaltrash/phoenix_test_playground.
The issue isn't about nested forms, it's about hidden fields that are updated during a phx-change event. The pertinent bits are:
https://github.com/totaltrash/phoenix_test_playground/blob/master/test/my_app_web/features/smoke_test.exs
  test "admin can create user", %{conn: conn} do
    conn
    |> visit("/users/new")
    |> fill_in("Name", with: "Aragorn") # <- this works fine
    |> fill_in("Email", with<EMAIL_ADDRESS># <- this fails
    |> click_button("Save")
    |> assert_has("table", text: "Aragorn")
  end

The second form change fails with:
** (ArgumentError) value for hidden "user[secret]" must be one of ["z"], got: ""
code: |> fill_in("Email", with<EMAIL_ADDRESS>     stacktrace:
       (phoenix_live_view 1.0.0-rc.6) lib/phoenix_live_view/test/live_view_test.ex:1102: Phoenix.LiveViewTest.call/2
       (phoenix_test 0.3.1) lib/phoenix_test/live.ex:121: PhoenixTest.Live.fill_form/4
       test/my_app_web/features/smoke_test.exs:8: (test)

Which appears to be LiveViewTest complaining about changing the value of a hidden as if it was a normal text field (not through the hidden_fields in render_change)
The hidden field is changed here:
https://github.com/totaltrash/phoenix_test_playground/blob/38ca2a4a0825cf2eb655b8194760c5319eff3de7/lib/my_app_web/live/user_live/form_component.ex#L45
I think PhoenixTest is building the form data correctly the first form change (passing the hidden field to render_change), but on the second fill_in, it's just adding the hidden field to the rest of the params

@totaltrash I'm not sure I understand the problem enough to reproduce it. I see in the playground you shared (thanks for sharing that by the way!) that the form has a hidden "Secret" field with that you seem to update in the validate handle event.
But I don't really get what you're trying to accomplish or how to reproduce this. Any more info you can provide?

Yeah hopefully!
So, I noticed the issue originally with a nested form that was built using AshPhoenix.Form. AshPhoenix.Form implements Phoenix.HTML.FormData and adds a couple of fields to the form that are rendered by inputs_for as hidden fields. One of these fields are used to track which nested forms have been updated during the lifecycle of the form (_touched). As I was filling in the form with phoenix_test, an argument error would occur (which appears to be an error Phoenix.LiveViewTest raises when you attempt to set a value on a hidden field in a test).
The playground I shared reproduces the error without the AshPhoenix dependency. Basically, any change to a hidden field on phx-change fails - but only on the second attempt at filling in a field (the first attempt works fine because the hidden field has not yet been changed).
Note, the test in the playground doesn't itself try to update a hidden field, the change is happening on the server.

@totaltrash sorry for the delay here. Thanks so much for the phoenix playground! I see now where we're having issues... but now I have to figure out how to solve it. Just wanted to let you know I'm looking into it.


Aws api gateway android get specific data from web based

Hi, so far I followed your API-gateway petstore demo is working fine because it is open API and able to show data on my android phone.
However, If I have a website which allows the user to log in and check the sales record based on the ID. What is the guideline to configure the API-gateway? Should I use the private API?

If your API is used to serve users from Internet, you still need public API Gateway.
You can use API Gateway Lambda Authorizers to adopt to your logged users.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
If you integrate Cognito as authentication method, you can also use IAM authentication.
https://aws.amazon.com/premiumsupport/knowledge-center/iam-authentication-api-gateway/


fixed issues with dexgaurd

Dexguard does not recognize subclasses unless they have a '$' in between the class and the subclasses.

Thanks for your pull request. Added using of $ as a delimiter for inner classes (https://github.com/idamobile/dagger-proguard-helper/commit/02b5e53508ac25b2086bf518533e6b0ad2fc41b2)


Language breadcrumbs never show up for the file that's persisted open

Open something.ts
Reload the window
something.ts is persisted open
See that the breadcrumbs for methods, classes, etc don't show up, we only get breadcrumbs for files and folders
Close something.ts, reopen
Now the language breadcrumbs appear.

Works for my dummy language, must be TypeScript having a problem to recompute this...


Update _index.md

fixed some grammar issue
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

How are users affected by this change:
Is this breaking change:
How to migrate (if breaking change):

@clubanderson
Thank you for your great contribution!
Would you please sign off and pass the DCO check?
cf. https://github.com/pipe-cd/pipecd/pull/4893/checks?check_run_id=24111264579

I signed the PR and updated all versions. I do not know what else is blocking this PR now. Please advise

@clubanderson
Thank you for signing and coping your changes!!
This PR will be merged after another reviewer approves.
You do not need to do something else:)


Dirty page checking and snapshot diffs

The aim of this PR is:

Return diffs from the workers back to the master after executing a batch of threads. This means tracking dirty pages on worker hosts when executing a batch of threads, then returning the resulting memory diff back to the master when finished.
Push diffs from the master host to workers when executing subsequent batches of threads (i.e. push the whole snapshot to the host when executing the first batch, then only push diffs after that). This means tracking dirty pages on the master between executing batches of threads.

Changes:

Add pushing diffs between hosts. This is either pushing diffs on their own (master -> worker), or pushing diffs along with a thread result (worker -> master). See notes below on this.
Add dirty page checking based on soft-dirty PTEs.
Add snapshot() method to executor subclasses so that Faabric can request a pointer to their memory (which it then uses to work out dirty pages).
Convert both snapshot push operations (full and diffs) to await a response synchronous, as the master host needs to know the snapshot data has been pushed and set up before sending function messages.
Add test fixtures where possible to reduce verbosity of tests.
Made logger an instance variable where possible to avoid calling getLogger all over the place.

Because the diffs from child threads have to be applied before other threads can continue, we have to make sure that they are applied before the thread result is returned (as the thread result is the thing that other threads wait on). Therefore we have to piggyback the diffs on the existing thread result message.
I've ported the thread result message to use flatbuffers which is where all the other snapshot stuff lives. For now I've put it in with the existing SnapshotClient and SnapshotServer in an attempt to minimise the number of changes in this PR, but eventually we'll need to commit to either protobuf or flatbuffers. Flatbuffers seem potentially more efficient, but the awkwardness of passing them around and accessing the data within is a major downside.

Left some comments, overall LGTM, and the dirty page tracking looks great and neat. I know you started this before we agreed on the new PR+commit structure, but for the future, 15 hundred lines added with four commits is very hard to review in a per-commit fashion (which btw you can do using n and p in the browser).

Yes let's not be too strict on this one, I think we can aim for the n/p reviewing in an ideal world but not worry too much if we don't achieve it every time. In this case it was a choice between 50 commits with things like "fixing tests" repeated over and over and one big one, neither of which is useful. I could potentially have rebased into something slightly more meaningful, but I think you have to start the work in that mindset for it to really work.

Wrt the PR size/topics I feel that all the fixture changes had really nothing to do with dirty page checking, so this could definately be in a different PR.

Yes, again in an ideal world, but let's not let great be the enemy of the good. "nothing to do" is a little strong, it avoided repeating code in the new tests I was writing.


Multiple colour themes

We could provide an option which sets the primary colour. It's currently blue, but we should be able to add green, orange etc.
The user can then specify the colour theme via html_theme_options.
html_theme_options = {
    "theme_color": "orange"
}

# Or let them specify an arbitrary colour primary colour
html_theme_options = {
    "theme_color": "#abc123"
}

This value will then be assigned to a CSS variable.

Any chance on this being implemented? I'm trying to change the banner and highlight text to another color. If not implemented, would you be able to let me know if I could alter than in a customs.css file? I've tried a few approaches but have come up empty handed (sorry I don't have lots of CSS or HTML experience so if you could provide an example would be greatly appreciated!)

I worked out how to do it with a .css file - turned out that once I provided the html_static_path in the conf.py, it wasn't needed in the html_css_files so when trying to add the custom variables, it was calling a file from the wrong directory

@drneavin Glad you got it sorted. Will try and get this issue resolved soon.

Hi, I've tried your recommendation in conf.py but it doesn't work:
html_theme_options = {
"theme_color": "#abc123"
}

How can I modify the style sheet from:
docs/_build/static/css/my_theme_piccolo.css
In conf.py I've already put:
html_static_path = ['_static']
html_style = 'css/my_theme_piccolo.css'

Content of my_theme_piccolo.css:
@import url("basic_mod.css");
/* Typography */
:root {
--mainNavColor: #2471a3;
--notificationBannerColor: #176bb0;
}

But it doesn't work. Please help?
Thanks.


Implement DecodingLayer interface for SCTP

Now can use SCTP layer in NewDecodingLayerParser like TCP, UDP

I signed it!

Hi. Thanks for your contribution. Looks like you added a test for payload length less than 12. Is it a normal case ? If so, please add a unit test. If not, please trigger an error.
Laurent

Hi. Can you clarify line number: 71 or 80?

To be honest, I didn't spot the line 71... which is great. In fact, line 80 is useless. Please just do the safety check first and next consider you are above 12.

You are right. I removed this verificaction


Proper handling of curved camera geometries

The information we need is in the SimTelFiles:
It contains pixel x, y, z and x and y of the normal vector on the pixel.
In the comment it says that the vector should be (x, y, 1).
What is the angle to the z direction of the pixels of the CHEC camera @watsonjj ?
Just to verify.
I got 7.7° 4.62°, 1.5° for the different pixel groups, is that correct?

s = SimTelFile('chec.simtel.gz')
camera_settings = s.telescope_descriptions[1]['camera_settings']

x = camera_settings['pixel_x']
y = camera_settings['pixel_y']
z = camera_settings['pixel_z']

# normal vector components
nx = camera_settings['nxpix']
ny = camera_settings['nypix']
nz = np.ones_like(nx)

The chec.simtel.gz is the file @watsonjj has provided here #963

@dneise maybe we should give better names to those nxpix and nypix in eventio

Looks sort of correct. The pixels should be orientated with each of the modules*, where the module positions can be found at start of the camera configuration file for chec. How do you only get 3 distinct pixel groups for the z angle? I get a range between 2 and 9 degrees.
*on a side note, is the corresponding module number for each pixel saved in camera_settings?

This is what I did:
from eventio import SimTelFile
import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D
import numpy as np

s = SimTelFile('chec.simtel.gz')
camera_settings = s.telescope_descriptions[1]['camera_settings']

x = camera_settings['pixel_x']
y = camera_settings['pixel_y']
z = camera_settings['pixel_z']

# normal vector components
nx = camera_settings['nxpix']
ny = camera_settings['nypix']
nz = np.ones_like(nx)

n = np.column_stack([nx, ny])

print(*np.unique(np.round(np.rad2deg(np.arctan(n)), 1), axis=0), sep='\n')

fig = plt.figure()
ax = fig.add_subplot(1, 1, 1)

ax.quiver(x, y, nx, ny)
ax.set_aspect(1)

fig.savefig('chec.png', dpi=300)
plt.show()

The simtel files contains something called pixel drawers, maybe that's it?

Can this issue be closed? @MaxNoe

No, we have no handling of curved geometries / the definite answer we don't need it

I emailed with Konrad again, and he said we should like we do now just look at the xy projection. However that results in ugly camera displays, since there we don't actually do the projection but draw a regular square at each center position.
This also might create problems for the muon calibration or any other algorithm where you need to calculate a signal acceptance for each pixel.
So input from the two mirror telescope teams here would be very welcome, I cannot yet wrap my head around how best to implement this.
How do we need to transform a pixel with (x, y, n_x, n_y) where n_x and n_y are x and y components of the normal vector of the pixel to a position in the field of view (TelescopeFrame)


Added yellow color for OpenEPaperLink Firmware 2.6

Support yellow with new 2.60b OpenEPaperLink firmware

Done


Initial implementation of the Bevy Remote Protocol (Adopted)

Objective
Adopted from #13563.
The goal is to implement the Bevy Remote Protocol over HTTP/JSON, allowing the ECS to be interacted with remotely.
Solution
At a high level, there are really two separate things that have been undertaken here:

First, RemotePlugin has been created, which has the effect of embedding a JSON-RPC endpoint into a Bevy application.
Second, the Bevy Remote Protocol verbs (excluding POLL) have been implemented as remote methods for that JSON-RPC endpoint under a Bevy-exclusive namespace (e.g. bevy/get, bevy/list, etc.).

To avoid some repetition, here is the crate-level documentation, which explains the request/response structure, built-in-methods, and custom method configuration:

Click to view crate-level docs
//! An implementation of the Bevy Remote Protocol over HTTP and JSON, to allow
//! for remote control of a Bevy app.
//!
//! Adding the [`RemotePlugin`] to your [`App`] causes Bevy to accept
//! connections over HTTP (by default, on port 15702) while your app is running.
//! These *remote clients* can inspect and alter the state of the
//! entity-component system. Clients are expected to `POST` JSON requests to the
//! root URL; see the `client` example for a trivial example of use.
//!
//! The Bevy Remote Protocol is based on the JSON-RPC 2.0 protocol.
//!
//! ## Request objects
//!
//! A typical client request might look like this:
//!
//! ```json
//! {
//!     "method": "bevy/get",
//!     "id": 0,
//!     "params": {
//!         "entity":<PHONE_NUMBER>,
//!         "components": [
//!             "bevy_transform::components::transform::Transform"
//!         ]
//!     }
//! }
//! ```
//!
//! The `id` and `method` fields are required. The `param` field may be omitted
//! for certain methods:
//!
//! * `id` is arbitrary JSON data. The server completely ignores its contents,
//!   and the client may use it for any purpose. It will be copied via
//!   serialization and deserialization (so object property order, etc. can't be
//!   relied upon to be identical) and sent back to the client as part of the
//!   response.
//!
//! * `method` is a string that specifies one of the possible [`BrpRequest`]
//!   variants: `bevy/query`, `bevy/get`, `bevy/insert`, etc. It's case-sensitive.
//!
//! * `params` is parameter data specific to the request.
//!
//! For more information, see the documentation for [`BrpRequest`].
//! [`BrpRequest`] is serialized to JSON via `serde`, so [the `serde`
//! documentation] may be useful to clarify the correspondence between the Rust
//! structure and the JSON format.
//!
//! ## Response objects
//!
//! A response from the server to the client might look like this:
//!
//! ```json
//! {
//!     "jsonrpc": "2.0",
//!     "id": 0,
//!     "result": {
//!         "bevy_transform::components::transform::Transform": {
//!             "rotation": { "x": 0.0, "y": 0.0, "z": 0.0, "w": 1.0 },
//!             "scale": { "x": 1.0, "y": 1.0, "z": 1.0 },
//!             "translation": { "x": 0.0, "y": 0.5, "z": 0.0 }
//!         }
//!     }
//! }
//! ```
//!
//! The `id` field will always be present. The `result` field will be present if the
//! request was successful. Otherwise, an `error` field will replace it.
//!
//! * `id` is the arbitrary JSON data that was sent as part of the request. It
//!   will be identical to the `id` data sent during the request, modulo
//!   serialization and deserialization. If there's an error reading the `id` field,
//!   it will be `null`.
//!
//! * `result` will be present if the request succeeded and will contain the response
//!   specific to the request.
//!
//! * `error` will be present if the request failed and will contain an error object
//!   with more information about the cause of failure.
//!
//! ## Error objects
//!
//! An error object might look like this:
//!
//! ```json
//! {
//!     "code": -32602,
//!     "message": "Missing \"entity\" field"
//! }
//! ```
//!
//! The `code` and `message` fields will always be present. There may also be a `data` field.
//!
//! * `code` is an integer representing the kind of an error that happened. Error codes documented
//!   in the [`error_codes`] module.
//!
//! * `message` is a short, one-sentence human-readable description of the error.
//!
//! * `data` is an optional field of arbitrary type containing additional information about the error.
//!
//! ## Built-in methods
//!
//! The Bevy Remote Protocol includes a number of built-in methods for accessing and modifying data
//! in the ECS. Each of these methods uses the `bevy/` prefix, which is a namespace reserved for
//! BRP built-in methods.
//!
//! ### bevy/get
//!
//! Retrieve the values of one or more components from an entity.
//!
//! `params`:
//! - `entity`: The ID of the entity whose components will be fetched.
//! - `components`: An array of fully-qualified type names of components to fetch.
//!
//! `result`: A map associating each type name to its value on the requested entity.
//!
//! ### bevy/query
//!
//! Perform a query over components in the ECS, returning all matching entities and their associated
//! component values.
//!
//! All of the arrays that comprise this request are optional, and when they are not provided, they
//! will be treated as if they were empty.
//!
//! `params`:
//! `params`:
//! - `data`:
//!   - `components` (optional): An array of fully-qualified type names of components to fetch.
//!   - `option` (optional): An array of fully-qualified type names of components to fetch optionally.
//!   - `has` (optional): An array of fully-qualified type names of components whose presence will be
//!      reported as boolean values.
//! - `filter` (optional):
//!   - `with` (optional): An array of fully-qualified type names of components that must be present
//!     on entities in order for them to be included in results.
//!   - `without` (optional): An array of fully-qualified type names of components that must *not* be
//!     present on entities in order for them to be included in results.
//!
//! `result`: An array, each of which is an object containing:
//! - `entity`: The ID of a query-matching entity.
//! - `components`: A map associating each type name from `components`/`option` to its value on the matching
//!   entity if the component is present.
//! - `has`: A map associating each type name from `has` to a boolean value indicating whether or not the
//!   entity has that component. If `has` was empty or omitted, this key will be omitted in the response.
//!
//! ### bevy/spawn
//!
//! Create a new entity with the provided components and return the resulting entity ID.
//!
//! `params`:
//! - `components`: A map associating each component's fully-qualified type name with its value.
//!
//! `result`:
//! - `entity`: The ID of the newly spawned entity.
//!
//! ### bevy/destroy
//!
//! Despawn the entity with the given ID.
//!
//! `params`:
//! - `entity`: The ID of the entity to be despawned.
//!
//! `result`: null.
//!
//! ### bevy/remove
//!
//! Delete one or more components from an entity.
//!
//! `params`:
//! - `entity`: The ID of the entity whose components should be removed.
//! - `components`: An array of fully-qualified type names of components to be removed.
//!
//! `result`: null.
//!
//! ### bevy/insert
//!
//! Insert one or more components into an entity.
//!
//! `params`:
//! - `entity`: The ID of the entity to insert components into.
//! - `components`: A map associating each component's fully-qualified type name with its value.
//!
//! `result`: null.
//!
//! ### bevy/reparent
//!
//! Assign a new parent to one or more entities.
//!
//! `params`:
//! - `entities`: An array of entity IDs of entities that will be made children of the `parent`.
//! - `parent` (optional): The entity ID of the parent to which the child entities will be assigned.
//!   If excluded, the given entities will be removed from their parents.
//!
//! `result`: null.
//!
//! ### bevy/list
//!
//! List all registered components or all components present on an entity.
//!
//! When `params` is not provided, this lists all registered components. If `params` is provided,
//! this lists only those components present on the provided entity.
//!
//! `params` (optional):
//! - `entity`: The ID of the entity whose components will be listed.
//!
//! `result`: An array of fully-qualified type names of components.
//!
//! ## Custom methods
//!
//! In addition to the provided methods, the Bevy Remote Protocol can be extended to include custom
//! methods. This is primarily done during the initialization of [`RemotePlugin`], although the
//! methods may also be extended at runtime using the [`RemoteMethods`] resource.
//!
//! ### Example
//! ```ignore
//! fn main() {
//!     App::new()
//!         .add_plugins(DefaultPlugins)
//!         .add_plugins(
//!             // `default` adds all of the built-in methods, while `with_method` extends them
//!             RemotePlugin::default()
//!                 .with_method("super_user/cool_method".to_owned(), path::to::my::cool::handler)
//!                 // ... more methods can be added by chaining `with_method`
//!         )
//!         .add_systems(
//!             // ... standard application setup
//!         )
//!         .run();
//! }
//! ```
//!
//! The handler is expected to be a system-convertible function which takes optional JSON parameters
//! as input and returns a [`BrpResult`]. This means that it should have a type signature which looks
//! something like this:
//! ```
//! # use serde_json::Value;
//! # use bevy_ecs::prelude::{In, World};
//! # use bevy_remote::BrpResult;
//! fn handler(In(params): In<Option<Value>>, world: &mut World) -> BrpResult {
//!     todo!()
//! }
//! ```
//!
//! Arbitrary system parameters can be used in conjunction with the optional `Value` input. The
//! handler system will always run with exclusive `World` access.
//!
//! [the `serde` documentation]: https://serde.rs/

Message lifecycle
At a high level, the lifecycle of client-server interactions is something like this:

The client sends one or more BrpRequests. The deserialized version of that is just the Rust representation of a JSON-RPC request, and it looks like this:

pub struct BrpRequest {
    /// The action to be performed. Parsing is deferred for the sake of error reporting.
    pub method: Option<Value>,

    /// Arbitrary data that will be returned verbatim to the client as part of
    /// the response.
    pub id: Option<Value>,

    /// The parameters, specific to each method.
    ///
    /// These are passed as the first argument to the method handler.
    /// Sometimes params can be omitted.
    pub params: Option<Value>,
}

These requests are accumulated in a mailbox resource (small lie but close enough).
Each update, the mailbox is drained by a system process_remote_requests, where each request is processed according to its method, which has an associated handler. Each handler is a Bevy system that runs with exclusive world access and returns a result; e.g.:

pub fn process_remote_get_request(In(params): In<Option<Value>>, world: &World) -> BrpResult { // ... }

The result (or an error) is reported back to the client.

Testing
This can be tested by using the server and client examples. The client example is not particularly exhaustive at the moment (it only creates barebones bevy/query requests) but is still informative. Other queries can be made using curl with the server example running.
For example, to make a bevy/list request and list all registered components:
curl -X POST -d '{ "jsonrpc": "2.0", "id": 1, "method": "bevy/list" }' <IP_ADDRESS>:15702 | jq .

Future direction
There were a couple comments on BRP versioning while this was in draft. I agree that BRP versioning is a good idea, but I think that it requires some consensus on a couple fronts:

First of all, what does the version actually mean? Is it a version for the protocol itself or for the bevy/* methods implemented using it? Both?
Where does the version actually live? The most natural place is just where we have "jsonrpc" right now (at least if it's versioning the protocol itself), but this means we're not actually conforming to JSON-RPC any more (so, for example, any client library used to construct JSON-RPC requests would stop working). I'm not really against that, but it's at least a real decision.
What do we actually do when we encounter mismatched versions? Adding handling for this would be actual scope creep instead of just a little add-on in my opinion.

Another thing that would be nice is making the internal structure of the implementation less JSON-specific. Right now, for example, component values that will appear in server responses are quite eagerly converted to JSON Values, which prevents disentangling the handler logic from the communication medium, but it can probably be done in principle and I imagine it would enable more code reuse (e.g. for custom method handlers) in addition to making the internals more readily usable for other formats.

One small thing, I think we want to add protocol versioning. In my opinion, we should start at 1.0.0 and follow semver for all verbs, networking types, and server handlers, just like it was a public rust API. The client should include the protocol version on every request.

i agree protocol versioning is important, but i'm not sure that we should start at 1.0 considering Bevy is not yet 1.0, so i think 0.1.0 is probably a better initial version.

BRP is mostly intended for editor, can we keep this as "experimental" and start versioning when the editor integrates it?
There will be more changes coming and there isn't even a consumer

can we keep this as "experimental"

yeah thats fine

I basically made it so that bevy_remote is neutered entirely on wasm targets to satisfy CI. Maybe we should investigate a relaxation of the CI requirement that the entire workspace compile on web assembly at some point (by way of contrast, the dependencies of bevy_remote don't just do nothing on wasm, they don't compile at all).

I'm okay with this being neutered on web for now. @mweatherley, are you happy with the state of this now?

I'm okay with this being neutered on web for now. @mweatherley, are you happy with the state of this now?

Yeah, I'm fine with it, I think :) I guess what I would say is that I don't personally have any blocking concerns about the state it's in right now, but I think various things (e.g. documentation) could be definitely improved.

All right, in light of @torsteingrindvik's comments, I lightly restructured BrpRequest so that it doesn't need to parse parameters lazily any more. This means it can be used more easily to structure input for clients, which I have demonstrated in the client example (which doesn't need raw JSON any more). The rough edges are still there, though; if we want to support this kind of thing more thoroughly, we should actually add useful constructors for these types. Obviously, I consider that out of scope for the present PR. :)

Of course, wasm build failure... Ping me when you want me to retry!

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to https://github.com/bevyengine/bevy-website/issues/1696 if you'd like to help out.