How to put events to EventBridge

I have a task which is asked that when I produce the message to rocketmq, it can transform the message to aliyun eventbridge or aliyun function-compute. However, this failed even when I try the demo about /putEvents
2023-02-07 10:37:10.083@@@@@@@@[reactor-http-server-epoll-10]@@INFO@@accessLog[62]@@requestTraceId :  | url : http://<IP_ADDRESS>:7001/putEvents | requestParam : {} | requestMethod : POST | requestBody : "{\n    \"specversion\": \"1.0\",\n    \"type\": \"rocketmq\",\n    \"source\": \"https://github.com/cloudevents/spec/pull\",\n    \"subject\": \"123\",\n    \"id\": \"A234-1234-1234\",\n    \"time\": \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\": \"application/json\",\n    \"data\": {\n        \"body\": \"demo\"\n    },\n    \"aliyuneventbusname\": \"demo-bus\"\n}"
2023-02-07 10:37:10.093@@@@@@@@[reactor-http-server-epoll-10]@@ERROR@@accessLog[64]@@Catch unexpected exception.
java.util.NoSuchElementException: No value present
	at java.util.Optional.get(Optional.java:135)
	at org.apache.rocketmq.eventbridge.adapter.api.converter.EventConverterAdapter.getEventConverter(EventConverterAdapter.java:74)
	at org.apache.rocketmq.eventbridge.adapter.api.converter.EventConverterAdapter.toEventsRequest(EventConverterAdapter.java:61)
	at org.apache.rocketmq.eventbridge.adapter.api.controller.EventDataController.lambda$putEvents$0(EventDataController.java:62)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:1637)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onSubscribe(MonoFlatMap.java:103)
	at reactor.core.publisher.MonoCurrentContext.subscribe(MonoCurrentContext.java:33)
	at reactor.core.publisher.MonoFlatMap.subscribe(MonoFlatMap.java:60)
	at reactor.core.publisher.MonoPeekFuseable.subscribe(MonoPeekFuseable.java:74)
	at reactor.core.publisher.FluxSourceMonoFuseable.subscribe(FluxSourceMonoFuseable.java:38)
	at reactor.core.publisher.FluxMapFuseable.subscribe(FluxMapFuseable.java:63)
	at org.springframework.http.server.reactive.ChannelSendOperator.subscribe(ChannelSendOperator.java:74)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:150)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1080)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:241)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:73)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onNext(FluxPeekFuseable.java:198)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onNext(FluxPeekFuseable.java:198)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1080)
	at reactor.core.publisher.MonoIgnoreThen$ThenAcceptInner.onNext(MonoIgnoreThen.java:290)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1080)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:144)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1080)
	at reactor.core.publisher.MonoZip$ZipCoordinator.signal(MonoZip.java:241)
	at reactor.core.publisher.MonoZip$ZipInner.onNext(MonoZip.java:323)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onNext(FluxPeek.java:185)
	at reactor.core.publisher.FluxDefaultIfEmpty$DefaultIfEmptySubscriber.onNext(FluxDefaultIfEmpty.java:92)
	at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FluxSwitchIfEmpty.java:67)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:73)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:115)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:115)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:104)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1080)
	at reactor.core.publisher.MonoCollectList$MonoBufferAllSubscriber.onComplete(MonoCollectList.java:117)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:245)
	at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:130)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:245)
	at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:130)
	at reactor.ipc.netty.channel.FluxReceive.terminateReceiver(FluxReceive.java:377)
	at reactor.ipc.netty.channel.FluxReceive.drainReceiver(FluxReceive.java:202)
	at reactor.ipc.netty.channel.FluxReceive.request(FluxReceive.java:110)
	at reactor.core.publisher.FluxMap$MapSubscriber.request(FluxMap.java:149)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.request(FluxPeek.java:130)
	at reactor.core.publisher.FluxMap$MapSubscriber.request(FluxMap.java:149)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.request(FluxPeek.java:130)
	at reactor.core.publisher.MonoCollectList$MonoBufferAllSubscriber.onSubscribe(MonoCollectList.java:90)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onSubscribe(FluxPeek.java:163)
	at reactor.core.publisher.FluxMap$MapSubscriber.onSubscribe(FluxMap.java:86)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onSubscribe(FluxPeek.java:163)
	at reactor.core.publisher.FluxMap$MapSubscriber.onSubscribe(FluxMap.java:86)
	at reactor.ipc.netty.channel.FluxReceive.startReceiver(FluxReceive.java:273)
	at reactor.ipc.netty.channel.FluxReceive.subscribe(FluxReceive.java:124)
	at reactor.core.publisher.FluxMap.subscribe(FluxMap.java:62)
	at reactor.ipc.netty.ByteBufFlux.subscribe(ByteBufFlux.java:242)
	at reactor.core.publisher.FluxPeek.subscribe(FluxPeek.java:83)
	at reactor.ipc.netty.ByteBufFlux.subscribe(ByteBufFlux.java:242)
	at reactor.core.publisher.FluxMap.subscribe(FluxMap.java:62)
	at reactor.core.publisher.FluxPeek.subscribe(FluxPeek.java:83)
	at reactor.core.publisher.MonoCollectList.subscribe(MonoCollectList.java:59)
	at reactor.core.publisher.MonoFilterFuseable.subscribe(MonoFilterFuseable.java:47)
	at reactor.core.publisher.MonoMapFuseable.subscribe(MonoMapFuseable.java:59)
	at reactor.core.publisher.MonoMapFuseable.subscribe(MonoMapFuseable.java:59)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.MonoSwitchIfEmpty.subscribe(MonoSwitchIfEmpty.java:44)
	at reactor.core.publisher.MonoDefaultIfEmpty.subscribe(MonoDefaultIfEmpty.java:37)
	at reactor.core.publisher.MonoPeek.subscribe(MonoPeek.java:71)
	at reactor.core.publisher.Mono.subscribe(Mono.java:3080)
	at reactor.core.publisher.MonoZip.subscribe(MonoZip.java:128)
	at reactor.core.publisher.MonoFlatMap.subscribe(MonoFlatMap.java:60)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.drain(MonoIgnoreThen.java:148)
	at reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:56)
	at reactor.core.publisher.MonoPeekFuseable.subscribe(MonoPeekFuseable.java:74)
	at reactor.core.publisher.MonoPeekFuseable.subscribe(MonoPeekFuseable.java:74)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:150)
	at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FluxSwitchIfEmpty.java:67)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.innerNext(FluxConcatMap.java:271)
	at reactor.core.publisher.FluxConcatMap$ConcatMapInner.onNext(FluxConcatMap.java:803)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:115)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:1637)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:156)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.set(Operators.java:1451)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.onSubscribe(Operators.java:1325)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onSubscribe(FluxMapFuseable.java:90)
	at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:54)
	at reactor.core.publisher.MonoMapFuseable.subscribe(MonoMapFuseable.java:59)
	at reactor.core.publisher.Mono.subscribe(Mono.java:3080)
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.drain(FluxConcatMap.java:418)
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.onSubscribe(FluxConcatMap.java:210)
	at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:128)
	at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:61)
	at reactor.core.publisher.FluxConcatMap.subscribe(FluxConcatMap.java:121)
	at reactor.core.publisher.MonoNext.subscribe(MonoNext.java:40)
	at reactor.core.publisher.MonoSwitchIfEmpty.subscribe(MonoSwitchIfEmpty.java:44)
	at reactor.core.publisher.MonoFlatMap.subscribe(MonoFlatMap.java:60)
	at reactor.core.publisher.MonoFlatMap.subscribe(MonoFlatMap.java:60)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
	at reactor.core.publisher.MonoSubscriberContext.subscribe(MonoSubscriberContext.java:47)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.MonoOnErrorResume.subscribe(MonoOnErrorResume.java:44)
	at reactor.core.publisher.Mono.subscribe(Mono.java:3080)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.drain(MonoIgnoreThen.java:167)
	at reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:56)
	at reactor.core.publisher.MonoPeekFuseable.subscribe(MonoPeekFuseable.java:70)
	at reactor.core.publisher.MonoPeekTerminal.subscribe(MonoPeekTerminal.java:61)
	at reactor.ipc.netty.channel.ChannelOperations.applyHandler(ChannelOperations.java:380)
	at reactor.ipc.netty.http.server.HttpServerOperations.onHandlerStart(HttpServerOperations.java:397)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:309)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
	at java.lang.Thread.run(Thread.java:748)

Which RocketMQ/RocketMQ Connect edition for debugging?

its value validate illegal, show your /putEvents json please

It is the demo
{
    "specversion": "1.0",
    "type": "com.github.pull_request.opened",
    "source": "https://github.com/cloudevents/spec/pull",
    "subject": "123",
    "id": "A234-1234-1234",
    "time": "2018-04-05T17:31:00Z",
    "datacontenttype": "application/json",
    "data": {
        "body": "demo"
    },
    "aliyuneventbusname": "demo-bus"
}

make sure yours request headers Content-Type starts with content in the list {application/cloudevents-batch+json, application/json, application/cloudevents+json}

make sure yours request headers Content-Type starts with content in the list {application/cloudevents-batch+json, application/json, application/cloudevents+json}

I post the HTTP request as follows
POST /putEvents HTTP/1.1
Host: <IP_ADDRESS>:7001
Content-Type: application/cloudevents-batch+json
resourceOwnerAccountId: 123456
parentAccountId: 123456
loginAccountId: 123456
Content-Length: 343

{
    "specversion": "1.0",
    "type": "com.github.pull_request.opened",
    "source": "https://github.com/cloudevents/spec/pull",
    "subject": "123",
    "id": "A234-1234-1234",
    "time": "2018-04-05T17:31:00Z",
    "datacontenttype": "application/json",
    "data": {
        "body": "demo"
    },
    "aliyuneventbusname": "demo-bus"
}

And it returns
{
    "requestId": "aaaae2a8-6937-422e-aced-f57fb86e44ff",
    "code": "InternalError",
    "message": "InternalError"
}

and there is no output in the access.log except for the requestTraceId

you can run the EventBridge project by Idea, and debug for the errors detail


add in validation for same tag renaming

