phyllome development stage and children

Proposed new child of plant organ development stage (PO:0025339)
phyllome development stage (new PO:0025579): A plant organ development stage (PO:0025339) that has aprimary participant a phyllome (PO:0025023).
Proposed children of phyllome development stage, current and revised definitions:
lemma development stage (PO:0001047):Stages of development of the lemma defined by characteristic morphological, structural, histological or other visible features.
Revised def'n: A phyllome development stage (PO:0025579) that has as a primary participant a lemma (PO:0009037).
lodicule development stage (PO:0001049):Stages of development of the lodicule defined by characteristic morphological, structural, histological or other visible features.
Revised def'n: A phyllome development stage (PO:0025579) that has as a primary participant a lodicule (PO:0009036).
palea development stage (PO:0001048): Stages of development of the palea defined by characteristic morphological, structural, histological or other visible features.
Revised def'n: A phyllome development stage (PO:0025579) that has as a primary participant a palea (PO:0009038).
Reported by: lauramoore1859
Original Ticket: obo/plant-ontology-po-term-requests/548

Added a new relation:
phyllome development stage (PO:0025579) part_of shoot system development stage (PO:0025527).  See #582.
Closing this tracker for.  Can be reopened later if needed.


Missing files in C:\users\root\Application Data\pyinstaller\bincache10_py3*

pyinstaller is reporting the following error message when I try building for windows:
4996 INFO: Executing - strip C:\users\root\Application Data\pyinstaller\bincache10_py37_64bit\api-ms-win-crt-stdio-l1-1-0.dll
----------------------------------------
Error running 'strip C:\users\root\Application Data\pyinstaller\bincache10_py37_64bit\api-ms-win-crt-stdio-l1-1-0.dll':
[WinError 2] File not found
----------------------------------------
Error: Executing command failed!
Inspecting the directory immediately after that shows that the listed file is the only one present.
Running the entrypoint script again results in a similar result (again only one file present, explicitly mentioned in the error message) with a different DLL.
On top of the cdrx/pyinstaller-windows image from the Docker Hub, I've tried it with both the -py3-win32 and -py3-win64 Dockerfiles. I had to switch to winehq-stable as reported here to be able to get to this point. With the same result I've also tried the following combinations of python3 (with 3.5 and 3.6 could not reach this point) and pyinstaller versions, all with winehq-stable, with both Dockerfiles:
py3.7.5; pyinstaller-3.5
py3.7.5; pyinstaller-3.6
py3.7.9; pyinstaller-3.6
py3.7.5; pyinstaller-4.1
py3.8.7; pyinstaller-4.1
py3.9.1; pyinstaller-4.1

I have this issue also when I run pyinstaller in a Windows virtual machine

I have this issue also when I run pyinstaller in a Windows virtual machine

Resolved by specifying strip=False to the EXE(...) in the spec file.

Resolved by specifying strip=False to the EXE(...) in the spec file.


Correct the Twitter badge icon

Fixes issue #416
For Great Justice.

Thanks @nekohayo, justice has been merged :)

Thanks @nekohayo, justice has been merged :)


What is the second script?

The README states

Provides two command line scripts. First is to upload an org or txt files to Anki. The second allow quick notetaking and storage.

But Command line scripts only lists org_to_anki, so I'm wondering about that other notetaking and storage script.
I'm still wondering whether it's worth adopting your plugin or not. Used to rst/markdown syntax, but org seems like a fair alternative.
It also seems like a vim plugin could be wrapped around org_to_anki, to upload a file selection (eg a :ToAnki mapping).
How much effort would it take to support the reverse process, Anki to org? If I could sync Anki with a git repo of .org files, it would be extremely satisfying (the git repo could then be used as part of a Zettelkasten).

Hey,
Unfortunately that script no longer works and I had forgotten to remove mention of it from the readme. It only every functioned as a CLI capture tool where you could run it to get user input that would then be written to a file stored somewhere on the users local system.
I'm not really familiar with vim plugins as all but in theory there is nothing to stop you you calling the script with some contextual arguments to parse the current file. (I assume!)
I'm not sure. I would definitely think it is possible in future but the upload does not store any metadata about where the files came from.  It would be similar to an "Export Deck" feature another user has actually requested. It would be doable I think but I'm really not sure on the time scale of when I might get such a thing done.
I think the next big change on the backlog will be to allow users to sync rather then just update. So that changes in files are reflected in the users' decks

Please feel free to follow #65 for updates on when the sync behavior will be implemented!


Now Playing Icon does not stop bouncing

How to reproduce
Steps to reproduce the behavior:
1. open Music app
2. Play a song
3. quit Music App
4. See error

Expected behavior
Now Playing Icon stops bouncing
Screenshots

Versions:

macOS version: [10.15.2]
Pock version:  [0.7.1]

I can't replicate this issue. Can you please try if this also occurs with other music apps (like Spotify)?

Only with Music.
I tried Netease Music, this didn’t happen.
My setting:

uncheck “ hide when not playing”
widget style only info

I found the issue! A fix is coming. 🎉


is #65 the solution to all of the universes problems?

I love you guys, don't hate me!

:+1:
#65 is the big elephant in the room, hopefully after that we can focus on incremental updates.


Suggestions for graceful shutdown branch

a few small things I saw while reviewing #5193

I'm not sure I want to apply your changes to TabletServer.java. I can apply the others if you want to update this PR.


[Release] Training Operator 1.8 Roadmap

This is the tracking issue for Training Operator 1.8 release.
The feature freeze date for the next Kubeflow 1.9 release is April 15th.
We are targeting the following features for Training Operator 1.8:
SDK

[ ] Train/Fine-Tune API for LLMs
[x] Unit tests for SDKs: https://github.com/kubeflow/training-operator/pull/1938
[x] Consolidate SDK APIs: https://github.com/kubeflow/training-operator/issues/1877
[x] Fetch Job and Pod events: https://github.com/kubeflow/training-operator/issues/1863
[x] Set compute resources: https://github.com/kubeflow/training-operator/pull/1990

Backend

[ ] Support v1.26-v1.28 Kubernetes version.
[ ] Deprecation notice for MXJob: https://github.com/kubeflow/training-operator/issues/1996

Misc

[ ] Improve docs for Training Operator.
[ ] Update contributor guide.
[x] Example for torchrun and PyTorchJob: https://github.com/kubeflow/training-operator/pull/1965

@deepanker13 @droctothorpe @tenzen-y @kubeflow/wg-training-leads @kuizhiqing @terrytangyuan @lowang-bh Please let me know items that we want to add for Training Operator 1.8.
cc @kubeflow/release-team

@johnugeorge @deepanker13 Do we need to create tracking issue with remaining items for Train/Fine-tune API for LLMs ?

I'd like to get https://github.com/kubeflow/training-operator/pull/1953 merged as well

@andreyvelich  thanks for putting this together. On the "Misc: Improve docs for the training operator", if you can start a seprate issue highligintg known issues, doc areas to be improved or particular topics you want to address we can start coordinating with the release team doc leads as well to get some help.
I would suggest having a separate issue for autogen APIs, in case you want to address that as well.

@terrytangyuan Sure, can we discuss the MXJob deprecation plan on the next AutoML and Training WG meeting ?
I think, it would be better if we are going to remove support for MXJob in 2 releases. For example, in 1.8 release we are going to inform users that MXJob will be removed in the next version. And when we release 1.9 we will remove MXJob.
That should give sufficient time for users to migrate even that MXNet has already been archived.
WDYT @kubeflow/wg-training-leads @tenzen-y  ?

if you can start a seprate issue highligintg known issues

@StefanoFioravanzo Sure, I will create an issue based on tasks that we discuss on the last call.
Also, I will create issue for SDK doc autogen.

First of all, as I mentioned here: https://github.com/kubeflow/katib/issues/2255#issuecomment-1910584792, I would suggest supporting kubernetes v1.27-v1.29.
Also, Moving #1906 forward would be better. It probably isn't possible to complete all the tasks, but I think we will be able to get some results.

I think, it would be better if we are going to remove support for MXJob in 2 releases. For example, in 1.8 release we are going to inform users that MXJob will be removed in the next version. And when we release 1.9 we will remove MXJob.
That should give sufficient time for users to migrate even that MXNet has already been archived.
WDYT @kubeflow/wg-training-leads @tenzen-y ?

SGTM. We can say that we don't any maintenance for MXJob during one release, which means it was deprecated.
Maybe, creating dedicated issue would be better.

First of all, as I mentioned here: https://github.com/kubeflow/katib/issues/2255#issuecomment-1910584792, I would suggest supporting kubernetes v1.27-v1.29.

It's good point about Kubernetes version @tenzen-y!
I agree that 1.27 - 1.29 should be our target.
@kubeflow/release-team What do you think about target goal of supporting Kubernetes 1.27 - 1.29 for Kubeflow 1.9 release?

Ah, I found the features that we drop from the previous release due to the release deadline.
Can we put the following to improve UX:

https://github.com/kubeflow/training-operator/issues/1993
https://github.com/kubeflow/training-operator/issues/1708

I just had discussion with @kubeflow/release-managers on Kubernetes versions.
We are going to target Kubernetes 1.27 - 1.29 for the next release of Training Operator.

I just had discussion with @kubeflow/release-managers on Kubernetes versions. We are going to target Kubernetes 1.27 - 1.29 for the next release of Training Operator.

It's nice notifications! Thank you!

@johnugeorge @deepanker13 Do we need to create tracking issue with remaining items for Train/Fine-tune API for LLMs ?

Okay I will create one

Hello @kubeflow/wg-training-leads, this is a kind reminder that Monday, March 4th will be our Kubeflow 1.9 release development checkpoint, we will be halfway through our dev cycle, and we expect most of the work to be well underway.
Can you please acknowledge your status with respect to your roadmap, comment on the progress made so far, and provide an assessment of the work that remains?
(understandably) Not everything may be completed in time. Please proactively let the release team know if there are delays, blockers, or uncertain situations, know so that we can align expectations and try and help you out, if possible.

Hi ! When is the v1.8 is planned for release? Some managed k8s versions e.g EKS reach end of support very soon. (July 24, 2024) https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar
Is there any tentative timeline ? Please advise.

