Fix using $this in static context in Subscription.php

The updated Subscription::handlePaymentPaid changed in #220 is a static function, but tries to use $this. This causes php to throw an exception Error: Using $this when not in object context. The $subscription variable is already available, so this could be used instead of $this.

Hi @Woutrrr,
thanks for letting us know and provide a fix!


decouple app-db and re-frame

This is just a proposal PR. I wasn't able to run tests (OS X) or update examples. I can put more work into this if the general idea is approved.
In Plastic I had to vendor re-frame, because I wanted to use my own app-db and router. Unfortunately router.cljs, handlers.cljs and subs.cljs are requiring re-frame's db.cljs directly which didn't give me a chance to cherry-pick them independently.
This PR removes direct dependency of router.cljs, handlers.cljs and subs.cljs on db.cljs. To preserve backward compatibility this dependency is moved to core.cljs which should be used as public api by majority of re-frame consumers anyways.
The second change is making automatic start of router loop optional. Again, it was moved to core.cljs. Library consumers who will not include core.cljs can still include router.cljs and kick-start router loop by calling  (router-loop some-app-db) manually (or provide their own).
This PR does not touch undo.cljs because it is not exposed via core.cljs, I'm afraid decoupling it from app-db would break current API. Anyways, I don't need re-frame's undo at this point

Btw. this would allow me to use re-frame as a library in Plastic. My situation is a bit more complicated, because I'm running a web worker with its own re-frame instance. Some jobs dispatched on worker need some continuation on main thread, so I really need to implement my own routing.
If anyone is interested, my overlay over re-frame lives here:
https://github.com/darwin/plastic/blob/master/cljs/src/main/plastic/main/frame.cljs
https://github.com/darwin/plastic/blob/master/cljs/src/worker/plastic/worker/frame.cljs

Looks reasonable to me, fwiw.

I just tested to include re-frame with this PR applied. And still it is not suitable for me to consume it as a library. Another problem are id->fn, key->fn and other state vars littered around. I cannot create an isolated instance of re-frame with its state.
I need two instances of re-frame living in a single javascript context. This is for development, in dev mode I run both main and worker thread in main javascript context to ease development and debugging (cljs-devtools do not work for web workers and devtools in general are not UX optimized for multi-threaded development in javascript).
My current solution was to copy re-frame sources two times, each under its own namespace. This is how I got around state being hardcoded.

I'm not sure this will help with what you are trying to achieve but ... I have for a while now been considering putting all re-frame state into a single deftype and then making all re-frame.core API functions be defined in terms of that type.
(deftype re-frame [^:mutable app-db
                             ^:mutable id-fn
                             ^:mutable key-fn
                             etc .....]

     ;; re-frame core
     (dispatch [this event]  ...)
     (dispatch-sync [this event] ....)
     (register-sub [....] .....)

)

That would then allow you to create different re-frame instances.  It would be backwards compatible because the existing API would be rewritten in terms of a single global instance.
Having said this... the idea remains not 100% thought through and, given my current workloads, there's no chance of me doing this in the next couple of months (even though it probably isn't that hard).