Fixes

check for same tag renaming
renaming same tag or more will not add tag to all contacts

Codecov Report

Merging #97 (dbaabee) into master (c8182a6) will decrease coverage by 0.11%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #97      +/-   ##
============================================
- Coverage     37.79%   37.68%   -0.12%
  Complexity      295      295
============================================
  Files            87       87
  Lines          1696     1701       +5
  Branches        183      185       +2
============================================
  Hits            641      641
- Misses         1011     1016       +5
  Partials         44       44

Impacted Files
Coverage Δ

...va/seedu/address/logic/commands/RenameCommand.java
0.00% <ø> (ø)

...eedu/address/logic/parser/RenameCommandParser.java
0.00% <0.00%> (ø)

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 c8182a6...dbaabee. Read the comment docs.


Added callback argument to getSession() and parseCognitoWebResponse()

Closes #114
Description of changes:
Added callback argument to getSession() and parseCognitoWebResponse() functions
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

+1, although I wonder, why do you not call this.userhandler.onSuccess if there is a callback? They aren't exclusive

@perrin4869 I only left it in there to be backward compatible to avoid a breaking change and requiring a new major version of the SDK.
IMO, the SDK should not support both ways going forward but only the callback argument passed to each function.
If this was my repository, I would have deleted the this.userhandler.onSuccess logic and made a new major version.

Hm... In order to remain backwards compatible though, even if there is a callback, I think you should call the userhandler callbacks as well

When I say backwards compatible, I mean a developer could update the version of the SKD used in their application and it will continue to work as it did. Assuming this Pull Request was accepted and it was released with a minor version bump on NPM, if you update to that version, their application would continue to work without any changes. The changes suggested will achieve this.
I personally don't see a use case where a developer would want to handle authentication logic in two different places (I am not saying there is not one). IMO it is not adding flexibility, only complexity, and would lead to developers introducing race conditions by not knowing which one would run first. Developers would also have to make a decision on which method to use, which would require documentation on why the SDK supports two methods and suggestions on which one suits different scenarios. As stated above, this does not seem to add flexibility, only complexity (for no benefit IMO, again this is just my opinion and it may be wrong).
If the owners of the SDK agree with the your statements, I will change it so that both are supported but I would strongly suggest against that. The reason for this Pull Request is because the existing API of the SDK does not fulfil the needs required. If it did, I would not suggest two ways of getting a session and/or creating a session, I would just use the existing API.

Oh this has bitten me quite a bit. Also the documention is not clear about when onSuccess and onFailure are called. I changed some code. Now it is called twice. Very frustrating.
I completely agree with that paragraph.

I personally don't see a use case where a developer would want to handle authentication logic in two different places (I am not saying there is not one). IMO it is not adding flexibility, only complexity, and would lead to developers introducing race conditions by not knowing which one would run first. Developers would also have to make a decision on which method to use, which would require documentation on why the SDK supports two methods and suggestions on which one suits different scenarios. As stated above, this does not seem to add flexibility, only complexity (for no benefit IMO, again this is just my opinion and it may be wrong).

Also the docs could use a lot of work. The lib exposes about 10 classes but mentions only one or two of them. The Main Class CognitoAuth has only public members but most of those are most likely only meant for internal use. Very hard to follow. The docs should be improved and/or private method/fields should be made or at least marked as private.


An issue with mixing Yarn and npm

I use Yarn for generating new projects (ng set -g packageManager=yarn). After generating a new project, I decided to install a package, but used npm:
npm i @ngrx/store
This installed the package, but replaced the content node_modules/@angular with an empty cli directory.
If I use yarn add @ngrx/store, the package is installed and the content of node_modules/@angular is preserved.
Expected behavior: even if I use Yarn for project generation, I should be able to use npm without these side effects.
I use Angular CLI 1.7.2

