Make C# source generators incremental

Switch to incremental source generators to increase their performance as they are executed in steps and avoid re-doing work.
TODO

[ ] I am not convinced that the way I'm reading the analyzer properties is the best way to do it since the syntax step is still going to be executed regardless of the properties' values.
[ ] I haven't tested them thoroughly and I'd like to make sure I didn't introduce a regression before marking the PR out of draft.

I didn't realize there was a draft for this already, I had made a discussion proposal here as ISourceGenerator does indeed have a lot of performance implications for anything beyond the smallest of projects.
If you're looking for structure from other generators the MVVM Toolkit ones are some of the best around, they have tests setup as well.
For generator performance, you can look to use context.SyntaxProvider.ForAttributeWithMetadataName to very efficiently look for specific attributes.
For tests, you can also use things like Compilation.GetFileContentsByName to check the output from the generator, from other SG tests here.
Seems like setting up tests for the current generator could be a good first step? I know having tests makes running source generators and debugging them as part of debugging a test a whole lot easier of a workflow.
Also, not sure how decisions  in https://github.com/godotengine/godot-proposals/issues/7895 effect this code; I'm not familiar enough with the engine and extension internals to know.

@Lidsel what do you mean by the following:

but that approach increases user friction. Decide which is best.

What user friction is increased? User use of attributes should be unchanged between the two implementations. This is just generator implementation detail using ForAttributeWithMetadataName to find attributes?
Agree that dedicated analyzers can certainly be useful to provide hints/help to users on using correct patterns.

Combine the generators for Godot classes into a single generator, so the expensive value-gathering code runs only once. Move just the builders to separate classes instead.

I was thinking the same thing. Usually I prefer smaller PRs that make small improvements over big PRs that are hard to review, so I just wanted to make an initial move to incremental generators before doing more changes.

GodotClassData should be a record and already contain all the class + member information you're going to need for the builders in value-comparable form (this includes value-comparable collections). This allows skipping needless re-generation when nothing about a class changes between compilations.

Sure, like I said I wanted to keep the PR small to start, but it sounds like a good idea.

As pointed out, ForAttributeWithMetadataName is the preferred approach for identifying syntax that should trigger code generation and its use on Godot classes can be enforced with an analyzer, but that approach increases user friction. Decide which is best.

This would require C# classes to have some attribute and, as you say, would increase user friction. I don't think we'll want to do that with the scripting API. It would also break compatibility.

The diagnostic-reporting code should be in analyzers instead. Analyzers run asynchronously and aren't as performance-tight as generators. @paulloz also mentioned there being issues with displaying the diagnostics in IDEs if they come from generators.

I think that depends on the diagnostic, if the generator is already going to be performing the check anyway might as well report the diagnostic, that's what the API is there for, I imagine. Of course if there's some checks that we can move outside of the generators into analyzers that would be great.
As for IDEs not supporting diagnostics from generators, that sounds like an IDE bug to me. I think I've heard from users that Visual Studio does display them, but I can't confirm since I don't use it. I've seen them reported in VSCode at some point with the new Roslyn-based C# extension but I think source generators are currently broken, so I'm currently using the Omnisharp backend.

As you can see this PR is somewhat abandoned at the moment, I haven't had the time to work in it. I'm mostly worried about breaking changes, so I think a good first step would be to implement proper tests (I was looking at Microsoft.CodeAnalysis.Testing). Then we can make refactors without worrying so much about breaking stuff.

@hawkerm The user would have to add an attribute to every Godot type-derived class for ForAttributeWithMetadataName to work. If the types are made from within the editor it could be done automatically in the template, but not if the user creates a class with the regular class template in the IDE. Also on existing projects they would need to run a code fix to add them retroactively. It's not a big amount of friction, but I also understand there haven't been complaints about the performance so far.

I was recommending this API for the existing attributes like Export, so there wouldn't be changes required there.
For the classes themselves, that's of course a different discussion. Not sure if there's a better approach from a performance perspective. At least with Godot most things inherit from some sort of Node, so that should be a starting point to limiting scope of the generator.

if the generator is already going to be performing the check anyway might as well report the diagnostic

Hard agree.

I've seen them reported in VSCode at some point with the new Roslyn-based C# extension

That may indeed be an issue with Omnisharp that'll get phased out when (if?) the issues with the Roslyn extension are fixed. In my own tests (granted, more than a year old now), diagnostics reported from an ISourceGenerator never showed in VSC. But all of those reported from a DiagnosticAnalyzer appeared how they should've. I'd be interested to know what's the state of other IDEs on that.


License

Could you add a license to the project?
There are open source licenses such as Apache 2.0, MIT, BSD, etc

@TalosDx OK

@TalosDx MIT License is added.


Dictionary: keys in a different order

 Alamofire.request(url, method: .get, parameters: parameters, headers: allHeaders).validate().responseJSON {             responseJSON in         }
responseJSON return Keys in a different order

[Data]: 56 bytes
[Result]: SUCCESS: {
active = 27;
cancel = 92;
finish = 46;
}
... result : SUCCESS: {
active = 27;
cancel = 92;
finish = 46;
}
▿ success : 3 elements
▿ 0 : 2 elements
- key : cancel
- value : 92
▿ 1 : 2 elements
- key : finish
- value : 46
▿ 2 : 2 elements
- key : active
- value : 27

▿ 3 elements
▿ 0 : 2 elements
- key : "finish"
- value : 46
▿ 1 : 2 elements
- key : "cancel"
- value : 92
▿ 2 : 2 elements
- key : "active"
- value : 27

What the server sends:
{   "active" : 46,   "cancel" : 92,   "finish" : 27 }

Objects are unordered by definition in JSON, you should not depend on the ordering in any way. Additionally, the underlying types used to store JSON objects (Dictionary or NSDictionary) are also unordered by definition, and in the case of Swift's native Dictionary, will have a different iteration order for every instance, even with the same keys.
Also, we use our GitHub project for bug reports and feature requests. In the future, you should open questions like this on [Stack Overflow](https://stackoverflow.com.
Cheers. 🍻

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


Allow for custom cookie options per session

For example: some users want their cookies to wipe after the session others want them to stick around for a week.
I think it is possible by extending the Session class and setting a new optional property that will then be referenced during the cookie response.
Would you consider this feature?

Would you like to send a Pull Request to add this feature? Remember to add unit tests.

I plan to take this on in a couple weeks, thank you.


Add python3-moderngl-pip, python3-scipy-pip, python3-objloader-pip

Please add the following dependency to the rosdep database.
Package name:
-python3-moderngl-pip
-python3-scipy-pip
-python3-objloader-pip
Package Upstream Source:
https://github.com/moderngl/moderngl
https://github.com/scipy/scipy
https://github.com/szabolcsdombi/objloader
Purpose of using this:
python3-moderngl-pip - moderngl is a very helpful python wrapper for opengl that simplifies handling of vertex buffer and array binding.
python3-scipy-pip - the scipy version in apt package manager is outdated.  The newer version in pip was required for my project
python3-objloader-pip - this python package handles loading of .obj files, useful for building 3D applications in opengl, etc.

The newer version in pip was required for my project

Unfortunately this is part of being in a distribution we all need to use the consistent released version. For your personal project you're welcome to create your own rosdep rules that will override the upstream ones here. But for consistency across the community we don't want them in the public ruleset as it will likely break other users who expect the standard version.


GEM-5401: change gemfire-lucene to be gemfire-search

these checks will pass once GemFire Search 1.0.0 is released :)


fix(docs): update custom settings example

closes #196

@AhmedElywa should we write a test for this DX update?

Codecov Report

Merging #215 (bb560bb) into main (774624f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #215   +/-   ##
=======================================
  Coverage   55.46%   55.46%
=======================================
  Files          45       45
  Lines         640      640
  Branches      115      115
=======================================
  Hits          355      355
  Misses        267      267
  Partials       18       18

@AhmedElywa should we write a test for this DX update?

Test what?
I only changed a docs how we call the custom settings function no need for test here you can merge it.👍

Agreed on the docs change, but there is a CLI output that we changed. (src/cli/nexus-prisma.ts)
@AhmedElywa  looks like the test on MacOS 16 is failing

Agreed on the docs change, but there is a CLI output that we changed. (src/cli/nexus-prisma.ts)
@AhmedElywa looks like the test on MacOS 16 is failing

I can’t do anything about the MacOS issue the time in snap in ms but the time In the test in seconds that’s why it’s failing

@andrewicarlson what is the purpose of the testing here?

I can’t do anything about the MacOS issue the time in snap in ms but the time In the test in seconds that’s why it’s failing

Please just update the regex string replace to not assume ms but account for s OR ms units. It'll require a snapshot update with new replacement of e.g. <unit>.

I can’t do anything about the MacOS issue the time in snap in ms but the time In the test in seconds that’s why it’s failing

Please just update the regex string replace to not assume ms but account for s OR ms units. It'll require a snapshot update with new replacement of e.g. <unit>.

Thanks for your help I opened new PR #217 for that fix Please do a review

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@next-major dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


How to generate dataset in HubRouter

Hi !
First, thank you for sharing your nice work.
I tried to reproduce your work for a course, but I failed to generate the dataset.
The link(https://people.cs.nctu.edu.tw/~whliu/NCTU-GR.htm) in the README in HubRouter has been invalid for some unknown reason.
So could you provide the data for the reproduction?
Thanks! :)

