Map data files to repository

CLI does not require more options but will try to map all data files passed in the command to a repository, based on the ISA-JSON.
Current logic:

Scenario where all files passed with the --data-files option are matched to data files in the ISA-JSON:

Continue submission

Scenario where more data files are passed with the --data-files option then there are present in the ISA-JSON:

Extra data files are simply ignored and submission continues.
We could log a warning that one sample was ignored during submission.

Scenario where the ISA-JSON has more data files then is passed with the --data-files option:

An error is raised informing the user there is a mismatch in data files that has te be corrected.

Closes #78

Just to be sure a test submission:
############# Welcome to the MARS CLI. #############
Running in Development environment
Starting submission of the ISA JSON to the target repositories: biosamples, ena.
ISA JSON with investigation 'Bob's investigation' is valid.
Submission to biosamples was successful. Result:
{'targetRepository': 'biosamples', 'errors': [], 'info': [], 'accessions': [{'value': 'SAMEA131435379', 'path': [{'key': 'investigation'}, {'key': 'studies', 'where': {'key': 'title', 'value': 'Arabidopsis thaliana'}}, {'key': 'materials'}, {'key': 'samples', 'where': {'key': 'name', 'value': 'leaf 1'}}]}, {'value': 'SAMEA131435378', 'path': [{'key': 'investigation'}, {'key': 'studies', 'where': {'key': 'title', 'value': 'Arabidopsis thaliana'}}, {'key': 'materials'}, {'key': 'sources', 'where': {'key': 'name', 'value': 'plant 1'}}]}]}
#sample/331: comments=[] id='#ontology_annotation/accession_#sample/331' annotationValue='SAMEA131435379' termAccession=None termSource=None.
#source/330: comments=[] id='#ontology_annotation/accession_#source/330' annotationValue='SAMEA131435378' termAccession=None termSource=None.
Uploading ENA_TEST2.R2g.fastq.gz to FTP
Start submitting to ena.
Submission to ena was successful. Result:
{'targetRepository': 'ena', 'errors': [], 'info': [{'message': 'This submission is a TEST submission and will be discarded within 24 hours'}], 'accessions': [{'value': 'ERP166052', 'path': [{'key': 'investigation'}, {'key': 'studies', 'where': {'key': 'title', 'value': 'Arabidopsis thaliana'}}]}, {'value': 'ERX13337714', 'path': [{'key': 'investigation'}, {'key': 'studies', 'where': {'key': 'title', 'value': 'Arabidopsis thaliana'}}, {'key': 'assays', 'where': {'key': '@id', 'value': '#assay/18_20_21'}}, {'key': 'materials'}, {'key': 'otherMaterials', 'where': {'key': '@id', 'value': '#other_material/332'}}]}, {'value': 'ERX13337715', 'path': [{'key': 'investigation'}, {'key': 'studies', 'where': {'key': 'title', 'value': 'Arabidopsis thaliana'}}, {'key': 'assays', 'where': {'key': '@id', 'value': '#assay/18_20_21'}}, {'key': 'materials'}, {'key': 'otherMaterials', 'where': {'key': '@id', 'value': '#other_material/333'}}]}]}
Update ISA-JSON based on receipt from ena.
#other_material/332: comments=[] id='#ontology_annotation/accession_#other_material/332' annotationValue='ERX13337714' termAccession=None termSource=None.
#other_material/333: comments=[] id='#ontology_annotation/accession_#other_material/333' annotationValue='ERX13337715' termAccession=None termSource=None.

CLI does not require more options

How disappointing, every new feature should come with at least 3 new options :wink:

The code looks good, but while I was reviewing this, I started wondering: do we even need the --data-files option? Or can we get rid of it and just use the files passed in the ISA-JSON directly?
Is it because we can't use a full filepath in the ISA-JSON, or the full path might change between the ISA-JSON producer and the broker?

Indeed, we need to know where the data files are located and this information is not in the ISA-JSON.
But I agree that we should find a way to reduce the number of options and arguments...

@kdp-cloud did you by any chance also do a metabolights test run?

@kdp-cloud did you by any chance also do a metabolights test run?

No sorry! I don't have credentials yet for submitting to metabolights (shame on me! :smile: ).


Issue with crossjoins

The related bug is listed in DSW
But it looks like it is rather MDX2JSON issue

Turned out it is DSW


Bump alluxio-maven img to 0.07

Applies the change introduced by https://github.com/Alluxio/alluxio/pull/15150 by building the docker image and updating its references to the newly tagged version

alluxio-bot, merge this please


Create new Vue component for Bootstrap's custom Radio Buttons

Implemented in User Edit form. Closes #105

I have addressed the two concerns. Merging.


Move service name and navigation into section

This is a possible fix for the 'unclear service name' accessibility issue from https://github.com/alphagov/govuk-design-system/issues/3811
Links

Service header component
Example with a header, service header (with service name and navigation) and phase banner
Example page with header and service header (service name only)
Example page with header and service header (navigation only)
Example page with cookie banner, header, phase banner, service header (with service name and navigation) and breadcrumbs, to emulate a potential 'worse case scenario'
Preview Branch. To install, use npm install --save "alphagov/govuk-frontend#dc8ff97b4"

Before:

    service name
    service navigation

      service name
      service navigation


adde travis ci

Signed-off-by: Lenny Verkhovsky<EMAIL_ADDRESS>

@lennybe
please fix typo in subject from 'adde' to "add"

abondoned


query: add strict mode flag

[x] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
Adds --store.strict-mode flag to Thanos Query as agreed on https://thanos.io/proposals/202001_thanos_query_health_handling.md/. The changes seem straightforward:

Refactored some places where we refer to "healthy" stores - now they are not necessarily healthy but active stores to which we will send the queries;
Refactored to separate specified store addrs into two sets - dynamically specified and statically. This should make the flow more straightforward i.e. no changes were needed to the resolvers' part;
StoreSpec has a new method Static() which tells us if a node has been specified statically. This seems to be the right abstraction layer.

Finally, marks the proposal as "done".
Verification
Unit tests pass which cover the new functionality.