This is an issue with the interaction of two different package managers and not something the CLI has control over.  Using two different package managers in the same project (regardless of Angular-CLI's presence) will generally lead to dependency issues.

This was not just dependency issues. Dependencies were removed and the cli directory was created.


Custom scroll bar with hover effect

Thanks for assigning me the issue #77.
Please review and merge.
Thanks.

Please review my PR🙏


Offer translation to strings collected by makemessages

Description
The newly created projects could have the translation to strings by default.
Rationale
I frequently create projects supporting multiple languages, and there's always the need to translate these strings manually.
I'd happily provide the PT-BR (Brazillian Portuguese) translation if there is any interest in the proposal. I guess the user could choose which languages to include while creating a new project.

That's an interesting suggestion. I understand the problem you're describing, and appreciate the pain to translated the same strings over and over.
For context, by default, we ship with American English only.
I assume your suggection is to add more .po files under the locale folder, without configuring the additional languages, right? I don't think we should add more languages to the LANGUAGES settings by default.
In terms of usability, it would be a massive boost I think. If you need some of the languages we provide, then it's much easier to get started, and if not, it's pretty simple to remove the translation files you don't need, or they can also stay around, I don't think there is any harm in that.
While I think the default LANGUAGES settings that we provide should stay minimal, we could add all the translations commented out, to make it easier to add them.

I guess the user could choose which languages to include while creating a new project.

That would be ideal, although the user would typically give one or more (e.g. en-us and fr-fr), and it doesn't look supported by cookiecutter right now: https://github.com/cookiecutter/cookiecutter/issues/1002

Hello there!
Good to see you appreciated the idea. Just to make sure I got this:

We'll create multiple .po folders, for each supported language
All the supported languages will appear at LANGUAGES, but commented out by default
The user can uncomment the desired languages at LANGUAGES or delete some folders

I'll start working on this subject, starting from your branch at #4363.
Glad to help.


Remove ops from api urls

All API urls that contain ops have now been retired. eg. api.ops.maap-project.org
I think we already handled this in the code, however any documentation now needs updating.

Fixed by #50


Add notes on migrating crates to work with both editions

Some notes on supporting both editions while using implementation macros.
I haven't checked that the code compiles, so I would be grateful for a thorough review!

I've made these changes, and turned on CI for the last example, since it should compile in all situations :)

This is ready for review again.

Ping - I think this will be useful to rust users so we should either merge or tell me what I need to change.

I just ran into this problem when using the new some_crate::some_macro!() syntax and this PR would have saved me a fair amount of googling. @derekdreery is there anything left to do on this?

I'd merge this long time ago, but I don't have rights in this repo unfortunately.
ping @steveklabnik

woot


add stellaservice.com

Please review our Contribution Guidelines to ensure your changes abides by it.
Review your changes and complete the checklist below.

[x] Company name
[x] Company description
[x] Company location
[x] GitHub link
[-] How Elixir is used - developing a new product, primarily.
[x] Sorted alphabetically

Awesome!  Thank you @stellanetops 👍


This gem has been deprecated?

So this gem is no longer functioning? So all the code will not operate without switching out to the aws-sdk?
There are many Amazon documents which still as of September 2018 still referencing using this gem in ruby production.

@swagner2 you might want to check out https://rubygems.org/gems/mturk/versions/1.10.1 which is the official gem that I extracted the source from and made a syntax change to 3 years ago.
I'm not the maintainer of the mturk gem that is available from rubygems.org (and this is not the official source), so I can't speak for the state of the gem


Add CQM presolve

Replaces https://github.com/dwavesystems/dimod/pull/1264

Codecov Report

Merging #47 (a56a503) into main (f17f59f) will decrease coverage by 0.27%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##             main      #47      +/-   ##
==========================================
- Coverage   98.41%   98.14%   -0.28%
==========================================
  Files          15       18       +3
  Lines         506      540      +34
==========================================
+ Hits          498      530      +32
- Misses          8       10       +2

Impacted Files
Coverage Δ

dwave/preprocessing/__init__.py
80.00% <50.00%> (-20.00%)
:arrow_down:

dwave/preprocessing/presolve/__init__.py
100.00% <100.00%> (ø)

dwave/preprocessing/presolve/pypresolve.py
100.00% <100.00%> (ø)

tests/test_presolve.py
100.00% <100.00%> (ø)

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


Add more reasonable default lumerical mappings

These are pretty broadly used, and seem like reasonable defaults. Upstreaming because it's kind of weird to have to manually set these

note though- "W (tungsten) - Palik" is only an optical characterization. It's important to get EM characterization too, but I'm not sure if/where the dataset is (can't find it in default Lumerical DEVICE UI)


⚠ Bofrost.fr has degraded performance

In a4dd59f, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1529 ms

Resolved: Bofrost.fr performance has improved in 4960588 after 9 minutes.


Enable observability addons

ref: https://github.com/open-cluster-management/backlog/issues/15508
[Stable] Modifying managedcluster cr to disable observability  is to disable oba.
It("[Integration] Remove disable observability label from the managed cluster" won't be executed in canary environment.
That is why we cannot find the observability addon components in that managedcluster.
Signed-off-by: clyang82<EMAIL_ADDRESS>

/assign @songleo


Document results of time series rollup work as needed

Related:

cockroach issue to implement ts rollup: #21601
time series culling RFC

This may affect (at least?) the following docs:

FAQ re: how CRDB stores time series data

I didn't find much else that talked about time series storage requirements via this search.
Tobias says we may add a new cluster setting.  Will coordinate with @mrtracy who is implementing this.

Dup of https://github.com/cockroachdb/docs/issues/3443.


leds sequence support

Refactor the LEDs task for artnet, test output. Add support for .fseq sequence files (V2 Uncompressed only).
Add HTTP /vfs API for file GET/POST/DELETE support, and configtab FILE type for referencing these files.
WiP

[ ] fseq SKIP mode (skip frames if falling behind)
[ ] web support for config FILE type, file upload/delete/rename/download

Manual file upload for testing
curl -v <IP_ADDRESS>/vfs/leds-sequence/test.fseq -X POST --data-binary @test.fseq

CLI config support already works:
config set leds1 seqeunce_file test.fseq


Add GetMetadata API; implement for keychain+file

A new GetMetadata() API exports a new Metadata type.  The Metadata items can embed a *Item, which is permitted to be nil if no Item fields at all can be retrieved without prompting.
GetMetadata should always be safe to call without needing to authenticate and thus is suitable for use in batch workflows.
Implement GetMetadata for file and keychain backends.
Note: the keychain backend requires an updated go-keychain library, not yet vendored into this repo, and requires Go 1.10 to build.

See https://github.com/99designs/aws-vault/issues/287#issuecomment-423782191 for context.

@philpennock this is all great work, but I think we need to hold off until the Linux back-end is also working, otherwise this would break all Linux setups.

@frezbo I took that as an indication that I should take a stab at the Linux side too.
I'm limited to what I can find in documentation.  So I've unbroken compilation, by stubbing out the calls to always return an error, and included a note of how this could work, with libsecret.  I can't see how to make it work with kwallet.

@philpennock I pulled down the changes and the code does not panic and throws proper error. I think this is good to go for MVP1. Thanks.

Hey @philpennock I may have jumped the gun on this merge, I've reverted the merge on master. Can you re-open a PR on this?
In particular, I'm not sure I understand why Metadata is embedding Item

https://github.com/99designs/keyring/pull/29 is the redo which is a single squashed commit implementing both the previous two commits and also adapting to the changed field name inside keybase/go-keychain when they landed.


Find Non Gateway RouteAgent pod nodes

Due to the gateway failover refactoring, "kind" environment will have all worker nodes serve as gateway nodes.
This is done to save the resources of the environment running "kind".
Because of that, the test will not be able to find a non gateway worker and will fail.
Add a function to look for the non gateway route agent node in case a non gateway node is not found.
This change is required only for the "kind" env.
Details of the refactoring:
https://github.com/submariner-io/submariner/issues/2013
Signed-off-by: Maxim Babushkin<EMAIL_ADDRESS>

Closing as all the necessary changes will be handled by the following patches:
https://github.com/submariner-io/shipyard/pull/964
https://github.com/submariner-io/shipyard/pull/998


switchToOrthographicFrustum will cause globe render uncorrectly

Sandcastle example: https://sandcastle.cesium.com/#c=bY49a8NADIb/irjJhnKmsx1TCHQqZGjJdMvlrMZH78NIOpvk19eNWyhtBg3Pq/cRcjmxwOxxQYIdJFxgj+xL1MdbVhnlbrzPSaxPSEbVrUmboZ2NSFbz4sWNb/lAMuYz2Wn07pkKS4lV3aoHZdTqAPwMQMdyCdhvAPDk45RJoFCotG4E4xSsIDen4j5QtGOu22+z+a12g5/BD7s7b4ILlnndvJcQXv0Vjeq7Zu3/U0O2g0/nw4wU7OWrNj72L1uote6aFe+bknM4Wfpz+RM
Browser:  Chrome 104.0.5112.101
Operating System: macOS 12.5.1
Cesium Version: 1.96

update:  Only apear in Intel based Mac Computer. I found that it's correctly render at Windows or Apple silicon's Mac computer.


Guess mime_type and add to thumbnail object

Fun Stuff

Tested successfully with both a png https://test.kexp.org/filebrowser_filer/serve/22902/40/40/ and a jpeg https://test.kexp.org/filebrowser_filer/serve/22497/40/40/


Remove Microsoft.DataAnnotations (repo and package)

Currently this package only has one annotation ([Index]) and we're not even using it. We decided to just get rid of this package all together.
[Index] (currently copied from EF6) has some design issues and we'll re-design it when we get to it. We can probably also just ship it as part of EF rather than having a separate package just for this one annotation.

Clearing up for triage, repo is now private and we should work out if we want to delete it or keep it.


Create basic set of CRUD actions for LotMan in the cache

LotMan is going to be a solution for storage management in distributed high-throughput data environments like the cache. In order to modify lot information in the cache, we should expose a set of RESTful CRUD endpoints through Pelican.

In addition to setting up CRUD endpoints, LotMan itself should be further hardened against segfaults. See https://github.com/PelicanPlatform/lotman/issues/7


CUDA out of memory

I run the trainning code and get the error: CUDA out of memory
I've already check the Issues discussion in VPG by AndyZeng. However, the code instruction changed too much.
Please help.

Please provide specific hardware specifications.
In the case of using low-performance GPU, you could try to use PyTorch AMP ( Automatic Mixed Precision)  to automatically handle mixed-precision training. AMP aims to improve the training speed and memory utilization while maintaining the desired model accuracy.

@JackJrs Please provide specific hardware specifications.
In the case of using low-performance GPU, you could try to use PyTorch AMP ( Automatic Mixed Precision) to automatically handle mixed-precision training. AMP aims to improve the training speed and memory utilization while maintaining the desired model accuracy.

Hi. Sorry for my late. Here are my hardware:
CPU: Intel core i3-6100 CPU @ 3.70GHz (4 CPUs)
Graphic card: NVIDIA GeForce GTX 1660

@JackJrs Please provide specific hardware specifications.
In the case of using low-performance GPU, you could try to use PyTorch AMP ( Automatic Mixed Precision) to automatically handle mixed-precision training. AMP aims to improve the training speed and memory utilization while maintaining the desired model accuracy.
Hi. Sorry for my late. Here are my hardware:
CPU: Intel core i3-6100 CPU @ 3.70GHz (4 CPUs)
Graphic card: NVIDIA GeForce GTX 1660

@JackJrs The GTX 1660 is equipped with only 6 GB of GDDR5 memory. Maybe the current code cannot be directly run on this hardware setup.
We run the code with NVIDIA GTX 3090 which has 24 GB video memory.


[SCTP] state cookie generation

move https://github.com/webrtc-rs/sctp/issues/1 to here
looking at the state cookie generation implementation, shouldn't it include HMAC generation and other things as mentioned here?

According to the RFC:
Note: After sending out INIT ACK with the State Cookie parameter,
      "Z" MUST NOT allocate any resources or keep any states for the new
      association.  Otherwise, "Z" will be vulnerable to resource
      attacks.

And later regarding state cookie generation:
From the TCB, identify and collect the minimal subset of
       information needed to re-create the TCB, and generate a MAC using
       this subset of information and a secret key

The current impl creates all resources from start, and doesn't do this "delayed init" via the state cookie. This is probably okay since the SCTP state is bound to the underlying lifetime of the DTLS, which in turn depends on ICE. "Resource attacks" might be unlikely if the lower levels guards for it.
But it begs the question, what do we want to do with this issue?
It seems unnecessary to encode a bunch of stuff into the state cookie when we
a) not going to use it to recreate the TCB (Association) from it
b) could keep any state wanted (such as created time) in the Association directly
We could maybe enforce a timely init by having a 60 second lifetime of the cookie. That doesn't need to be stored in the cookie itself however.


Sleep no wake up

I have to say, a very good config where everything works straight away.
There's probably just a problem with the Sleep , did it work for you?
I'm already high on Sonoma but it didn't work in Ventura either.

Sleep doesn't work with this GPU; there is no known workaround that I've seen.


Check for references to core IDs that do not exist

The IPT should validate that all the core ID used in the extension(s) references a core ID that exists.
Please note, this check can currently be performed by http://tools.gbif.org/dwca-validator/

Related issue in DwC-A validator: http://dev.gbif.org/issues/browse/TOOL-7

@cgendreau I anticipate the IPT will do referential integrity checks on DwC-As by making external calls to the GBIF Data Validator API.
For large datasets, it may take hours for the data validator to finish. Therefore, instead of the user having to wait for the results, how about they can have them sent directly to their email? Of course they would have to provide an email in their API request for this to work. Thanks.

There is no plan to send a response by e-mail at the moment. But if we were to do that it is very likely that we would use the GBIF login instead.
Running the validation on large dataset won't take hours if we do not interpret all records.

Relevant issue on portal feedback.

@CecSve Thank you for the comment.
That's going to be a pretty expensive check. We can probably consider validating references for relatively small datasets

@mike-podolskiy90 it seems like it is the scope of the new data model though?
https://github.com/gbif/ipt/issues/1736#issue-1123931961

Yes, but that is frictionless data package and those checks will be performed by the frictionless library itself

Yes, but that is frictionless data package and those checks will be performed by the frictionless library itself

Would that mean that the publisher would not get any notification similar to the messages they receive when publishing currently?

No. Data package would not be generated, and validation errors would be displayed.

No. Data package would not be generated, and validation errors would be displayed.

Would the checks and validation errors only be for publishers using the frictionless packages? Or is it planned to also have such checks for regular DwC archives?

Ok. I will not make a new issue as the origin of this issue is capturing what I would suggest.
Ideally, the IPT should validate referential integrity of DwC-A's to capture mismappings and potentially stop the generation of an archive if the issues are not fixed by the publisher. Relevant issues for inclusion of referential integrity checks are:
https://github.com/gbif/portal-feedback/issues/4522
https://github.com/gbif/portal-feedback/issues/4491
https://github.com/gbif/portal-feedback/issues/3766
@ManonGros please add to this if I am missing something

Another issue related to referential integrity: https://github.com/gbif/portal-feedback/issues/5359#issuecomment-2176844133


Persistence of models

Proposed changes:

Fix training core model via command line (rasa train core)
Any functions reading model archives is able to handle the case where both or just one model is available.

closes https://github.com/RasaHQ/rasa_nlu/issues/3126
Status (please check what you already did):

[x] made PR ready for code review
[ ] added some tests for the functionality
[x] updated the documentation
[x] updated the changelog

@tmbo Does it make sense to change the scripts in rasa/nlu and rasa/core? As far as I can see it, the scripts in there can just be called directly via python rasa/nlu/train.pyetc. - not sure if this is still intended as all functionality can be accessed via the command line interface rasa (except the visualize), which calls the scripts in rasa/nlu and rasa/core.

@tmbo The documentation points currently to the old scripts, such as
python3 -m rasa.core.run -d models/dialogue -u models/nlu/current --event_broker pika_producer --endpoints endpoints.yml

However, even those commands seems to be outdated as there is no option like --event_broker anymore. I would like to update the documentation, but I guess I would struggle quite a bit. What do you think? Will this be tackled anyway with the updated documentation?

Yes, we need to rewrite these commands. The question is how much that will interfere with the documentation work @amn41 is currently doing. I'd want to avoid doing to many docs changes while he is working on that. @amn41 would it be an issue to change the commands now or should we rather create an issue and tackle it after your work is done?

please re-write now so the docs are up to date, I'll manage any conflicts on my end


Nightly/weekly build for small fixes

I have a bug that blocks me from using CouchDB 3.0.0. This bug was fixed but I can't have the fixed version... is there a way to get a nightly/weekly build?

Hi! I don't know the actual schedule but we're backporting our fixes to a 3.0.x branch that we will use for CouchDB 3.0.1 too. So, I don't know when a new release is coming, but I think that you'll be able to use CouchDB 3 very soon :)