Hi @satishpasumarthi, we are planing to make the first RC.0 for Training Operator v1.8 this week.
We will support Kubernetes v1.27-1.29 in that release.

Hi @satishpasumarthi, we are planing to make the first RC.0 for Training Operator v1.8 this week. We will support Kubernetes v1.27-1.29 in that release.

Thanks for the reply @andreyvelich . I see only PRs for supporting v1.28 and v1.29 https://github.com/kubeflow/training-operator/pull/2039 and https://github.com/kubeflow/training-operator/pull/2038. My understanding was v1.27 is already supported in v1.7. Please correct me if I am mistaken

Hi @satishpasumarthi, we are planing to make the first RC.0 for Training Operator v1.8 this week. We will support Kubernetes v1.27-1.29 in that release.

Thanks for the reply @andreyvelich . I see only PRs for supporting v1.28 and v1.29 #2039 and #2038. My understanding was v1.27 is already supported in v1.7. Please correct me if I am mistaken

@satishpasumarthi You're correct.
In v1.7, the training-operator supports v1.25-v1.27. In v1.8, the training-operator will support v1.27-v1.29.

Is there anything missing to cut the release? We want to start the manifests sync for training-operator for Kubeflow 1.9.0-rc0

Is there anything missing to cut the release? We want to start the manifests sync for training-operator for Kubeflow 1.9.0-rc0

Not yet. Johnu will prepare the release today.

Any chance we can see a release?

Any updates on when we might see a new release?

You can find the new release here: https://github.com/kubeflow/training-operator/releases/tag/v1.8.0-rc.0


make databags optional

Just as the title says - I have a lot of complexity in my wrapper cookbook, which includes pulling from Chef Vault for instance. Because of this, I'd like to be able to provide attributes myself without having to clutter up my env with a ton of databag items.
Thanks!

Ok, i checked all checks, and nothing very important failed. I will correct all erros after the merge


fix: upgrading the Tailwind version

Description
This PR targets upgrading the tailwind CSS version of the repository. Presently, this PR is drafted in order to add the present styles of the website.
Note - All the config files are made from scratch so if I miss anything, kindly inform me in the PR so that it can be discussed and added in the upcoming commits.
Related issue(s)
Fixes #782

Hey @magicmatatjahu,  I was adding the colors and theme to the tailwind.config.js and noticed some bugs in it. The classes are not getting overlapped with each other. Do read the following issues and tell us then what we need to change:

https://stackoverflow.com/questions/1321692/how-to-specify-the-order-of-css-classes
https://github.com/tailwindlabs/tailwindcss/issues/1452

Hey! Looking over this real quick and I think I am spotting the issues. I'm getting towards the end of my day today and will look at this tomorrow with fresh eyes and compare to the old tailwind config file and make sure all the utilities are there so no styles get broken. I'll let you know what I find! 🔍

Thank you @akshatnema, I was able to get it running using v14. Is it okay if I make some fixes and push commits here?

Yeah @mcturco , go ahead 🚀

@akshatnema Oh actually, I don't have permissions to push commits to PRs in this repo. Are you able to grant me the permissions on your PR?

@mcturco You must be a maintainer here too :sweat_smile:, it will be then very helpful to you as well as contributors to go with the review.
I have added you as a contributor in my forked repo. Kindly accept the invitation,  it will be in your mail.

@akshatnema Thank you! I just added some commits that fixed the errors. There was a typo in the JSON within tailwind.config.js that was causing some of the utilities to not get added in properly.
I additionally made some changes to the typography components that better suits the new tailwind version updates.
I quickly looked through the site after these changes were made and didn't see any other issues, but perhaps another set of eyes and another round of checks would be great.

Thanks, @mcturco for correcting the config and making the changes in the PR.
Yeah, the preview looks fine to me. I can't see more errors there. Can we move this PR to 'Ready for review'?

@akshatnema No problem. And yup, let's do it!

@magicmatatjahu @derberg the PR is ready for review. I want to add one point here. The changes made in the package-lock.json file are not coinciding with package.json file. This is because there are a lot of issues with installing node_modules in Node v17.8.0 and running the the website in Node v14.19.3. So, it's better if we merge PR #749 first and then move on to this PR to get merged. What's your view on this?

@magicmatatjahu I corrected those components but we have a bigger problem now. Algolia Search is not getting correct CSS from the CDN and hence, all the internal elements of Algolia isn't getting right properties. Please have a look into it and correct the configuration accordingly.

@derberg @mcturco When @akshatnema hasn't available, I switch to his branch and fixed some issues (including also Twitter problem with auto height). If you will have free time, could you check the styles in this PR looking on styles from hosted www.asyncapi.com to check any differences? I managed to fix a lot of bugs but maybe I missed one. Thanks!

I compared side by side multiple views on desktop and also in iPhone emulation and could not find a single issue that I could point out 👏🏼

/rtm

I think this PR has to be merged manually. I can see that in merge commit, there is no mention of @mcturco and @magicmatatjahu, but anyways,  huge thanks to @magicmatatjahu for solving these errors. There were many UI and CSS errors, but you corrected them very effectively.


Expand and implement Property Revealer

Expand and implement an existing mod (iguana_PropertyRevealer).
Some properties are hidden, but are still useful to know for the player, like Qi Absorption Speed Bonus. This would reveal those properties, and properly categorize them.

An addition, properties directly influenced by the Base Stats, to avoid making sense of the hexagonal spread.


issue #860 in original library

Merging the PR #860 to this fork of the original library.

Explained above.


Add linshokaku to code owners

Welcoming @linshokaku to the code owner of PPE!

Confiremd:

This CODEOWNERS file is valid.


A tests: key of None/Null at the model level fails parsing validation in 1.7, but didn't in 1.4

An empty tests: key in the model shema YAML file throws a parsing error in 1.7+, when it is working or ignored in 1.4 (core especially)
Why does this matter?  I have customer looking to migrate from 1.4 core/cloud to 1.7, and we had to painfully work through the parse and reparse to find each error, because the parser dies on these errors. (Find one and die, fix, full parse, find next and die).
Sample:
version: 2

models:
    - name: my_first_dbt_model
      description: "A starter dbt model"
      tests:
      columns:
          - name: id
            description: "The primary key for this table"
            tests:
                - unique
                - not_null

The tests: key under description: is the problem.
Error message:
Parsing Error
  Invalid models config given in models/example/schema.yml @ models: {'name': 'my_first_dbt_model', 'description': 'A starter dbt model', 'tests': None, 'columns': [{'name': 'id', 'description': 'The primary key for this table', 'tests': ['unique', 'not_null']}], 'original_file_path': 'models/example/schema.yml', 'yaml_key': 'models', 'package_name': 'my_new_project'} - at path ['tests']: None is not of type 'array'
23:08:09 Parsing Error
  Invalid models config given in models/example/schema.yml @ models: {'name': 'my_first_dbt_model', 'description': 'A starter dbt model', 'tests': None, 'columns': [{'name': 'id', 'description': 'The primary key for this table', 'tests': ['unique', 'not_null']}], 'original_file_path': 'models/example/schema.yml', 'yaml_key': 'models', 'package_name': 'my_new_project'} - at path ['tests']: None is not of type 'array'

@jtcohen6 @dbeatty10 - Is this syntax actually still "pointless" but valid?  We are throwing a pretty hard parser error here as part of a version upgrade path..

@will-sargent-dbtlabs I'm going to move this to the dbt core repo - the Parsing Error you're seeing here is not being returned from the JSON Schema validation (which is informative only) but from core itself.


Is it possible to add ignored directories and files to update_code task?

Is it possible to add ignored directories and files to update_code task? I know I can use rsync, but I'm having trouble getting it to work. And I prefer to to use git… but I need to exclude the a few folders, but I want them in my git repo; ie SASS and Src JS files etc?

Since deployer is using git clone, you can try to use .gitattributes or just delete dirs after update_code.

I am cleaning up on issues. Fill free to reopen if needed.
Also, we have a new section available: discussions.


Fixer.io provider

https://business-factory.github.io/docs/tasks/python/fixer-io-currency-provider

@business-factory/pythonistas I refactored the provider a bit, please take a look :-)

I can see that response from https://api.fixer.io/2017-09-22?base=USD looks like this
{
    "base": "USD",
    "date": "2017-09-21",
    "rates": {
        "AUD": 1.2601,
        "...": 1.6428,
    }
}

That means that this API may return rates for another day "date": "2017-09-21" as requested 2017-09-22. @martinvy @harpener Do you think it's OK and it will be overwritten next day or we should somehow check it?

@martinvy @harpener  Yes, when I run the command with clean DB everything is fine, but when I run the command second time I get a lot of errors like this:
[WARNING] 2017-09-26 08:54:12 at dao_exchange_rate.py:26 (MainProcess) -- Session rollback. Error: (psycopg2.IntegrityError) duplicate key value violates unique constraint "USD_exchange_rates_date_provider_id_currency_key"
DETAIL:  Key (date, provider_id, currency)=(2017-09-24, 2, HKD) already exists.
[SQL: 'INSERT INTO "USD_exchange_rates" (date, provider_id, currency, rate) VALUES (%(date)s, %(provider_id)s, %(currency)s, %(rate)s) RETURNING "USD_exchange_rates".id'] [parameters: {'rate': Decimal('7.8121039999999997149870978319086134433746337890625'), 'currency': 'HKD', 'provider_id': 2, 'date': datetime.date(2017, 9, 24)}]. Record {'provider_id': 2, 'rate': Decimal('7.8121039999999997149870978319086134433746337890625'), 'date': datetime.date(2017, 9, 24), 'currency': 'HKD'}

@miso-belica well, that's not quite an issue, but the UX could be better :) The error refers to inserting of duplicated exchange rate, but the duplicates are only logged and then skipped and all other rates are correctly inserted.


SubjectBase