Thanks all good as implemented as in design heart
However, I just realized that there might be a better UX even if we would allow instead of strict-mode flag adding a new --store-strict next to --store so you can fine granularly add certain stores as strict. I definitely like this more... It looks like with your implementation it's the matter of few tweaks to make this happen.
WDYT @GiedriusS ?
Sorry for this, but I literally did not think about this idea when we were reviewing proposal (:

It's ok but I hope that you understand where the frustration might come from. Without the other discussions that we've had, I can only see marginal UX improvement where the HELP message would be close to the place where the StoreAPIs are defined. I think it's debatable whether it will make sense to have some statically specified StoreAPIs with Cortex's query-frontend on top without the strict mode. With TLS (--grpc-client-tls-secure, https://github.com/thanos-io/thanos/issues/977) it's a totally different case and that's where it would make more sense.
All in all, I will remake this PR with your suggestion and update the proposal. I really want everyone to be happy with this and other things that we do hence why I have made that proposal in the first place.


Auto-updater broken as of 0.34.3: NSURLSession/NSURLConnection HTTP load failed

Minimal repro here: https://gist.github.com/mkscrg/d56227f2b6a3a430a17d
auto-updater fails immediately after the update-available with this error:
2015-11-14 18:45:14.807 Electron[2750:121917] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
auto-updater error: An SSL error has occurred and a secure connection to the server cannot be made.: (null)

In my limited tests, I could hit this issue with Electron >= 0.34.2 && OS X >= 10.11. Dropping to 0.34.1 and/or 10.10 seemed to avoid it.

Possible workaround: apparently some SSL certs break auto-updater and some don't. All of our wagonhq.com certs seem to work fine.
I tried serving the update files different ways and found:

Amazon's content certs break auto-updater. This includes

s3.amazonaws.com
*.s3.amazonaws.com
*.cloudfront.net

Our "normal" SSL certs seem to work fine. For example *.wagonhq.com, which is a Comodo wildcard cert. I'm not sure what distinguishes this from Amazon's certs.
A simple self-signed cert breaks auto-updater. (Made like this.)

/cc @joshaber

Correct. This is because of App Transport Security, new in iOS 9 and OS X 10.11.
Unfortunately in classic Apple fashion there's very little documentation about it. It looks like the best they have is documentation of the plist keys: https://developer.apple.com/library/prerelease/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40016240
You'll need to either setup your update server with a cert that App Transport Security will accept, or add an exception to your app.

@joshaber is it odd that we ran into this issue as of 0.34.2? We got around it by using an ATS-friendly cert, but I was surprised to find this breakage in an Electron point release.

Hmm that is a bit surprising. I'd have thought it'd be dependent on the SDK you're linking against, but perhaps it's using the SDK Squirrel was built against instead.

Is it possible you changed the SDK your app is building against?

No, we're using electron-prebuilt. Maybe something changed in that build?

Entirely possible. In my quick checking I didn't see any documentation on how they actually build Electron.

From 0.34.2 the Electron build switched to use OS X 10.11 SDK because of an issue of our internal CI machine, that should be the root problem of this. @joshaber I'm cc-ing you in that issue.

@zcbenz I wonder if Electron should include an ATS exception by default so that we can undo this breakage. Maybe even NSAllowsArbitraryLoads and let users turn it back on if they want it?

@joshaber I'm :+1: on adding NSAllowsArbitraryLoads by default, but many apps are creating their own Plist files, so it will not really fix this.

It'd be :cool: :up: if Apple would yanno, specify why correctly-validating certificates don't work

It'd be :cool: :up: if Apple would yanno, specify why correctly-validating certificates don't work

FWIW, nscurl --ats-diagnostics URL will usually give you more info.


add support for non-json content types (sse streaming)

Fixes #2788

New feature (non-breaking change which adds functionality)

enables use cases in language models that stream the outputs (e.g. ChatGPT)
Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevent result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

local model with predict calling openai apis and returning an EventSourceResponse

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[x] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

allow model returning EventSourceResponse

@yuzisun @xfu83 could you kindly take a look. minimal change that should help supporting LLMs
cc @Nagarajj @rachitchauhan43

added the streaming support for v1 endpoints in https://github.com/kserve/kserve/pull/3475


Use <IP_ADDRESS> instead of localhost

As previously discussed in [1] and [2], all web activities running in
sugar shell should use "<IP_ADDRESS>" instead of "localhost", considering
the server is always going to be used via the local network interface.
This fixes the problem in Ubuntu 14.04 LTS where libsoup is not able
to resolve localhost when no active network is present, breaking web
activities integration with sugar shell.
[1] https://dev.laptop.org/ticket/12479
[2] https://dev.laptop.org/ticket/12503
Signed-off-by: Martin Abente Lahaye<EMAIL_ADDRESS>

@godiard can you give it a try?

Tested on XO-1, disconnecting wifi and ad-hoc, the same error is present. Merged.
Please send a email to sugar-devel explaining the problem and requesting activity developers do a update.


Nominator: Allow multiple nominations per round

SCP rules allows nodes to nominate multiple values.
Only constraint is that once a node confirms a nomination, it should
stop nominating new values.

it should stop nominating new values

Technically the node can choose to do whatever it wants, but other (non-faulty/non-byzantine) nodes will ignore the new values if they know that node has already confirmed something.
Anyway just trying to clear it up for everyone.

it should stop nominating new values

Technically the node can choose to do whatever it wants, but other (non-faulty/non-byzantine) nodes will ignore the new values if they know that node has already confirmed something.
Anyway just trying to clear it up for everyone.

I wonder what is the background of this change. At the end of the 10 mins interval when the nomination begins, the set of transactions will be fairly stable. Once we called the nominate method of the SCP, then there is an internal timer inside SCP that kicks in, and tries to renominate the same set of transactions(and other node's nominations too) that were passed into the nominate method for that round.

I wonder what is the background of this change. At the end of the 10 mins interval when the nomination begins, the set of transactions will be fairly stable. Once we called the nominate method of the SCP, then there is an internal timer inside SCP that kicks in, and tries to renominate the same set of transactions(and other node's nominations too) that were passed into the nominate method for that round.

I wonder what is the background of this change. At the end of the 10 mins interval when the nomination begins, the set of transactions will be fairly stable. Once we called the 'nominate' method of the SCP, then there is an internal timer inside SCP that kicks in, and tries to renominate the same set of transactions(and other node's nominations too) that were passed into the 'nominate' method for that round.

Flexibility mostly, we should not tie our own hands. IMO, we should take advantage of the SCP as much as we can.
If I am not mistaken, nomination phase can take arbitrarily long. So letting nodes nominate multiple values could help.

I wonder what is the background of this change. At the end of the 10 mins interval when the nomination begins, the set of transactions will be fairly stable. Once we called the 'nominate' method of the SCP, then there is an internal timer inside SCP that kicks in, and tries to renominate the same set of transactions(and other node's nominations too) that were passed into the 'nominate' method for that round.

Flexibility mostly, we should not tie our own hands. IMO, we should take advantage of the SCP as much as we can.
If I am not mistaken, nomination phase can take arbitrarily long. So letting nodes nominate multiple values could help.

Please make a note of the original issue from which this PR comes, like "Part of #1228"

Please make a note of the original issue from which this PR comes, like "Part of #1228"

Please make a note of the original issue from which this PR comes, like "Part of #1228" in the description of this PR. It can make us find the original issue.

Well, this is not necessarily part of any existing issue tho. It is more like an overall improvement.

Please make a note of the original issue from which this PR comes, like "Part of #1228" in the description of this PR. It can make us find the original issue.

Well, this is not necessarily part of any existing issue tho. It is more like an overall improvement.

Looks good now, just please squash.

Looks good now, just please squash.

Looks good now, just please squash.

Done

Looks good now, just please squash.

Done


Update elixir_agi package

Hey,
Can we update elixir_agi package in hex so new commands can be usable?
Thank you very much

Done!


Allow user to specify resolution when downloading a screenshot

Is your feature request related to a problem? Please describe.
I'm happy that I can take a high quality image of my diagram via the screenshot button, but I want to be able to increase or decrease quality and change the dimensions as I want, so that I can get exactly the image I want, perhaps for a desktop background, or a print-out diagram.
Describe the solution you'd like
When I click the screenshot button, I want to specify the resolution of the image:

Describe alternatives you've considered
Additional context
The screenshot button is in the MoreActionsDrawer, accessed here:

Technical ideas

MUI's dialog and text field (with input adornments) components seem like they should work well for this
Zod + react-hook-form could also be good for ensuring the inputs are valid when submitting the dialog, similar to how we validate topic description here:

Thank you so much

So how do I start.
Should clone this to my system and create a new branch to fix that or what?

Thank you for getting back to me so quickly, but I need some direction on
what I will do to start on the fixes of this issue. Please pull off a
detailed roadmap for me?
On Mon, 7 Oct 2024 at 17:56, Joel Keyser @.***> wrote:

Assigned #339 https://github.com/amelioro/ameliorate/issues/339 to
@Emmanuel-222 https://github.com/Emmanuel-222.
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#event-14544016272, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3IMOEC7K4LNM2MLOBTZ2K4LTAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUGU2DIMBRGYZDOMQ
.
You are receiving this because you were assigned.Message ID:
@.***>

Hey @Emmanuel-222 no problem 🙂

check out the CONTRIBUTING.md file; it's got info about running the project, an overview of the code, and a link at the bottom for the PR process (you'll need to fork this repo and make your changes on your own branch there)
I realize the text in the screenshot is a bit outdated, it says "download screenshot" now - if you search for that text in the repo you'll find the current logic for downloading a screenshot without yet being able to specify the resolution
instead of downloading the screenshot right away, we should be able to open a modal to specify the resolution (then confirming the dialog should trigger the download logic). we're actually doing something similar for renaming a View, so that logic might be able to help you get started. you can find that View-rename dialog on the playground:

How does that sound? Let me know if you have any more questions.

Hi Joel,
I am still on the installation process, but after following the
contribution.md file I had an error.
Here is a screenshot.
On Mon, 7 Oct 2024 at 19:42, Emmanuel Ogbuefi @.***>
wrote:

Thanks, I'll check it out right away!
On Mon, 7 Oct 2024 at 19:25, Joel Keyser @.***> wrote:

Hey @Emmanuel-222 https://github.com/Emmanuel-222 no problem 🙂

check out the CONTRIBUTING.md
https://github.com/amelioro/ameliorate/blob/main/CONTRIBUTING.md
file; it's got info about running the project, an overview of the code, and
a link at the bottom for the PR process (you'll need to fork this repo and
make your changes on your own branch there)
I realize the text in the screenshot is a bit outdated, it says
"download screenshot" now - if you search for that text in the repo you'll
find the current logic for downloading a screenshot without yet being able
to specify the resolution
instead of downloading the screenshot right away, we should be
able to open a modal to specify the resolution (then confirming the dialog
should trigger the download logic). we're actually doing something similar
for renaming a View
https://github.com/amelioro/ameliorate/blob/8b8c16920c84b2e3ae89abd5c2bc5ffbf52c43b1/src/web/topic/components/TopicPane/QuickViewSection.tsx#L110-L118,
so that logic might be able to help you get started. you can find that
View-rename dialog on the playground
https://ameliorate.app/playground:
image.png (view on web)
https://github.com/user-attachments/assets/0faa204d-3150-45e3-b2e8-130d8da05ccd

How does that sound? Let me know if you have any more questions.
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2397601577,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3LFZD6QDYDP35BGSTTZ2LGZJAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJXGYYDCNJXG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hey @Emmanuel-222 , I don't see a screenshot in your post

Sorry about that, here it is. [image: Screenshot 2024-10-08 114825.png]
On Tue, 8 Oct 2024 at 14:30, Joel Keyser @.***> wrote:

Hey @Emmanuel-222 https://github.com/Emmanuel-222 , I don't see a
screenshot in your post
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2399856795,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3MD2QBMCV2KJZUJZODZ2PNAXAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHA2TMNZZGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

I sent it has an attachment, probably didn't load up
On Tue, 8 Oct 2024 at 16:19, Emmanuel Ogbuefi @.***>
wrote:

Sorry about that, here it is. [image: Screenshot 2024-10-08 114825.png]
On Tue, 8 Oct 2024 at 14:30, Joel Keyser @.***> wrote:

Hey @Emmanuel-222 https://github.com/Emmanuel-222 , I don't see a
screenshot in your post
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2399856795,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3MD2QBMCV2KJZUJZODZ2PNAXAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHA2TMNZZGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Emmanuel-222 I think replying on this thread via email does not allow attachments - seems like others have had this issue https://github.com/orgs/community/discussions/52761. If you want to include the image, you probably need to post it on GitHub directly. If email is easier right now, perhaps you could post an error message in text rather than a screenshot?

This is it 👆👆

@Emmanuel-222 I found this WSL issue that seems promising - can you try the steps here https://github.com/microsoft/WSL/issues/5923#issuecomment-1215454084?
In summary, if you run wsl -l before entering WSL, and it shows docker as your default WSL distro, you should use wsl -s <other distro, Ubuntu for me> to set the distro properly, and maybe you'll need to restart your apps that are using wsl for that to take affect. I guess this is a bug that can happen when installing docker?
Let me know if that doesn't fix it!

It fixes it and show another error on running "npm run dev"

@keyserj
I fixed it.

This is the final thing that is stopping me

@Emmanuel-222 the last line in setupLocal runs docker build -t mock-auth mock-auth/ to build a mock-auth image for mocking login locally. You can run docker image ls to see if the build command successfully created the mock-auth image (latest is just the default tag that's applied). If you don't have that image, try running docker build -t mock-auth mock-auth/ again and see if there are errors.
FYI - commenting here is totally fine, but if you have Discord that might be faster to get through back-and-forth. This is the Discord server for Ameliorate and I'm generally available there for messaging.

@keyserj the project has finally started working.
I wanted to ask where the function is in.
Which file?

Refer back to https://github.com/amelioro/ameliorate/issues/339#issuecomment-2397601577
Generally a good way to find where code is, is to search the repo for text that shows up in the UI. That's why I suggested to search for "download screenshot". That should lead you to the button, which has an onClick, and you can trace the code from there. You'll also probably find it helpful to see existing logic to open a modal, which I link to in the comment above.

Okay thank you. Then about login. Still stuck.

The contributing guide's Running the project mentions that the mock auth service allows you to enter any user/pass to login, and it'll approve you.
Technically for this task, I think you should be able to do everything you need from the playground, but logging in doesn't hurt if you want to explore more.

Hi @keyserj,
This is what I have worked on so far. What do you think?
https://github.com/user-attachments/assets/7f232792-8c23-468f-b06a-7b1d8ec7afc6

Hey @Emmanuel-222, that looks pretty cool! I use a tool to take screenshots like this all the time, and it's nice to see what the code might look like.
But I think for the purposes of this issue, this solution has a few significant drawbacks.
First off, to clarify: the width and height that we're currently using for the resolution do not affect what content is in the image, they only affect the size that the image is scaled to. The nodeBounds variable is what determines what's in the image.
So the area being captured for the screenshot is currently unchangeable - it always captures all of the nodes being displayed, fits them within the image, and centers them. That's intentional, so that you don't have to spend effort repositioning or zooming-to-fit your diagram, or only snapping certain parts of it. If you ever want to only capture certain nodes, you can just filter out the other nodes. Manually capturing an area takes more work to get what you want, and each snapshot you take will likely be slightly different than if you try taking another.
Another downside of the manual capture is that you can only capture a region that fits within your monitor's size. The default resolution is currently larger than my monitor, which enables a higher quality e.g. you can zoom into the screenshot and see more pixels than you can see just looking at the diagram via the app on your monitor.
For these reasons, I think the solution initially suggested by this issue would be better. Namely, this is the solution in the image below, where a modal is provided to enter pixel values if the user desires.

@Emmanuel-222
Regarding how the code currently works: if you change the lines that hardcode the resolution, say you decrease these from 2560 x 1440 to 1920 x 1080, you'll still get the same nodes in the image, centered in the same spot. But the KB of the image file will be smaller, and the image might look a little more blurry, because there are fewer pixels being used.
This GitHub issue is asking for a modal where you can enter these two numbers. This modal should look and behave very similarly to the Quick View modal in the gif below (but instead of accepting Title, it should accept Width and Height:

Let me know if there's anything more specific that I can clear up.

Hi @joel,
So I think for this one it would be for good user experience that the user
maybe not of necessity should only see the resolution(height and width) as
they drag the cursor for screenshots. What do you think?
On Tue, Oct 15, 2024, 14:07 Joel Keyser @.***> wrote:

@Emmanuel-222 https://github.com/Emmanuel-222
Regarding how the code currently works: if you change the lines that
hardcode the resolution
https://github.com/amelioro/ameliorate/blob/b2256c2139a8228cb5e2e6854b2ba7c5ae86ec6f/src/web/topic/components/TopicWorkspace/MoreActionsDrawer.tsx#L70-L71,
say you decrease these from 2560 x 1440 to 1920 x 1080, you'll still get
the same nodes in the image, centered in the same spot. But the KB of the
image file will be smaller, and the image might look a little more blurry,
because there are fewer pixels being used.
This GitHub issue is asking for a modal where you can enter these two
numbers. This modal should look and behave very similarly to the Quick View
modal in the gif below (but instead of accepting Title, it should accept
Width and Height:
chrome_2024-10-10_10-13-35.gif (view on web)
https://github.com/user-attachments/assets/c8d9d003-1938-4f01-bffb-632f30bd1a9a
Let me know if there's anything more specific that I can clear up.
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2413867831,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3KFO63JEXCPBYFCGYLZ3UHRHAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJTHA3DOOBTGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Emmanuel-222 as I mentioned above, dragging the cursor to take the screenshot is not desirable because:

user has to spend effort repositioning the diagram before screenshotting. with the current solution, the diagram is automatically centered in the screenshot.
user has to spend effort setting the desired zoom before screenshotting. with the current solution, the diagram is automatically zoomed to fit the size of the screenshot.
user can only capture a screenshot that fits within their monitor's size. with the desired solution (entering width x height), you can take a screenshot of any resolution quality you want.

Do these points make sense?

Okay I will do just that.
I'm really sorry I'm just replying to this. In Nigeria we had a total
blackout for a while due to our energy grid collapsing, so most of what I
have been doing has been solely my work. I will get on this as soon as
possible. Thank you.
On Thu, Oct 17, 2024, 15:01 Joel Keyser @.***> wrote:

@Emmanuel-222 https://github.com/Emmanuel-222 as I mentioned above,
dragging the cursor to take the screenshot is not desirable because:

user has to spend effort repositioning the diagram before
screenshotting. with the current solution, the diagram is automatically
centered in the screenshot.
user has to spend effort setting the desired zoom before
screenshotting. with the current solution, the diagram is automatically
zoomed to fit the size of the screenshot.
user can only capture a screenshot that fits within their monitor's
size. with the desired solution (entering width x height), you can take a
screenshot of any resolution quality you want.

Do these points make sense?
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2419637013,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3JIUEKPFHVKO6PINATZ367KPAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJZGYZTOMBRGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Emmanuel-222 no worries, sorry to hear about the blackout.

Hey @Emmanuel-222 thanks for looking at this ticket - I'm going to unassign you to open this ticket for others. Let me know if you're still working on it and I can reassign you.

Sure @joel still working on this.
Just a bit carried away due to the season 😀. Compliment of the season 😀
On Fri, Dec 27, 2024, 21:14 Joel Keyser @.***> wrote:

Hey @Emmanuel-222 https://github.com/Emmanuel-222 thanks for looking at
this ticket - I'm going to unassign you to open this ticket for others. Let
me know if you're still working on it and I can reassign you.
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#issuecomment-2564002917,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3OIOYHS7X2HZ3ZDDGT2HWYJNAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGAYDEOJRG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

How many times did you send this message ?
On Fri, Dec 27, 2024, 21:25 Joel Keyser @.***> wrote:

Assigned #339 https://github.com/amelioro/ameliorate/issues/339 to
@Emmanuel-222 https://github.com/Emmanuel-222.
—
Reply to this email directly, view it on GitHub
https://github.com/amelioro/ameliorate/issues/339#event-15774725889, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A2SYH3PXQT57PNM3PIO75X32HWZURAVCNFSM6AAAAABPQJUSHOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVG43TINZSGU4DQOI
.
You are receiving this because you were assigned.Message ID:
@.***>

Once on this issue, once on the associated PR.


Feature/api visibility

Closes #1020
Proposed changes

add visibility field
add visibilitySwitch to API view

Also fixes undefined initial value for bookmarkCount

@apinf/developers please review

Found issue with @brylie in router "apiBackend.findOne" call, not yet able to solve. Happens when creating Api Backend.

This is ready for review.

@frenchbread Could you review this PR?

Code looks good!
Tested & noticed that API is not showing up on My bookmarked APIs tab. (I think it's logical to show to a user his API wether it's private or not)

Also FYI, was not able to create new user to test with different permissions. Tested with no logged in user

@frenchbread, I am able to add multiple users. Perhaps do meteor reset? What are steps to reproduce the second user issue?

Tested & noticed that API is not showing up on My bookmarked APIs tab. (I think it's logical to show to a user his API wether it's private or not)

I have added a change that shows private bookmarked APIs, if the user is a manager of the API and has also bookmarked it. Private APIs should only show up for managers, regardless of whether a user has previously managed to bookmark the API.

I am able to add multiple users. Perhaps do meteor reset? What are steps to reproduce the second user issue?

@brylie Ran meteor reset & even got new keys, did not solve the issue.

Thanks for fixes. This looks good. Merging.


Handle Swagger Schema Objects

Hi,
I'm using Swagger to define Schema Objects which are based on the JSON Schema Specification Draft 4.
I have a standalone example that you can find here:
https://gist.github.com/jeremyb/a0419ad9d5501fb602f052169112166f
I'm curious to know if you might be interested to make symfony-json-rest-api works with Swagger (not only with separate JSON Schema files).
Currently, I see some issues with the PayloadValidator class (especially with $jsonSchemaFilename: file_exists and realpath calls).
Also, we probably need to update JsonSchemaTools to allow the creation from a SchemaStorage?
Do you have some ideas about how to handle that? I'm available to contribute in the next days/weeks :)

Hi !

I'm curious to know if you might be interested to make symfony-json-rest-api works with Swagger (not only with separate JSON Schema files).

Definitively yes! Swagger is close to be mainstream. I guess we should keep decoupled stuff but we can make effort to make swagger validation compatible.
I guess we could enforce the usage of SchemaStorage even for simple jsonSchema. Let say a SchemaLoader,  so the realpath and file_exists would be done outside the validator. (SRP will thank us).
Something like
<?php

namespace Rezzza\SymfonyRestApiJson;

class PayloadValidator
{
    private $jsonSchemaTools;

    private $schemaloader;

    public function __construct(JsonSchemaTools $jsonSchemaTools, SchemaLoader $schemaloader)
    {
        $this->jsonSchemaTools = $jsonSchemaTools;
        $this->schemaloader = $schemaloader;
    }

    public function validate($payload, $validationPath)
    {
        $validationSchema = $this->schemaloader->schemaOfPath($validationPath);

        $delegateValidator = $this->jsonSchemaTools->createValidator();
        $refResolver = $this->jsonSchemaTools->createRefResolver();

        $delegateValidator->check(
            json_decode($payload),
            $refResolver->resolve($validationSchema->asString())
        );

        if (!$delegateValidator->isValid()) {
            throw InvalidPayload::withErrors($payload, $jsonSchemaFilename, $delegateValidator->getErrors());
        }
    }
}

where schema loader would accept an array of id => filepath in construct (we could event support http in a next step).
So for your example:
new SchemaLoader([
    'petstore' => 'https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v2.0/json/petstore-simple.json'
]);

and in routing.yml
route:
     _jsonSchema: "petstore#/definitions/NewPet"

It would fix all issues, does not it ?

Hi @tyx
Sorry for the late response.
Basically, I really like what you purpose, especially the SchemaLoader part. And it would fix all the issues. The pain point to me is $refResolver->resolve($validationSchema->asString()) and in particular the asString(). Perhaps there's something to do with the justinrainbow/json-schema package with the UriRetriever for example? Do you see what I have in mind? It's just an idea for now, so I need to think more about this, and I didn't have enough time this week to investigate deeper :)

Ok yes may be we should have extra work around the refResolver but I'm sure it is not a big deal :p


WIP Friend List feature

Creating PR first to prevent bigbang

[x] Created a friendlist
[x] FriendList able to display on UI
[ ] Modify logic for friendList to display friends
[ ] FriendCommand
[ ] UnfriendCommand

Sick la


Complex artist lines fail to search

{"action":"PLAYING","serverid":"be032f85-0602-4b1b-9bca-9204244c05f8","channel":"discord","title":"House in LA","subtitle":"Jungle / The Wired Strings","album":"For Ever"}
startswith Jungle, The Wired Strings : Jungle / The Wired Strings

The root cause of this is a discrepancy between how roon reports plays and how the search API returns track data.
Playback separates multiple artists with the / character but the search lists use ,.  For an exact search we should replace slashes with commas when comparing.  But I've chosen to just strip off all secondary artists and limit the search to just the primary artist.  This seems like the most resilient approach, although it's possible the decision will cause undesired search hits because we're not being precise enough.  Will monitor and evaluate later.


[Feature][Connector-V2][TiKV] Support TiKV Source & Sink

Purpose of this pull request
Add new new connecotor of TiKV source and sink,
refer to https://github.com/apache/incubator-seatunnel/issues/1946#issuecomment-1253260625.

Check list

[x] Code changed are covered with tests.
[x] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

copy https://github.com/apache/incubator-seatunnel/pull/2830

Please resolve conflicts @Xuxiaotuan .

Please resolve conflicts @Xuxiaotuan .

get


Update MD file on new branch 2017-21-28_05-11-54

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Service listing page: segregate by framework, adapt URL scheme

Story https://trello.com/c/I0beYt9w/40-1-allow-services-page-to-filter-by-framework
In short, a supplier's service listing page has been segregated to provide listings by framework. Though for the hierarchy to continue making any sense, URLs of various pages living beneath /suppliers/services/<service_id> had to be moved to beneath /suppliers/frameworks/<framework_slug>/services/<service_id>.
The supplier dashboard has had its large "View services" link moved to the per-framework links:

The actual listing page is now at /suppliers/frameworks/<framework_slug>/services and has had its heading changed appropriately:

Service detail pages have been moved to /suppliers/frameworks/<framework_slug>/services/<service_id> and its breadcrumb pointing back to the listing page has been adjusted appropriately:

The section editing page has been moved to /suppliers/frameworks/<framework_slug>/services/<service_id>/edit/<section_name> and "listing" breadcrumb has been similarly updated:

The removal view has been moved too (though of course you can't see it from this screenshot):

A redirector has been added to cope with old links to services. This will universally redirect any URL beneath /suppliers/services/<service_id>(/trailing/path) to /suppliers/frameworks/<framework_slug>/services/<service_id>(/trailing/path) by looking up the services framework_slug (but notably only after checking access rights).

Looks a bit odd when there's an ongoing procurement... (The link at the top, above the supplier name.)
Maybe we don't need to fix this right now, but will need to before the next procurement opens:

Oh that is odd. It feels like something that should be in a banner maybe. @laurenceberry ?


[BACKLOG-18677] Kettle plugin classloader support for multiple plugin…

… jars
@pentaho/2-1b pls review

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/plugins/BasePluginType.java
  core/src/main/java/org/pentaho/di/core/plugins/JarFileAnnotationPlugin.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleSelectiveParentFirstClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleURLClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/PluginRegistry.java
  core/src/test/java/org/pentaho/di/core/plugins/PluginRegistryUnitTest.java
  engine/src/main/java/org/pentaho/di/core/plugins/JobEntryPluginType.java
  engine/src/main/java/org/pentaho/di/core/reflection/StringSearcher.java
  ui/src/main/java/org/pentaho/di/ui/spoon/Spoon.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.plugins.BasePluginType

Instruction Change: -.08%:small_red_triangle_down:
Line Change:  + .16%

org.pentaho.di.core.plugins.KettleURLClassLoader

Complexity Change: -2.88%:small_red_triangle_down:
Instruction Change: -.66%:small_red_triangle_down:
Line Change: -1.43%:small_red_triangle_down:
Method Change: -9.52%:small_red_triangle_down:

org.pentaho.di.core.plugins.Plugin

Branch Change: -16.67%:small_red_triangle_down:
Complexity Change: -4.44%:small_red_triangle_down:
Instruction Change: -1.40%:small_red_triangle_down:
Line Change: -2.38%:small_red_triangle_down:

org.pentaho.di.core.plugins.PluginRegistry

Branch Change:  + 5.34%
Complexity Change:  + 7.45%
Instruction Change:  + 3.81%
Line Change:  + 3.65%
Method Change:  + 2.20%

org.pentaho.di.core.plugins.PluginRegistry.new Comparator() {...}

Complexity Change: -100.00%:small_red_triangle_down:
Instruction Change: -100.00%:small_red_triangle_down:
Line Change: -100.00%:small_red_triangle_down:
Method Change: -100.00%:small_red_triangle_down:

org.pentaho.di.core.plugins.JobEntryPluginType

Branch Change: -5.91%:small_red_triangle_down:
Complexity Change: -1.18%:small_red_triangle_down:
Instruction Change: -.36%:small_red_triangle_down:

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .77%
Complexity Change:  + 1.02%
Instruction Change:  + .16%

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -1.32%:small_red_triangle_down:
Complexity Change: -1.85%:small_red_triangle_down:
Instruction Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -.10%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change: -1.92%:small_red_triangle_down:
Complexity Change: -1.69%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -1.04%:small_red_triangle_down:
Complexity Change: -1.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change: -2.00%:small_red_triangle_down:
Complexity Change: -1.89%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 3.37%
Complexity Change:  + 3.90%
Instruction Change:  + .34%
Line Change:  + .93%

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change:  + .06%

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change: -.14%:small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change:  + .10%

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change:  + .07%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceinsert.SalesforceInsertMeta

Instruction Change:  + .15%

org.pentaho.di.trans.steps.salesforceupdate.SalesforceUpdateMeta

Instruction Change:  + .17%

org.pentaho.di.ui.spoon.Spoon

Branch Change:  + .01%
Complexity Change:  + .00%
Instruction Change:  + .01%
Line Change:  + .00%
Method Change: -.01%:small_red_triangle_down:

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on core/src/main/java/org/pentaho/di/core/plugins/BasePluginType.java. Found 2016. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on core/src/main/java/org/pentaho/di/core/plugins/JarFileAnnotationPlugin.java. Found 2013. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on engine/src/main/java/org/pentaho/di/core/plugins/JobEntryPluginType.java. Found 2016. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on engine/src/main/java/org/pentaho/di/core/reflection/StringSearcher.java. Found 2013. Was expecting 2017

Checkstyle violations
The code submitted is not complying with one or more of our guidelines. To perform these checks locally, please use this tool.
/home/buildguy/project/core/src/main/java/org/pentaho/di/core/plugins/KettleSelectiveParentFirstClassLoader.java

:heavy_exclamation_mark: 'method call rparen' has incorrect indentation level 8, expected level should be 6. at Line: 50

You're probably right about logging something on those empty catch blocks, at this point I just trying to maintain previous "log free" behaviour.

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -Dsurefire.runOrder=alphabetical -B -fn -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,engine,core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/plugins/BasePluginType.java
  core/src/main/java/org/pentaho/di/core/plugins/JarFileAnnotationPlugin.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleSelectiveParentFirstClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleURLClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/PluginRegistry.java
  core/src/test/java/org/pentaho/di/core/plugins/PluginRegistryUnitTest.java
  engine/src/main/java/org/pentaho/di/core/plugins/JobEntryPluginType.java
  engine/src/main/java/org/pentaho/di/core/reflection/StringSearcher.java
  ui/src/main/java/org/pentaho/di/ui/spoon/Spoon.java

Newly Broken Tests:
org.pentaho.di.trans.steps.abort.AbortTest.testAbortAbortsWithInputRow:
:red_circle: org.mockito.exceptions.verification.WantedButNotInvoked
org.mockito.exceptions.verification.WantedButNotInvoked:

Wanted but not invoked:
trans.stopAll();
-> at org.pentaho.di.trans.steps.abort.AbortTest.testAbortAbortsWithInputRow(AbortTest.java:82)

However, there were other interactions with this mock:
trans.getSocketRepository();
-> at org.pentaho.di.trans.step.BaseStep.<init>(BaseStep.java:454)

trans.isRunning();
-> at org.pentaho.di.trans.step.BaseStep.waitUntilTransformationIsStarted(BaseStep.java:1779)

trans.isSafeModeEnabled();
-> at org.

org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization:
:red_circle: java.lang.RuntimeException
java.lang.RuntimeException: Error validating dateFormatLocale
	at org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization(TextFileInputMetaLoadSaveTest.java:167)
Caused by: org.pentaho.di.core.exception.KettleException:

Attribute dateFormatLocale started with value no_NO_NY ended with value no_no_ny

	at org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization(TextFileInputMetaLoadSaveTest.java:167)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: <0.1% (click to expand)
org.pentaho.di.core.plugins.BasePluginType

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.core.plugins.KettleURLClassLoader

Complexity Change: -2.9% :small_red_triangle_down:
Instruction Change: -0.7% :small_red_triangle_down:
Line Change: -1.4% :small_red_triangle_down:
Method Change: -9.6% :small_red_triangle_down:

org.pentaho.di.core.plugins.Plugin

Branch Change: -16.6% :small_red_triangle_down:
Complexity Change: -4.4% :small_red_triangle_down:
Instruction Change: -1.4% :small_red_triangle_down:
Line Change: -2.4% :small_red_triangle_down:

org.pentaho.di.core.plugins.JobEntryPluginType

Branch Change: -5.9% :small_red_triangle_down:
Complexity Change: -1.2% :small_red_triangle_down:
Instruction Change: -0.4% :small_red_triangle_down:

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -0.7% :small_red_triangle_down:
Complexity Change: -0.9% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Method Change: -1% :small_red_triangle_down:

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -1.9% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.pgbulkloader.PGBulkLoaderMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.9% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -Dsurefire.runOrder=alphabetical -B -fn -f 'pom.xml' -pl 'ui,.,engine,core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'ui,.,engine,core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,.,engine,core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/plugins/BasePluginType.java
  core/src/main/java/org/pentaho/di/core/plugins/JarFileAnnotationPlugin.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleSelectiveParentFirstClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/KettleURLClassLoader.java
  core/src/main/java/org/pentaho/di/core/plugins/PluginRegistry.java
  core/src/test/java/org/pentaho/di/core/plugins/PluginRegistryUnitTest.java
  engine/src/main/java/org/pentaho/di/core/plugins/JobEntryPluginType.java
  engine/src/main/java/org/pentaho/di/core/reflection/StringSearcher.java
  pom.xml
  ui/src/main/java/org/pentaho/di/ui/spoon/Spoon.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: <0.1% (click to expand)
org.pentaho.di.core.plugins.BasePluginType

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.core.plugins.KettleURLClassLoader

Complexity Change: -2.9% :small_red_triangle_down:
Instruction Change: -0.7% :small_red_triangle_down:
Line Change: -1.4% :small_red_triangle_down:
Method Change: -9.6% :small_red_triangle_down:

org.pentaho.di.core.plugins.Plugin

Branch Change: -16.6% :small_red_triangle_down:
Complexity Change: -4.4% :small_red_triangle_down:
Instruction Change: -1.4% :small_red_triangle_down:
Line Change: -2.4% :small_red_triangle_down:

org.pentaho.di.core.injection.bean.BeanInjector

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1.3% :small_red_triangle_down:

org.pentaho.di.core.plugins.JobEntryPluginType

Branch Change: -5.9% :small_red_triangle_down:
Complexity Change: -1.2% :small_red_triangle_down:
Instruction Change: -0.4% :small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.3% :small_red_triangle_down:
Line Change: -3.9% :small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Branch Change: -0.7% :small_red_triangle_down:
Complexity Change: -0.6% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -1.1% :small_red_triangle_down:
Complexity Change: -1.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -1.9% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -4.5% :small_red_triangle_down:
Complexity Change: -5.2% :small_red_triangle_down:
Instruction Change: -0.4% :small_red_triangle_down:
Line Change: -0.9% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -0.2% :small_red_triangle_down:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.


Allow to configure image quality in AdaptiveImageServlet

Feature Request
Allow to configure the quality value of the generated image binary from the AdaptiveImageServlet via content policies .
Currently only 1.0f is being hardcoded as 2nd parameter in https://helpx.adobe.com/experience-manager/6-2/sites/developing/using/reference-materials/javadoc/com/day/image/Layer.html#write(java.lang.String, double, java.io.OutputStream) in the AdaptiveImageServlet (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/54f5c002db11f34f9561a5eff09afa3af05741d9/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L365)
This leads to 100% quality (and therefore bigger file sizes for JPEG). In some cases it would be desirable to render with a different quality value.

Hi @kwin,
Thank you for creating this useful feature request. We will discuss it shortly and keep you updated.
CQ-4249803

Most probably it will be even more useful to define different quality factors per size and mimetype.

Just to stress how important this is I tried it out with the image from https://privatschutz.allianz.de/out/dwAllianzPrivat/img/background/startpage_full.jpg.
When delivering this with quality 1.0 with a width of 2048 pixels I end up with a size of 1.3 MB.
When reducing the quality factor to 0.8 with a width of 2048 pixels I end up with a size of 346 KB. With a factor 0.8 I can not see any noticeable quality difference and this ends up with a size of only 25%(!) compared to the one rendered with a quality of 1.0.
So even the default within Core WCM Components should not be 1.0 but rather much less.

One more related issue is with GIFs, due to the hardcoding of the 1.0 the number of colors is being reduced to 2 (within com.day.image.ImageSupport#doCreateGIFMetadata(...)).

As long as only JPEG is supported (GIF is never transformed and all other image types disregard the quality being given) it is most probably enough to configure it only once.


fix for issue #14

Coverage increased (+0.005%) to 94.805% when pulling c1ee10bd3c19451fdd40cb6d62bf7d71d1ac494e on pintman:master into 57f0b9901357112e475d79a1f14a3db139036678 on maphy-psd:master.


Backport "Avoid duplications of properties in pom.xml" to LTS

Backports #20020 to the LTS branch.
PR submitted by the release tooling.
[skip ci]

No regressions detected in the community build up to lts-20295.
Reference


Rename spsa_samples from confusing "batch_size"

This is independent from the size of the batch coming in (which must be one for SPSA)

Since this change breaks the API, would you be able to add a 6-month deprecation warning first?

Ah, good idea. Updated

OK to merge when tests pass


Make leds_increment to handle overflow

While leds_circular_shift handles overflow, it seems that leds_increment doesn't, so I just copied the corresponding part of the source code.

Can one of the admins verify this patch?

No need to handle it.


Expose the links feature in badge-maker

In order to utilize the 'links' feature in badge-maker, 'links' must be added to expectedKeys.

Messages

:book:

Thanks for contributing to our documentation. We :heart: our documentarians!

:book:
:sparkles: Thanks for your contribution to Shields, @dmatis!

  Generated by :no_entry_sign: dangerJS against fe0f4e09cb25ee4ba6f42d237f8317baef628ab2

Refs https://github.com/badges/shields/issues/4949
The main reason this isn't currently exposed in the package is because the way it works at the moment is a bit odd for legacy reasons. See related conversation (mixed in with some other discussion) in https://github.com/badges/shields/issues/4849#issuecomment-609108141
My current thinking on this (that I haven't actually done anything about) is that it would make more sense to expose it as labelLink and messageLink but as someone (maybe the only person :D ) who actually wants to use this feature for something, you might be a good person to give us some feedback on your use-case..

Hi @chris48s, we're building a dashboard with badges containing the deployed SHA for each of our environments. We would like the links feature so that we can click on the badge and redirect to the appropriate Github URL for that SHA. The links aren't static so unfortunately we're unable to statically add them to our Markdown.
We can't use Shields endpoint as described here: https://shields.io/endpoint because it's not accessible outside our VPN (so we need to create our own badge using badge-maker).

So in terms of just purely getting a thing done, if the link isn't always the same, you are right in terms of the options available to you. That said, if you're going to stand up your own server to render badges with badge-maker, another option would be to have the process issue a redirect to a custom static badge, or proxy the response.
So at the moment, you've got a function that does some stuff and then runs something like
makeBadge({
  label: 'build',
  message: 'passing',
  color: 'brightgreen',
})

and returns that string with a 200 OK response but then another way to achieve roughly the same end result is to generate the string build-passing-brightgreen instead of the JS object {label: 'build', message: 'passing', color: 'brightgreen' } and then issue a 302 Redirect to https://img.shields.io/badge/build-passing-brightgreen (or proxy the response, if you want).
If you did that, then I think that would allow you to just achieve what you're trying to do right now with the ?link param?

In terms of this feature, if you're keen to work on it I think exposing the public API labelLink and messageLink probably makes the most sense in the package but its a bigger job than just setting links = [labelLink, messageLink] because currently links[0] affects the whole badge when links.length == 1 but only the left side when links.length == 2. To make labelLink make sense as a param it should only ever affect the label (left) side of the badge but then just making that change in the package is then a BC break for the server so when we call out to makeBadge() in the server component we'll need to translate that to
labelLink = links[0]
messageLink = links[0]

if links.length == 1 to retain the existing behaviour of ?link for SaaS users. We'll also need tests for all that.
That said, if you don't want to work on it (esp if the above approach solves your immediate issue), this has at least prompted me to think through this issue again so I may end up tackling it.

@dmatis would you be keen on working on the solution that @chris48s outlined above? If not, I suggest we close this pull request, anyone can still feel free to pick this task up at a later stage. 😉


Feature request: toolchain for Nvidia Jetson Nano, Xavier, TX2  aarch64 hosts? (IDFGH-4618)

Many of us are using the New Nvidia Boards (Linux ARMx64)  for Learning and Development with GPU Accelerated application and AI, and would like to be able to develop for ESP32 using this board. I know there are recent support for Raspberry PI OS, would love to have it available on this platform too.
Thanks.

Any estimate on when this will be integrated. The linked issue indicates Q1 and we're getting near the end of Q1. I saw that the latest 4.3 beta release claims support for the new macos M1 platform which I expect would require a new release of the toolchain. Will this platform make it in?

Any updates on this?

Hi @SebastianBar, aarch64 toolchains (for Xtensa and RISC-V) are now provided and should be installed automatically when you run install.sh. This is available in master branch and in release v4.4.
We still don't have an aarch64 toolchain for ESP32 ULP coprocessor, so it won't be installed when running install.sh on aarch64. Aside from that, installation on aarch64 using install.sh should succeed. If you run into any issue, please share some details about your OS and the IDF version you are using.

not sure but I installed this last night, on a windows system 64 bit Intel, running in docker ubuntu, with the build instructions provided as of last night. 3/13/2022 10:pm I woke today, and just ran the test-rust-toolchain.sh and ran into this error, I followed the install instructions , including the dependency requirements..
`error: failed to run custom build command for `esp-idf-sys v0.30.6`

Caused by:
  process didn't exit successfully: `/root/rust-build/rust-esp32-std-demo/target/debug/build/esp-idf-sys-a70d87110bf5a3f6/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_VERSION
  cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=MCU
  PATH=/root/rust-build/rust-esp32-std-demo/.embuild/espressif/esp-idf-v4.3.2/tools:$PATH

  --- stderr
  Error: Could not install esp-idf

  Caused by:
      command '"python3" "/root/rust-build/rust-esp32-std-demo/.embuild/espressif/esp-idf-v4.3.2/tools/idf_tools.py" "--idf-path" "/root/rust-build/rust-esp32-std-demo/.embuild/espressif/esp-idf-v4.3.2" "--quiet" "--non-interactive" "install-python-env"' exited with non-zero status code 1`

@RepRapid indeed, the aarch64 related changes aren't present in release/v4.3. We could probably patch this in esp-idf-sys. Perhaps you can leave a comment in https://github.com/esp-rs/esp-idf-sys/issues/14?

@RepRapid indeed, the aarch64 related changes aren't present in release/v4.3. We could probably patch this in esp-idf-sys. Perhaps you can leave a comment in esp-rs/esp-idf-sys#14?

@igrr @JurajSadel As it is confirmed now that v4.4 should support aarch64, but toolchain is still not supporting!
So Can you please help me by providing the steps to get ESP-IDF set up on Jetson Nano?
"It don't require to install toolchain but it's still supports aarch64" sounds bit confusing to me.

We still don't have an aarch64 toolchain for ESP32 ULP coprocessor, so it won't be installed when running install.sh on aarch64

Is there a timeline for the ULP coprocessor support on aarch64? This is preventing me from compiling code on the rpi4 for ESPhome.. I know there are workarounds like compiling on a different machine but this particular program (ESPhome) requires re-compilation on any settings change for the devices so it is inconvenient.

Any news on this?
Same issue on my odroid n2+
Processing midesklamp1s (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
Tool Manager: Installing platformio/toolchain-esp32ulp @ ~1.22851.0
INFO Installing platformio/toolchain-esp32ulp @ ~1.22851.0
Error: Could not find the package with 'platformio/toolchain-esp32ulp @ ~1.22851.0' requirements for your system 'linux_aarch64'

We have the new pre-release of binutils for the ULP ready here, but we need some time to integrate it into ESP-IDF. Unfortunately it's not a drop-in replacement as some of the arguments have changed. We'll update this ticket once the changes are merged in IDF!

@igrr thx a lot.
just let us know an we can test it.

ULP toolchain has been updated in the master branch in https://github.com/espressif/esp-idf/commit/a9bd454529e0e3a7b9207b079d8d511e1ca76a07 and now supports aarch64 Linux.
This will be backported to release/v4.4 branch as well.

@igrr
thx a lot!
Any hints when the home assistant get's this update?
Currently running "ESPHome Current version: 2022.8.3"
thx

tried today with the newest esphome 9.2 release an got the same error:
INFO Reading configuration /config/esphome/schreibtisch.yaml...
WARNING GPIO2 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing midesklamp1s (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
Tool Manager: Installing platformio/toolchain-esp32ulp @ ~1.22851.0
INFO Installing platformio/toolchain-esp32ulp @ ~1.22851.0
Error: Could not find the package with 'platformio/toolchain-esp32ulp @ ~1.22851.0' requirements for your system 'linux_aarch64'

@popy2k14 Since there is no official release for IDF 4.4.3 all the new stuff is not yet in Platformio. I dont use esphome nor have i skills how to setup anything there.
If you manage to use my Platformio fork you can use the new patch5 toolchains and ULP v2.35. The setup is
platform = https://github.com/Jason2866/platform-espressif32.git#new_ULP

ok, thx. thought that it was released already.
i can wait until it's released :-)
thx

ULP toolchain has been updated in the master branch in a9bd454 and now supports aarch64 Linux. This will be backported to release/v4.4 branch as well.

Any timeline available when this 4.4 including ULP toolchain for ESP32 on Aarch64 would be available?

@mkruiver it is available in release/v4.4 branch now, since the commit a8e81f8

Thansk for the quick response!
However, it seems there has not been a 4.4 release since this commit, so effectively not available yet?
The latest 4.4 is from more than 28 days ago, it seems?
https://github.com/espressif/esp-idf/releases/tag/v4.4.2

Clear, thanks! (I am using IDF via another framework, so will wait for the
next 4.4.x release) :)
Thanks a lot for the extensive replies on this thread!
On Sun, Oct 9, 2022, 13:47 Ivan Grokhotkov @.***> wrote:

Of you are using IDF directly and if you need this functionality you can
either git checkout the latest release/v4.4 branch or cherry-pick that
commit.
If you are using IDF via other frameworks (Arduino, Platformio, etc) then
you'll have to wait until the next 4.4.x bugfix release is published. (I
can't give an estimate of when that will happen, but you can subscribe to
IDF release notifications here on Github.)
—
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/6432#issuecomment-1272524401,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5HT7ZN44NL5GO6SEOO7RLWCKWEJANCNFSM4WJ4SVUA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Any hint's i can get the 4.4 release branch to build on my arm 64 odroid n2+ with HA esphome addon:
What i am currently using is an rather old package, but OTA isnt working:
esphome:
  name: midesklamp1s
  platformio_options:
    platform_packages:
      - framework-arduinoespressif32 @ https://github.com/pauln/arduino-esp32.git#solo-no-mac-crc/1.0.6
    platform:
      -<EMAIL_ADDRESS>
esp32:
  board: esp32doit-devkit-v1

i want to use the newest 4.4 to check if OTA works.
Sure i can flash with serial the first time.
Sadly i cant compile it because of the ulp toolchain issue of current releases.
I also have the info, that the package i previously used (solo-no-mac-crc branch) should have the folloiwing config:
esphome:
  name: midesklamp1s

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: true

Any hints how i can add the current 4.4 release where the toolchain is fixed? to the last xaml?
thx

@popy2k14 What do you need now? Solo1 (CONFIG_FREERTOS_UNICORE: y) support or not?
If solo1 is needed idk if this is working.
esphome:
  name: midesklamp1s
  platformio_options:
    platform:
      - https://github.com/tasmota/platform-espressif32/releases/download/v<IP_ADDRESS>/platform-espressif32-<IP_ADDRESS>.zip

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: true

Thanks for trying to help. Sadly doesnt work:
Platform Manager<EMAIL_ADDRESS>has been installed!
INFO<EMAIL_ADDRESS>has been installed!
Platform Manager: Removing espressif32 @ 2.0.5
INFO Removing espressif32 @ 2.0.5
Platform Manager<EMAIL_ADDRESS>has been removed!
INFO<EMAIL_ADDRESS>has been removed!
Error: Development platform 'espressif32' is not compatible with PlatformIO Core v6.0.2 and depends on PlatformIO Core >=6.1.0.

You have to upgrade your platformio version to 6.1 or newer

SAure i would, but esphome is an addon in an supervisor which i dont have control over.

See my changes above

Try this one. I changed the platformio version requirement to 6.0.2
esphome:
  name: midesklamp1s
  platformio_options:
    platform:
      - https://github.com/Jason2866/platform-espressif32/releases/download/v2.0.5-esp/platform-espressif32-2.0.5-esp.zip

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: true

thx a lot, now we are step further.
it builds it but fails with:
Compiling /data/midesklamp1s/.pioenvs/midesklamp1s/src/esphome/core/scheduler.o
Compiling /data/midesklamp1s/.pioenvs/midesklamp1s/src/esphome/core/util.o
Compiling /data/midesklamp1s/.pioenvs/midesklamp1s/src/main.o
*** [/data/midesklamp1s/.pioenvs/midesklamp1s/memory.ld] Source `/data/cache/platformio/packages/framework-espidf/components/esp_system/ld/esp32/memory.ld.in' not found, needed by target `/data/midesklamp1s/.pioenvs/midesklamp1s/memory.ld'.
========================= [FAILED] Took 136.13 seconds =========================

Delete hidden folder .platformio Looks like old stuff is there. If this does not work esphome does changes "somewhere" which are not compatible to plain origi. Platformio

Tried to rename the device, this way it uses /data/midesklamp1ss/ directory instead of /data/midesklamp1s/, so tehre should be no garbage from old builds. Sadly same issue.
Also uninstalled esphome addon and reinstalled to clear all garbage -> same issue.
Sorry to be OT here.
Just one last OT question.
Can you please post the needed tasmota config for the "1S" lamp.

https://templates.blakadder.com/mi_desk_lamp.html

HUGE THX!
Was looking a while ago for tasmota support without luck.
It seems as of 09:2022 the 1S is supported!
thx a lot!

Hi @Jason2866 ,
I just came from this issue:
https://github.com/esphome/issues/issues/3093
Can you help me with this error I'm getting on my Pi 4 ARM when trying to compile in esphome:
/bin/sh: 1: /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc: not found

@cvjensen  The arm toolchains are not yet official supported in platformio.
You can try my fork which does support.j
To use with platformio this entry is needed.
platform = https://github.com/tasmota/platform-espressif32/releases/download/v<IP_ADDRESS>/platform-espressif32-<IP_ADDRESS>.zip

Idk if it is possible to use with HA. I am NOT using HA nor Esphome.

It keeps giving me the error:
Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_6d7a8 && [1/2] Building C object CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj
/data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc   -mlongcalls -o CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj   -c testCCompiler.c
/bin/sh: 1: /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc: not found
ninja: build stopped: subcommand failed.

I just tried to log in to the docker container running esphome and it seems like the file is there:
root@5c53de3b-esphome:/# ls -l /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-g++
-rwxr-xr-x 1 root root 778104 Feb 11  2022 /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-g++
root@5c53de3b-esphome:/# ls -l /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc
-rwxr-xr-x 1 root root 774008 Feb 11  2022 /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc

Any idea who I can contact to get help?

No one, wait until it is supported or install ESPhome / HA on X86 machine.

It keeps giving me the error:
Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_6d7a8 && [1/2] Building C object CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj
/data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc   -mlongcalls -o CMakeFiles/cmTC_6d7a8.dir/testCCompiler.c.obj   -c testCCompiler.c
/bin/sh: 1: /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc: not found
ninja: build stopped: subcommand failed.

I just tried to log in to the docker container running esphome and it seems like the file is there:
root@5c53de3b-esphome:/# ls -l /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-g++
-rwxr-xr-x 1 root root 778104 Feb 11  2022 /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-g++
root@5c53de3b-esphome:/# ls -l /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc
-rwxr-xr-x 1 root root 774008 Feb 11  2022 /data/cache/platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gcc

Any idea who I can contact to get help?

No one, wait until it is supported or install ESPhome / HA on X86 machine.

When will it be supported ?


Docs/4/mattykyu documentation

Pull Request
Description:

Implemented MVP of Project Documentation and added commit linters, semantic versioning, automatic changelog generators, and commitizen support.
Related Issue:

Closes #2 and #4

Shelf for now.


Issue with axios

Describe the bug
Error after add axios.
Reproduction
I have tried

yarn add axios
yarn dev
It freezes a few minutes, then error (see log bellow).

After, i have tried
module.exports = {
    optimizeDeps: {
        exclude: ['vue-api-query','axios'],
    },
}

On main.js add import axios from 'axios'
yarn dev
Then error:

Uncaught SyntaxError: The requested module<EMAIL_ADDRESS>does not provide an export named 'default'

System Info

required vite version: 0.15.3
required Operating System: Linux
required Node version: 12

Logs
<--- Last few GCs --->

[6622:0x563155d83da0]   116039 ms: Scavenge 2035.8 (2040.5) -> 2035.0 (2040.5) MB, 8.1 / 0.0 ms  (average mu = 0.350, current mu = 0.430) allocation failure
[6622:0x563155d83da0]   116105 ms: Scavenge 2035.8 (2040.5) -> 2035.0 (2040.7) MB, 8.7 / 0.0 ms  (average mu = 0.350, current mu = 0.430) allocation failure
[6622:0x563155d83da0]   116173 ms: Scavenge 2035.9 (2040.7) -> 2035.0 (2040.7) MB, 8.6 / 0.0 ms  (average mu = 0.350, current mu = 0.430) allocation failure

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x563153079999]
Security context: 0x264110dc08a1 <JSObject>
    1: load [0x3e9297d23f71] [/var/www/app/my-app/node_modules/resolve/lib/async.js:~154] [pc=0x387b25586cb2](this=0x12a4913048f1 <JSGlobal Object>,0x3e9297d23ff9 <JSArray[7]>,0x3e9297d23f11 <String[43]: /var/www/app/my-app/node_modules/zlib/index>,0x2d6c1ee404a9 <undefined>)
    2: loadAsFile [0x36e349ebf21] [/var/www/app/my-app/node_modules/resolve/lib/asy...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

I think you might have to use an es module version of axios. Maybe something like this: https://www.npmjs.com/package/@bundled-es-modules/axios (didn't test it, just found it on google). Or use snowpack to convert the official module.

Maybe we should support commonjs module or umd module...Or compiled them into es module.

I used snowpack to compile axios to esmodule, it works vite 0.14.4

Yeah this is supposed to work, the pre-bundling still needs some tuning.

I used snowpack to compile axios to esmodule, it works vite 0.14.4

How can I do that ?

npm i -D snowpack
add axios to package.json...
"snowpack": {
"webDependencies": [
"axios",
npx snowpack
then... import axios from 'axios'
Warmest Regards,
Aaron
The information herein is given on a general basis without obligation and
is strictly for information purposes only. We do not warrant the accuracy
or completeness of the information, graphics, links, or other items
contained herein, and expressly disclaim liability for errors or omissions
in these materials.
On Tue, May 19, 2020 at 1:34 AM hamza0867<EMAIL_ADDRESS>wrote:

I used snowpack to compile axios to esmodule, it works vite 0.14.4
How can I do that ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vite/issues/174#issuecomment-630332034, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABAWBHRPP2LBD2Q5SLXCXMDRSFWT3ANCNFSM4NDTIHAQ
.

thanks @ais-one

Closing to track in #162

maybe you can try fetch()


Add experimental & deprecated flags on errors

Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #301

PR #302

PR #303

PR #304

PR #305

PR #306

PR #307

PR #309   👈

This stack of pull requests is managed by Graphite.


input format parameter when using a SQL db

The input format in this case is either "mysql" or "postgresql". These are not really input formats per se, would it perhaps make more sense to have a separate --db-type parameter that is only used when connecting to dbs?

Not sure, I think it overcomplicates the config. The "input format" selects the Reader, maybe we can change the name of the option but I would keep "mysql" and "postgresql" with the others. I left it like this because for rdf the input format is always the same but if a remote address is provided the connection is performed to the remote triplestore.


nixos/grub: Name initrd-secrets by system, not by initrd

Previously, secrets were named according to the initrd they were
associated with. This created a problem: If secrets were changed whilst
the initrd remained the same, there were two versions of the secrets
with one initrd. The result was that only one version of the secrets would
by recorded into the /boot partition and get used. AFAICT this would
only be the oldest version of the secrets for the given initrd version.
This manifests as #114594, which I found frustrating while trying to use
initrd secrets for the first time. While developing the secrets I found
I could not get new versions of the secrets to take effect.
Additionally, it's a nasty issue to run into if you had cause to change
the initrd secrets for credential rotation, etc, if you change them and
discover you cannot, or alternatively that you can't roll back as you
would expect.
Additional changes in this patch.

Add a regression test that switching to another grub configuration
with the alternate secrets works. This test relies on the fact that it
is not changing the initrd. I have checked that the test fails if I
undo my change.

Persist the useBootLoader boot disk state, similarly to other state.

I had to do this, otherwise I could not find a route to testing the
alternate boot configuration. I did attempt a few different ways of
testing this, including directly running install-grub.pl, but what
I've settled on is most like what a user would do and avoids
depending on lots of internal details.
Making tests that test the boot are a bit tricky (see hibernate.nix
and installer.nix for inspiration), I found that in addition to
having to copy quite a bit of code I still couldn't get things to
work as desired since the bootloader state was being clobbered.

My change to persist the useBootLoader state could break things,
conceptually. I need some help here discovering if that is the case,
possibly by letting this run through a staging CI if there is one.
Fixes #114594.
cc potential reviewers:
@lopsided98 (original implementer) @joachifm (original reviewer),
@wkennington (numerous fixes to grub-install.pl), @lheckemann (wrote
original secrets test).
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Rebased and per @rnhmjoj's comment, introduced virtualisation.persistBootDevice used to control the disk persistence, leaving the default as false.

We should do the same change in systemd-boot, which is the only other bootloader that sets supportsInitrdSecrets = true. The script is in
nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py


Boolean operations: "Requested capacity is too large" on MacOs Sonoma.

Description of bug
../../../../../../src/cpp/skia-builder/skia/src/base/SkContainers.cpp:106: fatal error: "Requested capacity is too large." zsh: trace trap  manim discord.py -pql --disable_caching -v WARNING
How to reproduce the issue
import manim as mn

class Example(mn.Scene):
    def construct(self):
        sq = mn.Square(color=mn.RED, fill_opacity=1)
        sq.move_to([-2, 0, 0])
        cr = mn.Circle(color=mn.BLUE, fill_opacity=1)
        cr.move_to([-1.3, 0.7, 0])
        un = mn.Difference(sq, cr, color=mn.GREEN, fill_opacity=1)
        un.move_to([1.5, 0, 0])
        self.add(sq, cr, un)

System specifications
System Details

macOS 14.0 (Sonoma)):
RAM: 32 GB
Python version (python/py/python3 --version): python 3.11.6
Manim v0.18.0 installed with conda.

Can't reproduce on MacOS 12.3 / Monterey. Might be a Sonoma-specific issue.

RAM: 1TB

Are you sure? What sort of machine are you working on? 😱

Damn. I cannot downgrade to Monterey (and to be honest I don't even want to do that! :D).
Let's wait if someone has Sonoma and can tackle this issue.

Are you sure? What sort of machine are you working on? 😱

Oooops! That is the HD! :D
The RAM is 32 GB :D I am going to correct.

I have the same issue on a new git-story install.  My machine is an M2 Mac pro with 32GB RAM.  Using a conda install.
../../../../../../src/cpp/skia-builder/skia/src/base/SkContainers.cpp:106: fatal error: "Requested capacity is too large."
[1]    61446 trace trap  git-story
/Users/base/anaconda3/envs/mer/lib/python3.11/multiprocessing/resource_tracker.py:254: UserWarning: resource_tracker: There appear to be 1 leaked semaphore objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '

Hope this helps and someone can fix it.  Seems to be in skia.

Given that I kinda will need this feature soon, I try to take a look at the source code, but the available time is unfortunately always limited. :(
TLDR: I think it is just a matter of time and this issue will be fixed somewhere, so perhaps the best would be just to wait. :)
Some findings and personal considerations:
What I found out is that the boolean_ops module (the one in charge of allowing users to perform boolean operations on Mobjects) relies on Skia, which is a google tool for 2D graphics. However, to access this tools we need some python binding and Manim is using skia-pathops. By looking at the code, the process to perform boolean operations seems to be:
Mobjects -> skia-pathops -> Skia (and back)
The cause of the issue that we are encountering is somewhere in this chain, but a thorough investigation would be needed to figure out where exactly.
However, I am pretty sure that the very same issue will hit some dev working in some point of such a chain(I don't know in which point of the chain) and he/she will (hopefully) fix it.
I also run some pytest locally and they fail the boolean operation tests. This doesn't happen yet in the github workflow because macos-latex is not v14. However,  sooner or later the action will be updated and I don't know how the Manim Community will address the issue (but in the meantime the issue may be solved elsewhere and there will be zero problems for the Manim workflow).
As a personal consideration, I noticed that Skia is used only for boolean ops (I may be wrong though) which is a very tiny part of Manim and yet there are two dependencies: skia-pathops and Skia. I am not a fan of having too many dependencies, especially if we use them for small part of the codebase, as boolean_ops appear, plus Google is notorious to suddenly drop support for its own tools. Skia do much more that just boolean operations and using it only for boolean_ops sounds a bit to overkill, perhaps there is a smaller size solution that could fit better there. Finally, Skia is a 2D whereas in Manim pretty much everything is 3D.
In the light of that,  perhaps a good idea would be to avoid having such a chain dependency and to cook a "in-house" solution instead, or to use a smaller dependencies where we could somehow have more control like for example this - I don't think we can have any influence on Skia itself.
I understand that it could take long time for "in-house" solution and I am aware that the "blanker is always short", but IMO this could be a good MsC thesis work for some student.  ;-)

I did a quick search since binary operations on polygons (that's more or less what we do, modulo the fact that our edges are usually Bezier curves) is very common in CAD. There are quite some libraries and algorithms out there, this one seems to stand out: Pyclipr is a Python library offering the functionality of the Clipper2 polygon clipping and offsetting library

Angus Johnson - Clipper2
https://github.com/drlukeparry/pyclipr

I understand that it could take long time for "in-house" solution and I am aware that the "blanket is always short", but IMO this could be a good MsC thesis work for some student. ;-)

It was me who added the dependency. I've implemented it as a proof of concept where we could do Boolean Operations on Mobjects and it ended up in the library as it is. Writing it "in-house" would be hard and would not be as performant as it is now (because you know, python). I recommend you create a new issue so we won't lose it.

after reinstall package [skia-pathops](https://github.com/fonttools/skia-pathops) the problem is fixed for me.


Make RST docs consistent with Editor Help docs

Closes godotengine/godot-proposals#4116.

Built-in documentation uses a syntax similar to GDScript, while the online documentation uses C-style.
1. Use method_name(param1: Type1, param2: Type2 = default) signature
instead of method_name ( Type1 param1, Type2 param2=default ):

I think parentheses without spaces would look better with a monospaced font.
2. Add tooltip for void type:

3. Use Array[Type] instead of Type[]:

4. Use BitField[Type] instead of BitField<Type>:

5. Highlight pointer types (in extension documentation):

Maybe some other way to highlight is needed. For example bold font, but I'm worried about escaping * and **.

See also https://github.com/godotengine/godot/pull/80765#issuecomment-1685820159. I'm not sure if we should show the full signature, or if we should hide the types and qualifiers.

How do we feel about this? I honestly like all of the changes except the method signature for the same reasons brought up above. I feel like the rest just "read" better for most people.

My question from 3 weeks ago still stands. I think anything but the method signature is an objectively good thing. Would be good to rebase.

I understand why point 5 is controversial, but I think that points 3 and 4 make no sense without 1, especially since this is how it's done in EditorHelp. We are making the signature more similar to GDScript, the only difference is that the return type is before the method name, because of the table. See also godotengine/godot-proposals#7607.

I must note, however, I don't think this closes the original proposal. OP still desires the the returned value to be on the right as per GDScript standard.
While that can be done, it needs to first be evaluated, as it would be very alienating for most users. Second, it needs to be well-thought out because with the current way built-in docs display method attributes, doing it won't look pretty.

Thanks!


Add tests for all possible error cases

Current Apps Script testing structure will exit with 1 when Apps Script API call returns error.
https://github.com/curvegrid/multibaas-for-google-sheets/blob/beaba407e3447cb3cc1ed7e4197f63d5182248de/test/mbSheetsAddOn.js#L32-L50
But tests for intentional error cases need to be ignored to check them as expected.

No need to handle server error cases.


Add travis and docker integration tests.

/cc @acaiafa @Ginja
This adds the kitchen-bokken plugin and a mess of changes to travis.yml. It ultimately allows us to run integration tests using docker.

/cc @coderanger
It looks like that poise-service is explicitly disabling running systemd within a container. For now we'll converge this on those systems using sysvinit.

hi @johnbellone, just interested to understand why you chose kitchen-dokken over kitchen-docker , what are the advantages / disadvantages?
Thanks :) 👍

@claudio-viola Dokken supports systemd out of the box, kitchen-docker requires additional configuration to make it work.


SwiftCompilerSources: Replace BlockArgument with Phi and TermResult.

All SILArgument types are "block arguments". There are three kinds:

Function arguments
Phis
Terminator results

In every situation where the source of the block argument matters, we need to distinguish between these three. Accidentally failing to handle one of the cases is an perpetual source of compiler bugs. Attempting to handle both phis and terminator results uniformly is always a bug, especially once OSSA has phi flags. Even when all cases are handled correctly, the code that deals with data flow across blocks is incomprehensible without giving each case a type.
Unfortunately, we don't have these C++ types yet (nothing big is blocking that, it just wasn't done). That's manageable because we can use wrapper types on the Swift side for now. Wrapper types don't create any more complexity than protocols, but they do sacrifice some usability in switch cases.
There is no reason for a BlockArgument type. First, a function argument is a block argument just as much as any other. BlockArgument provides no useful information beyond Argument. And it is nearly always a mistake to care about whether a value is a function argument and not care whether it is a phi or terminator result.

@swift-ci test

@swift-ci test

@nate-chandler did most of the work to fix this on the C++ side. When that's done, updating the syntax on the Swift side will be a trivial search/replace x = Phi(x) => x as? Phi

@swift-ci test

@swift-ci smoke test linux

@swift-ci smoke test linux


WIP: RHOARDOC-1614:File name changes to reflect new terminology

https://issues.jboss.org/browse/RHOARDOC-1614
Files renamed to reflect new terminology Some files for the Getting Started are not renamed as the term 'booster catalog' is the name of the repo.

Can one of the admins verify this patch?

ok to test

Thanks @snelluli1!

Closed in favour of #1286.


Create Path_Sum.cpp

I added Path Sum  in C++ which was not present in this repo. I added with  proper code (with comment) , time and space complexity also. @kasakvaish  Please merge it.


[Graph] Improve graph layouts to be able to take node transformation into account

@syrel Should this be closed?


Add node-exporter to kustomization.yaml in xdp

The node-exporter kustomize manifests used to be part of the prometheus kustomize manifests, but were moved out as part of https://github.com/cilium/scaffolding/commit/b6c4a02827212bf70c5fa38604a0674c7863752a. This change was not propagated to xdp's kustomization.yaml.
Signed-off-by: Ryan Drew<EMAIL_ADDRESS>

Small enough for a self-merge.


Add function that returns available locales

This extends the Loader trait
Fixes https://github.com/XAMPPRocky/fluent-templates/issues/15
I think returning iterator is more lightweight solution than the vector. The only drawback is that I return Boxed object due to the polymorphic nature of the iterator.
It is also should be possible to avoid boxing by adding the associated type to the trait. However, I couldn't get the lifetimes right in my first try, so are you happy with Box?

Actually maybe I no longer need this after https://github.com/XAMPPRocky/fluent-templates/pull/16

Thank you for your PR! I think boxing is fine for now. I think the method would still be useful to have; for example if you wanted to print a list of locales.

The failing build is not related to my change. Seems like it is due to changes in flume, why is it building with v 0.7.2?

Because in cargo flume = "0.7.1" is equivalent to ^0.7.1 where it will use semver compatible versions. You can fix that by setting it to "=0.7.1".

Thanks for explanation on cargo version policy. It should be another PR then.

@XAMPPRocky I am about to push a PR to fix it.

Rebased onto master.

Thank you for your PR!