Sounds good!


BUG: module 'TubeTK' has no attribute 'swig'

Please move all PR's to InsightSoftwareConsortium/ITKTubeTK


Enable UnusedVariable error prone check

#4188
Enable UnusedVariable

@brandboat Could you look into OrcPageSource as well to remove (or suppress) unused variable?

Sure ! It would be great if anyone could make a quick review on this PR since code change a lot everyday while unused variable is very common.

Sure ! It would be great if anyone could make a quick review on this PR since code change a lot everyday while unused variable is very common.

Good point.
@brandboat to make your and reviewer's job easier, i would suggest to split this pull request into multiple separate pull requests (not commits), so that we can merge incrementally.
for example "Fix unused variables in presto-bigquery",  "Fix unused variables in presto-cassandra",  "Fix unused variables in presto-hive", etc.
We will then enable the errorprone check at the end.
Also, we should avoid marking the unused places with @SuppressWarning. The point is rather to remove them, if possible.
By having it in smaller PRs, it will be easier to process.
Does it make sense?

@brandboat to make your and reviewer's job easier, i would suggest to split this pull request into multiple separate pull requests (not commits), so that we can merge incrementally.
for example "Fix unused variables in presto-bigquery", "Fix unused variables in presto-cassandra", "Fix unused variables in presto-hive", etc.
We will then enable the errorprone check at the end.

@findepi Thanks for your comment !
Agree, there are too many code changes in this PR.

Also, we should avoid marking the unused places with @SuppressWarning. The point is rather to remove them, if possible.
By having it in smaller PRs, it will be easier to process.

Yes, we should not leave useless variable. Adding @SuppressWarning in this PR is when refactoring out unused variable may change lots of files and make this PR hard to deal with. But if we split this PR by package or in smaller PR, we could solve all unused variables piece by piece.
I will open other PRs later.

Yes, we should not leave useless variable. Adding @SuppressWarning in this PR is when refactoring out unused variable may change lots of files and make this PR hard to deal with.

That's an important observation and thanks for taking care of reviewability of the change.
Note that proposed split "per module" is just a proposal.
in particular, if there are many changes in given module, it may still be hard to read.

Close this PR and open another new PR in #5987.


Gcode issue1199 p2

Split commits; builds on -p1, so includes that patch. Updated to current version

Internet Archive copy of discussion in original issue: https://web.archive.org/web/20151128081631/http://code.google.com/p/tesseract-ocr/issues/detail?id=1199

I think this one can be safely closed.


docs: Document GitHub flavoured code fences

Fixes #1259

Just realized this also fixes #1732

Merged as effaf6c2c97c90619f12293f8c474e2738d6d2f6 (master) and 2dc8d8ef6688584b7f8b0e3644ee681795271782 (v0.15.docs).


custom module user levels

Id like to have users add movies, but i would not like to have them delete them.
same goes for episodes, if they want to look for better version ok, but don't let them mistakenly delete the entire series.
same goes for logging, like with CP, that is not info i want to share with users
i hope i make sense.

ok i see you also made some adjustments with this tree:
https://github.com/Hellowlol/HTPC-Manager/tree/addnewuser
ill check to see i this fills my needs. if you need feedback ill get back to you

the adducer branch didn't work for me, do you have a helping hand?

There isn't much to it. But first you need to enable auth, to do that enter a username and password in the general tab. After that you add a restricted user. Then you reboot, login with restricted user. Do the stuff you want to test

iv got it all working and have the restriction i need. I jut want the modules to be more restricted. Like when adding a movie, i don't want restricted users to have the option to choose quality. Id like to set that up as a fixed variable.
Same goes for the download location where Sonarr should put it shows. I have a couple location therefor the add_show_folder drop down shows these. it would be good to restrict this to what i set as fixed variable in the settings of the module.
For now ive fixed the latter by deleting extra folders, but the quality i can't seem to find where to fix this in.
Can you point me in the direction or have another idea?
these are just a couple of custom module user levels.
Personally i think these should be set, if nessecary in the module settings.
for the rest, great work! love the manager, i got people adding there own shows now.
perhaps for later i could add personal folders, based on login. that would help with the plex distribution.

You can fix your CP problem by just using only one quality setting;)


re-post: in keypirinha naming question

hi! love the functionality of the plugin, thank you so much for putting it together.
one quick question. I'm wondering if there's a way we can chose to or opt out of the "AMG" naming scheme?
when searching for a game, I see "AMG Steam: Hades". seeing the AMG and platform ahead of the game breaks much of the continuity of keypirinha and can throw me off. while this is a nitpicky preference, is there a chance we can have this as an option in the configuration to simply opt out of "AMD [Platform]" when searching?
let me know please, thx!

1.6.0 allows you to disable both parts of the prefix individually. Let me know if there's any problems


🎏 New gl.yaml for Galician language

Thanks @jmmarino2 please update the docs to mention this in the i18n section


[DAEF-247] fix the react-polymorph url in package.json

This PR tries to fix the travis CI integration that was broken by me with another PR.

Looks good. Appveyor build fails due to devops refactoring, I'll fix that.


bug on sign in to dashboard after migration

What I'm trying to achieve
try to sign in to the dashboard after the migration
What I expected to happen
get error: extensions.manage_plugins' is not a valid PermissionEnum

I've fixed it by deleting a row from auth_permission with content-id of extension

Hey, could you tell which version/commit id of saleor you're using?
This bug are fixed in https://github.com/mirumee/saleor/commit/509eeb82f62024a51b21b0dd47063656bc82fcc3?diff=unified#diff-011d2378166da8d309679d66b437a554


chore(npm-shrinkwrap): add npm-shrinkwrap.json to sfpowerscripts-cli

As the sfpowerscripts-cli is an executable, and not a library, it should make
use of npm-shrinkwrap so that for each version of the CLI, dependencies are
static.
npm-shrinkwrap.json is published with the package, whereas package-lock.json is not published.

Codecov Report

Merging #767 (40aaa75) into develop (b578f3a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #767   +/-   ##
========================================
  Coverage    66.35%   66.35%
========================================
  Files           46       46
  Lines         1605     1605
  Branches       357      357
========================================
  Hits          1065     1065
  Misses         507      507
  Partials        33       33

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 b578f3a...40aaa75. Read the comment docs.


payment-details embedded component pops empty, disappear, and re-pops before displaying info about payment

When using the payment-details embedded component (alone, without the payments embedded component)... no matter if called from a button "View payment details" or if executed on page load... it always pops empty, disappear, and re-pops before displaying info about payment. How to fix it?

Stripe talks about this popping behaviour here, but could find a way to fix it.
https://docs.stripe.com/connect/get-started-connect-embedded-components#reacting-to-component-display
PS.: I am using the pure version import { loadConnectAndInitialize } from '@stripe/connect-js/pure';

Stripe talks about this popping behaviour here, but couldn't find a way to actually fix it.
https://docs.stripe.com/connect/get-started-connect-embedded-components#reacting-to-component-display
PS.: I am using the pure version import { loadConnectAndInitialize } from '@stripe/connect-js/pure';

Could you attach a video of this behavior?

https://github.com/user-attachments/assets/1d37bed4-a802-4149-b809-163772ec3028

Could you provide more details about your integration (e.g. which version of connect-js is used, are you using raw html or react or others), and maybe code if possible? Thanks!

It could be related to the state updated asynchronously (e.g., after an API call). In that case, the component might render before the state is populated, causing it to briefly appear empty and re-render when it is updated.

Hey everyone, I'm getting the same issue. I checked that there're no async state updates.
@dvadri have you found a solution?

Hi guys, I haven't found the solution yet. I'm using Laravel v11:
This is the html of the page from the video:

    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, height=device-height, initial-scale=1.0, maximum-scale=1.0" />
    @vite(['resources/css/app.css', 'resources/js/payment.js'])

    <button id="view" wire:ignore class="m-3 p-3 bg-red-100 rounded">View Payment Details</button>

This is the payment.js:
import { loadConnectAndInitialize } from "@stripe/connect-js/pure";
let paymentIntentId = 'pi_example123';
console.log(paymentIntentId);
let shop_id = 'exampleShop123';
console.log(shop_id);
const viewButton = document.getElementById('view');
viewButton.addEventListener('click', function() {
const fetchClientSecret = async () => {

    // Fetch the AccountSession client secret
    const response = await fetch('/account_session', {
            method: "POST",
            headers: {
                "X-CSRF-TOKEN": "{{ csrf_token() }}",
            },
            body: JSON.stringify({
                shop_id: shop_id,
            }),
        });
    if (!response.ok) {
        // Handle errors on the client side here
        const {error} = await response.json();
        console.error('An error occurred: ', error);
        return undefined;
    } else {
        const {clientSecret: clientSecret} = await response.json();
        return clientSecret;
    }
}

const stripeConnectInstance = loadConnectAndInitialize({
    // This is your test publishable API key.
    publishableKey: "pk_test_example123",
    fetchClientSecret: fetchClientSecret,
});

// Include this element in your HTML
const paymentDetails = stripeConnectInstance.create('payment-details');

paymentDetails.setPayment(paymentIntentId);
const container = document.getElementById("payment-details-container");
container.appendChild(paymentDetails);

// use setOnClose to set a callback function to close payment-details
paymentDetails.setOnClose(() => {
    paymentDetails.remove();
});

});
This is the app.js (that Laravel uses):
import './bootstrap';
import { loadConnectAndInitialize } from '@stripe/connect-js/pure';
// Ensure the loadConnectAndInitialize is accessible globally
window.loadConnectAndInitialize = loadConnectAndInitialize;
---x---
Another problem I just spotted... I also think the payment-details embedded component isn't showing all the disputes related to a single charge. I tested using the<PHONE_NUMBER>000079 (multiple dispute card from Stripe) and only one of the disputes appeared, while in the regular stripe dashboard for the conected account (when accessing from the platform account) both disputes appeared.
I also noticed the retrieve charge api won't list all the disputes under the 'dispute' parameter, but just shows one. This might explain it and be all interconnected. Can someone from Stripe check if it's a bug? Because otherwise connected accounted without dashboard access won't be able to counterdispute one of the disputes!!!

