Distributed binary files

Hello,
I've noticed that now you ship some random binary files under lib folder. Could you not do that and somehow depend on win32 or something like that module?

To be clear: these are not random files, it is a ntdll library. These files were added quite long ago (#45). More details why these files are needed can be found here.
As far as I can see, it is the best way to get the actual version, because other functions from WinAPI are either deprecated or can return incorrect information in some cases. Though I'm not a Windows expert and would like to know if there is a better solution.
I suppose GetProcAddress can be used to obtain the address to this function. I'm going to try it.

I have published 2.0.1 version which includes fix for this issue.


Support PHP 5.4.0 for version 0.2.0

Hello,
can you please change the guzzlehttp/guzzle package in  your composer version 0.2.0?
guzzlehttp/guzzle version 6.* doesn't support PHP 5.4.0. But version 5.* does.
So can you change it to "guzzlehttp/guzzle": "^5.3.1",
and update the tag version to 0.2.1 ?
Thank for your help

@ivankristianto sorry for delay, makes the sence to me. Feel free to make PR and I will merge it.


DAS APIM integration

DAS APIM integration related artifacts. Please review and merge.
Thanks

Since this is an already developed capp and the relevant sources are available in the provided blog url, we will not merge this to wso2-qa-artifacts location as a duplicate. You can submit a README on how to use the artifact with the correct and all required instructions.
However you can submit a customized source of this which may be covering a new scenario which is not already covered.


Test "initial peer discovery" failed

Mode : NATIVE
branch : master_1327
commit : 5fa2c64
server - https://gist.github.com/evabishchevich/b5ce147c6ca0a1566d520117fa54b167
6p - https://gist.github.com/evabishchevich/eda2f55bb92501ba2555ae17470dda2e
6p - https://gist.github.com/evabishchevich/8d878a0e9f20dedfb8ad37b5e6d25446
s7  - https://gist.github.com/evabishchevich/821f5d7984a43c4981129868d4e8cd61

6p - https://gist.github.com/evabishchevich/c5d7529384e829da30e6dddc7c45828c
6p - https://gist.github.com/evabishchevich/b1b301a9f8dd1c13389b5ae9f1761ea5
s7 - https://gist.github.com/evabishchevich/362a7a543be44930834a2a73c0882575

6p - https://gist.github.com/evabishchevich/6774b0237f802292e8a085c20b008264
6p - https://gist.github.com/evabishchevich/435947cb8a8a957e4c5789e01f69ba6a
s7 - https://gist.github.com/evabishchevich/84fd1c7fe5054813898b97fcd0129c79

We got the same peer twice during discovery
Received:
10-21 16:27:05.568 2468-2540/com.test.thalitest I/jxcore-log: Peer: "24:00:BA:F9:9A:9F-58"
10-21 16:27:05.568 2468-2540/com.test.thalitest I/jxcore-log: Peer: "24:00:BA:F9:9A:9F-59"
10-21 16:27:05.569 2468-2540/com.test.thalitest I/jxcore-log: Peer: "60:AF:6D:7F:A5:22-116"

Run only 1 file
6p - https://gist.github.com/evabishchevich/2163f6202c484f32605d9480bc8adf27
6p - https://gist.github.com/evabishchevich/bce452daa6b2c0ea594089d09179deb5
s6 - https://gist.github.com/evabishchevich/b6ffe04738a1f7e4ad421674f1e7bcf8

6p:
https://gist.github.com/evabishchevich/40c50a5378b53d6edf248dd2b8ce4b43
6p:
https://gist.github.com/evabishchevich/bc3a6ff65dd4059fabc69dae86aae281

6p:
https://gist.githubusercontent.com/evabishchevich/3ea248a2e2deaafac317cbc21284eab4/raw/5a921b0e996bad5752e03320185c867314aaf28f/gistfile1.txt
6p:
https://gist.githubusercontent.com/evabishchevich/757720d9edc0f129700a9f3a2196e2b6/raw/2c8872700f4504419b9717a9ccf80093a36a3c96/gistfile1.txt

6p 1:
https://gist.github.com/evabishchevich/95ac52fe18825fb391a715211a4c79ee
6p 2:
https://gist.github.com/evabishchevich/f80488447fa0d7618c9bfef342e464eb

Tried to flush scanner before stop but still get the failed test
6p:
https://gist.github.com/evabishchevich/df245b0203c7316cfd8a2692d5395a2a
6p:
https://gist.github.com/evabishchevich/947a6f4e47ae20ffe7b2c200ff14f251


[Bug] stg_hubspot__contact:  Duplication between PROPERTY_CREATEDATE and PROPERTY_CREATED_AT

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the issue
Hello,
I have an issue with a duplicate column, when running dbt run -s +stg_hubspot_contact I have the following error

I have   hubspot__pass_through_all_columns: true
I had a closer look and it seems that the properties: PROPERTY_CREATEDATE and PROPERTY_CREATED_AT are named after prefix removal PROPERTY_CREATED_AT.
I think this is because in get_contact_columns() macro
 the PROPERTY_CREATEDATE is mapped to created_at:
   {"name": "property_createdate", "datatype": dbt.type_timestamp(), "alias": "created_at"},
The issue comes from the fact that the column PROPERTY_CREATED_AT is not excluded in the exclude parameter of stg_hubspot__contact which only returns these columns:
['_FIVETRAN_DELETED', '_FIVETRAN_SYNCED', 'ID', 'PROPERTY_HS_CALCULATED_MERGED_VIDS', 'PROPERTY_EMAIL', 'PROPERTY_COMPANY', 'PROPERTY_FIRSTNAME', 'PROPERTY_LASTNAME', 'PROPERTY_CREATEDATE', 'PROPERTY_JOBTITLE', 'PROPERTY_ANNUALREVENUE']

(so PROPERTY_CREATEDATE and not PROPERTY_CREATED_AT)
And then obviously PROPERTY_CREATED_AT is renamed as created_at and this is causing the issue.
Hope I was clear enough
Have a great day
Relevant error log or model output
see above

Expected behavior
Either exclude PROPERTY_CREATED_AT by default to avoid this issue or change  PROPERTY_CREATEDATE mapping
I think the PROPERTY_ + aliases defined in  get_contact_columns() macro
 should be excluded as well.
dbt Project configurations
dbt hubspot source 0.12.0
dbt 1.4.4
Package versions
dbt hubspot source 0.12.0
dbt 1.4.4
What database are you using dbt with?
snowflake
dbt Version
dbt 1.4.4
Additional Context
maybe we will open a PR
Are you willing to open a PR to help address this issue?

[ ] Yes.
[X] Yes, but I will need assistance and will schedule time during our office hours for guidance
[ ] No.

I created this attached PR to showcase the issue but I guess there is better way to fix it

Hi @moreaupascal56 thanks for flagging this issue! I have started taking a look at this and could use a little more information. In your source contact table, are you seeing both PROPERTY_CREATEDATE and PROPERTY_CREATED_AT  columns, or only PROPERTY_CREATED_AT?

Hey thanks !  we have both columns in the source table. I don't know
however if this is a custom property we made on hubspot or a default one
from hubspot
Le mer. 11 oct. 2023, 21:27, fivetran-catfritz @.***> a
écrit :

Hi @moreaupascal56 https://github.com/moreaupascal56 thanks for
flagging this issue! I have started taking a look at this and could use a
little more information. In your source contact table, are you seeing
both PROPERTY_CREATEDATE and PROPERTY_CREATED_AT columns, or only
PROPERTY_CREATED_AT?
—
Reply to this email directly, view it on GitHub
https://github.com/fivetran/dbt_hubspot_source/issues/117#issuecomment-1758393929,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMENIP5JFLPE2SH7NL5PJZ3X63XLJANCNFSM6AAAAAA53UOLDM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@moreaupascal56 Thank you much for the info! I will discuss this with our internal team.

@moreaupascal56 Thanks again for identifying the issue areas! I talked with the team, and we are thinking to update the alias you identified in the get_contact_columns() macro to be create_date. This way we're staying closer to the source naming, and you could still utilize the property_created_at field if you wish. We didn't want to remove user custom fields just because of the way we built the package. What are your thoughts?

Thanks @moreaupascal56! We plan to bring this into the next update for this package. We'll also let you know when we have a better sense of the timing.

Sounds great, thanks for the update!
Le mar. 17 oct. 2023, 20:29, fivetran-catfritz @.***> a
écrit :

Thanks @moreaupascal56 https://github.com/moreaupascal56! We plan to
bring this into the next update for this package. We'll also let you know
when we have a better sense of the timing.
—
Reply to this email directly, view it on GitHub
https://github.com/fivetran/dbt_hubspot_source/issues/117#issuecomment-1766948758,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMENIPYXXG3DRWYEFRPLZXDX73FANAVCNFSM6AAAAAA53UOLDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRWHE2DQNZVHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

this fix is in the latest release of the package!
if you're using the transform package, v0.14.0 will include this change

hi there,
Looks good I am not able to test on prod rn because I switched jobs but this will help the team for sure :)
Thanks a lot and have a great day ! See you!!
Pascal


docs: typos #6407

closes #6407

v14.12.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Update LR Trie API

Adds PATRICIA to the existing Merkle Tree. Part of the heavy lifting for the implementation was forked from https://github.com/carver/eth-trie.rs however there's gotchas that need to be addressed later on.
The library as defined in lr_trie will eventually be moved and refactored within its a separate repository at a later time.

@vrrbmk Agreed, that'll be refactored in subsequent iterations


Rename "Enabling Unsafe Sysctls" section

Section called "Enabling Unsafe Sysctls" sounds dangerous, when trying to tell someone that net.ipv4.ip_unprivileged_port_start is considered a safe sysctl in current Kubernetes versions.
The generic explanation of "safe and unsafe sysctls" should be renamed more generic, and later subsection about how to actually enable unsafes can retain the pre-existing section name.

Should I squash the commits?

/approve

/lgtm


No longer working?

It seems support for sensors has been moved to a paid version of Cesium (Ion SDK) and the original opensource version of these utils has been moved to a private repo, will these plugins still work in the latest versions of Cesium?
I am not seeing any hits for these Entity rendering functions (conicSensor, customPatternSensor, and rectangularSensor.) in CesiumJS https://github.com/search?q=repo%3ACesiumGS%2Fcesium+rectangularSensor&type=code
Please let me know, thanks

Hi Dave, This code is a fork of the sensors in cesium previous to the move to the paid version i.e. Cesium Ion. They can be used in cesiumJS without Ion SDK. Nevertheless, they still need to be aligned to webgl 2 for the very latest versions (part of the work on the shaders is already done).

Shaders are aligned from version 1.0 are aligned to work with the latest cesium versions


Catkin build failure while cloning into a catkin workspace