I notice that SubjectBase has been added (though it's not yet available in any release) however it only defines abstract methods, which is kinda useless. It would be good if it also handled the low-level plumbing with ImmutableList etc.

Especially as Rx's ImmutableList is internal, so we either need to take a dependency on Immutable Collections, or copy Rx's ImmutableList into our code.

@grokys is this still something you're interested in?

Yeah, it's definitely something that would be useful!

@grokys ok cool, let's tease this stuff out:

what would you like to see changed with SubjectBase? For reference, it's mostly being used as a base class, and I get the feeling that's why it's necessary to make public:

do you think we should adopt ImmutableList internally and remove that code? That feels better for the overall ecosystem, rather than making Yet Another Implementation public and encouraging more fragmentation...

Here's a rough PR which migrates our usage of the internal ImmutableList over to use the System.Collections.Immutable version - much easier than I anticipated...

Definitely a 👍 to using the external ImmutableList now and removing our impl now that we can.

We have to be careful with swapping those, see https://github.com/Reactive-Extensions/Rx.NET/pull/222#issuecomment-231825104

Ok, it seems that the use-case I was thinking of when I created this issue is no longer relevant, but I can explain what I was thinking:
The problem was that the ImmutableList impl in Rx was private so that to create my own subject I would've had to add a new dependency that I didn't previously have. Moving to System.Collections.Immutable would of course make that no longer true.
However, there's a lot of commonality to the implementations of OnNext/OnError/OnCompleted in the different subject implementations, which could maybe be exposed, but I think the recently added Subject.Create method should make creating a new new subject less common; so probably not worth messing with this.
Closing this for now.


onClick Watch, see in terminal TypeError: Cannot read property 'length' of undefined

onClick Watch, I see in terminal TypeError: Cannot read property 'length' of undefined
Is this a bug report or a feature request?
bug report
Version Info

Version of Majestic: v1.2.23
Version of Jest:  23.6.0
Version of Node: v8.11.3
Operating System: macOs 10.14.4

Reproduction Repo
repro repo coming soon 🤞
$ npx majestic
npx: installed 29 in 1.974s
⚡  Majestic v1.2.23 is running at http://localhost:4000
/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:33749
    this.length = input.length;
                        ^

TypeError: Cannot read property 'length' of undefined
    at State.init (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:33749:25)
    at new Tokenizer (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:33806:16)
    at new UtilParser (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:34913:1)
    at new NodeUtils (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:35048:1)
    at new LValParser (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:35086:1)
    at new ExpressionParser (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:35410:1)
    at new StatementParser (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:37022:1)
    at new Parser (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:38494:5)
    at new <anonymous> (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:33023:26)
    at new <anonymous> (/Users/m/.npm/_npx/23768/lib/node_modules/majestic/dist/server/index.js:30585:5)

Unfortunately, this error alone doesn't explain much. Would you be able to reproduce this in a minimal example, please?

I got this error too. The different is I did not click on watch.
The error occur occasionally.
Happend in v1.2.23 and v1.3.

@ziofat Does the error breaks majestic and makes in not usable?

@Raathigesh Yes it does. The process exited with non-zero code and the buttons in web UI did not respond to any clicks.

It looks like the babel parser is failing to parse. Will take a look.

When there are syntax errors, we handle it better in version 1.4.
I'm closing it for the time being but feel free to reopen it the issue is not resolved.


[matmul] Investgate better software pipelining

Right now we have a pretty straightforward shared memory prefetch pipeline. We need to investigate if there are more advanced software pipelining techniques that can help to improve matmul performance.

Related: https://github.com/nod-ai/playbook/issues/58

Closing to dedupe with https://github.com/nod-ai/playbook/issues/58


Support for optgroups

What it says on the tin.  I chose not to support django forms API (where the choices are interpreted differently if the values are lists or tuples), even so it leads to pretty callsites.
In practice I found the proposed API more eh practical ;-)
Existing test cases pass and the adjusted form kitchen sink does what you expect.
BUT note the comment on the existing choice_tuples method.

Codecov Report

Merging #73 into master will decrease coverage by 0.14%.
The diff coverage is 38.09%.

@@            Coverage Diff             @@
##           master      #73      +/-   ##
==========================================
- Coverage   99.10%   98.96%   -0.15%
==========================================
  Files          64       64
  Lines        8346     8367      +21
==========================================
+ Hits         8271     8280       +9
- Misses         75       87      +12

Impacted Files
Coverage Δ

iommi/form.py
97.34% <38.09%> (-1.71%)
:arrow_down:

iommi/table__tests.py
100.00% <0.00%> (ø)

iommi/table.py
98.65% <0.00%> (+0.12%)
:arrow_up:

Continue to review full report at Codecov.

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


Replace OS variables fails

Rebar3 will fail if RELX_REPLACE_OS_VARS=true and in sys.config you have unquoted variables like
{http_port, ${HTTP_PORT}},

where http_port is being replaced with an integer (or an atom but atoms can be quoted to let the script not fail). The error that I get is:
===> The config file (/../sys.config) specified for this release could not be opened or parsed: 40: syntax error before: HTTP_PORT

I am told this is not fixable under current OTP rules for reading these files. As such I will have to close this as wontfix as there is no reasonable way for us to handle this.

This used to work in pre-beta4 releases. It just broke somehow. I can try to find the commit that changed things.

Are you sure about that? If you can find a time it worked I'd be interested. It shouldn't have.

Yes it used to work perfectly!

In sys.config? It works fine in vm.args.

I just verified tag 3.0.0-beta.3 works with both sys.config and vm.args

Ah, yup https://github.com/erlware/relx/commit/1cde722a7ce0760c723680414cc4af653ab8b260
But, does rebar3 tar work with it in beta.3? I really thought it only half worked before I made this change, so made it consistent throughout.

I'm not trying to generate a tar, just a simple development release.

I know, but can you check if it works with rebar3 tar?

No it doesn't :/

Yea, that is what I thought :(. Which makes it a bad feature to half support. Users will think it works up to the point they want to make a tarball and it fails -- due to systools consulting the file, not relx or rebar3. With the recent change I make sure when the release is first built that it checks so that this disconnect doesn't happen.

But why don't you pass the sys.config/vm.args file through the filter, replace the variables and then consult it so that neither release not tar fail?

It is a runtime feature, if we did that then the tarball would be static after creation and it wouldn't be useable when deployed.

So basically the feature is useless unless you don't use non-string and non-atom values or you convert to integer when reading the environment.

Right, or put them in vm.args since you can do -<appname> http_port ${HTTP_PORT} in there just fine.

Alright, this sounds like a legit workaround


Create SoundCloud block

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #178
Test URLs:

Before: https://main--mammotome--hlxsites.hlx.page/us/en/about-us/news-media-category/mammotome-one-voice
After: https://178-soundcloud--mammotome--hlxsites.hlx.page/us/en/about-us/news-media-category/mammotome-one-voice

added doc to https://github.com/hlxsites/mammotome/pull/180


ngrok: expose oauth client id/secret setters

Fixes #68

Current dependencies on/for this PR:

main

PR #72   👈

This comment was auto-generated by Graphite.


feat: supports collision filtering

I implemented a group method similar to box2d collision filtering that uses only bit operations, ensuring minimal performance impact. The stress demo has also been updated for observing the results.
I'll be using this functionality but unsure if others will also need it ~

I didn't include dist / docs in the commit due to potential conflicts with multiple PRs, but I'm unsure if it's more convenient for you.

@noih published https://github.com/Prozi/detect-collisions/releases/tag/v9.6.0


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>Major Changes

b137fa2: Initial release.
Extract from resolve.imports.

<EMAIL_ADDRESS>Patch Changes

b137fa2: Extract patternKeyCompare to pattern-key-compare package.

71f87b3: Add ts folder to distribution.
It is needed for declarationMap to work.
Remove extra typing files in cjs folder.

Updated dependencies [b137fa2]

<EMAIL_ADDRESS>

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (4f4382c) compared to base (b137fa2).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           27        27
  Branches        13        13
=========================================
  Hits            27        27

Flag
Coverage Δ

resolve.imports
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


FLUME-3360 Fix assemble failed on macOS

https://issues.apache.org/jira/browse/FLUME-3360

Thanks for the patch!


Torch 1.11 pytorch_vision Docker image

Add Torch 1.11 image to pytorch_vision Docker image build matrix

Thanks for this!
Would it be possible to update the mmcv version on the line here to 1.4.8? I believe this is the only version of mmcv that has precompiled packages for pytorch 1.11. Maybe the best thing would be to specify the MMCV version as a variable and set it to 1.4.8 for this tag

Yea sure I'll just make MMCV_VERSION an argument for the Dockerfile.


cli: Handle no npm info

Hey, I just made a Pull Request!
Solves the problem when no npm package info is found during backstage-cli versions:bump.
How
This PR handles empty response from yarn info used by backstage-cli versions:bump. Empty responses now throws a not found exception and is handled by ignoring the package bump and prints a message that the package is ignored due to package info not found.
Note that all empty stdout from yarn info will be handled the same way regardless of stderr. Please feedback if this is ok or not.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)

Thanks for the feedback 👍  now updated

Thanks for the feedback 👍  now updated

@ahrberg The build error is due to a temporary breakage in master - please just rebase on latest master, and you should be good to go

@ahrberg The build error is due to a temporary breakage in master - please just rebase on latest master, and you should be good to go

and now there's an unused import to remove :) ssoooo clooooose!

and now there's an unused import to remove :) ssoooo clooooose!


Integrate react-native-dotenv

Why?
It is very important to separate secrets from your source code. Secrets are API keys or any sort of keys that you would not want to disclose along with the source code as they might provide access to your database, may be used to fetch other more important credentials, etc. Instead, you just share the source code while allowing other people to create their own .env file.
Include the following packages and go through the documentation

react-native-dotenv

Setup a temp environment variable and log it in ShowScreen
Gist of sets

include react-native-dotenv
create a .env file in the root of the project and add a temp variable to it of your choice ( also make sure you add this file to .gitignore )
import the variable using react-native-dotenv module
log the variable

Hi , I am trying to include react-native-dotenv to my project . As written in its doc, it is said i need to add some presets to .babelrc file in my root directory . I dont have a .babelrc file in my project root dir . I do have babel-config file though .Should i just go ahead and make the changes in that file ? (Also i have also babel-preset-react-native)

Hi , I am trying to include react-native-dotenv to my project . As written in its doc, it is said i need to add some presets to .babelrc file in my root directory . I dont have a .babelrc file in my project root dir . I do have babel-config file though .Should i just go ahead and make the changes in that file ? (Also i have also babel-preset-react-native)

Hey @agnivabasak, yes you can add those presets to your babel-config.js file ( both .babelrc and babel-config do the same thing ).
Also here is a screenshot of one of my babel.config.js files, yours may look different but this is how you need to add the preset