@dvadri Looking at this code - can you console log the code in your click listener and verify it is running only once? I believe the video you shown indicates that 2 separate payment details components are mounted onto the page.

@dvadri And regarding multiple disputes, we do not currently support multiple disputes management in embedded, but that shouldn't be causing your issue


Improve README

Make the README more informative and easier to use

[Current coverage][cc-pull] is 7.97%

Merging [#60][cc-pull] into [master][cc-base-branch] will increase coverage by 0.04%

@@            master       #60   diff @@
========================================
  Files           15        15
  Lines          744       740     -4
  Methods         93        93
  Messages         0         0
  Branches         0         0
========================================
  Hits            59        59
+ Misses         685       681     -4
  Partials         0         0

Powered by Codecov. Last updated by [77b92d9...ddcf3df][cc-compare]
[cc-base-branch]: https://codecov.io/gh/CorWatts/fasterscale/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/CorWatts/fasterscale/compare/77b92d9589089dbb8532545110310c6c3743e8e3...ddcf3df1409fdeddb3ba9b2cf7b482a29738f68e?src=pr
[cc-pull]: https://codecov.io/gh/CorWatts/fasterscale/pull/60?src=pr


Conflict of Licenses

Hello there,
First I would like to say thank you for creating and maintaining Behat.
I would like to point out that after due diligence in my company, it brought up a conflict of licenses where Behat itself is under the MIT license but the behat/transliterator, a dependency from behat,  is under the artistic license.
The artistic license was declared a liability for us (my company actually), therefore, a problem.
Would it be possible to make behat/transliterator an optional dependency OR change its license to MIT as well?

I'm not a lawyer, it probably depends on whether we can find a suitable alternative? If there's a package that does something similar but is maintained elsewhere it might be a good idea

The issue with this package is that it is quite a mess from a licensing PoV. It aggregates some data coming from a Perl package (which is where the Artistic license comes from) and some other helpers which were copied from doctrine 1 IIRC (or maybe other sources).
I'm not sure how to handle a license change for such a package.

A quick look on packages shows a few translit packages; I guess this is mostly used for snippet generation?
I wonder if we could move it to a suggest and have some dumber fallback transliteration behaviour


'[String]' does not have member name 'indexOf'

Can you fix this?

Hello, A library is adjusted to Swift 2 but I created a branch for swift 1.2
If you use pods, use
pod 'Google-Material-Design-Icons-Swift', :git => 'https://github.com/Vaberer/Google-Material-Design-Icons-Swift.git', :branch => 'swift1.2'


setup repo

[x]  Add a setup.py
[x]  Update metadata
[x]  Ensure the structure of the repo supports packaging

I think this is fine for now. The repo that has to be properly packaged is TEStribute. We do not need to publish the mock services outside of GitHub.


Android 4.0.4+ fixes for Let's Encrypt

Since Sept 30 2021 most of old devices have a lot of problems with Let's Encrypt certificates (and even with getpocket which have certs from Amazon but it is other story).
As one of workarounds some sites recommend to do something like
sudo certbot certonly --manual --preferred-chain "ISRG Root X1"

But looks like acme-companion doesn't use certbot.
How can I do same tweak?

I found solution for my docker-compose.yml
  environment:
    - acme_preferred_chain="ISRG Root X1"

Now my cert tree looks like
ISRG Root X1
-- R3
---- my site

Same as sites which works fine. But my site not work with my device(


Add name property for basename sans extension.

Adds a name property to the file metadata that does not include the extension. This is helpful when working with the metalsmith-permalinks plugin to build static websites.
A common file path for a blog post on a static website is something like /blog/blog-post-title/index.html. You can access this new name property in the template of your blog post loop to link to the blog post if you are only displaying a summary of the blog post in your loop:
{{#each collections.posts}}

{{{this.title}}}

{{this.summary}}

{{/each}}

Thanks for reviewing!

great job :+1: please see inline comments, and make appropriate changes so I can merge :)

@ahmadnassri updated per your comments. thanks for the feedback.
while looking at the node docs i noticed that in v0.12.0 a path.parse method was added which does everything, but would require upping the node engine of this package from >=0.10 to >=0.12. not sure how you feel about that change.
example:
files[file].path = path.parse(file) //returns root, dir, base, ext, and name

this seems cleaner and would scope all of the properties under the path property (which i like). it would require a non-backwards compatible version change though.
if you don't like that idea, just merge this pull request. if you like that idea i can close this pull request and send you a different pull request.

@kylerush why not both? :) I like the setup of path.parse better, but I also want backward comptability, so i'll add that as well.

released in v2.0.0 using path.parse and changing the base object to files[file].path as per your suggestion :+1:

@ahmadnassri thank you!


GetAppServiceIdentityAsync() throws exception after last update

The authentication has been broken after the last azure mobile app update (1.1.2). I cannot get user claims from the ClaimsPrincipal or from GetAppServiceIdentityAsync() method with the setting property runtimeVersion: "1.0.0" or removing it. In both cases the ClaimsPrincipal returns only basic claims, and not the expected claims for AAD authentication:
basic claims when failing.txt
expected claims when working fine.txt
The GetAppServiceIdentityAsync() method, which is supposed to be the prefered way to get the user claims, throws different exceptions depending on the runtimeVersion configuration. When I remove it or set it to "1.0.0" it throws a HttpRequestException:
exception.txt
When I set runtimeVersion to "1.0.3" it throws an InvalidOperationException:
exception2.txt
But with runtimeVersion "1.0.3" at least I can get the claims from the ClaimsPrincipal object.
I've tried also with runtimeVersion "1.1.2" but I get the same behavior as with runtimeVersion "1.0.0".
Summary table

runtimeVersion
ClaimsPrincipal
GetAppServiceIdentityAsync()

not present
basic   claims
HttpRequestException

1.0.0
basic   claims
HttpRequestException

1.0.3
expected   claims
InvalidOperationException

1.0.7
expected   claims
InvalidOperationException

1.1.2
basic   claims
HttpRequestException

So was able to reproduce the HttpRequestException found in version 1.1.2, and this is likely not a regression. It is just the InvalidOperationException present in 1.0.3 and 1.0.7 was occuring in the code before the HttpRequestException is now being hit, so now that the InvalidOperationException is not being hit, we are seeing the HttpRequestException.
Starting early last year, our product started enforcing inbound requests to use TLS 1.2 unless various conditions are met. It turns out that earlier versions of .NET (I believe 4.6.1 and earlier?) default outbound requests to TLS 1.0. Since GetAppServiceIdentity() calls the site's own /.auth/me?provider={provider} endpoint to get the user claims, the request throws an HttpRequestException, as the site refuses to acknowledge a request using TLS 1.0.
Essentially, to make this behavior work, your app needs to start using TLS 1.2. I achieved this by adding the below line to my Startup.cs file, though I believe you can add it almost anywhere in the pipeline.
System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;.
This made the HttpRequestException go away for me, and hopefully does for you as well.

@ConnorMcMahon the TLS 1.2 tweak has solved the issue. I've removed the runtimeVersion setting from our authentication config as I understand it is the best option.


Grok-1.5V code release

Hi, when are you planning to release the source code of Grok-1.5V?
Thanks

Does it matter? The amount of GPU power required to test the code for Grok is enormous. Even if the code is released, (just like Grok-1), there is no way you can test it on your local PC. I believe you need a subscription on X to test it.

it does matter, so i can learn how vision and language are put into communication

I’ve encountered some challenges while working with Grok. After downloading the weights (approximately 300GB) and setting it up in my IDE, my PC froze as soon as I ran the run.py script. Upon investigating the code, it appears that this LLM requires a platform with at least 8 GPUs (Linux/Unix). Given these requirements, it seems impractical for my current setup.
However, I can see how this can be achieved with Ollama. Ollama's capability to run on local drives allows the possibility of building a GUI with various Llama models. This can provide a user-friendly frontend interface, enabling users to interact with different models and serving as an effective learning platform. This, in my opinion is fantastic.
Given these constraints, however, how would you learn about the communication/connection between the GUI and backend in Grok when it cannot be implemented on local drives due to its high GPU requirements? Can you provide more details?

I'm asking about 1.5V because I'm interested in the multimodal model:
vision + language
On Fri, 17 May 2024, 15:45 Patrick T., @.***> wrote:

I’ve encountered some challenges while working with Grok. After
downloading the weights (approximately 300GB) and setting it up in my IDE,
my PC froze as soon as I ran the run.py script. Upon investigating the
code, it appears that this LLM requires a platform with at least 8 GPUs
(Linux/Unix). Given these requirements, it seems impractical for my current
setup.
However, I can see how this can be achieved with Ollama. Ollama's
capability to run on local drives allows the possibility of building a GUI
with various Llama models. This can provide a user-friendly frontend
interface, enabling users to interact with different models and serving as
an effective learning platform. This, in my opinion is fantastic.
Given these constraints, however, how would you learn about the
communication/connection between the GUI and backend in Grok when it cannot
be implemented on local drives due to its high GPU requirements? Can you
provide more details?
—
Reply to this email directly, view it on GitHub
https://github.com/xai-org/grok-1/issues/323#issuecomment-2117645412,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEBXWKAFGHIC4GMKAYUZZITZCYCY5AVCNFSM6AAAAABGGBBZUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGY2DKNBRGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


INS-3574: not to print CLI help on insolard successful start

remove annoying help print

fixed in PR #2828


Adds functionality to determine task and shared params automatically.

Hi, many thanks for the cool libary. As I work on a PhD in object detection where the number of different losses that are summed up can be quite high (auxillary losses, denoising etc). I am very interested in trying this project out in my domain. However determining the shared and tasks parameter manually is in a practical setting quite a challenge which is why I created this PR. I plan to add additional functionality that will be relevant to my domain down the line.
This PR does the following:

Adds functionality to determine task and shared parameters from a list of tensor representing a calculation
Removes task_params and shared_params argument from the mtl_backward
Fixes inconsistency  in test_mtl_backward_various_shared_params as the test checks for grads of parameters that are unused

Just trying to understand the logic. You consider that a a node in the graph is shared if it is in the dependency graph of all nodes that the current node depend on?

Just trying to understand the logic. You consider that a a node in the graph is shared if it is in the dependency graph of all nodes that the current node depend on? I think it might be something we could provide but this probably needs to be disantengled from the mtl_backward function which is more general.

No whether a parameter is shared is not determined from the computational graph in which it is in. I look at all the other computational graphs from the provided losses and check whether the parameter is present in them too. If this is the case I classify them as being shared. The implementation is a bit weird since I essentially have to identify whether a parameter is present in another graph by compaing memory addresses of Tensors.
I am not sure whether it makes to disentangle them as the function gives you automatically the correct shared and task params for all current cases. It basically in its current form is designes to increase useability as it avoids errors due to wrong input and takes of overhead of additional logic one would need to write (In my case I need to provide up to 20 loss values and then extracting shared and task parameter becomes complicated).

Hi @raeudigerRaeffi , thanks a lot for your contribution! I think your idea is really great for most use-cases, as it simplifies the interface (even in much simpler cases than yours).
My concerns are:

whether your implementation solid enough, or whether it could break in some tricky cases / be hard to maintain. I didn't look at your code in detail, so I can't be sure of that yet.
whether your method is general enough to consider all crurent possible use-cases of mtl_backward. If not, I would agree with Pierre to make another function, for instance auto_mtl_backward or something. Again I didn't take time to think about this yet.
this will incur a breaking change. Since the library is still a beta with very few users, this is fine IMO, but we would need to explain how to make the change, in the Changelog. This is quite straightforward but we have to keep this in mind.

We will both be very busy for the next few days, so I'm sorry in advance if we delay our actual review and decision.

I would like to know more about your specific experiment. Do you expect to have many parameters that are shared across several objectives but not necessarily all? (e.g., parameters that are shared among 10 out of the 20 losses you have) I feel like it would be meaningful to also combine those with an aggregator instead of summing. For that specific goal, we could write another backward method that gives a way to do exactly that instead. I think that MTL is a slightly specific problem that we need to provide as it is an important part of practical MOO with Jacobian-based methods. However, we are very interested in other experiments, and it would be fun to see if we can achieve a non-negligible improvement in your experiment.

The experiment I want to run is to train a Transformer based Object Detector using torch jd (probably the DINO variant). To give a very simplified architectual description:
feature_extractor -> encoder -> decoder        -> bounding_box_nn                                                                           -> class_nn
Intuitively from the architecture you can see already two objectives namely bounding box prediction aswell as class prediction. Additionally further objectives like denoising etc are introduced to stabilize training. These are objectives that all share the same set of parameters and would fit the current interface. However as you also already alluded too there are additional objectives that have a different set of shared parameters. These objectives are the same as the ones above but formulated as an auxillary task to stabilize the gradients. In the case for DINO what is done is that all the previous mentioned objectives are also calculated for each decoder layer in the decoder block. For now this is not too important though as comparing two training runs(without auxillary task) with and without jd learning is probably enough to get a feel for it. Shoukd meaningful increases be observed it would then make sense to come up with an implementation that accomondates the auxillary tasks aswell. My intuition for why I think JD could be relevant here is primarly the sheer number of objectives during training.

Hi @raeudigerRaeffi , thanks a lot for your contribution! I think your idea is really great for most use-cases, as it simplifies the interface (even in much simpler cases than yours).
My concerns are:

whether your implementation solid enough, or whether it could break in some tricky cases / be hard to maintain. I didn't look at your code in detail, so I can't be sure of that yet.
whether your method is general enough to consider all crurent possible use-cases of mtl_backward. If not, I would agree with Pierre to make another function, for instance auto_mtl_backward or something. Again I didn't take time to think about this yet.
this will incur a breaking change. Since the library is still a beta with very few users, this is fine IMO, but we would need to explain how to make the change, in the Changelog. This is quite straightforward but we have to keep this in mind.

We will both be very busy for the next few days, so I'm sorry in advance if we delay our actual review and decision.

No worries ^^. With regards to your concerns:

I made it atleast work for the already provided test cases. I am however also not sure whether 100% of all cases can be covered with the current implementation (also a little bit difficult to test for this).
I would say for now it probably covers all the current usecases assuming only 1 set of shared parameters as it is just a drop in replacements for parameters that would have otherwise been specified by hand. If in the future you want to extend it for objectives that have shared parameters but not across all objectives the function would need to be adjusted. I am pretty sure however that this case can be handled by a function aswell since it literally just tree traversal.

Thanks for the recent updates!
@raeudigerRaeffi are you ok with us pushing some commits directly to your branch?

To clarify our plan, we want to revert some of the changes to mtl_backward that you made, we want to keep the arguments that this PR removes. However we want those to have default values that will be the one that you probide in this PR. We also want to add the same logic to torchjd.backward, add sone tests, improve the docstrings and add changelig entries. Once we have done that, we will make an official update to the library and move to 0.3 (Correct me if I am wrong @ValerianRey ).
Please tell us what you think about this plan @raeudigerRaeffi .

Thanks for the recent updates!
@raeudigerRaeffi are you ok with us pushing some commits directly to your branch?

Yes feel free to modify it as you like. I also looked a bit into whether the input parameter can be automatically be infered which to my knowledge is not possible from the autograd computation graph. So some creative solution would probably required here

Can we say that the shared_params are the tensors expecting grad that are in the computation graph leading to the features? Similarly, the inputs argument of torchjd.autojac.backward could be defined as the tensors expecting grad that are in the computation graph leading to the outputs.
Then, each task's parameters could be defined as the tensors expecting grad that are in the computation graph of the task's loss, minus the shared_params.
I don't think this is perfect, because technically, a parameter could be used both to compute the features and one or more of the losses, but we don't handle those cases well anyway.
Definition of "expecting grad" (cf. https://github.com/TorchJD/torchjd/blob/main/src/torchjd/autojac/_transform/accumulate.py#L48-L54):
def _expects_grad(tensor: Tensor) -> bool:
    """
    Determines whether a Tensor expects its .grad attribute to be populated.
    See https://pytorch.org/docs/stable/generated/torch.Tensor.is_leaf for more information.
    """

    return tensor.requires_grad and (tensor.is_leaf or tensor.retains_grad)

Another thing that came up in my case recently with the current interface can cases be supported where one task is fully in the computation graph of another task ? So for example I impose a loss on the layer before the output as task1 and the loss of the output as task2. task1 parameters would be just a subset of task2 and would have no individual task parameters.

Another thing that came up in my case recently with the current interface can cases be supported where one task is fully in the computation graph of another task ? So for example I impose a loss on the layer before the output as task1 and the loss of the output as task2. task1 parameters would be just a subset of task2 and would have no individual task parameters.

If I understand correctly you have auxiliary losses, right?
In that case, you could have several levels of aggregation:

Aggregation of the jacobian of [loss1, loss2] wrt the params common between task1 and task2.
Aggregation of the jacobian of all losses wrt to all params that are common between all tasks.

You could also decide to update the params common between loss1 and loss2 based on the sum of the gradient of loss1 wrt them and the gradient of loss2 wrt them (as in SGD). This is equivalent to the first option, but using the Sum() aggregator for the first aggregation.
So basically, when a parameter is used for several objectives, the question is how do you want to aggregate the information of the gradients. And if you're fine with just summing them, you're better off just using gradient descent for those parameters (for efficiency concerns).
The good news is that our engine torchjd.autojac supports basically all possible cases. It's just that we don't necessarily have the interface to make it easy to create the Transform that will do what you want.
I think that mtl_backward should remain quite simple, so in your scenario it would be probably better to just make it sum the gradients wrt the common params of loss1 and loss2, and only actually aggregate the Jacobian wrt the shared_params (which, in my mind, should be the parameters that all tasks used).
An alternative would be to consider the Jacobian wrt all parameters that have been used by at least two losses. This Jacobian could be quite sparse, because many losses dont even depend on some parameters. In that case, we would consider the shared_params to be the set of params used in the computation graph of at least two losses.
I would be very curious about what you, as a user, would prefer between those options. In any case, we need to discuss with @PierreQuinton :

What happens after the shared params and tasks params have been selected (we didn't decide yet about some of the possible edge cases)
What parameters should be automatically considered as shared params vs task params by your function.

Another thing that came up in my case recently with the current interface can cases be supported where one task is fully in the computation graph of another task ? So for example I impose a loss on the layer before the output as task1 and the loss of the output as task2. task1 parameters would be just a subset of task2 and would have no individual task parameters.

If I understand correctly you have auxiliary losses, right?
In that case, you could have several levels of aggregation:
* Aggregation of the jacobian of [loss1, loss2] wrt the params common between task1 and task2.

* Aggregation of the jacobian of all losses wrt to all params that are common between all tasks.

You could also decide to update the params common between loss1 and loss2 based on the sum of the gradient of loss1 wrt them and the gradient of loss2 wrt them (as in SGD). This is equivalent to the first option, but using the Sum() aggregator for the first aggregation.
So basically, when a parameter is used for several objectives, the question is how do you want to aggregate the information of the gradients. And if you're fine with just summing them, you're better off just using gradient descent for those parameters (for efficiency concerns).
The good news is that our engine torchjd.autojac supports basically all possible cases. It's just that we don't necessarily have the interface to make it easy to create the Transform that will do what you want.
I think that mtl_backward should remain quite simple, so in your scenario it would be probably better to just make it sum the gradients wrt the common params of loss1 and loss2, and only actually aggregate the Jacobian wrt the shared_params (which, in my mind, should be the parameters that all tasks used).
An alternative would be to consider the Jacobian wrt all parameters that have been used by at least two losses. This Jacobian could be quite sparse, because many losses dont even depend on some parameters. In that case, we would consider the shared_params to be the set of params used in the computation graph of at least two losses.
I would be very curious about what you, as a user, would prefer between those options. In any case, we need to discuss with @PierreQuinton :
* What happens after the shared params and tasks params have been selected (we didn't decide yet about some of the possible edge cases)

* What parameters should be automatically considered as shared params vs task params by your function.

Now I understand what you mean. I agree, the shared parameters are the parameters which the features depend on, then the task specific are the parameter a task depends on minus the shared parameters. I suggest that we make a function
def _get_variables(root: Tensor, exclude: set[Tensor]): set[Tensor]

Which iterate over the parameters in the same way as the current method _traverse_ag_graph does, except that it will exclude any node in exclude. In this way for a task loss, we can get its task specific parameters by doing _get_variables(task_loss, {features}), or something similar.

Hey @raeudigerRaeffi, hope you're doing good!
We recently added the default values to the inputs argument of backward, which are found through a function similar to yours: _get_leaves_of_autograd_graph.
After merging this change to this branch, I changed the logic to rather use our _get_leaves_of_autograd_graph function (in 9bac6f2), which we have heavily tested a few days ago.
The whole logic of determining which params are shared and which are task-specific is now also a lot simpler:

shared_params will default to the leaves used to compute the features.
tasks_params will default, for each task, to the leaves used to compute the corresponding loss, excluding those used to compute the features.

There is thus no need to count the usages of each leaf tensor anymore.
Do you think this is reasonable? In case someone wants to customize (for instance, consider some parameters shared by 2 of the tasks as shared and not task-specific), they still can manually provide those parameters.
I still have tests to add, for example with your use-case of having the first task's parameters be a subset of the second task's parameters.

This is ready for a final review @PierreQuinton


Cleanup unused benefits and conditions after conditional offer removal.

Fixes #1493

One minor comment on the query syntax, otherwise this looks good to me. Also just need to check that the test failure on Django 1.8/Python 3 goes away.
Thanks!


feat(cairo_native): add synchronous sierra to native compilation flow

This change is

crates/blockifier/src/state/contract_class_manager.rs line 137 at r1 (raw file):
Previously, avi-starkware wrote…
It prints an error message to stderr using a configurable logger.

Should I write log::error!() to make it clearer?

crates/blockifier/src/state/contract_class_manager.rs line 137 at r1 (raw file):
Previously, noaov1 (Noa Oved) wrote…
Oh, I see. I prefer that, but I leave it up to you.

Done.


Document how to use a value comparer to compensate for different behavior of string comparisons in client and store

Typically string comparisons performed on the store can have different behaviors to comparisons in memory, e.g. trailing blanks and casing may be ignored in the store.
In previous versions of EF this made things like fixup of string keys hard to predict: related data would be pulled from the database because the FK and PK values matched according to the server semantics but once in memory the strings didn't match and therefore fixup didn't happen. This is described in more detail in CodePlex dotnet/efcore#284.
This kind of difference appears more often when working with existing data, so how important this is depends on how much we prioritize those scenarios. If the data was stored by EF then string keys have a better chance to be an exact match.
The idea to address this is that on the client, EF Core could always use a custom string comparison algorithm that would mimic the behavior in the database. That is, one that ignores trailing blanks and casing.

@RichardD2 It's very likely this doesn't work on 3.1. Value comparers have seen significant improvements since then.

@ajcvickers Thanks. Looks like using a value converter works in 3.1 as an alternative:
public sealed class StringToUpperValueConverter : ValueConverter<string, string>
{
    private static readonly Expression<Func<string, string>> ToProvider = s => s;
    private static readonly Expression<Func<string, string>> FromProvider = s => s.ToUpperInvariant();
    public static readonly StringToUpperValueConverter Instance = new();

    private StringToUpperValueConverter() : base(ToProvider, FromProvider)
    {
    }
}


Gradle: Upgrade the detekt plugin to version 1.2.1

This now automatically provides the "detekt" extension. For details see
https://arturbosch.github.io/detekt/changelog.html#121.
Signed-off-by: Sebastian Schuberth<EMAIL_ADDRESS>

@mnonnenmacher mind merging this despite the unrelated test failures?


Tune and add breakpoints for the navbar to address overflow issues under certain conditions.

With crates with long names, and when the "Go to latest version" or "Yanked" warning badges present, the navbar doesn't overflow correctly.  This PR adds some additional breakpoints to ensure we don't experience the visual glitch of the overflow, as well as moves the "Source" link to the crate menu to buy some additional space.
To test
# add two versions of a crate with a long name
cargo run -- build crate air-interpreter-wasm 0.0.33
cargo run -- build crate air-interpreter-wasm 0.0.35

# Start the webserver
cargo run -- start-web-server --reload-templates

# From the web UI, verify that the breakpoints are correctly hit for the latest version
<browse to http://localhost:3000/air-interpreter-wasm/0.0.35/air_interpreter_wasm/index.html >
# From the web UI, verify that the breakpoints are correctly hit for an older version
<browse to http://localhost:3000/air-interpreter-wasm/0.0.33/air_interpreter_wasm/index.html >

# Now, yank both versions
psql postgresql://cratesfyi:password@localhost:15432 -c "UPDATE releases SET yanked = true FROM  crates WHERE releases.crate_id = crates.id AND crates.name = 'air-interpreter-wasm'"

# From the web UI, verify that the breakpoints are correctly hit for the latest version
<browse to http://localhost:3000/air-interpreter-wasm/0.0.35/air_interpreter_wasm/index.html >
# From the web UI, verify that the breakpoints are correctly hit for an older version
<browse to http://localhost:3000/air-interpreter-wasm/0.0.33/air_interpreter_wasm/index.html >

Fixes #1205

Except for the nits, the code looks good to me (as far as I understand it). I didn't test it locally yet though. I'll try to whenever I have some time.

@GuillaumeGomez thanks for your time! Looking forward to further review :+1:

I didn't test it locally yet though. I'll try to whenever I have some time.

I tested it, it works very well :)

Looks good to me as well. Let's maybe wait for @Nemo157 to take a look as well?

Nah, I think this is fine as is. Thanks for reviewing!


om[] with different number of columns

Consider frequencies in Pg. 6 of https://arxiv.org/pdf/2106.14310.pdf:

Let’s say we want to keep the first 2 frequencies for Omega_1 and first 5 frequencies for Omega_2. So, first row of om[] will have 2 columns and second row of om[] will have 5 columns. Is it possible to form such om[] in Juqbox? Do number of columns have to be equal for each row? If they have to be equal, how should we construct the last 3 columns of the first row? Keeping number of frequencies low is ideal not to make optimization harder than it is supposed to be.

The trick is to enter some phony frequencies for Omega_1 to make both sets of frequencies get the same number of elements. Then set zero bounds for the phony ones. Use this function to assign the bounds:
minCoeff, maxCoeff = assign_thresholds_ctrl_freq(params, D1, maxamp)
IpOpt will eliminate the degrees of freedom with bounds = 0, i.e. they will not be part of the optimization.

Ok, I will try assign_thresholds_ctrl_freq. Should I still use assign_thresholds or assign_thresholds_freq together with assign_thresholds_ctrl_freq? Or would assign_thresholds_ctrl_freq be enough?

The return values (minCoeff, maxCoeff) are passed into setup_ipopt_problem(). It is the last assignment of these arrays that matter.


Update frequently-failed-cases.md

Docs Build status updates of commit 22aebc7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/concepts/deploy-and-publish/appsource/prepare/frequently-failed-cases.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit c9b76ff:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/concepts/deploy-and-publish/appsource/prepare/frequently-failed-cases.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Statement is a same word for « Instruction » or « Declaration » ?

I work on French translation of Vue.
All was clear from guide/syntax.md but with event.md I'm not really sure to have well understand.
This is my current comprehension
In the document syntax.md at line 74, we can read

to describe this {{ var a = 1 }}
For Linguee, Statement means Declaration : http://www.linguee.fr/francais-anglais/search?source=anglais&query=statement
For Google Translate, Statement means Declaration : https://translate.google.fr/?um=1&ie=UTF-8&hl=fr&client=tw-ob#en/fr/statement
So I understant this :
Instruction is Instruction
Statement is Declaration
Expression is Expression
So, I can describe this :
var num = 20 + true,
    bool;
str = "Hello World";
delete str;
if (num === 21) {
    bool = true;
} else {
    bool = false;
    num = 0;
}

like this :
┌──────────────────────────────────────────────────┬───────────────────────────────┬───────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Instruction                                      │ Instruction                   │ Instruction       │ Instruction                                                                                │
├──────────────────────────────────────────────────┼──────────────────────────┬────┼──────────────┬────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│                                                  │                          │    │              │    │ Control Flow                                                                                │
│                                                  │                          │    │              │    ├────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────┤
│ Statement (declaration)                          │                          │    │              │    │ Block statement                                        │ Block statement                                          │
├─────┬───────────────────────────────────────┬────┤                          │    │              │    ├──────┬────────────────┬─────┬──────────────────────┬───┼────────┬───────────────────────┬─────────────────────┬───┤
│     │ Expression                            │    │ Expression               │    │ Expression   │    │      │ Expression     │     │ Instruction          │   │        │ Instruction           │ Instruction         │   │
│     ├─────┬────┬────┬────┬──────┬────┬──────┤    ├─────┬────┬───────────────┤    ├────────┬─────┤    │      ├─────┬─────┬────┤     ├─────────────────┬────┤   │        ├──────────────────┬────┼────────────────┬────┤   │
│     │     │    │    │    │      │    │      │    │     │    │               │    │        │     │    │      │     │     │    │     │ Expression      │    │   │        │ Expression       │    │ Expression     │    │   │
│     │     │    │    │    │      │    │      │    │     │    │               │    │        │     │    │      │     │     │    │     ├─────┬────┬──────┤    │   │        ├──────┬────┬──────┤    ├─────┬────┬─────┤    │   │
│     │ var │ op │ od │ op │ od   │ op │ var  │ sc │ prp │ op │ operand       │ sc │ op     │ var │ sc │      │ od  │ op  │ od │     │ var │ op │ od   │ sc │   │        │ var  │ op │ od   │ sc │ var │ op │ od  │ sc │   │
│     │     │    │    │    │      │    │      │    │     │    │               │    │        │     │    │      │     │     │    │     │     │    │      │    │   │        │      │    │      │    │     │    │     │    │   │
│ var   num   =    20   +    true   ,    bool   ;    str   =    "Hello World"   ;    delete   str   ;    if (   num   ===   21   ) {   bool  =    true   ;    }   else {   bool   =    true   ;    num   =    0     ;    } │
└─────┴─────┴────┴────┴────┴──────┴────┴──────┴────┴─────┴────┴───────────────┴────┴────────┴─────┴────┴──────┴─────┴─────┴────┴─────┴─────────────────┴────┴───┴────────┴──────────────────┴────┴────────────────┴────┴───┘

and that means
These lines are one « Expressions » and work

{{ num = 20 + true, bool }}
{{ str = "Hello World" }}
{{ delete str }}
{{ var num = 20 + true, bool }}
{{ if (num === 21) { bool = true; } else { bool = true; num = 0 ; } }}

should be

Someone for help me to really correctly understand ?

@posva may have some thoughts here.

Thanks for the ping @chrisvfritz

So I think. Maybe the correct line are

Instead of binding directly to a method name, we can also use methods in an inline JavaScript expression:
Sometimes we also need to access the original DOM event in an inline expression handler

Yes, it should be expression instead as above. @chrisvfritz WDYT?

In this case the

should be

No, it's a statement, as you said before. Declaration could be the french equivalent for it, though

Thx @posva. So a will keep my initial comprehension and we will translated that keeping this source in mind :

Instead of binding directly to a method name, we can also use methods in an inline JavaScript expression:
Sometimes we also need to access the original DOM event in an inline expression handler

I will also to be more attentive when I see a « false » usage of « statement », and also in a well referenced page (http://www.w3schools.com/js/js_statements.asp)
I'm glad to know exactly the difference with no doubts thanks to you.

Thanks for pointing it out. I submitted a PR to fix that very specific line

@Haeresis @posva I don't think that distinction between expression and statement is completely correct. See here for my explanation.

@Haeresis Hey, actually v-on accepts statements so it was correct from the beginning

So to resume: my comprehension is ok, and the explaination of @posva too. But in the specific case of v-on, a statement is ok and not only an expression. This is not the case for v-if or {{ that require an expression. It's why:
In the document syntax.md at line 74, we can read  to describe this {{ var a = 1 }} (because that return an error).
and Instead of binding directly to a method name, we can also use methods in an inline JavaScript **statement**: to describe this <button v-on:click="say('hi')">Say hi</button> (because <button v-on:click="if (true) { say('hi') }">Say hi</button> works also).
Understood. So all is ok for me. Thx a lot.


[BUG] 422 using a dict body with 0.27.0

The following endpoint was running fine with 0.26.0 and  Python 3.6.5:
@app.patch("/ps/user")
async def patch_user(user_dict: dict, add: List[str] = Query(None)) -> dict:
...
but with upgrading to 0.27.0 I got the following 422 error:
{
    "detail": [
        {
            "loc": [
                "query",
                "user_dict"
            ],
            "msg": "field required",
            "type": "value_error.missing"
        }
    ]
}

I can't find and according change in the last commits so I assume this is a bug?
Thanks,
Daniel

Thanks! Yep. You caught a bug :bug:
It should be fixed by #287 . There are also several new tests to check that this behavior doesn't change in the future.
It's available in version 0.27.2 (just released). :tada: :rocket:

wow, that was fast. It's working now with 0.27.2 👍
Thanks

Thanks for reporting back and closing the issue! :rocket: :cake:

@tiangolo, could this issue be back in version 0.61.1?
I'm trying to define an end point like the follow (tried the following and other variations) and all return 422:
(removing the param1 didn't help either)
@app.post('/op1/{param1}')
async def op1(param1: int, my_dict: Dict[Any, Any]):
pass
@app.post('/op1/{param1}')
async def op1(param1: int, my_dict: Dict[Any, Any] = Body(...)):
pass
@app.post('/op1/{param1}')
async def op1(param1: int, my_dict: Dict[Any, Any] = Body(default=dict(), embed=False)):
pass
The only workaround I found was defining my_dict as str and parsing the json myself.

I can't reproduce your issue @DannyVarod
Run as pytest <filename>:
from typing import Dict, Any

import pytest
from fastapi import FastAPI, Body
from fastapi.testclient import TestClient

app = FastAPI()

@app.post('/op1/{param1}')
async def op1(param1: int, my_dict: Dict[Any, Any]):
    return my_dict

@app.post('/op2/{param1}')
async def op2(param1: int, my_dict: Dict[Any, Any] = Body(...)):
   return my_dict

@app.post('/op3/{param1}')
async def op3(param1: int, my_dict: Dict[Any, Any] = Body(default=dict(), embed=False)):
    return my_dict

client = TestClient(app)

@pytest.mark.parametrize("endpoint", ["op1", "op2", "op3"])
def test_everything(endpoint: str):
    param1 = 1
    my_dict = {"potato": "potato"}

    res = client.post(f"/{endpoint}/{param1}", json=my_dict)
    assert res.json() == my_dict

@Kludex, how comes you used json=my_dict and not data=my_dict or json=json.dumps(my_dict)?

@DannyVarod the test client is based on Requests, the json parameter take pure Python data types and converts them to serialized JSON. The data parameter is for form data. json=json.dumps(my_dict) would pass a single string to json, then Requests would send that as a JSON string type, not as a JSON object.

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.

@tiangolo I have since figured this out. The names are misleading though,m because JSON is a form of serializing data into a string - not an object. I would expect data to be for original data and json for serialized data (into JSON), incase someone wants to use a custom serializer.

Yep, it's an old design decision by Requests 🤷😅


When I add the plugin a few minutes later , kong will be delete it auto .

Please read the CONTRIBUTING.md guidelines to learn on which channels you can
seek for help and ask general questions:
https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#where-to-seek-for-help
Summary
When I add the plugin a few minutes later , kong will be delete it auto .
Steps To Reproduce

curl -X POST http://kong-kong-admin:8001/plugins     --data "name=ip-restriction"      --data "config.whitelist=<IP_ADDRESS>/24"
{"created_at":1552880392,"config":{"whitelist":["<IP_ADDRESS>\/24"],"blacklist":null},"id":"b32797b8-ae9a-4b81-b665-113bb8200eec","service":null,"enabled":true,"run_on":"first","consumer":null,"route":null,"name":"ip-restriction"}

API LOG

<IP_ADDRESS> - - [18/Mar/2019:03:42:27 +0000] "DELETE /plugins/b32797b8-ae9a-4b81-b665-113bb8200eec HTTP/1.1" 204 0 "-" "Go-http-client/1.1"

Additional Details & Logs

Kong version ($ kong version)
1.02
Kong debug-level startup logs ($ kong start --vv)
Kong error logs (<KONG_PREFIX>/logs/error.log)
Kong configuration (the output of a GET request to Kong's Admin port - see
https://docs.konghq.com/latest/admin-api/#retrieve-node-information)
Operating system
Centos Kubernetes

Are you using the kubernetes ingress controller?
If so this is expected behaviour: you need to manage Kong via CRDs.
Note that it is a roadmap item to allow manual management in parallel. See https://github.com/Kong/kubernetes-ingress-controller/blob/5fd0735bdd9abb1841a058e369858874d5152d4d/docs/roadmap.md#kong-ingress-controller-roadmap

Tks, i will try.

Are you using the kubernetes ingress controller?
If so this is expected behaviour: you need to manage Kong via CRDs.
Note that it is a roadmap item to allow manual management in parallel. See https://github.com/Kong/kubernetes-ingress-controller/blob/5fd0735bdd9abb1841a058e369858874d5152d4d/docs/roadmap.md#kong-ingress-controller-roadmap

tks. i will try it


FixtureSpec

I see that in some test frameworks they like to create a fixture and then refer to that in their tests.
First question - is there any fundamental difference between this:
class Demo : FunSpec() {

  fixture {
    User("sam")
  }

  test("testing usernames") {
    this.username.shouldNotBeEmpty() // this refers to the fixture
  }
}

and this:
class Demo : FunSpec() {
  override fun isolationMode() = InstancePerTest
  val user = User("sam")
  init {
    test("testing usernames") {
      user.username.shouldNotBeEmpty() // this refers to the fixture
    }
  }
})

Or is it just a case of people don't know the latter exists and / or they prefer the syntax of the former ?
Secondly, is it worth adding this support into a FixtureSpec whereby the final test scope has the fixture as the receiver ?

I have no idea why a Fixture is needed if you can do the second option

In Spek, they required this (memoized) because they have a scanning step before the actual run. The value of such a construct in KotlinTest would be the fixture scope, meaning when the fixtures need to be recreated or cleared (in the case of mocks). In a sense, the IsolationMode does this, but it requires a new test class instance, whereas fixture recreation/reset might be more efficient.
That said, I always found fixture initialization inside a test class a bit messy (especially for integration tests...), I think Spek 2 allows declaring them outside and using them in the test class...
A good DI framework could also do this, but if well adapted for testing scope (test class/branch/leaf), there might be what to add in this.
Also, having access to declared mocks and not just the test subject is important, since some test setup depends on mock settings.

So it sounds like fixtures exist because other frameworks don't do the clever trickery that kotlintest does with it's isolation modes.

Partially right @sksamuel, since if there's too much fixture code in the test it could quickly get very messy, so having some kind of fixture support that could be plugged in to the different test levels, might be useful. Maybe an extension of listener that can return an object graph that's used in the test? (Using by and delegates according to prop names might be a plus...)
I didn't think it through completely though... there might be much to build on this idea if you like it.

It would be fairly straightforward to add a FixtureSpec that hides the isolation mode and provides an object graph used by the test. It would just delegate to isolation mode behind the scenes I suppose. Is that what you mean?