Hi,
Thanks for your attention to our work!
The following links might help:
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec1.capo70.3d.35.50.90.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec2.mpl60.3d.35.20.100.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec3.dragon70.3d.30.50.90.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec4.aplace60.3d.30.50.90.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec1.capo70.3d.35.50.90.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/adaptec5.mfar50.3d.50.20.100.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/newblue1.ntup50.3d.30.50.90.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/newblue2.fastplace90.3d.50.20.100.gr.gz"
"http://www.ispd.cc/contests/07/rcontest/benchmark/newblue3.kraftwerk80.3d.40.50.90.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/bigblue1.capo60.3d.50.10.100.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/bigblue2.mpl60.3d.40.60.60.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/bigblue3.aplace70.3d.50.10.90.m8.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/bigblue4.fastplace70.3d.80.20.80.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/newblue4.mpl50.3d.40.10.95.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/newblue5.ntup50.3d.40.10.100.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/newblue6.mfar80.3d.60.10.100.gr.gz"
"http://www.ispd.cc/contests/08/benchmark/newblue7.kraftwerk70.3d.80.20.82.m8.gr.gz"

Thanks!


update: Added log to notation login and logout commands

This PR adds logs to the login and logout commands.

Codecov Report

Merging #484 (9eafa12) into main (7a947d5) will decrease coverage by 0.10%.
The diff coverage is 27.77%.

@@            Coverage Diff             @@
##             main     #484      +/-   ##
==========================================
- Coverage   32.14%   32.03%   -0.11%
==========================================
  Files          25       25
  Lines        1341     1361      +20
==========================================
+ Hits          431      436       +5
- Misses        898      913      +15
  Partials       12       12

Impacted Files
Coverage Δ

cmd/notation/registry.go
0.00% <0.00%> (ø)

cmd/notation/logout.go
41.66% <17.64%> (-12.50%)
:arrow_down:

cmd/notation/login.go
40.90% <18.18%> (-1.78%)
:arrow_down:

pkg/auth/native_store.go
91.11% <100.00%> (+0.41%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Looks like we are not adding much information in debug logs, do we really want debug log for login logout commands?

Oh yeah, so I think one good reason to add debug logs to login is that there are several https roundtrips among notation, registry, and authorization service -> spec. Printing out those traces could be useful during debug.
As for logout, the logger prints out the name of the credential helper program for debug purpose, as we are using Docker's credential helpers.


refactor: add miss stop ticker

add miss stop ticker
replace ticker with time.After(X)

thanks for this @hoanguyenkh! while we good just take these changes in, imo since they're not of immediate concern and could be applied to all comet chains, I think it makes sense to upstream this change

thanks for feedback, i think upstream this change is good choice

Sounds good. We can close this PR here and pull this change from upstream once it is implemented.


dart2js: assert_with_message_test fails in minified code

The minified interceptor name for JSNull is being rejected, leading to the evaluation of null.constructor.
This happens in the formatting of the TypeError for a failed boolean conversion for the case when the assertion expression evaluates to non-bool.
The null deref is trapped an converted to a NullError.
Seems related to: https://github.com/dart-lang/sdk/issues/19137

@@@BUILD_STEP dart2js_extra-drt tests --minified --dart2js-batch --csp --checked failures@@@
FAILED: dart2js-drt-checked release_ia32 dart2js_extra/assert_with_message_test
Expected: Pass
Actual: RuntimeError
CommandOutput[dart2js]:
CommandOutput[content_shell]:
stdout:
#READY
CONSOLE MESSAGE: line 78: {
"type": "debug",
"value": "test_controller.js started",
"timestamp": 0
}
CONSOLE MESSAGE: line 78: {
"type": "print",
"value": "dart-calling-main",
"timestamp": 0.064
}
CONSOLE MESSAGE: line 78: {
"type": "sync_exception",
"value": "Exception: Expect.isTrue(false, 'name: <<NullError: method not found: 'constructor' on null>> (F) is TypeError') fails.\nStack: Expect.isTrue(false, 'name: <<NullError: method not found: 'constructor' on null>> (F) is TypeError') fails.\n    at dart.d (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:682:3)\n    at dart.aB (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1510:24)\n    at dart.aC (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1509:3)\n    at ak.dart.ak.$2 (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1295:3)\n    at dart.c5 (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1242:3)\n    at dart.bw (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1266:3)\n    at dartMainRunner (http://<IP_ADDRESS>:41436/root_dart/tools/testing/dart/test_controller.js:311:5)\n    at http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1638:55\n    at init.currentScript (http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1634:55)\n    at http://<IP_ADDRESS>:41436/root_build/generated_compilations/dart2js-checked-minified-csp-sdk/tests_compiler_dart2js_extra_assert_with_message_test/test.js:1637:84",
"timestamp": 0.092
}

Fixed: https://github.com/dart-lang/sdk/commit/5612c202a02e2f39dec8914aa74661d813a92ce5


bitstream-extraction_git.bb: Update MIT license file checksum

LIC_FILES_CHKSUM was invalid and producing a warning:
"WARNING: bitstream-extraction-git-r0 do_populate_lic: ${COREBASE}/LICENSE is not a valid license file, please use '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in LIC_FILES_CHKSUM. This will become an error in the future"
Corrected the value for MIT license to remove the warning and prevent a future error.

I will add this patch once we release 2017.4, on dec 6th. We usually take patch through mailing list rather than pull request

Can you add signed-off by in your patch?

Ping? Can you send me your email address and name? I can make the patch and add your signed-off by line

Drew Withers
<EMAIL_ADDRESS>

https://github.com/Xilinx/meta-xilinx-tools/commit/8cf32a6eb5fab62a178e0c7f68cd99832957a22d


remap_restarts uses SLURM for lake/landice/saltwater (Resolution for issue #85)

The purpose of this pull request is to resolve the issue brought up by @mathomp4 in issue #85. Mostly reuses code from remap_upper.py. Requesting @mathomp4 try running this branch before merging.

Requesting @mathomp4 try running this branch before merging.

Ooh. I will do so Monday. (That said, please ping me Monday to make sure I do 😄 )


Implement the RX Depacketizer

Implements the design doc/designs/quic-design/rx-depacketizer.md, from #18610.
It relies on functionality from #18676 (ACK Manager implementation), #18795 (QUIC Encoding and decoding functionality), #18870 (QUIC Record Layer design) and #18612 (SSL object refactoring using SSL_CONNECTION object)

A lot of other functionality is currently not in place and not even in PRs, so there are a lot of comments with the key words "ADD CODE" and "ASSUMPTIONS" that will be amended as development of those components progresses.
Until all of those question marks are resolved, this PR will remain a draft.

This has now been adapted with #18870 in mind

I'll do more adaptation to minimize it further, so we can do some very minimal preliminary tests

This currently requires the following additional PRs:

#18676
#18949

This is now ready enough for a real review

cca82837bd8ea3ddfa56717353b97d22cacf1505 implements the alignment suggested here: https://github.com/openssl/openssl/pull/18838#discussion_r946802714
Personally, I thoroughly dislike this re-alignment.  It means that statements end up looking weirdly aligned, all because of a brace at the end of a case or default line, a brace which isn't very visible.  To me, this is a lot worse  than the ending double brace that are aligned the same.

Personally, I thoroughly dislike this re-alignment. It means that statements end up looking weirdly aligned, all because of a brace at the end of a case or default line, a brace which isn't very visible. To me, this is a lot worse than the ending double brace that are aligned the same (and mind you, I agree that's not perfect either... but...).

Either we could do it the same way as we require curly brackets for both if and else blocks of if/else statements if one of the blocks needs it. I.E. require extra curly brackets for all cases of a switch where you need one. Or to avoid extra indentation we could allow this:
switch (x) {
case 1:
    stmt;
    break;
case 2: {
    decl somevar;

    stmt-with-somevar;
    another-stmt;
    break;
    }
default: {
    stmt;
    another-stmt;
    }
}

Personally, I thoroughly dislike this re-alignment. It means that statements end up looking weirdly aligned, all because of a brace at the end of a case or default line, a brace which isn't very visible. To me, this is a lot worse than the ending double brace that are aligned the same (and mind you, I agree that's not perfect either... but...).

Either we could do it the same way as we require curly brackets for both if and else blocks of if/else statements if one of the blocks needs it. I.E. require extra curly brackets for all cases of a switch where you need one. Or to avoid extra indentation we could allow this:
switch (x) {
case 1:
    stmt;
    break;
case 2: {
    decl somevar;

    stmt-with-somevar;
    another-stmt;
    break;
    }
default: {
    stmt;
    another-stmt;
    }
}

Between the choices, I prefer this last one.  The other option would be to stop outdenting case/default lines, but that seems to be a bigger hurdle...

switch (x) {
case 1:
    stmt;
    break;
case 2: {
    decl somevar;

    stmt-with-somevar;
    another-stmt;
    break;
    }
default: {
    stmt;
    another-stmt;
    }
}

This is better than what is currently in this PR - but I don't think this is the way to go.

Re case indentation, I really think that should be a separate and broader coding style discussion.  It seems unlikely that we will get to an agreement here.
Meanwhile, I'm going to modify the cases to the bracing style @t8m proposed, as I find it much less disturbing.

One thing that seems to be missing is to check the allowed frames based on the packet type. I.e., check against this table: https://github.com/openssl/openssl/blob/5f10b1f371469f6ca921337c4d390f05ada6c606/doc/designs/quic-design/tx-packetiser.md#frames
In case of Initial packet type a packet containing such invalid frames may be discarded as a whole. Other violations should cause error being reported and connection close.

Refactored to avoid the case-and-brace source formatting dispute...  I find the result more appealing, now that it's done.
A bunch of review comments addressed.

One thing that seems to be missing is to check the allowed frames based on the packet type. I.e., check against this table: https://github.com/openssl/openssl/blob/5f10b1f371469f6ca921337c4d390f05ada6c606/doc/designs/quic-design/tx-packetiser.md#frames
In case of Initial packet type a packet containing such invalid frames may be discarded as a whole. Other violations should cause error being reported and connection close.

