text:
Uncaught LocalProtocolError

Hey there, first of all many thanks for providing this great library!
I'm running version 0.9.2 but I think it might be still relevant.
Websocket server had some ongoing maintenance and was dropping connections from time to time. Looks like this lead to the issue seen below. Should this wsproto error maybe be mapped to ConnectionClosed?
File "/pex-app/lib/python3.10/site-packages/trio_websocket/_impl.py", line 937, in send_message
      await self._send(event)
    File "/pex-app/lib/python3.10/site-packages/trio_websocket/_impl.py", line 1249, in _send
      data = self._wsproto.send(event)
    File "/pex-app/lib/python3.10/site-packages/wsproto/__init__.py", line 64, in send
      data += self.connection.send(event)
    File "/pex-app/lib/python3.10/site-packages/wsproto/connection.py", line 107, in send
      raise LocalProtocolError(
  wsproto.utilities.LocalProtocolError: Event TextMessage(data='...', frame_finished=True, message_finished=True) cannot be sent in state ConnectionState.REMOTE_CLOSING.

I guess so, but the definition of that exception is quite blurry.  If it's a programming error, I wouldn't want it suppressed as ConnectionClosed.
    Indicates an error due to local/programming errors.

    This is raised when the connection is asked to do something that
    is either incompatible with the state or the websocket standard.

For what it's worth, our app has never hit this exception, running 1000's of instances for years.

I notice there are only two calls of wsproto.send(), and the other one checks state first:
 if self._wsproto.state == ConnectionState.OPEN:
    self._wsproto.send(CloseConnection(code=close_reason.value))

it's a little troubling that this send-when-closing case isn't exposed by the autobahn test suite, but perhaps it's very timing sensitive.

And I don't understand this code, explicitly calling send if the state is REMOTE_CLOSING:
https://github.com/HyperionGray/trio-websocket/blob/5613f20ab47c653633a08f73788f7bb459853d20/trio_websocket/_impl.py#L1100-L1101

And I don't understand this code, explicitly calling send if the state is REMOTE_CLOSING:

apparently sending CloseConnection is allowed during REMOTE_CLOSING:
https://github.com/python-hyper/wsproto/blob/88d5efaa16c798747522781d625f137bae2ca15b/src/wsproto/connection.py#L97-L105

For what it's worth, our app has never hit this exception, running 1000's of instances for years.

I see, we're running an old wsproto (0.14), but the change of raising LocalProtocolError for a text message is very recent (1.2.0):
https://github.com/python-hyper/wsproto/commit/b0efe554cca8ac24dcf82940137d04c90351c9c1

It might be a race condition.  When trio-websocket receives a CloseConnection event, it doesn't set it's local state to closed (via _close_reason) immediately.  First it sends the CloseConnection reply to the peer.  So if send_message() is called during this period, it would case a LocalProtocolError with wsproto >= 1.2.0.
https://github.com/HyperionGray/trio-websocket/blob/5613f20ab47c653633a08f73788f7bb459853d20/trio_websocket/_impl.py#L1092-L1102

For good measure, I'm asking wsproto to clarify state change timing.
https://github.com/python-hyper/wsproto/issues/181

autobahn client test hits a LocalProtocolError, but it's a different case (ConnectionState.CLOSED):
ERROR:client:  runtime exception during test case 7.1.6
Traceback (most recent call last):
  File "client.py", line 72, in run_tests
    await run_case(args.url, case)
  File "client.py", line 40, in run_case
    await conn.send_message(data)
  File "/.../trio_websocket/_impl.py", line 945, in send_message
    await self._send(event)
  File "/.../trio_websocket/_impl.py", line 1257, in _send
    data = self._wsproto.send(event)
  File "/.../venv/lib/python3.7/site-packages/wsproto/__init__.py", line 64, in send
    data += self.connection.send(event)
  File "/.../venv/lib/python3.7/site-packages/wsproto/connection.py", line 108, in send
    f"Event {event} cannot be sent in state {self.state}."
wsproto.utilities.LocalProtocolError: Event TextMessage(data='Hello World!', frame_finished=True, message_finished=True) cannot be sent in state ConnectionState.CLOSED.

Unfortunately, send_message() is defined as raising ConnectionClosed if a connection is closed, but the case where a close is in progress is left undefined.  The current implementation (with wsproto < 1.2.0) silently ignores the send.
https://github.com/HyperionGray/trio-websocket/blob/ad402206a801b668cc0c0a80dd0ea994b96aa041/trio_websocket/_impl.py#L929-L936

repo: HyperionGray/trio-websocket


text:
[MPC_Node-6] process has died

When i set "2D nav Gaol" in Rviz , occurs this error!
cppad-20160000.1 error from a known source: vector: index greater than or equal vector size Error detected by false result for     i < length_ at line 477 in the file      /usr/include/cppad/utility/vector.hpp MPC_Node: /usr/include/cppad/utility/error_handler.hpp:207: static void CppAD::ErrorHandler::Default(bool, int, const char*, const char*, const char*): Assertion false' failed.
[MPC_Node-6] process has died [pid 5762, exit code -6, cmd /home/qlp/catkin_ws/devel/lib/hypharos_minicar/MPC_Node __name:=MPC_Node __log:=/home/qlp/.ros/log/22928914-c330-11ea-98f8-000c29253a31/MPC_Node-6.log].
log file: /home/qlp/.ros/log/22928914-c330-11ea-98f8-000c29253a31/MPC_Node-6*.log
`

According this file  HyphaROS MiniCar (1/20 Scale MPC Racing Car)，
IN Install from source (16.04) -->create your own catkin_ws   ---> catkin_make
it occurs some warning, may be this cause  [MPC_Node-6] process has died ?
Thanks for your reply!
Scanning dependencies of target MPC_Node Scanning dependencies of target Pure_Pursuit [  5%] Building CXX object hypharos_minicar/CMakeFiles/Pure_Pursuit.dir/src/Pure_Pursuit.cpp.o [ 11%] Building CXX object hypharos_minicar/CMakeFiles/MPC_Node.dir/src/MPC.cpp.o [ 17%] Linking CXX executable /home/qlp/catkin_ws/devel/lib/hypharos_minicar/Pure_Pursuit [ 17%] Built target Pure_Pursuit Scanning dependencies of target ydlidar_node [ 23%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/src/ydlidar_node.cpp.o In file included from /home/qlp/catkin_ws/src/ydlidar/sdk/include/ydlidar_driver.h:10:0,                  from /home/qlp/catkin_ws/src/ydlidar/sdk/include/CYdLidar.h:4,                  from /home/qlp/catkin_ws/src/ydlidar/src/ydlidar_node.cpp:12: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::show(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:40:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::message(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:53:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::warning(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:69:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::error(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:85:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::debug(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:104:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ [ 29%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/impl/unix/unix_timer.cpp.o [ 35%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/impl/unix/unix_serial.cpp.o [ 41%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/impl/unix/list_ports_linux.cpp.o [ 47%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/ydlidar_driver.cpp.o In file included from /home/qlp/catkin_ws/src/ydlidar/sdk/src/common.h:17:0,                  from /home/qlp/catkin_ws/src/ydlidar/sdk/src/ydlidar_driver.cpp:9: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::show(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:40:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::message(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:53:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::warning(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:69:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::error(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:85:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::debug(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:104:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ [ 52%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/Console.cpp.o [ 58%] Building CXX object hypharos_minicar/CMakeFiles/MPC_Node.dir/src/MPC_Node.cpp.o In file included from /home/qlp/catkin_ws/src/ydlidar/sdk/src/Console.cpp:1:0: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::show(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:40:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::message(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:53:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::warning(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:69:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::error(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:85:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::debug(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:104:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ [ 64%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/serial.cpp.o In file included from /home/qlp/catkin_ws/src/ydlidar/sdk/src/common.h:17:0,                  from /home/qlp/catkin_ws/src/ydlidar/sdk/src/serial.cpp:12: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::show(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:40:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::message(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:53:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::warning(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:69:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::error(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:85:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::debug(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:104:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ [ 70%] Building CXX object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/CYdLidar.cpp.o In file included from /home/qlp/catkin_ws/src/ydlidar/sdk/include/ydlidar_driver.h:10:0,                  from /home/qlp/catkin_ws/src/ydlidar/sdk/include/CYdLidar.h:4,                  from /home/qlp/catkin_ws/src/ydlidar/sdk/src/CYdLidar.cpp:1: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::show(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:40:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::message(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:53:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::warning(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:69:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::error(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:85:18: warning: format not a string literal and no format arguments [-Wformat-security]        printf (out);                   ^ /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h: In member function ‘void ydlidar::Console::debug(const char*, ...)’: /home/qlp/catkin_ws/src/ydlidar/sdk/include/Console.h:104:20: warning: format not a string literal and no format arguments [-Wformat-security]          printf (out);                     ^ [ 76%] Building C object ydlidar/CMakeFiles/ydlidar_node.dir/sdk/src/lock.c.o [ 82%] Linking CXX executable /home/qlp/catkin_ws/devel/lib/ydlidar/ydlidar_node [ 82%] Built target ydlidar_node Scanning dependencies of target ydlidar_client [ 88%] Building CXX object ydlidar/CMakeFiles/ydlidar_client.dir/src/ydlidar_client.cpp.o [ 94%] Linking CXX executable /home/qlp/catkin_ws/devel/lib/ydlidar/ydlidar_client [ 94%] Built target ydlidar_client [100%] Linking CXX executable /home/qlp/catkin_ws/devel/lib/hypharos_minicar/MPC_Node [100%] Built target MPC_Node

find HyphaROS_Simulation_Stage.launch delete following:

ok

There is no effective way!
i will try reinstall ubuntu and ros....

I was faced with same problem as you do. You can just reinstall ipopt to solve the problem. Remember to follow the steps in the doc file of this very package.

source: gharchive/issue

authors: Curiosi-Orch sxxa-qlp

license_type: permissive

license_source: github-api


text:
Fix user objects not linked in slack and email messages

The messaging module use model's get_absolute_url method
to determine and link a model object to its page.
The user model is linked in the slack messagge template but
didn't have get_absolute_url().

@theskumar  The test "test_lead_not_saved_on_activity" fails, did a test rerun but the same test fails so something changed.

Will take a look, ideally things shouldn't have change or been connected.

Found the issue in the here
https://github.com/HyphaApp/hypha/blob/0df974b2fd05a9bad73a048ebb5aee89629974e3/hypha/apply/activity/adapters/activity_feed.py#L208-L216
Based on the name of the test... test_lead_not_saved_on_activity, this doesn't correlate why the activity feed should not store the related object if it's provided.
I propose to update the test, so that it saves the related=user in the Activity table when passed to the send_message.

source: gharchive/pull-request

authors: frjo theskumar

repo: HyphaApp/hypha


text:
fix: SSL error for USA KIA

Hi.  Sorry for the out of the blue PR from a random contributor on the internet.
Please see https://github.com/Hyundai-Kia-Connect/kia_uvo/issues/913
This PR sets the 0x4 flag on the SSL context for the KIA USA SSL adapter.
Thank you for your great work!

Thank you for this!

authors: cdnninja npike

license: MIT


text:
Display the EV battery temperature?

Hi, have been using this and it works fine inside HA.
I have a KIA EV6 in EU
Is it possible to get the EV battery temperature and a symbol gor pre-Heating ?
It should really helpful to see info regarding battery pre-heating that start automaticly when drivning long range and you look for fastest (shortest) possible charging time.

Is this in app?

No, not in the KiaConnect.
You need to use OD2B connection to reach this at the moment.
/TB
Den tors 6 apr. 2023 23:39cdnninja @.***> skrev:

Is this in app?
—
Reply to this email directly, view it on GitHub
https://github.com/Hyundai-Kia-Connect/kia_uvo/issues/620#issuecomment-1499659602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATTNM6TGORT3FVNBWN4QTTDW74ZYDANCNFSM6AAAAAAWVDQXLU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Then not something we can add.


text:
decoder blue boxes

Hi again
Checking your model implementation I realized that you decoder blue box outputs 32 channels and then you apply a final conv layer into the 3 output channels
I think that the blue box is the one that maps from 32 to 3 output channels since no extra layer is drawn in the paper.
The paper says:
"The end of the decoder has the same spatial size as the original image, and the number of features equal to the initial input feature size, followed by 1x1x1 convolution into 3 channels and a sigmoid function."
I think that "the end of the decoder" here means the output of the last green block and the 1x1x1 convolution that follows is the blue box
I have also found this implementation that agrees with my interpretation:
https://github.com/athon2/BraTS2018_NvNet/blob/master/nvnet.py
What do you think?

@alalbiol, Sorry for my delayed response. I was busy in an academic event for the duration of the last 6 days, so could not attend to any of the issues during that time.
Thank you for pointing it out. I had a look at my code and realized that not only am I using the wrong blue block, but also the green decoder blocks in my implementation use 1x1x1 convolutions instead of 3x3x3. I will need to change the decoder blue and green blocks and make sure the output shapes match up. I have a couple of things at hand right now. So, might take some time for me to start working on this issue. Added to To-Do anyways. Thank you for your contribution.

Meanwhile, if anyone fixes this or any other issue, please submit a PR. This will be helpful for everyone.

Hi again
Checking your model implementation I realized that you decoder blue box outputs 32 channels and then you apply a final conv layer into the 3 output channels
I think that the blue box is the one that maps from 32 to 3 output channels since no extra layer is drawn in the paper.
The paper says:
"The end of the decoder has the same spatial size as the original image, and the number of features equal to the initial input feature size, followed by 1x1x1 convolution into 3 channels and a sigmoid function."
I think that "the end of the decoder" here means the output of the last green block and the 1x1x1 convolution that follows is the blue box
I have also found this implementation that agrees with my interpretation:
https://github.com/athon2/BraTS2018_NvNet/blob/master/nvnet.py
What do you think?

that means every green block kernel size should be 111 instead of 333 and every blue block kernel size should be 333???

authors: IAmSuyogJadhav alalbiol sneh-debug


text:
Что это?

Когда будут обновления? Разрабы совсем обленились! 😡

Иди тренируйся

authors: AlanMute IBKnight


text:
StaticFileServer for serving files at web site root ("/") not working

This router entry worked in Kitura 1.0 to serve a web site, and does not seem to work in Kitura 1.1.
router.get("/", middleware: StaticFileServer())
This was used to serve files fro directories such as:
/
/img
/css
etc...
Did something change in the routing logic in 1.1?  I don't see any recent changes to the StaticFileServer code.
I will post an example later today to demonstrate the problem.

Related to #821.

@youming-lin Is there an ETA on the fix for this? This broke the kitura-starter sample app -> static content not served.

@rolivieri I've found the cause of the issue and is currently working on a fix. ETA two more days, no guarantees though.

I was going to put together a sample app to demonstrate the issue, but it looks like we can duplicate things with https://github.com/IBM-Swift/Kitura-Sample.  If you still need an example project, let me know.

Hi @youming-lin is this fixed now? If so, please move to Validate :)

@ianpartridge Not yet, it's currently awaiting review: #845

PR has been merged. Fix should be in Kitura 1.1.2 now.

authors: dsperling ianpartridge rolivieri youming-lin

repo: IBM-Swift/Kitura


text:
Support _total parameter in search requests

Is your feature request related to a problem? Please describe.
https://www.hl7.org/fhir/search.html#total
The _total parameter is trial-use, but could be useful in cases where the client wants to improve performance by bypassing the resource count calculation (which requires a separate database query).
Per the spec:
none        There is no need to populate the total count; the client will not use it
estimate    A rough estimate of the number of matching resources is sufficient
accurate	   The client requests that the server provide an exact total of the number of matching resources

Team Discussion:
In our implementation we are only going to support 'estimate' as 'accurate'
Describe the solution you'd like
Implement _total as described in the spec.
Describe alternatives you've considered
Ignore _total and rely on existing count query implementation.
Additional context
N/A

Added the label to bulkdata, it would cut the queries in nearly a half.  For a 12K export that would mean about 24 queries at 100ms each is 2.4 seconds of saved time. In very large environments, this adds up.
More specifically this benefits PatientChunkReader

We may want to add support for this _total parameter on the history operations as well.  For whole-system history, we think it should continue to default to no total, because that is the current behavior and its the only way to make it performant enough for a "changes feed".

I dug into it a bit more.

If the total is known, then the _page automatically gets reduced back to the last page if you pick too big of a number.  It generates an OperationOutcome for it, but just throws it away.
If we did not do this, then the OFFSET used in the internal query would just return no results back, so that looks good.

In FHIRPersistenceJDBCImpl.search(…) the total is used to determine matched vs included, if the _include/_revcinclude parameters are used.  So may need to disallow _total in combination with _include/_revinclude.

I think there would be a way out needing to do the match vs included calculation at all by adding "includeType" to the ResourceDTO since the underlying query does use a SORT_ORDER specifically for that.  If it's worth doing, that is.

There is a little bit of validation with paging and the calculation of the next page link that detects if a request would be beyond the last page. If the _total is not "accurate", then if we skip the total page calculation to save on performance, then we would need to ensure that requests beyond the last page behave in a reasonable matter, since we would no longer know which page is the last without having the total.

I think we would always return a next page blindly.
For BulkData I would run a total=accurate enabled search, and switch to _total=none, and control the paging in the bulkdata code.

1. If we don't have the total, then we don't know if we are on the last page. Today, if we know we are on the last page, we don't return a "next" link.  Without the total, seems like we would always return it if the current page is full (or maybe just always).

We could just return the next page, and the next page would be empty.

2. If we don't have the total, then we don't know if the caller is requesting a page beyond the last page. As long as the internal query can handle it, I think we would just try to run the query and get nothing back.  Unless there's some problem with requesting _page=12345678, when there's only 1 total record.

👍🏻 I like this approach.

I dug into it a bit more.
1. If the total is known, then the _page automatically gets reduced back to the last page if you pick too big of a number.  It generates an OperationOutcome for it, but just throws it away.

Interesting, did not know we did that....

2. If we did not do this, then the OFFSET used in the internal query would just return no results back, so that looks good.

👍🏻

In FHIRPersistenceJDBCImpl.search(…) the total is used to determine matched vs included, if the _include/_revcinclude parameters are used. So may need to disallow _total in combination with _include/_revinclude.

👍🏻 I totally agree on the disallowed combination and we'd just update our conformance.md

I think there would be a way out needing to do the match vs included calculation at all by adding "includeType" to the ResourceDTO since the underlying query does use a SORT_ORDER specifically for that. If it's worth doing, that is.
It's intriguing. It may be beyond the scope here?

Since there's an issue for allowing the currently-disallowed combination of _sort + _include/_revinclude, https://github.com/IBM/FHIR/issues/1915, I think deferring this as well.  Then the combination of _total + _include/_revinclude and be considered a future enhancement.  I'll open an issue for that to size and prioritize.

Verified:
?_total=nonsense             error, as expected
?_total=none                 no total
?_total=estimated            total calculated and included in bundle
?_total=accurate             total calculated and included in bundle
?_total=none&_include...     error as expected
?_total=accurate&_include... error, but ought to succeed. Can be addressed in #2070

authors: lmsurpre prb112 punktilious tbieste

repo: IBM/FHIR


text:
bundle search parameters that target entry resources (composition and message)

Why can't the information be obtained in the second picture(Bundle?composition:Composition.status=final)?
I tried both v4.7.1 and v4.8.3 and the results are the same (Total always is "0")

Seems like a specific instance of the more general case we'd need to support for #2732

Note:  Bundle also has a very similar search parameter Bundle-message.  Its just like Bundle-composition but for messages instead of documents.

@owencch given the cost of storing all contained resources in all cases, we thinking it might be better for you to define your own custom search parameters for just the fields you want.  For example, in this case you could introduce your own search parameter for Bundle-composition-status with an expressions like Bundle.where(type='document').entry[0].resource.as(Composition).status.  Let us know if you need some hints/examples for how to do that.

Yes, We need some hints/examples to illustrate how to do this, please let
us know.
Lee Surprenant @.***> 於 2021年8月30日 週一 下午11:00寫道：

@owencch https://github.com/owencch given the cost of storing all
contained resources in all cases, we thinking it might be better for you to
define your own custom search parameters for just the fields you want. For
example, in this case you could introduce your own search parameter for
Bundle-composition-status with an expressions like
Bundle.where(type='document').entry[0].resource.as(Composition).status.
Let us know if you need some hints/examples for how to do that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IBM/FHIR/issues/2689#issuecomment-908415995, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3LKEP4OQ3ZYR7WDLVRJTTT7OMKNANCNFSM5CI2EZYQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@owencch the docs for that are at https://ibm.github.io/FHIR/guides/FHIRSearchConfiguration#11-tenant-specific-parameters.  assuming your are using a single tenant named "default", you'd populate config/default/extension-search-parameters.json with a collection that has one or more custom search parameter definition.
There is an example in 1.1.1 of that guide and you can try modifying that into what you want.  Something like this:
{
   "resourceType": "Bundle",
   "type": "collection",
   "entry": [{
      "fullUrl": "http://ibm.com/fhir/SearchParameter/Bundle-composition-status",
      "resource": {
         "resourceType": "SearchParameter",
         "id": "Bundle-composition-status",
         "url": "http://ibm.com/fhir/SearchParameter/Bundle-composition-status",
         "version": "4.0.1",
         "name": "composition-status",
         "status": "draft",
         "experimental": true,
         "description": "The status of the Composition in this document bundle",
         "code": "composition-status",
         "base": ["Bundle"],
         "type": "token",
         "expression": "Bundle.where(type='document').entry[0].resource.as(Composition).status",
         "multipleOr": true,
         "multipleAnd": true,
         "modifier": []
      }
   }
}

Adding some design notes
issue2689DesignNotes.docx

authors: lmsurpre michaelwschroeder owencch


text:
Implement payload offload support for Azure Blob

Is your feature request related to a problem? Please describe.
Relational database systems are not best suited to storing large objects. This can lead to increase runtime costs as well as scalability limitations.
Describe the solution you'd like
Following the groundwork done in #1869 and #2900, implement payload persistence offloading for Azure Blob.
The solution must provide a mechanism for cleaning orphaned records which may remain after a failed transaction.
The solution should consider using asynchronous patterns for storing and fetching the payload data. This will be important when processing large bundles to maintain acceptable response times.
Describe alternatives you've considered
Accept the limitations and cost of keeping the payload within the RDBMS.
Acceptance Criteria
GIVEN a server configured with payload persistence for Azure Blob enabled
AND a new resource is ingested
WHEN the transaction is successful
THEN the resource can be read back
AND the payload can be found in the offload storage
GIVEN a server configured with payload persistence for Azure Blob enabled
AND a new resource is ingested
WHEN the transaction is rolled back
THEN the payload can not found in the offload storage
GIVEN a server configured with payload persistence for Azure Blob enabled
AND a new resource is ingested
WHEN the transaction fails and rollback is not possible (e.g. network partition)
THEN the payload is removed from the offload storage after the cleanup reconciliation process is run
Additional context
Design discussion to be had regarding how, where and when to run the transaction cleanup process.
The payload persistence mechanism is not tied to a Liberty Datasource so Liberty's transaction recovery mechanism doesn't apply. The discussion is really about whether the cleanup process should be a separate standalone job, or a background thread started by the FHIRServletContext.
Work for this feature should consider #2900 which implements the same offloading mechanism using Cassandra.

Was running some concurrent create/delete and this seems to have caused a issue with Azure.Blob offload active.

Tested many scenarios with Azure.blob offload, and currently I have not found any new problems.  Closing issue


text:
issue #2145 - add MaturityLevel javadoc and annotation to model classes

Also updated copyrights to 2021.
Signed-off-by: Lee Surprenant lmsurpre@us.ibm.com

Left one minor comment, otherwise LGTM.

Do you think the @MaturityLevel annotation should be after the @Generated annotation indicating that "everything below the @Generated annotation is generated"?

authors: JohnTimm lmsurpre tbieste


text:
$map function is throwing exception when an array has only one element

There seem like a bug in the $map function. when I try to run this expression (https://try.jsonata.org/vga_ZLC4c) on jsonata console it works fine but not in Jsonata4Java library.

I tried this with the current code and it seemed to work:
Attempting to load JSON from file: dataobject_9.json
Using json:
{
  "subscriptions" : [ {
    "entitlementIds" : [ "30a2aad62" ]
  } ]
}
Enter jsonata expression (or q to quit):
subscriptions.entitlements != null
false
Enter jsonata expression (or q to quit):
subscriptions.entitlementIds != null
true
Enter jsonata expression (or q to quit):
{ "ProductEntitlements": subscriptions.entitlementIds != null ? [ $map(subscriptions.entitlementIds, function($string) { { "EntitlementId" : $string } })] : [] }
{
  "ProductEntitlements" : [ {
    "EntitlementId" : "30a2aad62"
  } ]
}


text:
NumberFormatException - $.predictions[0].probability

Hi,
I am trying to call the Image Caption Generator from Android app via RetroFit2.
When i try to test the API with the default image available in the Emulator I am getting the following exception.
My Guess is that this issue is from the API, Please correct me if I am wrong.
com.google.gson.JsonSyntaxException: java.lang.NumberFormatException: Expected an int but was 9.84082025545015e-05 at line 1 column 140 path $.predictions[0].probability
com.google.gson.internal.bind.TypeAdapters$7.read(TypeAdapters.java:245)
com.google.gson.internal.bind.TypeAdapters$7.read(TypeAdapters.java:235)
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129)
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220)
com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:82)
com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61)
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129)
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220)
retrofit2.converter.gson.GsonResponseBodyConverter.convert(GsonResponseBodyConverter.java:37)
retrofit2.converter.gson.GsonResponseBodyConverter.convert(GsonResponseBodyConverter.java:25)
retrofit2.ServiceMethod.toResponse(ServiceMethod.java:119)
retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:218)
retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:112)
okhttp3.RealCall$AsyncCall.execute(RealCall.java:141)
okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
java.lang.Thread.run(Thread.java:764)

My Bad.
I had this probability variable as Int instead of Float.
@Expose
private float probability;
Now able to call the API and receive response without issues.
Hope this answer helps someone. Thanks

repo: IBM/MAX-Image-Caption-Generator


text:
[TileCatalogNew] not responsive

Describe the bug
TileCatalogNew is not responsive when resizing the window.
To Reproduce
Steps to reproduce the behavior:
Render the catalog in a flex container and resize the window to a smaller size.
Expected behavior
Expect tiles to rearrange dynamically based on screen size.

:tada: This issue has been resolved in version 2.79.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: IBM/carbon-addons-iot-react


text:
Accessibility Violations: The ARIA attribute 'aria-label' is not valid for the element  with ARIA role 'none'

Is this issue related to a specific component?

> What did you expect to happen? What happened instead? What would you like to see changed?
The ARIA attribute 'aria-label' is  valid for the element <header> with ARIA role 'none'

What browser are you working in?

Mozilla

What version of the Carbon Design System are you using?

"carbon-components": "^10.56.0",
"carbon-components-angular": "^4.59.8",

Screenshots or code

Can you please share your implementation of ibm-header?

I was not able to reproduce the problem.

Check this CodeSandbox: https://codesandbox.io/s/carbon-components-angular-2183-wsl66n
The code CodeSandbox package.json:
...,
"carbon-components": "10.57.2",
"carbon-components-angular": "4.59.9",
...

Can you try to reproduce this in a CodeSandbox app?

we have also same code as codesand , once will update to 10.57 and let yo know if we get same issue

We are also having carbon components latest version , Even though we have added same code  in CodeSandbox, unable to reproduce the violation .

Any updates from this issue

We are unable to reproduce the issue in CodeSandbox, but still we are getting same issue.

Hi, is there an update on this issue?

Closing issue since it cannot be reproducible via storybook and codesandbox.

authors: Akshat55 PallaviPattikuntapalli maicongodinho sant-santhiya

repo: IBM/carbon-components-angular


text:
Evaluate form control inputs and composition

We should take inventory of all our form controls structure and inputs, and make sure they're as standardized as possible.
Generally we should follow standard HTML conventions, and deviate where needed (for styling or usability reasons).
We should support simple built in labels, helper text, and error states, as well as fully customized variants. This may require adding an extra wrapper component and removing bx--form-item from each form control - or something completely different (discussion open)
More to come ...

It seems like we've settled on an approach via #524 and #525 - next steps are just making sure we're consistent with all our form components


text:
feat: add CRDs for v1 api

This PR is building up on https://github.com/IBM/composable/pull/91 and aims at adding CRDv1 support (fixing #88).
The final mitigation will be a migration to kubebuilder v3

Closing in favour of #97

repo: IBM/composable


text:
Add GetQueryParam utility method to support pagination

This PR adds a small utility method to extract the value of a query parameter from a URL string.  This will be used in the pagination support for Go.

I've marked this as a draft because I think we should hold off merging until the rest of the pagination support is worked out, but I wanted to post this to get feedback on the design/implementation.

:tada: This PR is included in version 5.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: ibm-devx-automation mkistler

repo: IBM/go-sdk-core


text:
Operator CRD migration from v1beta1 to v1

Migrate operator CRD from v1beta1 to v1

Changes required :

file name change 2.3.0/ibm-spectrum-scale-csi-operator.v2.2.0.clusterserviceversion.yaml  should be 2.3.0/ibm-spectrum-scale-csi-operator.v2.2.0.clusterserviceversion.yaml

oc-olm-test-playbook.yaml, you can add 2.3.0 in below section
OPERATOR_VERSIONS:

1.0.0
1.1.0
2.0.0
2.1.0
2.2.0
and same is for k8s-olm-test-playbook.yaml file

Done

repo: IBM/ibm-spectrum-scale-csi


text:
Improve PortSetPair

Instead of handling named ports separately in PortSetPair, add some global mapping from named ports to integers so that they are handled within the CanonicalHyperCubeSet.

Due to limited functionality of named ports, added relevant assertions , and assumptions in documentation.

repo: IBM/network-config-analyzer


text:
Unexpected inline_response_schema warning when the schema $ref points to another file

Using: ibm-openapi-validator@0.51.3
Related to: #125

Hello 😄
When using a ref to a response that exists in another file, I get the following warning:
[Warning: inline_response_schema] paths./.get.responses.200.content.application/json.schema (36)
 Response schemas should be defined with a named ref.

Thing is, I think I am using a named ref, it just points to another file...
Excerpt from my index.yml
paths:
  /:
    get:
      ...
      responses:
        "200":
          $ref: "./models/visits.yml#/components/responses/visitItemListResponse"

Excerpt from my models/visits.yml
components:
  ...
  responses:
    visitItemListResponse:
      description: "Visitor Visit List"
      content:
        application/json:
          schema:
            $ref: "#/components/schemas/visitItemList"

In addition, I get the same error using a schema ref, and skipping the response ref:
index.yml
paths:
  /:
    get:
      ...
      responses:
        "200":
          description: "Visitor Visit List"
          content:
            application/json:
              schema:
                $ref: "./models/visits.yml#/components/schemas/visitItemList"

Everything else is validating OK.
Is this expected? Is it bad to re-use responses or schemas that are already declared in another file?
I am not attempting to generate an SDK, but I'm guessing the SDK generator wants the responses to be defined in the same file...
Not an urgent issue 😃

Hi @brendansafr - sorry for the delay in response. It is not bad to re-use schemas declared in another file. The tool is supposed to be able to handle API definitions defined across multiple files - this may be occurring due to a bug in the parsing logic. Have you tried this with any later versions?

Good call! No rush :) I'll give it a go on the latest version :D

I created a StackBlitz and can confirm, the warning I received goes away using ibm-openapi-validator@0.81.0. I'll upgrade to the latest version 😄 Thank you!

repo: IBM/openapi-validator


text:
🛑 IDR (dataset 369) is down

In bdf847b, IDR (dataset 369) (https://idr.openmicroscopy.org/webclient/?show=dataset-369) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IDR (dataset 369) is back up in e263324 after 36 minutes.

repo: IDR/upptime


text:
🛑 IDR (well 1029401) is down

In 008af31, IDR (well 1029401) (https://idr.openmicroscopy.org/webclient/?show=well-1029401) was down:

HTTP code: 502
Response time: 166 ms

Resolved: IDR (well 1029401) is back up in efe9480 after 9 minutes.


text:
🛑 IDR (well 1046336) is down

In 3eff193, IDR (well 1046336) (https://idr.openmicroscopy.org/webclient/?show=well-1046336) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IDR (well 1046336) is back up in c6aab2e.


text:
2015 pilot state machine.

I've started scribbling down an FSM similair to last years, but I think this one might be simple enough to just do linearly.
ie:
line-follow until T-intersection. stop.
turn.
line-follow to block.
(solve activity)
turn around.
line-follow to intersection.
(repeat to finish)

http://www.ewh.ieee.org/reg/3/southeastcon2015/track/index.html
This complicates things a lot. As it turns out, they will have intersections, so the state machine will have to account for this.

Some functionality that I would like is:

"follow_to_intersection":

Ability to differentiate intersection from right angles. (We'll avoid worrying about 4-ways for now, because I'm positive that the demo boards having them was a mistake).

Ideally, this would be handled within the follow function so that the previous function can continue working uninterrupted.

"follow_to_box"

Functionality would be similar to other follow_to_intersection. I think it might even be possible to just use follow_to_intersection, since to the IR's might not even see them as different.
It's worth noting that this function doesn't even have to tell the difference between a box and an intersection, because neither one would ever be called in a situation where it might hit the other.

turn_on_intersection

This should be easy enough to do without any huge changes. I'm working on a function in mec_driver for rotating 90 degrees, but some line-detecting intelligence in it would be useful if that's not accurate enough.

Update: turn_on_intersection is unecesary, blindly turning works fine and it just needs to get close enough for IR to see it anyway.

All that matters is being able to follow the line (including around corners) and stop whenever you hit an intersection or box.
Return values aren't important, but if you return information strings about what exactly it saw to stop, that has the potential to be useful.

Pilot will need to be updated for general navigation.


text:
Server-side generic interop and support other namespaces

Hi, this looks very nice!
However, I wanted a generic implementation of sessionStorage that also supports server side Blazor. I thought I could easily generate that myself, as follows:
namespace MyApp;

[JSAutoGenericInterop(
    TypeName = "Storage",
    Implementation = "window.sessionStorage",
    HostingModel = BlazorHostingModel.Server,
    OnlyGeneratePureJS = true,
    Url = "https://developer.mozilla.org/docs/Web/API/Window/sessionStorage",
    GenericMethodDescriptors = [
        "getItem",
        "setItem:value"
    ])]
public partial interface ISessionStorageService;

That almost works, except for two things:

The generated implementation, in SessionStorageService.g.cs, doesn't contain a using Microsoft.JSInterop; statement, so it doesn't work in another namespace.
The FromJson extension method doesn't work on ValueTask<string>, so the currently generated code doesn't work.
(Specifically in the implementation of GetItemAsync:ValueTask<TValue?> ISessionStorageService.GetItemAsync<TValue>(string key, JsonSerializerOptions? options)
  where TValue : default => _javaScript.InvokeAsync<string?>("window.sessionStorage.getItem", key).FromJson<TValue>(options);

)

As an additional note, I'd personally prefer if it wasn't required to add the FromJson and ToJson methods as extension methods to use the generic interop, as those methods now show up in the Intellisense of every object in my project (using Resharper).
Thanks for your help, and your work on this project!

Yeah, it's a bit limited right now. You could get this to work by setting the namespace of your interface to Microsoft.JSInterop:
namespace Microsoft.JSInterop;

[JSAutoGenericInterop(
    TypeName = "Storage",
    Implementation = "window.sessionStorage",
    HostingModel = BlazorHostingModel.Server,
    OnlyGeneratePureJS = true,
    Url = "https://developer.mozilla.org/docs/Web/API/Window/sessionStorage",
    GenericMethodDescriptors = [
        "getItem",
        "setItem:value"
    ])]
public partial interface ISessionStorageService;

As for the extension methods, yeah, that's a good callout. I'm still thinking on how to best address that.

Fixed in b2a509de6579457eaf14ce9cdd1286a62c768909

authors: IEvangelist rhodon-jargon

repo: IEvangelist/blazorators


text:
Use of Auth2 introspect as default

The current draft relies heavily on the use of JWT tokens (which are mandatory) as OAuth2 access tokens. The limiting factor is that all authorization decisions are to be made when the JWT authorization token is handed out, as these are codified inside the token. This means that the token contains information who the client is and what it may do. It does not take into account what the client may do at a specific server. Say for example there are two servers, named A and B, and both implement API X and Y. The token cannot indicate that a client may invoke API X at server A and API Y on server B.
To enable this, the proposal is to rely as a default on Auth2 introspect (RFC7662). The introspect call is authenticated, such that the authorization server knows which specific client-server combination to authorize. Moreover, with introspect, the access token is opaque to the clients. The structure is to be defined and understandable only by the authorization server. This gives implementation freedom that server may still use JWT, but it may also hand-out large random numbers.
Using introspect makes that the IUA could fall back fully on widely supported OAuth2 mechanisms, rather than a few IETF drafts (that are not RFCs yet) : OAuth2 authorization framework; OAuth2 bearer token headers; OAuth2 introspect
The SAML and JWT tokens are still possible as options, using the custom authorization header methods. Clients that do not support these types of tokens would still be able to treat them as opaque bearer tokens and offer them to the introspect endpoint to get them validated and receive the contents (in JSON format).
The introspect result can be identical to the IUA JWT contents in structure, including the IUA and BPPC extensions, with the addition of the active field as defined in RFC7662.

Using introspection in IUA would be a breaking change to the current profile. I personally like it, since the access token is just an ID and the resource server exchanges the access token to the data it requires to authorize. But this would really be a big change and would also not be compatible with SMART on FHIR. Thus I didn't follow this path, when reworking the IUA profile.

breaking changes are allowed during Trial Implementation. Now is a good time to make a breaking change that is the right thing to do. You can alternatively define an option that uses introspection.

It is recommended to use the introspect as a default for this profile for the reasons stated above. As such, indeed this is a breaking change. Sounds like we are not averse to breaking changes at this stage of development. How do we progress to affect this recommendation?

SMART On FHIR mandates the use of bearer tokens (see http://hl7.org/fhir/smart-app-launch/index.html#step-3-app-exchanges-authorization-code-for-access-token).
In the current IUA specification bearer tokens are an option, so to be compatible with SMART, implementers must implement that option. In that sense I would argue that by default the current IUA specification is not compatible with SMART, because of the difference in token types.
Moreover, the SMART specifications explicitly do not indicate the format of the access token. However, they also do not indicate how the access token is validated. OAuth2 Introspect would be a compatible means. Leaving it up to the authorization server to choose its token structure.
As such, my suggestion would be to promote the bearer token and introspect API to the default way of authorizing. The IHE-JWT and IHE-SAML token format would be modelled as options. Interesting about this approach is that if a client would not understand the IHE-JWT or IHE-SAML format, or would not have the logic to validate them correctly, it can still fallback to the introspect API to get these tokens validated.
The change is indeed breaking from a specification point of view, because clients and servers must understand the bearer tokens. That said, existing implementations that rely on the IHE-JWT or IHE-SAML format would not be completely incompatible, as they would just utilize those options...

Note that an important distinction IUA has vs SMART... is that IUA does not mandate a tight relationship between the authorization server and the resource server. SMART does. Thus the choice of token types can be something totally hidden from the client in SMART. In IUA this is not the case, it might be, but it is not mandated.
We did discuss today that we could add an option for introspection. This would be a signficnant add to the profile, which will be difficult to get done by our November deadline. But we will try.
@joostreuzel can you help with the addition? I can do the IHE Profiling narrative structural stuff, but don't know enough about OAuth to write any details.  How much 'profiling' of the OAuth introspection are needed? Can we just point at an OAuth defined transaction and just say the result is our JWT definition?

Introspection becomes complicated when there is not a tight relationship between the AS and the resource server, since each resource server needs to be able to authenticate to each AS in order to access the protected introspection endpoint. RFC 7662 requires authentication of the resource server but doesn't require a specific authentication method. Unfortunately, you can't use IUA in its current form to authenticate to the introspection endpoint or it creates a circular introspection dependency. To work at scale, you'd need to automate the registration and authentication of actors in this community of AS's and RS's. BTW, extensive work has been done in this area.

I would argue that with the JWT and SAML specification there is also relation between the authorization server and the resource server, as the resource server will need the right certificates (and trust in those) to validate the JWT and SAML tokens. These certificates are typically pulled (regularly) from a well-known endpoint from the trusted authorization service. In that sense, introspection does not really make difference: clients will know their trusted authorization services.
With introspect, the authorization server has knowledge of the resource servers as these will need to perform authenticated calls towards the introspection endpoint. With JWT or SAML that is not necessarily the case. Depending on the scenario this knowledge may actually be good thing: the authorization server may leverage that knowledge in its authorization logic and thus introspect response (as we do). It provides the opportunity to control which resource servers are part of your ecosystem. Resource services in such cases must be pre-registered.
For cases where there is no explicit need for the authorization server to know the resource servers, there is RFC7591: dynamic client registration that allows resource servers to register themselves.

@JohnMoehrke I would be happy to help out. RFC7662 does not leave a lot of room for profiling (as it is so simple). The elements we need to specify is the way of authentication to the endpoint (basic authentication is typically supported), and refer to RFC7591 for client registration. The latter I would provide as recommendation.

During yesterdays IUA bi-weekly meeting, we decided to add the introspection way as an option, but not as a mandatory requirement. Since we need to finish the supplement till end of October and I'm running out of time since end of October is also the due date for the changes to swiss national extensions to be finished.
Who can provide text blocks specifying the introspection requirements and the new required transaction to add this option?

I will provide the supplement structure, and let @joostreuzel fill in the details. We should make it as terse as possible.

@joostreuzel please see that I have added the supplement framework for the new transaction. Please check all my text around Introspection. The text I put in there is based on my executive level understanding. Most of what you need to do is at the end of the file in the new transaction ITI-102. It is setup with the typical IHE supplement template as a request and response. I also did include the link to the JWT constraints we have documented in 71, so please don't replicate that detail, as we can use it by reference.

Reminder my pull request was about adding the IHE profile supplement layout. I do not know enough about OAuth. So if the client is not involved, then please go ahead and make that change.

To be of use in Swiss EPR, the introspection should also be able to response a XUA compliant access token in SAML format. Can you take that into account?

The introspect call is token format agnostic. You simply pass it the bearer token as is. The Authorization Server (which handed out the token in the first place) is expected to understand its own formats... That is actually one of the reasons of the introspect endpoint: it makes both authorization client as well as resource server agnostic to the format of the token. With introspect, the only actor that needs to understand the token format is the Authorization Server, which both creates and interprets the token structure.

see #112 for the pull request

Your last commit did not update the table of content. Can you do that?

In this new model of publishing with markdown... do we want to make the table of content more sparse? I think it is not needed in an html publication to cotiunue to have anything other than H1 table of content.

I will do that...
That said. The text describes now clearly the three options for token format and validation (JWT, SAML, or via introspect). JWT is required, the others are not as agreed.
During writing, I started to be convinced that implementations should be provided with the freedom to choose one or more of these three options. The three options would become all optional, but there is an additional constraint that at least one of the three must be supported. Resource Servers that receive a token they cannot validate should simply refuse the request. Without this freedom, servers that would implement the SAML option would also (and often unnecessarily) need to implement JWT support.
Perhaps this is something to discuss on a next call.

please create a new issue for the changing of options.  This issue should be closed with the addition of the introspection option.

new issue created: #115

toc has been updated in 50daa2c2a4077d04ed972c5d5bbf4e4d436cab3a  The comments before and after hint to the use of the markdown-toc extension to vscode...

is this issue done?

I think the initial question (making introspect default) is not what we resolved here. Renaming the issue to "add introspection option" would be a better match, and we could close this issue.
In the next telco, I would still like to have the discussion on what is required and what is optional with respect to token formats/introspect. See #115.

@joostreuzel will write up an "Open Issue" for inclusion in the public comment.
@msmock will assure the open issue has counter arguments against mandatory introspection in JWT environments.

@john: I would expect a strong justification for making introspection mandatory first, since Jost clearly stated that it is easy for phillips to support the JWT option, but they just don‘t want to do it.

Am 22.10.2020 um 17:05 schrieb John Moehrke notifications@github.com:

@joostreuzel will write up an "Open Issue" for inclusion in the public comment.
@msmock will assure the open issue has counter arguments against mandatory introspection in JWT environments.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I would like to stress that the JWT option is not easy for Philips. There is explicit reliance on reference tokens, because of three reasons:

The tokens do not contain any data. Any party that gets hold of a JWT token has access to the (privacy and security) sensitive data contained in that token. This includes resource servers which access has been revoked, intermediate routers, etc. Our legal/regulatory experts have some serious issues with this.
Our authorization models make use of constructs that are not encodable in the current JWT format. Think of per resource server scope settings (while the token may be used with several resource servers simultaneously).
Resource Servers dealing with introspect will be able to handle all types of tokens (XUA, JWT, opaque). This allows them to be used in more different solution configurations without code changes.

While JWT may remove the need for introspect calls, it is not as powerful functionally, privacy and even security-wise. I would rather state that for cases where JWT is used, the introspect call is trivial to implement as it would basically just do the token validation, audience check and then return the JWT contents. Simple to implement and offer as a generic (micro-) service.
In short this not a matter of “just not willing to”. I would rather provide the counter argument: as it so trivial to implement introspect for JWT tokens, why not just offer it as a generic service in the Swiss project?

I can't see this as a strong justification:

access token are encrypted. Thus it is not justified to claim that "Any party that gets hold of a JWT token has access to the (privacy and security) sensitive data contained in that token.”

I see. It’s not up to me to criticize your design decisions. But you are mixing up authorization and policy enforcement in the resource servers and break the foundations of the standard by adding extra functionality. It’s up to Phillips to do so, but I don’t see why we should manifest that for the IHE community.

Resource server would also by prepared for the 3 token types, if we we leave the 3 options, not making introspection mandatory.

Introspection might be trivial to implement from a coding perspective. But that’s not an argument for making it mandatory in general, since it may have a big impact in real life projects.
In the Swiss electronic patient dossier IUA is used in a cross community context. To minimize the required cross community transactions and the related trade off (operational, organizational, testing, etc.), we follow a representational state transfer approach, i.e., we provide all the data in the access token which are required by the resource server to enforce the access policies. This approach is not Swiss specific and quite common in real life projects. Currently we use XUA access token only, but we are preparing to extend the EPR for mobile access using a JWT token. Thus, the introspection option is not suitable for the Swiss electronic patient dossier.
The ordinances of the law of the Swiss electronic patient dossier rely on the IHE profiles (currently 16 IHE ITI profiles). Vendors must implement the mandatory transactions of the underlying IHE profiles, as well as the Swiss national extensions. They must run conformance tests to proof compliance against a Gazelle environment (so called SIA tests). The tests cover the connectathon tests for the IHE profiles as well as the additional tests to verify compliance with the national extensions.
Making the introspection option mandatory requires the Swiss vendors to implement and proof compliance to the introspection options, although it is useless in the context of the Swiss electronic patient dossier context, since it would exchange a JWT to the same JWT or a XUA assertion to exactly the same XUA assertion.
To summarize, the introspection option does not meet the requirements of the Swiss electronic patient dossier and if mandatory, causes a high trade off (operational, organizational, testing, etc.).
If there are doubts on the interoperability of the current IUA.b requirements, I suggest to make the JWT option mandatory and all other options mandatory, as it is in the current IUA version.

On 26 Oct 2020, at 10:36, joostreuzel notifications@github.com wrote:
I would like to stress that the JWT option is not easy for Philips. There is explicit reliance on reference tokens, because of three reasons:
The tokens do not contain any data. Any party that gets hold of a JWT token has access to the (privacy and security) sensitive data contained in that token. This includes resource servers which access has been revoked, intermediate routers, etc. Our legal/regulatory experts have some serious issues with this.
Our authorization models make use of constructs that are not encodable in the current JWT format. Think of per resource server scope settings (while the token may be used with several resource servers simultaneously).
Resource Servers dealing with introspect will be able to handle all types of tokens (XUA, JWT, opaque). This allows them to be used in more different solution configurations without code changes.
While JWT may remove the need for introspect calls, it is not as powerful functionally, privacy and even security-wise. I would rather state that for cases where JWT is used, the introspect call is trivial to implement as it would basically just do the token validation, audience check and then return the JWT contents. Simple to implement and offer as a generic (micro-) service.
In short this not a matter of “just not willing to”. I would rather provide the counter argument: as it so trivial to implement introspect for JWT tokens, why not just offer it as a generic service in the Swiss project?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/IHE/IT-Infrastructure/issues/106#issuecomment-716428832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEC6MXYKPOQXYTYSGAJJVDSMU7INANCNFSM4RZSFNBA.

access token are encrypted. Thus it is not justified to claim that "Any party that gets hold of a JWT token has access to the (privacy and security) sensitive data contained in that token.”

In the current IUA specification JWT token encryption is optional. We may want to add a statement in transaction ITI-72 that resources servers MUST be able to handle JWE tokens.

I see. It’s not up to me to criticize your design decisions. But you are mixing up authorization and policy enforcement in the resource servers and break the foundations of the standard by adding extra functionality.

As perhaps expected, I don't agree there. The Authorization Server is a policy decision point, not the policy enforcement point. That does not change in our designs with introspect. It is just that policy decisions can be communicated more precisely using introspect than encoded with JWT tokens, as policy determination can happen "just in time" in the authorization process and catered towards specific resource server/client combinations. Policy enforcement still takes place at the resource servers.
Note that I do understand your case for a RESTful transaction that is all-encompassing in the sense that it carries all the necessary elements to handle the request, including any supporting (authorization) data. This reduces dependencies between systems to a bare minimum. Let me stress that it is not my intention to break this possibility. JWT is a valuable option in many situations.
Our primary use-case is different. We are not constructing a nation-wide EPD. What we try to do is construct what we call "end-2-end solutions" from a multitude of systems with varying capabilities, ranging from questionnaire providers, EMRs, (out-of-hospital) patient monitoring systems, imaging modalities, IoT solutions, etc. The challenge is to have these integrate, typically tailored to the context of a single customer or health system. Flexibility is required as different combinations of those products will be necessary for different customers. HTTP-based RESTful APIs are necessary to deal with the increase of cloud-based systems.
Many of these customers already have a user authentication mechanism in place that is able to hand out access tokens (e.g. based on OpenID). These tokens will differ in structure depending on the customer's installed base. What we offer is an authorization layer on top of the authentication systems that besides some complex authorization policies uses introspect to provide a harmonized view on these tokens. The resource servers, relying on introspect, do not need to understand the (customer specific) access token structures. Forcing the use of JWT tokens does not make sense in these situations as it would introduce a layer of complexity (e.g. token exchange mechanisms) that are unnecessary and error-prone.
Different use-cases call for different approaches. Where JWT may be more suitable in the cross-organization/community projects, introspect helps us deal with the variances in legacy systems. As such I feel this choice may need to be made at a project level, not at a general IUA level.

@JohnMoehrke should I reopen issue 2 in the document, or shall I create a new issue for this? Moreover, should I refer to this and the other threads from the issue statement?

Different use-cases call for different approaches.

That was my position from the beginning. So we agree upon not making introspection mandatory.

Am 27.10.2020 um 10:53 schrieb joostreuzel notifications@github.com:

access token are encrypted. Thus it is not justified to claim that "Any party that gets hold of a JWT token has access to the (privacy and security) sensitive data contained in that token.”
In the current IUA specification JWT token encryption is optional. We may want to add a statement in transaction ITI-72 that resources servers MUST be able to handle JWE tokens.
I see. It’s not up to me to criticize your design decisions. But you are mixing up authorization and policy enforcement in the resource servers and break the foundations of the standard by adding extra functionality.
As perhaps expected, I don't agree there. The Authorization Server is a policy decision point, not the policy enforcement point. That does not change in our designs with introspect. It is just that policy decisions can be communicated more precisely using introspect than encoded with JWT tokens, as policy determination can happen "just in time" in the authorization process and catered towards specific resource server/client combinations. Policy enforcement still takes place at the resource servers.
Note that I do understand your case for a RESTful transaction that is all-encompassing in the sense that it carries all the necessary elements to handle the request, including any supporting (authorization) data. This reduces dependencies between systems to a bare minimum. Let me stress that it is not my intention to break this possibility. JWT is a valuable option in many situations.
Our primary use-case is different. We are not constructing a nation-wide EPD. What we try to do is construct what we call "end-2-end solutions" from a multitude of systems with varying capabilities, ranging from questionnaire providers, EMRs, (out-of-hospital) patient monitoring systems, imaging modalities, IoT solutions, etc. The challenge is to have these integrate, typically tailored to the context of a single customer or health system. Flexibility is required as different combinations of those products will be necessary for different customers. HTTP-based RESTful APIs are necessary to deal with the increase of cloud-based systems.
Many of these customers already have a user authentication mechanism in place that is able to hand out access tokens (e.g. based on OpenID). These tokens will differ in structure depending on the customer's installed base. What we offer is an authorization layer on top of the authentication systems that besides some complex authorization policies uses introspect to provide a harmonized view on these tokens. The resource servers, relying on introspect, do not need to understand the (customer specific) access token structures. Forcing the use of JWT tokens does not make sense in these situations as it would introduce a layer of complexity (e.g. token exchange mechanisms) that are unnecessary and error-prone.
Different use-cases call for different approaches. Where JWT may be more suitable in the cross-organization/community projects, introspect helps us deal with the variances in legacy systems. As such I feel this choice may need to be made at a project level, not at a general IUA level.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@msmock correct. We are NOT making introspection mandatory at this time. We are just adding an open issue that explains our current situation of three modes all optional, while asking for feedback on if introspection should be made mandatory. So we are now trying to come up with the wording of the open issue..
@joostreuzel a new issue.

That was my position from the beginning. So we agree upon not making introspection mandatory.

I think the current proposal makes sense: make all mechanisms for claim derivation from tokens (JWT/SAML/Introspect) optional and move that choice to individual projects. Vendors that claim maximum conformance can always opt to implement all three.

@JohnMoehrke OK, will update the pull request.

authors: JohnMoehrke Martin-Rosner joostreuzel lcmaas msmock

repo: IHE/IT-Infrastructure


text:
don't require confidential clients to use symmetric authn

https://github.com/IHE/ITI.IUA/blob/master/IHE_ITI_Suppl_IUA.md#341-iua-actors-transactions-and-content-modules

This profile requires the use of a client_id for client identification and a client_secret used with the HTTP Basic Authentication scheme for client authentication of confidential and credentialed clients, if no other methods for identification and authentication are used.

We anticipate confidential clients in the auth code flow to increasingly move away from symmetric authentication to signed JWTs. This profile shouldn't restrict that.
Priority:

Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

The intention is not to restrict it. Authorization servers should at minimum support client_id and client_secret based authentication, but may support alternative methods. Support for these methods can be published through the meta-data document. If that needs to be phrased better, please suggest an improvement.

we should make clear this is a minimum, not a restriction.

authors: JohnMoehrke isaacvetter joostreuzel


text:
v0.7.3

Reworked navigation using new features
Fixed some bugs in library
Added state keeping in case the application gets killed by the system
Added last used servers and users for faster connection to the most recent server

Closes #78

repo: IIIuminator/EnQ


text:
🛑 Pilsudski Institute is down

In 49f4508, Pilsudski Institute (https://pilsudski.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Pilsudski Institute is back up in a6a5cdf.

repo: IJPNY/upptime


text:
程序部署在centos上以后台运行的方式启动，接口不响应

您好，请问下我程序部署在centos上以后台运行的方式启动（后面加&方式启动的），通过接口访问一直无响应，假死状态，前端运行一直正常。
很少在linux系统上部署过程序，请问下是框架不支持，还是我这边程序开发发布配置的问题？ 谢谢额

框架支持在linux下运行，你可以查看相关日志。
在运行目录下有个logs目录下有服务日志

请问下我程序部署在centos上以后台运行的方式启动（后面加&方式启动的），通过接口访问
你找supervisor进程管理器 这样的管理去管理。要不然很容易被kill 掉

框架支持在linux下运行，你可以查看相关日志。
在运行目录下有个logs目录下有服务日志

我以你提供的demo （HttpApiServer.HelloWorld）部署在linux下前端运行可以访问，如果添加&方式允许就是一直无响应假死状态

以上在前端运行正常

以上以 &后台运行 网页及接口长时间一直无响应

建议使用hosting启动
https://github.com/IKende/FastHttpApi/wiki/Hosting和DI注入控制器

建议使用hosting启动
https://github.com/IKende/FastHttpApi/wiki/Hosting和DI注入控制器

大佬，我参照你给你意见使用hosting启动，但是控制器没有起来，所有接口不可用

然后我又恢复到我原来的启动方式，由于更新到了最新版本，现在所有设置的路由跟方法名称不一致的访问请求都不可用

现在用的链接库的版本

以上路由跟方法名不一致的都不能通过路由访问，怀疑路由都失效了，是否是升级新版本后哪个配置没有设置

是的新版本重新调整了日志，日志里应该会有记录路由定义重写内容
http://doc.ikende.com/#2ca7fc0d97334f29a5154d7a063ebe83

是的新版本重新调整了日志，日志里应该会有记录路由定义重写内容
http://doc.ikende.com/#2ca7fc0d97334f29a5154d7a063ebe83

看重新路由没有问题，但是通过路由访问的提示不支持

头痛

authors: IKende lvrongwu nodyang

repo: IKende/FastHttpApi


text:
get_metadata() returns wrong values

Pay attention to the PhaseEncodingDirection field.
In [1]: from bids.grabbids import BIDSLayout

In [2]: layout = BIDSLayout("/data")

In [3]: layout.get_subjects()
Out[3]: ['100307']

In [4]: layout.get_metadata("/data/sub-100307/fmap/sub-100307_acq-EMOTIONLR_dir-1_epi.nii.gz")
Out[4]:
{'IntendedFor': 'func/sub-100307_task-EMOTION_acq-LR_bold.nii.gz',
 'PhaseEncodingDirection': 'i-',
 'TotalReadoutTime': 0}

In [5]: layout.get_metadata("/data/sub-100307/fmap/sub-100307_acq-EMOTIONLR_dir-2_epi.nii.gz")
Out[5]:
{'IntendedFor': 'func/sub-100307_task-EMOTION_acq-LR_bold.nii.gz',
 'PhaseEncodingDirection': 'i-',
 'TotalReadoutTime': 0}

In [6]: !cat /data/sub-100307/fmap/sub-100307_acq-EMOTIONLR_dir-1_epi.json
{
  "PhaseEncodingDirection": "i-",
  "IntendedFor": "func/sub-100307_task-EMOTION_acq-LR_bold.nii.gz",
  "TotalReadoutTime": 0
}

In [7]: !cat /data/sub-100307/fmap/sub-100307_acq-EMOTIONLR_dir-2_epi.json
{
  "PhaseEncodingDirection": "i",
  "IntendedFor": "func/sub-100307_task-EMOTION_acq-LR_bold.nii.gz",
  "TotalReadoutTime": 0
}

that's will be fun on fixing this issue is there any on it and want to gives it a try

authors: chrisfilo umarbrowser

repo: INCF/pybids

license: mit

license_source: bigquery


text:
🛑 dsdd.ivdnt.org is down

In 2092608, dsdd.ivdnt.org (https://dsdd.ivdnt.org/DSDD) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dsdd.ivdnt.org is back up in c3b0a97 after 14 minutes.

repo: INL/ivdnt-statusoverzicht


text:
Add all downloading options to Dataset page in view mode

Overview of the Feature Request
The goal is to add all downloading options to Dataset page in view mode.
This include: citation, files, and metadata (See mockups).
Mockup of the requested element

Process action items
Find out more about the action items in the process definition

[ ] Analyze required data access logic
[ ] Document associated API endpoints
[ ] Develop the UI element
[ ] Add the element to the page and storybook
[ ] Create spike issues if required and add them to related open or closed issues

What inspired the request?

UI discussion on Dataset page initial work

What existing behavior do you want changed?
N/A
Any brand new behavior do you want to add to Dataverse?

Add Dataset downloading options to Dataset page

Any open or closed issues related to this feature request?
Not yet

Please note that for the "Cite Dataset" dropdown we need to create an API endpoint for the various formats (Endnote XML, RIS, and BibTeX):

https://github.com/IQSS/dataverse/issues/3140

I'm not sure why I gave up on this, but long ago (2016!) I did start hacking a bit on adding this citation API: https://github.com/IQSS/dataverse/commit/c433395f4a1756ee14e669b91820047edc4db1ad

authors: GPortas pdurbin

repo: IQSS/dataverse-frontend


text:
Feat/425 publish dataset and collection

What this PR does / why we need it:
Implements the Publish Dataset feature where both the dataset and it's parent collection are not published. In this case, the Publish Dataset Modal allows the user to publish both the dataset and collection at the same time.
Note that this feature depends on a js-dataverse PR that is not yet merged: https://github.com/IQSS/dataverse-client-javascript/pull/199.  When it is merged, package.json can be updated to use the latest 'alpha' version.
Which issue(s) this PR closes:

Closes #425

Special notes for your reviewer:
I'm using feat/461-publish-collection as the base branch because it contains the integration code to call the Publish Collection js-dataverse use case.
Suggestions on how to test this:
Step 1: Run the Development Environment

Execute npm i.
Navigate with cd packages/design-system && npm run build.
Return with cd ../../.
Ensure you have a .env file similar to .env.example, with the variable VITE_DATAVERSE_BACKEND_URL=http://localhost:8000.
Navigate with cd dev-env.
Start the environment using ./run-env.sh unstable.
To verify the environment, visit http://localhost:8000 and check your local Dataverse installation.

Step 2: Test the feature

Create a collection. When it is created, it will have the 'Unreleased' status
Within the new collection, create a dataset.
On the Dataset page,  Choose Publish Dataset,  and Publish.
On the Publish Dataset Modal, there will be a text asking if you want to publish the parent collection as well as the dataset.  It will contain a link to then parent collection
Choose 'Continue' to publish the dataset and collection
When the publish is completed, check that the dataset and the collection are both published.  The dataset should be Version 1.0, and the collection should no longer have the 'Unreleased' status

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
This is not a change from the JSF, but here is what the JSF modal looks like.  'Unpublished' is the name of the parent collection.

Is there a release notes update needed for this change?:
Additional documentation:

coverage: 98.403% (+0.9%) from 97.53%
when pulling 8b7699526b33387975e5aa812d90a55db82a44fd on feat/425-publish-dataset-and-collection
into ff8ed384968784225e5a2ebd0618f7a8e332c16f on develop.

Hi @ekraffmiller could you update js-dataverse package version with 2.0.0-alpha.2, https://github.com/IQSS/dataverse-client-javascript/pull/199 is already merged, thanks!

tested in local - no issues found.
Testing of 520.docx

authors: coveralls ekraffmiller g-saracca ofahimIQSS


text:
Дефекты верстки блоков с именем пользователя

Блок с именем залогиненного пользователя отображается некорректно для устройств всех размеров за исключением extra small.
Нужно обеспечить вертикальное выравнивание аватара и имени пользователя.
Пример 1:

Пример 2:

В навбаре аватар должен отображаться слева от имени пользователя, вне зависимости от количества строк, которые занимает имя пользователя.
Пример 1:

Пример 2:

Вроде бы ничего не воспроизводится из вышеперечисленного.

authors: kovalevsky rainrb


text:
Add useful links

Добавлены полезные ссылки по следующим темам:

Написание python-кода
Практики Code review
Оформление репозитория
Форматирование кода
Комментарии в коде & Документация
Работа с github-репозиторием
Тестирование
Contribute в OpenSource
Как сделать pip-пакет
Менеджмент зависимостей
Воспроизводимость в ML-проектах

Close #8

Ну и лучше перенести в https://github.com/ITMO-NSS-team/open-source-ops/tree/master/best-practices

Не забудь кстати в заглавное README добавить ссылку.

Можно ещё вот эти 2 ссылки от Андрея внести - https://techrocks.ru/2019/04/16/good-readme-on-github/ и https://github.com/hackergrrl/art-of-readme (вторую планируем к переводу).

Можно ещё внести
https://github.com/github/github-ospo
На днях github выкатил.

authors: nicl-nno pacifikus

repo: ITMO-NSS-team/open-source-ops


text:
🛑 Website is down

In a1c9de4, Website (https://pt.ivao.aero/portal) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Website is back up in f4af26e.

repo: IVAO-Portugal/status-page


text:
[BUG] 中国版防爆玻璃破坏后会掉落

描述这个Bug
( 请描述该Bug出现后，游戏内的情况，尽可能详细 ）
复现这个Bug
（请告诉我应该如何复现这个Bug）
1.
2.
3.
4.
期望的行为
（您希望游戏做出的正确的行为是什么）
游戏内截图或视频
（您可以添加一个截图或视频链接来帮助我更好地找到Bug原因）
地图版本号
（请告诉我您正在游玩的地图版本号，一般在大厅悬浮字上）
游戏版本号
（请告诉我您正在运行的Minecraft版本号）
附加描述（备注）
（可选）

fix : commit 1d4e8e6f501e78fa498e6a37178dd7663344971b


text:
Passive Engine Re-write for Paralellism

Passive engine rewrite: Ok
General code refactor: Ok
some missing code: Fixed (Need to be tested)

@codingo @Ice3man543
Changelog

Introduced general pool backbone (applied to passive and resolver engines)
Passive engine now works in parallel

I think it would be good to make these kinds of changes in multiple commits. There's some additional refactoring I can see here but given that it's all in one commit it's a bit tricky for me to test and track the changes. I'll start that work once this is merged though (I'd already started some of it already when adding more verbose error handling, but I'll come back to it in this branch).
The code itself looks good, is there something further you're working on before merging with this?

@Mzack9999 as codingo noted, there is some scope for more refactoring here, changing the naming scheme, making some small changes to make it compatible with the latest commits i made. But, you have done an amazing work. Once you are finished, notify us and we will tidy up things a little bit.
:+1:

@codingo Probably you can review it. You also wanted to do some more refactor, right?

I do, but I think it would be best in a separate branch so we can put a release tag on this to keep everything  clean.
I'll set this up in the test bench shortly!

@Ice3man543 looks to satisfy testing on my end. Since it's a rather significant change suggest you do the same and then we can merge.

Sure @codingo

@codingo This doesn't complies with the new output style we created in ui rewrite branch. Also, there are a few things that I don't understand. Probably need to refactor some more and make this a bit more easier to understand. All in all, it's great work by @Mzack9999 :+1:
Though i am not in the mood to code, so won't review it yet. Probably tomorrow ...

@Ice3man543 let me know if you need any help

@Mzack9999 So i finally took a look at the code and ran it. The tool has became a lot more faster :smile: thanks to you. So great work :+1: Keep it up. But there are some issues with the pull request that stop me from merging it right now. It's a lot more faster though :).

Aquatone Style JSON output is not working
Output doesn't matches at some places with new standard.
Resolver logic has been messed up. Resolver should return *helper.Job structures as output so that we can output them to file. But in passive-engine rewrite branch it returns []string.

If all these mistakes can be fixed by you, then awesome. Otherwise, i am going out of town for a few days. After i return, i can fix these and merge the branch.
@codingo What do you say?

I replaced helper.Job with a more generic helper.Domain. I'll try to correct in next days the various outputs

@Ice3man543 @codingo hopefully I merged correctly the output styles from master, I just left a TODO related to output to directory which I've no time to address right now, but should be a fast fix

@Mzack9999 I am working on fixing some things. Will fix everything i can see and then merge :)

@Mzack9999 The aquatone style output is still messed up. I am working now on cleaning it. Will be done by morning i guess if i leave everything and work on this! Do you think merging it to the master is correct? Also, have you done any benchmarks? I will do them :)

Oh god, i merged it by mistake :(
@codingo Can you test the new build ?

@Mzack9999 The aquatone -nW flag output doesn't works as expected. Check it out.

@Mzack9999 @codingo No worries now. I made some chages so that it works fine. Now, everything is working as supposed and even faster due to Worker pools and create a more modular architecture :)
Thanks a lot @Mzack9999 for this. It is really appreciated. Tomorrow morning, i'll add worker pools to bruteforcer and fix some bugs, making our 1.2 release. Also, we got 200 stars. Congrats on that :+1:


text:
Make data/state param more consistent

It's called data on request in, but state on response. #fail

Now allow state to be passed where data is now used.

repo: IdentityModel/oidc-client-js


text:
Adjacency mapper fix

Because this might be easier than trying to sort out whatever got done with the other branches.

Looks good to me (and was properly built by the CI system), but EU4toVic2 is @kratostatic's show, so I'll let him merge it.

authors: Idhrendur woggy

repo: Idhrendur/paradoxGameConverters


text:
Added support for a data-confirm attribute

Hi! I really like your library, it's handy to be able to do this in frameworks other than Rails. I added a feature to allow "confirm" boxes on links; are you interested in incorporating it?

I would like to have this feature

This is definitely a good idea but onclick passive js code is replaced by .click() and break some tests here. I have to take a look for make sure that all is ok.
Or course you can use this implementation :)

authors: Ifnot johnpc randrews

repo: Ifnot/RestfulizerJs


text:
Add PremultiplyTest and UnpremultiplyTest imports to GafferImageTest/init.py

I just realised that I never added the tests for Premultiply/Unpremultiply to GafferImageTest/init.py, so the tests would never be run unless directly specified.
Here they are

Thanks!

authors: HughMacdonald johnhaddon

repo: ImageEngine/gaffer


text:
feat(middleware): Added some JWT middleware to decode from the bearer…

… token and parse using the secret and function you pass in

The left side is the error message (if it fails). The right side is the
token (if it parses).
On Mon., 20 Feb. 2017, 16:04 David Vuong, notifications@github.com wrote:

@davidvuong commented on this pull request.
In
src/main/scala/com/imageintelligence/http4c/middleware/JWTAuthMiddleware.scala
https://github.com/ImageIntelligence/http4c/pull/6#discussion_r101948203
:

+import com.auth0.jwt.JWT
+import com.auth0.jwt.algorithms.Algorithm
+import com.auth0.jwt.exceptions.JWTVerificationException
+import com.auth0.jwt.interfaces.DecodedJWT
+import org.http4s._
+import org.http4s.dsl._
+import org.http4s.headers.Authorization
+import org.http4s.server.AuthMiddleware

+import scalaz._
+import Scalaz._
+import scalaz.concurrent.Task
+
+object JWTAuthMiddleware {
+

def getBearerToken(req: Request): String / String = {

Just curious, what's the point of making this a disjunction of String or
String. Why not just String? Is it so you can use it in the for in apply?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ImageIntelligence/http4c/pull/6#pullrequestreview-22688790,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnjyZXdCNZ5R5irBhuF9MnTsNAfw6Qiks5reR7agaJpZM4MFw55
.

Sure but they're both just strings. Why not just returning a string rather than wrapping it up in something else?

We need to represent the failure case. If we just returned a string, we have no way to figure out as a caller whether it parsed correctly or not. In most languages you would throw an exception instead of returning a value encompassing both errors.
It's a bit like returning Option[String], except we want a verbose error message so we use Disjunction.

authors: davidvuong dbousamra


text:
diag_ard_touch_calib problem

Hello,
i´m using
ESP32, TFTESPI ,XPT2046
if on calibration i can not select the first cross.
On my own raw data it Shows
Pressure = 900, x = 3845, y = 769
But slection is only accepted at
x = 3655, y = 932
how i can change

Hi arnold --
Some touch displays have less sensitivity in the corners. You can adjust the position of the calibration target to be further away from the corner by modifying the TARGET_MARGIN line in the diag_ard_touch_calib sketch. Try increasing the margin from 10 to 50 pixels, for example:
#define TARGET_MARGIN 50
Does that help?

Yes. this works.
but if my touch would have Problem in one Corner why i still can see the Position in raw data if i print it out

Hi @arnold-b -- sorry for the delay as somehow I overlooked this update.
Glad to hear the margin setting worked.
Regarding your second question: you had asked why you could still see the raw position reported in the corner:

Were you seeing the position reported from GUIslice's touch diagnostic (eg. with DBG_TOUCH enabled) or was it from the XPT2046 library's touch test example?
There are a few reasons why the raw touch may be detected but the calibration won't proceed from the target. Usually this is either caused by the touch pressure value not meeting the range defined in your config (ADATOUCH_PRESS_MIN, ADATOUCH_PRESS_MAX -- you could try reducing PRESS_MIN) or that the debounce filter is detecting noisy input.

If you were interested in getting a more specific explanation, please modify your config file to enable DBG_TOUCH, set the TARGET_MARGIN back to 10 and then let me know what debug messages are reported while you press and release in the first corner target.
Thanks!

I believe the original issue was resolved a while back. If there are further updates to your second question, please feel free to update this or else create a new issue. Thanks

authors: ImpulseAdventure arnold-b

repo: ImpulseAdventure/GUIslice


text:
Refactor MongoAdapter to separate repo and use it as Nuget package

Package Name: InDieTasten.MongoClientAdapter

Hat sich erledigt. Adapter wird nicht mehr benötigt, weil bis zum GetDatabase-Aufruf eh alles synchron in dem MongoDb.Driver funktioniert.

repo: InDieTasten/VirtualDev


text:
🛑 Plugins Store is down

In d1ee61c, Plugins Store (https://ipe-plugins.js.org) was down:

HTTP code: 503
Response time: 76 ms

Resolved: Plugins Store is back up in f839697.

原因: Fastly 全球 CDN 宕机

repo: InPageEdit/status


text:
Bringing the Ego-Network to SC and SV

Implementation Steps SC:

[ ] add ego-network to visualizationTypes of SC
[ ] in SC write node-link structure to store? (which can be used for uploading to SV)

Notes:

Network in SC does not render smooth bc. simulation triggers constant repaint of preview png (story flow); Any ideas how to solve?

Rework node and link data structures to reference entities and nodes by id only

authors: johannesliem samuelbeck

repo: InTaVia/web


text:
🛑 Incloodo Production Services is down

In 22fea11, Incloodo Production Services (https://server.incloodo.com/) was down:

HTTP code: 503
Response time: 419 ms

Resolved: Incloodo Production Services is back up in 5fa4376.


text:
refactor: use separate method to find timestamp

This PR refactors the GetNymHandler. This control flow uses one if/else statement to retrieve the nym with or without a timestamp. Whether the timestamp is retrieved directly or via the corresponding sequence number is determined in a separate method _retrieve_timestamp. This method either returns a timestamp, returns None (the current state will be retrieved without using a timestamp), or raises InvalidClientRequest if both the timestamp and sequence number are retrieved.
Signed-off-by: Char Howland char@indicio.tech

Looks like we have merge conflicts; please merge in Indicio-tech:feature/did-indy-new and push changes with the conflict resolved :slightly_smiling_face:

I'd like to see the github actions running on this PR before merging. I'll send some more details on how we can make that happen.

authors: cjhowland dbluhm

repo: Indicio-tech/indy-node


text:
rough filter UI

Reviewers:

[ ] @sihrc

What's the purpose of the PR?

(I think card got archived)
This is to add filtering to the demo in terms of both source of data and the time period being collected. It seems that a bunch aren't being filtered by date on elastic search's side so will need to check that out. Also allows for tweaking of filtering and DBScan settings so that the user can tweak to suit their query.
Description of changes
(Meta note: the what code was changed part of this might be a little redundant with all the diffs below)
A quick explanation of the stuff unrelated to filtering:
__init__.py messing with the the keywords stuff for better titles,
clusterer.py tweaking granularity of steps in DBScan epsilon,
Most everything else is related to filtering, might be some small UI tweaks, CSS stuff.
Notes to reviewers

Keep in mind while reviewing code:

Is relevant code tested?
Are added functions/methods documented?
Separation of concerns (SOC)
Don't repeat yourself (DRY)
Limit the number of positional arguments
Is function/method length reasonable?
Can code be broken down into smaller components?
Where do added functions/methods belong?
Are variable names descriptive?
Are errors handled appropriately?
Can logic be simplified?
Does the code make sense in context? (expand the diff)

We should add a preliminary integration test that tests a query we know the outcome for with some kind of heuristic. It would make checking the results of this much more efficient.

We need tests for the changes to the client.py. There are existing tests.

authors: aidankmcl sihrc

repo: IndicoDataSolutions/ClusterRSS