Not working

>>> a = Autocards()
Loading backend, this can take some time...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\USER\autocards\autocards.py", line 79, in __init__
    self.qg = qg_pipeline('question-generation',
  File "C:\Users\USER\autocards\pipelines.py", line 360, in qg_pipeline
    tokenizer = AutoTokenizer.from_pretrained(tokenizer)
  File "C:\Users\USER\AppData\Roaming\Python\Python39\site-packages\transformers\models\auto\tokenization_auto.py", line 435, in from_pretrained
    return tokenizer_class_fast.from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)
  File "C:\Users\USER\AppData\Roaming\Python\Python39\site-packages\transformers\tokenization_utils_base.py", line 1719, in from_pretrained
    return cls._from_pretrained(
  File "C:\Users\USER\AppData\Roaming\Python\Python39\site-packages\transformers\tokenization_utils_base.py", line 1791, in _from_pretrained
    tokenizer = cls(*init_inputs, **init_kwargs)
  File "C:\Users\USER\AppData\Roaming\Python\Python39\site-packages\transformers\models\t5\tokenization_t5_fast.py", line 128, in __init__
    super().__init__(
  File "C:\Users\USER\AppData\Roaming\Python\Python39\site-packages\transformers\tokenization_utils_fast.py", line 105, in __init__
    raise ValueError(
ValueError: Couldn't instantiate the backend tokenizer from one of:
(1) a `tokenizers` library serialization file,
(2) a slow tokenizer instance to convert or
(3) an equivalent slow tokenizer class to instantiate and convert.
You need to have sentencepiece installed to convert a slow tokenizer to a fast one.
>>> a.consume_var("a")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

Related to #35.
I think you should try with earlier versions of transformers.

unfortunately i can't install transformers v3

Please be more explicit.


issue with ceph / rados and tenants

We have a ceph cluster front-ended by a rados gateway that provides S3 access.  goofys works well enough in this scenario unless we supply credentials that have a "tenant".  In most S3 implementations, the namespace for buckets is global to the cluster, but rados gives you the option to put each S3 user into its own "tenant" to make the bucket names only be required global per-tenant.  This generally works transparently to the client, provided the client always provides an Authorization header with each request, otherwise the bucket will need to exist in the global namespace.  It's kind of either or, if your user is created with a tenant ID, then each bucket will be in this namespace.
In the detectBucketLocationByHEAD method in internal/goofys.go , this does an unauthorized request.  This breaks the ceph / radosgateway scenario I outlined above when using credentials associated with a tenant.  I have forked the code and managed to get this working locally by signing the HEAD request with v4 creds, however I have no ability to test this against EMC, Amplidata etc to make sure I haven't broken anything.  Rados supports v4 auth, so no need to fall back to v2 in this scenario, and as far as I'm aware this is the only setup that is multi-tenant capable.  I am wanting to make a PR, but I'd like a bit of guidance as to how to handle the logic around fallback, or if that is even necessary.  What I'm thinking though is to move the fallbak logic that happens in internal/goofys.go ~~ line 170, I would move that down into the detectBucketLocationByHEAD method.
Thoughts?  If I don't hear back I'll just submit a PR and we can discuss it there.

The reason why detectBucketLocationByHEAD does an anonymous HEAD is so that we know if the bucket is public-read, so signing the HEAD request would break that. I also have limited abilities to test other proprietary on-prem object stores - I added them when people emailed me credentials privately and they have since expired.
Does ceph return 403 for detectBucketLocationByHEAD? I am a little unclear on what the failure scenario is. Maybe some API walk-through / debug log will help.


 The cache is
OS-specific. See
https://github.com/mvdan/github-actions-golang#how-do-i-set-up-caching-between-builds
Signed-off-by: Antonin Bas<EMAIL_ADDRESS>

Codecov Report

Merging #2499 (006ba98) into main (b6f81ba) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2499   +/-   ##
=======================================
  Coverage   42.00%   42.00%
=======================================
  Files         148      148
  Lines       18166    18166
=======================================
  Hits         7630     7630
  Misses       9846     9846
  Partials      690      690

Flag
Coverage Δ

unit-tests
42.00% <ø> (ø)

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

Impacted Files
Coverage Δ

pkg/apiserver/handlers/endpoint/handler.go
58.82% <0.00%> (-11.77%)
:arrow_down:

pkg/apiserver/storage/ram/store.go
78.94% <0.00%> (+1.50%)
:arrow_up:

Test
Before
After
Change

Unit test (ubuntu-latest)
5m22s
5m35s
+4%

Unit test (windows-2019)
9m1s
8m44s
-3%

Golangci-lint (ubuntu-latest)
10m38s
10m11s
-4%

Golangci-lint (macos-latest)
9m25s
8m36s
-9%

Build Antrea binaries (amd64)
1m59s
26s
-78%

Build Antrea binaries (arm64)
2m17s
2m12s
-4%

Build Antrea binaries (arm)
2m12s
2m25s
+10%

Build Antrea Windows binaries
1m55s
1m52s
-3%

Build antctl for macOS, Linux and Windows
5m19s
3m41s
-31%

TOTAL
2888s
2622s
-9%

I was expected a better change than 9%, but it's still a quantifiable gain. There is some variation across runs and it seems pretty common to implement that kind of caching.

@luolanzone thanks for the review, I will wait until https://github.com/antrea-io/antrea/pull/2474 is merged before I merge this, since you opened that one first

@luolanzone I have rebased and I used an env variable for the cache name

/skip-all


fix: Remove redundant dot in error message

Description
Like the following example error messages contains a redundant trailing dot.
Transaction execution failed due to issues with transaction inputs, please review the errors and try again: Gas budget: 1000 is lower than min: 1000000..

Test plan
Run ExecuteTransactionBlock with the update. Then the trailing dot will be removed

The change itself looks reasonable to me, but it looks like there are some tests (particularly, some snapshot tests) that also need to be updated -- would you mind updating those?

Sure let me work on it

It looks like there are still some more tests that need to be updated. See the output here for an example: https://github.com/MystenLabs/sui/actions/runs/8982457752/job/24675989734?pr=17362

Hi sorry for waiting. I was busy on sdk. I think I have fixed the errors!

Almost -- you have one more test that needs updating. It's a little difficult to read the CI output in this case, so I have snipped out the relevant failure:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Differences ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: crates/sui/tests/snapshots/ptb_files_tests__move_call_fun_resolution.ptb.snap
Snapshot: move_call_fun_resolution.ptb
Source: crates/sui/tests/ptb_files_tests.rs:97
────────────────────────────────────────────────────────────────────────────────
Expression: results.join("\n")
────────────────────────────────────────────────────────────────────────────────
-old snapshot
+new results
────────────┬───────────────────────────────────────────────────────────────────
   30    30 │    ╭─[4:13]
   31    31 │  3 │ --assign zero_x_zero @0x0
   32    32 │  4 │ --move-call zero_x_zero::option::is_none<u64> a
   33    33 │    ·             ─────┬─────
   34       │-   ·                  ╰── Object 0x0000000000000000000000000000000000000000000000000000000000000000 does not exist.
         34 │+   ·                  ╰── Object 0x0000000000000000000000000000000000000000000000000000000000000000 does not exist
   35    35 │  5 │ --move-call std::Option::is_none<u64> a
   36    36 │    ╰────
   37    37 │
   38    38 │   × Error when processing PTB
────────────┴───────────────────────────────────────────────────────────────────
Stopped on the first failure. Run `cargo insta test` to run all snapshots.
test test_ptb_files::ptb_files/move_call/move_call_fun_resolution.ptb ... FAILED

failures:

---- test_ptb_files::ptb_files/move_call/move_call_fun_resolution.ptb ----
test panicked: snapshot assertion for 'move_call_fun_resolution.ptb' failed in line 97

failures:
    test_ptb_files::ptb_files/move_call/move_call_fun_resolution.ptb

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 38 filtered out; finished in 26.33s

Sorry I didn't know that was the same error caused by this change. I have changed ptb_files_tests__move_call_fun_resolution.ptb.snap file

Thank you for help too @amnn !


Dead-letter on crash

Currently if the Node.js process segfaults, the connection is not closed. Once AMQP decides that it is dead, the message that caused a segfault is requeued. In many cases this will cause another worker to crash. Then another, until all are dead.
Would be better to dead-letter in this case.

It looks like our best bet is to use the redelivered tag, and then NACK (requeue=false) the message (or route it differently).
http://stackoverflow.com/questions/17654475/consuming-not-acknowledge-messages-from-rabbitmq
However, redelivery can happen because of several reason. A channel close due to being scaled down (which is expected and happens a lot with guv) will requeue just like a crash will.
So deadlettering is basically mandatory then. So maybe we should only enable this behavior for --deadletter queues.

@jonnor would be good to bump this in priority


feat: make handshake cancelable

it'll make the handshake work with graceful shutdown(see: https://github.com/cosmos/cosmos-sdk/issues/16202)
handshake could be a long running process if there are many local blocks to replay, for example we use it to do profiling.
Hope we can backport this to 0.34.x.

PR checklist

[ ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

This seems reasonable to me. Although it can't be backported (even to v0.38) as-is because in its current form it's a Go API-breaking change.
To be able to backport this, one would need to additively introduce functions like NewNodeContext and Handshaker.HandshakeContext that take the context parameter, keeping the old functions present in such a way that they call the new *Context functions with context.TODO() or context.Background().

I see, we can try that in the backport PR I think.

Thanks for this contribution. Out of curiosity, what is the behavior you expect/plan for the application once it cancels the handshake?

Thanks for this contribution. Out of curiosity, what is the behavior you expect/plan for the application once it cancels the handshake?

There are two specific use cases right now:

Close the profiler when starting the node with --cpu-profile flag.
Wait for async commit to finish.

In general, let the defer functions a chance to run when the node is interrupted by signal.

@yihuang will you be submitting the manual backports to the v0.38.x, v0.37.x and v0.34.x branches?

hey, was this able to sneak into 0.38?

.38.x, v0.37.

here we are: https://github.com/cometbft/cometbft/pull/1011


User Data after Trail?

What happens to a users data, files, etc... the trials ends?

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

ID: 28550025-fde2-9a83-a826-f7e3ccb313db
Version Independent ID: 2a304432-b10c-220f-3453-e19e7a155c67
Content: Manage the Microsoft Teams Commercial Cloud Trial offer
Content Source: Teams/iw-trial-teams.md
Service: msteams
GitHub Login: @chuckedmonson
Microsoft Alias: chucked

@officedocsbot assign @scanum

Hi @dgonzaITpro
Thank you for reaching out.
Soon after the 30 day grace period, your trial account information and data is permanently erased.
Hope this information is helpful. Kindly confirm and thank you for your patience.

@dgonzaITpro  Thank you for submitting this feedback.
From our understanding the issue has been resolved. If you feel it hasn't been resolved please re-open this issue.

@officedocsbot close


Seriously, i just want to use discord. Leave me alone.
In what world is ruining an entire theme a good idea.

as Patrick would say "take it easy its just a drawing"

It makes the theme completely unusable though, and theres no way to be rid of it without changing themes

Removing it now.


Feature extraction

Hi
thanks for sharing your code with us. Is this model good for feature extraction or it has been designed only for the translation purpose?
Thanks:)

Hi,
It depends on what you mean by "feature extraction". The last layer of an LSTM (which sums up the entire input sequence), or even the attention matrix can be used as features for auxiliary tasks.
If you are talking about low-level audio features, it turns out that the speech-to-text models implemented here take as input pre-computed features (e.g., MFCCs), so they would not be very useful for this purpose.


Moving torch.device to work in Google Colab

In https://github.com/snap-stanford/GEARS/blob/719328bd56745ab5f38c80dfca55cfd466ee356f/demo/model_tutorial.ipynb

device = 'cuda:7'

Running the notebook will fail with:
RuntimeError: CUDA error: invalid device ordinal
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

Can we adjust the demo notebook to use cuda:0? That way it will work on Google Colab, which only gives one CUDA device by default

Sure, feel free to make the changes on your end. Will add it to the next commit


Recipe Finder

Related Issue
#384
Closes: #384
Describe the changes you've made

Display UI with form to search and button to generate
Connect to API and get meals
Display meals in DOM with image and hover effect
By clicking on meal , details can be seen
Click on generate button and fetch & display a random meal

Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] New and existing unit tests pass locally with my changes.

Screenshots

#gssoc'21

@urvashi-code1255 I am facing problem in resolving conflict.Please help me
And also I'have created a PR for Recipie finder.Do check it and also check PR for  Text To Speech

@urvashi-code1255 I have created a PR for recipe finder.Plases check it and let me know!


fix: return oauth identity when user is created

What kind of change does this PR introduce?

When the oauth user is first created, the identity needs to be returned in the user object as well.

What is the current behavior?
Please link any relevant issues here.
What is the new behavior?
Feel free to include screenshots if it includes visual changes.
Additional context
Add any other context or screenshots.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 57.971%

Totals

Change from base Build<PHONE_NUMBER>7:
0.003%

Covered Lines:
9211

Relevant Lines:
15889

💛  - Coveralls


메뉴에 Blog 추가

[
{
'filePath': 'src/components/Header/index.tsx',
'lineNumber': 42,
'comment': '- Pre-condition check  \n  No pre-condition check is performed on the scrollTo function. It should be checked if it is a function before calling it.  \n- Runtime error check  \n  No runtime error checks found.  \n- Optimization  \n  No optimization points found.  \n- Security issue  \n  No security issues found.'
},
{
'filePath': 'src/pages/Home/index.tsx',
'lineNumber': 51,
'comment': '- Pre-condition check  \n  No pre-condition check is performed on the AboutContent and ContactContent objects. They should be checked if they are null or undefined before being used.  \n- Runtime error check  \n  No runtime error checks found.  \n- Optimization  \n  No optimization points found.  \n- Security issue  \n  No security issues found.'
}
]


tests: net: mld: Check null ptr dereference

If pkt allocation fails, then prepare to handle NULL pointer.
Coverity-CID: 195844
Fixes #14405
Signed-off-by: Jukka Rissanen<EMAIL_ADDRESS>

Codecov Report

Merging #14461 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #14461   +/-   ##
=======================================
  Coverage   51.98%   51.98%
=======================================
  Files         308      308
  Lines       45505    45505
  Branches    10543    10543
=======================================
  Hits        23655    23655
  Misses      17050    17050
  Partials     4800     4800

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 6368ed4...8ae1e34. Read the comment docs.

Changed to user assert

This could be merged


Date format when exporting to Excel

Hi all,
I'm having a kind of issue when exporting to Excel.
I'm exporting a report through,
"Report.SaveAs(Report::"AST-Export Trf To Excel Header", '', ReportFormat::Excel, OutStrHdrs, RecRef);"
I do it this way because I need to add to a zip file, but I think this is not the problem.
It's a very simple list type report. One of the columns is a date. I change the format of this column like this.

It's supposed not to add the regional formatting, because it doesn't have the *.
But when I open the Excel, the format of this column "is not" Date, it appears as Custom,

It's a problem because the Excel must be imported in another app, and it needs to have a true date format.
Am I doing something wrong? Is anything I could do to fix this? I've try lot of diferent formats, put the format as "="dd/mm/yyyy"", without format, etc, and always is passing the region.
Thanks in advance!

Hello,
Thank you for your feedback. Since your question is not about the Help, we suggest that you contact technical support. For more information, see Report a Problem.


UglifyJs webpack plugin outdated

the current version of UglifyJS used is 0.4.6, it comes bundled with webpack 3 and won't get updated till webpack 4. This is only a real issue when running a production build.
The error I got before updating uglifyjs-webpack-plugin was:
ERROR in static/js/vendor.e6673a0bbd4d800fda06.js from UglifyJs
Invalid assignment [./node_modules/main-server/src/services/progress.hooks.js:5,0][static/js/vendor.e6673a0bbd4d800fda06.js:93783,25]

in regards to
  return async (context) => {

which only works in a UglifyJs recent update, included in uglifyjs-webpack-plugin 1.0+
To update to 1.1.x now run... npm i -D uglifyjs-webpack-plugin
and swap
  new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      },
      sourceMap: true
    }),