Update README.md

Amazing resource for all IT businesses.

Closing due to inactivity.
Please open a new PR with a reference to this one if you can follow up with more information.


Configuration?

What's the correct configuration?
I'musing like this in bootstrap/app.php, but it doesn't works
use Illuminate\Foundation\Configuration\Middleware;

/*
|--------------------------------------------------------------------------
| Create The Application
|--------------------------------------------------------------------------
|
| The first thing we will do is create a new Laravel application instance
| which serves as the "glue" for all the components of Laravel, and is
| the IoC container for the system binding all of the various parts.
|
*/

$app = new Illuminate\Foundation\Application(
    $_ENV['APP_BASE_PATH'] ?? dirname(__DIR__)
);

/*
|--------------------------------------------------------------------------
| Bind Important Interfaces
|--------------------------------------------------------------------------
|
| Next, we need to bind some important interfaces into the container so
| we will be able to resolve them when needed. The kernels serve the
| incoming requests to this application from both the web and CLI.
|
*/

$app->singleton(
    Illuminate\Contracts\Http\Kernel::class,
    App\Http\Kernel::class
);

$app->singleton(
    Illuminate\Contracts\Console\Kernel::class,
    App\Console\Kernel::class
);

$app->singleton(
    Illuminate\Contracts\Debug\ExceptionHandler::class,
    App\Exceptions\Handler::class
);

$app->withMiddleware(function (Middleware $middleware) {
    $middleware->replace(
        \Illuminate\Http\Middleware\TrustProxies::class,
        \Monicahq\Cloudflare\Http\Middleware\TrustProxies::class
    );
});

/*
|--------------------------------------------------------------------------
| Return The Application
|--------------------------------------------------------------------------
|
| This script returns the application instance. The instance is given to
| the calling script so we can separate the building of the instances
| from the actual running of the application and sending responses.
|
*/

return $app;

Sorry, my error, i've updated from laravel 10 to 11 and my bootstrap is different.


Update README.md

Fixing missing triple quote

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


Handle edited commands

If the bot is invoked by a Discord message with an invalid syntax it correctly responds with an error.
If that command is then edited to be correct nothing changes in Discord, either the bot doesn't receive the updated command or doesn't handle or respond to it correctly.

Resolved in v0.2.0.


Rename createDefault selector to newDefault

Two occurrences:
https://github.com/pharo-contributions/taskit/blob/a2c520791918c2a34b2fdb85f500bdd2f02b35f6/TaskIt/TKTCommonQueueWorkerPool.class.st#L21
https://github.com/pharo-contributions/taskit/blob/a2c520791918c2a34b2fdb85f500bdd2f02b35f6/TaskIt/TKTWorker.class.st#L41

There are more more to rename:
(SystemNavigation default allMethods
	select: [ :each | each package name beginsWith: 'TaskIt' ])
	select: [ :each | each selector beginsWith: 'create' ]

"
- TKTCommonQueueWorkerPool class>>#createDefault
- TKTPharoProcessProvider>>#createProcessDoing:named:
- TKTPharoProcessProvider>>#createProcessDoing:
- TKTProcessProvider>>#createProcessDoing:named:
- TKTProcessProvider>>#createProcessDoing:
- TKTProcessProvider class>>#createProcessDoing:named:
- TKTProcessProvider class>>#createProcessDoing:
- TKTWorker class>>#createDefault)
"


Support --function as a generator option

Syntax will be nx g @simondotm/nx-firebase:function <name> --project=<projectname> [--alias=<projectname>] [--directory=<dir>]
It will generate an application which is:

based on @nrwl/node:webpack, so that the code is fully
linked to project <projectname>
added to the firebase.json config file functions array for that project
assigned a codebase with the <projectname>
it will be separately buildable and deployable
it will have its own deploy target, which will deploy only this codebase

function applications will only work with Firebase CLI v10.7.1 and above.

This neatly solves a number of other issues:

Watched builds not building dependencies, webpack bundles everything from source
Makes it easier to create libraries without worrying about cold start times

However, a major caveat is:

Bundled functions include everything and this does not help cold starts
The solution for this is to split functions into multiple apps (maybe even 1 function per app) and use codebase
But, doing that, it's not clear just now how we'd watch multiple function projects for emulation

Possibly we can add function projects as implicit dependencies of the main firebase application. Then nx watch will work.

Implemented in #116


Zone can be specified for volume adjustments

This small change makes it possible to specify the zone as an optional argument to the volumeUp/volumeDown/adjustVolume methods.

Thanks!


OpenAPI Provider

What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds new openapi provider.
Which issue(s) this PR fixes:
Closes #147
Does this PR introduce a user-facing change?:
- New OpenAPI Provider

Try this PR out:
make build
./ingress2gateway print --providers openapi3 --input-file=pkg/i2gw/providers/openapi3/fixtures/input/1-petstore3.yaml

@arkodg @youngnick @LiorLieberman et al
Sharing this as a draft for some initial feedback.
Quite a few TODOs ahead still, including:

[ ] backendRefs
[ ] Gateways and parentRefs
[ ] input with multiple OAS docs → Fix route names/namespaces

Apart from more testing of course.
Please check out the test cases already covered under providers/openapi/fixtures.

I want to mark this as ready for review, but not before coming to a decision about how to proceed for backendRefs and gatewayClassName.
It was suggested to use command-line args for those. I would like to know how people feel about that?
A few questions to drive the conversation next should we say this indeed is the desired approach:

Should I just define those as flags of the print command?
Since they don't have meaning for other providers converting from Ingress resources, will providers like istio, ingress-nginx, kong, etc ignore the values when supplied?
Perhaps call those options --default-backend-name and --default-gateway-controller-name?
Or they could be namespaced specifically for this provider – e.g. --openapi3-bakcend-name and  --openapi3-gateway-controller-name – tho I can see a possible mess in the future should other providers ask for other similar options. If it is provider-specific, should the options be required when --providers includes openapi3 and forbidden otherwise?
Provider-specific options could also be serialised into a single command-line flag (e.g. --provider-options "backend-name=x,controller-name=y")
Is it starting to get a little bit too much to pass in the call to ToGatewayAPIResources? Should we change the API to accept a more generic PrintOptions type?

cc @youngnick @arkodg @LiorLieberman

/cc @arkodg

I want to mark this as ready for review, but not before coming to a decision about how to proceed for backendRefs and gatewayClassName.
It was suggested to use command-line args for those. I would like to know how people feel about that?
A few questions to drive the conversation next should we say this indeed is the desired approach:

Should I just define those as flags of the print command?
Since they don't have meaning for other providers converting from Ingress resources, will providers like istio, ingress-nginx, kong, etc ignore the values when supplied?
Perhaps call those options --default-backend-name and --default-gateway-controller-name?
Or they could be namespaced specifically for this provider – e.g. --openapi3-bakcend-name and  --openapi3-gateway-controller-name – tho I can see a possible mess in the future should other providers ask for other similar options. If it is provider-specific, should the options be required when --providers includes openapi3 and forbidden otherwise?

+1 on this approach. having access to generic --default-backend-name, --default-gateway-controller-name flags might be confusing for users. I'd prefer having openapi3--prefixed command line flags to avoid such a confusion. openapi is a special case, and I do cannot think of many other such special cases in the future

Provider-specific options could also be serialised into a single command-line flag (e.g. --provider-options "backend-name=x,controller-name=y")
Is it starting to get a little bit too much to pass in the call to ToGatewayAPIResources? Should we change the API to accept a more generic PrintOptions type?

+1 on introducing a PrintOptions struct to pass all the needed parameters.

hey reg naming, i'd vote for

<openapi provider prefix>-backend - openapi provider specific CLI arg
gatewayc-controller - common to the entire CLI arg

Where I wrote controller-name please read gateway-class-name, since obviously we're talking about generating Gateways, not GatewayClasses. Apologies for my distraction before.

I was feeling somewhat uncomfortable with hard-coding provider-specific CLI flags when there's already a mechanism in place to register providers more dynamically. So please let me know what you think about https://github.com/kubernetes-sigs/ingress2gateway/pull/157/commits/12dd6a09cceb21f537a2c134e01d64f012665630.
I'm proposing a function to declare and a method to retrieve those provider-specific user input values, that keeps the common implementation clean from it. Explanation and example provided in PROVIDER.md.
I'm using the method to register --openapi3-backend and --openapi3-gateway-class-name both as specific to the openapi3 provider. Example of how the flags will show in command help:
$ ./ingress2gateway print --help
Prints Gateway API objects generated from ingress and provider-specific resources.

Usage:
  ingress2gateway print [flags]

Flags:
  -A, --all-namespaces                       If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even
                                             if specified with --namespace.
  -h, --help                                 help for print
      --input-file string                    Path to the manifest file. When set, the tool will read ingresses from the file instead of reading from the cluster. Supported files are yaml and json.
  -n, --namespace string                     If present, the namespace scope for this CLI request.
      --openapi3-backend string              Provider-specific: openapi3. The name of the backend service to use in the HTTPRoutes
      --openapi3-gateway-class-name string   Provider-specific: openapi3. The name of the gateway class to use in the Gateways
  -o, --output string                        Output format. One of: (json, yaml). (default "yaml")
      --providers strings                    If present, the tool will try to convert only resources related to the specified providers, supported values are [apisix ingress-nginx istio kong openapi3]. (default [apisix,ingress-nginx,istio,kong,openapi3])

Global Flags:
      --kubeconfig string   The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@arkodg, if you think gateway-class-name is useful to all providers, I'm happy to hard-code this one as we normally would and remove it from openapi3-specific, even if for now only openapi3 will be doing something with it.

@guicassolato no strong feelings, the project maintainers have a much better understand of naming and should decide

@guicassolato no strong feelings, the project maintainers have a much better understand of naming and should decide

cc @LiorLieberman @mlavacca

