Dragging only moves handle, leaves dialog behind

I'm submitting a...

[x] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior
When trying to drag the drag handle ("marker") of a dialog, only the handle itself moves.
Expected behavior
The whole dialog moves as it did before
Minimal reproduction of the problem with instructions

clone this repo (the playground)
npm ci && npm run start
create a dialog with draggable: true
(optional) apply custom style to the drag handle to make it easier to see
try to drag the dialog

alternatively, the same behaviour is reproducible over on https://ngneat.github.io/dialog/
you can use your browser's css inspector to add something like this to make the issue more visible:
.ngneat-drag-marker {
    background: red;
}

Environment

Angular version: 15.0.0, 15.0.4 (almost latest)

Browser:
- [x] Chrome (desktop) version 108
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 108
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [x] Edge version 108

Others:
* I noticed the regression in a local project after upgrading from 2.1.1 to 3.3.0
* I was able to reproduce it in the latest playground (1d5509210d124d65c1cf15c7ee84951dfe1cde2c) aswell as 3.0.0 (028bccadd8275ef8966ff0921894c9fd32a12e9a)
* it's weird how the latest release commit on github is 3.1.0, but npm has 3.3.0 already. I didn't look into that any further and hope my version info is correct

I see. I'll check when I find some free time. It'll be great if you can help and at least check in which commit it was broken.

sure! I had some trouble getting the older versions to build at first, but I got it in the end.
looks like it's f5575f59da2fb61b9c0aa229e8890eaf32a2a56c, because it's broken there while 5a1fd12c66a3e817b879eaf4afb6952d71102b71 is still fine

alternatively, the same behaviour is reproducible over on https://ngneat.github.io/dialog/

Was the demo website ever updated with the fix? I am still seeing the faulty behaviour there. Not the best impression if you're looking for a draggable dialog and coming here checking the demo first.


Port P-OS to PSoC 4 BLE

Done.
PSoC's needs also HW programming code (VHDL) and our build system does not support that for now.
Therefore, a PSoC Creator Project is created for PSoC 4 BLE porting and required Drivers are implemented.
Just run PSoC Creator project under, Projects\hello_world\PSoCCreator\P-OS

Some examples : https://www.hackster.io/cypress/products/psoc-ble-pioneer-kit


[WIP] Validate examples

Related Issue(s): #632
Proposed Changes:

Add a validation script that validates all examples in the repository.
Fix up examples that did not pass validation.

Work in progress for the moment. I will cherry-pick changes on top of dev after #640 is merged.
PR Checklist:

[x] This PR has no breaking changes.
[ ] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[ ] API only: I have run npm run generate-all to update the generated OpenAPI files.

Talked with @jbants , sounds like this needs some more work so won't be ready for 0.9.0 release, moving to 1.0

Sounds good; I should have some time in the next couple of weeks to update and clean this up.

What's the state of this? Possible to get done for 1.0-beta1?

Closing in favor of #834


Unnecessary permits Azure

Perform tests only using the automation API. I think it could work only with that permission. If so, update all the documentation.

Need two:)


Avatar is static and has no movement in space. (Azure Kinect body tracking in unity sample file)

Describe the bug

The Avatar or the character in unity is mimicking the point body in terms of joint movement, but is stuck in a single place and is unable to move in space. Even though the point body is able to move in space (inside unity) according to the user's movement in front of the kinect (in real world), the avatar/character is not able to move and is stuck in one place.
I followed @anantley 's tutorial (Mr. Angus Antley) to recreate this.
I want to achieve something like this. Notice how the Avatar and the Point body both move according to the user's movement.

Is it a problem with the unity version. I am currently using Unity Editor version 2021.13f


Flexible LSR convergence criterion, residual calculation and residual diagnostic

What changes does this PR introduce?
(Bug fix, feature, docs update, ...)
I tried to improve the convergence of the sea ice LSR solver by changing the LSR convergence conditions. This is intended for studies that rely on a good level of numerical convergence, probably not for high-resolution pan-arctic or global climate simulations.
What is the current behavior?
(You can also link to an open issue here)
With the current behavior:

The SEAICEnonLinTol parameter has no influence on the solver iterations.
The LSR solver stops when the solution of the linearized system is not converging anymore, but it might not be a good solution for the non-linear system.
The convergence of the linearized system is fixed and does not depend on the initial state of the solver.
There is no output for the spatial field of residual
the global LSR residual is scaled by the square root of the domain size globalArea.

What is the new behavior
(if this is a feature change)?

The outer-loop non-linear solver will stop once the SEAICEnonLinTol runtime parameter is reached
The LSR convergence criterion is based on the computation of the residuals
The LSR convergence criterion is computed from the initial residual to avoid taking a lot of time to converge to a solution far from the solution of the non-linear system during the first outer loops. I implemented several methods to compute the criterion and Ieft the one that I found to work the best uncommented.
There is now a 2D residual field SIlsrRe diagnostic to study where the residuals are high and low in the simulation.
The global LSR residual is scaled by the number of grid cells (Nx*Ny) to reflect numerical convergence per grid cell better.

Does this PR introduce a breaking change?
(What changes might users need to make in their application due to this PR?)
Normally not. If the LSRFLEX flag is not defined, the model's behavior should be the same (also need to set SEAICEnonLinTol low enough so it is typically reached). But it will change the LSR output to STDOUT files because the global residual is computed differently.
Other information:
I am not sure if we want this implemented in the main branch of MITgcm or if this is the most efficient implementation. Because I took a new position, I won't be able to work on this much, but I thought, maybe, it would be useful to someone.
I studied this because I found that the LSR_ERROR runtime parameter (the LSR convergence criterion) is unreliable in improving the convergence. See the graph below:

The top is the cell-averaged residual, and the bottom is the total number of x and y LSR iterations needed to reach LSR_ERROR. In an idealized experiment, I decreased the LSR_ERROR parameter from the default value of 1e-5 to 1e-6, 1e-7, and 1e-8, and in the first three cases, the numerical convergence did not improve. Only at 1e-8, we start to see a real difference
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)

Thanks @dringeis I'll take a look.

Thanks for this useful contribution. Some changes are required to make the code work with TAF (see detailed comments). @dringeis If you want to, I can make these changes.

yes please do all the changes that you see as necessary.

@dringeis
Please have a look at my changes. Additionally, we could improve the I/O of seaice_lsr in general (use print_message instead of writing directly to standardMessageUnit). I tried the code with seaice_obcs, and this changes the results (as expected), but I cannot tell if for better or for worse (differences are < 10%). Clearly the convergence of the LSR solver is dramatically improved (when I use SEAICEnonLinIterMax = 100 or larger), but I cannot control the convergence of the linear iteration. Will that become a problem in MPI-parallel configurations, where we know that we need a sufficiently small LSR_ERROR <= 1e-5?
About the nonlinear convergence criterion: in the JFNK and KRYLOV solvers we use relative reduction, here it is now an absolute criterion. For consistency this should be changed, shouldn't it?

I suggest to test this code in seaice_obcs. Oviously, the results will change.
@dringeis please see if you can live with my most recent changes.
Also I would like to wait with this PR until PR #734 has been merged.

@dringeis  and @mjlosch  I have few comments:

I tend to prefer the way the SEAICE_LSR was reporting convergence directly to STDOUT, without the PRINT_MESSAGE (I think I ended up tweaking a bit these print back in 2011, when S/R SEAICE_RESIDUAL was introduced). And the main reason is that, since several info are printed on 1 line, adding the 20.c usual prefix results in a long line that I found harder to follow.
The new diagnostics "SIlsrRe " can be confusing, since it does not have a "well defined" location: not at grid-cell center, not at western edge (U-location) and not at southern edge (V-location). Is there a way to refine how it's computed so that, at the end, its location is defined ?
currently, there is no run-time switch to use (or not) the LSR-Flex method. If it's not too difficult to add one, it would be interesting to have it, I think.
I am not sure I understand the new way to "scale" the residual: rAw and rAs enter the residU and residV sum but the globalArea scaling is gone. This makes me think that I will get very different results at 100.km resolution or 10.m resolution with same number of grid points ?

@jm-c thanks for looking at this

I tend to prefer the way the SEAICE_LSR was reporting convergence directly to STDOUT, without the PRINT_MESSAGE (I think I ended up tweaking a bit these print back in 2011, when S/R SEAICE_RESIDUAL was introduced). And the main reason is that, since several info are printed on 1 line, adding the 20.c usual prefix results in a long line that I found harder to follow.

OK, I see your point. We can change this back to print directly to standardMessageUnit

The new diagnostics "SIlsrRe " can be confusing, since it does not have a "well defined" location: not at grid-cell center, not at western edge (U-location) and not at southern edge (V-location). Is there a way to refine how it's computed so that, at the end, its location is defined ?

OK, I can change that so that the squared residuals are averaged to the grid-cell center. I guess, convenience was the guiding principle here. One can argue that you do not want to mix the residuals from different grid cells for diagnostics, but it does make it nebulous where this should be defined.

currently, there is no run-time switch to use (or not) the LSR-Flex method. If it's not too difficult to add one, it would be interesting to have it, I think.

OK, we can do that, too. I didn't think it was necessary. This entails renaming the cpp flag to ALLOW_SEAICE_LSR_FLEX or similar to follow the usual procedure.

I am not sure I understand the new way to "scale" the residual: rAw and rAs enter the residU and residV sum but the globalArea scaling is gone. This makes me think that I will get very different results at 100.km resolution or 10.m resolution with same number of grid points ?

I had the same question, see @dringeis reply in one of the inline comments. I'll "unresolve" that comment.

@mjlosch following up:
Regarding point 1: If we want to keep using PRINT_MESSAGE, then it would be better to split the lines, which means longer STDOUT, and since I noticed some users already tend to use a lower debugLevel to make STDOUT shorter, it would not really improve this aspect. Now I think this change was all in 1 commit so it might be not too difficult to go back (i.e., not using PRINT_MESSAGE).
Regarding point 2: we might need to add an EXCH call for uTmp,vTmp if the result is defined at grid-cell center. The other alternative would be to have 2 diagnostics, one for uRes and one for vRes.
Regarding point 3: a run-time switch would be nice, making this easier to test and check what it's doing. Also would be able to turn this on in 1 secondary test experiment (e.g., one of offline_exf_seaice) and leave the other unchanged.
Regarding point 4: seems that uRes,vRes have same units as rhsU,rhsV, same as FORCEX,FORCEY, i.e., "m/s^2".
So this "new scaling" does look strange to me. May be one could try in a simple set-up (like offline_exf_seaice) to change the horizontal resolution by 1000 (or more) but keep same number of grid-point and see what "residual" we get.