Hi,
I am trying to install MVSim as a ROS package. Because of that, I created a new catkin workspace and sourced "/opt/ros/noetic/setup.bash". But I got a catkin build error as you can see in below:
../../apply-protol.sh: line 7: /home/username/catkin_ws/build/mvsim/venv/bin/activate: No such file or directory
make[2]: *** [modules/msgs/CMakeFiles/mvsim-msgs.dir/build.make:915: modules/msgs/lib/libmvsim-msgs.so.0.8.1] Error 1
make[2]: *** Deleting file 'modules/msgs/lib/libmvsim-msgs.so.0.8.1'
make[1]: *** [CMakeFiles/Makefile2:2249: modules/msgs/CMakeFiles/mvsim-msgs.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
I googled it for solving but I cannot find anything useful. What should I do?
Thanks in advance.

Have you tried building with colcon instead? colcon is used for ROS 2, but it works great for ROS1 too. Just clone as usual in a clean workspace, and run colcon build --symlink-install instead of the catkin command.
If you can confirm it works for you with colcon but fails with catkin, I might try to fix it, but as long as we normally build everything with colcon nowadays it wouldn't be a top priority.

PS: You can also just install it with sudo apt install ros-noetic-mvsim if you want to "dig" into the sources...

When I tried to setup MVSim with sudo apt install ros-noetic-mvsim, apt said to me that it would install these packages (libxxf86vm-dev python3-venv python3.8-venv ros-noetic-mrpt2 ros-noetic-mvsim x11proto-xf86vidmode-dev) as well. So I installed these packages without ros-noetic-mvsim and after that I tried to rebuild with catkin. Now I am getting a different error as you can see in below:
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/exception.cpp: In member function ‘virtual const char* PyCallBack_std_exception::what() const’:
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/exception.cpp:37:30: error: ‘override_caster_t’ in namespace ‘pybind11::detail’ does not name a template type; did you mean ‘overload_caster_t’?
37 |     static pybind11::detail::override_caster_t<const char*> caster;
|                              ^~~~~~~~~~~~~~~~~
|                              overload_caster_t
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/exception.cpp:40:20: error: ‘caster’ was not declared in this scope
40 |      std::move(o), caster);
|                    ^~~~~~
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/stdexcept.cpp: In member function ‘virtual const char* PyCallBack_std_runtime_error::what() const’:
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/stdexcept.cpp:39:30: error: ‘override_caster_t’ in namespace ‘pybind11::detail’ does not name a template type; did you mean ‘overload_caster_t’?
39 |     static pybind11::detail::override_caster_t<const char*> caster;
|                              ^~~~~~~~~~~~~~~~~
|                              overload_caster_t
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/std/stdexcept.cpp:42:20: error: ‘caster’ was not declared in this scope
42 |      std::move(o), caster);
|                    ^~~~~~
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/mvsim/Comms/common.cpp: In member function ‘virtual const char* PyCallBack_mvsim_UnexpectedMessageException::what() const’:
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/mvsim/Comms/common.cpp:40:30: error: ‘override_caster_t’ in namespace ‘pybind11::detail’ does not name a template type; did you mean ‘overload_caster_t’?
40 |     static pybind11::detail::override_caster_t<const char*> caster;
|                              ^~~~~~~~~~~~~~~~~
|                              overload_caster_t
/home/username/catkin_ws/src/mvsim/modules/comms/python/generated-sources-pybind/mvsim/Comms/common.cpp:43:20: error: ‘caster’ was not declared in this scope
43 |      std::move(o), caster);
|                    ^~~~~~
make[2]: *** [modules/comms/CMakeFiles/pymvsim_comms.dir/build.make:102: modules/comms/CMakeFiles/pymvsim_comms.dir/python/generated-sources-pybind/std/exception.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [modules/comms/CMakeFiles/pymvsim_comms.dir/build.make:76: modules/comms/CMakeFiles/pymvsim_comms.dir/python/generated-sources-pybind/mvsim/Comms/common.cpp.o] Error 1
make[2]: *** [modules/comms/CMakeFiles/pymvsim_comms.dir/build.make:115: modules/comms/CMakeFiles/pymvsim_comms.dir/python/generated-sources-pybind/std/stdexcept.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2195: modules/comms/CMakeFiles/pymvsim_comms.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
In file included from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/format.h:12,
from /opt/ros/noetic/include/mrpt/math/include/mrpt/math/TPoint2D.h:12,
from /home/username/catkin_ws/src/mvsim/modules/simulator/include/mvsim/basic_types.h:13,
from /home/username/catkin_ws/src/mvsim/modules/simulator/include/mvsim/ClassFactory.h:11,
from /home/username/catkin_ws/src/mvsim/modules/simulator/include/mvsim/FrictionModels/FrictionBase.h:12,
from /home/username/catkin_ws/src/mvsim/modules/simulator/include/mvsim/FrictionModels/DefaultFriction.h:13,
from /home/username/catkin_ws/src/mvsim/modules/simulator/src/FrictionModels/FrictionBase.cpp:10:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/FrictionModels/FrictionBase.cpp:21:1: note: #pragma message: TODO: When each wheel will have its own friction - remove logger_.
21 | MRPT_TODO("When each wheel will have its own friction - remove logger_.")
| ^~~~~~~~~
In file included from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/format.h:12,
from /opt/ros/noetic/include/mrpt/math/include/mrpt/math/TPoint2D.h:12,
from /opt/ros/noetic/include/mrpt/math/include/mrpt/math/TPose2D.h:12,
from /home/username/catkin_ws/src/mvsim/modules/simulator/src/VehicleBase.cpp:11:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/VehicleBase.cpp: In member function ‘virtual void mvsim::VehicleBase::simul_pre_timestep(const mvsim::TSimulContext&)’:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/VehicleBase.cpp:413:2: note: #pragma message: TODO: Use chassis cog point
413 |  MRPT_TODO("Use chassis cog point");
|  ^~~~~~~~~
In file included from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/exceptions.h:14,
from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/safe_pointers.h:11,
from /opt/ros/noetic/include/mrpt/maps/include/mrpt/maps/CPointsMap.h:15,
from /opt/ros/noetic/include/mrpt/maps/include/mrpt/maps/CSimplePointsMap.h:11,
from /home/username/catkin_ws/src/mvsim/modules/simulator/src/Sensors/Lidar3D.cpp:11:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/Sensors/Lidar3D.cpp:32:1: note: #pragma message: TODO: Also store obs as CObservationRotatingScan?
32 | MRPT_TODO("Also store obs as CObservationRotatingScan?")
| ^~~~~~~~~
/home/username/catkin_ws/src/mvsim/modules/simulator/src/Sensors/Lidar3D.cpp: In member function ‘virtual void mvsim::Lidar3D::internalGuiUpdate(mrpt::optional_refmrpt::opengl::Scene&, mrpt::optional_refmrpt::opengl::Scene&, bool)’:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/Sensors/Lidar3D.cpp:116:3: note: #pragma message: TODO: render 3D lidar FOV
116 |   MRPT_TODO("render 3D lidar FOV");
|   ^~~~~~~~~
In file included from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/exceptions.h:14,
from /opt/ros/noetic/include/mrpt/core/include/mrpt/core/safe_pointers.h:11,
from /opt/ros/noetic/include/mrpt/opengl/include/mrpt/opengl/Viewport.h:12,
from /opt/ros/noetic/include/mrpt/opengl/include/mrpt/opengl/COpenGLViewport.h:11,
from /opt/ros/noetic/include/mrpt/opengl/include/mrpt/opengl/COpenGLScene.h:11,
from /home/username/catkin_ws/src/mvsim/modules/simulator/src/WorldElements/ElevationMap.cpp:10:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/WorldElements/ElevationMap.cpp: In member function ‘virtual void mvsim::ElevationMap::loadConfigFrom(const rapidxml::xml_node*)’:
/home/username/catkin_ws/src/mvsim/modules/simulator/src/WorldElements/ElevationMap.cpp:98:3: note: #pragma message: TODO: Imgs or txt matrix
98 |   MRPT_TODO("Imgs or txt matrix")
|   ^~~~~~~~~
make: *** [Makefile:141: all] Error 2
I gave that error when the build process is %90. What should I do?
PS: I installed with apt, I am using it well. I am writing this to let you know and maybe other people will benefit from it.

That "overload_caster_t" error is due to a mismatch in the expected version of pybind11... which I think was handled automatically whatever version you used, but it seems it fails in your case for some reason (?).
Anyhow, if you don't need the MVSIM Python API (you can still use the regular ROS Python API), just go to the "catkin_ws" build directory for mvsim, and run cmake . -DMVSIM_WITH_PYTHON=OFF to disable that feature, then try continue building.

It worked that building with cmake argument -DMVSIM_WITH_PYTHON=OFF. Thank you very much for your interest.
Also, I congratulate you for developing such a useful application. Really easy to use and great performance.

Awesome! 👍


Cant reproduce image on project website

Use default config with num_steps =2, ensemble size =4

@sdbds They used Spectral color map

@sdbds They used Spectral color map. The depth map also has to be inverted iirc

It wasn't the colormaps that was the problem, and the details checked out a lot

Similar problem


Hosted data feeds appear to be having issues

It seems that both https://path.transitdata.nyc/gtfsrt and https://path2.transitdata.nyc/gtfsrt feeds are having intermittent issues right now (either returning incomplete or empty proto data). Running the application locally still works with the --use_panynj_api option. @jamespfennell when you have time, could you see if there are any obvious issues in the logs? If the issue is resolved by the time you check, please feel free to close.
Note also that I am seeing some incomplete data on the path-data demo site as well (https://jsfiddle.net/qkp7g8ze/embedded/result/), but I would expect the PANYNJ API to be working (assuming that is what is running on path2).

Hey, I don't have time to debug fully right now but I'm definitely seeing in my monitoring that both applications have been crashing throughout the day. It seems to have started today. Unfortunately my deployment environment is such that I lose the logs when the Docker container crashes (oops), so I don't have log lines from the crashes. I can fix the logging setup to capture the logs externally and see if I can capture a crash.
Other services running on my VM don't seem affected, and the VM logging (e.g RAM usage) look totally normal, so I don't think it's a problem with the VM I'm running this on.

Hey @jamespfennell - one other issue I am seeing is that I think both https://path.transitdata.nyc/ and https://path2.transitdata.nyc/ seem to be returning the same data now. My guess is that both are using the mrazza API. It's possible I am doing something incorrect on my end, but is it possible there is a config issue here on the server?

Woops! My reverse proxy config was pointing both URLs to the same deployment of this app. Just fixed it!

I guess it would be nice if the html status page (https://path.transitdata.nyc/) showed which flags are being used? Sorry for the hassle!

Thanks for taking a look and the quick fix!
Also, feel free to close this issue if things look OK on your end. I think the services are running more reliably now from my end (aside from the known intermittent issues with the mrazza API, which I think is a separate issue).
I wasn't sure if you're using this to track your investigation into the previous crashes and/or the logging improvements you mentioned, which I why I haven't closed it myself.


npm install npm@version not working on the mac image

It would be cool to optionally specify which version of npm is used regardless of the node version (use case: I am using AWS Lambda with the 8.10 runtime, but I want to use<EMAIL_ADDRESS>

This is a fair suggestion, and one I've given some thought to, but I think we're probably not going to do this. We've had some discussion surrounding this, but in general, we view the setup-* actions as actions to setup the tool but not the ecosystem around it - so the setup actions should work like node's installer executable does. Npm is a little bit of a tricky case because the installer packages npm with Node, so its not clear where the tool ends and the ecosystem starts. For now, though, we've decided to adopt the same behavior as the installer executable and not install different versions of npm and/or Yarn.
FWIW, I'm also a little less worried about this one because its relatively easy to fix - just add a step run: npm install --global<EMAIL_ADDRESS>Again, this feels like the line that the Node installer draws.
Does that make sense/seem reasonable?

It is reasonable and the first thing I tried, but it seemed like the global install worked but was not effective (so my next steps that ran still used the old version).
Maybe I did something wrong, but getting npm@6 using node 8.10 didn't work, like:
npm i -g npm@6
npm ci

failed with 'ci' not being a known command (it looked like npm@5 was still the one in effect)

Huh, that's weird. If that's not working, we definitely should fix that!
With that said, I'm not able to reproduce. Could you try running npm -v before/after doing the global install and see if we're getting the correct version of npm that way?
Also, if your repo is public would you mind sharing it?

Here's an example:
https://github.com/dougmoscrop/serverless-plugin-log-subscription/pull/9/checks?check_run_id=195597827
Is it because I am doing this in separate steps?

If there was a setup-npm or npm-version input, it would just run the command above that appears to be failing on the mac for some reason.  Steps do run out of process but it should be fine since that should change symlinks.
We don't have an npm-version property since (1) installing a node version by querying their json, happens to carry a version of npm and (2) if the version specified is different then it would just do npm -i npm@ver (so why not just do that)?
So I think the action item is to figure out why npm -i is not working on the mac image.

Hello everyone. Sorry for the late response. I've tried to reproduce the issue, but it looks like nodejs version setting up by the action works as expected. If you use nodejs version from hosted images you can try to upgrade npm version with this command: npm i -g npm --prefix=/usr/local/opt/node@14
For now I'm closing the issue. We have similar issue with adding npm-version input. If you have any concerns feel free to contact us.


Upgrade Quorum to v2.1.1

Hi,
Please upgrade Quorum to v2.1.1.
v2.1.1 fixes a major bug: #517 Fix consensus on private contract failure
This bug causes a bad block every time a private transaction is reverted and makes local development difficult.
Thank you!

Looks like this change has been made in the latest release. Thanks!


Is express dead?

Is the express dead? Six months without updates, the last commit in version 5 is 2 years ago. What is going on? How can I help you? Do you have plans to release 5?

No.we even have TC meeting you can view on our web site to understand what is going on. We have many repos and there is work throughout.

Note that we did skip a couple TC meetings due to US holidays and some of us were at the Node.js Interactive conference. I even talked about the state of Express as an opening keynote :)

Very good news! Many thanks, I'll see the meetings =)

Let me fetch the link to my talk, which I think may be the best place to start.

Ah, here are the links: https://github.com/expressjs/discussions/issues/47

Nice!!! Thanks!!! =D

I spent quite a while googling for the state of express, and express 5.0 before landing on this issue. The video State of the Union: Express from Node.js Interactive in Dec 2016 was exactly what I was looking for - and covers everything in great detail. Thank you!
I know this sort of comment isn't that helpful in everyone's inbox, however I'm hoping it makes this video easier to find because I think it's important for the express community to hear about the new governance and that you're looking for more contributions. I personally was very interested in the router being a separate module & the GitHub project structure.
Mayhaps a link on the website and/or changing the title of this thread to be something more positive would be beneficial? Just a thought 😁

I absolutely agree :) ! I thought there was an issue on the website repository to get them added, but I guess it's just in the discussions repo and talked about on one of the TC meetings. I just make sure to ping in https://github.com/expressjs/discussions/issues/47#issuecomment-274508626 and will make a PR to the website repo soon if no one else does before I get to it :D


--Implementation of Nvidia's HBAO effect (soft shadows in corners and crevices) via Magnum

Motivation and Context
This PR implements Nvidia's HBAO as per the shaders found here but using Magnum's graphics framework.  This work was built from, and compared against, a reference implementation of the Nvidia sample code using Nvidia's graphics framework that was integrated into Habitat-Sim in this WIP PR.
Both Classic and Cache-Aware implementations are available, as well as Perpective and Orthographic sensor support (driven by the projection matrix configuration of the owning visual sensor).
TODO for This PR :

Update test images to match the working effect.
Gate test so that it does not attempt to run in WebGL builds not necessary

TODO Next PR/Future Work :

Configuration support to allow easy customization of effect
Add MSAA support
Validate effect when accessed via Habitat-Lab

Demonstration of with/without effect via CacheAware algorithm, both Perspective and Orthographic projection.
https://github.com/facebookresearch/habitat-sim/assets/1093953/b5908c40-fc34-41aa-9ef5-073f09c44a83

How Has This Been Tested
New C++ tests to verify integrity of effect; existing c++ and python tests pass

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[x] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Pretty cool! Nice job!

Note : currently the test images are out of date but the test is still passing, so this needs to be investigated.

Did you have a change to measure rendering performance with/without HBAO?

Not yet, I am going to investigate that today.


Fix/client/Handling undefined of houseId

Describe your changes

Changed not to throw an error in the auth store because, on the main page, we need to show a guide to create a house!

Issue
URL
http://localhost:3000/ -> No errors
http://localhost:3000/rules -> Show errors
Screenshot (if you made the UI)
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings and no errors

Duplicate


Error with gradio

I am new to the application. I am trying to run it on windows 11, and I get the following error with gradio:
C:\temp\video2slides-main>gradio app.py
Watching: 'C:\temp\video2slides-main' 'C:\temp\video2slides-main'
Traceback (most recent call last):
File "C:\temp\video2slides-main\app.py", line 226, in
demo.queue(concurrency_count=4).launch()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\shris\AppData\Local\Programs\Python\Python312\Lib\site-packages\gradio\blocks.py", line 1882, in queue
raise DeprecationWarning(
DeprecationWarning: concurrency_count has been deprecated. Set the concurrency_limit directly on event listeners e.g. btn.click(fn, ..., concurrency_limit=10) or gr.Interface(concurrency_limit=10). If necessary, the total number of workers can be configured via max_threads in launch().

Hi, the issue has been fixed for gradio4

Do you mean I need to get the latest of gradio? Or last of video2slides?

Please download the latest code of video2slides to fix the issue


feat(ComponentExample): add React demos for CodeSandbox

Refs #803. Contains experimental version of the CodeSandbox example found at:
https://github.com/carbon-design-system/carbon-website/issues/803#issuecomment-458336202
The code contains built version of experimental production CSS build. Once v10 is shipped, we can switch it back to UNPKG link.
Changelog
New

Codesandbox code for multi select, inline multi select, filterable multi select and combo box. All has experimental style.

This looks great! Wondering though if we need this in addition to the other work you did in #803?

@alisonjoseph This and #1059 tackles the same problem in different ways. I created both because I was not sure whether the team wants to go. Closing this for now as the team seems to prefer #1059, but please let me know in case otherwise - Thanks!


can I use the Spring @Transactional

can I use the Spring @Transactional ??

Speedment does not support @Transactional but supports transactions as described here: https://speedment.github.io/speedment-doc/crud.html#transactions
It would be cool if it did though.  You could write a support method that takes a Runnable and does everything in the run() method in a transaction.

ok ths


docs: add Commits section to CONTRIBUTING.md

Issue #, if available:
Description of changes:
Add a "Commits" section to contributing guidelines with information about conventional commits. Additionally, add guidance around providing subtypes to conventional commit messages, especially when writing commits that are specific to one platform or another.
Testing done:

[x] I've reviewed the guidance in CONTRIBUTING.md

License Acceptance
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Looks good. I know we have a PR title check for conventional commits + a DCO check as well. Do you think we need to mention those?

I think this should be sufficient - DCO is already mentioned in contributing guidelines. As for PR title check, if the PR author has followed conventional commits in their commits, then the pre-populated PR title will be the commit message and pass those checks.

Do you think we should follow up by adding some custom rules to release-please.yaml to make different platforms have their own sections in the release notes?

I considered that, but scopes are not included in the parsing spec https://github.com/commitizen/conventional-commit-types/blob/master/index.spec.json . Ideally we could define our rules as something like the below but it is not supported :/
changelog-types: >
            [
              {
                "type":"feat",
                "scope":"",
                "section":"Features",
                "hidden":false
              },
              {
                "type":"feat",
                "scope":"macOS",
                "section":"Features",
                "hidden":false
              },
              {
                "type":"feat",
                "scope":"Windows",
                "section":"Features",
                "hidden":false
              },
              ...
             ]

(also I updated to change <subtype> -> <scope> in our docs in latest rev)
As is without new custom rules, a commit feat(windows): the feature would appear in release notes like:
Features

* windows: the feature
* some other feature w/o a scope tag

Do you think we should follow up by adding some custom rules to release-please.yaml to make different platforms have their own sections in the release notes?

I considered that, but scopes are not included in the parsing spec https://github.com/commitizen/conventional-commit-types/blob/master/index.spec.json . Ideally we could define our rules as something like the below but it is not supported :/
changelog-types: >
            [
              {
                "type":"feat",
                "scope":"",
                "section":"Features",
                "hidden":false
              },
              {
                "type":"feat",
                "scope":"macOS",
                "section":"Features",
                "hidden":false
              },
              {
                "type":"feat",
                "scope":"Windows",
                "section":"Features",
                "hidden":false
              },
              ...
             ]

(also I updated to change <subtype> -> <scope> in our docs in latest rev)
As is without new custom rules, a commit feat(windows): the feature would appear in release notes like:
Features

* windows: the feature
* some other feature w/o a scope tag

Cool, thanks for the info!


In-place sed calls fail in orbstack but work fine in Docker Desktop

Describe the bug
I use VSCode Remote Containers - with Docker containers - for developing the Dokku project. When the container starts up, there are some make targets that run, several of which call sed with in-place replacement. These calls fail with latest Orbstack, but appear to work fine with Docker Desktop. Additionally, I get permission failures when restarting sshd within the container due to perms being too open for some ssh keys in /etc/ssh (the errors don't occur in Docker Desktop).
# example call
$ cd /etc/ssh ; sed --in-place "s/^#Port 22/Port 22/g" sshd_config ; ls sed* ; cat sed*
sed: couldn't open temporary file ./sedeuPh5I: Permission denied
# file is listed
sedeuPh5I
# file somehow doesn't exist?
cat: sedeuPh5I: No such file or directory

From the above, it seems like somehow there is a race condition in writing files?
Both of these issues basically make it impossible to bootstrap a VSCode remote container environment for Dokku, and possibly break permissions elsewhere in the codebase. I use in-place sed all over the place, but the latter permission issues for untouched ssh keys seems suspicious.
To Reproduce
Steps to reproduce the behavior:

Clone https://github.com/dokku/dokku
Open repository in VSCode
Rebuild the app as a remote container
View the build output
If you miss the build output, in a shell within the container, run cd /root/go/src/github.com/dokku/dokku ; make setup-deploy-tests
See error

Expected behavior
Sed should work :D
Screenshots

Logs
vmgr.log
Info report
% orb report
OrbStack info:
  Version: 0.11.0 (110000)
  Commit: 26e09531a8770bcfbaacc3723b091639f0f6d0dd (v0.11.0)

System info:
  macOS: 13.4 (22F66)
  CPU: arm64, 10 cores
  CPU model: Apple M1 Pro

---------------- [ cut here ] ----------------

Please copy and paste the above information into your bug report.
Open an issue here: https://github.com/orbstack/orbstack/issues/new/choose

Additional context
This works totally fine under Docker Desktop, so I'm switching to that while the issue is being debugged :)

Maybe related to https://github.com/orbstack/orbstack/issues/195, according to https://discord.com/channels/1106380155536035840/1110774099715825778/1112232041065500766 :(

This only happens with older versions of sed, so a workaround is to upgrade the distro in your Docker image. It's the same underlying issue as #195, which is actually caused by a bug on Apple's side. Will add a workaround in OrbStack.
Closing in favor of the other issue. If you're still having sshd permission issues after the fix is released, then please open a new issue as it's likely unrelated.

Released in v0.11.1.


build-support/go: fix eval of vendorSha256 accesses

Before the change there was no way to poll for presence of vendorSha256 attribute:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
   error: attribute 'vendorSha256' missing
      292|     passthru = passthru // { inherit go goModules vendorHash; } // { inherit (args') vendorSha256; };
         |                                                                     ^

After the change the poll happens as expected:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
"no hash"

(cherry picked from commit a1422a7f8f12b68e307b92b7daa254f412e9ff96)
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@zowoq can we backport this?

Is vendorSha256 not deprecated?
Does the approach here has benefits over using this?
nix-repl> telegraf ? vendorSha256
false
nix-repl> telegraf ? vendorHash
true

Ok. Sorry, I was confused. This is already in nixpkgs master.


Fixes for IPsec and endpoint routes

First two patches stolen from: https://github.com/cilium/cilium/pull/17301

First commit fixes the path bpf_network -> bpf_lxc for when endpoint routes and IPsec are enabled. Second commit implements an additional fix for that path when L7 proxy is used.

Final patch fixes an issue with xfrm policy templates that caused dropped in AKS.
Please see commit descriptions for more details.

/test

AKS failure might be #16938

❌ 6/11 tests failed (1/84 actions), 0 tests skipped, 0 scenarios skipped:
Test [to-entities-world]:
❌ to-entities-world/pod-to-world/https-to-one-one-one-one-index-1: cilium-test/client2-6dd75b74c6-8pjfx (<IP_ADDRESS>) -> one-one-one-one-https-index (one.one.one.one:443)
Test [to-cidr-1111]:
Test [echo-ingress-l7]:
Test [client-egress-l7]:
Test [dns-only]:
Test [to-fqdns]:
Connectivity test failed: 6 tests failed
Error: Process completed with exit code 1.

/mlh new-flake Cilium-PR-K8s-1.21-kernel-4.19

/test

@gandro mentioned this might fix #17644, I propose running CI with AKS re-enabled on top of this PR to check. We can do it within this PR with a temporary test commit, or via a separate PR. Happy to do it in any case if you'd like.

@gandro mentioned this might fix #17644, I propose running CI with AKS re-enabled on top of this PR to check. We can do it within this PR with a temporary test commit, or via a separate PR. Happy to do it in any case if you'd like.

I doubt it will. The third commit in this PR fixes a bug that only occurs when the first commit in this PR exists. When AKS was flaky and disabled, the first commit was not in master.

The third commit in this PR fixes a bug that only occurs when the first commit in this PR exists.

Looking at the first commit message, it seems to me that the path followed without the first commit would be:

[...] when endpoint routes are disabled, we run the BPF program for
ingress pod policies from cilium_host, via a tail call in bpf_host.
Therefore, in that case, we need to jump from bpf_network to cilium_host
first, to follow the correct path to the lxc interface.

So, isn't it possible to observe the same drops due to the problematic forward template even without the first patch?

So, isn't it possible to observe the same drops due to the problematic forward template even without the first patch?

I don't think so (but could be wrong obviously). As John said:

Before endpoint routes we redirect packet to cilium_host which traverses cilum_host->cilium_net going through skb_scrub. This removes any ipsec context so the xfrm dir fwd policies do not matter.


[Enhancement] debian/ubuntu installation via. package manager/apt

Is your feature request related to a problem? Please describe.
Managing the OpenSearch installation via the package manager apt under Debian/Ubuntu is a better way for the version control and especially any future updates.
Describe the solution you'd like
Installing OpenSearch from an APT repository for Ubuntu/Debian: https://opensearch.org/docs/latest/install-and-configure/install-dashboards/debian/#installing-opensearch-dashboards-from-an-apt-repository
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

[Triage]
Hey @leowinterde, with apt OpenSearch can also be installed, can you please check this https://opensearch.org/docs/latest/install-and-configure/install-opensearch/debian/ ?
Thanks
@bbarani @peterzhuamazon


Make Glitch demos automatically updatable

Glitch demos are up at https://glitch.com/~mwc-demos but we need a method to automatically update them

updatable with npm command


Python 3 compatibility

The Python 3-compatible branch mentioned on the project home page is over a
year old, so apparently it's not kept up-to-date with pydot development. The
latest tag is for version 1.0.15, whereas 1.0.28 is the current version of
pydot.

Python 3 is becoming more and more mainstream, especially for new projects. It
would be very nice to be able to use pydot in Python 3.x projects too.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 5 Nov 2012 at 1:43

bump, @nlhepler

@andreabedini, I think Google has decided I'm upstream...?! Cool, but strange. Seeing as erocarrera owns the original, perhaps we should just actually create a legitimate fork?

There's a bunch of people who have made copies of the Google code repo. The good news is that the git hashes should be exactly the same for everyone so merges between the new repos are possible.
I came across this trying to make theano work with pydot. The version of pydot from pypi didn't work well but your fork did.
happy to help if you and @erocarrera decide to merge.

@erocarrera now is marked correctly as upsteam.
Now, another problem with the py3k patch in Debian:
>>> import pydot
>>> a=pydot.Dot()
>>> a.create()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/pydot.py", line 2003, in create
    stdout_output = ''.join(stdout_output)
TypeError: sequence item 0: expected str instance, bytes found

I am getting errors regarding python3 compatibility.
pydot/setup.py", line 5
    except ImportError, excp:

and when I fix that error:
pydot/pydot.py", line 32
    except Exception, e:

print commands are also not python3 compatible.
Is there going to be a python3 compatible fork coming out of this project?

FTR: I updated the patch (and so even the package) to https://anonscm.debian.org/cgit/python-modules/packages/pydot.git/tree/debian/patches/0002-support-python3.patch (which is basically https://github.com/nlhepler/pydot/ as of today)

As of cb0dfe193166da8bc8f2279821b82dc1a930ebff, pydot runs in both python 2 and 3.
There were some minor API changes along the way, mainly to draw a clear distinction between unicode (strings) and bytes, and keep bytes at bay at the program boundaries, as is the recommended paradigm after the introduction of python 3. Explicit is better than implicit, and bytes should not be confused with unicode.


[in_app_purchase] support for  old version of PlayStore request

Use case
After upgrading to [in_app_purchase] 3.2.0, queryProductDetails Returning an empty list on a phone with an old version of the PlayStore(24.4.23) installed.   But new version PlayStore(41+) works fine.
It seems that we need to call the querySkuDetailsAsync instead on old version Playstore.
Reference:   https://developer.android.com/google/play/billing/migrate-gpblv6
Proposal
Hope to support older versions of PlayStore

Backwards compatibility is supposed to be handled by the android library, I'm not sure it is something the plugin can control. The plugin is using version 6.1.0. See https://github.com/flutter/packages/blob/9c6f691a8c891ff61d32eec4382c1850df599c67/packages/in_app_purchase/in_app_purchase_android/android/build.gradle#L65.
It may be that the play billing library itself does not support the playstore version you're using.
Do you get any errors in your app?
What version of in_app_purchase were you using before upgrading to 3.2.0?
What device is using that version of the playstore?
What version of android is the device running?

Backwards copatilility is not supported by the android library very well.Below is copied from https://developer.android.com/google/play/billing/migrate-gpblv6

Rarely, some devices are unable to support ProductDetails and queryProductDetailsAsync(), usually due to outdated versions of Google Play Services. To ensure proper support for this scenario, call isFeatureSupported() for the PRODUCT_DETAILS feature before calling queryProductDetailsAsync. If the response is OK, the device supports the feature and you can proceed with calling queryProductDetailsAsync(). If the response is FEATURE_NOT_SUPPORTED, you can instead request the available backward-compatible products list with querySkuDetailsAsync(). To learn more about how to use the backward compatibility features, see the May 2022 subscription features guide.

I modified the code using querySkuDetailsAsync according to the above instructions. It worked on my old PlayStore.
My previous in_app_purchase version is 3.0.5
My  PlayStore version is 24.4.23,  I reproduced on  Emulator with old playstore.
My android version is android 14. (My phone do not have playstore installed by default, so I installed a very old version of playstore.)

@Morris-Mao happy to review a pull request if you want to push a pr. https://github.com/flutter/packages/blob/main/CONTRIBUTING.md

/cc @zoeyfan Potential small work item to track.


[Fix] client selects local dp

Before: Client checks if dp is local by dp.hosts[0].
Once there is one and just one dp satisfied, only one dp will be written till dp is full so that the write rate is low  in the beginning.
After: Client checks if dp is local by dp.nearhosts[0].
dp.hosts[0] may be not local, but dp.nearhosts[0] mostly is local because it's sorted. So all local dp can be chosen.

https://github.com/cubefs/cubefs/pull/1958


Colab compatibility improvements

Hi! I just added these fixes that improve on the Colab compatibility experience.

Ensure Google Colab GPU Compatibility

Added parameters to compile for all available GPU models in Google Colaboratory.
Moved the instructions to a common file used by all setup files
Adapted Colab file, removing outdated error indicators

Suppressing compiler warnings
Updated documentation

Updated documentation inside and outside of Colab file.
Removed references to any shared Colab file, to avoid outdated versions out there. The one in the master branch of this repo should be the canonical one.
Added versioning to the file itself, so we can easily tell when someone is using an old version of the file.
Added markdown input for configuration

Hi, thank you for your commits, but I meet a error when I use Tesla V100 with compute capability 7.0.
I change the arch gen-code in the compiler_args.py. However, it seems that it doesn't work.
Thanks in advance!

Hi there! It seems like you're on the right path. Did you try adding both the arch and code to 70 compatibility?
Also, I know that this error can also occur on cases where the CUDA drivers are not quite supported -- I'm not entirely sure how to verify that's the case. Around the internet people just keep trying different versions of pytorch, cuda and nvidia drivers until they find a combination that works. What we did is fixed those in Colab to a known working version.

Hi,thank you for your reply!
Yes,I use both the arch and code. First, I fork this repository from your Github. Then I add the
'-gencode', 'arch=compute_70,code=[sm_70,compute_70]' in the compiler_args.py. At last, I modify the git source in the colab file from my github. But it seems that it is not a useful way.

 When I used a non-Colab Pro account, I got a T4 GPU and it worked as expected.


Should not set Scenario["plasma"]["2D_prof"] = []

Hi Severin et al,
ECRadScenario.set_up_profiles_from_imas() is a bit too eager to reset everything to an (empty) list:
https://github.com/AreWeDreaming/ECRad_PyLib/blob/f6322e9261af3941eb48c983986c0a6e379b3c40/src/ecrad_pylib/ECRad_Scenario.py#L232-L233
https://github.com/AreWeDreaming/ECRad_PyLib/blob/f6322e9261af3941eb48c983986c0a6e379b3c40/src/ecrad_pylib/ECRad_Scenario.py#L240-L241
E.g. Scenario['plasma']['2D_prof'] should remain a scalar boolean in order to be able to write it to netcdf output later on:
https://github.com/AreWeDreaming/ECRad_PyLib/blob/f6322e9261af3941eb48c983986c0a6e379b3c40/src/ecrad_pylib/ECRad_Scenario.py#L672-L673
I got it to work after rewriting the two loops above as:
for key in ["rhot_prof", "rhop_prof", "Te", "ne"]:
    self["plasma"][key] = []

Greetings,
Wolfgang

Hi Wolfgang, sorry for ignoring this. I think I have create a quite general fix in https://github.com/AreWeDreaming/ECRad_PyLib/commit/47e09103007fc11cb229cbb6d4e35606c8897237. Do you use the conda build? I can create a new release for you to test it.

Also new mamba release for Pylib now,


Add output to opta help result

Description
Add output subcommand to the opta -h
Safety checklist

[x] This change is backwards compatible and safe to apply by existing users
[x] This change will NOT lead to data loss
[x] This change will NOT lead to downtime who already has an env/service setup

How has this change been tested, beside unit tests?

Slack Discussion: https://opta-group.slack.com/archives/C0240NBKUMT/p1649690540381179

#813 already exists and has been merged.


Update Onassis and TheInterestingTimes URLs

Checks can't complete, could you please assist @stackbithq?

That's ok, the last check for the deploy preview is passing and the site preview looks correct.


Change static document root to MEDIA_ROOT

Uploaded media files were not working correctly, and we noticed that
document root for media was defined as a MEDIA_URL and not MEDIA_ROOT
as it should.
Refs: LIIK-56

Codecov Report

Merging #36 into master will decrease coverage by 0.07%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #36      +/-   ##
==========================================
- Coverage   94.77%   94.70%   -0.08%
==========================================
  Files          45       45
  Lines        2678     2642      -36
  Branches       68       68
==========================================
- Hits         2538     2502      -36
  Misses        128      128
  Partials       12       12

Impacted Files
Coverage Δ

city-infrastructure-platform/urls.py
86.66% <0.00%> (ø)

azure_client_ip/middleware.py
68.75% <0.00%> (-1.84%)
:arrow_down:

traffic_control/views.py
100.00% <0.00%> (ø)

azure_client_ip/test_middleware.py
100.00% <0.00%> (ø)

traffic_control/tests/test_mount_api.py
100.00% <0.00%> (ø)

traffic_control/tests/test_barrier_api.py
100.00% <0.00%> (ø)

traffic_control/tests/test_permissions.py
100.00% <0.00%> (ø)

traffic_control/tests/test_signpost_api.py
100.00% <0.00%> (ø)

traffic_control/tests/test_portal_type_api.py
100.00% <0.00%> (ø)

traffic_control/tests/test_road_marking_api.py
100.00% <0.00%> (ø)

... and 3 more

Continue to review full report at Codecov.

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


Modify Cavium PCIe initialization to support PCIe compliance for BBU

Product: (OC-SDR, OC-LTE, OC-LTE, OC-Power, All, N/A, others)
OC-LTE
Component: (PSU, GBC, BBU, FEM, LED, ME)
BBU
Revision: (A, B, C ...)
Rev C
*Category: (schematic, layout, BoM, gerber, compliance, testing, documentation, etc.)
Compliance
Clearly explain the issue in detail, with snippets of schematic (or ref to the exact page), layout, etc, as needed
For PCIe compliance testing PCIe controller has to be put in to EC(Enter compliance) mode and link speed should be forced to 5GT. Currently PCIe auto-negotiation puts the link speed as 2.5GT and it does not allow to do PCIe compliance testing for 5GT. There is a need to add code in Linux build for the Cavium PCIe initialization and forcing the link speed as required.

Added support for PCI compliance in the kernel and provided a release to HW team to test. HW team able to verify 5Gbps. Attached kernel
pci_compliance.txt
patch file.


TSconfig support

Is it planned? Or there are some restrictions for using more common way for ts developers instead of tweaking package.json?

Could you share what you'd like and how that would be different from the current setup? I'd definitely like to improve this.

How about:
Instead of having
"globals": {
      "__TS_CONFIG__": {
        "module": "commonjs",
        "jsx": "react"
      }
    }

You have:
"globals": {
      "__TS_JEST__": {
        "tsconfig": "./my-tsconfig.json"
      }
    }

in preprocessor.js - getTSConfig  you can use path module to resolve the file:
const path = require('path');
const config = require(path.resolve(globals.__TS_JEST__.tsconfig));
return tsc.convertCompilerOptionsFromJson(config.compilerOptions).options;

I'll take a look at this on the weekend or if you want to take a stab at it, I'd welcome a PR :)


[EN] Feedback for: /tools/polymer-starter-kit/index.html

There's a 404 on Getting Started.
https://developers.google.com/web/tools/setup/polymer-starter-kit/?hl=en

This should be fixed - removed link.
https://developers.google.com/web/tools/polymer-starter-kit/


Crashes and excessive memory + CPU consumption when dealing with corrupted databases

I've now spent a bit of time fuzzing libmdbx, like I fuzzed Berkeley DB, LMDB, GDBM, TDB and other databases inspired by BDB and/or DBM in the past. Sorry, I didn't find about libmdbx until fairly recently...
In the README and Makefile, I read that you worked on fixing some crashes, and that you have asan & ubsan test targets - so clearly, you paid at least some level of attention to memory safety and UB, which is a good thing.
However, with a Time To First Crash around 2 minutes, '2021 libmdbx tolerates corrupted databases better than '2018 and '2021 LMDB do (TTFC << 1s on mdb_dump), and marginally better than Berkeley DB 18.1.40 (yes, the latest version, despite dozens of fixes for CVE-numbered issues over the years... I basically gave up reporting issues) does, but libmdbx is not quite fool-proof yet :)
Building and starting a first, simple fuzzing job is straightforward, along the lines of:
git clone https://github.com/erthink/libmdbx
cd libmdbx
AFL_USE_ASAN=1 CC=$HOME/AFLplusplus/afl-clang-fast DESTDIR=$HOME/libmdbx_prefix_asan make install V=1
cd ..
mkdir libmdbx_fuzz
cd libmdbx_fuzz/
mkdir input
echo "" | $HOME/libmdbx_prefix_asan/usr/local/bin/mdbx_load -T -n empty
echo -e "key1\nvalue1" | $HOME/libmdbx_prefix_asan/usr/local/bin/mdbx_load -T -n one
cd ..
mkdir /dev/shm/libmdbx_tmpdir
AFL_TMPDIR=/dev/shm/libmdbx_tmpdir $HOME/AFLplusplus/afl-fuzz -i input -o output -M master -- $HOME/libmdbx_prefix_asan/usr/local/bin/mdbx_chk @@

(the AFL++ setup, which basically reduces to git clone and make when the build dependencies are installed, is not described here, for brevity)
I stopped the mdbx_chk fuzzing process a bit after reaching 1M execs. Triaging the crashes already showed 5 unique code locations and SIGBUS, SIGSEGV, weirdness when unpoisoning memory, use after poison through wild pointers: that's enough to warrant creating this issue and provide the information which can enable you to perform your own fuzzing jobs.
The final afl-fuzz output was:
                american fuzzy lop ++3.14a (master) [fast] {0}
+- process timing ------------------------------------+- overall results ----+
|        run time : 0 days, 0 hrs, 42 min, 20 sec     |  cycles done : 12    |
|   last new path : 0 days, 0 hrs, 0 min, 54 sec      |  total paths : 240   |
| last uniq crash : 0 days, 0 hrs, 0 min, 18 sec      | uniq crashes : 48    |
|  last uniq hang : 0 days, 0 hrs, 6 min, 3 sec       |   uniq hangs : 15    |
+- cycle progress ---------------------+- map coverage+----------------------+
|  now processing : 3*2 (1.2%)         |    map density : 6.16% / 10.04%     |
| paths timed out : 0 (0.00%)          | count coverage : 1.65 bits/tuple    |
+- stage progress ---------------------+- findings in depth -----------------+
|  now trying : splice 3               | favored paths : 81 (33.75%)         |
| stage execs : 62/110 (56.36%)        |  new edges on : 120 (50.00%)        |
| total execs : 1.05M                  | total crashes : 8155 (48 unique)    |
|  exec speed : 447.0/sec              |  total tmouts : 78 (29 unique)      |
+- fuzzing strategy yields ------------+-------------+- path geometry -------+
|   bit flips : disabled (default, enable with -D)   |    levels : 11        |
|  byte flips : disabled (default, enable with -D)   |   pending : 55        |
| arithmetics : disabled (default, enable with -D)   |  pend fav : 0         |
|  known ints : disabled (default, enable with -D)   | own finds : 235       |
|  dictionary : n/a                                  |  imported : 0         |
|havoc/splice : 202/531k, 81/509k                    | stability : 99.54%    |
|py/custom/rq : unused, unused, unused, unused       +-----------------------+
|    trim/eff : disabled, disabled                   |          [cpu000:100%]
+----------------------------------------------------+

The crash triage output is part of the tarball.
NOTE: in order to reproduce crashes, the best practice is to start from fresh copies of the files. The output of AddressSanitizer killing mdbx_chk on the attached files seems to be stable from one run to the next one (apart from randomized addresses, of course), but for instance, starting from fresh files is definitely necessary for reproducing a subset of the endless stream of crashes in Berkeley DB.
Ideas for improving the next stages of the fuzzing process:

first and foremost, using a much wider input corpus. The 2-file corpus I used is enough to show that libmdbx's tolerance to offline data corruption / specially crafted files needs improvements, but there should be tests with > 1 keys / values, sub-databases, different page sizes, both endiannesses, databases after some creations and deletions of items, etc.
fuzzing the other CLI front-ends as well;
using ubsan and msan instrumentation for fuzzing (unless using UMRs is an integral part of the way libmdbx works, but I doubt it);
using AFL persistent mode, which often speeds up the fuzzing process;
using Honggfuzz (and also its persistent mode): I use it less often than AFL++, but in some of my past runs, it found some interesting testcases that AFL didn't.

Looking forward to the fixes which will make libmdbx even more production ready ;)
mdbx_chk_asan_crashes_20210707.tar.gz

A couple hours of fuzzing the msan-instrumented version, which runs about an order of magnitude slower than the asan-instrumented version, produced 42 "unique" crashes which all reduce to the same location as most other testcases which also trip the asan-instrumented version: mdbx_page_get_ex at .../libmdbx/src/core.c:13043:7.

Triaging the testcases flagged as hangs by afl-fuzz (significant CPU time outliers) shows runaway CPU and memory consumption.  mdbx_chk commits allocated memory at a rate of gigabytes per second, until the Linux OOM killer kicks in to save the system. libmdbx is not the first code base displaying such behaviour on my computer when dealing with corrupted input.
Jul  7 22:55:34 hostname kernel: [801454.621961] Out of memory: Killed process 537258 (mdbx_chk) total-vm:24830357632kB, anon-rss:12189300kB, file-rss:2012kB, shmem-rss:0kB, UID:1000 pgtables:24356kB oom_score_adj:0 Jul  7 22:55:39 hostname kernel: [801459.841971] Out of memory: Killed process 537262 (mdbx_chk) total-vm:22548656256kB, anon-rss:12195952kB, file-rss:2016kB, shmem-rss:4kB, UID:1000 pgtables:24384kB oom_score_adj:0 Jul  7 22:55:49 hostname kernel: [801469.479816] Out of memory: Killed process 537271 (mdbx_chk) total-vm:21609371776kB, anon-rss:12184332kB, file-rss:2028kB, shmem-rss:4kB, UID:1000 pgtables:24336kB oom_score_adj:0 Jul  7 22:55:54 hostname kernel: [801474.487720] Out of memory: Killed process 537274 (mdbx_chk) total-vm:21474916012kB, anon-rss:12190908kB, file-rss:1960kB, shmem-rss:16kB, UID:1000 pgtables:24408kB oom_score_adj:0 Jul  7 22:56:03 hostname kernel: [801483.723544] Out of memory: Killed process 537282 (mdbx_chk) total-vm:25769881728kB, anon-rss:12194924kB, file-rss:2120kB, shmem-rss:4kB, UID:1000 pgtables:24392kB oom_score_adj:0 Jul  7 22:56:09 hostname kernel: [801489.754089] Out of memory: Killed process 537285 (mdbx_chk) total-vm:21474916012kB, anon-rss:12187120kB, file-rss:2080kB, shmem-rss:16kB, UID:1000 pgtables:24376kB oom_score_adj:0 Jul  7 22:56:15 hostname kernel: [801496.026316] Out of memory: Killed process 537291 (mdbx_chk) total-vm:21474916012kB, anon-rss:12190812kB, file-rss:2080kB, shmem-rss:16kB, UID:1000 pgtables:24376kB oom_score_adj:0 Jul  7 22:56:24 hostname kernel: [801504.593456] Out of memory: Killed process 537305 (mdbx_chk) total-vm:29997740160kB, anon-rss:12192060kB, file-rss:1976kB, shmem-rss:4kB, UID:1000 pgtables:24360kB oom_score_adj:0 Jul  7 22:56:29 hostname kernel: [801509.835272] Out of memory: Killed process 537308 (mdbx_chk) total-vm:24439282992kB, anon-rss:12191236kB, file-rss:2036kB, shmem-rss:4kB, UID:1000 pgtables:24360kB oom_score_adj:0 Jul  7 22:56:35 hostname kernel: [801515.190677] Out of memory: Killed process 537311 (mdbx_chk) total-vm:22011785344kB, anon-rss:12196192kB, file-rss:2036kB, shmem-rss:0kB, UID:1000 pgtables:24352kB oom_score_adj:0
The 20+ TB total-vm figures are simply a consequence of the way AddressSanitizer works, but the anon-rss figures are caused by mdbx_chk's operation.
mdbx_chk_asan_hangs_20210707.tar.gz - these files can perform partial DoS on most computers, you have been warned ;)

Thank for your attention and reporting.
By the first part of the traces I found that a some check was missed in at least one place, which is why a damaged meta-page is not skipped and as a result subsequent fails occur.
I think that tomorrow during the day I will provide a fix.

I've taken the current contents of the devel branch, fb78c5fca557deb349a5e5f2dadec224ae35784e , for another short test drive, restarting from the previous fuzzing output directory - which means that my input corpus still sucks. I only fuzzed the ASAN-instrumented code.
You're on the right track: your changes have decreased the crash rate by over an order of magnitude: less than 1K crashes in over 3.5M execs :)
mdbx_chk_asan_crashes_20210713.tar.gz contains samples and stack traces. The restart phase shows a nullptr deref of write type.
Note that some of these samples trigger the production of 100+ lines of error output by mdbx_chk, and I've seen some other malformed samples produce several thousand lines of error output, which is a weak form of DoS. You may want to add some automatic trimming of messages beyond some count, possibly with a final summary, and I guess with a way to disable said trimming.

Once again - Thank for your attention and reporting.
Until now, I have not finished the work yet, so there was no new information here.

@debrouxl, Briefly, there were the four problems/drawbacks/bugs:

BUG: When reading the header during opening a database all the three meta-pages are read, verified and bad ones are skipped.
However, then an invalid meta pages were not cleared/purged and were used if one contains a greater transaction number (i.e. information about the more recent transaction).
This was the main problem and the reason for the vast majority of subsequent failures.
DRAWBACK: A "fuzzied" meta page can still be valid/correct, but contain a very large upper limit of the database size.
However, the MDBX maps a whole DB to RAM, so such a huge database requires a large address space region (number of PTE) regardless of the current amount of data. This is enough for a large memory consumption and triggering OOM-killer.
However, in builds with ASAN, the situation was aggravated, since memory is required for the bitmask of the mem-state and the CPU costs for handling it. This was the cause of stalling and hangs.
DRAWBACK: Historically, the mdbx_chk utility checks database data in two stages: it traverses a page tree to check and correctness of structure, and then iterates the records.
Thus, any corruption will be detected at the first stage, and at the second stage you can see how this damage will affect the operation (for example, whether there will be SIGSEGV or other problems). However, such crashes with SIGSEGV or ASAN errors are not the best behavior for a database validation utility.
So I have just disabled the iteration of records for now, if problems were found in a page tree.
Next I will add command-line options to enable the previous behavior.
Nonetheless, I should warn that with a corresponding corruption, the library will crash as the mdbx_chk before, but it is irrational to fix, since:

it will lead to a lot of overhead;
these checks do not guarantee the integrity of the data (but MithrilDB will have a Merkle-tree based verification).
This is not considered a (new or one more) attack vector, since (in general) it means that the attacker has the ability to rewrite data in memory, and not just attack the database.

REGRESSION/BUG: When fixing the first problem, an error was made-accessing the buffer before it was allocated.
This new year has not yet been fully tested, and you have helped with this.

You're right, full iteration of records makes less sense when the page tree is broken. Although high overhead would be tolerable for default-disabled checks, I tend to agree that attempting to make full traversal of a broken database memory-safe is lower priority :)
Earlier this morning, I rebuilt the code and started another instance with HEAD @ 4fc6d67a6b59c35b3da8bc566fa108ad314f0909 . The crash rate is still a bit over 1 per 2K execs, with two different stack traces so far, both use after poison. I'll let the fuzzer run for a longer time before posting samples.
Before that, I managed to produce databases with different page size by editing the output of mdbx_dump before feeding it to mdbx_load, which makes the input corpus slightly less bad. My first suggestion from #218 remains valid.
Next time, before starting a new fuzzer instance, I guess I'll throw some DBs with sub-databases in the mix.

On the newest mdbx_chk fuzzing job, barely more than three quarters of the paths are considered examined, but it's been over 3h since the latest so-called 'unique' crash was found, so it's time to post something :)
The crash rate has remained approximately constant throughout the past nearly 14h, the 10K crashes mark is about to be crossed while the 20M execs mark was just crossed.
I have packed up all of the files which used to crash, or still crash, mdbx_chk @ 4fc6d67 : mdbx_chk_asan_crashes_20210714.tar.gz
In the output, there are three different source locations for crashes:
ERROR: AddressSanitizer: use-after-poison on address 0x7fc849f5e0bc at pc 0x000000586821 bp 0x7ffe10260d50 sp 0x7ffe10260d48
WRITE of size 4 at 0x7fc849f5e0bc thread T0
    #0 0x586820 in atomic_store32 .../libmdbx/src/internals.h:287:3
    #1 0x586820 in mdbx_setup_dxb .../libmdbx/src/core.c:11834:3
    #2 0x57100d in mdbx_env_open .../libmdbx/src/core.c:12595:22
    #3 0x4ccc78 in main .../libmdbx/src/mdbx_chk.c:1244:10
    #4 0x7fc849c1ad09 in __libc_start_main csu/../csu/libc-start.c:308:16
    #5 0x420669 in _start (.../libmdbx/mdbx_chk+0x420669)

Address 0x7fc849f5e0bc is a wild pointer.
SUMMARY: AddressSanitizer: use-after-poison .../libmdbx/src/internals.h:287:3 in atomic_store32

ERROR: AddressSanitizer: use-after-poison on address 0x7f6a113f20b8 at pc 0x00000064bc10 bp 0x7ffde3aaf2b0 sp 0x7ffde3aaf2a8
READ of size 4 at 0x7f6a113f20b8 thread T0
    #0 0x64bc0f in mdbx_lck_destroy .../libmdbx/src/lck-posix.c:519:51
    #1 0x58f884 in lcklist_detach_locked .../libmdbx/src/core.c:1617:10
    #2 0x58f884 in mdbx_env_close0 .../libmdbx/src/core.c:12708:18
    #3 0x570363 in mdbx_env_open .../libmdbx/src/core.c:12682:10
    #4 0x4ccc78 in main .../libmdbx/src/mdbx_chk.c:1244:10
    #5 0x7f6a110aed09 in __libc_start_main csu/../csu/libc-start.c:308:16
    #6 0x420669 in _start (.../libmdbx/mdbx_chk+0x420669)

Address 0x7f6a113f20b8 is a wild pointer.
SUMMARY: AddressSanitizer: use-after-poison .../libmdbx/src/lck-posix.c:519:51 in mdbx_lck_destroy

ERROR: AddressSanitizer: BUS on unknown address 0x7fc95947f000 (pc 0x00000065caeb bp 0x7ffdc48d16d0 sp 0x7ffdc48d0980 T0)
    #0 0x65caeb in unaligned_peek_u32 .../libmdbx/src/core.c:159:5
    #1 0x65caeb in peek_pgno .../libmdbx/src/core.c:315:20
    #2 0x65caeb in node_largedata_pgno .../libmdbx/src/core.c:338:10
    #3 0x65caeb in mdbx_page_check .../libmdbx/src/core.c:17166:39
    #4 0x6898dc in mdbx_walk_tree .../libmdbx/src/core.c:20380:11
    #5 0x60bb62 in mdbx_walk_sdb .../libmdbx/src/core.c:20629:8
    #6 0x60a941 in mdbx_env_pgwalk .../libmdbx/src/core.c:20653:10
    #7 0x4d2772 in main .../libmdbx/src/mdbx_chk.c:1497:10
    #8 0x7fc95914ad09 in __libc_start_main csu/../csu/libc-start.c:308:16
    #9 0x420669 in _start (.../libmdbx/mdbx_chk+0x420669)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS .../libmdbx/src/core.c:159:5 in unaligned_peek_u32

No additional stack trace found since my previous message.

Once again - Thank a lot for your attention and reporting.

And thanks to you for providing a set of fixes which raise the TTFC above ~1h30 for ASAN-instrumented mdbx_chk (the 3 currently running new instances, which synchronize their queue from the old instances, have yet to produce their first crash) in ~9 days. This is quite a short interval in my experience fuzzing various pieces of FLOSS since late 2014 - even those maintained by people employed by corporations to work at least part-time on the code bases :)
Also, no "hangs" were found so far, even if afl-fuzz flagged several hundred "timeouts" among the ~6M execs so far; these might partially be due to the fact the computer effectively slowed down when I added more afl-fuzz instances: lower CPU frequency to remain within the TDP cap, even duty-cycling the processor to minimal frequency at times.
I threw an afl-fuzz ... mdbx_dump -a -r instance and an afl-fuzz ... mdbx_stat -p -e -f -r -a instance into the mix one hour later. Still enough to find that for these two (also ASAN-instrumented) programs, the TTFC is around 1 minute, effectively soon after the initial sync from the other cooperating fuzzer instances' queues starts.
I'll post samples later, when the instances have produced a bit more work... ~30' wall clock and ~2M mdbx_dump+mdbx_stat total execs aren't much.
I forgot to add DBs with sub-databases before the new runs, but they can be injected by adding an afl-fuzz ... mdbx_drop instance... I'll do that after posting this comment.