Thanks again for driving this Gui!
Regarding gateway-class-name I hear you, I think what we ultimately want to do is to have IR (intermediate representation) and have --input-provider and --output-provider. Each provider would implement old config --> IR and IR --> Gateway configs (+gateway extensions). That at least what @arkodg and I discussed at KubeCon.
If we do plan move on to this logic, I think gateway-class-name will be derived from the --output-provider flag.
Since we dont support it now, an nor gateway extensions are supported, I am trying to think whether it will indeed be useful for other providers. The more I think about it - I get to the conclusion that we must move to input and output providers separately. So I'd vote leaving gateway-class-name  prefixed
Regarding the backend flag - still not sure how you were going to represent it in a flag value? A formatted string with name,ns,port? (not loving this either)
About the general approach of registering provider specific flags dynamically. I like it but trying to think what are the use-cases for other providers.
We have to ask ourselves how different the openapi provider from all other providers PLUS how much of the logic is similar, maybe we want to have a subcommand for openapi which will make things simpler? not saying we should but just throwing it some thought
Lastly I left a few random comments on https://github.com/kubernetes-sigs/ingress2gateway/commit/12dd6a09cceb21f537a2c134e01d64f012665630.
Thats really awesome, thanks again!

Hi @LiorLieberman. Thank you so much for taking the time to review this.
It turns out the biggest effort here has not been converting OAS to Gateway API per se, but the details... where, as we all know, lives the Devil. The PR has grown bigger and I still hope to be able to deliver valuable contribution with it.
A few comments in line...

Thanks again for driving this Gui! Regarding gateway-class-name I hear you, I think what we ultimately want to do is to have IR (intermediate representation) and have --input-provider and --output-provider. Each provider would implement old config --> IR and IR --> Gateway configs (+gateway extensions). That at least what @arkodg and I discussed at KubeCon.

I like the idea of IR. Of course, that only works if the abstraction in the middle is capable of absorbing all the complexity from all possible inputs/"old configs". In fact, the main reason why I didn't use Ingress as IR – and therefore do OAS -> Ingress -> Gateway API, relying on the standard ("common") conversion functions – was not being able to support capabilities that exist in the old config (OAS, in this case) but not in the IR, such as header and query matchers.
To be completely honest, I also wanted to avoid generating invalid HTTPRoutes with more rules or more matches per rule than it can take, without introducing breaking changes to existing providers. To give an example, even the Swagger Petstore API would activate this problem.
I believe a straight OAS -> Gateway API conversion for now allowed me solving both issues: capabilities and conformance.

If we do plan move on to this logic, I think gateway-class-name will be derived from the --output-provider flag.

Yes, I can see how that could work for gateway-class-name.

Since we dont support it now, an nor gateway extensions are supported, I am trying to think whether it will indeed be useful for other providers. The more I think about it - I get to the conclusion that we must move to input and output providers separately. So I'd vote leaving gateway-class-name prefixed

So, to be clear then, you're aligned with @mlavacca and with how I ended up implementing it, i.e. openapi3-gateway-class-name?

Regarding the backend flag - still not sure how you were going to represent it in a flag value? A formatted string with name,ns,port? (not loving this either)

Currently, it's namespace/name, no support for port number. We could instead establish a convention to use $SERVICE.$NAMESPACE.svc.cluster.local:$PORT, for example. Would that be preferable?

About the general approach of registering provider specific flags dynamically. I like it but trying to think what are the use-cases for other providers. We have to ask ourselves how different the openapi provider from all other providers PLUS how much of the logic is similar, maybe we want to have a subcommand for openapi which will make things simpler? not saying we should but just throwing it some thought

I was hoping the example provided in PROVIDER.md would convince you 🙂 It's a different use case than OpenAPI.
By that I don't mean to disagree that openapi3 is a special case, because it definitely is. To begin with, it doesn't count with a few crucial pieces of information that Ingress does, such as names of the backends, names of the gateway TLS certificate secrets, which gateway controller ultimately will be responsible for the generated Gateway API objects... And I'm sure we'll find others. However, I believe OAS to Gateway API is not special in the sense that, sooner or later, all providers will need something that is specific to its case.
I can ramble for several pages about the truth behind this last statement, but instead I'll turn to my other point of motivation for having flags dynamically registered. I'm concerned about the leakage of a provider specific detail hard-coded at the level that is supposed to abstract that. It feels like violating a principle, apart from opening a dangerous precedent IMO.
If you are sure we won't regret it (with the information we know now), I will keep it simple and hard code --openapi3-gateway-class-name, --openapi3-backend and (heads-up!) --openapi3-gateway-tls-secret directly inside func newPrintCommand() {...}. Otherwise, the work is done and nothing to worry about.

Lastly I left a few random comments on 12dd6a0.

Thanks for those too! Both valid points that I will be addressing next.

I believe a straight OAS -> Gateway API conversion for now allowed me solving both issues: capabilities and conformance.

Right, to clarify, I did not mean that you should have done OAS-->Ingress-->Gateway, instead I am saying that in future extensions we should do OAS-->IR, Istio CRDs -->IR, Ingress-->IR, and have output providers from the other side do IR-->provider

So, to be clear then, you're aligned with @mlavacca and with how I ended up implementing it, i.e. openapi3-gateway-class-name?

👍

Currently, it's namespace/name, no support for port number. We could instead establish a convention to use $SERVICE.$NAMESPACE.svc.cluster.local:$PORT, for example. Would that be preferable?

hmm not sure, why should a user include svc.cluster.local? it seems like we only have to support namespace, name, and port, right? so I am good with whatever convention you decide here as long as you document it.
Regarding the last bullet, I think what you added is great, so definitely good with keeping it.
Are there any more blockers/things we need to figure out before we can merge this ?

Currently, it's namespace/name, no support for port number. We could instead establish a convention to use $SERVICE.$NAMESPACE.svc.cluster.local:$PORT, for example. Would that be preferable?
hmm not sure, why should a user include svc.cluster.local? it seems like we only have to support namespace, name, and port, right? so I am good with whatever convention you decide here as long as you document it.

I guess I was just trying not to come up with yet another convention. But you're probably right. Why requiring users to know the cluster domain if we don't actually need it?
I'll include the option for the port number. Let's make it [namespace/]name[:port]. Examples of valid values:

--openapi3-backend=my-service
--openapi3-backend=my-namespace/my-service
--openapi3-backend=my-service:3000
--openapi3-backend=my-namespace/my-service:3000

Are there any more blockers/things we need to figure out before we can merge this ?

After the above, I think we're good.

Thanks @LiorLieberman!

Awesome, before my final review.

Quite a few TODOs ahead still, including:

[x]  Gateways and parentRefs
[ ]  backendRefs
[ ]  gatewayClass
[ ]  Name objects after the OAS title (?)
[ ]  Input with multiple OAS docs (?)

Apart from more testing of course.
Please check out the test cases already covered under providers/openapi/fixtures.

Is this up to date? I think you already took care of some unchecked stuff here (like gwc for example)
Can you please update the comment whats already addressed and whats not, and then add TODOs (future/unsupported) things in provider.MD and ping me for final review?

Awesome, before my final review.

Quite a few TODOs ahead still, including:

[x]   Gateways and parentRefs
[ ]   backendRefs
[ ]   gatewayClass
[ ]   Name objects after the OAS title (?)
[ ]   Input with multiple OAS docs (?)

Apart from more testing of course.
Please check out the test cases already covered under providers/openapi/fixtures.

Is this up to date? I think you already took care of some unchecked stuff here (like gwc for example) Can you please update the comment whats already addressed and whats not, and then add TODOs (future/unsupported) things in provider.MD and ping me for final review?

I've updated the comment, @LiorLieberman.
I think the only item not covered in this iteration is the one of input files declaring multiple OAS docs, which I prefer leaving for a future improvement, if ever requested.
The limitation to a maximum of 1 OAS per input file is already mentioned in provider.MD.

/hold for implementing the requested changes from last review.

@guicassolato can you change the release notes to be slightly more detailed? It will make my life easier when releasing a new version


fix importing aws securityhub timestamp

Different aws securityhub findings have different time formats.
fixes #3276

approving now so it can go into the release. some more error handling should be added to make it more robust.


Centered warning exclamation mark

Change in styles to centre the exclamation mark in the cvid warning on the confirmation page

I don't see any difference to the positioning:


Add a preference to disable new marker-based problem highlighting

We need a way to enable the old behavior which involved selecting the problematic segment of a query in the editor.

Verified


Change reference input type to string instead of File

I'm still trying to get a successful run of the full detect variants workflow.

I was able to run the detect variants workflow successfully with these changes.

+2


Added CV Screener

*Fixed #1409

Description 📜
This website show us details of different employees along with their photo, age, city, skills, language etc. We can can view different employee details by clicking next button. At the end of application website is reset to first employee. I have used html, css, javascript in this website.
Fixes #1409

Type of change 📝

[x] Add a new project

Domain of Contribution 📊

[x] Project using HTML, CSS & JS

Checklist ✅

[x] I have performed a self-review of my own code or work.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] My changes generate no new warnings.
[x] I'm GSSoC'22 contributor

Screenshots / Gif (Recommended) 📸

End of application

https://user-images.githubusercontent.com/85051124/167342401-3616d7e1-3c15-45a0-9355-ba32986fd101.mp4

@gurjeetsinghvirdee I have added video and updated README.md file. I have written project name, description, tech-stack used in README.md file. Kindly view.


cant build nestjs app from version 4.1

Hi thanks for your great lib
form version 4.1 I cant build my projects and get this error
node_modules/@mikro-orm/migrations/typings.d.ts:7:9 - error TS2300: Duplicate identifier 'migrationsList'.
   migrationsList(migrations: MigrationDefinitionWithName[], parameters?: any[]): UmzugMigration[];
   node_modules/@types/umzug/index.d.ts:265:9
   migrationsList: (migrations: MigrationDefinitionWithName[], parameters?: any[]) => Migration[];
   'migrationsList' was also declared here.
  node_modules/@types/umzug/index.d.ts:265:9 - error TS2300: Duplicate identifier 'migrationsList'.
 migrationsList: (migrations: MigrationDefinitionWithName[], parameters?: any[]) => Migration[];
  node_modules/@mikro-orm/migrations/typings.d.ts:7:9
  migrationsList(migrations: MigrationDefinitionWithName[], parameters?: any[]): UmzugMigration[];
 'migrationsList' was also declared here.