for
    new UglifyJsPlugin({
      sourceMap: true
    }),

This project follows the lead of https://github.com/vuejs-templates/webpack, and once the corresponding change is made to the upstream project (at https://github.com/vuejs-templates/webpack/blob/develop/template/build/webpack.prod.conf.js#L36-L43) we can swap things over here.
(See https://github.com/vuejs-templates/pwa/pull/114/files#diff-04c6e90faac2675aa89e2176d2eec7d8R67 for a formal explanation.)

webpack 4 is coming soon, shouldn't be a problem for too long. still surprising though.


Implement pick block

Resolves #1
One design choice made here is to make vanilla (or well, StationAPI/other injectors) handle as much as possible, i.e. using return in the mixins.
Looking to get feedback on:
I considered using a lookup table for entities just as tiles have with pickBlockLookupMap. It would be of the type HashMap<Class<?>, Integer>. It would, of course, still require a special case for the Minecart (just like getItemIDFromTileID also has special cases).  Both outcomes are fine by me.

Resolves #1
One design choice made here is to make vanilla (or well, StationAPI/other injectors) handle as much as possible, i.e. using return in the mixins.
Looking to get feedback on:
I considered using a lookup table for entities just as tiles have with pickBlockLookupMap. It would be of the type HashMap<Class<?>, Integer>. It would, of course, still require a special case for the Minecart (just like getItemIDFromTileID also has special cases).  Both outcomes are fine by me.

I think a hashmap would be better because it would be easier I think for other modders to quickly add their entities to the pickBlock functionality. But, if I am wrong on that point, then I think the if statements are fairly simple since there are so few entities in vanilla minecraft to select. Let me know what you think!

Resolves #1
One design choice made here is to make vanilla (or well, StationAPI/other injectors) handle as much as possible, i.e. using return in the mixins.
Looking to get feedback on:
I considered using a lookup table for entities just as tiles have with pickBlockLookupMap. It would be of the type HashMap<Class<?>, Integer>. It would, of course, still require a special case for the Minecart (just like getItemIDFromTileID also has special cases).  Both outcomes are fine by me.

I think a hashmap would be better because it would be easier I think for other modders to quickly add their entities to the pickBlock functionality. But, if I am wrong on that point, then I think the if statements are fairly simple since there are so few entities in vanilla minecraft to select. Let me know what you think!


Add basic support for custom variables to existing actions

This is an MVP for adding custom variables to the actions for the generic blink module!
This allows users to use custom variables when using the existing actions to set the blink rate (either the flat rate or specified on/off durations). Doing so unlocks use cases that require a dynamic value when setting the blink rate.
For example, this is the use case that led me to fork this: I created a Companion config where a user is tapping a button, a bpm is calculated from the taps, the bpm is converted into on/off time duration values in custom variables, and then the generic blink module (using this branch) is used to display that bpm visually by accepting the values of those on/off duration custom variables.
https://github.com/bitfocus/companion-module-generic-blink/assets/31675433/4e72a746-7760-47a3-96c3-430aec206b37

Drop the console.logging and I’m good with it!

Ha. Sorry, it's been a minute. Done


4.1.10 Runtime  error at TabView Control:    Cannot read property 'checkActionComponent' of undefined

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request

Current behavior

ERROR TypeError: Cannot read property 'checkActionComponent' of undefined
at AmexioTabComponent.ngAfterContentInit (amexio-ng-extensions.es5.js:18957)
Expected behavior

Minimal reproduction of the problem with instructions
For bug reports please provide the STEPS TO REPRODUCE and if possible a MINIMAL DEMO of the problem via
https://plnkr.co or similar (you can use Our Amexio Plunker as a starting point: http://plnkr.co/edit/M9AeGH?p=info)
What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z

Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version: XX
- Platform:

Others:

Hi @baminmru
we are not able to reproduce above error in  version 4.1.10. Can you send me your TabView usage.


Error 403: Domain cannot use apis. - domainCannotUseApis

I am trying to setup gam on osx El Capitan. Below is a log
GAM 3.61 - http://git.io/gam
Jay Lee<EMAIL_ADDRESS>Python 2.7.10 64-bit final
google-api-python-client 1.4.1
Darwin-15.0.0-x86_64-i386-64bit x86_64
Path: /Users/Sachdev/gam

Usage: gam [OPTIONS]...

GAM. Retrieve or set Google Apps domain,
user, group and alias settings. Exhaustive list of commands
can be found at: https://github.com/jay0lee/GAM/wiki

Examples:
gam info domain
gam create user jsmith firstname John lastname Smith password secretpass
gam update user jsmith suspended on
gam.exe update group announcements add member jsmith

I am getting the following error, when I run gam info user
Error 403: Domain cannot use apis. - domainCannotUseApis

Any suggestion which setting is missing

I'm getting this too, after following all the steps in the setup guide.
Some background info that may be useful: I just upgraded my domain, earlier today, from the free Google Apps to Google Apps for Work.

Ah, I've found the solution: http://stackoverflow.com/questions/17888730/getting-domain-cannot-use-apis-when-using-google-admin-sdk-directory-api
You need to go to Security > API Reference > Enable API access.

Thanks. This fixed the issue.


[Proposal] new "laravel lts" installor command for 5.1

laravel new will install the latest version of Laravel into local environment every time.
Soon Laravel 5.2 will been released. After released, this command make 5.2 project.
Laravel 5.1 is LTS, so we need a easy way to install this version.
I suggested laravel new --lts in larachat. Taylor replied laravel lts command is acceptable.

Great. We're open to PRs then. :)

NB, we don't usually process proposal issues. Talking on slack is sufficient.


feat: command to replicate minimal information of the social user

Changes

What has changed?
Don't forget to run changeset pnpm exec changeset
If you continue making commits, it's best to convierte la PR en un draft
or create it as draft desde el principio.
Then, when it's ready, convert it into a Ready for review,
, so that the GitHub Actions don't run until the PR is ready.

docs

https://legendaryum.atlassian.net/jira/software/projects/LE/boards/1?assignee=712020%3A71750ee7-8648-475c-99c7-c39c60a8e3fc&selectedIssue=LE-2695


ListOf v0.8 (Do Not Merge)

After testing the dev branch, it seems to be breaking in multiple locations. Issues I have identified so far are:

Code not compiling and application fails to start, apparently because of this block
Login page redirection not working once JWT expires, issue was probably already there, it's been fixed here
Creating a new value in a list fails, I haven't found the root cause but payload is not properly built

I've stopped testing after identifying this last issue. I'm concerned there would be more bugs considering the high number of changes. I'm closed this merge request for now and will try to rework the changes in smaller PR.


Conflict with @cap-js-community/event-queue

Hello, in https://github.com/cap-js/telemetry/blob/main/lib/tracing/trace.js#L94 you're checking if it is an HTTP request by only checking content of cds.context?.http?.req.
What @cap-js-community/event-queue is doing, is creating a context which looks like http context, but actually is not.
Even if this context of the request is inconsistent, I think tracing library should be more resilient and should not throw if input object is incorrect.
Is it possible to add some safeguards there?
UPD: I've also opened an issue in @cap-js-community/event-queue as I'm not sure who should fix this. Maybe you could have an internal discussion on the issue?

hi @corporateuser
thanks for reporting. i think it's ok to assume that an object called http.req has headers. ;) that is what leads to a type error, right? i'll discuss with the colleagues...
best,
sebastian

@sjvans to tell you the truth, I would prefer both libraries do some actions:

telemetry does not throw because of some inconsistently written code (talking about random user code, NOT about event-queue!!!), as if we've seen it once, then someone could do this for some other reason
event-queue doesn't pretend to perform http queries, when they are not
Also maybe if event-queue is lacking of some capabilities in cds itself we could add a feature request for them directly

We ,just as a matter of temporary patching, have done:
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index fb0f4c8..98e81be 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -91,7 +91,7 @@ function _getStaticAttributes(fn) {
 }

 function _getRequestAttributes() {
-  if (!cds.context?.http?.req) return
+  if (!cds.context?.http?.req || !cds.context?.http?.req?.headers || !cds.context?.http?.req?.protocol || !cds.context?.http?.req?.url || !cds.context?.http?.req?.method) return

   if (!cds.context.http.req.__attributes) {
     const req = cds.context.http.req

hi @corporateuser
req.http is a defined API. if ctx.http.req is available, then is must be a valid instance of express' req/ node's IncomingMessage.
optional chaining is syntactic sugar and should not be used to defensively check the existence of each property.
best,
sebastian


Introduce CEP (Chaos Enhancement Proposals) for Litmus Chaos Project

Introduce CEPs (Chaos Enhancement Proposals) to share insights & obtain feedback from community on development of new features/modifications to current ones

CEP Template has been included in the repo.


Develop the content for the service level agreements

[ ] SLA for service levels suppliers will receive (e.g. x amount of time to respond to their questions, x amount of time to issue payment?)
[ ] SLA for service levels clients will receive (e.g. x amount of time for IT Strategy to review their opportunity text before posting on website?)

This is connected to other activities like: finalizing the website content and finalizing the auto response to the generic email account


Remove deprecated constraints and dynamic dim support with test fixes

The backing APIs have been deprecated for a year and were removed from PyTorch 2.6 nightlies, causing import errors.
torch.export and torch-mlir have long since provided a supported way for exporting dynamic dims.

With this, we can remove the torch restriction here: https://github.com/iree-org/iree-turbine/blob/main/pytorch-rocm-requirements.txt#L3


Impossible to rename tokens

@npmccallum, @justin-stephenson, @freeotp team: I have updated the app and I can not rename tokens...
Can you add again the feature?
Thanks in advance.

Seconded. This feature was present in the old version before the rewrite, and removing it is a big loss in usability.
To give an example: Our in-house Single Sign-On presents itself as Microsoft AD since that is where the credentials are stored. However, to login to your Microsoft account you need another token, which also presents itself as Microsoft AD. Without renaming the only way to keep them apart was to assign custom icons to each token. Sadly, this feature has also been removed in the rewrite. Much preferred the old version, although the ability to export tokens seems useful.

I have this problem too.
And I can’t remove any token.

Got the same issue with a new entry named "Keycloak".


No more crashes when using uniplemented windows.js features

Okay, proper fix got to be done there https://github.com/PrismarineJS/prismarine-windows/issues/1 though


Find metrics to compare RMC against

One possible metric: https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>5311v1

closing as no longer relevant due to https://github.com/broadinstitute/rmc_production/issues/122


feat: webworker flags

This seems to get the job done, however, due to lack of tests and all of this flags everywhere, I'm not 100% if I didn't miss anything.

@diasdavid I think this changes need to happen in bin/test, the dom/webworker flags are being checked there, if anything they probably need to be removed from there. I think either way works.

@dryajov @dignifiedquire applied your CR

Apparently, failing at WebWorker tests doesn't make the tests fail

@diasdavid Thats bad... going to take a look at it.

Apparently, failing at WebWorker tests doesn't make the tests fail

that's a bug Oo

Apparently, failing at WebWorker tests doesn't make the tests fail

being tracked in #100

@dryajov @dignifiedquire what is needed to finish this PR?


README update

Description
Updating documentation to cover oneAPI
Update variable DAALROOT -> DALROOT

apparently a-b lists do not work, probably makes sense to use unordered lists


Add initial documentation for StatefulSetSlice feature

Add documentation for StatefulSetSlice feature targeting Kubernetes alpha in 1.26

KEP-3335 Enhancement: https://github.com/kubernetes/enhancements/pull/3336
KEP-3335 Implementation: https://github.com/kubernetes/kubernetes/pull/112744

/retitle Add initial documentation for StatefulSetSlice feature

/remove-area blog
/remove-area release-eng
/remove-language de
/remove-language es
/remove-language fr
/remove-language hi
/remove-language id
/remove-language ja
/remove-language ko
/remove-language pl
/remove-language pt
/remove-language vi
/remove-language zh

Hi @pwschuurman! This PR needs a doc review by Mon Nov 28th to get this into the release. Please reach out to required SIGs to get their review. Thank you!

@soltysh @sftim @tengqm Thanks for the reviews so far. Can you take another quick look before the docs freeze? Thanks!

@sftim Thanks. Updated the formatting of the new section

@sftim @soltysh Can you take another quick look before the docs freeze? Thanks!

/lgtm
/approve


Show error page to user if IP is rate limited

https://github.com/BustByte/coronastatus/pull/483

Fixed in #483


one line fix for issue #205

This problem affected forecast of OFL catch in a model with seasons
OFL catch contained only catch from Nseas
Fix involved deleting one line that was re-initializing that quantity

Looks good to merge in, Rick, if you think so! Great it was just a one line fix.


Using dlists can result in "node.getContext() is not a function" error

This PR fixes the problem described in #4. Instead of aborting, it logs a warning and keeps on validating.

Thanks @cpfeiffer. Sorry it's taken so long to get to this.


Local state remains on previous thread after context switch

Monix Version: 3.0.0-RC2
Observed behavior:
When using Local the state is left behind on the previous thread after a context switch. For example, given a Local[Int](default = 0), you start on thread 1 and set local=42 and then shift to another thread. On thread 2 you automagically see local=42  thanks to enableLocalContextPropagation... BUT local=42 remains on thread 1, even though the task is done with that thread. It assumes the next task will clean up before starting, which IMO makes the default value somewhat useless (as the value never really means anything to you).
Expected behavior:
When context switch occurs thread 1 / local should be reverted to the default=0 value.
Reproduction steps:
object Application extends App {
  implicit val scheduler: Scheduler = Scheduler.traced
  val local = Local[Int](0)

  (0 to 1000).foreach { _ =>
    Task
      .eval {
        if (local() > 0) {
          println("Uh-oh!")
        }
        local.update(local() + 1)
      }
      .asyncBoundary // If you comment this out, all works fine... but with it in, demonstrates the context is left behind on the previous thread.
      .map { _ =>
        local.update(local() - 1)
      }
      .executeWithOptions(_.enableLocalContextPropagation)
      .runSyncUnsafe()
  }
}

@ljwagerfield I didn't realize you were using the Local directly. In this case that is the expected behavior since you are indeed jumping to an async boundary so it is ok to see that the local never gets back to 0 because you are not referencing the same var given that you are in another thread.
There are some known issues with TaskLocal restoring the local (https://github.com/monix/monix/issues/624) but this is not that case.

Ok, but out of interest: how could you implement a re-entrancy check using TaskLocal? This is something ThreadLocal was very useful for, but obviously won't work with Tasks...
object Implicits {
  private val local = Local[Int](0)
  implicit class RichConnectionIO[A](val connectionIO: ConnectionIO[A]) {
    /**
      * Calls 'transact' internally, but warns on re-entrant calls which result in nested transactions.
     **/
    def transactSafely(): Task[A] =
      if (local() > 0)
        println("WARN: nested transaction detected!")

      local.update(local() + 1)
      connectionIO.transact().doOnFinish(_ => Task.eval {
        local.update(local() - 1)
      })
  }
}


Added bodyAsBase64 element to LoggedRequest JSON in requests find output

In order to pass back a binary body such as a zip or jpeg exactly as received in the original request for verification, we need a new bodyAsBase64 element in the LoggedRequest JSON. The original string element body corrupts the stored byte array so this was needed as there was no way to retrieve it otherwise.
So calling the usual http://<host>:<port>/__admin/requests/find will return the same JSON as before but now it will also have something like this example...
"bodyAsBase64": "TXkgdGV4dAo=",
... at the same level as "body": "My text" element.
For the moment, this is only in the REST API, not the Java API. We tried the Java API after finding that the REST API didn't return binary but that has the same issue.

Oh dear. Not sure what the failure with #181.2 is caused by. The tests ran successfully locally when I did a gradle clean build.

I've tried the same Oracle JVM version used by the failing Travis CI job, being jdk1.7.0_76 and all tests pass. I'm still puzzled as to why they have failed here.

Looks like port numbers clashing. I don't think it's a result of anything you've done - since Travis builds run in Docker containers I'm guessing this is a random clash with some other process whose TCP stack is not fully isolated.
Running it again seems to have made the problem go away.

Can you elaborate what you mean by this being the REST API only and not the Java API?

The REST API was just referring to calling WireMock via JSON+HTTP so thinking about it, it's not really REST so sorry for the confusion there.
The effort to get bodyAsBase64 working was concentrated around that rather than the Java side. I'm not in a position to be able to try the Java Client right now and it's not something we need at this stage given that the JSON+HTTP approach is working nicely with this change.
I hope this is enough of a claification/elaboration for you but if you need more info then ask away.

I'm just wondering what you think is missing on the Java side. I can't see anything obvious I'd want to add, since there's no DSL component to this.

Ah OK, maybe the Java side is OK now with this change. All I can remember is that without this change there was no way to get the byte array back unmangled (due to UTF-8 conversion I think it was).
The recent addition in v1.58 and v2.0.8 (I think) of the bodyAsBase64 request element meant that we just needed to amend the code to return it in the response from __admin/requests/find and all was good. We didn't look at the Java side anymore - but if you think it'll work with this pull request then that's good. I can't try it out until Friday but a colleague of mine might try it tomorrow.

Ah, I think I see the potential problem: because the LoggedRequest constructor takes body as a String, you'll get a bad version of it back if you use the Java API remotely.

Yeah, I think it'd be a bit misleading to leave it in its current state.
I think all that would need to happen would be to modify the LoggedRequest constructor that takes body as a string to take the base64 version instead (also changing the JSON property name appropriately).
As a bonus, it might be nice to remove the byte[] based constructor and just use the base64 version everywhere.

Right - thanks for the advice. I'll leave it for my colleague to look at tomorrow or look at it myself on Friday when I'm back.
Thanks again.

Cool, appreciate you both putting the effort in!

I've done a second commit that includes the changes for the Java API as discussed. Both interfaces work and all of the tests pass. If there is anything for me to do beyond this then please let me know.


ixblue_stdbin_decoder: 0.1.1-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository ixblue_stdbin_decoder to 0.1.1-1:

upstream repository: https://github.com/ixblue/ixblue_stdbin_decoder.git
release repository: https://github.com/ixblue/ixblue_stdbin_decoder-release.git
distro file: noetic/distribution.yaml
bloom version: 0.9.7
previous version for package: null

ixblue_stdbin_decoder
* Reduce minimum required CMake version to allow build on Debian Stretch for ROS Melodic
* Contributors: Romain Reignier

holding for the upcoming Noetic sync


Sensor polling interval not working

The polling interval as set in the configuration is not reflected on the update intervals of the sensors when the server is running. The actual interval is sporadic and unnecessary high.
Configuration
sensor_modules:
  - name: dht22
    module: dht22
    type: dht11 # can be  DHT11, DHT22 or AM2302
    pin: 4

sensor_inputs:
  - name: temperature
    module: dht22
    interval: 10 #interval in seconds, that a value is read from the sensor and a update is published
    digits: 4 # number of digits to be round
    type: temperature

  - name: humidity
    module: dht22
    interval: 10 #interval in seconds, that a value is read from the sensor and a update is published
    digits: 4 # number of digits to be round
    type: humidity

Logs
2019-06-14 14:46:02,422 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 42.0
2019-06-14 14:46:09,354 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:46:12,422 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 42.0
2019-06-14 14:46:19,356 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:46:22,424 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:46:29,349 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:46:32,417 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:46:39,350 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:46:42,420 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:46:49,353 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:46:52,421 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:46:59,353 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:47:02,423 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:47:09,349 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:47:14,945 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:47:24,410 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:47:27,480 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:47:29,349 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:47:37,482 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:47:39,349 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:47:44,944 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:47:56,942 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:48:00,011 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 40.0
2019-06-14 14:48:03,081 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0
2019-06-14 14:48:06,152 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'humidity' value 39.0
2019-06-14 14:48:09,348 mqtt_gpio (INFO): sensor_timer_thread: reading sensor 'temperature' value 28.0

Thanks for the report.
Could you also provide the relevant sections of your config, if you're setting the interval there?

I edited the original post to include the wanted information.

What I think might be happening is that it takes a non-trivial amount of time to read the sensor, so it skews the timing. Can you try setting it to 30 or 60 seconds and see if it outputs the values more punctually?

should be fixed with the async integration. Please create a new issue, if the problem is still there.


Fix cross_iter_dep check.

Resolves #7854
Cross iteration dependency check wasn't working with the disjointness test working on ir.Var instead of variable names.  I changed to using names instead.

@DrTodd13 github is reporting a merge conflict, please could you address this? Many thanks.

@DrTodd13 github is reporting a merge conflict, please could you address this? Many thanks.

Simple.  Done.

Thanks for resolving the conflict @DrTodd13. Since then a8d4012 was added, is there a code sample available that was failing without this change? I note it limits analysis of indexes to arrays, would something involving a tuple trigger a problem prior to this addition?

Thanks for resolving the conflict @DrTodd13. Since then a8d4012 was added, is there a code sample available that was failing without this change? I note it limits analysis of indexes to arrays, would something involving a tuple trigger a problem prior to this addition?

There are existing tests that incorrectly prevent fusion if I didn't check for arrays only there.  So, I think your test case desire is already covered.

Thanks for resolving the conflict @DrTodd13. Since then a8d4012 was added, is there a code sample available that was failing without this change? I note it limits analysis of indexes to arrays, would something involving a tuple trigger a problem prior to this addition?

There are existing tests that incorrectly prevent fusion if I didn't check for arrays only there. So, I think your test case desire is already covered.

I guess the question is... should something in the test suite be checking for this if the test suite passes invariant of the patch in a8d4012? Would it be good to add a new test with a cross iter dep that includes indexing into non-arrays that asserts that fusion is occurring when expected?

@stuartarchibald Please see if my latest change(s) are what you are looking for.


docs(zh_CN): Description is different from the preview

describe: https://github.com/lf-edge/ekuiper/issues/1368
Signed-off-by: 龚国玮<EMAIL_ADDRESS>

Thanks Guowei! I find the English version has the same problem, could you also change the screenshot there?

OK

Do I need to merge into the same request?

Do I need to merge into the same request?

It's fine, we can squash and merge after review

DCO check fails, please follow the instruction in the details to get it passed.


Return the default gas adjustment if used instead of null

Where is int get limit => estimate?

gas.dart line 18


InputLabel on Autocomplete react-select Input

When trying to insert an InputLabel in the autocomplete field using react-select, when it has a selected value, and takes the focus out of the field, the Label returns to the same place of the value (back into the field) .
And to let the field without a placeholder you need to declare placeholder as an empty string in inputProps (like this:  placeholder: ""). Without the empty string, the placeholder defaults to "Select ..." (was this to be the default behavior anyway?)
Expected Behavior
The InputLabel should remain above the field (top).
Link for problem
Code on sandbox.io
My Environment

Tech
Version

Material-UI
1.0.0-beta.34

React
16.2.0

browser
Chrome 64.0.3282.167

Sorry, we won't provide support on this demo, it's already too hacky. If you find a workaround please submit a pull request.

@aldo-jr - I have to thank you for the sandbox link, it helped me get a floating label onto the react-select example. I was having the same issue as you with the label collapsing back onto the value in the input and determined that you just need to control the "shrink" prop on the Input label to force the label to stay where it is. Something like <InputLabel shrink={inputHasValue}/> should do it


Less linting not working for mixins with rulesets

VSCode Version: 1.5.2
OS Version: OS X 10.11.6

Steps to Reproduce:

Create a .less file with a mixin that has a ruleset as argument

.tablet-and-larger(@rules){     @media (min-width: @screen-sm) { @rules(); } }
2. Less linting underlines @rules() on the @media line and also the last curly brace. The errors returned are

} expected
at-rule or selector expected

http://lesscss.org/features/#detached-rulesets-feature

Could be related to #12720 perhaps?

Here is an example snippet taken from lesscss.org. It illustrates both issues with detached rulesets used in a nested media query, and rulesets passed directly as a mixin parameter.

Fixed in the meantime. Verified in the January build.


Add response time and size

After each request, it'd be nice to see the response time + size of the response in KB somewhere. E.g. 251ms, 23.3kb

Does GraphiQL.Footer suffice?

@leebyron display-wise yes, but I think we'd need a hook into _fetchQuery.

The provided fetcher function should be the appropriate hook, I believe.
I'd like to find a way to do this which allows for very easy extension as I think others will want more or different information about requests.

haha yah. of course the fetcher would let you do this. my bad.
So I guess the question becomes, should we just implement this completely in user-land? If so, np. We can close this and @KyleAMathews I can throw this in graphiql-app sometime soon.

My thought when creating this is that GraphiQL should ship with some sort of basic response info indicator that'd be easily overridable e.g. in the top section to the right of the play button.

I feel like GraphiQLToolbar and GraphiQLFooter are available to serve exactly that purpose - to give users freedom to provide any customized information/feature they want. I do think that this should be implemented in user-land.

Could have this as an optional add-in for express-graphql: https://github.com/expressjs/response-time

Why not just use extensions and create this yourself: https://github.com/graphql/express-graphql#options. Obviously means using the express-graphql server. Seems pretty trivial to implement in user-land.

Thanks for pinging this neglected old issue @joelgriffith. extensions is indeed intended for exactly this kind of use case, and rendering it in the footer is an appropriate place to put the data, so I think we should probably close this. Thanks to everybody who participated in the thread!


Missing space before -or

Not a major issue, more of a formatting task..
https://github.com/beatcracker/Powershell-Misc/blob/931b7fd3c632de07494de71b3eae8a4a35133c91/Use-ServiceAccount.ps1#L327

Thanks, fixed!


Inference against a corpus is segfaulting

I am migrating away from model.make_doc to tp.util.Corpus and am finding that using Corpus segfaults. My tiny repro is here:
#!/usr/bin/env python3

import time

import numpy as np
import tomotopy as tp

# Workaround for `str.split` received unknown kwarg user_data
class WSTok:
    def __call__(self, raw, **kwargs):
        return raw.split()

def get_highest_lda_list(model, N, docs):
    corpus = [model.make_doc(doc.split()) for doc in docs]
    topic_dist, ll = model.infer(corpus)
    k = np.argmax(topic_dist, axis=1)
    return [" ".join(e[0] for e in model.get_topic_words(k_, top_n=N)) for k_ in k]

def get_highest_lda_corpus(model, N, docs):
    corpus = tp.utils.Corpus(tokenizer=WSTok(), stopwords=[])
    corpus.process(doc for doc in docs)
    topic_dist, ll = model.infer(corpus)
    k = np.argmax([doc.get_topic_dist() for doc in topic_dist], axis=1)
    return [" ".join(e[0] for e in model.get_topic_words(k_, top_n=N)) for k_ in k]

if __name__ == "__main__":
    docs = [line.strip() for line in open('10_line_pretokenized_corpus.tsv')]
    lda = tp.LDAModel.load('tm_model.bin')
    N = 10
    t0 = time.time()
    list_res = get_highest_lda_list(lda, N, docs)
    print(f"Took {time.time() - t0} seconds (list)")
    corpus_res = get_highest_lda_corpus(lda, N, docs)
    print(f"Took {time.time() - t0} seconds (corpus)")
    t0 = time.time()
    assert all(e == f for e, f in zip(corpus_res, list_res))

When I run this, I see:
Took 19.61503529548645 seconds (list)
Segmentation fault (core dumped)

Running this with catchsegv shows these relevant lines:
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x46210)[0x7f171bd43210]
/home/erip/.venv/lib/python3.8/site-packages/_tomotopy_avx2.cpython-38-x86_64-linux-gnu.so(_ZNSt6vectorIjSaIjEE12emplace_backIJRjEEEvDpOT_+0x7c)[0x7f16d662705c]
/home/erip/.venv/lib/python3.8/site-packages/_tomotopy_avx2.cpython-38-x86_64-linux-gnu.so(_Z10makeCorpusP16TopicModelObjectP7_objectS2_+0x681)[0x7f16d6db8f51]
/home/erip/.venv/lib/python3.8/site-packages/_tomotopy_avx2.cpython-38-x86_64-linux-gnu.so(_Z9LDA_inferP16TopicModelObjectP7_objectS2_+0x25a)[0x7f16d6d71b8a]

which seems to point here... maybe d.get() is null?

It seems like my WSTok is the issue and that it doesn't meet the expected interface (__call__ should return (tok, start, stop)). If I use tp.util.SimpleTokenizer(pattern="\w+"), it seems to be OK... this is somewhat unexpected, though so maybe documentation can be slightly improved.

Hi, @erip
Could you share some pieces of the file 10_line_pretokenized_corpus.tsv for reproducing?
A similar error is not reproduced in the sample text I have, so it is not easy to determine the cause.
If you share the file where the problem is reproduced, it will be of great help to find the cause.

@bab2min are you using the WSTok here? It should cause the error


Building for Meteor 1.5 (not semver)

Building for Meteor 1.5 will produce an error first because:
release = release.match(/(^\d+.\d+.\d+)/gmi)[0];
won't match 1.5 (would only match 1.5.0), which is followed with an error in 'checkMeteorVersion':
if (!_semver2.default.satisfies(release, versionRange))
because 1.5 is not semver.
Exactly the same errors pop up within 'chooseStrategy'.
After manually bypassing all of these though, Meteor 1.5 appears to work just fine!

@KoenLav I got this same error when trying to build after updating! But I didn't have time to look into it. I got some kind of error specifying cannot read [0] of undefined (something like that, cant quite remember)
How did you get it to work? Manually bypassing error? How did you do that?
Would you just have to change the release version in .meteor folder to 1.5.0?

@sferoze I manually edited the code in node_modules/meteor-desktop/dist.
If you look at the error messages you'll be able to figure out where the errors arise from and you can comment that code (as the code is only used to do version checking for Meteor, and you know you're using the right version).
This is not a production ready fix, hence I didn't save the code or anything.

Better version checking is now released in v0.7.2

Works fine with Meteor 1.5 now!

I get a new error now:
ERROR  meteorApp:  error occurred during checking preconditions:  TypeError: Cannot read property '0' of null
    at MeteorApp.castMeteorReleaseToSemver (C:\MyAPP\node_modules\meteor-desktop\dist\meteorApp.js:362:83)
    at MeteorApp.checkMeteorVersion (C:\MyAPP\node_modules\meteor-desktop\dist\meteorApp.js:373:32)
    at MeteorApp._callee3$ (C:\MyAPP\node_modules\meteor-desktop\dist\meteorApp.js:441:42)

I don't know how this is possible but after inspecting the code if find that the concatenation of the function this.getMeteorRelease() and .0.0 result only on .0.0.
I check the type of the result of the function it was string so after some time i just convert it in float before the concatenation and it work.
So this return (this.getMeteorRelease() + '.0.0').match(/(^\d+\.\d+\.\d+)/gmi)[0]; become this return (parseFloat(this.getMeteorRelease()) + '.0.0').match(/(^\d+\.\d+\.\d+)/gmi)[0]; on dist/meteorApp.js at line 362


validate installModes failed on OCP 4.2.0

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).
I try to use install.sh to install the olm on ocp 4.2 environment, but failed like below:
hchenxa@hchenxadembp:~/Documents/hchenxa/src/hchenxa_github/openshift/operator-lifecycle-manager/deploy/upstream/quickstart$ ./install.sh 0.13.0
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
customresourcedefinition.apiextensions.k8s.io/clusterserviceversions.operators.coreos.com configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
customresourcedefinition.apiextensions.k8s.io/installplans.operators.coreos.com configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
customresourcedefinition.apiextensions.k8s.io/subscriptions.operators.coreos.com configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
customresourcedefinition.apiextensions.k8s.io/catalogsources.operators.coreos.com configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
customresourcedefinition.apiextensions.k8s.io/operatorgroups.operators.coreos.com configured
namespace/olm created
namespace/operators created
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
clusterrole.rbac.authorization.k8s.io/system:controller:operator-lifecycle-manager configured
serviceaccount/olm-operator-serviceaccount created
clusterrolebinding.rbac.authorization.k8s.io/olm-operator-binding-olm created
deployment.apps/olm-operator created
deployment.apps/catalog-operator created
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
clusterrole.rbac.authorization.k8s.io/aggregate-olm-edit configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
clusterrole.rbac.authorization.k8s.io/aggregate-olm-view configured
operatorgroup.operators.coreos.com/global-operators created
operatorgroup.operators.coreos.com/olm-operators created
error: error validating "https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml": error validating data: [ValidationError(ClusterServiceVersion.spec): unknown field "installModes" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec, ValidationError(ClusterServiceVersion.spec): unknown field "provider" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec]; if you choose to ignore these errors, turn validation off with --validate=false