@debrouxl , thank you for your work.
You provide significant assistance, because having ready-made data about problems, I can focus on fix ones.
However, I think that you should not use anything other than mdbx_chk when fuzzing right now.
As I wrote earlier, it is unreasonable to add full-fledged checks when the engine/library is used usual way.
Therefore, the crashes of all utilities except mdbx_chk are predicted/expected and will not give a new information.
Nonetheless, a full check of the database pages used can be added as an option, i.e. by an explicit user request.
This does not require many changes, but I will do it after the release of the next stable version (it's time).
After that, it will be sense to engage the rest of the mdbx-tools in fuzzing.

You're welcome :)
Well, the help text for mdbx_dump states that its -r option aims at dumping data from corrupted databases :)
But your changes in core libmdbx code already made it more robust.
While working on corrupted databases is indeed not the main intended use case for mdbx_drop + mdbx_stat, the harder to fuzz mdbx_copy + mdbx_load, or a generic CLI front-end like the one I recently suggested in #218 (should you consider it a valuable suggestion for later implementation in libmdbx and/or its successor), BDB, GDBM and TDB attempt not to crash when dealing with broken DBs. BDB keeps failing at it, but recent GDBM (post https://puszcza.gnu.org.ua/bugs/?503 and earlier private reports) does quite a good job, and after several fixes, TDB did a good job in 2018.
Of course, the flip side of the coin is that some of these safety measures can only reduce raw speed, though I have no idea by how much... and one of the hallmarks of liblmdb / libmdbx is their raw speed. Therefore, a tradeoff needs to be drawn here, quite possibly along the lines of adding a safer mode, as you suggest :)
I've killed the mdbx_dump, mdbx_stat and mdbx_drop (x2, a temporary instance used to inject another pair of testcases) fuzzing jobs. Here are the files for later investigation at your leisure: mdbx_dumpdropstat_010167_crashes_20210717.tar.gz