also this is my package file
"scripts": {
    "prebuild": "rimraf dist",
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },
  "dependencies": {
    "@mikro-orm/core": "^4.1.0",
    "@mikro-orm/nestjs": "^4.2.0",
    "@mikro-orm/postgresql": "^4.1.0",
    "@mikro-orm/reflection": "^4.1.0",
    "@mikro-orm/sql-highlighter": "^1.0.1",
    "@nestjs/common": "^7.4.4",
    "@nestjs/config": "^0.5.0",
    "@nestjs/core": "^7.4.4",
    "@nestjs/jwt": "^7.1.0",
    "@nestjs/platform-fastify": "^7.4.4",
<EMAIL_ADDRESS>"^7.4.4",
    "@nestjs/swagger": "^4.6.1",
    "@nestjs/websockets": "^7.4.4",
    "nestjs-minio": "^2.0.9",
    "nestjs-redis": "^1.2.8",
    "argon2": "^0.27.0",
    "casbin": "^5.1.6",
    "class-transformer": "^0.3.1",
    "class-validator": "^0.12.2",
    "dotenv": "^8.2.0",
    "faker": "^5.1.0",
    "fastify-multipart": "^3.2.1",
    "fastify-swagger": "^3.4.0",
    "mime-types": "^2.1.27",
    "moment": "^2.29.1",
    "pg": "^8.4.1",
    "point-of-view": "^4.6.0",
    "qs": "^6.9.4",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^6.6.3",
    "typeorm": "^0.2.28",
    "typeorm-adapter": "^1.2.0"
  },
  "devDependencies": {
    "@mikro-orm/cli": "^4.1.0",
    "@nestjs/cli": "^7.5.1",
    "@nestjs/schematics": "^7.1.2",
    "@nestjs/testing": "^7.4.4",
    "@types/faker": "^5.1.2",
    "@types/jest": "26.0.14",
    "@types/mime-types": "^2.1.0",
    "@types/minio": "^7.0.6",
    "@types/node": "^14.11.10",
    "@types/qs": "^6.9.5",
<EMAIL_ADDRESS>"^2.1.11",
    "@types/supertest": "^2.0.10",
    "@typescript-eslint/eslint-plugin": "^4.4.1",
    "@typescript-eslint/parser": "^4.4.1",
    "eslint": "^7.11.0",
    "eslint-config-prettier": "^6.13.0",
    "eslint-plugin-import": "^2.22.1",
    "jest": "^26.5.3",
    "prettier": "^2.1.2",
    "supertest": "^5.0.0",
    "ts-jest": "26.4.1",
    "ts-loader": "^8.0.5",
    "ts-node": "^9.0.0",
    "tsconfig-paths": "^3.9.0",
    "typescript": "^4.0.3"
  },
  "mikro-orm": {
    "useTsNode": true,
    "configPaths": [
      "./src/mikro-orm.config.ts",
      "./dist/mikro-orm.config.js"
    ]
  },
  "jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "rootDir": "src",
    "testRegex": ".spec.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }

and this is my tsconfig
{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2017",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "paths": {
      "@src/*": ["src/*"],
      "@configs": ["src/configs"]
    }
  }
}

Looks like the PR with updated typings for umzug is finally merged.

Faced the same problem with the latest 4.1.0 version
Not sure that this issue has been resolved

It is fixed (yesterday), but not released yet - will be shipping 4.2 today probably.
Not sure why the downvotes, I just stated what the root cause is, and closed it with an actual fix...

It is fixed (yesterday), but not released yet - will be shipping 4.2 today probably.
Not sure why the downvotes, I just stated what the root cause is, and closed it with an actual fix...

Thank you for providing the info 👍
Will check this workaround


Where should joint matrices be stored?

in which class is it correct to store jointMatrices collections?
If I understood correctly, Skin is not suitable because each meshNode can have its own global transformations. Then should jointMatrices be stored for each Mesh or its Node to be passed to the shader?

You should keep in mind the semantics of what is represented in a glTF asset. For example: The joint matrices are not stored in the glTF directly. They are computed from the information that is contained in the glTF, taking into account the structure and relationships of the elements in the glTF.
When you have classes like Mesh, Skin and Node that roughly correspond to the elements in a glTF, then you would probably not store any List<Matrix> jointMatrices in the Mesh class. You would also not store it in the Skin class. You might store it in the Node class, because that's where all the information that is required for computing the joint matrices comes together. But you might very well "encapsulate" this part in a class that is specific for rendering. This might be something like a RenderedMesh, maybe with specifiaizations like RenderedSkinnedMesh or so.
This is probably related to https://github.com/KhronosGroup/glTF-Tutorials/issues/80#issuecomment-1437565043 . In any case, it sounds like a very specific question about the class design of a library that is supposed to load or render glTF. As such, there is no single, 'true' answer, and I'd recommend looking at other glTF libraries to see how they solved this. (This does not mean that you'd have to take the same approach - but it might make you aware of some caveats...)

ok, thanks


MongoODM embed collection

Hi guys,
I'm trying to use alicebunde for my project fixtures. I have an Address entity which is an embed document and a DistributionCenter which is a normal document that contains the address. The problem is that when I run php app/console doctrine:mongodb:fixtures:load I got this error:
  [InvalidArgumentException]
  Class "HelloFresh\Business\Entity\Address" does not have an identifier

Bu the document works pretty well on the mongodbbundle, it's even validated by doctrine:mongodb:mapping:info command.
If you guys can help me I'll appreciated a lot
Thanks,

Forget it guys.... I figure it out.
Just have to use the (local) attribute on the Address fixture file and that's it.
Thank you anyway


Fix amp tests

A few changes to fix AMP-related problems in our tests:

With opt_level="O1" (the default), AMP patches many torch functions, which breaks any tests that run afterwards. This patch introduces a pytest extension that lets tests be marked with @pytest.mark.spawn so that they are run in their own process using torch.multiprocessing.spawn so that the main python interpreter stays un-patched.

Since AMP defaults to O1 now, DP tests no longer throw exceptions. Remove the pytest.raises that expects the exception.

Since AMP patches torch functions, CPU inference no longer works.
Skip prediction step for AMP tests.

Note that there are still a couple of unrelated test failures that will be addressed in another PR.

Travis failure appears to be due to this unrelated issue: https://github.com/pytorch/vision/issues/1718

tests are failing on PIL, I found somewhere that adding Pollow>=4.2 solves the issue

https://github.com/python-pillow/Pillow/issues/4130
https://pillow.readthedocs.io/en/stable/releasenotes/7.0.0.html#pillow-version-constant

Supposedly torchvision will do a bug fix release early next week (0.4.2?) that will resolve the Pillow issue. The fix is already in torchvision master. I’m inclined to just wait for that and update our minimum torchvision version.
On Jan 4, 2020, at 9:40 AM, Jirka Borovec<EMAIL_ADDRESS>wrote:

tests are failing on PIL, I found somewhere that adding Pollow>=4.2 solves the issue

python-pillow/Pillow#4130https://github.com/python-pillow/Pillow/issues/4130
https://pillow.readthedocs.io/en/stable/releasenotes/7.0.0.html#pillow-version-constant

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/williamFalcon/pytorch-lightning/pull/661?email_source=notifications&email_token=AAJWJZX6D2YL4MJQK2BDZWDQ4CUW7A5CNFSM4KCP5IUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC2JUY#issuecomment-570795219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJWJZW4YFKSU5U5B25OEQTQ4CUW7ANCNFSM4KCP5IUA.


Request droplet action automatically start compression

When using the app as a droplet (dropping folders on the app or its alias), I'd recommend automatically starting the compression rather waiting for the user to press the compress button.
Rational: more in keeping with droplet app concept.
At a minimum, it would nice to have the option even if it were a defaults write hidden/expert pref.

Added as an options setting in version 2.5.


Removing folding controls removes gutter diff decorations

"editor.showFoldingControls": "never",

VS Code Version: 1.74.0 (user setup)
OS Version: Windows_NT x64 10.0.19044

Nvm, it was because of
"editor.lineDecorationsWidth": "5",


Backport exponential backoff into v2

Unfortunately we're stuck on ES 1.5 so have to stick with the 2.x clients, however with our production workloads the exponential backoff functionality is very important for when we need to perform cluster maintenance. I've backported the code from 4.x and everything works great.
I've created a temporary package in nuget for anyone who wants this feature today:
https://www.nuget.org/packages/Serilog.Sinks.Elasticsearch.Backoff/2.2.0
Thanks,

Thanks! I merged it in the maintenance branch. Be aware that there is no build/nuget package from that branch. So thanks for offering your package from Nuget.


VueJS DOM parsing fix

When using $domScript->textContent, DOM library starts parsing some tags within strings and messes the output up. For example alert("text"); becomes alert("text");
So instead of DOM operations, we extract script contents with a regex.

Fair enought

new version available


Add FrameAnimationContext for Spritesheets

Hi,
I wanted to use drawsvg to programmatically create some art assets for a game I'm working on, so I added a feature to render a FrameAnimation as a bitmap spritesheet (i.e. a single raster image with each frame laid out in a grid). The new function frame_animate_spritesheet works just like frame_animate_video, and takes an optional row_length parameter to determine the dimensions of the spritesheet.
If this feature is outside the scope of the project, feel free to pass on it - I just thought I'd submit the code if you find it worth including.
Example usage:
import drawsvg as draw

def draw_frame(t):
    d = draw.Drawing(2, 6.05, origin=(-1, -5))
    d.set_render_size(h=300)
    t = (t + 1) % 2 - 1
    y = t**2 * 4 - 4
    d.append(draw.Circle(0, y, 1, fill='lime'))
    return d

with draw.frame_animate_spritesheet('example.png', draw_frame, row_length=10) as anim:
    for i in range(20):
        anim.draw_frame(i/10)
    for i in range(20):
        anim.draw_frame(i/10)
    for i in range(20):
        anim.draw_frame(i/10)

Cool!  This is a nice use of the frame animation context.  I will definitely merge it once I have some time to look more closely at the code.
Is this grid-based sprite-sheet layout standard or common?  Do you have example code to import the PNG into a game engine?

Thanks - I'm happy to make any changes necessary.
Sprite sheets like this are built into most 2D game engines - here are some examples from the docs of Godot and Phaser.js.

After merging this, I also added support for spritesheet output from native animations (via Drawing.as_spritesheet()).  I appreciate the clean code that made this easy.
Published version 2.1.0.