Thanks for commenting. I thought about it last night and I decided to rewrite re-frame to fit my needs. I will try to preserve 0.4.1 API in re-frame.core.
Here is my current progress (it probably won't compile, just an proof-of-concept rewrite):
https://github.com/darwin/re-frame/blob/transducers/src/re_frame/frame.cljs
https://github.com/darwin/re-frame/blob/transducers/src/re_frame/core.cljs
Plans:

one re-frame reframe instance is called "frame" and should be a value, all frame manipulations should be pure and return a new frame value

frame should keep state and provide a transducer: [state, event] -> state
this transducer is completely decoupled from underlying ratom or core.async channel. It can be used in app-specific ways. Default implementation in re-frame.core will implement 0.4.1-style dispatch and router-loop using core.async. Other implementations may apply this transducer differently. As a simple example imagine: given a seq of events, you can easily apply transducer to produce seq of corresponding app states. Or transduce seq of events into the final state. Or do arbitrary composition of frame transducer with app-specific transducers. For example you can easily filter events, prioritize them or do arbitrary algorithmic transformation on events or resulting states.

middlewares are already transducer-like, I will try to not touch them, I will just drop pure middleware, which will be implemented on re-frame.core level. Middlewares should have no knowledge of underlying-mechanism of state application (i.e. no dependency on reagent/atom).

again subscription subsystem should have no knowledge of underlying-mechanism of state application (no dependency on reagent/atom).

closing, let's move to https://github.com/Day8/re-frame/pull/107


fix(deps): update icr.io/cpopen/ibm-operator-catalog:v4.15 docker digest to 8b6323f

This PR contains the following updates:

Package
Update
Change

icr.io/cpopen/ibm-operator-catalog
digest
3aeaffc -> 8b6323f

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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

GitHub release
v1.4.11

Your semantic-release bot :package::rocket:


Video not loading

Problem
I'm trying to load a local fs video and it does not play at all.
use dioxus::prelude::*;

fn main() {
    dioxus::desktop::launch(app);
}

fn app(cx: Scope) -> Element {
    cx.render(rsx! (
        video { src: "dioxus://index.html/test.mp4", controls: "true", "type": "video/mp4" }
    ))
}

I also tried src:

dioxus://test.mp4
test.mp4
./test.mp4

Steps To Reproduce
Steps to reproduce the behavior:

Create video tag
Load it inside a video tag

Expected behavior
The video should start playing
Environment:

Dioxus version: 0.2.3
Rust version: 1.59.0
OS info: Manjaro
App platform: desktop

Questionnaire

[ ] I'm interested in fixing this myself but don't know where to start
[ ] I would like to fix and I have a solution
[x] I don't have time to fix this right now, but maybe later

I'm not sure where you saw that you need to prefix the asset with dioxus://index.html but that's not necessary. Just include the path relative to your crate root.
fn app(cx: Scope) -> Element {
    cx.render(rsx! {
        div {
            video {
                src: "examples/assets/video.mp4",
                autoplay: "true"
            }
        }
    })
}

works for me.

Damn my video is HEVC (H.265 encoded) MP4!
And that brings me to the next question: Is there support for MP4/MKV/AVI H264/H265/etc.?

Currently, desktop apps are rendered with the platform's WebView library

(https://dioxuslabs.com/guide/)
I think that means that video codec support depends on your system, not Dioxus – so it might vary..

It seems that if your videos aren't supported by browsers, then using them in desktop won't work.


[REQ] add a (GH-compliant) license file

Hi there, 1st of all thanks for this cool work !
Since we've "doxed" it in our HyMPS project (under the AUDIO category \ Effects section \ General page \ Compressing subsection), can you please add a license file to it ?
As you know, expliciting licensing terms is extremely important to let anyone better/faster understand how to reuse/adapt/modify sources (and not only) in other open projects and vice-versa.
Although it may sounds like a minor aspect, license file omission obviously causes an inconsistent generation of the relative badge too:

(badge-generator URL: https://flat.badgen.net/github/license/lbros96/MultiBandCompressor/?label=LICENSE)
Anyway you can easily set a standard one through the GH's license wizard tool.
Last but not least, let us know how - in your opinion - we could improve our categorizations and links to resources in order to favor collaboration between developers (and therefore evolution) of listed projects.
Thanks in advance.

Hi I have just added a license file. Thanks for the heads up glad you enjoyed the work.


Pace refactor

See https://github.com/GEOS-ESM/pace/issues/41

@FlorianDeconinck - NDSL, PyFV3, and PySHiELD have been created in the NOAA-GFDL organization.  One the current PRs are accepted and merged, I think we can proceed with the plan.

👍
Github doesn't allow me to cross-post issues or move an issue from our GEOS-ESM project into the NOAA-GFDL, so we'll track progress on the https://github.com/GEOS-ESM/pace/issues/41 side of things, and I'll cross post a summary here

I started to add this info in the NASA PR, but thought maybe you wouldn't want clutter info about the a different org in your PR.

I think it's good info on the issue, I don't segregate it's all Open Source. I would have rather put everything here but Github is not allowing me so we might have those kind of cross-posting issue often

ndsl is in. Much clean up needs to happen but the basics are done and moved in Pace

pyFV3 and pySHiELD have been created and their main branch is now protected (discussion on git strategy to follow)
Pace has been refactored to bring together all the packages.

Remaining task:

docs needs splitting
Makefile workflow is broken in all repositories
docker is broken in all repositories

Clean up on naming and random bits will be an ongoing effort.

New repositories:
ndsl
pyFV3
pySHiELD


Still can't figure out Bookings and how to restrict booking dates to a few months in the future

[Enter feedback here]
All I wanted to do was say I did not really understand the page I was viewing from Microsoft.  It did not seem to address any issues of relevance for me and I must confess to not really understanding it.   I'm trying to use Bookings but nothing about it seems intuitive to me.  I can't change the availability of permissible dates, e.g.,  I'll try to find other options

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

ID: adb53eb7-85a1-6aa0-dfd1-e2b54586008a
Version Independent ID: 5532470a-a47d-e3bd-4e74-02b2c822cae1
Content: Microsoft Bookings
Content Source: microsoft-365/bookings/bookings-overview.md
Service: bookings
GitHub Login: @kwekuako
Microsoft Alias: kwekua

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!

@syarnellYIrsch Thank you for your feedback. For How to questions and technical problems, we recommend you to create a support ticket via the need help section on the admin center, so that our support team can assist you in fixing them.
Hope this helps!
Thanks
Sri


chore: adding resolutions for dependabot alerts

Description of changes
Adding resolutions for dependabot alerts.
Issue #, if available
N/A
Description of how you validated changes
builds, unit tests run.
Checklist

[x] PR description included
[x] yarn test passes

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

Codecov Report

Merging #492 (c2e6652) into main (5a1b0b6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #492   +/-   ##
=======================================
  Coverage   66.24%   66.24%
=======================================
  Files         228      228
  Lines       14999    14999
  Branches     3675     3675
=======================================
  Hits         9936     9936
  Misses       4624     4624
  Partials      439      439

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


setMaximumDate(date) in 'weeksMode' does not disable weeks paging like the way in 'monthsMode'

I need to look into this. I believe minDate and maxDate for weeks is not WIA.

@joecizac, @ekchang this is an easy fix I've done locally:
In MaterialCalendarView#setCalendarDisplayMode(...)
it doesn't call adapter.setRangeDates(minDate,maxDate) even though it sets the max and min in adapter.migrateStateAndReturn(...). Calling adapter.setRangeDates(...) will init the bounds of the new adapter.
My apologies for not submitting a PR, have been working to get it implemented and this, along with a number of other small items, have forced me to pull locally for now.

@emitchel it didn't work. It's locking the paging a week or two before the actual max date

We will be releasing a 1.3 snapshot soon. You're encouraged to try it out and let us know if these problems are still existent. Please tag any issues with the 1.3 snapshot with the 1.3-SNAPSHOT label. Thanks!

@ekchang Looking forward to test the snapshot.

Snapshot instructions: Change to the snapshot maven URL and add compile 'com.prolificinteractive:material-calendarview:1.3.0-SNAPSHOT' to your dependencies.

Confirm whether the issue is still present now that 1.3.0 is live.


Wrong rooms for scenario 113

Affected Scenario(s): [e.g. 6, 10 and 33]
Scenario 113 The Lost Thread
Describe the bug
The wrong rooms are displayed on the far left side of the map.  Room L3b should be at top left but is shown on lower left side of the map. Room L2a should be at the Bottom but is shown at the top left.  The two left most rooms are transposed.
in the top and bottom rooms, the wrong rooms are displayed. When opening the left door in room J2B, room L3b is show instead of L2a.  Similarly when the left door in room J1b is opened room L2a is shown instead of room L3b.  The contents of the rooms are okay.  Only slight problem is the placement of the dark corridors are on the wrong sides.
To Reproduce
Steps to reproduce the behavior:

From starting room
Click on door at lower right side which reveals room J2b.
Click on door on left side which reveals room L3b which should be the top left room.
Click on dark corridor on bottom (which should be on top) which reveals room above which should be room L3b but is shown as room L2a.

Browser : [e.g. Chrome, Firefox]
Safari 15.4 on OSX 12.3
Chrome on windows, don't know version.

Hi @cafelizardo, Sorry for the later reply, it's been really busy here 🙁  This should be a relatively easy fix, I'll get it into the next release 🙂


Extend Groove Gauge minimum %'s to 0.01%

Title, but Non-Hard gauge should be at 2.00% at least.
You can also add an option for displaying as 2%, 1%, 0.1% or 0.01% at minimum.

Is this about matching LR2 behavior health/scoring-wise or is this a request for new visual extension?

Just a new visual extension.
fyi, the current gauge is displayed at 1% minimum.

Is this about matching LR2 behavior health/scoring-wise or is this a request for new visual extension?

This is mating not for LR2, a oraja series which number after dot is 407


entering and exiting altscreen in the terminal causes mouse wheel scrolling to misbehave

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.95.3
OS Version: Mac OS Sonoma 14.7.1

Steps to Reproduce:

Open Terminal
Create enough output that the terminal scrolls
Run any command that switches the terminal to altscreen and back. For example, run and quit less /usr/share/dict/words or run and quit vim.
Attempt to scroll the terminal using the mouse wheel.

Expected behavior:
The terminal scrolls relative to the current position (the bottom of the scrollback).
Actual behavior:
Attempting to scroll up has no effect. Attempting to scroll down jumps to the top of the scrollback and scrolls down from there.
Based on the behavior, I'd imagine that switching to altscreen is resetting some notion of the internal scroll position to the top of the scrollback, and it's not being properly restored when the altscreen is ended.

/duplicate https://github.com/microsoft/vscode/issues/224750


Add entity modifier middleware

This PR replaces the conditional validation for XCode Playground to a more flexible and testable function. It adds a new middleware called Entity Modifier that is intended to be used when changes are required to Entity's path.
In addition this PR bumps Go to 1.17.

👍


Fix nif path

The nif can not be found in 0.2.0-rc.1 version

@tzumby hey. it seems we should set nif path - https://hexdocs.pm/rustler/0.22.0-rc.1/Rustler.html#module-configuration-options

@tzumby would you mind releasing it on hex.pm?


Add minimum column width as an option to reading order

Add column width as an option for reading order, allow to force a minimum width which is usefull for some ref number / option list.

Before / after (note that line number are merged with the line and not anymore in their own column.

We can make an automatic estimatio algorithm to preprocess the layout of the page, font sizes and other data to best-guess good values of minVerticalGapWidth and minColumnWidthInPagePercent for running the ReadingOrderDetection module on a document.


kv(ticdc): refine regionTsManager

What problem does this PR solve?

Issue Number: close #7151
What is changed and how it works?
this is a part of batch process resolvedTs, change the Upsert call parameter type to reduce object allocat after #7079  is merged

add a func named Insert to  insert the expired items popped from the heap when resolving lock
remove unnecessary func call heap.Fix if the resolvedTs is not updated

Check List
Tests

Unit test
Integration test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
 `None`.

/run-all-tests

/merge

/run-verify-test


added fallback dns server option

resolves #24
added option to specify a fallback dns server, so that is not found locally it will fetch records from that server.

@glinton done with the import reorder


fix: ensure fee explainer initially aligns with trade quote

Description
Fixes trade fee explainer:

Reflects active trade quote values and compare against the pre-fox-discounted trade fee, instead of a blanket 30bps
Pre-populates the sliders for the current quote values
Formats dollar amounts as user selected currency instead of USD
Fixes orange fox power slicer triangle to point to the correct part of the slider (it was too far right previously)

Includes general cleanup of fee data around the swappers.
Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #5990
Risk

Risk that fee amounts are somehow broken or missing in the trade input, trade confirm and trade steps during trade execution
Risk that fiat amounts are incorrect when on non-usd currencies

Testing
Test the risk points above to prove no issues.
Engineering
Worth testing with monkey patch to ensure big fox holders arent rugged.
Note that swappers only accept integer bps values, so this change take that into account without presenting a confusing ux. It also maintains floating point fox discount amounts for better clarity around exact fox holding, which is also used to compute the fox discount that ends up being presented to the user
Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #6010   👈

This stack of pull requests is managed by Graphite.

@gomesalexandre as discussed I've updated the UI to display the sub $1000 free condition accurately:


Default loglevel is ERROR though using debug sources

OpenUI5 version: 1.50.9
Browser/version (+device/version): Chrome 65.0.3325.181
Any other tested browsers/devices(OK/FAIL):
URL (minimal example if possible):
User/password (if required and possible - do not post any confidential information here):
Steps to reproduce the problem:

Use debug sources by adding ?sap-ui-debug=true as URL parameter (e.g. http://localhost:8000/?sap-ui-debug=true )

What is the expected result?
I'm using the debug sources so log output with jquery.sap.log.debug should be written to the console.
What happens instead?
Despite using the debug sources the log level for jquery.sap.log is 1 (= ERROR) so that output with jquery.sap.log.debug is not written to the console.
Any other information? (attach screenshot if possible)

Are you sure with the debug sources?
The stack trace at the right hand side more looks like productive sources with source maps being active (Chrome dev tools show debug source file names as those are used by the source maps, but executed code is minified code and only de-minified in the source tab of the dev tools)
But for sure this doesn't match the URL parameter.

Hi @codeworrior
You're right. Seems the debug sources were not loaded.
Today it works and I can't reproduce the behavior.
Regards,
Frank


Update all dependencies and move graphql to peerDeps

Codecov Report

Merging #108 into master will decrease coverage by 0.08%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #108      +/-   ##
==========================================
- Coverage   42.57%   42.49%   -0.09%
==========================================
  Files          20       20
  Lines         505      506       +1
  Branches       87       94       +7
==========================================
  Hits          215      215
- Misses        290      291       +1

Impacted Files
Coverage Δ

src/loaders/introspection-from-export.ts
0% <0%> (ø)
:arrow_up:

src/engine/codegen.ts
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Feature Request: Create program what automaticly will patch blender

In order to patch the executable to work on 7, the import table needs to be modified so that it loads this library instead of the real user32.dll. This has the potential to cause stability issues with Blender.
The current implementation makes the change at compile time thus no executable hacking is required and will not cause stability issues.


Add Security def changes for Content Moderator

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@marstr I have context on this one, I merge. Please reach out to me if you have any concerns. Thanks!

No modification for AutorestCI/azure-sdk-for-ruby

 https://github.com/Azure/azure-sdk-for-python/pull/1721


Missing Support Line for Bulgaria

Hello,
I have bought a license key for Microsoft Office Pro-2016. For more than 30 days, I'm trying to add the license to the product
but won't work. The supplier cannot resolve the issue. Same time I'm trying to resolve the issue by activating it via phone, but the phones given for Bulgaria Region even in this page are not responding. They forwarding the call to the server, which cannot be a place for support. I call 4- times already in the regular hours, and nobody respond on my call.
Again, I'm fighting to install, a license which I own for MS Office Pro 2016.
This page, and contacts/phone is not supporting the line with people/organization winch such issues.

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

ID: 3ef2273c-fbf5-b34d-19c3-c4a8fdbf2539
Version Independent ID: 07eddc2c-a408-3f47-d056-5cf1bd95ca4e
Content: Support information for Bulgaria - Microsoft 365 admin
Content Source: microsoft-365/admin/support/bulgaria.md
Service: o365-administration
GitHub Login: @cmcatee-MSFT
Microsoft Alias: cmcatee

@ivaydesign Please do not post that information here. Please send it directly to me<EMAIL_ADDRESS>

@msbemba would you please email me?

@cmcatee-MSFT Sorry I missed this. I don't have access to call this number, It is not connecting from India. @ivaydesign Were you able to send the details to<EMAIL_ADDRESS>?
Thanks
Sri

@cmcatee-MSFT Sorry I missed this. I don't have access to call this number, It is not connecting from India. @ivaydesign Were you able to send the details to<EMAIL_ADDRESS>?
Thanks
Sri

@ivaydesign I'm currently working with the author to see if we can get this information. Meanwhile, would you be able to share the below information with<EMAIL_ADDRESS>?
CFN/TFN/Customer dialing number :
ANI(Caller's number)
Date of call:-
Time of call with time zone
Outgoing/incoming call :
The options you selected in the IVR:- :
Call ID/interaction ID (if available):-
Thanks
Sri

@msbemba I received the call info from @ivaydesign and have forwarded it internally for investigation. Thanks!

@msbemba Thank you very much for the contribution and sharing this explanation. @ivaydesign Hope it helped. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Add some functions, fix some stuff

BOOL should be a typedef for c_int
PFD_TYPE_RGBA, PFG_TYPE_COLORINDEX, PFD_MAIN_PLANE, PFD_OVERLAY_PLANE, and PFD_UNDERLAY_PLANE should be BYTE
c_struct! should generate structs with public fields
Add the following functions:

GetProcAddress
DescribePixelFormat

Add the following types:

FARPROC
NEARPROC

There are a lot of other constant types that are wrong, but 🤷

There are a lot of other constant types that are wrong, but 🤷

There's places where the C api isn't even consistent about what type a value is supposed to be, is the problem.
I can accept the new types and externs, but the changes to types are a breaking change technically.
If there is gonna be a 2.0 we should go farther and use more actual newtyping and repr(transparent) stuff. Like the newer style in the windows-rs crate.

There's places where the C api isn't even consistent about what type a value is supposed to be, is the problem.
I can accept the new types and externs, but the changes to types are a breaking change technically.
If there is gonna be a 2.0 we should go farther and use more actual newtyping and repr(transparent) stuff. Like the newer style in the windows-rs crate.

Ah, right, those would be a breaking changes. In the meantime, I guess we are stuck with casting constants as necessary? (Or taking the module approach, as described in #2)

Ah, right, those would be a breaking changes. In the meantime, I guess we are stuck with casting constants as necessary? (Or taking the module approach, as described in #2)

The pub fields thing is technically also a breaking change, though, (AFAICT) and that's just broken w/o a workaround. Can that be merged, at least?

The pub fields thing is technically also a breaking change, though, (AFAICT) and that's just broken w/o a workaround. Can that be merged, at least?

making the fields pub is allowed, you just can't make them private again after that. And if all fields are pub and then structure isn't non_exhaustive you can't add more fields (pub or priv).
But going from some amount of private to all public is legal.

making the fields pub is allowed, you just can't make them private again after that. And if all fields are pub and then structure isn't non_exhaustive you can't add more fields (pub or priv).
But going from some amount of private to all public is legal.

Ah, right, I'm only making private fields public not adding new fields. Got confused there.
With that out of the way, I rolled back the breaking changes, should be ready to merge.

Ah, right, I'm only making private fields public not adding new fields. Got confused there.
With that out of the way, I rolled back the breaking changes, should be ready to merge.


Problem with deficit integral for centrally impinging wakes

There seems to be a problem/error/bug with the self similar gaussian wake if it hits a downstream turbine centraly.
It is easy to reproduce the error using the example file simulationLogarithmicInflow.m. Just add subModels.modelData.ad=0; and subModels.modelData.bd=0; after the subModel definition.
I assume the problem is caused when the deficit integral is computed using the bivariate cumulative distribution function.
Until resolved, it is possible to fix the problem by replacing deltax < obj.x0 with 1 in line 117 of self_similar_gaussian_velocity.m. This way the integral is computed numerically and the bvcdf function is avoided.

Thanks for finding this issue! It indeed seems to be something with the integration scheme. I have considered completely removing the bvcdf_wake code for simplicity, but it appears to be a factor 3 faster, doing some quick runs. One solution lies in ensuring that dy and dz are nonzero, simply as:
% Corrections to avoid numerical issues if dy == 0     dy = eps; end if dz == 0     dz = eps; end
I will push this solution back to the master branch.


Move to dev/prod model?

I'm wondering if we want to adopt a dev/prod model. Basically this means:

When a PR gets accepted it does not go into master, it goes into a branch dev.
Once a push to dev happens it triggers a different series of CI tests

Usually this is where longer tests would run (only quick tests need to pass to get merged into dev)
This is where we could ensure/determine if the changes break downstream repos (we'd thus avoid breaking downstream repos until dev gets merged into master)
If these CI tests pass, then we'd merge dev into master.

I'm only opening this issue on ParallelZone, but it would apply throughout the stack.
@NWChemEx-Project/ci-cd thoughts?

@yzhang-23 not yet.

I think the idea is a good one. One question here is: what takes longer, building the code or running the tests?
At the moment I think building the code takes longer than running the tests. However, if we want to have tests that check the code more extensively this may become an issue. For example building a Fock matrix once given synthetic data could be quite fast as compared to doing a full direct SCF with real integrals, etc. One thing that will be needed in particular is some guidance on what is long and what is short. Is 1 second still short, what about 10 seconds, ...? 100 Tests of 10 seconds each still takes about 20 minutes.

@hjjvandam at the moment building the code takes longer. My hope is that between the roll out of Docker images, and cacheing, we can get the build time way down (I actually am optimistic we can get each CI run to under 5 minutes).
I'd be inclined to consider long vs. short more descriptive than prescriptive. Point being, I think merging into dev should focus on getting the most code coverage, in the least amount of time, whereas dev to master should focus on exhaustive coverage. The assumption is that exhaustive coverage is going to require, in some shape or another, significantly more resources than partial coverage. If that assumption is not valid, then I think the separation doesn't make as much sense; however, particularly if we throw some performance tests into the mix, I feel like it's a pretty safe assumption.

I am probably missing something, but what are the major advantages/disadvantages of this approach.  I see the major one of not breaking downstream repos in the master, but won't they still break in dev? Won't this still require a lot of management of keeping dev and master up to date with each other?  I do see potential advantages in the testing time, so that would be useful.

Assume I make a PR which breaks downstream repos. With dev/master, we can safely merge the PR into dev without breaking the downstream repos (they use master). While we work on fixes for the downstream repos (which is facilitated by being able to stage those changes into the downstream dev branches), other developers can develop off of the dev branches and development doesn't have to stop on upstream or downstream repos.
In theory I think the only additional management is creating the additional automation. More specifically, if changes don't break downstream repos they get automerged from dev to master. In theory the dev to master pushes should be fully automated, i.e., if dev doesn't break downstream then it gets immediately merged to master; if it does break the downstream repos it needs to wait for the downstream repos' dev branches to work with the changes.

If those longer (regression) tests are not ready, I suggest that we should get them ready, then move to the dev/prod model.

The tests will come (simply making sure we don't break downstream repos is going to be time consuming). The bigger question is how hard will it be to roll out a dev/prod model when those tests are ready vs. right now as we make the CI changes we're already in the process of making (e.g., Docker images, cacheing)?

I am probably missing something, but what are the major advantages/disadvantages of this approach. I see the major one of not breaking downstream repos in the master, but won't they still break in dev? Won't this still require a lot of management of keeping dev and master up to date with each other? I do see potential advantages in the testing time, so that would be useful.

@twindus I could be wrong, but my impression is that the downstream repos might be broken in the dev branch, and although testing the dev branch could be done automatically, merging it to master may still take some manual effort, since it may take several cycles of debugging/testing until all longer (regression) tests pass in the end. In my mind, the advantage of this dev/prod model is that we can always have a stable master version of the code to release, the price to pay is that we need to more work in merging dev to master.

I'm going to ping @zachcran to see what he thinks, since he's currently doing this for the CMakePP organization.

If those longer (regression) tests are not ready, I suggest that we should get them ready, then move to the dev/prod model.

The tests will come (simply making sure we don't break downstream repos is going to be time consuming). The bigger question is how hard will it be to roll out a dev/prod model when those tests are ready vs. right now as we make the CI changes we're already in the process of making (e.g., Docker images, cacheing)?

I think our current changes on CI with Docker images can be easily adapted to both branches, either master or  dev. We can can run different tests (assign different groups for the tests)  in order to merge the code into master or dev. We can design a workflow like this:

When codes pushed to dev, build the repo and run the unit tests; if all tests pass, merge the code into dev;
If 1 is successful, build the repo and run the longer tests; if all tests pass (unlikely in the first try), merge the code into master.
If 2 is not successful, manual effort is necessary to debug the code and re-run 1 and 2.

Thanks for the ping on this. The current work moving CMaize to the dev/prod model is in this PR. In CMaize, the workflow is currently planned to work similarly to what @yzhang-23 suggests:

A PR is submitted to dev, which must have passing unit tests and approving reviews before being merged to dev. Ideally the integration tests from 2 have already been run on the submitter's local system without error, but there isn't a hard requirement here.
If 1 is successful, the merging commit of the PR into dev triggers additional integration tests on the dev branch, which pull down some of our CMaize test repositories to make sure CMaize is still properly building, testing, and installing them after the changes.
3a. If 2 is successful, dev is merged into master and the changes go live. The version should be bumped accordingly as well, but I haven't figured this part out yet.
3b. If 2 fails, manual effort is necessary to fix the issue. Any solutions need to pass 1 and 2 again.

I'm going to ping @zachcran to see what he thinks, since he's currently doing this for the CMakePP organization.

I think a dev/prod workflow could be useful in the NWChemEx stack. In CMaize, the unit tests are more of an initial screening that cannot check the full functionality of the code due to CMaize being a build tool. Integration tests take more time and involve multiple repositories being built and installed, so it makes sense not to run them on every commit to a PR.
In the NWChemEx stack, I can see this dev layer being used to check for unacceptable amounts of performance degredation, the change breaking downstream repositories (as mentioned before), and running tests that may take 10x-100x as long as your usual unit tests (I am thinking <1 sec/test). @hjjvandam makes a good point that 100 tests that each take 10 sec still takes a lot of (CI) time when run repeatedly (for example, if someone makes many small commits to a PR without using [skip ci]). We could also use this second "testing phase" as a place to test that the Python bindings are working properly after an installation, if such a thing is necessary.
Some of the potential downsides I can think of right now:

It will likely be more difficult to debug errors that occur in the dev branch, especially if a complex installation setup is needed, like when checking for errors in downstream repos. If the integration tests are set up carefully, they should be able to set themselves up on a local system by running ctest, though.
The CI will become more complex. I am not sure how the docker setup will be handled between branches and workflows, but I have never looked into it.
It could be easy to accidentally start a PR off of master instead of dev or submit a PR to master instead of dev, so additional protections would need to be put in place to avoid these mistakes.
Fixing errors will require more pull requests to submit potential fixes, bloating our commit count. I don't particularly care about a high commit count, though, since it shows that work is being done.

3. It could be easy to accidentally start a PR off of master instead of dev or submit a PR to master instead of dev, so additional protections would need to be put in place to avoid these mistakes.

How to open a PR for a specified branch, say dev?

Can I design the dev/master CI as the follow?

We ban any direct PR to master. All PRs must go to dev instead.
PRs to dev go through the original CI steps: building,unit testing, doc building, etc. If all CI steps go smoothly, new codes are checked into dev;
Merging into dev immediately triggers a new testing job: some longer integrating tests would be run to ensure that the new codes won't break any downstream repos. Additional code building work might be necessary;
Once 3 is successful, merge into master; if 3 is not successful, human interference is necessary. One may need to restart from step 2 until all tests pass.
Currently we don't have the longer tests ready, but I will fake them with the existing unit tests, simply to pave the road and find the new path. Realistic tests can be added later.

@yzhang-23 what you have sounds good to me! For a proof of concept of the "longer tests" you can add a CI test to ParallelZone, which makes sure the changes don't break PluginPlay. I'd probably just do empty tests the rest of the way up, until the repos are public (and CI time doesn't count against us).

Anyone familiar with fromJSON()? I want to generate a matrix of file names using fromJSON():
matrix: ${{ fromJSON('[ {"dfiles":Docker/ParallelZone.Dockerfile}, {"dfiles":Docker/PluginPlay.Dockerfile} ]')}}
but get the following error
Error when evaluating 'strategy' for job 'file-name-test'. .github/workflows/test_JSON.yaml (Line: 33, Col: 21): Error parsing fromJson,.github/workflows/test_JSON.yaml (Line: 33, Col: 21): Unexpected character encountered while parsing value: D. Path '[0].dfiles', line 1, position 12.,.github/workflows/test_JSON.yaml (Line: 33, Col: 21): Unexpected value ''
Any idea? Many thanks!

Probably it is due to missing the double quotes in the JSON values.
matrix: ${{ fromJSON('[{"dfiles":"Docker/ParallelZone.Dockerfile"}, {"dfiles":"Docker/PluginPlay.Dockerfile"}]') }}

Probably it is due to missing the double quotes in the JSON values.
matrix: ${{ fromJSON('[{"dfiles":"Docker/ParallelZone.Dockerfile"}, {"dfiles":"Docker/PluginPlay.Dockerfile"}]') }}

Thanks! I will try.

Finally make the dynamical matrix definition work in github action! Opened a PR to update the docker_image_build action. Now we only re-build the image for a repo when the corresponding docker files are changed. So we need only maintain those docker files.
Now I only build and push the docker images without testing them. I believe test building of repos with the images are necessary to ensure nothing is wrong. I'm trying to add this feature to the docker_image_build workflow.

Problem found for the docker image building action (thanks for Ryan!): tagging still triggers the changed-files action, which causes error and stops the CI workflow. Opened a PR for a solution and hope it will fix this.

@ryanmrichard @zachcran As discussed above, in order to make a dev/master model, I have to run tests in different groups (unit test v. s. integration tests). I have some naive questions about testing in NWChemEx repos:

Generally, how to add a new test in a repo, for example, PluginPlay? Would adding new .cpp files under the test/ directory work? I know cmake uses add_test() for new tests, but here everything is done with cmaize.
I want to assign different labels to different types of tests, e. g., unit tests are labelled as "unit", and integration tests are labelled as "integration". How to do it with cmaize_add_tests()?

Generally, how to add a new test in a repo, for example, PluginPlay? Would adding new .cpp files under the test/ directory work? I know cmake uses add_test() for new tests, but here everything is done with cmaize.

CMaize's cmaize_add_tests command wraps the traditional CMake add_test command. cmaize_add_tests takes a SOURCE_DIR path. Any C++ file in that path (recursively) will be added to the test. So, to answer your question, if you add a .cpp file to that path it will be added to the test. That all said, cmaize_add_tests is a convenience function, if it doesn't work for your use case you can always fall back to add_test.

I want to assign different labels to different types of tests, e. g., unit tests are labelled as "unit", and integration tests are labelled as "integration". How to do it with cmaize_add_tests()?

If you look at parallelzone (specifically here) you can see the pattern I landed on. Basically, under tests/<language>/ there is one directory per test suite. Right now there's two test suites: "unit tests" and "documentation snippets". If you want to add integration tests I would add a new directory integration_tests and a new cmaize_add_tests command with SOURCE_DIR set to tests/<language>/integration_tests.

Generally, how to add a new test in a repo, for example, PluginPlay? Would adding new .cpp files under the test/ directory work? I know cmake uses add_test() for new tests, but here everything is done with cmaize.

CMaize's cmaize_add_tests command wraps the traditional CMake add_test command. cmaize_add_tests takes a SOURCE_DIR path. Any C++ file in that path (recursively) will be added to the test. So, to answer your question, if you add a .cpp file to that path it will be added to the test. That all said, cmaize_add_tests is a convenience function, if it doesn't work for your use case you can always fall back to add_test.

I want to assign different labels to different types of tests, e. g., unit tests are labelled as "unit", and integration tests are labelled as "integration". How to do it with cmaize_add_tests()?

If you look at parallelzone (specifically here) you can see the pattern I landed on. Basically, under tests/<language>/ there is one directory per test suite. Right now there's two test suites: "unit tests" and "documentation snippets". If you want to add integration tests I would add a new directory integration_tests and a new cmaize_add_tests command with SOURCE_DIR set to tests/<language>/integration_tests.

Thanks, Ryan! That really helps.

@yzhang-23 In addition to all of the great info @ryanmrichard provided, you can set the LABELS property on a test to label it:
set_property(
    TEST ${test_list}
    PROPERTY
        LABELS "integration_tests"
)

This lets you run ctest with the -L integration_tests argument to only run tests with that label. You can also run all tests without that argument with -LE integration_tests.
There isn't a great way to do this with the cmaize_add_test() function right now, but I do have an example of doing it in CMaize PR 99 (here) in tests/scripts/CMakeLists.txt for doing with with CMake's add_test() function.

@yzhang-23 In addition to all of the great info @ryanmrichard provided, you can set the LABELS property on a test to label it:
set_property(
    TEST ${test_list}
    PROPERTY
        LABELS "integration_tests"
)

This lets you run ctest with the -L integration_tests argument to only run tests with that label. You can also run all tests without that argument with -LE integration_tests.
There isn't a great way to do this with the cmaize_add_test() function right now, but I do have an example of doing it in CMaize PR 99 (here) in tests/scripts/CMakeLists.txt for doing with with CMake's add_test() function.

I will try your suggestions. Many thanks, Zach!

@ryanmrichard @zachcran @hjjvandam @twindus I'm now trying to apply the dev/master model with docker image. I have some thoughts on the longer integration tests in our previous design. Please help me to find out them right or wrong:

Each repo is associated with two docker images: one is the building image, which provides a software environment to build the repo, and the other is the release image, which contains the installed libraries compiled with the source codes of the repo.
The building image is built with a dockerfile, and may also depend on the release images of other repos. Updating the dockerfile would trigger the re-building of the building image as well as the corresponding release image.
Updating the source code of a repo would update the release image, if the building/testing processes are successful. Then, updating a release image also requires updating the building images of the repos depending on this release image. So, a chain of image rebuilding processes could be formed and this chain finally ends with the repos on which no other repos depend.
In my eyes, this chain of image rebuilding processes provides a thorough way to test whether a new code/dockerfile change would break other repos or not. So, the question is, do we really need to prepare some "longer integration tests" considering that we have to update all relevant images?
All images should be finally pushed only when the chain of rebuilding ends without any errors (all unit tests in different repos pass). If not, all images should be kept in their original forms. So, I should find an easy way to trigger the final push action when a chain of workflows complete successfully. I'm trying to figure this out.

@yzhang-23 I think this sounds like a reasonable test case. I still think we should leave room in the dev branch for longer integration tests, though, to run things like checking for unacceptable amounts of performance degradation and running tests that may take 10x-100x as long as your usual unit tests (I am thinking <1 sec/test). They don't necessarily need to exist right now, but we shouldn't lock ourselves out of that option later down the road.

@yzhang-23 I think this sounds like a reasonable test case. I still think we should leave room in the dev branch for longer integration tests, though, to run things like checking for unacceptable amounts of performance degradation and running tests that may take 10x-100x as long as your usual unit tests (I am thinking <1 sec/test). They don't necessarily need to exist right now, but we shouldn't lock ourselves out of that option later down the road.

I agree. We should prepare longer tests for performance evaluation. I can save some places for such tests in my workflows.

I'm not sure if having pushes to a repo's dev branch rebuild images for the entire stack will scale. Consider a change to ParallelZone/dev. This is going to rebuild images for the entire NWX stack. This will be extremely expensive in terms of CI time. Second, it requires PZ to know every downstream dependency which depends on it (a task which gets harder as PZ gets more popular). For non-API breaking changes (n.b., API includes behavior) to PZ this entire image cascade is also somewhat superfluous, as by definition the changes should not break downstream repos.
The only scalable solution I can think of is a combination of semantic versioning and pinning dependency versions. At present, we have a lot of downstream breaks, but that's also because with the exception of PZ and PluginPlay we don't have stable APIs.
I also realize that this comment is "chasing our tails". At least for me, there's too much going on and I can't keep it all straight without some sort of design doc to refer back to.

@yzhang-23 a possibility would be to only make images for new major and/or minor releases. We'd also have to be a bit more discerning with what constitutes a minor release.

@yzhang-23 a possibility would be to only make images for new major and/or minor releases. We'd also have to be a bit more discerning with what constitutes a minor release.

I think a possible compromise is in the building images we only include non-NWChemEx packages, but not the release images of dependent repos (let CMake handle them on-the-fly). In such a setting, the building images are not necessarily updated frequently, and we can save time in building.

The new CI design (dev/master model and docker-image-based building/testing/releasing) works! Workflows triggered by repository_dispatch tested for Utilities, which is the first step. My planned second step would be make the new CI work for a smaller testing set of repos (Utilities, ParallelZone, TensorWrapper, Chemist, PluginPlay and SimDE). SimDE is the hub connecting many other repos, and NWChemEx would the end downstream repo (maybe only NUX depends on it).
CI testing in multiple repos at the same time is a pain. Hope everything would go smoothly.

Anyone has any idea on how to trigger a workflow in a non-default (not master) branch when another workflow is done successfully?

Finally I gave up this idea (trigger a workflow in a non-default (not master) branch) in our dev/master model. Repository_dispatch or workflow_run only trigger workflows in the master branch (correct me if I am wrong). Now the ugly thing is that I have to keep a large workflow file which contains many jobs running only in the dev or other non-default branches.

I'm trying to login to the GitHub docker image registry using the official action login-action:
- name: Login to GitHub Container Registry       uses: docker/login-action@v2       with:         registry: ghcr.io         username: ${{ github.actor }}         password: ${{ secrets.DOCKER_PAT }}
However, my workflow failed for missing the password:
Run docker/login-action@v2   with:     registry: ghcr.io     username: yzhang-23     ecr: auto     logout: true Error: Username and password required
It looks that the value of 'password' is missing. This is very weird since I had used this login action in the way above many times before. I suspected that this was due to the expiration of the token DOCKER_PAT, but updating DOCKER_PAT did not help. Any idea?

I'm trying to login to the GitHub docker image registry using the official action login-action:
- name: Login to GitHub Container Registry
      uses: docker/login-action@v2
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.DOCKER_PAT }}

However, my workflow failed:
Run docker/login-action@v2
  with:
    registry: ghcr.io
    username: yzhang-23
    ecr: auto
    logout: true
Error: Username and password required

It looks that the value of 'password' is missing. This is very weird since I had used this login action in the way above many times before. I suspected that this was due to the expiration of the token DOCKER_PAT, but updating DOCKER_PAT did not help. Any idea?

Solved with add a line into the parent workflow file: secrets: inherit, but not fully understand why.

Just realized one cannot totally rely on the overall running report of GitHub actions. For example, for the automerge action pascalgn/automerge-action, GitHub would report a success even when the merging action actually gets skipped or fails! One should check carefully on the results of every action.


Add possibility to attach closed issues from TestRail as Known Issue without reopen them

If we have stable TestRail integration, Zafira check bugs status.
Here we have only open bugs available (even with some duplicates):

It will be good to have closed bugs assigned to this tests (with green background) for selection as well. May be in separate extendable div.
Will be useful if bug was already closed on Master branch, but still available in some feature branch.

Looks like this ticket is dedicated to Jira integration, this logic was globally refactored in the latest releases.


THUMB typo in uqsub16

Describe the bug
Looks like possible copy/paste typo in ARMTHUMBinstructions.sinc in uqsub16. Discovered with
support/sleigh -t ARM6_le.slaspec
Warning: temporary is written but not read in constructor
tmp2 is never used, and is probably meant for the Rd0811[16,16]
Rd0811[ 0,16] = tmp1[0,16];
Rd0811[16,16] = tmp1[0,16];

Environment (please complete the following information):

Ghidra Version: 9.0

Thanks for the find.  It does look like a typo.
The change will be added to the bl half change for #39.

Fixed in 9.0.1


Add support for mlock() and munlock()

It is now possible to lock the whole memory into RAM, it won't
be swapped.
Closes #51.
I'll add a test tomorrow.

Let me know if checking VmLck on Linux goes too far.

Let me know if checking VmLck on Linux goes too far.

I like it. I think you can just use fs::read_to_string instead of from_utf8_lossy though as the file in question should always be plain ASCII?


Slow Vmap when using PRNGkeys in Pytree OO implementation for dropout

I'm attempting to make a simple Object Oriented interface for MLP using Jax.  When following the documentation for the stax dropout it says that a PRNGkey must be an argument in the apply_function.  All layers pass **kwargs to the __call__ function so that akey is available for the dropout layer.
Training over batches means also passing batches of PRNGkeys to the __call__ function of the Net.  The training cycle takes 4x longer using this implementation compared to a version without dropout (i.e. no **kwargs, no batched keys).
Is this the right way to implement Dropout?  Am I missing some subtlety about vmap, jit, or grad that is causing this slowdown.
Any advice or feedback would be helpful.
from typing import Any, List, Tuple

import jax.numpy as np
from jax import jit, nn, random

from .base import PyTreeLike
from .tensor import Tensor

class Layer(PyTreeLike, is_abstract=True):
    """Abstract Class for Layers. Enforces subclasses to implement
    __call__, tree_flatten, tree_unflatten and registered as Pytree"""

    def __call__(self, inputs: Tensor, **kwargs) -> Tensor:
        raise NotImplementedError

class ActivationLayer(Layer, is_abstract=True):
    """Abstract Class for Activation Layers."""

    def tree_flatten(self) -> Tuple[List[None], None]:
        return ([None], None)

    @classmethod
    def tree_unflatten(cls, aux: Any, data: Iterable[Any]) -> "ActivationLayer":
        return cls()

class Linear(Layer):
    """Dense Linear Layer.
    Computes output = np.dot(w, inputs) + b"""

    def __init__(self, w: Tensor, b: Tensor) -> None:
        self.w = w
        self.b = b

    @jit
    def __call__(self, inputs: Tensor, **kwargs) -> Tensor:
        """outputs = np.dot(w, inputs) + b in single instance notation."""

        return np.dot(self.w, inputs) + self.b

    def tree_flatten(self) -> Tuple[Tuple[Tensor, Tensor], None]:
        return ((self.w, self.b), None)

    @classmethod
    def tree_unflatten(cls, aux: Any, params: Tuple[Tensor, Tensor]) -> "Linear":
        return cls(*params)

class Dropout(Layer):
    """Dropout Layer. If in train mode, keeps input activations at given probability rate,
    otherwise returns inputs directly"""

    def __init__(self, keep: float = 0.8, mode: str = "train"):
        self.keep = keep
        self.mode = mode

    @jit
    def __call__(self, inputs: Tensor, **kwargs) -> Tensor:
        """If in train mode, keeps input activations at rate,
        otherwise returns directly"""

        if self.mode == "eval":
            return inputs

        key = kwargs.get("key", None)
        if key is None:
            msg = (
                "Dropout layer requires __call__ to be called with a PRNG key "
                "argument. That is, instead of `dropout(inputs)`, call "
                "it like `dropout(inputs, key)` where `key` is a "
                "jax.random.PRNGKey value."
            )
            raise ValueError(msg)
        mask = random.bernoulli(key, self.keep, inputs.shape)
        return np.where(mask, inputs / self.keep, 0)

    def tree_flatten(self) -> Tuple[List[None], Tuple[float, str]]:
        return ([None], (self.keep, self.mode))

    @classmethod
    def tree_unflatten(cls, aux: Tuple[float, str], params: List[Any]) -> "Dropout":
        return cls(*aux)

class Tanh(ActivationLayer):
    def __call__(self, inputs: Tensor, **kwargs) -> Tensor:
        return np.tanh(inputs)

class FeedForwardNet(Layer):
    """Class for feed forward nets like Multi-layer Perceptrons."""

    def __init__(self, layers: List[Layer]) -> None:
        self.layers = layers

    @jit
    def predict(self, vector_inputs: Tensor, key: Tensor) -> Tensor:
        """Predict for a single instance by iterating over all the layers"""
        for layer in self.layers:
            vector_inputs = layer(vector_inputs, key=key)
        return vector_inputs

    @jit
    def __call__(self, batched_inputs: Tensor, batched_keys: Tensor) -> Tensor:
        """Batched Predictions"""

        return vmap(self.predict)(batched_inputs, batched_keys)

    def tree_flatten(self) -> Tuple[List[Layer], None]:
        return self.layers, None

    @classmethod
    def tree_unflatten(cls, aux: Any, params: List[Layer]) -> "FeedForwardNet":

        return cls(params, aux)

If your network is very small, it's possible that generating random numbers for dropout is the bottleneck. Otherwise, can you try running with JAX_LOG_COMPILES=1 to see if JAX is compiling anything at runtime? (That's often the culprit when things are running more slowly than expected.)

Thank you for your help.  The compilation output looked right.   My net is indeed small for the purposes of learning from toy examples.  CPU training time vs GPU time time was initially fairly similar before implementing dropout.  I think the random.split in my training code must be the   bottleneck for the CPU as the GPU time did not change much when using dropout.  Closing

Thanks for your suggestion.  The compilation output looked correct, so I think the bottleneck is the random.split for generating new keys each batch. On CPU that caused training time to be quite a bit slower, but on GPU the additional time was negligible.  Closing.

Nevermind, the slowdown was my own fault: repeatedly casting list of keys to ndarray of keys.   I avoided creating the list in the first place and the slow down vanished.  Thanks again.


entrypoint - add parameters for socket bind address and port

entrypoint.py
Allow the user to set the port number also for the remote worker
Allow the user to restrict the composer api or remote worker api to
localhost
Dockerfile-ubi
Allow the user to override the entrypoint parameters
Set the environment variable default value to keep current behavior
This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

Thanks!


Enable PWA Support

Changes

Add public/service-worker.js.
Register service worker in src/index.tsx.

Notes

Web app manifest is already supported in CRA.
Cannot use typescript inside service worker.

This PR is made on top of https://github.com/dooboolab/dooboo-native-ts/pull/162

@hyochan Please review this PR. Note that I made this branch on top of your branch (not master).

@hyochan Please review this PR. Note that I made this branch on top of your branch (not master).

@hyochan Please review this PR. Note that I made this branch on top of your branch (not master).

This is the way to go! You did great

@hyochan Please review this PR. Note that I made this branch on top of your branch (not master).

This is the way to go! You did great


Questions related to pre-trained dataset ImageNet

Thank you for your outstanding work! I have some questions about the ImageNet dataset that I would like to ask you.

I find it a bit confusing that in the pre-training yml file there are only GT files about ImageNet and no LR files.
There are some images with small size (e.g. less than 256x256) inside the ImageNet dataset, how do you handle for these images?
By the way, can you give me an overview of the ImageNet dataset preparation?
Looking forward to your reply!

@GoPikachue Reading the data loader file to solve the first two questions. For dataset preparation, you only need to generate the meta info file according to your own data organization.

OK, I haven't read the relevant documents carefully yet, I will go through them first.


[Fixes] Ensure $profile is always available

Description

To resolve an issue for agents that don't have Az-Modules pre-installed (and hence no $profile is setup) we should always create the profile file if not existing. This eases later case handling.

Pipeline references

For module/pipeline changes, please create and attach the status badge of your successful run.

Pipeline

Type of Change
Please delete options that are not relevant.

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Update to documentation

Testing on my instance, please stand by.

Testing on my instance for Hosted (Ubuntu-latest) and Self-Hosted (windows) agents, please stand by.

$profile seems to work but now it gets stuck at Connect-AzAccount

Works here: https://dev.azure.com/carml/CARML/_build/results?buildId=2813&view=logs&j=b4b5998d-b947-590b-b545-9e943da9769d&t=13e2ef29-dd19-55d4-f477-199a144487c1


Initial conceal support

Adds support for the conceal attribute denoted by invis in the terminfo and usually \x1b[8m.
It is very similar to setting the foreground to match the background except it won't affect other attributes such as underline or strike-through (they will still show the foreground colour). It isn't widely supported but most modern terminals do handle it correctly.
Through testing it is supported by kitty but the maintainer said in an issue that he doesn't like it and it isn't included in the terminfo.

I happen to agree that this is probably a bad idea in most circumstances.  The most obvious use case for this is for password entry forms, where you can copy the password but cannot see it.  Given the fact that this is not obvious to the user, and that it's possibly a vector for a hidden channel, I cannot recommend doing this, ever.
What is your use case for this ability?
Note that if you just want to clear the screen visually, you can put a space character in the cell.  That's the preferred way to achieve the visual effect, and it has the benefit that copy/paste from the terminal will not leak data that the user cannot see.

What is your use case for this ability?

Just having a more complete support of what is possible. If included I would include it in a PR for lf so a file previewer could make use of it.
I can't think of a circumstance where it would be useful so I wouldn't mind not having support.


mount() fails to render the whole tree on ReactNative

I'm trying to render an entire tree with mount(), but only the first level gets rendered. This happens on React Native using react-native-mocks. I made a small repo just to reproduce the issue: https://github.com/manuelmorales/enzyme-mount-problem/. But here is the gist of it:
import React, { View, Text, StyleSheet } from 'react-native';
import { shallow, mount } from 'enzyme';
import { expect } from 'chai';

var jsdom = require('jsdom').jsdom;
global.document = jsdom('');
global.window = document.defaultView;

const Inside = React.createClass({
  render() {
    return (
      <View>
        <Text>Some text</Text>
      </View>
    )
  }
});

const Outside = React.createClass({
  render() {
    return (
      <View>
        <Inside />
      </View>
    )
  }
});

describe('mount()', () => {
  it('it should render Inner', () => {
    const wrapper = mount(<Outside />);
    expect(wrapper.find(Text).length).to.eq(1);
  });
});

wrapper.find(Text).length is returning me zero entries, when it should find one. And wrapper.debug() returns the following:
<Outside>
  <View />
</Outside>

While I expected:
<Outside>
  <View>
    <Text>Some Text</Text>
  </View>
</Outside>

Are my expectations correct? Is this a bug?

@lelandrichardson would be the best person to address this since he created react-native-mocks, but looking at the source, the <View /> component: react-native-mock/blob/master/src/components/View.js
  render() {
    return null;
  },

It just renders null, so it wont render any children you pass to it. Thats why you're just seeing <View /> instead of <View> <Text> Some Text </Text> </View>

Right, that explains everything. It looks to me that react-native-mocks was not design for this. I'll have to think of a different approach. Thanks a lot @lelandrichardson.

We made a fork named react-native-mock-render that will allow fully rendering native components with mount(). We wrote about it at https://blog.joinroot.com/mounting-react-native-components-with-enzyme-and-jsdom/

We made a fork named react-native-mock-render that will allow fully rendering native components with mount(). We wrote about it at https://blog.joinroot.com/mounting-react-native-components-with-enzyme-and-jsdom/

just what I was looking for 👍


FIX: Error in forward of 4bit linear lora layer

This was introduced during the refactoring of the forward function. It should now be fixed and be equivalent to the forward function before the refactoring:
https://github.com/huggingface/peft/blob/4df9c5a243194b03e703c1dd526d64163f9b4fd2/src/peft/tuners/lora.py#L1207-L1231
Bug reported by @jiqing-feng

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Global CLI config validation

Proposed changes
This PR adds schema validation for global CLI config file
Fixes
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to agents-aea?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the develop branch (left side). Also you should start your branch off our develop.
[x] Lint and unit tests pass locally with my changes and CI passes too
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have checked that code coverage does not decrease.
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

Codecov Report

Merging #255 (85b1a6f) into main (387c540) will decrease coverage by 0.20%.
The diff coverage is 100.00%.

:exclamation: Current head 85b1a6f differs from pull request most recent head a2e430e. Consider uploading reports for the commit a2e430e to get more accurate results

@@            Coverage Diff             @@
##             main     #255      +/-   ##
==========================================
- Coverage   94.53%   94.32%   -0.21%
==========================================
  Files         312      312
  Lines       25158    25167       +9
==========================================
- Hits        23783    23740      -43
- Misses       1375     1427      +52

Flag
Coverage Δ

unittests
94.32% <100.00%> (-0.21%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

aea/cli/utils/constants.py
100.00% <ø> (ø)

aea/cli/utils/config.py
93.04% <100.00%> (-2.24%)
:arrow_down:

aea/cli/init.py
47.36% <0.00%> (-46.06%)
:arrow_down:

aea/cli/fetch.py
68.46% <0.00%> (-4.51%)
:arrow_down:

aea/cli/utils/package_utils.py
86.28% <0.00%> (-2.35%)
:arrow_down:

aea/cli/registry/utils.py
72.26% <0.00%> (-1.46%)
:arrow_down:

aea/cli/utils/click_utils.py
96.00% <0.00%> (-0.80%)
:arrow_down:

aea/cli/add.py
80.00% <0.00%> (+0.90%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Added "weight" field to control response. Added "percentage" to both …

…secure scores and control's score objects. Refer control score to it's correct type
Added "weight" field to control response. Added "percentage" to both secure scores and control's score objects. Refer control score to it's correct type
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of “no breaking changes
[X] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run automation - sdk

@jianyexi ,
Please remove the label "CI-BreakingChange-Python" since the new commit fixed it.
I'd appreciate a quick PR since this one is about adding 2 fields and updated example files


Callback not called on successful writes

The function write(buffer, callback) doesn't not call the callback when it succeeds, only when there is an error.
Given the asynchronous nature of node, shouldn't it call the callback with an undefined error, when it succeeds?
Thanks,
Franklin

It also appears to call it multiple times, which is very weird.

Try this
https://github.com/voodootikigod/node-serialport/compare/master...vird:patch-1

What platforms and version?  I tested and I got a single callback on successful write.
osx yosemite (iojs-v2.3.4), serialport 1.7.4 and 2.0.0
Raspberry pi (v0.10.40) serialport 1.7.4 and 2.0.


Follow-on to removal of jcr.Session from the kernel-api

Addresses: https://jira.duraspace.org/browse/FCREPO-1868
Depends on https://github.com/fcrepo4/fcrepo4/pull/1123

👍


added German (de) localization messages

PR Checklist
Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[x] Other - Please describe: Added German localization messages

Fixes
Issue Number: #76
What is the current behavior?
What is the new behavior?
Other information

@floookay Nice, thanks :v:


LPAL-803 Status detail page refactor and unit tests

Purpose
LPAL-803
Approach

Refactor the service-front status page controller so that the view model can be created independently of it
Add tests which create a view model (from stubbed out service-api responses + stubbed out database records), then render the "content" part of the status detail page, so we can assert about its content and test conditional sections etc.

Learning
A little bit about how to use Twig.
Checklist

[x] I have performed a self-review of my own code
[x] I have updated documentation (Confluence/GitHub wiki/tech debt doc) where relevant
[x] I have added tests to prove my work
[x] I have added mandatory tags to terraformed resources, where possible
[x] If I added a package.json or composer.json, I also made sure this is included in the script in .github/workflows/dependabot-update.yml
[ ] The product team have tested these changes

I will organise a PR party for this 2022-06-13 as it has some quite far-reaching changes.


Translate to SPANISH

All files has to be translated to SPANISH.
Check files at: https://github.com/CloudOpting/cloudopting-manager/tree/master/rest-component/src/main/webapp/i18n/es

New string to translate at publish.json.
Check "description.template".

I saw that you created a new branch to do the translation in spanish. How is it going?

Merged to the master branch.


Replaced Sec2Time with Sec2Hours for better timesheets reporting.

Current situation.
Tracked time informations is displayed in years, monthes, days, hours, minutes. This is not suitable for timesheets reporting. For example work day is 8 hours, work week often has 5 work days.
What is changed.
Added function Sec2Hours which shows tracked time in hours and minutes which is more convenient while reporting timesheets to management.

Please check the following:

Make sure you are targeting the main branch, pull requests on release branches are only allowed for backports.
Make sure you have read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md .
Describe what your pull request does and which issue you're targeting (if any).
It is recommended to enable "Allow edits by maintainers", so maintainers can help more easily.
Your input here will be included in the commit message when this PR has been merged. If you don't want some content to be included, please separate them with a line like ---.
Delete all these tips before posting.

I think this should be configurable on a Repo/Org basis. Not everyone use Gitea the same Way as you do.


Call e2e regression tests in CI

Copying old, issue, no immediate action is necessary
This is a follow-up to #854.

[ ]     Call the new make fill-cache-for-e2e-regression target to generate a snapshot of some (1000?) blocks for emerald and consensus (and sapphire?)
[ ]     Add a CI rule that will run the e2e regression tests (make test-e2e-regression ; make it not block if it finds diffs but it's running in non-interactive mode, i.e. not in a tty)

Closed by https://github.com/oasisprotocol/nexus/pull/410


Implement HDA_GetDeviceInformation method

Retrieve the hardware capabilities of HD Audio bus controller. Partially inspired by ReactOS hdaudbus implementation.
Todo: test it somehow. Maybe it needs to be tested with ENABLE_HDA set to 1.

Guess it's not needed anymore, after your recent changes. Closing. :slightly_smiling_face:


Cleanup datasheet and benchmarks

@nahoc A new column is introduced to the datasheet CSV, the first column is now a name field.


You miss 'v' on release version, and it can't be used

I already wrote to the author 4 weeks ago via mail and he answered, but it seems like he doesn't has the time to update his repo.
If anybody needs a quick solution: I forked the repo, made some minor improvements and did a correct v-tag.
https://github.com/dnnspaul/twofactor


login details

When I execute FakeLogonScreen.exe, where is the password saved?

Check the README:

FakeLogonScreen.exe: Writes output to console which for example is compatible with Cobalt Strike
FakeLogonScreenToFile.exe: Writes output to console and %LOCALAPPDATA%\Microsoft\user.db


How to see if a comment is replying to a certain user and contains a certain string?

Is there a way to see if the comment is replying to a specific user (my bot) and contains a specific string?
for example, while streaming replies
if (comment.replyingTo === '/u/username123thisIsMyBot') ...
and then
if (comment.body === '1+1') {
comment.reply("1+1 = 2");
Cheers

You could check comment replies with snoowrap.getUnreadMessages AFAIK. As long as comment reply PMs are enabled

Awesome thank you, I think this is what I'm looking for. do you know if theres a way to get only the 'body' of the replies?
Assumed its something like
r.getUnreadMessages().then(console.log(listing.body))
but it just throws errors

You just get an array (through a Listing class) with PrivateMessages and Comments in it.
Try doing just r.getUnreadMessages().then(console.log) to see what is outputted

That then outputs the following
Listing [ Comment { first_message: null,
first_message_name: null,
subreddit: Subreddit { display_name: 'BleachBraveSouls' },
likes: null,
replies: Listing [],
id: 'eufoz3n',
subject: 'comment reply',
was_comment: true,
score: 1,
author: RedditUser { name: 'TTT334' },
num_comments: 41,
parent_id: 't1_eufn969',
subreddit_name_prefixed: 'r/BleachBraveSouls',
new: true,
body: ':)',
link_title: 'Choose a 6* available characters',
dest: 'username1234',
body_html:
':)\n',
name: 't1_eufoz3n',
created:<PHONE_NUMBER>,
created_utc:<PHONE_NUMBER>,
context:
'/r/BleachBraveSouls/comments/cga0e9/choose_a_6_available_characters/eufoz3n/?context=3',
distinguished: null } ]

Yes, you get an array which contains one element right now, a comment. You can get the body of it and check the RegEx on that

Yeah haha I'm just having trouble working out how to get the body from it though
Still super new to Node JS but i'm trying to use things like this with no avail
if (r.getUnreadMessages.includes(":(")) ===  true {
console.log("true");
}

NodeJS and JS is more or less the same thing, NodeJS has some functionality to work with the system though. I'd recommend looking at some JS tutorials or walkthroughs of some simple applications
You would need to do something like
r.getUnreadMessages().forEach(item => {
  if (item instanceof Comment && item.body.includes(":(") {
    console.log(true);
  }
});

Yeah I still can't get it to work :(
Thanks heaps for the help though, I'll have to read up on it a bit more when I have the time
if (item instanceof Comment && item.body.includes(":(") {
SyntaxError: Unexpected token {

Oops, forgot a closing parentheses
r.getUnreadMessages().forEach(item => {
  if (item instanceof Comment && item.body.includes(":(")) {
    console.log(true);
  }
});

Haha now it's just saying the comment isn't defined. Tried to change it to a lowercase 'c' and still the same problem
Unhandled rejection ReferenceError: comment is not defined

You need to import it from snoowrap. If you're importing the whole of snoowrap you can try snoowrap.Comment

Hm it's giving me the following error still after using this
r.getUnreadMessages().forEach(item => {
if (item instanceof snoowrap.Comment && item.body.includes(":(")) {
console.log(true);
}
});
I've got this at the top of the script and tried putting it just above the r.getUnreadMessage part too
const Snoowrap = require('snoowrap');
Unhandled rejection ReferenceError: snoowrap is not defined
at r.getUnreadMessages.forEach.item (C:\Users\HUM0014\Desktop\Redditbot\reddit.js:68:23)

I'd recommend looking up some guides or walk-throughs on JavaScript


Telemetry Refactoring and Stable ClientId

This PR aims to fix two telemetry issues:
1) Telemetry was missing some events
The telemetry was not capturing some events because the telemetry class was being initialized and subscribed to Dependency Injection services, like References package loaded, after the events were being triggered. This was necessary to capture the MetadataChanged events that is used on issue number 2.
The proposed fix:

Refactor the telemetry class into a dependency injection service, like all other services.
Create and add the ITelemetryService in all services' constructor to make sure it gets initialized before any other service. There are other ways to do this, but it would need a change in JupyterCore to force a new instance of ITelemetryService to be created during the App initialization, like calling public void Configure(IApplicationBuilder app, IWebHostEnvironment env) from Startup.cs.
Since the services depend on the ITelemetryService (for it to get instantiate) and the TelemetryService depends on the services (to subscribe to their events), it would cause a circular dependency which is not allowed.
So I created a PubSub Event Service to avoid the circular dependency. This service is very generic and could also be used for communication between services in an event-based fashion.

2) Having an unstable DeviceId impacts the count of unique users in transient environments
In environments like MyBinder/Kubernetes/Docker where a container is instantiated and disposed several times on different machines, the DeviceId is unstable and will lead to duplicated users count.
The proposed fix:

When telemetry is enabled (not removed during compilation, or not opt-ed out) we persist an anonymous (randomly generated) ClientId in the browser's cookie storage.
The Kernel.js first check if the telemetry is not opted-out, and if not, it will call a service that:

Checks if we need the user's consent to store non-essential data in the cookie (complying with GDPR regulations);
If consent is not needed or if it's granted, the service generates a random guid and stores it in the cookie storage.

I'm holding on updating the unit tests to see if you agree with my refactoring of the telemetry as a DI service.
Once you are okay with that approach, I'll update the unit tests (by instantiating the DummyTelemetryService).

Thanks for tagging me! Reviewing now, will take a little bit, but in the meantime I wanted to respond to this real quick:

Create and add the ITelemetryService in all services' constructor to make sure it gets initialized before any other service. There are other ways to do this, but it would need a change in JupyterCore to force a new instance of ITelemetryService to be created during the App initialization, like calling public void Configure(IApplicationBuilder app, IWebHostEnvironment env) from Startup.cs.

It's not a bad idea to give additional hooks to microsoft/jupyter-core. If it would be helpful to have a configuration action there as well, let's go on and add that.

Thanks. That would be great.
You do it or I do it? If it’s the former, you can just create the infra and then I adapt my code.

From: Chris Granade<EMAIL_ADDRESS>Sent: Sunday, March 8, 2020 10:50:58 AM
To: microsoft/iqsharp<EMAIL_ADDRESS>Cc: XField<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [microsoft/iqsharp] Telemetry Refactoring and Stable ClientId (#101)
Thanks for tagging me! Reviewing now, will take a little bit, but in the meantime I wanted to respond to this real quick:

Create and add the ITelemetryService in all services' constructor to make sure it gets initialized before any other service. There are other ways to do this, but it would need a change in JupyterCore to force a new instance of ITelemetryService to be created during the App initialization, like calling public void Configure(IApplicationBuilder app, IWebHostEnvironment env) from Startup.cs.

It's not a bad idea to give additional hooks to microsoft/jupyter-core. If it would be helpful to have a configuration action there as well, let's go on and add that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fiqsharp%2Fpull%2F101%3Femail_source%3Dnotifications%26email_token%3DAN3JLUK5BKIWKCQBYXDT7D3RGPSJFA5CNFSM4LDXYSC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOE4O4Q%23issuecomment-596232050&data=02|01||c0f4bd42afce466f557e08d7c38943a6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637192866616772065&sdata=JEofjyIWr9i2G0sOb6EtQEBlaIGrFCfiHIhJNKVZQsY%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAN3JLUNCIUM5XPGMTPNUIKDRGPSJFANCNFSM4LDXYSCQ&data=02|01||c0f4bd42afce466f557e08d7c38943a6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637192866616782070&sdata=TzGta2jZnXbDqjng4O5fLoq%2FBw9iRNZEhOA4akM8F8Y%3D&reserved=0.

Thanks! Now I only need to do the PR for the service part, deploy it to prod, and update the telemetry.ts with the production URL before we merge.

Thanks! Now I only need to do the PR for the service part, deploy it to prod, and update the telemetry.ts with the production URL before we merge.

May I suggest merging on to a feature branch, then, so that you can easily get beta builds from this to use with the other parts of this feature?

@cgranade, I've addressed all the previous feedback, and updated the client id API URL to production.
After you review my latest changes to instrument the origin, I think we can merge it to master.


Can a ChannelHandler trigger an early exit from a ChannelPipeline

Expected behavior
I would like to have an AuthenticationHandler as a first stage (ChannelnboundHandler) in a ChannelPipeline. If the authentication check fails I would like to return an error response and skip the evaluation of the remaining handlers in the pipeline.
I would be nice if the documentation could be amended with some example for such use cases.

As this is more of a question than anything else, I think the forum question covers it.

Added it here because last time I was asked to file issues for documentation improvements.

Sure, but the API docs do already mention this on the various protocol methods. The question is only whether we need a specific example to call this out in narrative documentation, which I don’t think we do to be honest.

I guess a higher level overview with some real world examples would be nice. But I guess we have to wait until @normanmaurer writes the Setty 2.0 book ;-)

@helje5 lol... I am almost sure I will never ever write a book again ;)

Everyone I've ever spoken to who has written a technical book has told me that, @normanmaurer 😉


Added BDD badge to README

IBM Cloud toolchain: Delivery Pipeline deployed inventory to inventory, including commit 560bba9cac70148d5ed6c9bdd5385d88db25036a


Web Client Support for Azure AD Application Proxy

Hello,
Is there a timeline as to when RD Web Client will work with Azure AD Application Proxy? Is this something that's on the road-map?
Thanks,
t

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

ID: 7242a6c0-8f40-bb91-c23e-0081a4d4a94a
Version Independent ID: 9a1213ac-baf5-c1f3-e735-33a0b818fb6f
Content: Supported configurations for Remote Desktop Services
Content Source: WindowsServerDocs/remote/remote-desktop-services/rds-supported-config.md
Product: windows-server-threshold
GitHub Login: @lizap
Microsoft Alias: elizapo

really interested in whether/how to publish this so that it functions with Azure AD SSO (MFA/conditional access), I would have thought this would be provided through AAD AP?

I'm also interested in using the web client with Azure MFA, is there a timeline for this ?

Any news on this yet please MS?

Yes, would please somone from the product group shed some light on this. One portal (myapps) to rule them all (legacy apps included) once AAD Proxy supports RDWebClient.

Very interested in this as well. Currently requiring only IE to use Azure App Proxy to rweb/gateway is not good.

Also hoping the they support all browers with Azure App Proxy and Azure AD authentication

Yes me too, when will this be a thing?

#please-close


Importing errors

Hi,
I can't resolve import errors.
Webpack 4
React
Babel 6

Added vendor

Added external & node

Maybe I need to include react-data-export ir xlsx folder to my module rules?

Solved by adding '../xlsx': 'var _XLSX' to webpack externals.

@igoriok1994 glad you solved it,


Merged changes from fix/6543 and added comments

Continuation of https://github.com/numba/numba/pull/6577 (fix for https://github.com/numba/numba/issues/6543)

@benwilliamgraham thank you for submitting this. I see only a single commit in this PR. If this is a continuation of #6577 I would have expected at least one commit from @stuartarchibald ? Did you perhaps use git commit --amend? For the code, is it simply the code from #6577 with additional source code comments?

For the code, is it simply the code from https://github.com/numba/numba/pull/6577 with additional source code comments?

Yeah, it's the original code along with the comment and the update from https://github.com/numba/numba/pull/6577#discussion_r542713967

For the code, is it simply the code from #6577 with additional source code comments?

Yeah, it's the original code along with the comment and the update from #6577 (comment)

OK; thank you! Can you redo this PR and split it into two commits please:
a) The original commit from @stuartarchibald
b) The additional commit with the changes you made
Otherwise we can not review this since the attribution of @stuartarchibald for that work/commit would be lost. Thank you!

@esc do you recall if patch 735f10d actually fixed the problem or just moved it somewhere else? I've a vague recollection of it only being a partial fix.

@esc do you recall if patch 735f10d actually fixed the problem or just moved it somewhere else? I've a vague recollection of it only being a partial fix.

This is my recollection also. I would tend to argue, this PR will also need at least my patch from:
https://github.com/numba/numba/issues/6543#issuecomment-740726668
Or a variant of that. And also, all the additional test-cases listed in #6543 to really make sure the fix is solid.

@esc do you recall if patch 735f10d actually fixed the problem or just moved it somewhere else? I've a vague recollection of it only being a partial fix.

This is my recollection also. I would tend to argue, this PR will also need at least my patch from:
#6543 (comment)

Ah good, glad we have the same recollection of this, and now it's recorded in comments it is less likely to be forgotten!

Or a variant of that. And also, all the additional test-cases listed in #6543 to really make sure the fix is solid.

I think that until the root causes are discovered and explanations offered for them, that it'd be very hard to review a patch. Without this, a "fix" could just be moving the problem elsewhere.

I think that until the root causes are discovered and explanations offered for them, that it'd be very hard to review a patch. Without this, a "fix" could just be moving the problem elsewhere.

@stuartarchibald I concur. For example, now that the tests have been added, I see that the linear probing tests hangs on linux on public CI.

I think that until the root causes are discovered and explanations offered for them, that it'd be very hard to review a patch. Without this, a "fix" could just be moving the problem elsewhere.

@stuartarchibald I concur. For example, now that the tests have been added, I see that the linear probing tests hangs on linux on public CI.
@benwilliamgraham it's probably worth considering my patch from here: https://github.com/numba/numba/issues/6543#issuecomment-740726668 which may help.

I added the patch but it seems that it causes some memory to not be freed. Also, is there a good way to attribute the patch to you in git?

I added the patch but it seems that it causes some memory to not be freed. Also, is there a good way to attribute the patch to you in git?

I think using my github handle in the commit message is fine. I think you might need to take a closer look here. IIRC this bug was quite tricky, maybe you get more lucky than we did so far.

@benwilliamgraham we will wait on you. Please do let us know if you make progress on this and @stuartarchibald and I will be happy to review! Thank you so much for looking into this.


Can I use ESP32S2 as Server and Client at the same time? (IDFGH-6692)

Hello,
my project is a camera web server, ESP32S2 is connected to an OV5640 camera sensor, here ESP32S2 works both as server and client, in server mode, one can access the server and get still image and stream video and in client mode, ESP32S2 sends data to a node server.
So my question is this possible for ESP32S2 to work in server and client mode simultaneously?

There is nothing to prevent you to run client and server at the same time. If you are talking about sending the same image to some other server and streaming it to a browser at the same time, you will need think of how you will manage the frames and also consider that the time it's needed to service both requests will be more.

Thanks for reporting, feel free to reopen.


Unable to build with pcl_ros

Describe the bug
I am not sure if this is the best place to ask, but I am running out of ideas. I am trying to include the ocs2_ros_interfaces package as well as pcl_ros, and they seem to really dislike each other. I created one node that depends on pcl_ros, and another that depends on ocs2_ros_interfaces. I can build each of them separately but when they are trying to build together, I get a lot of errors. The errors specifically relate to pcl in the code terminal, but I figured I might as well ask here as well in case anyone else has gotten pcl_ros to build with ocs2_ros_interfaces.
To Reproduce
Steps to reproduce the behavior:
Add pcl_ros to the package.xml and CMakeLists.txt, create a node that has #include <pcl/point_types.h> (or any pcl_ros header file). Try to catkin build.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Ros Noetic on Ubuntu 20.04
Additional context
Add any other context about the problem here.

Hello I fixed it! I was not adding the PCL libraries correctly...


all: implement RFC 5780 NAT Discovery

Maybe as "nat" subpackage.

Is it need stun server to help NAT discovery?

@songjiayang yes, the STUN Server need to support RFC 5780 too.
The gortcd currently does not support this.
About the general usage of NAT discovery:
If we can use ICE, the NAT discovery is not needed.
However, it can be used for diagnostics purposes.
E.g. some multiplayer games display NAT Status as "Strict" or "Open" to user a

Thanks for your explanation.

Closing in favour of separate client package.