Overnight, all 3 mdbx_chk instances found crashes by ~11h wall clock time. The crash ratio is in the ppm range: 3 x (< 100 crashes for > 15M execs). In the output, I see a single libmdbx source location yielding SIGBUS... and a bunch of internal AddressSanitizer sanity check errors !
mdbx_chk_asan_crashes_20210717.tar.gz

Today's status update:

over 200M execs, and nearly 3000 crashes;
no new source locations, AFAICS.
Nevertheless, here's an updated tarball, again a superset of the previous one: mdbx_chk_asan_crashes_20210718.tar.gz .

I plan on letting the fuzzers run for several more days. Reaching 1G execs would be nice, but would take another ~8 days, so I might stop before then. Adding other instances on the same computer would only provide sub-linear scaling, due to thermal throttling.
FTR, the use-after-poison .../libmdbx/src/core.c:115:10 in peek_u8 source location flagged by fuzzing mdbx_chk also occurs in the output of mdbx_dump -a -r on samples which crash that program, and reciprocally, mdbx_dump -a -r also crashes on some of the files which crash mdbx_chk at that location. Therefore, you'll kill (at least) two birds in one stone by fixing both issues from this batch :)
The other source location flagged by fuzzing mdbx_chk, BUS .../libmdbx/src/core.c:13620:9 in mdbx_cursor_next, does not reproduce with the samples from mdbx_dump -a -r I posted previously; however, mdbx_dump -a -r shows another issue in the same function: BUS .../libmdbx/src/core.c:13677:7 in mdbx_cursor_next.