the message shows that the installModes was not valid in clusterserviceversion validation, I am not sure why it failed here.
What did you expect to see?
A clear and concise description of what you expected to happen (or insert a code snippet).
What did you see instead? Under which circumstances?
A clear and concise description of what you expected to happen (or insert a code snippet).
Environment

operator-lifecycle-manager version:

Kubernetes version information:

Kubernetes cluster kind:

Possible Solution

Additional context
Add any other context about the problem here.

and append the full logs with -x options:
hchenxa@hchenxadembp:~/Documents/hchenxa/src/hchenxa_github/openshift/operator-lifecycle-manager/deploy/upstream/quickstart$ bash -x ./install.sh 0.13.0
+ set -e
+ [[ 1 -ne 1 ]]
+ release=0.13.0
+ url=https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0
+ namespace=olm
+ kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/crds.yaml
customresourcedefinition.apiextensions.k8s.io/clusterserviceversions.operators.coreos.com configured
customresourcedefinition.apiextensions.k8s.io/installplans.operators.coreos.com unchanged
customresourcedefinition.apiextensions.k8s.io/subscriptions.operators.coreos.com unchanged
customresourcedefinition.apiextensions.k8s.io/catalogsources.operators.coreos.com unchanged
customresourcedefinition.apiextensions.k8s.io/operatorgroups.operators.coreos.com unchanged
+ kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml
namespace/olm unchanged
namespace/operators unchanged
clusterrole.rbac.authorization.k8s.io/system:controller:operator-lifecycle-manager unchanged
serviceaccount/olm-operator-serviceaccount unchanged
clusterrolebinding.rbac.authorization.k8s.io/olm-operator-binding-olm unchanged
deployment.apps/olm-operator configured
deployment.apps/catalog-operator configured
clusterrole.rbac.authorization.k8s.io/aggregate-olm-edit unchanged
clusterrole.rbac.authorization.k8s.io/aggregate-olm-view unchanged
operatorgroup.operators.coreos.com/global-operators unchanged
operatorgroup.operators.coreos.com/olm-operators unchanged
error: error validating "https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml": error validating data: [ValidationError(ClusterServiceVersion.spec): unknown field "installModes" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec, ValidationError(ClusterServiceVersion.spec): unknown field "provider" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec]; if you choose to ignore these errors, turn validation off with --validate=false