Good point.  I'll save that for Monday

One thing that seems to be missing is to check the allowed frames based on the packet type. I.e., check against this table: https://github.com/openssl/openssl/blob/5f10b1f371469f6ca921337c4d390f05ada6c606/doc/designs/quic-design/tx-packetiser.md#frames
In case of Initial packet type a packet containing such invalid frames may be discarded as a whole. Other violations should cause error being reported and connection close.

Good point. I'll save that for Monday

Done

CIs are relevant.

No unit tests.
Should this still be in draft? :smiley:

CIs are relevant.

This still depends on #18949, so will obviously not be possible to merge before that one's in.

I've rebased, and squashed while I was at it.

I've added pointers to a OSSL_ACKM and a OSSL_QRX in QUIC_CONNECTION, and added SSL_ctrl() commands to set them, given a QUIC_CONNECTION * passed as an SSL *.  This allows test programs to deal with QUIC connections without having to include deeply private headers.
Following that, I've modified test/quic_record_test.c to also parse frames and find out if that was successful or not.
This should now be fully reviewable, pending the CI results.

I've added pointers to a OSSL_ACKM and a OSSL_QRX in QUIC_CONNECTION, and added SSL_ctrl() commands to set them, given a QUIC_CONNECTION * passed as an SSL *. This allows test programs to deal with QUIC connections without having to include deeply private headers.

I suppose this would be just a temporary thing. IMO we do not want such internal ctrls to expose guts of QUIC implementation. To me it seems less problematic to just add some test utility functions which would include the internal headers to set the structure members directly. But others might have different opinions.

I've added pointers to a OSSL_ACKM and a OSSL_QRX in QUIC_CONNECTION, and added SSL_ctrl() commands to set them, given a QUIC_CONNECTION * passed as an SSL *. This allows test programs to deal with QUIC connections without having to include deeply private headers.

I suppose this would be just a temporary thing. IMO we do not want such internal ctrls to expose guts of QUIC implementation. To me it seems less problematic to just add some test utility functions which would include the internal headers to set the structure members directly. But others might have different opinions.

The other option I see is to make QUIC_CONNECTION "internal" (i.e. defined in a include/internal header) instead of so deeply private.  But that's a lot more invasive, so I'd rather leave that as a future exercise / for another PR.

I expected to see some code handling the C spec here: frames containing only ACKs do not count towards bytes in flight for congestion control purposes. The depacketiser seems like the natural place to detect this but I don't see any code doing so.

Not sure how that's supposed to work in code...  but I guess I should look more closely at #18018

I expected to see some code handling the C spec here: frames containing only ACKs do not count towards bytes in flight for congestion control purposes. The depacketiser seems like the natural place to detect this but I don't see any code doing so.

Not sure how that's supposed to work in code... but I guess I should look more closely at #18018

Nope, that didn't enlighten me...

It seems that all review comments have been addressed

All CIs are happy now

This is necessarily incomplete because lots of things it needs to plug into are not yet completed, but as a framework I think it suffices. It can be changed by subsequent PRs at the same time that the functionality it needs to plug into is added.
I've only two remaining concerns:

Does this actually need to depend on SSL objects? It could be a separate object, or depend only on QUIC_CONNECTION?
The frame decoding uses two passes. I don't think this is necessary? The ACKM can be informed of a received packet at the end of a single pass which accumulates the is_ack_eliciting flag.

I've only two remaining concerns:
* Does this actually need to depend on SSL objects? It could be a separate object, or depend only on `QUIC_CONNECTION`?

The way things are currently declared, QUIC_CONNECTION is declared as strictly private inside libcrypto, while SSL is a well known object.  Either way, it's a fairly natural way to do this, since SSL will tend to be the carrying object, as far as I've been able to tell... and the way QUIC_CONNECTION is made, it isa SSL anyway...

* The frame decoding uses two passes. I don't think this is necessary? The ACKM can be informed of a received packet at the end of a single pass which both handles frames and accumulates the is_ack_eliciting flag.

This may be a misunderstanding, then.  However, that's how I read https://github.com/openssl/openssl/blob/master/doc/designs/quic-design/quic-ackm.md#on-rx-ack-frame, that the ACKM bits must be fully handled before frame data is processed further.  If that was incorrect, then oh boy I'll happily reduce the code to be one pass only.

The way things are currently declared, QUIC_CONNECTION is declared as strictly private inside libcrypto, while SSL is a well known object.

IMO this was not the intention. The QUIC_CONNECTION should be well public within the libssl of course. We might want to move the declaration somewhere else if the current place is wrong for that purpose.

The SSL * should be used only for outside APIs as there is (albeit minimal) overhead associated with converting it to QUIC_CONNECTION *.

The way things are currently declared, QUIC_CONNECTION is declared as strictly private inside libcrypto, while SSL is a well known object.

IMO this was not the intention. The QUIC_CONNECTION should be well public within the libssl of course. We might want to move the declaration somewhere else if the current place is wrong for that purpose.

I miswrote, I did mean libssl

... We might want to move the declaration somewhere else if the current place is wrong for that purpose.

Wish granted!

Also a rebase is needed.

I'll rebase and squash

I'll rebase and squash

Done

This may be a misunderstanding, then. However, that's how I read https://github.com/openssl/openssl/blob/master/doc/designs/quic-design/quic-ackm.md#on-rx-ack-frame, that the ACKM bits must be fully handled before frame data is processed further. If that was incorrect, then oh boy I'll happily reduce the code to be one pass only.

Yeah, it definitely was not my intention to require multiple passes. Go ahead and make this single-pass.

... Go ahead and make this single-pass.

Done.

@hlandau assuming still OK?

Still OK

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged
Thank you all for the reviews!
d5ab48a192d45ec51355ef2a186125961331eb9b Move the QUIC_CONNECTION typedef to internal headers
69ed6760f938975d9cdcc12ec756d58c83ac6b90 Implement the RX Depacketizer
9be2693438756b5f1b789f1b8db76c3b987063dc Extend the RX Depacketizer frame table with what packet types they are valid in
8a163641c1d94c877a46ade8ff2ecefdf5cbbeeb Implement packet type checks in the RX Depacketizer
ecc920b3277311e859282b6d400ba8566d7ea8c1 Modify test/quic_record_test.c to also depacketize


RFM - octave.portable

Current Maintainer

[x] I am the maintainer of the package and wish to pass it to someone else;

Checklist

[x] Issue title starts with 'RFM - '

Existing Package Details
Package URL: https://chocolatey.org/packages/octave.portable
Package source URL: https://github.com/chocolatey-community/chocolatey-coreteampackages/tree/master/automatic/octave.portable

/confirm a.bejenaru

@abejenaru can you try that command 1 more time, I had forgotten to include dots as a valid character in usernames, but that should be fixed now (just want to have it confirmed first).

/confirm a.bejenaru

New maintainer notes

This package is hosted in the GitHub chocolatey-coreteampackages repository, when picking up this request please do one of the following

After being added as a new maintainer, please open a PR to remove the package and icon from the repository if you want to host the package in your own repository.
After being added as a new maintainer, please open a PR to add yourself as a maintainer to the nuspec and CODEOWNERS files, if you want the package to still be hosted in that repository.

I am happy to pick this one up - Chocolatey user name dgalbraith.

I am happy to pick this one up - Chocolatey user name dgalbraith.

Thanks! I've added you as maintainer, please check your email (also in spam) for a confirmation message.
Cheers!

Maintainer confirmation accepted.

New package version has been approved.


[ATK] Analog Joystick Test

In ATK, it would be nice to be able to test analog joysticks too. This would make sure that the rough ADCs in Paula work correctly.
And/or an actual analog joystics, of course :).

Hey man, you rock! Very well done! Just one note: it would be useful to keep track of the min/max values reached on the X/Y axes.

Good idea. One thing to note is that the values can wrap beyond 255 if the RC charge delay in the joystick is too high. I found this after modding a PC joystick with an extra 100nF on each pot. This is because PC sticks use a lower pot resistance than Amiga sticks. It worked fine on one axis but so happened my x axis will wrap to (256+)23 ish.
Now in a game I would deal with that wrap and also if course allow the full range of the joystick to be calibrated. But in the test I prefer just to deal in raw values, bit probably makes sense to detect and report the wrap in the min/max values?

One thing to note is that this is at 50hz whereas the pots are designed not to overflow if the counters are read with 16.6ms of setup (ie ntsc 60hz). Something for me to think about. I think the wrap is still useful to report at pal frequency. Maybe.

I guess what you should do depends on what old games did: did PAL games cope with the possible overflow, or can they be fooled by it? In the latter case I think it would be better to detect and report the overflow to the user.
Since adding caps to extend the X/Y range seems to be a popular mod (it is actually sort of why I'm asking), reporting overflows can also be useful to help people test different cap values until the best one is found.

Any thoughts on #35? I don't think there's much confusion in the test?

Here's a new firmware to try. It reports min/max and can report pot values up to nearly 500. If you're close to that value it means you don't have a pot connected on that line! Give it a try please:
atk_20_1.zip

Will do tonight.
About #35, sorry but it took me quite a bit to come up with a meaningful reply :).

That's okay, and it's resulted in a change :) Here's the new latest build:
atk_20_2.zip

Everything tests good here :).


[Feature] How to accelerate constrained decoding when regex needs to change with input?

Checklist

[X] 1. If the issue you raised is not a feature but a question, please raise a discussion at https://github.com/sgl-project/sglang/discussions/new/choose Otherwise, it will be closed.
[X] 2. Please use English, otherwise it will be closed.