I took a quick look and this looks good. @mjlosch Thanks !
I think the test in offline_exf_seaice.dyn_lsr is good. I have a small preference for not changing global_ocean.cs32x15, but if @mjlosch insist on testing this also there, would be fine too.

@jm-c Thanks.
I can remove the global_ocean.cs32x15 test again, no problem. It was only a suggestion.
I'd ask you to generate reference output for the modified offline_exf_seaice.dyn_lsr experiment.

OK, I am going to revert global_ocean.cs32x15/code/SEAICE_OPTIONS.h (all experiments SEAICE_OPTIONS.h have been updated in PR #734, so no need to change (back ?) this one here) and generate a new ref. output for offline_exf_seaice.

And since we are here, do you remember why we have this IF at the very top of Non-Linear loop, line 281 ?

This is another concession to auto-differentiation, but masked by some changes to the code. Originally we had the runtime parameter NPSEUDOTIMESTEPS and the fixed parameter MPSEUDOTIMESTEPS (set in SEAICE_SIZE.h). MPSEUDOTIMESTEPS determines the length of the tape, and the loop was over ipass =1, MPSEUDOTIMESTEPS, but the if-statement (ipass .LE. NPSEUDOTIMESTEPS) made sure that we do only NPSEUDOTIMESTEPS. Now SEAICEnonLinIterMax replaces NPSEUDOTIMESTEPS as a runtime parameter, but seaice_check.F makes sure that SEAICEnonLinIterMax.LE.MPSEUDOTIMESTEPS, so I think that this is OK. We could put #ifdef ALLOW_AUTODIFF_TAMC around the if-statement, to make this clear. What do you think?

@mjlosch I think I would understand better the need for this condition (line 281 in seaice_lsr.F from this PR branch) if it was:

IF ( ipass.LE.MPSEUDOTIMESTEPS ) THEN

but currently, this test, "IF ( ipass.LE.nonLinIterLoc ) THEN" beeing just at the top of the loop "DO ipass=1,nonLinIterLoc" (line 270) is not doing much, always True. I think it could be safely removed with a comment that we make sure, in seaice_check.F, that nonLinIterLoc is not larger than MPSEUDOTIMESTEPS. Or may be I missed something ?

I guess, you are right. I can push changes that address all of your suggestions/comments. It's a bit awkward, because there are now two IF ( doNonLinLoop ) statements, because the new variable doNonLinLoop which contains the two conditions with the EXIT statements changes after the first IF.

@mjlosch I should have mentioned this earlier (sorry), but could we add a check & stop in seaice_check.F if SEAICEuseLSRflex is True but SEAICE_ALLOW_LSR_FLEX is undefined ? And in the same routine, would it be better to distinguish according to SEAICEusePicardAsPrecon when we check MPSEUDOTIMESTEPS value ?

@mjlosch I should have mentioned this earlier (sorry), but could we add a check & stop in seaice_check.F if SEAICEuseLSRflex is True but SEAICE_ALLOW_LSR_FLEX is undefined ?

Sure!

And in the same routine, would it be better to distinguish according to SEAICEusePicardAsPrecon when we check MPSEUDOTIMESTEPS value ?

Here I am not so sure:

the check SEAICEnonLinIterMax .GT. MPSEUDOTIMESTEP is is done within ALLOW_AUTODIFF_TAMC, so I would expect anyone who tries the AD of seaice_lsr to know what they are doing (because it does not work).
SEAICEusePicardAsPrecon is only used when run a Picard solver (either LSR or KRYLOV) before the JFNK solver that will never work for the AD code (as it is implemented right now).

We could add a check in the ALLOW_AUTODIFF_TAMC block that stops the model when SEAICEusePicardAsPrecon=T, because that will just not work at all (but again, I expect anyone who tries that/is even aware of this runtime flag to know that this is bogus).

@mjlosch OK, I see your point. The only reason we may want to change the MPSEUDOTIMESTEPS check (but keeping it within ALLOW_AUTODIFF_TAMC) would be to be consistent with the new comments in seaice_lsr.F, lines 274-277. But if SEAICEusePicardAsPrecon is not supposed to be used in the adjoint, it's fine as it it now.

@mjlosch I made little adjustments in seaice_lsr.F (please check) but otherwise it's all good.
And  could merge this PR soon after you agree.

@jm-c your changes look good to me. Please merge!


Fix #24470 Atlas Texture with margin setting cause error in editor.

Fix #24470 by:

set pixel_pos = region_pos - margin_pos + pointer_pos.
return false when pointer is outside final texture.

Thanks!


Move Menu information out of Persistence Manager

Tight coupling from the core layer to the presentation layer.

Solution may be to have a lookup of menus for given components.


Bubble & Inline API

Summary of problem or feature requests
Hi,
I suggest Bubble & inline API integration in editor html builder using protected methods/properties
I suggest to insert the snippet below in vendor/view/datatables/editor.blade.php
Code snippet
//
$('#myTable').on( 'click', 'tbody td', function () {
    editor-instance.bubble( this );
} );

...

-->
System details

Operating System linux
PHP Version 7.1.3
Laravel Version 5.6
Laravel-DataTables Version 8.13.7

You can already do this by duplicating editor.blade.php like bubbles.blade.php and insert the snippet above. After that, use it as the template. Add ->setTemplate('datatables::bubbles') on the chain as last method call.

Hello,
@matteocostantini , did you manage to get it works ?
@yajra is it the same mecanism for inline editing (see https://editor.datatables.net/examples/inline-editing/simple.html)
Many thank's

Hi,
@Benoit75 , it works with inline and bubble, perfectly!

Hello,
@matteocostantini could you provide some example ? i used the last version of laravel-datatables-html (as described in https://yajrabox.com/docs/laravel-datatables/master/editor-tutorial) whitch means that i do not know how to add the specific JS code for inline or bubble.
Thank's


DDS Network configuration with USB connection & Orin nano & Notebook

I want to use notebook in addition to Orin nano with create3, to see data in Rviz for example, for that I need data from robot, i.e. /tf, /odom etc..
So far I have working communication between robot <--> Orin, and Orin <-> notebook, but I can't see any topics from robot on notebook.
I think this is very common setup, that could be useful to have for other people, if not with Jetsons, many will try to use USB cable+  RPi + notebook.
I already tried various FastDDS xml profiles, but there are not lot of info out there. In addition, when using FastDDS the robot stops sending data after few hours, or start to have 100% CPU and stops communicating.
With CycloneDDS, the communication is much better, but still I can't see anything robot related with notebook.
I created access point on Orin, to which I connect with notebook.
I had this setup with Turtlebot 2 which worked flawlessly, but it used Serial connection for communication.
Funny thing that ROS2 attempts to improve on networking, but now we need to be network experts too 🥹
For completion, Orin is connected to create3 with USB C like this, both Orin and notebook have Ubuntu 22.04 and ROS Humble, on create3 is H.2.3 firmware.
I want to use access point on Orin, since I will move robot to different locations, and will connect with notebook (or anything else) after start of the robot.
Does anyone have working configuration like this and is willing to share xml profiles (and/or network config) which are you using for DDS setup?

Hi @martinerk0! I believe the issue you are having is related to needing to tell Cyclone DDS on the Orin that you want to use multiple network interfaces. The below XML profile has worked well for me on my Orin:
<CycloneDDS>
   <Domain>
     <General>
        <NetworkInterfaceAddress>l4tbr0,wlan0</NetworkInterfaceAddress>
    </General>
   </Domain>
</CycloneDDS>

Then make sure to export CYCLONEDDS_URI=/path/to/the/xml/profile in terminal on the Orin and replace the path with the path to your new file. You can also permanently add this export to your ~/.bashrc if the configuration works for you.
Let me know if that helps!

@brianabouchard  Are you sure it works just by listing interfaces?  I don't want to connect to create3 with wifi, just use usb connection.
Do you have a third PC that is connected (by wifi) just to Orin that you can
ros2 topic list --no-daemon ?
It seems that data is not bridged between create3 usb interface and wireless interface on Orin.
They had several issues/topics about this:

used fastrtp with discovery server: https://github.com/iRobotEducation/create3_docs/issues/184
this is exacly my problem: https://github.com/iRobotEducation/create3_docs/discussions/366

@tokk-nv is author of Jetson documentation, did you manage to list create3 topics using just usb connection with 3rd PC?

Ahhh, I see. I missed that you did not want to connect the Create 3 to Wi-Fi.
The turtlebot folks put up instructions a little while back on how to add an IP route and use the Fast DDS discovery server that might be of some interest.
I'm also investigating other possibilities and will let you know if I discover anything of interest.

Okay, I figured it out! ( and learned new networking commands ❤)
First I switched to FastDDS, since it seems from https://github.com/turtlebot/turtlebot4/issues/26 that cyclone doesn't work.
I followed https://gist.github.com/roni-kreinin/8fbb20cb4603b8eb5e3961167fb22cd4 and used xml profile from Turlebot4.
Then, started discovery server Orin:
fastdds discovery -i 0
after this, (and some ros2 daemon stop & start)
I could see /tf  and other topics from Orin.
On the other PC, same xml profile, but with
<IP_ADDRESS> i.e. IP of Orin.
After this, it didn't work, but in Turtlebot4 repo they add magic env variable:
ROS_DISCOVERY_SERVER
So on Orin:
export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811"
and on 3rd PC:
export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811"
After this, I could see all topics, but still no data, that's probably because  fastdds is relaying ROS topics.
On PC, ping <IP_ADDRESS> revealed that I still can't access data on create3.
In TB4 guide they mention that you have to turn on IP forwarding on Orin(RPi), but this was already set to true
sysctl net.ipv4.ip_forward
and also correct ip route on PC ( On Orin it is already set by script if you followed the create3 website)
sudo ip route add <IP_ADDRESS>/24 via <IP_ADDRESS>
Last thing I could think of is that l4tbr0 interface doesn't allow traffic in, so I set:
sudo iptables -A FORWARD -o l4tbr0 -j ACCEPT
sudo iptables -t nat  -A POSTROUTING -o l4tbr0 -j MASQUERADE
Aaand after this, it works! 🎉
I think this is crazy amount of steps to get it working, thanks @brianabouchard for pointing out the Turtlebot repo.
I guess this could be put into service like they do on Turtlebot4, I don't think they would want to add another SBC like Orin Nano, or other Jetson, since it uses other interface names, etc, but I don't think it would be that much work, right?
In addition RPi5 is out and that could have different steps (or not) than RPi4.
Should I put this into docs? @alsora @justinIRBT
I think most people with Jetsons want to use it with some 3rd PC and access point (and USB cable to create3).
Maybe the iptables networking should be put into service somehow like they do in Turtlebot, maybe @tokk-nv could look at it since he made the Jetson scripts?

That's fantastic! Huge thank you for posting your results and process. I'm sure this will be helpful to others as well.
For the docs, I wonder if it makes sense to integrate this into the discovery server page as an additional option? I'd also be happy to add this to the networking recommendations page. @shamlian what do you think?

@brianabouchard  haha I would be more than happy to make PR myself, but I wonder if it fits into Jetson software config more, since it concerns Jetsons only.
The ROS_DISCOVERY_SERVER env var is new thing and they use it in DDS docs and ROS docs too.
Also, I'm using Humble + 22.04 + Jetpack 6 (DP) natively without docker, which isn't mentioned in Jetson software config  so maybe I can update it as well too?

@martinerk0 I'm actually in the process of revising the Jetson docs to separate out devices that can only run up to JetPack 4 (Nano) and add options for a native ROS 2 install on JetPack 5 and 6 as that is my preferred way to run things as well :) I will incorporate your feedback here into the PR.
The environmental variable is interesting to me. We found we did not need it when configuring a discovery server with all the devices on Wi-Fi and all clients as super clients because the xml takes care of that. This is described in a single sentence note in the ROS 2 docs. I suspect this has something to do with all devices being on the same network and specifying a discovery server IP and port when we launch the discovery server. But, I'm by no means a networking expert so I'm curious to learn more.
What I'd love to have are docs that detail multiple options for discovery server implementations with notes on device specific interfaces. From recent posts, the most common use cases seem to be the RPi 4 and the Jetson Orin, but I anticipate we'll see higher usage with RPi 5 coming soon.

I don't think adding JetPack 4 (Nano) to documentation is wise, Nano was EOLed and Jetpack 4.x supports only Ubuntu 18.04 and therefore not Galactic or Humble.
It would be nice if Turtlebot 4 guys added support for multiple SBC like Orin & RPi5, but from what I understand RPi 5 needs Ubuntu 23.10 due to driver support. It seems there won't be binaries for 23.x
I have RPi5 at home, so I could build Humble from source, but I don't think anyone would do that anyways.
What I really liked about Turtlebot 2 was that you could run it on almost anything. I haven't yet played with TB4 packages on Orin, but I suppose it won't work out of box. Have you tried TB4 on Orin?
For things like mapping & navigation I suppose all the bringup and setup scripts will be necessary, and doing this network config would be easy in comparison.

I agree that there are concerns on the Nano, but we still have users interested in using them for a lower price point option. Yes, JetPack 4 runs Ubuntu 18.04, but we have actually had great success in upgrading it to Ubuntu 20.04 using some great instructions from Q-engineering.
I can't speak for the SBC choice for TB4, but I can confirm that I've only been able to get the RPi 5 to run Ubuntu 23.10. Slowrunner has been using RPi 5 successfully with a docker container for ROS 2. I've been planning to build Humble from source for my RPi 5 though.
No, I haven't tried the TB4 packages on the Orin, but I don't use TB4 packages for mapping and navigation. I build off of the Create 3 Examples repository.

Yeah I also used that image, but in the end,  4GB of memory is only useful in headless mode, RPi5 is much better deal now.
You created mapping/navigation just with create3? If so, that's impressive, I would like to see that :)
Anyway, I think we can close this issue as solved, if you make PR with updated Jetson docs, I would like to have a look at that :)


ERROR when building pip package: undeclared function related to swig

I was able to build the cc:tutorials_example_trainer , but failed to build the  pip package. Could anyone suggest how I can fix it? Thanks a lot!
Environment info
Operating System:
CentOS 6.5
Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
cuda-7.5
Steps to reproduce

I used python 3.5.1  installled by pyenv
I installed swig from source

Error Log
ERROR: /csproject/dygroup2/czeng/downloads/tensorflow/tensorflow/python/BUILD:978:1: C++ compilation of rule '//tensorflow/python:pywrap_tensorflow.so' failed: crosstool_wrapper_driver_is_not_gcc failed: error executing command
(cd /csproject/dygroup2/czeng/.cache/bazel/bazel_czeng/211970d9a1065a07eafbeb7dcc542b10/execroot/tensorflow &&
exec env -
PATH=/project/dygroup2/czeng//.pyenv/shims:/project/dygroup2/czeng//.pyenv/bin:/project/dygroup2/czeng/venv/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/cuda-7.5/bin:/usr/local/cuda-7.5/nvvm/bin:/csproject/dygroup2/czeng/venv/cudnnv5
TMPDIR=/tmp/2110270.1.all.q
third_party/gpus/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections -g0 '-std=c++11' -MD -MF bazel-out/host/bin/tensorflow/python/objs/pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.d '-frandom-seed=bazel-out/host/bin/tensorflow/python/objs/pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.o' -fPIC -DGPR_BACKWARDS_COMPATIBILITY_MODE -iquote . -iquote bazel-out/host/genfiles -iquote external/protobuf -iquote bazel-out/host/genfiles/external/protobuf -iquote external/bazel_tools -iquote bazel-out/host/genfiles/external/bazel_tools -iquote external/farmhash_archive -iquote bazel-out/host/genfiles/external/farmhash_archive -iquote external/jpeg_archive -iquote bazel-out/host/genfiles/external/jpeg_archive -iquote external/png_archive -iquote bazel-out/host/genfiles/external/png_archive -iquote external/highwayhash -iquote bazel-out/host/genfiles/external/highwayhash -iquote external/re2 -iquote bazel-out/host/genfiles/external/re2 -iquote external/eigen_archive -iquote bazel-out/host/genfiles/external/eigen_archive -iquote external/grpc -iquote bazel-out/host/genfiles/external/grpc -iquote external/nanopb_git -iquote bazel-out/host/genfiles/external/nanopb_git -isystem external/protobuf/src -isystem bazel-out/host/genfiles/external/protobuf/src -isystem external/bazel_tools/tools/cpp/gcc3 -isystem external/farmhash_archive/farmhash-34c13ddfab0e35422f4c3979f360635a8c050260 -isystem bazel-out/host/genfiles/external/farmhash_archive/farmhash-34c13ddfab0e35422f4c3979f360635a8c050260 -isystem external/jpeg_archive/jpeg-9a -isystem bazel-out/host/genfiles/external/jpeg_archive/jpeg-9a -isystem external/png_archive/libpng-1.2.53 -isystem bazel-out/host/genfiles/external/png_archive/libpng-1.2.53 -isystem external/highwayhash -isystem bazel-out/host/genfiles/external/highwayhash -isystem external/re2 -isystem bazel-out/host/genfiles/external/re2 -isystem third_party/eigen3 -isystem bazel-out/host/genfiles/third_party/eigen3 -isystem external/eigen_archive/eigen-eigen-5f86b31739cd -isystem bazel-out/host/genfiles/external/eigen_archive/eigen-eigen-5f86b31739cd -isystem third_party/gpus/cuda/include -isystem bazel-out/host/genfiles/third_party/gpus/cuda/include -isystem third_party/py/numpy/numpy_include -isystem bazel-out/host/genfiles/third_party/py/numpy/numpy_include -isystem util/python/python_include -isystem bazel-out/host/genfiles/util/python/python_include -isystem third_party/gpus/cuda -isystem bazel-out/host/genfiles/third_party/gpus/cuda -isystem third_party/gpus/cuda/extras/CUPTI/include -isystem bazel-out/host/genfiles/third_party/gpus/cuda/extras/CUPTI/include -isystem external/grpc/include -isystem bazel-out/host/genfiles/external/grpc/include -isystem external/grpc -isystem bazel-out/host/genfiles/external/grpc -Wno-self-assign -Wno-write-strings -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE="redacted"' '-D__TIMESTAMP="redacted"' '-D__TIME="redacted"' -fno-canonical-system-headers -c bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc -o bazel-out/host/bin/tensorflow/python/_objs/_pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.o): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc: In function 'swig_module_info* SWIG_Python_GetModule()':
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:2452:51: error: 'PyCObject_Import' was not declared in this scope
(char*)"type_pointer" SWIG_TYPE_TABLE_NAME);
^
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc: In function 'void SWIG_Python_SetModule(swig_module_info*)':
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:2521:92: error: 'PyCObject_FromVoidPtr' was not declared in this scope
PyObject pointer = PyCObject_FromVoidPtr((void ) swig_module, SWIG_Python_DestroyModule);
^
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:2512:22: warning: unused variable 'swig_empty_runtime_method_table' [-Wunused-variable]
static PyMethodDef swig_empty_runtime_method_table[] = { {NULL, NULL, 0, NULL} };/ Sentinel /
^
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc: In function 'swig_type_info SWIG_Python_TypeQuery(const char)':
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:2544:60: error: 'PyCObject_AsVoidPtr' was not declared in this scope
descriptor = (swig_type_info ) PyCObject_AsVoidPtr(obj);
^
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:2549:51: error: 'PyCObject_FromVoidPtr' was not declared in this scope
obj = PyCObject_FromVoidPtr(descriptor, NULL);
^
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc: In function 'PyObject _wrap_GetMatchingFiles(PyObject*, PyObject*)':
bazel-out/host/bin/tensorflow/python/pywrap_tensorflow.cc:5392:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (int i = 0; i < converted.size(); ++i) {
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-self-assign"
Target //tensorflow/tools/pip_package:build_pip_package failed to build

Which version of SWIG are you using? Can you try 3.0.8+?

Hi @caisq
Thanks for your reply. I tried SWIG Version 3.0.8 to my virtualenv directory but another error occured, saying that libpcre.so.1 not found

Same happens for 3.0.10
(cd /root/.cache/bazel/_bazel_root/2b02cca0edf7f3a977d1db2d1af2e0e1/execroot/tensorflow-0.9.0 && \   exec env - \     PATH=/software/gcc/6.1.0/login/bin:/software/tensorflow/0.9.0/:/software/python/3.4.5/login/bin:/software/intel/xe2015/composer_xe_2015.1.133/bin/intel64:/software/intel/xe2015/composer_xe_2015.1.133/bin/intel64_mic:/software/intel/xe2015/composer_xe_2015.1.133/debugger/gui/intel64:/software/CUDA/7.5.18/bin:/software/bazel/0.3.0:/software/java/1.8.0_25//bin:/usr/pbs/bin:.:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin \   /software/gcc/6.1.0/login/bin/gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -Wall -Wl,-z,-relro,-z,now -B/software/gcc/6.1.0/login/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x' '-frandom-seed=bazel-out/local-py3-opt/bin/tensorflow/python/_objs/_pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.o' -fPIC -iquote . -iquote bazel-out/local-py3-opt/genfiles -iquote external/protobuf -iquote bazel-out/local-py3-opt/genfiles/external/protobuf -iquote external/bazel_tools -iquote bazel-out/local-py3-opt/genfiles/external/bazel_tools -iquote external/farmhash_archive -iquote bazel-out/local-py3-opt/genfiles/external/farmhash_archive -iquote external/jpeg_archive -iquote bazel-out/local-py3-opt/genfiles/external/jpeg_archive -iquote external/png_archive -iquote bazel-out/local-py3-opt/genfiles/external/png_archive -iquote external/highwayhash -iquote bazel-out/local-py3-opt/genfiles/external/highwayhash -iquote external/re2 -iquote bazel-out/local-py3-opt/genfiles/external/re2 -iquote external/eigen_archive -iquote bazel-out/local-py3-opt/genfiles/external/eigen_archive -iquote external/grpc -iquote bazel-out/local-py3-opt/genfiles/external/grpc -iquote external/nanopb_git -iquote bazel-out/local-py3-opt/genfiles/external/nanopb_git -isystem external/protobuf/src -isystem bazel-out/local-py3-opt/genfiles/external/protobuf/src -isystem external/bazel_tools/tools/cpp/gcc3 -isystem external/farmhash_archive/farmhash-34c13ddfab0e35422f4c3979f360635a8c050260 -isystem bazel-out/local-py3-opt/genfiles/external/farmhash_archive/farmhash-34c13ddfab0e35422f4c3979f360635a8c050260 -isystem external/jpeg_archive/jpeg-9a -isystem bazel-out/local-py3-opt/genfiles/external/jpeg_archive/jpeg-9a -isystem external/png_archive/libpng-1.2.53 -isystem bazel-out/local-py3-opt/genfiles/external/png_archive/libpng-1.2.53 -isystem external/highwayhash -isystem bazel-out/local-py3-opt/genfiles/external/highwayhash -isystem external/re2 -isystem bazel-out/local-py3-opt/genfiles/external/re2 -isystem third_party/eigen3 -isystem bazel-out/local-py3-opt/genfiles/third_party/eigen3 -isystem external/eigen_archive/eigen-eigen-d02e6a705c30 -isystem bazel-out/local-py3-opt/genfiles/external/eigen_archive/eigen-eigen-d02e6a705c30 -isystem third_party/py/numpy/numpy_include -isystem bazel-out/local-py3-opt/genfiles/third_party/py/numpy/numpy_include -isystem util/python/python_include -isystem bazel-out/local-py3-opt/genfiles/util/python/python_include -isystem third_party/gpus/cuda -isystem bazel-out/local-py3-opt/genfiles/third_party/gpus/cuda -isystem third_party/gpus/cuda/include -isystem bazel-out/local-py3-opt/genfiles/third_party/gpus/cuda/include -isystem external/grpc/include -isystem bazel-out/local-py3-opt/genfiles/external/grpc/include -isystem external/grpc -isystem bazel-out/local-py3-opt/genfiles/external/grpc -Wno-self-assign -Wno-write-strings -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -MD -MF bazel-out/local-py3-opt/bin/tensorflow/python/_objs/_pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.d -c bazel-out/local-py3-opt/bin/tensorflow/python/pywrap_tensorflow.cc -o bazel-out/local-py3-opt/bin/tensorflow/python/_objs/_pywrap_tensorflow.so/tensorflow/python/pywrap_tensorflow.pic.o): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1. bazel-out/local-py3-opt/bin/tensorflow/python/pywrap_tensorflow.cc: In function 'swig_module_info* SWIG_Python_GetModule()': bazel-out/local-py3-opt/bin/tensorflow/python/pywrap_tensorflow.cc:2452:51: error: 'PyCObject_Import' was not declared in this scope          (char*)"type_pointer" SWIG_TYPE_TABLE_NAME);


Add support for CStor volume upgrade

Currently in v0.5.0 release the CLI can upgrade the Cstor Pools, i.e. CSPCs which must be done post control plane upgrade, now it might be helpful to add upgrade option for cstor to bring it at a feature parity level with Jiva volume upgrades(jiva lacks a pool concept in true sense)

cStor is deprecated and all the cli commands around that have also been deprecated.


LACT package forced to use vulkan?

Describe the bug
My PC was using the unstable channel for a while now. I have not updated the channel locally for about two-three months. I now switched to the stable 24.11. Since this switch, the LACT application fails to start. There is already an issue and a temporary solution in their repo. It seems like the issue occurs because the application is being rendered using vulkan, instead of OpenGL.
Has there been a distro-wide change or is just this application rendered using Vulkan?
The source of the LACT nix package mentions vulkan, but my understanding of the nix language is not good enough to make sense of how vulkan is used.
Steps To Reproduce
Run lact in the terminal:
2024-12-02T20:43:21.885666Z  INFO lact_client::connection::unix: connecting to service at "/var/run/lactd.sock"
Gdk-Message: 21:43:21.885: Error 71 (Protocol error) dispatching to Wayland display.

Run GSK_RENDERER=opengl lact gui - application starts
Notify maintainers
@figsoda

Add a :+1: reaction to issues you find important.

Related https://github.com/NixOS/nixpkgs/issues/358827

Update
I updated my entire system (still on stable nixos-24.11). Now lact (and other GTK apps) launch, but are rendered incorrectly:
Launching the application directly (lact gui):

Launching the application with
GSK_RENDERER=opengl lact gui

This does also happen with gnomes disk utility tool:


Implemented customizable profile fields for LinkedIn

As specified in issue #43
I tried to minimize the amount of changes to make it easy to review. I thought about removing the UserInfoEndpoint private const because it's only used in one place and I didn't like making a variable with the same name.
Let me know if you want me to change anything. Thanks!

@jerriep just checking in to see if you need me to do anything else for this. Thanks!

I am taking a bit of a break. Will try and look at it sometime over the next few weeks. Thanks :)

OK good to know thanks. When you do get around to it and anything needs changing don't hesitate to contact me.

Thanks @jerriep !


Create README.md to explain the workflow files and how to utilize build_pkg.yml workflow from other packages

Here is the draft one from previous discussions:
Certainly. Allow me to explain the situation first, and then we can determine the best location for this document.
The build_pkg.yml file serves as a reusable workflow that other packages can utilize. When modifications are made to the build_pkg.yml workflow, it often requires corresponding changes in the build_* scripts to handle the input variables or something else. Consequently, the git branch in build-package project should include changes to both the build_pkg.yml and build_* scripts together.
Without bind-mounting the build_* scripts inside the container, we would be unable to effectively test the build_pkg.yml workflow if the corresponding changes to the build_* scripts in the same branch are not present inside the container.
In addition to the specific utilize of the build_pkg.yml workflow from a particular branch using @workflow-branch-name, as demonstrated in this example: https://github.com/gardenlinux/package-htop/actions/runs/6823007358/workflow
There is an additional aspect to consider. When the actions/checkout action is used with repository: but without the ref:, it checkouts the default branch of the repository. Therefore, it is necessary to explicitly specify the ref: option with the workflow-branch-name that specific utilize from other packages along with the repository, as shown below:
      - uses: actions/checkout@v4
        with:
          repository: gardenlinux/package-build
          ref: workflow-branch-name

This explains the presence of the ref: ${{ github.ref_name }} line in the previous version of this PR. I believe it won't harm to the workflow to cause any issues if the workflow is utilized by other packages in the default branch, as the variable will also be changed to the default branch.
(However, it's a workaround for testing purposes. I dropped it due to it's unrelated to the goal of this PR. Please let me know if we do need it or just to be needed in this document.)
Now, let's discuss the most appropriate placement and title for this document. :)
Originally posted by @alee-ntap in https://github.com/gardenlinux/package-build/pull/8#discussion_r1391186674

Document created here:
https://github.com/gardenlinux/package-build/blob/feature/5-replace-pkg.ymal-with-workflow-variables/.github/workflows/README.md


Remote Config won't return the correct values based on a set user property value

Step 0: Are you in the right place?

For issues or feature requests related to the code in this repository
file a Github issue.

If this is a feature request please use the Feature Request template.

For general technical questions, post a question on StackOverflow
with the firebase tag.
For general (non-iOS) Firebase discussion, use the firebase-talk
google group.
For backend issues, console issues, and other non-SDK help that does not fall under one
of the above categories, reach out to
Firebase Support.
Once you've read this section and determined that your issue is appropriate for
this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

Xcode version: 12.4
Firebase SDK version: > 7.1.0
Installation method: Swift Package Manager
Firebase Component: RemoteConfig

[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
If I update Firebase to any version bigger than 7.1.0 then RemoteConfig stops working as expected.
My app uses an user property value to grab different values from RemoteConfig.
With any version bigger than 7.1.0 this user property value is ignored and RemoteConfig always returns the same
values no matter what. Whenever I rollback to 7.1.0 then everything works as expected.
If I look in the analytics debug view I can see my user property being set correctly.
Relevant Code:
On app start, before grabbing any RemoteConfig values I do this:
Analytics.setUserProperty("dummy_value", forName: "dummy_property")

Immediately after that I call fetchAndActivate. This works as expected on 7.1.0 but fails on any newer versions.

@zeusent Sorry about the trouble and thanks for the report and narrowing down the version.
@karenyz Please take a look. I suspect a regression related to #6692.

Hi folks, I believe this is affecting us still. Was there any progress here?

So It's been a bit unreliable and tricky to reproduce, but what we're seeing is essentially the following setup is inconsistent:

We have one param which has its value set conditionally to true based on a user property
We have an experiment whose allocation excludes users with that user property
Somehow we're still seeing users with this user property get the param set to false sometimes (but not always). It also seems to change arbitrarily on occasion.

To make it more concrete with an example:

In remoteconfig, we have a condition setting paramA to true if user property prop1 is true
We have an experiment config where the targeting explicitly excludes prop1 = true, but has variants with paramA true or false

For some reason, we still have users with prop1 true who are getting paramA set to false.

Hi there, as this is a very old issue with no updates, I am going to be closing this. If you come across anymore issues with remote-config using the latest firebase version, feel free to open a new ticket.


performance reduction for zipapps with many *.robot files

Dear all,
TLDR.: I believe that usage of the invalidated_caches function is causing performance issues, slightly on regular robot installations (+25% for the used example) and hugely for zipapps (+5s for the used example)
I noticed when using a lot of robot files, with only a view tests in them which run very quickly, that the runtime in a zipapp is much slower than a regular installation.
I did have a look at what is going on there, and I noticed that __ import __ is used, not importlib.util (importlib.util apears to be the recomeded methond).
A quick and dirty experiment using importlib.util instead of __ import __ did work on my minimal example, and improved speed on the given setup and example about 5-7x for the zipapp, and about 2x for the regular install.
Running the acceptance tests triggers about 1200 fails on windows (mostly permission issues) and about 250 on linux, and does not show a significant speedup (but the fails may influence runtime significantly...)
Is this a topic worth looking into? Are there known reasons not to use importlib.util? Am I fooled by the effect that missing calculations explain improved speed?
Some data.:
See the not-very-encouraging results of the CI run.:
https://github.com/franzhaas/robotframework/actions/runs/4645976291/jobs/8222120931
The example code used.:
https://github.com/MarketSquare/compact_testprogram_distribution
micro benchmarks
A micro benchmark in a regular environment.:

A micro benchmark in a zipapp.:

The microbenchmarks show little to very little speedup.
However.:
A microbenchmark in a regular environment.:

And in a zipapp.:

Therefore i now belive that the invalidate_caches function is causing the slowdown....
Best regards,
Franz

Dear all,
I followed the idea that reducing the calls to invalidate_caches improves performance. 5s is very slow, but avoiding to invalidate the caches is probably a good idea.
A CI run with modifications that minimize the usage of invalidate_caches
https://github.com/franzhaas/robotframework/actions/runs/4652244029/jobs/8232333488
there is a single unittest fail, and all other atests pass, I believe this is not too far of.
Still open is to get rid of the invalidate_caches completely by replacing the one remaining modify sys.path operations with for example importlib.utils.
The advantages I hope for are.:

faster execution, invalidating the cache less will speed up things...
removing a potential race condition. Modifying the sys.path, can influence other tasks which use the import system. This is relevant when having for example a streamlit frontend to robotframework.

Best regards,
Franz

I dug into this a bit more...
This is a known issue and python community is actively discussing it.
https://github.com/python/cpython/issues/103200
I did not check it myself,  but if I understand the discussion correctly, python 3.9 and earlier are not affected, python 3.12 is planned not to be affected and whether or not fixes will be implemented for 3.10 and 3.11 is open to debate.
To my understanding invalidated_caches  is necesseray and needs to be doing something in order for robotframework to work correctly under some conditions.
So we have the option to just sit this one out and wait for 3.12...
Best regards,
Franz

The problem at hand has been solved....

importlib.invalidate_cache() is used for a reason. Without it we couldn't import modules that are created during execution and I think it also helps if a module with same name is imported from different places. As you noticed, there are tests that break if importlib.invalidate_cache() is removed. I'm not sure is there a need to do it always before an import like nowadays, though. We possibly could do that only if an import fails and then retry.
The reason we use __import__ and not importlib for importing is that our importing code predates importlib. We even had our own cache invalidation logic that was made redundant by importlib.invalidate_cache(). There haven't been needs to switch to importlib otherwise, but if there ever are bigger changes to this code it certainly makes sense.


[atom-reason] Hover to see function declaration in scrollable tooltip window

Extension of jump-to-definition. Just show the code. If the person wants to jump then click on the tooltip window or something.
I myself have jump-back-to-previous-cursor or something along that line, so I wasn't personally feeling much friction.

@shayne might know how to implement this.


Update docstrings and adds a mockup fixture for reading room request

Adds a variety of smaller methods and updates docstrings with arguments and return variables for each method for processing reading room requests.

@helrond fixtures/readingroom_request.json is the request that I added to send to Aeon. Is that what you were thinking of?


Update the dependencies and require the SDK 3.x

As per title, along with a few dependencies (both dev and non) I updated the main SDK to version 3.x 🎉 There weren't many changes to do and the majority were in the tests. In reality, I just made the minimum amount of work to make the tests pass, taking for granted that since both unit and e2e tests are green everything is fine. If someone that is brave enough wants to try this out before merging it it would be really cool

After hours and hours of debugging, I found out the cause of the broken build: a change that happened between PHP 7.2 and 7.3 (I didn't find which one) which made sure that when an error is caught in a try statement, error_get_last() is not filled with its information. However, Xdebug maintained this behavior until 2.9.3 when the bug was fixed. TLDR, Travis CI is using a bugged version of Xdebug for PHP 7.2. I have no clue about why the step with SYMFONY_VERSION=3.4.* SYMFONY_DEPRECATIONS_HELPER=disabled doesn't fail though

I updated the CHANGELOG and added support for a few new options. However, the build on PHP 7.2 keeps failing and I have no idea how to fix it once for all because even if we workaround the issue in the FrameContextifierIntegration integration it may arise somewhere else and without changing how we handle the integration of the error handler with the framework I don't see any manouver space


Can we get a "max path weight" optional param for a_star_search?

Maybe there's another workaround.
I have a situation (I'm working through the tutorial book) where a monster can see me, it's physically near me, but it can't get to me (typically because another monster is in the way). Like, at all; no path exists.
So it runs an A* search, and sometimes that search (depending on the size of the map and some other factors) can take seconds! It drags the game to a halt. But really, even if the thing found a (super long) path; I don't want it to take it. So what I'd like to say is, find me a path with max weight <= 20, but if not, like, go about your business. But that doesn't seem to be possible at the moment.
Based on my (partial) understanding of the A* search algorithm, this shouldn't be a significant change. Is this a reasonable thing to add? Is there another workaround that I just don't understand?

That's a good idea. I'm not sure how Rust handles optional parameters (I think it doesn't, so I'll have to write a wrapper layer). You could probably fake it by counting the path steps, or making a line between the two points and making sure every cell in the line is passable (or include monsters as opaque when doing your visibility scan), but I can see that being generally useful - so I'll see what I can do.

Yeah, rust doesn't do optional parameters but a wrapper layer I assume would just be a few lines? I haven't looked at the original code so there could be complexity I don't see.
I'm not sure your "fake" would work in general (what if there is a path, it's just not the direct path ... bleh). And the issue is really with runtime of the A* search -- I can look at the path after it comes out and ignore it if it's too long, but if it took 3.5s to not find a path, I have a user responsivity problem 😅
That being said I think I can replace most of my uses of A* search with Dijkstra maps, I have high hopes for how that's going to pan out.


list of files not dont show

When i tried add this to my page with bootstrap 3.0.0 and the files list (already uploaded and not uploaded) are not showing, but are in code. Like in here: https://www.dropbox.com/s/fgtpspazm5orl3r/Screenshot 2014-02-11 16.54.43.png

I haven't seen this. And it is fairly old now, so I'm closing it. Sorry that I couldn't help out.


updates for koa2.x, use compose for stacks

Opening this for discussion and thoughts:
I was messing with Koa 2 alpha 2 and needed a router — breaking changes around passing ctx as an argument yields koa-router unusable right now. There's another project ko66 that seems to be a similar project that's been setup for Koa 2 support, but I'd like to see this lib grow and I'm sure others would as well.
This PR updates all middleware to the Promise-based Koa 2 async pattern. It does not use async/awaitnotation or transpiling, which I could see being an options for this lib as well. For simplicity's sake, everything GeneratorFunction was changed to a function with promise-based flow, all middleware functions were updates to the (ctx, next) signature and ctx is now used in place of this when modifying the middleware context.
Additionally, koa-compose was added as a dependency to drive layer middleware stacks. I think this is a better choice than invoking the layer chain of middleware functions by hand (ordered). Since koa-compose drives the actual koa middleware execution, there's likely going to be fewer issues when koa middleware api changes, as the compose lib can simply be updated. This also allows for exact same async flow in normal koa middleware due to the same dispatch function driving https://github.com/koajs/compose/blob/master/index.js#L31
By using Koa 2, >= node 4 would be required

(Koa requires node v4.0.0 or higher for (partial) ES2015 support.)

I have not updated the history.md with these notes.
Updates:

update koa dependency to alpha2
add koa-compose dependency for layer stack composition
update middleware signature to (ctx, next)
update param middleware signature to (param, ctx, next)
remove all generator functions and gen type checks
update all specs for promise-based usage
updates examples / comments / docs

Wow. I tried to do a PR too and got stuck when I saw that the stack is composed without koa-compose currently. I'm not 100% confident with koa-66 yet so @alexmingoia could merge this it would be great.

Haha. Thanks for checking it out, @felixfbecker . That was a tricky part. I thought you were doing something similar because I also had issues with regenerator "missing ) after argument" error and referenced your babel gh issue to help me fix it :D

Updated the changes @ https://github.com/jbielick/koa-router/commit/9e742f1153a04d6cefa80fc550de62f62c0a8721#diff-504fd89f344be1e9c4b583f3ebd7428aR319 to reflect the intended behavior. Prepends the layer stack of middleware with one middleware function that supplies params and captures to the context before yielding to the next middleware.
This essentially flattens the layers and applies the param-builders before each layer stack.
    layer1                    layer2
        |                             |
parambuilder        parambuilder
      /    \                       /     \
 mw1  mw2            mw3   mw4

would become
[layer1:parambuilder, mw1, m2, layer2:parambuilder, mw3, mw4]

Like the original code which iterated over each layer, modified ctx and then invoked each middleware in the layer before continuing to the next layer and doing the same.

Wow this is great. I will have time to review later today and I'll try to get this merged ASAP.


Bluetooth GATT multiple Primary Service Declarations

When I add multiple Primary Service Declarations to my Bleutooth Low Energy CSV file, I get an error (AT+BLEGATTSSRVSTART) when starting the GATT services:
AT+BLEGATTSSRVSTART

ERROR

What could be the cause? Can't multiple services be defined?
Esp32BleGatt.csv.txt
Update: It is the very same problem as: https://github.com/espressif/esp32-at/issues/87

Any news/plans when multiple gatt services will be supported?

We will support multiple Primary Service in next release.

Can you try b991a183bd6645340fc73a07cc964cfb3c5aae99? If you have any question, please just feel free to let us know.


Remove fs2 dependency for broader platform support

The use of fs2 for file locking limits the platforms where cargo-xbuild can be built/installed.  Upstream cargo was updated to make the locking calls itself, as fs2 is effectively unmaintained (and thus not merging patches to support new platforms).  This PR replicates that change, so cargo-xbuild is effectively freed of the platform constraints of fs2.
Thanks

Published as v0.6.1.

Seems like this PR has compilation issues on Windows: https://github.com/rust-osdev/cargo-xbuild/issues/92
Maybe you can look into this @pfmooney? For now I yanked version 0.6.1 again.

I think you forgot to add the winapi dependency in the Cargo.toml.
(We should really set up a CI workflow for this repo so that we detect such problems in the future.)

I think you forgot to add the winapi dependency in the Cargo.toml.
(We should really set up a CI workflow for this repo so that we detect such problems in the future.)

Ah, sorry about that!  I'll have PRs posted shortly to do both pieces (fix the winapi piece, and setup a github action to test run cargo build)

(You might also want to consider using cargo's new build-std feature instead of this crate.)

Yep, totally agreed.  In this case, I wanted to reduce friction for building an existing project which is setup to use cargo-xbuild.


Ember error handling

Currently it's just a blank page if there's a problem with the API server. Should include information about opening a github issue.

I'll see if I can tackle this after getting the API interactions refactored and tests around them!

Tests? My heart sings!
Adam Perry
Sent from mobile
On Jun 7, 2016 3:36 AM, "Chris Krycho"<EMAIL_ADDRESS>wrote:

I'll see if I can tackle this after getting the API interactions
refactored and tests around them!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dikaiosune/rust-dashboard/issues/46#issuecomment-224243046,
or mute the thread
https://github.com/notifications/unsubscribe/AGfyeeMsTl2zIXs5Xjyv5wIo7hOGxZ8hks5qJUnGgaJpZM4Ivovy
.

Boilerplate: I'm going to refocus this project on rfcbot, since that's the primary usage rusty-dash.com is seeing.


Group and roles assign failed

Describe the issue:
Fail group and roles assign to user
How to reproduce:

Login to the admin portal
2.Click create user and while creating add groups, roles
finish user creation

Expected behavior:
Assign roles and groups to created user
Actual behavior:
Once created user "user created successfully" message pop up, but after error message pop up like below and once navigate to the edit user assign roles and groups not display
Request payload:
{"Operations":[{"op":"add","value":{"members":[{"display":"hello","value":"40b361c3-e1e7-4d93-9003-d88c8229e3bc"}]}}],"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"]}
Response:

Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: [e.g., IS cloud M28 ]

Closing this issue since it was fixed with the PR: https://github.com/wso2/identity-apps/pull/1167


miss right parentheses in reshape section of DataFrames

In "Reshape from wide to long format''
stack(df, [1:n; ])
stack(df, [:col1, :col2, ...]
melt(df, [:col1, :col2]) [

Should the second stack be
stack(df, [:col1, :col2, ...])

And is there an extra bracket in melt, so should it be
melt(df, [:col1, :col2])

Thanks. Please, open a PR so I can merge your changes.


Not all python packages support egg_base

A small leftover from https://github.com/colcon/colcon-core/pull/387#issuecomment-698937014 is that some Python packages from PyPI don't support the egg_base option. We can work on getting fixes push upstream to these (https://github.com/msoulier/tftpy/pull/114, https://github.com/npcole/npyscreen/pull/106), but it would be nice if colcon could detect this failure and retry without that option.
Reproduction:
git clone https://github.com/npcole/npyscreen
colcon build

Result:
Starting >>> python3-npyscreen
--- stderr: python3-npyscreen
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'egg_info'
---
Failed   <<< python3-npyscreen [0.72s, exited with code 1]

We've found a handful of python packages in our distribution which fail in this way.

Please see #396 which aims to add support for Python packages using distutils.


added jenkinsfile parameters

@Tejadeepc Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.


Auto build for newly created feature branch

What feature do you want to see added?
Auto build for newly created feature branch, this will be a good help when doing a pull request because we can assure that latest code changes are buildable.
Upstream changes
No response

Hi @ericoliveros , you want new branches to be added automatically to the build monitor view or you want the new branch to be built automatically?
The former can be done if you use a regular expression to include jobs in the view or you can use the View Job Filters plugin.
The latter is not a functionality of a view, you need to configure that in the job itself.

there isn't a single way to do it, normally new jobs are built automatically and then it depends on your configuration.
I'd check the documentation of the plugin you use to fetch your code from your source code repository.
for example:
https://plugins.jenkins.io/github-branch-source/
https://plugins.jenkins.io/gitlab-branch-source/


WGSL output: bindings and layout

These tests are failing for WGSL

compute\buffer-layout
compute\dynamic-dispatch-11
compute\dynamic-dispatch-12
compute\entry-point-uniform-params
compute\frem
compute\func-cbuffer-param
compute\parameter-block
compute\type-legalize-global-with-init

All of the mentioned test cases except compute\buffer-layout are passing (WGSL output is compiling) now.
For compute\buffer-layout, there is still another issue for which I filed #4985.


Example

[x] Add workflow for example folder
[x] Include terraform validate in workflow
[x] Add k8s deployment spire
[x] Add k8s deployment vault
[x] Add spiffe-vault deployment on k8s
[ ] Add cosign container utilizing spiffe-vault to grab signing key from vault https://console.cloud.google.com/gcr/images/projectsigstore/global/cosign
[ ] Add example to retrieve/store a secret in vault utilizing spiffe-vault

Hey @marcofranssen, I was able to get everything working well on my Macbook. Since some images are not available yet, I built them locally. Aside from that, I was unable to execute the very last command to cosign the image. I don't think cosign is installed in the container.
Referring to this command: $ cosign sign -key hashivault://cosign philipssoftware/spiffe-vault:latest
Great work, really clear instructions!

Correct. Cosign is not in the image. Will work out the example a bit further to also have the cosign binary in a deployment.


Update UsePythonVersion to allow versions other than (pypy2 or pypy3.6)

Task name: UsePythonVersion@0
Description: Removes hardcoding of pypy version in favor of a prepended full version.
Documentation changes required: Y?
Added unit tests: Most likely necessary, I'll listen for feedback here.
Attached related issue: Y #15232
Checklist:

[ ] Task version was bumped - please check instruction how to do it
[ ] Checked that applied changes work as expected

^ for the above questions, what's the best way to test these updates in a real job?

I am not sure how this works. For reference, the github action setup python uses the version.json file from the pypy downloads to figure out what versions are relevant and to download a tarball.
In any case it would be good to adopt a strategy of allow downloading missing versions of python/pypy (like the github actions) so that new releases do not necessarily require a new image.

@mattip this relies on the existing findPyPy methodology that the the common tooling implements. It's not amazing, but it should still be able to locate the pypy distro.
I agree with your point RE: the actions manifest. I actually use it directly in my pipelines. I'm trying to keep a fairly targeted update in this PR though.

Closing, this was done differently in #16377, thanks.

@mattip thanks for the heads up, appreciate it.


Set up CodeSandbox CI

Hi @nene 👋
Wanted to check whether you'd be open to installing the CodeSandbox CI GitHub app to create an installable package on each PR.
Example (@upleveled/preflight):

Comment in PR https://github.com/upleveled/preflight/pull/481#issuecomment-1834224674
Installable package https://ci.codesandbox.io/status/upleveled/preflight/pr/481/builds/444571

If you're open to this, then you'd need to merge this PR and also install the CodeSandbox CI GitHub App

Yeah. Why not.


Update Composer dependencies (2023-07-25-00-13)

Visual regression test passed!
View the visual regression test report


AT+CIPDNS not working as expected

Documentation says <IP_ADDRESS> is the default DNS server. But query get +CIPDNS:1,"<IP_ADDRESS>".
I think documentation is wrong.
Automatic DNS settings from DHCP isn't stored if SYSSTORE=1. After reset CIPDNS isn't changed. So device always has the wrong DNS server if it is connected via DHCP. If there is no internet connection CIPDOMAIN should not work, but not verified yet.
AT+CIPDNS?
+CIPDNS:1,"<IP_ADDRESS>"

AT+SYSSTORE=1
AT+CIPDNS=0
AT+RST
AT+CIPDNS?
+CIPDNS:1,"<IP_ADDRESS>"

My firmware version:
AT+GMR
AT version:<IP_ADDRESS>-dev(s-dd5ecec - ESP8266 - Feb 24 2021 02:56:03)
SDK version:v3.4-rc
compile time(cf5c761):Mar 11 2021 10:11:38
Bin version:2.0.0(ESP8266_1MB)

I downgraded to this version:
git branch release/v<IP_ADDRESS>_esp8266
AT version:<IP_ADDRESS>-dev(24b71e4 - Aug 25 2020 08:41:31)
SDK version:v3.3-2-gb6e861a7
compile time(3355cd8):Mar 13 2021 13:53:57
Bin version:2.1.0(Unknown)

and it works as expected

s-dd5ecec means the firmware is generated by silence mode, while there is a known issue about it.
could you please test with no silence mode.

Closing due to lack of response, please feel free to reopen if this is still an issue and you can supply more details. Thanks.


RFM - cmder

I DON'T Want To Become The Maintainer

[x] I have followed the Package Triage Process and I do NOT want to become maintainer of the package;
[x] There is no existing open maintainer request for this package;

Checklist

[x] Issue title starts with 'RFM - '

Existing Package Details
Package URL: https://chocolatey.org/packages/cmder
Package source URL: https://github.com/admiringworm/chocolatey-packages/tree/master/automatic/cmder
Date the maintainer was contacted (in YYYY-MM-DD): 2021-12-13
How the maintainer was contacted: Contacted via Email

I am the maintainer of this package, and I have not been contacted regarding it.
Nor is this package outdated, please refrain from opening false RFM requests.


EXC_BREAKPOINT thrown

I'm facing an issue where my app crashes and I'm getting EXC_BREAKPOINT exception.
com.sunsetlakesoftware.GPUImage.openGLESContextQueue Crashed.
The problematic method is [GPUImageFilter newCGImageFromCurrentlyProcessedOutputWithOrientation:]
I'm unable to reproduce the crash, but I am getting the reports using Crashlytics.
What could be the cause of this?

I'm seeing the same thing in release 1.7 . Was anyone able to fix this successfully?
Here is my stack trace. Its happening to 5% of my users
Crashed: com.sunsetlakesoftware.GPUImage.openGLESContextQueue
0  CoreFoundation                 0x192257b9c CFRetain + 124
1  {AppName}                         0x100202a94 __56-[GPUImageFramebuffer newCGImageFromFramebufferContents]_block_invoke (GPUImageFramebuffer.m:334)
2  libdispatch.dylib              0x19120d1c0 _dispatch_client_callout + 16
3  libdispatch.dylib              0x19121a860 _dispatch_barrier_sync_f_invoke + 84
4  libdispatch.dylib              0x19121de9c _dispatch_barrier_sync_f_slow + 400
5  {AppName}                         0x100213688 runSynchronouslyOnVideoProcessingQueue (GPUImageOutput.m:33)
6  {AppName}                         0x100202990 -[GPUImageFramebuffer newCGImageFromFramebufferContents] (GPUImageFramebuffer.m:370)
7  {AppName}                         0x1001fd6e0 -[GPUImageFilter newCGImageFromCurrentlyProcessedOutput] (GPUImageFilter.m:198)
8  {AppName}                         0x1001ffa44 -[GPUImageFilterGroup newCGImageFromCurrentlyProcessedOutput] (GPUImageFilterGroup.m:50)
9  {AppName}                         0x10021450c -[GPUImageOutput imageFromCurrentFramebufferWithOrientation:] (GPUImageOutput.m:347)


Add beam_PostCommit_Python_ValidatesDistrolessContainer_Dataflow

This PR closes #33003, adding scheduled checks for Python SDK (non ML) distroless variants via GitHub workflows.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

I want to wait at least 24 hours from when fc9083b35f982d3f1c5579cc0d06e9ae87689f77 merged before flipping this PR to ready.


PR: Update conda-lock for change in release workflow

Description of Changes
We agreed to change the release workflow to PyPi -> conda-forge -> Github in order to produce sound conda-lock files on release for updating our conda-based applications. This results in the following changes to the installer CI workflow and update manager.

The Spyder conda package will only be built on CI for PRs and workflow-dispatch triggers, not releases
The conda-lock file will not be patched. For non-release events, this produces an accurate conda-lock file which cannot be used outside CI. For release events, this produces the accurate and portable conda-lock file.
The update manager only looks at Github for releases.

This is a follow-up PR to #22204

The update manager only looks at Github for releases.

I don't understand the need for this change because:

PyPI and Conda-forge users can get notifications about new updates more quickly than the ones using our installers, and that's fine.
Anaconda takes a lot of time (these days it could take between six months to a year) to update to a new version. So, we must not report a new version to them without checking if one is available in its channels (which is what we already have in place).

I don't understand the need for this change because:

PyPI and Conda-forge users can get notifications about new updates more quickly than the ones using our installers, and that's fine.

That's not fine since in these circumstances we prompt the user with the opportunity to install the update using our installers. If they accept and those installers are not yet available, then there will be an error.

Anaconda takes a lot of time (these days it could take between six months to a year) to update to a new version. So, we must not report a new version to them without checking if one is available in its channels (which is what we already have in place).

This is a good point and reveals an existing issue. Currently, in this circumstance, the main channel will be checked for updates, which you point out could be as much as a year behind. This means that users will not even be given the option to use our installer either.
By checking on GH, anaconda users will at least be given a timely opportunity to update using our installer. However, we may need to inform the user that if they do not opt for our installer a new version is not yet available on the main channel.

That's not fine since in these circumstances we prompt the user with the opportunity to install the update using our installers. If they accept and those installers are not yet available, then there will be an error.

Ok, I understand your logic now and you're right about this point.

This is a good point and reveals an existing issue. Currently, in this circumstance, the main channel will be checked for updates, which you point out could be as much as a year behind. This means that users will not even be given the option to use our installer either.

It's unfortunate that we have to do that for Anaconda users, but I don't see other choice (see below).

By checking on GH, anaconda users will at least be given a timely opportunity to update using our installer. However, we may need to inform the user that if they do not opt for our installer a new version is not yet available on the main channel.

The problem is that, with these changes, we'd be informing users that a new version is available regardless of being part of Anaconda. And, although I understand your point of letting users about a more recent version not present there, as a user I'd be frustrated by trying to install it through Anaconda just to see that it's not really part of it.
So, now I think we should revert the code you removed but only for Anaconda.

as a user I'd be frustrated by trying to install it through Anaconda just to see that it's not really part of it.

I don't think I understand your point here. As a user, if I'm informed that there is a new version of Spyder available if I use the installer, but there is not a new version available on the main Anaconda channel, then at least I have a choice. Otherwise I don't even know that Spyder is actually more than a year ahead of what I'm using.
If Anaconda installed Spyder users are a year behind, then I think this category of users should be the primary target for nudging to use our installer and not kept ignorant of it.
Perhaps I don't understand completely what you think the user would be frustrated with.

If Anaconda installed Spyder users are a year behind, then I think this category of users should be the primary target for nudging to use our installer and not kept ignorant of it.

I think there are several UX issues with that approach:

Users can be using Spyder through Anaconda in restricted environments (e.g. schools or companies) that don't allow them to update it on their own.

But even if that's not the case, I think we need to respect users' choice and not try to force them to use our installers if they decided to go with Anaconda. However, given the amount of downloads we have for our installers, most people find on their own that Anaconda is not the best choice because it's outdated and unstable.

I think there are several UX issues with that approach:

Users can be using Spyder through Anaconda in restricted environments (e.g. schools or companies) that don't allow them to update it on their own.

This is only true if "Check for updates on startup" is selected. In the institutional setting that you describe, this should be deselected anyway. Otherwise users will still be  as annoyed when Anaconda updates Spyder and users cannot do anything about it. This does not seem to be an issue directly related to our installers or whether GH is used to check for updates.

But even if that's not the case, I think we need to respect users' choice and not try to force them to use our installers if they decided to go with Anaconda.

I'm not suggesting that we force users to do anything. We inform users (both PyPi and conda users) that a preferred installer is available; the choice is theirs. Under the current situation, Anaconda users would not even be informed of the alternative until much much later.

@ccordoba12, I restored using the defaults channel for checking for updates when Spyder is installed from that channel.

I restored using the defaults channel for checking for updates when Spyder is installed from that channel.

Thanks @mrclary! We can keep talking about how to inform Anaconda users about updates, but that's a bit ortogonal to the changes you did here.


Fix runtime error when using PyJWT v2

This fixes the following error for create_access_token and create_refresh_token:
AttributeError: 'str' object has no attribute 'decode'

This resolves #25


Global Values not available in partial of sub charts

Output of helm version:
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}
Output of kubectl version:
not relevant
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
not relevant
Problem
Global values from subchart can not be accessed from partials used in other sub chart. (Names are changed and dependencies are simplified)
I have the following logical structure of charts (all charts are stored in individual repositories):
- app             # combines all charts
-- base           # contains some global values
-- appserver      # mainly deployment
--- helpers       # helpers for creating k8s labels

The dependencies are structured as follows (successfully - as they are present in the charts folder after retrieving them via helm dependency update):
# Chart.yaml of app chart
dependencies:
- base
- appserver

# Chart.yaml of appserver chart
dependencies:
- helpers

The global values are set in the base chart as following:
# values.yaml of base chart
global:
  organisationUnit: myDepartment

And included in the appserver chart via (tried both . context and $ context - same result)
# templates/deployment.yml of appserver chart
spec:
{{ include "labels" . | indent 8 }}

which is defined in the helpers chart
# templates/_helpers.tpl of helpers chart
{{- define "labels" -}}
mylabel: {{ required ".Values.global.organisationUnit required" .Values.global.organisationUnit | quote }}
{{- end -}}

which when templating results in the following error:

$ helm template -f <values> .

install.go:178: [debug] Original chart version: ""
install.go:195: [debug] CHART PATH: <path-to-app>

Error: execution error at (<appserver>/templates/deployment.yml:28:3): .Values.global.organisationUnit required
helm.go:84: [debug] execution error at (<appserver>/templates/deployment.yml:28:3): .Values.global.organisationUnit required

where deployment.yml:28:3 points directly to the snippet of the deployment.yml posted above.
which seems strange to me, because according to the helm documentation it should work:

Because of the way globals work, both mychart/templates/configmap.yaml and mysubchart/templates/configmap.yaml should be able to access that value as {{ .Values.global.salad }}.

In the example given by the helm doc, base would be mychart and appserver would be mysubchart.
If the field is set in the values.yaml of the app chart it works just fine. I read the whole Chart template Guide but can't wrap my head around the issue in my helm charts.
Thank you for your help.

I think this is describing what you're asking and works as expected. Play with this and see if you can get the behavior you're experiencing.
base.tar.gz

thanks for the fast reply, however the example is not exactly what I was describing. I changed your chart and added a small README to explain it.
chart.zip

I don't see a difference.
/tmp/foo/chart/wanted $ helm template . --set global.organisationUnit=foo
---
# Source: app/charts/appserver/templates/deployment.yaml
baseValues: |
  global:
    organisationUnit: foo
  helpers:
    global:
      organisationUnit: foo
labels:
  mylabel: "foo"

/tmp/foo/chart/working
$ helm template . --set global.organisationUnit=foo
---
# Source: app/charts/appserver/templates/deployment.yaml
baseValues: |
  global:
    organisationUnit: foo
  helpers:
    global:
      organisationUnit: foo
labels:
  mylabel: "foo"

$ helm version
version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.19.4"}

The whole point of this issue is that contrary to the documentation, the parameters from one subchart (base) are not available in partials of other subcharts (appserver -> helpers). I don't understand how setting the parameter manually correlates to this issue.

Ah, I think I see now what you're saying. If I'm now understanding correctly you're saying that these value files:
base
globals:
  base: foo

subchart1
globals:
   subchart1: bar

subchart2
globals:
  subchart2: baz

should result in all three charts having:
globals:
  base: foo
  subchart1: bar
  subchart2: baz

So with the attached charts, each chart defines one global. All globals are printed in each template using:
global: {{ nindent 2 (toYaml .Values.global) }}

resulting in
---
# Source: base/charts/subchart1/templates/globals.yaml
global:
  base: foo
  subchart1: bar
---
# Source: base/charts/subchart2/templates/globals.yaml
global:
  base: foo
  subchart2: baz
---
# Source: base/templates/globals.yaml
global:
  base: foo

testchart.tar.gz


OrientElementIterator throws NPE (orient 2.0)

In a large project, we call OrientElement.getProperty("field1") to get a field that is an embedded-list containing 2 vertices (as shown by studio), which returns an OrientElementIterable.  When next() is called on that, we end up in an instance OrientElementIterator with graph set to null, so this line throws an NPE:
if (ODocumentInternal.getImmutableSchemaClass(currentDocument).isSubClassOf(graph.getEdgeBaseType()))

There is a related bug in OrientElement.getProperty(final String key) -- if the element.graph is null, an exception is thrown on this line:
return (T) graph.getElement(fieldValue);

I can put a check there. In your case are you using detached elements? Why the graph instance is null?

Yes they are "automatically" detached.

Hi,
Small warning, if you use internal API you have no guarantee that contract of this API will stay the same in next version of database.

@laa what do you mean?

@lvca your changes did not prevent the NPE in OrientElementIterator, so I recommend re-opening the issue.  Here's the stack on where the NPE is about to be thrown since the graph in the OrientElementIterator is null:
OrientElementIterator<T>.next() line: 73
OrientElementIterator<T>.next() line: 34
OdbVertexElement(OdbElement).getField(String) line: 289
...

My OdbVertexElement.getField() function has just used OrientVertex.getProperty() to get an OrientElementIterable of a LINKLIST field, then tried to loop over the property value which called OrientElementIterator.next().  So your changes to OrientElement don't help to prevent the NPE here.

@laa note that I'm not using any internal API, just trying to iterate over a LINKLIST property (which is returned as an OrientElementIterable)

Checked if graph == null. Note that in this case the graph element can't be retrieved, but you rather should re-attach it.

@lvca that doesn't seem right, I'm using the automatic attach/detach mode as documented in this forum post where it's stated that I never need to attach/detach.

Should I create another issue to track the automatic attach/detach mode problem?

@8forty yes, please. In this way we can be more effective. Thanks.


radar drift by running lvi_sam

Hello, when I use the eee_01 sequence to run lvi-sam, if I subscribe to "/os1_cloud_node2/points", the radar will drift significantly. If I subscribe to "/os_cloud_node_merged", no point cloud will appear in rviz, only the visual odometry. Please take a look at your side to see if such an error has occurred. If there is any improvement, I will be very grateful.

since when did we have radar...  u mean LIDAR?

Hi, merging the pointclouds should be the issue of a software package. Why do you raise an issue at this dataset site?

Hi @520sp ,
You can check out this package https://github.com/brytsknguyen/slict/blob/master/launch/run_ntuviral.launch
It has node that merges the lidar data into a single topic.

Hi @520sp ,
You can check out this package https://github.com/brytsknguyen/slict/blob/master/launch/run_ntuviral.launch
It has node that merges the lidar data into a single topic.

OK, thank you very much for your response, I will try it.

Hi @520sp ,
You can check out this package https://github.com/brytsknguyen/slict/blob/master/launch/run_ntuviral.launch
It has node that merges the lidar data into a single topic.

Hello, sir, I have tried modifying the YAML file, but there is still a significant drift. I suspect that there might be some issues in the lvi-sam algorithm that are not compatible with this dataset, and we need to modify the code.


can I use DAGAN for binary classes

Hello,
I really need your help, it will be very much appreciated as I can't solve it, unfortunately.
I have a training dataset of classes 1 and 0. 6000x50x50x3 per each class. I want to generate more data for both classes. Can I do it using DAGAN? If yes I was wondering how to define this: " Then you need to choose which classes go to each of your training, validation and test sets".
In your code snippet from load_dataset will this be correct?
x_train, x_test, x_val = self.x[:1], self.x[1:2], self.x[1:2]
x_train = x_train[:gan_training_index]
return x_train, x_test, x_val
I guess here synthetic images for only one class will be generated, what should I do to generate for another class as well?

Hello @khatiakilanava , did you solve your issue and can provide some help. I also have only two classes containing some images and have no idea how to split this dataset. Thanks


Optimize Menu and Navigation

define which menues and navigation exist

created multiple tickets out of this:
Tooltips: https://github.com/swisspost/design-system/issues/1510
Dropdown: https://github.com/swisspost/design-system/issues/1501
todos:
create tickets for

[ ] automcomplete / combobox?
[ ] menu navigation
[ ] native select…


"How to do data science" blog link does not work

The link, https://blogs.technet.microsoft.com/machinelearning/2016/03/28/how-to-do-data-science/, leads to nowhere.

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

ID: 6978a47f-18b6-5ed4-d882-01f64fbfd950
Version Independent ID: 097e6379-3a1c-24f6-de51-9212f6dbe4b4
Content: Business understanding in Team Data Science Process
Content Source: articles/machine-learning/team-data-science-process/lifecycle-business-understanding.md
Service: machine-learning
Sub-service: team-data-science-process
GitHub Login: @marktab
Microsoft Alias: tdsp

@MarkArranz
Thanks for the feedback! We are currently investigating and will update you shortly.

@marktap Hi, I saw a lot of blogs under machine learning are broken, are you moderating it? https://blogs.technet.microsoft.com/machinelearning/2014/11/25/azureml-web-service-parameters/ Please tell me if you are not the right person I should reach out.

@YutongTie-MSFT  my alias is @marktab  (not "marktap", but I've seen this a few times now)
@garyericson  could you look at this document, and edit out dead links?

@marktab Thank you for clarification, sorry for the miss-assignment.

@MarkArranz thanks for reporting, we've removed the link to the dead blog. #please-close

@MarkArranz
We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.

#sign-off


"The purchase is not in a valid state to perform the desired operation." Callback

Hello,
We're confirming receipts using SERVICE.purchases().products().acknowledge() method. But there are countless receipts that return with "The purchase is not in a valid state to perform the desired operation." when we contacted the Google Support channel, they didn't help us at all. Is there any chance that we could get a proper explanation regarding this callback?
Edit: For future Google searches; Contacted Google Support team, due to our architecture we sometimes try to acknowledge a receipt more than once. It turns out (for consumable in app purchases) trying to acknowledge a receipt that has already been acknowledged returns with this callback.

Hi @umityayla,
This sounds like a question for the service team. Which API are you using?

We use the Play Services API. And yes, you are definetily right, but we got so little help from the support team that they even misread(?) the callback string and sent us the link to a Stackoverflow question regarding a SQL Server issue.

Hi,
Just to confirm, you're using the Google Play Developer API (https://developers.google.com/android-publisher) and reached out via one of the channels listed at https://support.google.com/googleplay/android-developer/answer/7218994?

Yes, unfortunately that's correct.

Any update on the issue? @busunkim96

per the message in the issue ("The purchase is not in a valid state to perform the desired operation."), they can try doing a "get" first to see if "acknowledge" is a valid transition.

The engineer says they'd need a purchaseToken to do any further debugging. I think you can open an issue here and they will take a look.

Thank you for your help and have a nice day!

Sorry for not posting a follow up. Contacted Google through issue tracker and their answer was the following way;

This may happen when you're trying to acknowledge or consume an item that is pending (not this case) or already marked acknowledged or consumed (likely this case).


fix: [SEI-6375]: Update documentation with new theme based custom-cicd endpoint

Update documentation with new theme based custom-cicd endpoint
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[x] Successful preview build.
[x] Code owner review.
[x] No merge conflicts.
[x] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://662a738c30b8e807ceb471ce--harness-developer.netlify.app


systemctl --user not working in KDE

This is the same issue as #11480, but for KDE 4.
$ systemctl --user
Failed to list units: Process org.freedesktop.systemd1 exited with status 1

Tested in 15.09 and unstable.

Actually, I'm seeing this in Gnome 3 as well.

This works in KDE 5

This problem has been intermittent, and I'm starting to think it may be due to a bad service I'm working on.

@chris-martin can this be closed?

I no longer really remember what it was about, so I suppose so.

Yeah, it is due to a bad service on boot.
After removing all files in .config/systemd/user/default.target.wants, systemctl --user works again.


Update users.json

add merox.dev website

Closing because the PR messes up other users... I will add manually


Only one channel in Plex

I have many channel in tvheadend but when i add Antennas tuner in Plex it only see 1 channel.
Any idea what cause this??

Did you find a solution to quickly map channel numbers to iptv/m3u sources?

I think I might have the same issue. Can you explain in more detail how you fixed it.


Uses expired artifacts

When it searches for artifacts, it yields 2 results. The 1st result is not expired and the 2nd result is expired. It attempts to download the 2nd result, which results in "Artifact has expired" error.

Hi! Thank you for your report.
You are using an outdated version of foundry-gas-diff: 3.7
Newer versions are available, introducing a fix to the issue you raised. Please use for example the latest version: 3.13.2
Closing this!


Green notifications: Make them nicer green

Every time I see this Im like 🤮

Can we have it in a nice green? Like "submit new issue green". That khaki green is just weird.

might be good to reuse https://www.figma.com/design/JXNtryaNYhY0XJNArzvPQx/Handoff?node-id=10766-13026&t=L9j6UCt5VCWcT3R0-0


Keyboard not updating

I just tried Colore by following the Getting started page and I can't get the keyboard to update, it just clear and fade back to my synapse configuration, here is my config:
windows 10 x64
.net 5.5.1
colore 6.0.0-unstable0240
synapse 3.3.1128.112711
chroma sdk 2.22.3
testing on a BlackWidow chroma v2
And here is my code :
using System;
using System.Windows.Forms;
using Colore;
using ColoreColor = Colore.Data.Color;

namespace BeatChroma
{
    public partial class Form1 : Form
    {
        IChroma chroma;

        public Form1()
        {
            InitializeComponent();

        }

        private async void testColor_Click(object sender, EventArgs e)
        {
            chroma = await ColoreProvider.CreateNativeAsync();
            await chroma.SetAllAsync(ColoreColor.Red);
        }
    }
}

Nevermind, I found a way to make it work. I just had to initialize it properly using the InitializeAsync function.
using System;
using System.Windows.Forms;
using Colore;
using Colore.Data;
using Colore.Effects.Keyboard;
using ColoreColor = Colore.Data.Color;
using Key = Colore.Effects.Keyboard.Key;

namespace BeatChroma
{
    public partial class Form1 : Form
    {
        IChroma chroma;
        IKeyboard keyboard;

        public Form1()
        {
            InitializeComponent();
            InitChroma();
        }

        private async void InitChroma()
        {
            chroma = await ColoreProvider.CreateNativeAsync();
            await chroma.InitializeAsync(new AppInfo("Beat Chroma","A razer chroma rhythm game.","Ikeiwa","none",Category.Application));
            chroma.Register(Handle);
            keyboard = chroma.Keyboard;
        }

        private async void testColor_Click(object sender, EventArgs e)
        {
            var effect = KeyboardCustom.Create();
            effect[Key.A] = ColoreColor.Red;
            await keyboard.SetCustomAsync(effect);
        }
    }
}


[core] Action meta objects are different

Description
The meta object (third argument) for action is currently different for different actions.
I was trying to use action payloads to parameterize a send action, but the send action doesn't seem to have access to action in the actionMeta object (third argument):
awardPoints: assign({
  totalPoints: (ctx, event, { action }) => ctx.totalPoints + action.points
}),
// doesn't work
sendPointsUpdate: send((ctx, event, { action }) => ({
  type: 'UPDATE_POINTS',
  points: action.points // action is undefined
}))

Expected Result
I would expect all actions get the same meta object, or at least all have the action property in the meta object.
Actual Result
assign gets {state, action, _event}, while send and pure (haven't checked other actions) just get {_event} for it's third argument.
Related Issues
#2421
#2306
Reproduction

Codesandbox
In the codesandbox, the assign actions work fine, but the send action breaks because it doesn't have the action property.

Additional context
v4.23.0

@davidkpiano This is the issue I was originally interested in^^ Can you confirm that it does indeed make sense to wait until v5.0 to take another look at the code for this?
Probably will make the solution much cleaner as well as the code looked more modular in the next branch at the first glance.

This has been fixed in xstate@beta