Hello @hchenxa

error: error validating "https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml": error validating data: [ValidationError(ClusterServiceVersion.spec): unknown field "installModes" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec, ValidationError(ClusterServiceVersion.spec): unknown field "provider" in com.coreos.operators.v1alpha1.ClusterServiceVersion.spec]; if you choose to ignore these errors, turn validation off with --validate=false

Based on the error message above, it appears that you are trying to install an old version of OLM where the CRDs do not  include Structural Schemas on a 1.16.X version of Kubernetes. 1.16 requires that CRDs include structural schemas / validation, as the error above indicates.
Some possible solutions include:

Moving to the latest version of OLM by running git checkout master and make release command to generate the appropriate CRDs
Moving to an older version of Kubernetes
Updating the script to include the --validate=false flag as the error above mentions, this approach may introduce unexpected runtime behavior

I'll be closing this for now as it isn't an OLM bug and is instead an OLM version <->Kubernetes version mismatch. If you have any strong opinions, please open the issue again and share your thoughts.

as I said in the issue, my cluster was ocp 4.2.0 and I think the kubernetes version was v1.14.6.
hchenxa@hchenxadembp:~/Documents/hchenxa/src/hchenxa_github/openshift/operator-lifecycle-manager/deploy/upstream/quickstart$ oc get nodes
NAME                           STATUS   ROLES    AGE   VERSION
master0.spiv.os.fyre.ibm.com   Ready    master   12d   v1.14.6+c07e432da
master1.spiv.os.fyre.ibm.com   Ready    master   12d   v1.14.6+c07e432da