Thanks, glad it was easy to extend!


react-three-js uses userData on object 3d

I noticed that the standard THREE-JS way of attaching data to mesh objects will blow up react-three-js.
object3dVariable.userData ={ whatever stuff you want}

You can get around this problem by declaring something like:
object3dVariable.userDataA ={ whatever stuff you want}

Where object3dVariable is a ref of a mesh.
However this breaks from standard THREE-JS conventions.  It may be impossible for the repo to operate without doing this. So perhaps include a warning in docs such as: using userData in react-three-renderer refs will cause an error, instead use userDataA.
Or the repo could be refactored to use a variable name that won't cause conflicts. Such as reactThreeRendInfo.
Original Code that caused error:
componentDidMount(){
        let self = this;
        // user data is three js user info that can be attached to object3d
        // we do this input system because viewport raycasts to object and fires off click event
        this.boundBox.userDataA = {
            onClick: function (event) {
                self.onStartMovement(event);
           }
        }
    }
    render() {
      return <object3D>
            <mesh   position={this.props.position}
                    name="handler:position"
                    key="boundBox"
                    ref={(item )=> this.boundBox = item}>
                <boxGeometry
                    width={2}
                    height={2}
                    depth={0.1}/>
                <meshLambertMaterial color={0xffffff} depthTest={false} transparent={true} opacity={0}/>
            </mesh>
           <SvgVisual key="anchor"
                       position={this.props.position}
                       iconName={'icon-four-way-arrow'}
                      strokeColor={0xffffff}
                       fillColor={0x000000}
                       size={2}
                       fill={true}/>
        </object3D>;
    }

I need to store some data in an Object, and according to the Three.js docs I'm supposed to use userData. However I don't think this is exposed in react-three-renderer. I've tried doing <group userData={{test: 'test'}} >

Yes unfortunately it is not exposed yet in r3r, I can think of some ways to fix this, either with an userData attribute or by making r3r use something other than userData.

While I am not manually changing the userData, I think I run into a related problem in https://github.com/toxicFork/react-three-renderer/issues/57#issuecomment-333309313


Error running apu on Ubuntu 16.04

Previously, I had issues when multiple devices were connected. Now, after disconnecting all devices but one apu -p todoapp-mvp-dagger -i -o results in the following error.
/var/lib/gems/2.3.0/gems/apu-0.3.7/lib/apu/android_project.rb:64:in `install': undefined local variable or method `execute_line' for #<Apu::AndroidProject:0x000000021af408> (NameError)
Did you mean?  @execute_line
               execution_line
	from /var/lib/gems/2.3.0/gems/apu-0.3.7/lib/apu.rb:61:in `manage_opts'
	from /var/lib/gems/2.3.0/gems/apu-0.3.7/lib/apu.rb:32:in `initialize'
	from /var/lib/gems/2.3.0/gems/apu-0.3.7/bin/apu:5:in `new'
	from /var/lib/gems/2.3.0/gems/apu-0.3.7/bin/apu:5:in `<top (required)>'
	from /usr/local/bin/apu:22:in `load'
	from /usr/local/bin/apu:22:in `<main>'

update should fix this issue


[BUG] Makemsix pack creates a broken (empty) package when the given directory contains a .git folder

Project
MSIX SDK
Describe the bug
When running makemsix pack with the directory argument that contains a .git, the generated MSIX package is broken as the original content in the given directory isn't in the package when inspecting the package.
To Reproduce
cd path\to\directory\of\contents
git init
makemsix pack -d path\to\directory\of\contents -p Package.msix

Use 7-zip to inspect the package and we won't see the original content used to create the package.
Expected behavior
All the original files/binaries in the directory should be present in the package.
Screenshots
Directory given:

Output MSIX package:

Platform
Windows 10 x64
Additional context
N/A

I was not able to repro this issue, but I fixed a bug where a package that contains .git cannot be unpacked. Please reopen if you see problem again


User Story: IO receive notification of operator reg status

Description:
As an IO, I want to receive a notification of my organization's registration status so that I'll know when to keep going with facility registration
Acceptance Criteria:
Given
When
Then
Development Checklist:

[ ] Checklist item
[ ] Checklist item
[ ] Checklist item
[ ] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

·Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

Seems like an automated email. Not beta version. Leaving for later.

Seems like duplicate of #79


Support flashcard syntax with question mark (?) at end of same line as the question

Discussed in https://github.com/st3v3nmw/obsidian-spaced-repetition/discussions/831

Originally posted by buzhiming999 January  8, 2024
Currently Supported
Question A
?
Answerline1
Answerline2
Answerline3

?    standalone line doesn't look very nice.
Desired Format
Format wanted as per #831
Question A  ?
Answerline1
Answerline2
Answerline3

you can use the > as the Separator for multiline flashcards

Thanks @WangShuoCode I've updated the description so hopefully it is clearer now.
The issue isn't the separator character, but rather wanting the ? at the end of the question text to be recognized as the delimiter between question and answer


Issues Creating Scripts in UI

Describe the Issue
Script block code not being obtained from modal and is causing creation of new scripts in the UI to fail.

Will be in nightly!


chore(deps): update most of the dependencies

As for PR #145

:tada: This issue has been resolved in version 2.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Trouble running inference using pretrained model

Hi,
I tried testing the model. However, I was not able to find the definition of LFNet anywhere in the code. Here is what I see when I try to run the code:
Traceback (most recent call last):
File "test.py", line 25, in
from libs.model import LFNet
ImportError: cannot import name 'LFNet' from 'libs.model' (/storage2/datasets/rkumari/GAENet/libs/model.py)
Instead I tried replacing it with GAENet, however the pretrained model weights did not match the proposed architecture. Could you please provide explicit instructions on how to reproduce results of the paper? Otherwise, this work is not useful to the community.

Hi @riya-kumari, were you able to resolve this issue, I was trying to run this model and see the same missing component. It looks like incomplete code is pushed, and author seems to be non-responsive @Wenchao-Du


Fix displaying media from URL

Identify source and display accordingly media from URL or local storage.

Hi @SlavyMihov, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;


Create GreedyALgoMinCoins

@SupriyaK2 contribute here https://github.com/Ishaan28malik/Get-Dev-Resources


Cannot upgrade from 0.0.27 to 0.0.28 (nor 0.0.29)

My current models are as follow:

CatalogMetadata -> belongsTo(async,polymorphic) -> Catalog
Catalog -> hasMany(async,polymorphic) -> Sections

Previously, my config looked like:
this.get('/api/catalogMetadata/:id', ['catalog-metadatas']);
this.get('/api/specificClassOfCatalog/:id', ['catalogs']);
this.get('/api/specificClassOfSection/:id', ['specific-class-of-sections']); // on for each specific class

After upgrading to 0.0.29 (though the breaking change was in 0.0.28), I had two problems:

I need to use camelize names when the model's name has more than one word. Since both Ember Data and Ember CLI are moving/have moved to dasherized strings, is this correct?

I'm also getting calls to the generic section endpoint for the polymorphic resources. Instead of /api/specificClassOfSection/:id, I'm getting calls to /api/sections/:id.

Are these bugs or features? I saw no reference to these changes in the changelog, though.

This sounds frustrating, sorry you're running into problems. I really appreciate you digging + opening up an issue!

When you say you need to use camelCase names, which part are you referring to? I see some camelCase values in your Mirage config, but those are the paths to your API. Could you clarify, perhaps by showing what you had to change your config to after upgrading?
Are you saying your Ember app is now requesting /api/specificClassOfSection/:id instead of /api/sections/:id? If so Mirage shouldn't have affected this at all, since Mirage sits outside of your app.

Please, don't apologize: you are doing an amazing job!

The changes would be as follow: this.get('/api/catalogMetadata/:id', ['catalogMetadatas']);, then move the fixture from catalog-metadatas.js to catalogMetadatas.js. I saw that in the get handler collection is getting the camelized name, and not the dasherized one.

If I upgrade, and fix some names (like the one in point 1), then mirage raises some errors about /api/sections/:id. It is strange but the only thing that changed in my package.json was mirage, so no clue why this is different.

For 1, collection is not camelized, it just pluralizes it. I'm actually still not sure the behavior you're expecting with
this.get('/api/catalogMetadata/:id', ['catalogMetadatas']);

Typically when you have a route with :id you want to return a single record whose id matches. If you wanted to find a catalogMetadata by id you could just use
this.get('/api/catalogMetadata/:id');

or specify the type explicitly with
this.get('/api/catalogMetadata/:id', 'catalogMetadata');

In your example you pass an array to the shorthand, so that's actually just going to return the entire collection of catalogMetadata records - is that what you want? What's the behavior you're going for?
BTW you can always write the function manually
this.get('/api/catalogMetadata/:id', function(db, request) {
  return db['catalog-metadatas']
});

so you can leave your filenames hyphenated. But I'm still not understanding exactly what behavior your going for.

I'm finding naming is a bit confusing as well.  It's not quite clear when to use camelized/dasherized/underscored.  I definitely think that all filenames should be dasherized to match ember-cli.  My understanding is that the keys on db are taken from the filename - so perhaps the shortform functions should automatically dasherize the url before looking up the db?
For example all three of these statements:
this.get('/fruit_basket/');
this.get('/fruit-basket/');
this.get('/fruitBasket/');

Should result in this:
this.get('/(fruit_basket|fruit-basket|fruitBasket)/', function(db , request){
  return db['fruit-basket'];
});

Yes this is confusing, originally it was to make it easy to load data into your tables (like you say, underscore filename = underscore db table name). Once we get serializers, everything will be dasherized, and if your API does underscore you'll configure that in the serializer.

Ok, is there any point in a PR to implement this behaviour immediately or are serializers landing in the near future?

They're blocked by relationships, which are still a few weeks out.
I suppose we could add a pr to support a single default serializer (i.e. not model-specific) that would just iterate through all the keys and either camelCase or snake_case them. This would involve standardizing all js prop names (always camelCase, including table names etc.).

I think a note in the docs about how to name things would go a long way.
Not being able to use the shortcuts due to having underscored urls but wanting to use dasherized filenames is a little bit of a frustration but certainly manageable.
I'd be happy to work on a PR but think it makes sense to keep it minimal at this point given it will all change soon anyway.