More than 400M execs, and more than 4000 crashes. No new source location for crashes :)

@debrouxl, I don't expect any mdbx_chk crashes from the current devel branch (since e7336e1d5e1a656c27b28a61c53a029db9cec2f9).

I am closing this issue, since all noticed problems have been fixed in the master branch and an implementation of the safe mode will done within https://github.com/erthink/libmdbx/issues/223.
Please fire a new issue if new bug(s) will be found by fuzzing.
@debrouxl, Thank for your work!

You're welcome :)
libmdbx's resistance to data corruption was already slightly better than liblmdb's when I started fuzzing it, it's now a class above after your fixes. For a work project, I once had liblmdb in mind, but its unsafety made it a non-starter; when libmdbx has a safe mode - and the project focus is on changing the area of the code where a project like liblmdb/libmdbx would fit... - libmdbx can become an option.
I can confirm that all of the problems noticed (on mdbx_chk, that is) have been fixed. Yesterday evening, I started a 4th instance of mdbx_chk built from the devel branch, version v0.10.1-73-g9a1dffc; ~15h later, it has found no crashes yet.
I'll open a new issue if new crashes are found in mdbx_chk.


shotcut: 24.06.26 -> 24.08.29

Description of changes

Release notes: https://github.com/mltframework/shotcut/releases/tag/v24.08.29
I saw that there's also a draft that's not been  kept up-to-date: https://github.com/NixOS/nixpkgs/pull/332590
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