Motivation
In some practical application scenarios, the regex needs to change with the input, and the speed of constrained decoding using Compressed FSM will be significantly slower than that of unconstrained decoding due to each time you need to compile. How do we support the constrained decoding acceleration requirement in unfixed regex scenarios? thanks~
Related resources
No response

It seems unrelated to the constrained FSM optimization. You can submit multiple requests if the regex can change in the middle.


[EMM-1428] Refer keystore password details from carbon.xml file

EMM uses config.josn file located at <EMM_HOME>/repository/deployment/server/jaggeryapps/emm/config location, which contains the key store related details. Since key store related details are maintained in carbon.xml file it would be better to refer key store information from carbon.xml, rather than maintaining separate configuration files.            Note - If a user wants to encrypt the key store information in json.config file, manual configuration can be used, but the component should be capable of decrypting the value.         Reference: https://wso2.org/jira/browse/EMM-1428

@Nirothipan will work on this.

These details have been currently removed from config.json and no longer exists. Hence closed.

Cannot automate, as this configuration has been removed for some time, and we just verified and closed the issue.


Add metadata to pipelinerun to capture the complete pipeline definition

It's currently impossible to reason on the exact pipeline definition, conditions, git and image urls used when a pipelinerun is executed given that pipelinerun includes references to pipeline, condition and pipeline resources which all can change after pipeline execution is complete.
This is specially difficult for building tooling around Tekton, for example causing graph visualisation of a completed pipelinerun change when the referenced pipeline is modified.
Adding metadata to the pipelinerun including the exact pipeline, conditions, and resources would allow to capture the exact state of the pipelinerun which won't change even if those referenced resources change. This can be done for example via adding annotations to PipelineRun
pipelinerun.tekton.dev/pipeline-configuration
pipelinerun.tekton.dev/pipelineresource-configuration
pipelinerun.tekton.dev/condition-configuration

An example of this is Helm Releases which embed the generated manifests from the Helm Chart inside the Helm Release to capture the exact resource definitions that are associated with a particular Helm Release, instead of referring to the chart given that the chart can change after the release was created.

This is also kinda related to @afrittoli comment on #859 on how do we manage pipeline reference of a PipelineRun when the Pipeline changes (after the run)

What happens when a PR that modifies the task/pipeline definition is merged? The desired behaviour would be that any running tasks/pipelines keep running on the old definition and any new task/pipeline uses the new definition. However if the new definition is applied to the cluster this would affect in-flight tasks/pipelines.

@vdemeester I have updated this issue to better capture the need

This is closed by https://github.com/tektoncd/pipeline/pull/2489 and https://github.com/tektoncd/pipeline/pull/2444


Update OpenMM interface

Codecov Report

Merging #14 (5dcd7f4) into main (7c71860) will decrease coverage by 0.27%.
The diff coverage is 14.46%.

Additional details and impacted files


:boom: first stab at the new header

This is by no means production code. The SASS and HTML will need to be changed. This is a first stab and getting it looking like it needs to be.

Next the CSS and templates will need tidying up.


Collecting detection velocities

Hello, ZOD developers! I was hoping you could help me understand if it was possible to obtain velocities for the detected vehicles around the ego vehicle in each frame. Based off of my understanding, detection velocities are not provided by default, neither is the data sequential, to attempt manual calculation.

Thanks for getting back to me, I guess i'll see what I can do!


Brightcove extractor: support customBC.createVideo(...); method (america.aljazeera.com and others)

found in http://www.americanbar.org/groups/family_law.html and
http://america.aljazeera.com/watch/shows/america-tonight/2015/6/exclusive-hunting-isil-with-the-pkk.html

Thanks. Merged with some improvements.


changed instructions for how to build

mostly line-end wrapping changes, but made the content around building the default images more explicit.

@benbp what's your thought on how to run these as a part of an overall setup, and then make them available for the instructions at https://github.com/rackhd/rackhd ? Extend the vagrant instance to build them locally in that instance? travis builds in on-imagebuilder that stuffs at least default results into binary and use the files from there?

@heckj These changes should be made in https://github.com/RackHD/docs/blob/master/docs/monorail/microkernel.rst too. I think the plan is to deprecate this README and just link to that.

Re your question: yeah I think if we can get around the legal issues of distribution, it'd be great to just download the latest builds, otherwise, yeah we'll want to set it up as part of the ansible provisioning step for the vagrant setup.

:+1:

Ah - very cool, I'll go read through what's in the RTD site and update this PR to be a change to point to that information to locate the docs in a single place. Honestly won't be able to tackle until tomorrow earliest though


Exclude sun/security/ssl/CipherSuite/DisabledCurve.java on z/OS

sun/security/ssl/CipherSuite/DisabledCurve.java is not supported on execute on z/OS. It is already disabled on windows and aix. Now this test needs to be disabled on z/OS.
For more details: openj9-openjdk-jdk11-zos/issues/1735

Triggered a verification build with fix.
Grinder_CR/2848/

Raised a PR for the fix
https://github.com/adoptium/aqa-tests/pull/4451

PR is merged hence closing the issue
https://github.com/adoptium/aqa-tests/pull/4457/


Namespace qualify Result