Yep I agree. You could do this.get('/some_users', 'some-users') for now, to have underscore url but refer to a dasherized collection name.

Same with the other shorthands, you can optionally specify collection name (which in your case would be the dasherized name): http://www.ember-cli-mirage.com/docs/latest/shorthands/

Ahh okay missed that - that will help.  I will try to submit something on naming conventions to the gh-pages branch.

I think the new serializers in 0.2.0 address this issue. Closing for now, feel free to reopen in case you have questions!


The quotemark rule does not allow options and severity.

Bug Report

TSLint version: 5.2.0
TypeScript version: 2.3.1
Running TSLint via: (pick one) CLI / Node.js API / VSCode / grunt-tslint / Atom / Visual Studio / etc

TypeScript code being linted
import { BottomSheetKey, BottomSheetService } from "bottomSheet";
import { INavItem, NavHeight } from 'core/services/nav.service';
import { Configuration } from './app.configuration';

with tslint.json configuration:
{
    "defaultSeverity": "error",
    "extends": [
        "tslint:recommended"
    ],
    "jsRules": {},
    "rules": {
        "quotemark": {
            "options": [ true, "single", "avoid-escape" ],
            "severity": "warning"
        }
    },
}

Actual behavior
The quotemark rule is ignored.
Expected behavior
There should be a warning reported from the quotemark rule on line 1 of the provided snippet at "bottomSheet".
Thoughts
This could be a larger issue with rules, but I've only observed it with quotemark.

If you use the new config format with severity and options, you don't want
the first option to be true. If you remove it from the array, the rule
should work as expected.
Am 12.05.2017 18:07 schrieb "Jacob Robertson"<EMAIL_ADDRESS>
Bug Report

TSLint version: 5.2.0
TypeScript version: 2.3.1
Running TSLint via: (pick one) CLI / Node.js API / VSCode /
grunt-tslint / Atom / Visual Studio / etc

TypeScript code being linted
import { BottomSheetKey, BottomSheetService } from "bottomSheet";import { INavItem, NavHeight } from 'core/services/nav.service';import { Configuration } from './app.configuration';
with tslint.json configuration:
{
"defaultSeverity": "error",
"extends": [
"tslint:recommended"
],
"jsRules": {},
"rules": {
"quotemark": {
"options": [ true, "single", "avoid-escape" ],
"severity": "warning"
}
},
}
Actual behavior
The quotemark rule is ignored.
Expected behavior
There should be a warning reported from the quotemark rule on line 1 of
the provided snippet at "bottomSheet".
Thoughts
This could be a larger issue with rules, but I've only observed it with
quotemark.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/palantir/tslint/issues/2746, or mute the thread
https://github.com/notifications/unsubscribe-auth/ALaeKN8MtJyisZmnL1SJfgTyAIcaUQPJks5r5IOlgaJpZM4NZfAU
.

Yeah, that works.  Thanks!
I couldn't find a good example in the docs for how to go from
    "rules": {
         "quotemark": [ true, "single", "avoid-escape" ],
    }

to
    "rules": {
        "quotemark": {
            "options": [ "single", "avoid-escape" ],
            "severity": "warning"
        }
    }

Is this subtle difference mentioned anywhere?

@jacob-robertson yes, it's in the Notable features & enhancements section of the 5.0.0 release notes


Change how Prisma Client loads .env when generated via postinstall script

Internal discussion: https://prisma-company.slack.com/archives/C016KUHB1R6/p1675812151232349

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community.
This issue was originally created for internal tracking purposes, but if you feel this is important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest.
For more insight into our priorities and how we’re thinking about the future of Prisma, please see our blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!


Flutter Apps are lagging on iOS when Status Bar extends (e.g. when hotspot is open)

My flutter apps have been consistently having this issue on iOS, anytime the status bar extends (like when persoanl hotspot is open), the performance of the app drops very significantly. I was wondering if anyone has an idea as to why this happens, or if anyone knows the fix to this problem.

Not able to reproduce this issue on latest dev, performance is the same when switching hotspot open

Code Sample
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Material App',
      theme: ThemeData.dark(),
      home: Home(),
    );
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Material App Bar'),
      ),
      body: Center(
        child: Container(
          child: Text('Hello World'),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: Icon(Icons.add),
        onPressed: () {
          Navigator.push(context, MaterialPageRoute(builder: (_) => Second()));
        },
      ),
    );
  }
}

class Second extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Material App Bar'),
      ),
      body: Center(
        child: Container(
          child: Text('Hello World'),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: Icon(Icons.add),
        onPressed: () {},
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel dev, 1.21.0-1.0.pre, on Mac OS X 10.15.6 19G73, locale
    en-GB)
    • Flutter version 1.21.0-1.0.pre at /Users/taha/Code/flutter_dev
    • Framework revision f25bd9c55c (3 weeks ago), 2020-07-14 20:26:01 -0400
    • Engine revision 99c2b3a245
    • Dart version 2.9.0 (build 2.9.0-21.0.dev 20bf2fcf56)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/taha/Code/sdk
    • Platform android-30, build-tools 30.0.1
    • ANDROID_HOME = /Users/taha/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.6)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.6, Build version 11E708
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 48.0.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.47.3)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.13.1

[✓] Connected device (4 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      13.6
    • macOS (desktop)        • macos                     • darwin-x64     • Mac
      OS X 10.15.6 19G73
    • Web Server (web)       • web-server                • web-javascript •
      Flutter Tools
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 84.0.4147.105

• No issues found!

Could everyone who still has this problem please file a new issue with the exact description of what happens, logs and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Query: No thanos-specific metrics, e.g. thanos_objstore_bucket_last_successful_upload_time

Thanos, Prometheus and Golang version used:
Thanos v. 0.16.0
Prometheus v2.22
GO v1.15
Object Storage Provider:
FILESYSTEM
What happened:
Thanos GUI doesn't show any Thanos-specific metrics, e.g., thanos_objstore_bucket_last_successful_upload_time, thanos_compactor_halted or thanos_blocks_meta_synced
What you expected to happen:
Get values for any of the thanos metrics
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
I'm pretty new to Thanos so I guess this is a configuration issue or misunderstanding on my part and would appreciate some help.
I have a HA-set up with 2 Prometheus instances + sidecar, query, one store (FILESYSTEM) which contains 2 months of data (no prometheus compaction, min/max time 2h) and now a compactor which I'm trying to debug. I read that there should be thanos-specific metrics about uploaded blocks, compaction etc but when I look for them in the Thanos GUI they aren't there. Any clues what I'm missing? All other metrics, de-duplication etc all works.
Query
/thanos query
--http-address "<IP_ADDRESS>:9080"
--grpc-address "<IP_ADDRESS>:10905"
--store "<IP_ADDRESS>:10901"
--store "<IP_ADDRESS>:10902"
--store "<IP_ADDRESS>:10904"
--query.replica-label "replica"
Compactor
thanos compact
--data-dir "/var/thanos/compactor"
--objstore.config-file "/etc/thanos/bucket.yml"
--http-address "<IP_ADDRESS>:10906"
--consistency-delay=30m
--retention.resolution-raw=0d
--retention.resolution-5m=0d
--retention.resolution-1h=0d
--block-sync-concurrency=20
--compact.concurrency=1
--wait
Store
thanos store
--data-dir "/var/thanos/store"
--objstore.config-file "/etc/thanos/bucket.yml"
--http-address "<IP_ADDRESS>:10903"
--grpc-address "<IP_ADDRESS>:10904"
--chunk-pool-size=8GB
--index-cache-size=2GB

Hi, if you are looking for the metrics of thanos components, for example compactor, you can get its metrics in the /metrics endpoint.
If you want to query the compactor metrics via Thanos query web UI, its metrics must be scraped via a Prometheus job and you have a sidecar to query from the Prometheus.

Well I'm new and confused!

Thanks yeya24, that makes total sense!


Synchronize Decimal with Darwin overlay

Reorganize Decimal.swift, bringing the two implementations back into alignment where it makes sense to do so. Even the organization of the two files has fallen out of sync, making it increasingly difficult to ensure parity.
A corresponding PR has been drafted for the Darwin overlay.
The major functional change here is incorporation of the function pow(_: Decimal, _: Int), which is present in the Darwin overlay but not found in swift-corelibs-foundation.

@swift-ci Please test Linux

@swift-ci Please test Linux

@swift-ci Please test Linux

@swift-ci Please test Linux

Unrelated SwiftPM failure; let's see if second time's the charm.

@swift-ci Please test Linux


Add an Example for WizardControl.Finished Event

Please add an example for WizardControl.Finished Event.
TODO (optional): Describe a specific scenario you would like to see addressed.
Help Topic: https://dahall.github.io/AeroWizard/html/E_AeroWizard_WizardControl_Finished.htm

The example is still not there.


request help: failed to list stream_routes

Issue description
apisix-ingress-controller报错输出：

apisix报错输出：

Environment

your apisix-ingress-controller version (output of apisix-ingress-controller version --long):

your Kubernetes cluster version (output of kubectl version):
1.18

if you run apisix-ingress-controller in Bare-metal environment, also show your OS version (uname -a):
3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Please upgrade your Helm chart version.
xref: https://github.com/apache/apisix-ingress-controller/issues/851#issuecomment-1026306420
https://github.com/apache/apisix-helm-chart/pull/233
duplicate: https://github.com/apache/apisix-ingress-controller/issues/858

I will close this issue.  It will be fixed in https://github.com/apache/apisix-ingress-controller/pull/868


Sarang87

Hello,
I have made my changes for you to review. I have included 3 index.js files
index_original.js => Original file from the google-scholar master which has the Cited count issue.
index_sarang87.js => File with fixed cited count issue for you to review. I have removed the throttled queue which is slowing down the performance considerably.
index_throttled_q.js => File with fixed cited count issue with the throttled queue to stop from getting blocked.
If it would be possible to retain the throttled queue while having a minimal impact on retrieval times for results that would be ideal.
Regards,

Hi - I know this is unrelated to your commit but I'm not sure where else to look for help.  Do you have any way around the CORS policy issue described here: https://github.com/VT-CHCI/google-scholar/issues/12 ?
I'm trying to use this to integrate Google Scholar search into our app but if I'm reading other information correctly it looks like Google Scholar doesn't allow API searches... how are you using this package?