LGTM
@NixOS/nixpkgs-merge-bot merge


Add HttpRuntime.AppDomainAppVirtualPath

Does this lead to being able to create a version of System.Web.VirtualPathUtility that works under ASP.Net Core?
I think I only really need
public interface IVirtualPathUtility
{
	string ToAbsolute(string virtualPath);
	string ToAppRelative(string virtualPath);
}
public class VirtualPathUtility : IVirtualPathUtility
{
	public string ToAbsolute(string virtualPath) => System.Web.VirtualPathUtility.ToAbsolute(virtualPath);
	public string ToAppRelative(string virtualPath) => System.Web.VirtualPathUtility.ToAppRelative(virtualPath);
}

@CZEMacLeod this is probably part of it. Can you open an issue with the APIs you would need? The whole VirtualPath infrastructure ends up pulling in a bit of stuff, so we're initially just going after APIs that are used in the wild.


Support async created apps

This library should support async apps (awaiting the default import of the app)
My apps usually have an async startup and this library cannot be used on my app.
This library would be useful if it resolved any promises returned by the app.

Thanks for reporting this @seriouslag.
Could you give me an example of this async app approach?

For example:
async function main() {
  await mongo.connect()
  const app = express()
  ...
  app.listen(5000)
}

main().catch(error => {
  console.error(error)
  process.exit(1)
})