In the case where we want to use the Result type and import other libraries that have their own Result class, how can we properly qualify this library by it's namespace?
For example, if I want to use Result<Int, NSError> and in the same file, import Alamofire (which has it's own Result type), how can I qualify the name space?
Example:
import Result
// all good here
func myFunc() -> Result<Void, NSError> {

}

------------------------------
import Result
import Alamofire
func myFunc() -> Result<Void, NSError> {

}

In the second example, the compiler complains of an unambiguous reference, which makes sense but you can't do Result.Result<Void, NoError> because then the compiler complains that it's missing generic arguments.

There's a workaround listed in #77.


It seems that the modified CODAL code is not properly applied as a runtime HEX file.

Hi, @pelikhan, @mmoskal.
Describe the bug
Although the member function of a specific class not implemented in codal-core was implemented in a class that inherited the class, MakeCode does not link the proper runtime HEX file.
Of course, these work without problems when using only the CODAL build system.
The CODAL code related to the previously modified Serial package or the newly added DYNAMIXEL worked well.
Is there anything different about the core package?
To Reproduce
Steps to reproduce the behavior:

Modify member function of CODAL Core Class
Commit & Push to GitHub.
pxt serve or pxt serve --localbuild
Write code at MakeCode (eg. MakeCode ROBOTIS)

forever(function () {
    serial.writeValue("V", pins.VOLTAGE.analogRead())
    pause(500)
})

Download & Upload to target board (The code has changed, so it must be compiled, not the cached hex file, but it is not recompiled. If you delete the "built/hexcache" folder and clear the browser's cache, it will be recompiled, but the hex hash value is the same.)
Look at the behavior of the board (The changed member function was not applied)

Expected behavior
I wrote it as a more specific example.

The getAnalogValue() function in Pin.h of codal-core is not implemented.
Therefore, we implemented getAnalogValue() in NRF52Pin of codal-nrf52.
We implemented to print 4444 instead of -1013(DEVICE_NOT_IMPLEMENTED) value.
Now it is applied. (We have confirmed that this compiles normally through various methods and creates a .hex file in the dockercodal or codal folder. We made sure that this compiles normally, such as by creating additional functions, inserting error codes or checking the .map file.)
Now, the value that was output as -1013 should be output as 4444. But...

Screenshots

Before

int NRF52Pin::getAnalogValue()
{
    return DEVICE_NOT_IMPLEMENTED;
}

After

int NRF52Pin::getAnalogValue()
{
    int data = 4444;
    return data;//DEVICE_NOT_IMPLEMENTED;
}

But...

Desktop:

OS: Windows10 Pro
Browser: chrome / NAVER whale(based on chrome)
Version: chrome 80.0.3987.149

Additional context

The field branch here really needs to be a tag to get proper caching. I know the name is confusing.
In your codal folder, where you were doing your implementation, run ./build.py -l - this will create a new tag in the target ( https://github.com/ROBOTIS-GIT/codal-cm300 ). Then put that tag in branch field.
Let me know if that helps!

Also, make sure to use ./build -l and not create tag with git tag - the build.py will also link to correct versions in all dependent repos.

Hello, @mmoskal
Thanks for help
Describe the bug
Previously, when I added a new accelerometer, I manually pasted the fix code into the dockercodal subfolder and tested it without uploading it to github.
In this process, the corrected code is reflected without any problems, so we test it in the same way and try to upload it once the problem is solved.
Does this method matter in any way?
In case of using ./build.py -l, the suggested solution
('missing checkin in', 'D: \ Path ~') complete with an error.
and still not fix "DEVICE NOT IMPLEMENTED"
To reproduce
Steps to reproduce the behavior :

The commands of pxt clean,pxt-cleangen, and pxt serve --localbuild were sequentially executed in the pxt-robotis local git folder.

Move into pxt-robotis/lib/robotis-cm-300/built/dockercodal
and, do python ./build.py -l
++ just input command  ./build.py -l cmd monitor flash shortly and nothing change.

complete with an error ('missing checkin', 'D: path ~ ')

no change

Expected behavior
Nothing has been reflected and remains the same.
Screenshots

test based on codal local git floder

it is working well

pasted updated NRF52Pin::getAnalogValue function code to dockercodal subfolder and do 'pxt builddaldts', 'pxt serve --localbuild'

test by this block

but...

Desktop:
OS: Windows10 Pro
Browser: chrome
Version: chrome 80.0.3987.149

It's best to test locally like you did before, without ./build.py -l. The ./build.py -l is needed to publish the fix at the end.
To test locally, I usually build from command line.
First, I suggest you add the following environment variables to your computer setup:
PXT_FORCE_LOCAL=1
PXT_RUNTIME_DEV=1
PXT_ASMDEBUG=1

The first one will force a non-cloud build, the second will force re-running cmake on every build - this is useful if you make changes in codal, and the third adds additional debug information to generated binary.asm (you may not need that, but it doesn't hurt).
Then, head to pxt-robotis/projects/my-project. You can use an existing project created from localhost:3232 or create a new one. The pxt.json should be modified to look something like this:
{
    "name": "my-project",
    "dependencies": {
        "robotis-cm-300": "file:../../libs/robotis-cm-300"
    },
    "description": "",
    "files": [
        "main.ts"
    ]
}

The crucial part is "file:../../libs/..." instead of "*" - this will let you modify .cpp files in your target and pxt-common-packages and have these be picked up by build.
BTW, never edit files under built/dockercodal/pxtapp - these will be overwritten.
If you edited pxtarget.json, delete pxt-robotis/built/target* that you may have left from previous pxt serve or pxt buildtarget.
Now, you should be ready to build, in pxt-robotis/projects/my-project just run pxt.

Let me know if this helps!

BTW, the critical bit is building your .uf2 file using pxt command, not the web app.

@mmoskal.
hello, mmoskal.
It was very helpful.
It seems that the problem occurred because the changes were not reflected as the cache was twisted.
Thank you.

I am closing this. Please reopen if the issue continues.


chore: split babel compiler code from karma-esm

split out code from karma-esm into building-utils so that it can be used by owc-dev-server

express-transform-bare-module-specifiers expects outdated types or lru-cache types are not fully up to date?
node_modules/express-transform-bare-module-specifiers/dist/compile-middleware.d.ts:7:45 - error TS2694: Namespace 'LRUCache' has no exported member 'Cache'.

7 export declare const babelCompileCache: LRU.Cache<string, string>;

what to do? find an alternative? fork?

I don't understand why we are type checking dependencies. This shouldn't be the case.

I was able to fix this by adding the outdated types to the package we use bare module specifier transform.


Fix current build failure in devel branch

Hi Robert,
This patch addresses the current build failure on the Bioc devel branch, which I think was introduced by changes to ucscTableQuery() in rtracklayer.  It looks like the order of the arguments might have changed, this just makes sure to specify that we're looking for the cytoband table inside the IdeogramTrack() function.
Let me know if anything else needs adding.

Hi Mike,
Happy New Year! And thank you for the fix.  I merged it.

Hi Mike,
Happy New Year! And thank you for the fix.  I merged it.


Maui do not run in windows using VSCODE

I need run it on my windows OS. Just like Visual Studio
Maui do not run in windows using VSCODE .
when i press F5 only show android and Mac.

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

ID: 779d2db3-3e9c-2692-57ff-787d9465a444
Version Independent ID: e77ba6a7-e59d-1e1e-52e1-935f98a985cf
Content: Build your first .NET MAUI app - .NET MAUI
Content Source: docs/get-started/first-app.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @wjvelasquez
What you're trying to do is a supported scenario, so should work. See https://learn.microsoft.com/en-us/dotnet/maui/get-started/installation?tabs=visual-studio-code#windows for more details.


[BUG] Bulk update using doc

I tried bulk update from version 2.0.0-RC-7 but got an issue, the values has double quote
this is my code
searchClient.bulk(refresh = Refresh.WaitFor) {
   update(
       doc = TestDocument(name="test", age= 20),
       index = "es-index",
       id = "1",
   )
}

expected result
{
   "name": "test",
   "age": 20
}

actual result
{
   "name": "\"test\"",
   "age": "20"
}

ES Version 7.12.1

Thanks for reporting, I will look into this.


Datepicker selects date from day before

Since recently I have a strange bug: When I select a date, the datepicker returns the date from the day before, see gif.
Can you replicate this on your PCs?

I cannot replicate it.

Yes, strangely today it disappeared on my side as well.

This could be the case. But we can then probably close this issue?

@skjerns I guess the first time you tried it between 0 and 1am? I think this is because the Datepicker always sets a timestamp at midnight (UTC+0) and your computer is set to UTC+1.

Mhh, I made the issue at 11:18 AM, so not really :-/ but as it's dissappearing, I'll look into it again tomorrow ar 11:18 AM ;)

@skjerns I found it and fixed it. When selecting a date we didn't use the timezoneoffset for that date but for the current date. So when selecting a date in summertime (after 28.03.) the bug occured.

Perfect! great job! Chris had the same issue yesterday, so good it's fixed now :)


stun prod

About the PR

(reworked the old closed PR from noudoit)
adds a stun type weapon that the crew can access via crafting this is not a good sec alternative as it does less stun drain per hit and cannot be carried easily.
Media

https://youtu.be/Pr_geH8uIww

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

add: Added a homemade stun weapon.

i understand this feature will probably be seen as very controversial, but with all of the changes to batons to include stamina damage and the like, i think that this has a decent shot of being an interesting option for combat.

army of tiders with stunprods chasing down nukies:

army of tiders with stunprods chasing down nukies:

or a lone secoff for that matter

this would completely fuck over nukies

Or maybe just replace the battery with a level 3 battery. They won't be that easy to get.
And maybe remove the capacitor from crafting? With your craft now, everyone will start dismantling substations and appliances.

everyone will start dismantling substations and appliances

that's againsts the rules

Or maybe just replace the battery with a level 3 battery. They won't be that easy to get.
And maybe remove the capacitor from crafting? With your craft now, everyone will start dismantling substations and appliances.

Just scale the effects down according to the cell's capacity.

Or maybe just replace the battery with a level 3 battery. They won't be that easy to get.
And maybe remove the capacitor from crafting? With your craft now, everyone will start dismantling substations and appliances.

Just scale the effects down according to the cell's capacity.

it is already 360 capacity, as it should be

@metalgearsloth could you do a review, please?

crafting recipe doesn't seem to work - something is wrong with battery and capacitor (they do not drop when this fails, i dunno)

crafting recipe doesn't seem to work - something is wrong with battery and capacitor (they do not drop when this fails, i dunno)

I didn't see a bug that would make things not fall out when you fail, but I fixed another bug. it should work properly now, I think.


Ship v2.1 of SSP

Download from Google, open in Word, clean up table, etc.
Save as PDF, Docusign it. We ship SSPs as PDFs so they're more or less immutable
Save as DOCX, upload back to Google Drive as the 'indev' version.
Acceptance Criteria

SSP has been Docusigned by:

[x] ISSO
[x] System Owner
[x] Product Lead or Biz Lead or Eng Supervisor

Signed SSP delivered to

[x] Max
[x] Google Drive Archive folder

SSP update notification (with highlights) emailed to

[x] cloud-gov-team
[x] JAB TRRs

[x] Google Drive updated with latest .docx

Security Considerations
Safe. The existence of this issue provides no useful public info to a malicious actor. Regularly
update our SSP is good for compliance & security

Signed SSP uploaded to Max.gov and Google drive. JAB and CG Team have been notified.


Null values aren't supported, if isEnabledForExtensions() == false

Hi,
I have a working step that collect stock information on product.template
When I want to use the same code on product.product, I got the following error:
Null values aren't supported, if isEnabledForExtensions() == false
logError("Create object adapter" );
ObjectAdapter objectAd = openERPSession.getObjectAdapter("product.product");
logError("Create filter" );
FilterCollection filters = new FilterCollection();
filters.add("active","=", "true");
filters.add("qty_available", ">", "0");
logError("Create tuple" );
String[] tuple = new String[]{"id", "ean13", "qty_available"};
logError("Create collections" );
RowCollection  products = objectAd.searchAndReadObject(filters, tuple);
The last line raises the error.
What should I do?
Regards,
Bernard

Hi @bwilmus ,
From now the lib force the option to false: https://github.com/DeBortoliWines/openerp-java-api/blob/master/src/main/java/com/debortoliwines/odoo/api/OdooXmlRpcProxy.java#L108
I'm not the author of this part and I don't really know if Odoo > 8 actually still not supporting the option set to true.
I've tested on a v8 implementation with the lib compiled with the option set to true and it succeed. Maybe you could try the lib I sent to you in PM.
regards

will be fix by https://github.com/DeBortoliWines/openerp-java-api/pull/41


Add several metrics, statistics, rekognition vendor and ability to work with tagged images

Hi Gaurav,
I'm Lucas, working for Recast.ai. We recently had to compare several image recognition APIs to pick the best one for us. First, thank you very much for providing cloudy_vision, it worked perfectly and saved us a lot of time.
While performing the benchmark, we enhanced cloudy_vision with several features we would like to share with you:

response_time and tags_count metrics
ability to compute vendor statistics (average and standard deviation)
rekognition vendor
ability to work with tagged images

That's a lot of changes for a single PR but they have been split into atomic commits to ease the review ;)
The additional metrics and statistics improved the benchmark relevance and we hope to see them integrated into cloudy_vision!

Wow, that's awesome! Thank you for the nice words, and even more so for
giving back.
I will have a chance to review this next week, apologies for my slowness,
but I hope to include it soon.
Thanks again, and best of luck with Recast.ai!
Gaurav
On Wed, Jan 11, 2017 at 2:02 PM, lucasdchamps<EMAIL_ADDRESS>wrote:

Hi Gaurav,
I'm Lucas, working for Recast.ai https://recast.ai. We recently had to
compare several image recognition APIs to pick the best one for us. First,
thank you very much for providing cloudy_vision, it worked perfectly and
saved us a lot of time.
While performing the benchmark, we enhanced cloudy_vision with several
features we would like to share with you:

response_time and tags_count metrics
ability to compute vendor statistics (average and standard deviation)
rekognition vendor
ability to work with tagged images

That's a lot of changes for a single PR but they have been split into
atomic commits to ease the review ;)
The additional metrics and statistics improved the benchmark relevance and
we hope to see them integrated into cloudy_vision!
You can view, comment on, or merge this pull request online at:
https://github.com/goberoi/cloudy_vision/pull/2
Commit Summary

[ADD] venv to .gitignore.
[ADD] resize setting, only import cv2 and resize when setting is set
to True.
[UPD] call_vision_api returns json instead of text, review vendors
dependencies.
[ADD] response_time metrics
[ADD] vendor statistics.
[ADD] tags_count metric.
[ADD] rekognition vendor.
[ADD] Ability to work with tagged images.

File Changes

M .gitignore
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-0 (2)
M cloud_vision.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-1 (132)
A example_tags.json
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-2 (3)
M readme.md
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-3 (22)
M static/template.html
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-4 (67)
M vendors/clarifai_.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-5 (6)
M vendors/cloudsight_.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-6 (12)
M vendors/google.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-7 (6)
M vendors/ibm.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-8 (9)
M vendors/microsoft.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-9 (7)
A vendors/rekognition.py
https://github.com/goberoi/cloudy_vision/pull/2/files#diff-10 (26)

Patch Links:

https://github.com/goberoi/cloudy_vision/pull/2.patch
https://github.com/goberoi/cloudy_vision/pull/2.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/goberoi/cloudy_vision/pull/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB4CUJ9PgHY3GPEmnMAfGjbV3dMuPUpks5rRVFmgaJpZM4LhH8o
.

Hi, did you have time to check it out? Thanks.

Hi @lucasdchamps, apologies for my slowness, I finally had a chance to review and accept your changes today.
Really nice work. I appreciate the new features: tagging, latency measurement, and Amazon's API. I also like your attention to detail on small things like: making resizing and cv2 import an option,  and fixing my kludge on returning text instead of Python structures from each vendor call.
I plan on updating the blog post and static generated content over the next couple of days, and I'll be sure to point to your contributions. Thanks again!


cannot allocate memory for thread-local data: ABORT

What steps will reproduce the problem?
1. Install mod_pagespeed_stable && restart apache 2.4.10
2. Visit hosted site

What is the expected output? What do you see instead?
Optimized page! Empty page!

$ curl -I http://hosted_site/
HTTP/1.1 200 OK
Date: Fri, 05 Dec 2014 13:11:54 GMT
Server: Apache/2.4.10 (Ubuntu)
Cache-Control: max-age=0, no-cache
Vary: User-Agent
Content-Type: text/html; charset=UTF-8

What version of the product are you using (please check X-Mod-Pagespeed
header)?

[Fri Dec 05 13:01:43.629435 2014] [core:notice] [pid 4874] AH00094: Command
line: '/usr/sbin/apache2 -D FOREGROUND'
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
cannot allocate memory for thread-local data: ABORT
[Fri Dec 05 13:04:07.486767 2014] [mpm_prefork:notice] [pid 4874] AH00169:
caught SIGTERM, shutting down
On what operating system?
Ubuntu LTS 14.04

Which version of Apache?
2.4.10

Which MPM?
Prefork

Memory mapping of apache2 process:
With http://paste.ubuntu.com/9382185/
Without http://paste.ubuntu.com/9382186/

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 5 Dec 2014 at 1:19

Any luck reproducing?


Get media track details (resolution and aspect ratio)

Hi. Is it possible to get the details of the remote video track added? The underlying MediaStreamTrack allows access to these settings, as per https://w3c.github.io/mediacapture-main/#dom-mediatracksettings.
Context: In Unity, when the remote video stream starts playing, I need to size the MediaPlayer's quad to match the aspect ratio, which can vary depending on the source video settings. Perhaps there's another way to do this?

The link you are referencing is a JavaScript API to capture videos, not a WebRTC one. There is no such thing as MediaStreamSettings in the WebRTC 1.0 standard, so it's not available in C++.
Surprisingly, there is currently no API that I know of which gives any information about the remote track. The only way is to get the frame size from the first callback invoke and lazily setup anything you want from there. This is what TestAppUWP is doing with its call to CreateVideoStreamSource():
https://github.com/microsoft/MixedReality-WebRTC/blob/a2a3c9ff7109567a1f5945b33ab3ca3aab94f423/examples/TestAppUwp/MainPage.xaml.cs#L979-L1003
We discussed adding an event for that (can't find the discussion again sorry), that would be doing that work internally and expose some event like VideoResized or similar, but that is mostly for convenience, wrapping over that lazy check in the frame callback.
I am happy to change that if someone shows me an API somewhere that actually gives those info when the track is added. But webrtc::PeerConnectionObserver::OnAddTrack() currently only gives the webrtc::RtpReceiverInterface, which doesn't contain much information. And this is understandable, since the video resolution can change during the session, so providing a resolution when the track is added is meaningless. In fact, I am not even sure the RTP layer can know the resolution until the first frame is received and possibly even decoded; see this comment:

In our case, frame dimensions were absent from the packet headers when using the Multiplex WebRTC protocol to send H264 frames.

@djee-ms Thanks for the detailed response. Reading width/height from the first video frame and lazily initializing things from there is a perfectly acceptable solution for my purpose. I should have thought of that myself :)

I think an explicit event would still be more convenient. I'll see to add one later.


Regression: missing 'lock' @output in Angular (again)

Check that this is really a bug

[X] I confirm

Reproduction link
https://github.com/nolimits4web/swiper/pull/5225/files#diff-bfa627463b910d30122bd97c77f46167402610e987ac7922fb67145fb0104525L398
Bug description
It seems that after merging https://github.com/nolimits4web/swiper/pull/5225 the @Output('lock') was removed by a mistake
Expected Behavior
No response
Actual Behavior
No response
Swiper version
8.0.3
Platform/Target and Browser Versions
any
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

Wow, that's awkward :)
Thanks for reporting!


(PUP-8971) add encrypted data type (for puppet 6.1)

This adds the Encrypted data type.

CLA signed by all contributors.

This is https://github.com/puppetlabs/puppet/pull/6899 just targeting master.

Copying my comments from the earlier PR:

It is desirable to generate a session key per catalog compile, not per secret. I don't think it's blocking.
Since we're targeting master which requires ruby >= 2.3, we can drop the if RUBY_VERSION < "2.1.0" branch.
We should implement integrity protection to protect against bit-flipping. The use of a fingerprint doesn't cover all of the data. One option is to use ciphers that support AEAD. It generates a tag as part of the encryption process, and can be used to verify the ciphertext is unmodified.
The decryptor should not make assumptions about the algorithm used to encrypt (since those can happen on different systems at different times). So we can't assume the IV is 16 bytes (eg buffer[0..15], buffer[16..-1]]). The encryptor needs to provide all of the public inputs that the decryptor will need later. This includes IV, algorithm, and if using AEAD, tag.
OpenSSL provides EVP_Seal* methods to derive a symmetric session key, encrypt the secret using the session key, and encrypt the session key with the recipients' public key. I don't think it's accessible via Ruby, but would be good to confirm.

Lots of good input - I will need help though to make those changes, and it seems we need to discuss what exactly we want to do.
Will start by rebasing this PR onto master.

Keeping a session key in the catalog - can be done but is a bit tricky also considering use cases where there is no catalog. @joshcooper said "not block", which I take as "does not have to be done in first release of Encrypted data type"
Fixed, the backwards compatibility for Error cause for Ruby < 2.1.0 is now dropped
Protect against bit-flipping; isn't this important for the entire catalog? (If I can bit flip encrypted data then I can also change any data in the catalog). If supporting AEAD, should the user ask for it, or should it always be used if algorithm supports it? Alternatively possible to opt out if on by default when supported?
The Encrypted data type has a format which is the combined cipher-name and serialization format name, adding additional attributes is possible, but I would then break them out into individual optional attributes, for example format, cipher, iv_length, and tag.
Will investigate

On topic (5) - This stackoverflow-post answers that SEAL is not in the Ruby OpenSSL implementation, but it points to this gist that shows how to do a SEAL using RSA (asymmetric) - which is pretty much how it is already implemented only that the current implementation is using the same cipher algorithm also for the session key.
Not sure how to proceed.

Need to discuss how to best proceed - the use of AEAD (essentially GCM) requires an IV which can be static (0) if key is guaranteed to be different each time, and if it is not, a context + counter or a random IV (not recommended) must be used. Is the use of a random key (per encryption) guaranteed to be (sufficiently) unique?
Anything that requires a context in which encrypt/decrypt takes place makes the process more complicated. In a non catalog scenario, how do you get the key across - what data type is that?
When using GCM, what is a suitable tag to use? The cert fingerprint? And send that as clear text? (Is it ok to reveal that? It identifies the target, and could that be considered sensitive?)
Advice from @jsane above says if key is different each time, then no IV is needed, but with GCM there is always an IV (and preferably (?) it should use unique key).
Then mix the above with use of SEAL - as per the gist above? To encrypt the random key with RSA?

Just checking in, there's been no updates or changes to this PR for a year, is this still a data type we'd like to implement? If so what work is left that we need to do to implement it/how can we support you @hlindberg? Or, should we close the PR for now, until we have a path forward?

I think this is of value. I got suggestions/feedback regarding how encryption should work that I did not know how to handle right away. I then got busy with other things.
Basically, someone needs to pick up answer the questions I raised in my last comment above and take it from there. Happy to help that person out and talk about all the things I implemented but I don't have the time now to learn the stuff that was pointed out as being required for this to be a good solution. OTOH - what is implemented is better than not having this at all IMO. It can always be improved...

I also think that this is of value. Having this be an intrinsic part of the language would be preferable to an add-on solution.

Closing this for now, as we don't have the bandwidth to move forward with it and it has grown stale.
We can always reopen if we get the time.


share/get: ShrExGetter

Overview
ShrExGetter implements Getter over ShrEx/ND and ShrEx/EDS and their respective clients. It relies on Discovery
to get data providers/peers. ShrExGetter must verify data integrity itself or by relying on underlying protocol clients.
// GetShare is no-op.
func (shrg *ShrExGetter) GetShare(context.Context, *Root, row, col int) (share.Share, error)

// GetEDS fetches all the shares in the form of EDS committed to the given root over `ShrEx/EDS`.
func (shrg *ShrExGetter) GetEDS(context.Context, *Root) (*rsmt2d.EDS, error)

// GetShareByNamespace fetches all the namespaced shares committed to the given root over `ShrEx/ND`.
func (shrg *ShrExGetter) GetShareByNamespace(context.Context, *Root, namespace.ID) (share.NamespaceShares, error)

// WithProvider hints ShrExGetter to fetch data from the given peers instead of Discovery.
func WithProvider(context.Context, ...peer.ID) ctx

Closed by #1624


transition.getName and editors

UMLEditor follows closely the UML2 spec for State Machine Diagrams and does not show the name property of the transition. It only shows triggers, guards and actions.
Was there a reason not to retrieve the name for GIVEN and WHEN from triggers?

@jdevoo Skyfire doesn't support triggers now. I may find time to address triggers later.


Show/Hide form fields based on configurable condition

This PR will enable you to configure a field to show/hide in the admin based on a configurable condition.
Requires https://github.com/marmelab/admin-config/pull/63 to exist in admin-config.

How is that different from field.cssClasses(), or something more sophisticated that could be achieved with field.template()?

I tried field.template() but seems like it's a bad idea, you need to "copy" templates from the source, then you would need to keep them updated if ng-admin changes them etc.
I'm not sure how you would use field.cssClasses() to achieve this in a simple way, i might be missing something though so please explain if you think so.

Hmm, i guess cssClasses can be used, didn't catch that the current entry is passed along to the function. It might fulfill the need of something like this then.

OK then, I'm closing this.

I did an attempt to use field.cssClasses() to achieve what I wanted, but the problem is that it doesn't apply the css class on the right element, so it seems impossible to hide the label as well as the field.
Any idea on how to do this to hide the label as well? If not, this PR might still be a good idea.

That’s what .template() is for. No need to add another way to achieve the same thing.

Le 10 févr. 2016 à 03:03, Espen Høgbakk<EMAIL_ADDRESS>a écrit :
I did an attempt to use field.cssClasses() to achieve what I wanted, but the problem is that it doesn't apply the css class on the right element, so it seems impossible to hide the label as well as the field.
Any idea on how to do this to hide the label as well? If not, this PR might still be a good idea.
—
Reply to this email directly or view it on GitHub https://github.com/marmelab/ng-admin/pull/924#issuecomment-182166773.

But with template you would have to copy all the different templates from "source". That means maintaining that when ng-admin changes?
And I didn't get the template to override "label" even though I passed in "true" as the second argument.
Have anyone tried using this approach in a while, it didn't work for me at least...

On 10. feb. 2016, at 15.24, Francois Zaninotto<EMAIL_ADDRESS>wrote:
That’s what .template() is for. No need to add another way to achieve the same thing.

Le 10 févr. 2016 à 03:03, Espen Høgbakk<EMAIL_ADDRESS>a écrit :
I did an attempt to use field.cssClasses() to achieve what I wanted, but the problem is that it doesn't apply the css class on the right element, so it seems impossible to hide the label as well as the field.
Any idea on how to do this to hide the label as well? If not, this PR might still be a good idea.
—
Reply to this email directly or view it on GitHub https://github.com/marmelab/ng-admin/pull/924#issuecomment-182166773.

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

You just need to set the template to use a particular ng-admin directive, which will not change. See the documentation:
    listview.fields([
        nga.field('amount', 'number')
            .format('$0,000.00')
            .template('<span ng-class="{ \'red\': value < 0 }"><ma-number-column field="::field" value="::entry.values[field.name()]"></ma-number-column>')
    ]);

If you’re not comfortable building up on top of ng-admin directives, you can also write your own field type.

Le 10 févr. 2016 à 08:31, Espen Høgbakk<EMAIL_ADDRESS><EMAIL_ADDRESS>a écrit :
But with template you would have to copy all the different templates from "source". That means maintaining that when ng-admin changes?
And I didn't get the template to override "label" even though I passed in "true" as the second argument.
Have anyone tried using this approach in a while, it didn't work for me at least...

On 10. feb. 2016, at 15.24, Francois Zaninotto<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
That’s what .template() is for. No need to add another way to achieve the same thing.

Le 10 févr. 2016 à 03:03, Espen Høgbakk<EMAIL_ADDRESS><EMAIL_ADDRESS>a écrit :
I did an attempt to use field.cssClasses() to achieve what I wanted, but the problem is that it doesn't apply the css class on the right element, so it seems impossible to hide the label as well as the field.
Any idea on how to do this to hide the label as well? If not, this PR might still be a good idea.
—
Reply to this email directly or view it on GitHub <https://github.com/marmelab/ng-admin/pull/924#issuecomment-182166773 https://github.com/marmelab/ng-admin/pull/924#issuecomment-182166773>.

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

—
Reply to this email directly or view it on GitHub https://github.com/marmelab/ng-admin/pull/924#issuecomment-182237458.

@fzaninotto as I said, I've tried that:
    nga.field('images', 'embedded_list')
      .template('
<ma-embedded-list-field field="::field" value="value" datastore="::datastore"></ma-embedded-list-field>
', true)
      .targetFields([
        nga.field('url', 'file'),
        nga.field('order', 'number')
      ])

And this does not hide the "label", even though I'm passing in true as the second argument. This is on creationView().
I'm happy to use this approach (if it works), but it's not very simple to find the directives to use, and it doesn't seem to work as advertised, that's why I proposed the change that I did.

The second option for the template() method is on master, not yet released on a tagged version. Please retest with the master branch.

Ok @fzaninotto that worked. It now hides the label, so thats good, I still don't think this a very good solution, if I'm not missing something obvious that is.
When using master I achieve hiding the labels when I don't want the fields to be shown, but how to then show the labels, and the field when I want them to be shown?
    nga.field('productId')
      .template('
<ma-input-field field="::field" value="value"></ma-input-field>
', true)

When using this solution, overriding the template (and label), adding ng-if to the template so that i can dynamically show the field based on a value of the entry, I don't have an easy way to show the label when I want to show the field.
Is there a way to easily do that, without recreating the label html? Doing it this way also seems to break "cssClasses" etc, since that part of the template is not rendered.
Is there another "higher level" directive I can use to achieve this? If not, i'm still sort of fan of something like the solution I proposed in this PR. I can see many use cases for wanting to show/hide parts of a form based on values in the form.
It would be even nicer to be able to define "form fieldset", and show/hide them based on conditions.

Why don't you add the label in your own custom template?
ng-admin is not here to reinvent angular. It gives you the whole power of angular, so you should use it.

I understand that, but it's about making it easy to achieve common goals.
If i would create the labels my self, first of all, it's a lot of work if there are many fields this need to be done with. Second it introduces another place things can break and would need to be maintained as time goes by. Let's say you change how the markup is on a field, nest the label inside something else or whatever, and then you apply some styling to that parent element. Or you would like a span inside the label if the field is required so you could do some fancy styling etc. I just don't want to go in and change the overridden templates if ng-admin changes in the future.
I'm up for changing the API for what I made If you would like it to look different, but I still think it would be a good idea to have an easy way to make fields hidden/visible without having to override templates. The proposed way is not very neat.

I understand your concern. But the current implementation is already a tradeoff. I don't want to introduce another way to do it, it would bring confusion.
thanks for your suggestion anyway.


DOM don't get purged

steps to reproduce

access a video directly
click the YouTube home button
add a video to blacklist
notice the video not disappearing

expected
video in step 4 should disappear

does not happen anymore, closing


Override default DrawTarget::fill_solid implementation

This PR overrides the default implementation of DrawTarget::fill_solid with an optimized implementation.
In my application this caused a 90% reduction in drawing time for one special case where most of the drawn rectangle was overlapping the display border.

This PR overrides the default implementation of DrawTarget::fill_solid with an optimized implementation.
In my application this caused a 90% reduction in drawing time for one special case where most of the drawn rectangle was overlapping the display border.

This is odd as fill_solid calls fill_contiguous which should at this point be doing pretty much the same thing. Am I missing something. Can you provide the example?

fill_contiguous doesn't clip the area rectangle to the display bounding box.

fill_contiguous doesn't clip the area rectangle to the display bounding box.

Hmm I think it should but I also think this means both are wrong right now. The bounding box is defined from the sizes in new which are expected to be display size. That means that fill_solid won't be able to use the remaining 80x240 pixels of the off-screen framebuffer portion.
I think the proper solution is to bound to the framebuffer size inside fill_contiguous?

Hmm I think it should but I also think this means both are wrong right now. The bounding box is defined from the sizes in new which are expected to be display size. That means that fill_solid won't be able to use the remaining 80x240 pixels of the off-screen framebuffer portion.

Maybe this should be configurable in some way? If the off-screen portion of the framebuffer is never used drawing outside the visible area isn't necessary and only takes additional time.

I think the proper solution is to bound to the framebuffer size inside fill_contiguous?

Implementing proper clipping in fill_contiguous is more complex, because it needs to be able to skip the parts of the colors iterator that are outside the drawn area. fill_solid doesn't need this additional complexity, because all pixels are the same, and will therefore be faster.

Maybe this should be configurable in some way? If the off-screen portion of the framebuffer is never used drawing outside the visible area isn't necessary and only takes additional time.

Not sure if that makes sense. If you're drawing outside the display size (but still within framebuffer) you'd be doing it on purpose no? To say.. scroll into it later?

Implementing proper clipping in fill_contiguous is more complex, because it needs to be able to skip the parts of the colors iterator that are outside the drawn area. fill_solid doesn't need this additional complexity, because all pixels are the same, and will therefore be faster.

Not really. Fill contiguous is 100% same from ST7789 perspective. There are only 2 differences to fill_solid from this driver's perspective:

The colors can differ (which has NO impact whatsoever it's just different u16 in the pipe)
The iter can stop sooner (which has no impact either because the setup allows doing a window bigger than data)

The window (clip area of data to be drawn) is set to the area rect in both cases.
I'm actually unsure what happens if the window definition is out of bounds for the frame buffer atm. tbh.

Not sure if that makes sense. If you're drawing outside the display size (but still within framebuffer) you'd be doing it on purpose no? To say.. scroll into it later?

Not in all cases. If you, for example, want to draw an animation that moves a rectangle from outside the frame into view you could just animate the position and not the size. In the first frames most of the rectangle would overlap the visible area.

The colors can differ (which has NO impact whatsoever it's just different u16 in the pipe)

It has an impact as soon as you start clipping.

The iter can stop sooner (which has no impact either because the setup allows doing a window bigger than data)

If you don't clip at the bottom but on the right side you need to skip some pixels after each row, which isn't handled correctly by just setting the update window.

If you don't clip at the bottom but on the right side you need to skip some pixels after each row, which isn't handled correctly by just setting the update window.

You'd have to clip this way only I guess. Not sure about the performance impact of that tho.
Given this your change makes sense, I'm still worried about the extra 80x240 framebuffer space being un fill_solid able. That to me seems like a bug.
Imagine you wanted to draw a rect there and then scroll it, the way the clipping is done now it won't be allowed at all. I think we should clip to the full 320x240 frame buffer instead.

You'd have to clip this way only I guess. Not sure about the performance impact of that tho.

Yes, you would. There is a better way to do clipping included e-g, but it isn't available publicly yet.

Given this your change makes sense, I'm still worried about the extra 80x240 framebuffer space being un fill_solid able. That to me seems like a bug.
Imagine you wanted to draw a rect there and then scroll it, the way the clipping is done now it won't be allowed at all. I think we should clip to the full 320x240 frame buffer instead.

OK, I'll change the implementation.

You'd have to clip this way only I guess. Not sure about the performance impact of that tho.

Yes, you would. There is a better way to do clipping included e-g, but it isn't available publicly yet.

Given this your change makes sense, I'm still worried about the extra 80x240 framebuffer space being un fill_solid able. That to me seems like a bug.
Imagine you wanted to draw a rect there and then scroll it, the way the clipping is done now it won't be allowed at all. I think we should clip to the full 320x240 frame buffer instead.

OK, I'll change the implementation.

Thanks, I'll run some tests later today or tomorrow and merge after.

Worked nicely, thanks!


Add Sentry integration for error monitoring

Description
This PR addresses the issue of integrating Sentry for comprehensive error monitoring and logging, as described in issue #18  The changes include setting up Sentry within the project to capture and track errors, providing improved visibility and real-time alerts for critical issues.
Changes Made

Integrated Sentry logging for comprehensive error tracking
Configured the project to send logs and errors to the Sentry platform

Testing Done

Verified Sentry integration by generating and monitoring test errors
Checked that logs were successfully sent to the Sentry dashboard

Related Issue
Resolves #18

Tested the Sentry integration by generating and monitoring test errors. Here is a screenshot from the Sentry dashboard, showcasing the captured errors.

I have checked it too. It look good to me.
Thanks @MbxrAteeq !


TeleIRC Ansible Go Migration

What This PR Does
Removes all NodeJS TeleIRC remains and updates the jflory.teleirc role to be version 2.0+ compliant.
Questions I Have

When running the ansible playbook, I had to manually run systemctl daemon-reload on the server in order to reload the services on disk. What is the best way to do this via ansible?
What variable was used in the NodeJS release versions for the NickServ username?
I had to add an IRC_NICKSERV_USER variable to the env settings for this.

Otherwise, this is currently what is running in production for all RIT-related channels :tada:

Hey @Tjzabel, checking in if this Pull Request is still relevant? Are there any other changes to make since jwflory/ansible-role-teleirc#4 was merged? Let me know what the best next step is.

@jwflory this PR is what's currently running in #rit-foss. Feel free to merge :+1:

Argh, this is also blocked by needing a CI pipeline that works. 🤦🏻

@jwflory anything I can do to help out with this?

@Tjzabel If you have some free time and want to take a stab at migrating the Travis CI pipeline to something else, that would be cool. @deejoe shared some FOSS options I haven't explored before. I think Open@RIT is using GitHub Actions as part of their workflow. A few repos are also using CircleCI already, but I think I am the bus factor for the CircleCI repos.
Ultimately, if you are keen to work on it, I think you could use a platform of your own choosing. Anything you'd like to get more experience with, or something you know well and could implement quickly.

@jwflory I added a GH Actions pipeline. Feel free to take a look at it kicking off in my branch :+1:
I didn't add in the IRC notification section, do we feel that's super useful? I can try to see if GH actions supports sending to IRC if so.

Confirmed. The pipeline is passing on main.


how to get the graph feature

I'd like to konw how to get the graph feature. I don't find it.

Hi, you can find how to get graph feature in this link

This issue is solved.


Fix multiservice-discovery test to run with Cargo and Bazel

Add the possibility to run the test with cargo test
Fix Bazel test retrying the connection to sd-service in case of failure
Add docs how to update the test in case of failure

Closing this because unmaintainable in this state


Default Interface Methods

Description 📜
I have created a documentation on the issue Default Interface Methods in Java.
Fixes #2627

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Java_#Domain

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

Okay Sir, Doing it!!

@VenkateswarNayak Please have a look on below points-

Please delete this file desktop.ini, do not understand the purpose of this ?
In code snippets, please follow naming concention while naming your classes. Ex - First Letter of Class and Interface should be capitalized.
Verify again the output of code snippets again , some of them are wrong.
Can you please also write one point on - When two interface have methods with same name, How we access them in implemening class, if you can add this point.
Rest all is good.
Thanks

@sumitaccess007  Sir, I have updated the required changes as mentioned by you. Please, kindly review it.


Updated WPILib to 2024.2.1

Current dependencies on/for this PR:

main

PR #3   👈

PR #1

PR #2

This stack of pull requests is managed by Graphite.

Merge activity

Feb 13, 2:58 PM EST: @BruceMcRooster started a stack merge that includes this pull request via Graphite.


Do we need something like LaunchedEffect ?

Just wondering if we need a way to execute code in response to an observable's value changing. Sort of like LaunchedEffect in Jetpack Compose.
Also should we start making youtube videos and reddit posts to grow the community ? I've been thinking about making a youtube tutorial on super. Can we have a discord or slack so I can send ideas ?

Good Day, regarding the first paragraph, there is a way to execute code whenever an observable's value changes similar to LaunchedEffect and that is by using the rxWatch API. However, unlike the LaunchedEffect, you have to use the observable's value in the function. I don't think I've written it's documentation yet but it's code is sufficiently documented.
As for the second paragraph, It would be amazing if videos, posts etc are created regarding the project as that would be the fastest way to grow the community, if you have any questions while working on your video please don't hesitate to ask I would be very happy to help.
Regarding discussion platforms, I have gone on to create a Discord Server, a lot of things are still amiss but they will be adjusted overtime. This is the link: https://discord.gg/dhY2hXfB

@DrDejaVuNG Discord link seems to be broken. I will be working on videos soon ! Love the library.


Okta sync on team edit event not processed currently

I would like to know if there is a roadmap for this feature as I do not understand the value of this integration without the sync being instigated when teams are changed from within Okta.

@gmconklin it can be added... we're not currently listening for any events other than those triggered by GitHub. We would need to implement a webhook listener and have each IdP configured to send events to the app.
First sequence
In this sequence, we're reacting to a change in GitHub, ensuring that teams are not manually edited
sequenceDiagram
    autonumber
    participant GitHub
    participant team-sync
    participant IdP
    GitHub->>team-sync: event (team created/edited)
    team-sync->>IdP: request group members
    IdP->>team-sync: return group members
    team-sync->>team-sync: compare members
    team-sync->>GitHub: update team members

Second sequence
In this sequence, we're running on a schedule
sequenceDiagram
    autonumber
    participant GitHub
    participant team-sync
    participant IdP
    team-sync->>team-sync: scheduled sync (cron)
    team-sync->>IdP: request group members
    IdP->>team-sync: return group members
    team-sync->>team-sync: compare members
    team-sync->>GitHub: update team members

Third sequence (not currently supported)
In this sequence, we would need to respond to changes in the IdP (i.e. Okta) and make updates based on those changes.
sequenceDiagram
    autonumber
    participant GitHub
    participant team-sync
    participant IdP
    IdP->>team-sync: event (group created/edited)
    team-sync->>IdP: request group members
    IdP->>team-sync: return group members
    team-sync->>team-sync: compare members
    team-sync->>GitHub: update team members

In order for us to support this we will need to implement a few things (completely doable, but should be laid out):

We need webhook verification implemented with a distinct endpoint. The current listener is validating GitHub payloads
Will all groups in Okta be sent to the app? This is one area where we might see a lot of noise

We implemented cron as a way to maintain an "eventually consistent" approach so that you can have minimal delays in provisioning. Using a 1h schedule, for example, isn't a massive blocker to most organizations. Since the app responds to GitHub events, we'll still have the benefit of ensuring no unauthorized access, but might have to wait an hour to get new users added to groups.
With that context in mind, we can probably add this as a feature, but I'll need to do some testing to make sure we can support it adequately