WIP: Proper runtime support

Part of https://github.com/fsprojects/Paket/pull/2252 but extra PR to make it easier to review.

OK this is crazy. If I got that correct some nuget packages can specify additional dependencies for a specific runtime in a file called runtime.json.
This looks like:
  "runtimes": {
    "win": {
      "Microsoft.Win32.Primitives": {
        "runtime.win.Microsoft.Win32.Primitives": "4.3.0"
      },

This means Paket needs to restore runtime.win.Microsoft.Win32.Primitives (which is not known through the regular dependency tree) to support the "win" rid (or any rid importing "win").
How do we do that in paket? I don't want to change the current resolver (as it is complicated enough). For now I'd try to implement this as a second phase (after regular restore has happened). This means that paket will ignore any runtime.json in the second layer (but doing this is insanity IMHO anyway)...
@forki please advise if that sounds like going into the wrong direction...

Runtime.json is a brain fart. I never understood what people were thinking
to implement that hack.
Am 17.04.2017 16:13 schrieb "Matthias Dittrich"<EMAIL_ADDRESS>
OK this is crazy. If I got that correct some nuget packages can specify
additional dependencies for a specific runtime in a file called
runtime.json.
This looks like:
"runtimes": {
"win": {
"Microsoft.Win32.Primitives": {
"runtime.win.Microsoft.Win32.Primitives": "4.3.0"
},
This means Paket needs to restore runtime.win.Microsoft.Win32.Primitives
(which is not known through the regular dependency tree) to support the
"win" rid (or any rid importing "win").
How do we do that in paket? I don't want to change the current resolver
(as it is complicated enough). For now I'd try to implement this as a
second phase (after regular restore has happened). This means that paket
will ignore any runtime.json in the second layer (but doing this is
insanity IMHO anyway)...
@forki https://github.com/forki please advise if that sounds like going
into the wrong direction...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/pull/2255#issuecomment-294493109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNBBzS0ndDDx5WsR1NfVA1arInvt9ks5rw3OVgaJpZM4M_IIr
.

And now what?

Ok this is an interesting start. I think I'll do the integration in the following way:

[ ] Add a new "runtimes" directive to the deps and lockfile

source https://nuget.org/api/v2
runtimes aot,win

nuget Newtonsoft.Json redirects: force

[ ] After regular install/update there will be another install/update step for the runtime dependencies for the enabled runtimes

This way restore doesn't need to be changed at all and the new packages will be in the regular resolution (I guess I need a new flag in the lockfile to "detect" if a package is in the regular resolution or if its picked because of runtime).
Still not sure if the default should be installing all packages for all runtimes OR no runtime at all. Currently I'm favoring all runtimes...

I'm not sure that it should default to installing for all runtimes (there are a ton of them) and in the absence of a specified runtime, isn't the default behavior to produce a FDD instead of a SCD ?

I'm not sure that it should default to installing for all runtimes (there are a ton of them) and in the absence of a specified runtime, isn't the default behavior to produce a FDD instead of a SCD ?

Yes, but I'm not sure how they handle native dependencies in that case. From observing I'd say they ignore runtime deps (as in runtime.json) but they still copy stuff in the regular resolution....

Why do we need runtime in deps file? Shouldn't it just install the runtime we just use?

Why do we need runtime in deps file? Shouldn't it just install the runtime we just use?

Good point. But do you really want to read the fsproj file for info and then use that for resolving packages? What about multiple or no fsproj file? csproj? What about "old-style" fsproj? I don't even want to go into that. At least not in the first step (this PR) tbh...

No not fsproj. I meant the following: install should lock everything, but
restore only needs to download the stuff for the target it currently runs
on
Am 18.04.2017 9:57 vorm. schrieb "Matthias Dittrich" <
<EMAIL_ADDRESS>
Why do we need runtime in deps file? Shouldn't it just install the runtime
we just use?
Good point. But do you really want to read the fsproj file for info and
then use that for resolving packages? What about multiple or no fsproj
file? csproj? What about "old-style" fsproj? I don't even want to go into
that. At least not in the first step (this PR) tbh...
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/pull/2255#issuecomment-294720155,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNKu_EtBNZguqU3z1dOtXdN3NvOOnks5rxGzZgaJpZM4M_IIr
.

What is "the target it currently runs on"?

The OS if the machine

And what if I run on windows and want to publish my project for unix?

Hook in restore into dotnet publish?
Am 18.04.2017 10:05 vorm. schrieb "Matthias Dittrich" <
<EMAIL_ADDRESS>
And what if I run on windows and want to publish my project for unix?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/pull/2255#issuecomment-294722009,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNDXTGRqOVFJszMB1nnuBQsKjuzsBks5rxG6ygaJpZM4M_IIr
.

So its the same problem you do another resolver step on "restore" to resolve the runtime deps. I think in pakets philosophy we should have already done that at that phase (IMHO) ... But it's up to you

I'd prefer the following when we get called by dotnet restore with an unknown runtime:

If in CI/noninteractive mode we fail when a runtime is not in the deps file and we are called
In interactive mode we ask the user if we should update the deps file and do an "install"

No not resolver. Only restore
For resolving (during install/update) we would check everything.
Am 18.04.2017 10:12 vorm. schrieb "Matthias Dittrich" <
<EMAIL_ADDRESS>
I'd prefer the following when we get called by dotnet restore with an
unknown runtime:

If in CI/noninteractive mode we fail when a runtime is not in the
deps file and we are called
In interactive mode we ask the user if we should update the deps
file and do an "install"

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/pull/2255#issuecomment-294723660,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNBBZI-zOeeITT8XoXemUczSaenIgks5rxHB8gaJpZM4M_IIr
.

@forki So we always resolve and lock every runtime down (during install/update). I'm fine with that, lets see how that works.
The lockfile might grow quite a bit with this.
But isn't install/update currently downloading the packages as well? Why would we change the behavior for the runtime deps?
I agree that our hook can have this behavior to only download whats needed.
It is really confusing, and I don't know if there is a good way how this fits into our world view...
On the other side I don't expect this PR to be perfect, just a start to experiment how things might work...

It does not fit our world view. That's the whole point.


Creating and Destroying Slides Dynamically

I'm creating a system where once a button is clicked data is loaded from a database and slides are dynamically created.
But there doesn't seem to be a way in Jssor to create slides on the fly.
Edit: My work around is to re-generate the slider every time. It feels a bit hacky, so if there was a better way, I think that would be best.

I will implement $Destroy api later.
For now, the approach is as follows,
jssor_slider1.$Pause();
//and then remove the 'slider1_container' element.

Doesn't $Pause just stop the Autoplay?
I'm currently removing the slider and re-making but I'm not pausing anything

Yes, it stops 'AutoPlay' for the previous slider.
And then you'd create a new one.

So if I want to use Jssor on a page that contains various thumbnails, any of which I want users to be able to click to display a full-size version in a slider that allows users to move between full-size versions of any of the other images, would I need to

Initialize Jssor on first click,
Jump to the clicked image,
Implement a close button on the slider that when clicked sets the slideshow div to "display:none", and
When another thumb is clicked, set the slideshow div to "display:block" and jump to the clicked image?

Yes, you can create jssor slider on demand.

var slider1 = new $JssorSlider$("id", options);
in the options, add $StartIndex: 1 (this option means which slide to display at the beginning. 0: first slide, 1: the second slide)
You can do some manual job to implement this feature. For example, add custom close button above the slider.
use slider1.$GoTo(1); to display specified slide.

Great, thanks for the reply. I'm about to give it a go as you've suggested. I've been looking at "lightbox" libraries, which are designed for such pop-up slideshows, but haven't found one with both touch and mouse controls as good as Jssor.

I'm trying to make the carousel work with different parameters on mobile devices (nested carousel similar to this one -> http://www.jssor.com/testcase/nested-slider-loop-through.source.html).
On mobile devices i want to show every item one by one from each carousel, but on desktop i want to swipe all items from one carousel at once.
It's all going well but at window resize i want to recall the carousel so that the new settings work as i intend.
I already did this but it's not working:
jQuery(window).resize(function($){
jssor_slider1.$Pause();
jQuery("#slider1_container").remove();
initializeCarousel($);
});
Can you provide a metod?
Thx in advance!


Custom authentication using dfinity/agent

I am trying to implement third-party authentication mechanism on front-end.
I'm trying to log in telegram web app into juno (because both nfid and internet identity work poorly in this environment)
Setup:
I have profiles table in juno (read: Public, write: Managed)
And i construct my identity in the following way:

const customIdentity = Ed25519KeyIdentity.generate()

// this doesnt work because reads are public :(
const profile = await getDoc({
  collection: "profiles",
  key: "123",
  satellite: {
    identity: customIdentity,
    satelliteId: "n5isd-iaaaa-aaaal-adtra-cai",
  }
})

// this works because reads are public
const profile = await getDoc({
  collection: "profiles",
  key: "123",
  doc: {
    username: "CodingFu"
  },
  satellite: {
    identity: customIdentity,
    satelliteId: "n5isd-iaaaa-aaaal-adtra-cai",
  }
})

I understand for the fact that user does not exist on authentication tab.
How can I add user with custom provider there?
Is there any way i can "fake" authentication in juno?
I know that i can make my customIdentity a controller for the satellite, but I can't do it for all the users. Plus I want to maintain "owner" field.
Please help!

How can I add user with custom provider there?

This is not yet supported. Providing interfaces for generic custom authentication is tracked in #156.

Is there any way i can "fake" authentication in juno?

I'm not sure what's "fake." Protected features require authenticated users. These are saved within a system collection named #user. If you are looking to hack around, one thing you could try is handling the reading and setting of such entities yourself. You can replicate the getDoc and setDoc methods from https://github.com/junobuild/juno-js/blob/51ecef384e001eab3d9c4aa254eb6df0b1a3a9f8/packages/core/src/services/user.services.ts#L16
This requires being able to obtain or derive an identity on your own—i.e., an identity is a must. It is worth noting that this can also potentially become insecure quickly; therefore, precautions are advised.

I know that i can make my customIdentity ...

If you are not using the built-in supported authentication (II and NFID), you have indeed have to pass the satellite parameters with your identity for each call.
Let me know if you have any other questions.

This was very very helpful! I managed to implement authentication! Thank you very much.

Cool! Is your solution open source? Would you ming sharing it?

let customIdentity: Identity | null = null;

export function setAPICustomIdentity(identity: Identity) {
  customIdentity = identity;
}

export function getSatteliteOptions(): SatelliteOptions {
  let options: SatelliteOptions = {};

  if (customIdentity) {
    options = {
      identity: customIdentity,
      satelliteId: import.meta.env.VITE_JUNO_ID as string,
    };
  }

  return options;
}

import React, { useEffect } from "react";
import { initCloudStorage } from<EMAIL_ADDRESS>import Loading from "../LoadingSplashScreen";
import { Ed25519KeyIdentity, ECDSAKeyIdentity } from "@dfinity/identity"
import { useRecoilState } from "recoil";
import { authState, customIdentity as customIdentityAtom } from "@/atoms/auth";
import { getSatteliteOptions, setAPICustomIdentity } from "@/api";
import {  fetchProfile, profileState } from "@/atoms/profile";
import { User, UserData, getDoc, setDoc } from "@junobuild/core";
import { Profile } from "@/types/entities";
import { useLocation, useNavigate } from "react-router-dom";
import { postEvent } from<EMAIL_ADDRESS>
export default function TelegramAuthProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const IDENITITY_KEY = "telegram_internet_identity";
  const [isInitialized, setIsInitialized] = React.useState(false);
  const [, setUser] = useRecoilState<User | null>(authState);
  const [, setProfile] = useRecoilState<Profile | null>(profileState);

  const location = useLocation();
  const navigate = useNavigate();

  useEffect(() => {

    async function authorize() {
      const cloudStorage = initCloudStorage();

      console.log("authorizing")
      let restoredIdentity = await cloudStorage.get(IDENITITY_KEY);

      let identity : Ed25519KeyIdentity;
      if (!restoredIdentity) {
        console.log("generating identity")
        identity = await Ed25519KeyIdentity.generate();
        await cloudStorage.set(IDENITITY_KEY, JSON.stringify(identity.toJSON()));
        console.log("idenitity saved", identity.toJSON())
        console.log("principal:", identity.getPrincipal().toString())
      } else {
        identity = Ed25519KeyIdentity.fromJSON(restoredIdentity);
        console.log("restored identity", identity)
        console.log("principal:", identity.getPrincipal().toString())
      }

      setAPICustomIdentity(identity);

      const user = await getDoc<UserData>({
        collection: `#user`,
        key: identity.getPrincipal().toText(),
        satellite: getSatteliteOptions()
      });

      if (!user) {
        const result = await setDoc<UserData>({
          collection: `#user`,
          doc: {
            key: identity.getPrincipal().toText(),
            data: {
              provider: "internet_identity",
            },
          },
          satellite: getSatteliteOptions()
        });
        setUser(result);
      } else {
        setUser(user);
      }
      setIsInitialized(true);
    }

    authorize();
  }, []);

  if (!isInitialized) {
    return <Loading />;
  }

  return <>{children}</>;
}

Baically i generate an identity and store it in telegram cloudStorage
it's like localStorage but it's synced between telegram clients on laptops, iphones, etc.
I'm still not 100% sure on security, but it does the trick.
I plan to move it out to auth canister and will make auth canister give me delegated identity, but while we are in prototyping phase, this approach works for me :)

@peterpeterparker
typescript nags at me, but what if I set provider to telegram in
const result = await setDoc<UserData>({
          collection: `#user`,
          doc: {
            key: identity.getPrincipal().toText(),
            data: {
              // @ts-ignore
              provider: "telegram",
            },
          },
          satellite: getSatteliteOptions()
        });

Thanks for the share, insteresting approach.

I'm still not 100% sure on security, but it does the trick.

I don't know how cloudStorage works but, indeed that does not feel super secure. Is the access to cloudStorage securised or anyone that basically knows telegram_internet_identity can retrieve the identity you stored? If the latest, it would be quite a loop hole.
I also don't know how things are encoded in cloudStorage...

typescript nags at me, but what if I set provider to telegram in

It's because typescript accepts only internet identity or nfid (see here). That will be extended once we develop the feature https://github.com/junobuild/juno-js/issues/156.


Organizations using SCPs to Restrict Regions

CloudMapper uses ec2.describe_regions() to pull back which regions to iterate over.  Is there a better way to get this in an org that restricts regions using SCPs?  Currently this causes a lot of access denied errors as cloudmapper tries to run describe calls in regions that aren't enabled.

I wanted to avoid hard-coding a list as AWS adds more regions, but it could make sense to fall back to a hard-coded list where this call is restricted.  There has been this PR to filter on the regions you collect from for this PR https://github.com/duo-labs/cloudmapper/pull/496 and issue https://github.com/duo-labs/cloudmapper/issues/549

Thanks for showing up a ticket about this exists already.
Please be aware, that thee "hardcoded" region does not only appear in the ec2.describe_regions part.
It appears way more often in the meaning of "hardcoded".
Maybe a effortless workaround could be, that there is on top of the "default" region also an "api" region.
This is available for all services except the "universal/global" ones. This could get rid of the situtation that my "hosting" region is depending somehow on the api region.

This issue has been resolved via #698 where you can now define which regions to collect from.


[Proposal] Moving the client package to docker/docker

Problem statement
The docker/engine-api repository was created to create a true decoupling between Engine internals and its public interface. A lot of valuable and solid refactoring came out of it, but today, most maintainers are complaining about the operational trade-offs it incurs.
Proposal
The content of this repository will be moved back as a sub-package of docker/docker. We absolutely want to preserve the architectural boundary, but we want to remove the repository boundary which is too cumbersome.
Under that scenario, what should we do with the docker/engine-api repository?

Abandon it in its current version, and encourage people to now import github.com/docker/docker/api/client/ (exact path TBD).
Have it contain the latest stable version of the client package extracted from github.com/docker/docker/api/client/ (exact path TBD).

I'm curious about your opinions @vdemeester @ibuildthecloud.

I'd prefer option 1 since with golang people can just vendor it "as is" and not have to worry about whether "master" of docker is, or is not, master on the APIs. People will just know they're always at the same level.  Plus, a tag of docker will automatically cover both areas. We don't need to worry about tagging 2 repos.

I would concur with @duglin. Absolutely though, trying to bring these back together in some manner that remains architecturally clean is goodness and makes life (for me at least - others might disagree :innocent: ) significantly easier.

Although I like engine-api a lot (it's smaller to get than docker/docker when vendoring :stuck_out_tongue_closed_eyes:), I think it has to be done at some point :sweat_smile:. The code in engine-api is to tied to docker/docker anyway so…
If we do it, I also prefer option 1 ; given also that we do something like #358 too 👼…

Agreed with option (1). For #358 we can just create a completely new repo with a better name.

FWIW 1,646 projects on github alone import the types package here alone... do you have a plan for informing people?

@jfrazelle we are not going to delete this or anything.  Existing imports will continue to work.
I'm sure we can add this change in the next release notes, etc so that people can get the updated client in the next release.

maybe a warning on init or something though? idk if that is more pain though for people

Ya, i thought about that but if that happens to me I usually freak out because some package is logging messages in my program.
I'll update the readme in this repo as a start and trying to think of a way to notify the people.


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Minor Changes

#2431 6cf298a Thanks @edwardysun! - Add pay to Services list

PR-Codex overview
This PR updates the version of @thirdweb-dev/service-utils from 0.4.18 to 0.5.0. It includes a new feature to add pay to Services list.
Detailed summary

Updated package version to 0.5.0
Added feature to include pay in Services list

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

thank you!


move IAMRole and IAMRolePolicyAttachment to v1beta1

Description of your changes
Add implementations of IAMRole and IAMRolePolicyAttachment that adhere to the managed resources standards
Tested with the following
IAMRole
apiVersion: identity.aws.crossplane.io/v1beta1
kind: IAMRole
metadata:
  name: sample-cluster-role
  annotations:
   crossplane.io/external-name: managed-resource-role
spec:
  forProvider:
    description: some description
    assumeRolePolicyDocument: |
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
  reclaimPolicy: Delete
  providerRef:
    name: example

IAMRolePolicyAttament
apiVersion: identity.aws.crossplane.io/v1beta1
kind: IAMRolePolicyAttachment
metadata:
  name: sample-role-servicepolicy
spec:
  forProvider:
    roleNameRef:
      name: sample-cluster-role
    # wellknown policy arn
    policyArn: arn:aws:iam::aws:policy/AmazonEKSServicePolicy
  reclaimPolicy: Delete
  providerRef:
    name: example
~

Checklist

I have:

[x]  Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the dependencies in app.yaml to include any new role permissions.

kubectl get iamrole.identity.aws.crossplane.io/metadata-name

NAME            ROLENAME   DESCRIPTION   READY   SYNCED   AGE
metadata-name              update desc   True    True     12s

For the ROLENAME column, because .spec.rolename has been removed, I tried to pull the value from annotation crossplane.io/external-name in the CRD definition. Didn't work for me.
(Pulling values from other annotations with no special characters does seem to work)

@sahil-lakhwani What is the latest on updating and merging this PR?

@sahil-lakhwani What is the latest on updating and merging this PR?

Hi @infinitecompute
There were some confusions, regarding which I had quick discussions with @hasheddan
And then I had to make some more changes to match the name change (provider-aws)
I have updated the PR.

@hasheddan @muvaf I have added new commits to address the comments.

I believe there are a few more of @muvaf comments to address, but going to go ahead and give this the LGTM! @sahil-lakhwani would you mind running a few manual e2e tests (like you did earlier) to verify functionality is operating as expected? Thanks so much for continuing to push through this!

@hasheddan Couldn't directly reply to your comment https://github.com/crossplane/provider-aws/pull/141#discussion_r392948035  but the thing you mentioned has been taken care of:
https://github.com/sahil-lakhwani/provider-aws/blob/54a5aa32696b9434364e038fd0db05a1b5864fc4/pkg/controller/identity/iamrole/controller.go#L113-L115
Also, I saw the test coverage results today, will take a look.

Is additional code coverage the only blocker to merging?

@negz I was trying to write the YAMLs for the scenario here and realized that we don't support inline IAM policies. Digging more, I found out RolePolicy term is used for inline policy and when we create a IAMRolePolicyAttachment, what happens is that the normal policy gets copied to Role as managed inline policy. The interesting part is that actual inline policies are added in the same way, as seen here and there is no way to create a RolePolicy without attaching it to a role. So, I think some consolidation could make sense there.
I suggest:

Rename IAMRolePolicyAttachment to IAMRolePolicy.
Add a field PolicyDocument to allow specifying the policy inline.
If the PolicyDocument is given, call PutRolePolicy and if PolicyArn is given call AttachRolePolicy.

The idea is that we'd have one managed resource for inline policy operations as opposed to mapping each imperative call to a managed resource. This functionality is additive and not blocking this PR but I wanted to drop it on this PR in case we want to rename the resource, better to do it before bumping to v1beta1.
Also, should we drop IAM prefix from the name of both IAM resources? We already have identity in the group name. Maybe change identity group name to iam to match the API?

Also, should we drop IAM prefix from the name of both IAM resources? We already have identity in the group name. Maybe change identity group name to iam to match the API?

This sounds reasonable to me. We'd have role.iam.aws.crossplane.io etc, and the Go types would be imported as iamv1beta1.Role.

I found out RolePolicy term is used for inline policy

Are you sure this is the case? As far as I can tell there's both PutRolePolicy (which specifies a policy to include inline) and AttachRolePolicy (which references an existing policy ARN) API calls. Both appear to use the term "role policy" for the policy, whether it's inline or distinct.

what happens is that the normal policy gets copied to Role as managed inline policy.

This doesn't match my understanding of the API. There seems to be a ListRolePolicy API call that lists inline policies, and also a ListAttachedRolePolicies that lists attached policies. As far as I can tell when you call GetRole it includes neither attached or inline policies.

we don't support inline IAM policies

@muvaf do we need to support inline IAM policies to support that use case? Under the current model, could we:

Create an IAM role that would be used by the pod that will access the RDS instance
Create an IAM policy that allows access to the RDS instance
Create an IAM role policy attachment to attach the policy from 2 to the role from 1?

I suggest:

Would this mean we could only attach IAM policies to IAM roles that were managed by Crossplane? It seems to me like there are two ways to associate a policy with a role; either include the policy inline, or add it as a distinct API object and create a reference between the two. The latter seems to be the more granular and flexible model.

This sounds reasonable to me. We'd have role.iam.aws.crossplane.io etc, and the Go types would be imported as iamv1beta1.Role. I feel okay merging this PR and making that change in a subsequent one though, to make it easier to review.

Sounds good. The rest of the discussions is not a blocker for this PR.
There is this doc that explains the inline and standalone policies. In all cases, you can use standalone policies with any entity (group, role, user etc.). The inline policy has essentially the same semantics except it has a one-to-one relationship with the entity.
Quoting from Inline Policies section of that doc:

Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the DynamoDB-books-app policy), but they are not sharing a single policy; each role has its own copy of the policy.

What I meant by copying is the mechanism that is described in the doc: if we used IAMRolePolicyAttachment that refers to a standalone policy, even though that standalone policy changes, the policy that is attached to the Role won't change. The moment we attach, a copy of the policy is coupled with the role. IMO, that is essentially the same thing with PutRolePolicy except that you give the policy to attach instead of refer to an existing one.

This doesn't match my understanding of the API. There seems to be a ListRolePolicy API call that lists inline policies, and also a ListAttachedRolePolicies that lists attached policies. As far as I can tell when you call GetRole it includes neither attached or inline policies.

Here is the comments from those calls:

ListAttachedRolePoliciesRequest returns a request value for making API operation for
AWS Identity and Access Management.
Lists all managed policies that are attached to the specified IAM role.

ListRolePoliciesRequest returns a request value for making API operation for
AWS Identity and Access Management.
Lists the names of the inline policies that are embedded in the specified
IAM role.

I can see your point that they are treated differently. Digging the outputs of those two calls, ListRolePoliciesRequest returns the PolicyNames []string and ListAttachedRolePoliciesRequest returns []AttachedPolicy which is just PolicyName string and PolicyArn string.
I feel tempted to handle both inline and reference cases in one resource but I can also see your point about high fidelity even though it will increase number of different managed resources.

Create an IAM policy that allows access to the RDS instance

That's what we are not able to do at the moment and I figured if we were able to expand the attachment for inline policy, then it'd be pretty easy to enable the use-case.

It seems to me like there are two ways to associate a policy with a role; either include the policy inline, or add it as a distinct API object and create a reference between the two. The latter seems to be the more granular and flexible model.

This sounds reasonable to me. We'd have role.iam.aws.crossplane.io etc, and the Go types would be imported as iamv1beta1.Role. I feel okay merging this PR and making that change in a subsequent one though, to make it easier to review.

Sounds good. The rest of the discussions is not a blocker for this PR. I can prepare a PR to do that.
There is this doc that explains the inline and standalone policies. In all cases, you can use standalone managed policies with any entity (group, role, user etc.). The inline policy has essentially the same semantics except it has a one-to-one relationship with the entity.
Quoting from Inline Policies section of that doc:

Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the DynamoDB-books-app policy), but they are not sharing a single policy; each role has its own copy of the policy.

What I meant by copying is the mechanism that is described in the doc: if we used IAMRolePolicyAttachment that refers to a managed policy, even though that managed policy changes, the policy that is attached to the Role won't change. The moment we attach, a copy of the policy is coupled with the role. IMO, that is essentially the same thing with PutRolePolicy except that you give the policy to attach instead of referring to an existing one. The CLI equivalent of those actions have more description: put-role-policy and attach-role-policy. I think your understanding is closer how it works and attaching is to refer managed policies, not copy it and treat as inline policy.
So, I agree that managed policy attachment and inline policy addition should be different resources.

Create an IAM policy that allows access to the RDS instance

That's what we are not able to do at the moment and I figured if we were able to expand the attachment for inline policy, then it'd have been pretty easy to enable the use-case.

It seems to me like there are two ways to associate a policy with a role; either include the policy inline, or add it as a distinct API object and create a reference between the two. The latter seems to be the more granular and flexible model.

I agree. But both ways have their own use cases. In this instance, even though it's possible to create a standalone policy, doing it inline makes more sense since the policy directly refers to an RDS instance and is the encouraged way. So, at some point we want inline option, too. But I can do with normal managed policy for now.

Also, should we drop IAM prefix from the name of both IAM resources? We already have identity in the group name. Maybe change identity group name to iam to match the API?

I mentioned this seemed like a good idea earlier, but now I'm thinking we can probably leave it as is. It seems like https://aws.amazon.com/iam/ is one service of https://aws.amazon.com/identity/, which also include SSO, Cognito, etc. I also suspect including IAM in the CR names will help folks, because you don't usually include the group in kubectl commands, and kubectl get iamrole, kubectl get iamrolepolicyattachment probably makes more sense to AWS users than kubectl get role, etc.

I mentioned this seemed like a good idea earlier, but now I'm thinking we can probably leave it as is. It seems like https://aws.amazon.com/iam/ is one service of https://aws.amazon.com/identity/, which also include SSO, Cognito, etc.

I have a feeling that identity is merely a marketing term. The grouping in the SDK seems like a better candidate to use in our groupings. You can see cognito and iam on the same level of services there without identity encapsulating them. Note that adopting SDK grouping has some nice implications as well such as reuse of some structs in our structs. For example ec2.Tag is used by all managed resources in ec2 group or rds.Tag is used by all RDS-related stuff.

I also suspect including IAM in the CR names will help folks, because you don't usually include the group in kubectl commands, and kubectl get iamrole, kubectl get iamrolepolicyattachment probably makes more sense to AWS users than kubectl get role, etc.

Yeah, kubectl get role does have an overlap. I'm not sure whether it'd be weird to make group iam and still call the role iamrole.
FWIW, you don't have to include the full group when there is collision. kubectl get provider.gcp and kubectl get provider.aws both return the right results. Maybe we could get away with using kubectl get role.iam to not have collision with kubectl get role (kubernetes Role resource).