Thanks @jdesboeufs.
Support published in latest version. (check README)


raspi-pwm REPLACE_INVALID_UTF8 when installing

Steps:

On a brand new Jessie install npm
npm install raspi-io

Versions:
HW: Pi B
OS: Jessie
node -v v0.10.29
node-gyp -v v0.12.2
npm -v 1.4.21
Error:

<EMAIL_ADDRESS>install /home/pi/node_modules/raspi-io/node_modules/raspi-pwm
node-gyp rebuild

make: Entering directory '/home/pi/node_modules/raspi-io/node_modules/raspi-pwm/build'
CXX(target) Release/obj.target/addon/src/addon.o
In file included from ../src/addon.cc:26:0:
../node_modules/nan/nan.h:328:47: error: ‘REPLACE_INVALID_UTF8’ is not a member of ‘v8::String’
static const unsigned kReplaceInvalidUtf8 = v8::String::REPLACE_INVALID_UTF8;
^
addon.target.mk:84: recipe for target 'Release/obj.target/addon/src/addon.o' failed
make: *** [Release/obj.target/addon/src/addon.o] Error 1
make: Leaving directory '/home/pi/node_modules/raspi-io/node_modules/raspi-pwm/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/share/node-gyp/lib/build.js:267:23)
gyp ERR! stack     at ChildProcess.emit (events.js:98:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:809:12)
gyp ERR! System Linux 4.1.13+
gyp ERR! command "nodejs" "/usr/bin/node-gyp" "rebuild"
gyp ERR! cwd /home/pi/node_modules/raspi-io/node_modules/raspi-pwm
gyp ERR! node -v v0.10.29
gyp ERR! node-gyp -v v0.12.2
gyp ERR! not ok
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian

It would seem that all I needed to do was to run the command as sudo which I had assumed not to be necessary.

Glad you got it working!

Thanks and sorry if I had rushed into wrong conclusions a bit too quickly.
On 30 November 2015 at 20:33, Bryan Hughes<EMAIL_ADDRESS>wrote:

Glad you got it working!
—
Reply to this email directly or view it on GitHub
https://github.com/nebrius/raspi-io/issues/38#issuecomment-160753312.


[Markdown] Headings rendering with # text

Is anyone else seeing that when you define headings in your .md files like # Heading 1 text or ## Heading 2 text, that there is a "#" character inserted before the heading displays?

#
Contact Us

I am going to fix this for now by adding .phenomic-HeadingAnchor{ display: none} to my css file. I propose that the default website should not display a "#" character next to headings as this is unexpected. I actually thought for a moment that this was a bug!!
Happy to send a PR if others agree. Let me know 😄

This is actually a feature. But as this keep comes up, I suggest we disable this by default.
@bherila If you want to send a PR,  remove autoLinkHeading in this file https://github.com/phenomic/phenomic/blob/fa314107debb6ca1f860b7c7a38dc30b0e2c8b6b/packages/plugin-transform-markdown/src/remark-plugins.js#L18-L27

Oh, I didn't convey my message clearly. I agree that the autoLinkHeading is a feature. However, my proposition is that the "#" element is hidden by default. This way, hash links can still work, but they don't generate unexpected visible elements on the page.

I agree. I had to hide this element as well.
Any visable features like this should be opt in (in my opinion)
The auto anchor tag is great :)
One note on the auto anchor tag, it breaks of you use any special characters ( /, (, ), etc) in the heading text. Probably need to encode or strip those out from the hash

Will remove it then :)
Feel free to open an issue if there is a bug. For slugs it's probably a remark-{something} issue :D

Are there plans to also add richer customisation of how the BodyRender works? What would be great is if it was possible to expose the remarkReactComponents to the caller so I can say:
const customComponents = {
  a: Link,
  p: Text
}
const page = () => (
<BodyRenderer remarkReactComponents={customComponents} />
)

This is a basic requirement for being able to make the most of using styled-components as usually you don't define global styles for classes, but rather rely on a styling the individual components.

@hellais actually it's already possible via the components props. See https://github.com/phenomic/phenomic/blob/137ca8c96b0033ac80300900e03cda7d65fb27a1/packages/plugin-renderer-react/src/components/BodyRenderer.js#L13
Tell me if that's enough for you. Will try to document this.

Tell me if that's enough for you. Will try to document this

Ah, yes that is actually exactly what I was looking for. Sorry I missed that part. Maybe adding a note to the docs would also be useful.
Thanks 👍

Note that we already have a better Link that what rr 3 is exposing, so be sure to not blindly override it ;)

This # has been removed by default since a few releases.


How to create influxdb bucket scheme in csv format

airQuality.csv
this is my csv file. but i can not upload it. there is a error. tells heading are incorrect. but i follow the instruction of the manual
Relevant URLs

https://docs.influxdata.com/influxdb/cloud/reference/cli/influx/bucket-schema/
Provide other relevant URLs (project issues, community threads, etc.)

This appears to be an issue with the product. The headers in your CSV match the expected headers. I have duplicated the issue. I'm transferring this issue to the InfluxDB repo.

This appears to be a documentation error, the CSV reader is expecting data_type rather than dataType. Unfortunately, that is inconsistent with the JSON reader but as that would be a breaking change, I would suggest we update the documentation to data_type for CSV.
https://github.com/influxdata/docs-v2/pull/4568

Correction, this is not a documentation issue and is a bug in the CLI vs what cloud expects.


Box inventory doesn't get marked removed if I delete a location

Deleting an AP marks it as a removed box in the inventories list.
However, if you delete a location, the device is not marked so. Therefore, it can appear as an active device in multiple locations.

Fixed backend. Changes live today


Add functional test for syncing and block announcements

Functional tests were failing when multiple tests were enabled because the test script would call _initialize_chains() which passed unrecognized parameters and tried to create a 199 block long chain.


feat: flatten

FYI @yokuze @jimjenkins5 @onebytegone

FYI @lukelafountaine

Actually, this is kinda clunky if you have an array of arrays, which is probably more common than the variadic arguments I allowed for.
// i.e. this doesn't work
const strings: string[] = flatten([ [ 'a', 'b' ], [ 'c', 'd' ] ]);
// you have to do this instead (add the spread):
const strings: string[] = flatten(...[ [ 'a', 'b' ], [ 'c', 'd' ] ]);

And, it doesn't handle nested arrays like Underscore did.
Also, the implementation is not great for huge arrays. That part I can easily revisit, but I'm actually not sure how to handle the types for the first two problems mentioned above. Any pointers on that @jimjenkins5 @yokuze @onebytegone @lukelafountaine?

With typescript > 3.7 you can have circular references in your type definitions. That would allow something like this:
import { isArray } from 'util';

// eslint-disable-next-line @typescript-eslint/no-type-alias
type DeepArray<T> = Array<T | DeepArray<T>>;

export function flatten<T>(...lists: DeepArray<T>): T[] {
   return lists.reduce((memo: T[], list) => {
      let flatList = list;

      if (isArray(list)) {
         flatList = flatten(...list);
      }

      return memo.concat(flatList as T[]);
   }, []);
}

Obviously, since it's typescript > 3.7 we'd need to upgrade typescript in this repo for it to work, but we're doing that anyway.

After the work that @jimjenkins5 is doing to upgrade us to Babel and the newest version of TypeScript is done, we should have access to the ES2019 Array#flat method: https://github.com/microsoft/TypeScript/blob/master/src/lib/es2019.array.d.ts#L32
We should use that built-in method where possible, and consider removing this function from the toolbox.

Note that Array#flat defaults to a shallow flatten with depth = 1. To mimick underscore, we'd need to do something like:
arr.flst(infinity);


Implement client for gateway eidasSamlParserService

EID-1317 Ensure EidasSamlParserResponse fields are not blank  …
We should always have a value for these fields. Using NotBlank will
ensure they're not null and have at least one non whitespace character.
EID-1323 Implement client for EidasSamlParserService  …
This moves the EidasSamlParserService to the gateway as this is the only
place it will be used.
It implements the client for it to call the eidas saml parser, as well
as the configuration.
A service is being generated in the GatewayApplication class, ready to
be passed into the new resource when we register it on the environment.
EID-1317 Check response for errors and validate DTO …
The NotBlank annotations on the DTO are not actually checked until you
use a validator on the object.
This also checks the status code on the response, as well as if the
entity is correct (can be processed).
If any of these things fail they'll raise a custom error message. This
can later be handled with a mapper.
EID-1323 Use jsonClient from ida-utils  …
It handles errors for us and removes some boilerplate.

The JsonClient is a wrapper around a normal jersey client (an error handling one), and a response processor which handles extracting the response json and generating the object you're after from it.


Improve Husky pre-commit script

Changes

Improve Husky pre-commit script

Context
Fixes #465.
I ran ShellCheck on the script and kept fixing stuff until it stopped complaining. 😄
The Husky pre-commit now works for me on Gitpod, please verify it works on your workstation as well.

Nice! I'll check it later and let you know.


Fixed the height of empty date/datetime fields on iOS.

This is a tough one because Semantic-UI doesn't really have official
date/datetime support, but without this on iOS the heights of these
fields when they are empty are completely collapsed.  Once they are
filled with a value, they are fine.  This just sets a min-height so
they are consistent with the other elements until the date is selected.
And 38px seems like the right value to use.
Tested on PC/Mac Desktop Chrome, Safari on Mac, and iOS 8.4 with Chrome on iPad 2/iPhone 6.

This commit should be in Semantic-UI. I leave the design part to Semantic-UI team.

Fair.  They've been touting an actual date-picker for quite some time now, which I assume will happen sometime in 2.0, maybe.  So I just had this lying around for now-- pretty much just pushing all my various mods out to your branch.  But ya, I prefer to leave the design part to someone else too - not my thing.
Cheers


allow indexes on nullable attributes

Description
Allow indexes on nullable attributes
closes #7204
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[x] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
[x] If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

Processing this pull request

Processing this pull request

Merged into branches master in dc06eb72d08c0f8d17eec9816e3562c153b2f58c

Processing #7772.


try using "/" to force connection to current server

🚀 Overview:
@lilitkarapetyan has explained that we could use "/" as the REACT_APP_SERVER_PATH to force a connection to the current host.
This PR tests that suggestion.
🔗 Link to preview
[If you're on a project which auto-deploys branches, link to the branches preview link here]
🤔 Reason:
Lilit's strategy is almost certainly better than Ian's.
🔨Work carried out:
Just trying "/" as REACT_APP_SERVER_PATH
🖥 Screenshot
[If the work is UI related then paste a screenshot of the update here.]

I don't think we're ready for this.
If we adopt this strategy, we need to remove the previous workaround (use current window URL if REACT_APP_SERVER not present.

@IanMayo if that's the case then let's reject the PR and close this branch down. The single-line change can be re-implemented at a later date and it keeps the repo clean.


Matrix to Telegram Bridge is not working

Describe the bug
I am using 3 protocols:
Telegram, IRC and Matrix
The IRC and Matrix have no problem but Telegram can not listen to the Matrix bot. I mean IRC and Matrix can listen to the Telegram messages but Telegram users can not listen to Matrix users only.
To Reproduce
I have this server and using the latest docker 42wim/matterbridge
Expected behavior
Already it was working great. I don't know after witch update it's happened.
Screenshots/debug logs
How can i start the docker by debug mode?
 Things may break." prefix=main
time="2021-05-30T06:49:09Z" level=info msg="Opening log file /var/log/matterbridge.log" prefix=config

Additional context
Please add your configuration file  (be sure to exclude or anonymize private data (tokens/passwords))

The problem has gone !


Error: Unsupported request method: kotlin/buildOutputLocation

Hi all, I tried installing this extension as I believe it should resolve the 'cannot be resolved' error when importing Kotlin classes into a Java file.
I built and installed the extension according to the readme file, but on trying to use it I still get the cannot be resolved errors, and see this in my log:
[2022-05-21 14:33:49.140] [exthost] [error] Activating extension fwcd.vscode-java-kotlin failed due to an error:
[2022-05-21 14:33:49.140] [exthost] [error] Error: Unsupported request method: kotlin/buildOutputLocation
    at handleResponse (/home/c/.vscode-server/extensions/fwcd.kotlin-0.2.26/node_modules/vscode-jsonrpc/lib/common/connection.js:477:48)
    at processMessageQueue (/home/c/.vscode-server/extensions/fwcd.kotlin-0.2.26/node_modules/vscode-jsonrpc/lib/common/connection.js:292:17)
    at Immediate.<anonymous> (/home/c/.vscode-server/extensions/fwcd.kotlin-0.2.26/node_modules/vscode-jsonrpc/lib/common/connection.js:276:13)
    at processImmediate (node:internal/timers:464:21)

I'm using VSC 1.67.2 on Windows, but I compiled and installed the extension remotely on my Debian 10 development machine.
It's entirely possible that a) I have misunderstood the purpose of this extension, and b) I've done something silly, but if anyone could help I'd appreciate it very much. Cheers.

Hey @C-Lunn
I haven't looked at this in a while, but I think what you're missing is the latest code for the kotlin-language-server. The latest changes that make this possible were not released yet as far as I'm aware, which means vscode-kotlin is not yet using them.
To make this work for now, you need to build the kotlin-language-server yourself (shouldn't be difficult, take a look at the readme) and use the kotlin.languageServer.path property from vscode-kotlin to let the extension know where the server executable is located.

Hi. Many thanks for this. I'll look into it.


Add some integration tests for internal.query

@artem-zinnatullin check, please

A W E S O M E :+1:

updated

:+1:


add script to install lightspeed plugin

What does this PR do?:
Adds a script to install/configure lightspeed dynamic plugin to RHDH. As part of this, the backstage config had to be modified to contain base URL for the app and the CORS settings to enable dynamic plugin asset loading.
PR acceptance criteria:
Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened and linked to this PR, if they are not in the PR scope due to various constraints.

[x] Tested and Verified

[x] Documentation (READMEs, Product Docs, Blogs, Education Modules, etc.)

How to test changes / Special notes to the reviewer:

I wonder if this should be baked into https://github.com/redhat-ai-dev/ai-rhdh-installer/pull/10 or if we rebase / revisit this PR after it is merged? It looks to me though like we could just install Lightspeed along with all the other plugins? wdyt @michael-valdron

@michael-valdron I've reworked the configuration into the new script, feel free to take a look :)

@Jdubrick @michael-valdron any chance to get this merged?