Plans for ActiveRecord adapter (a la Delayed::Job)?

Neat idea! This is exactly the functionality that sucker_punch requires for it to be perfect for my needs. However, I'd like to persist my jobs in my app's database the way delayed_job does. Do you have any plans of adding an adapter to concussion for persisting jobs that way? Thanks! :+1:

Apologies for the delay replying!
I can add an AR adapter quite easily, I'll look into it. I need to revisit the project anyway; the new version of sucker_punch uses a different interface which is bound to break my code.
Alternatively, if I don't get round to it in time, you could lock your version of sucker_punch to v.1.x and add your own adapter. The interface is described at length in the Redis adapter file. If you do, you can gemify it or issue a pull request. :)

Thanks @chemica for looking into it. There's no rush, I probably won't get to work on my project for another month or so anyway. But I do hope you'll continue developing concussion, as I still think it's a great addition to sucker_punch!


Using with redux-devtools-extension

I am trying to use it with redux-devtools-extension and i am getting the following error:
Uncaught TypeError: a.subscribe is not a function
I then tried adding redux's subsribe method here:
https://github.com/logux/logux-redux/blob/master/create-logux-creator.js#L127
var middlewared = enhancer(function () {
  return {
    getState: store.getState,
+   subscribe: store.subscribe,
    dispatch: dispatch
  }
})(reducer, preloadedState)

This solves the issue but nowredux-devtools-extension does not seam to find any store.
Also using the normal store.dispatch throws an error.
Has anybody managed to combine logux-redux with redux-devtools-extension?

Nope, I didn't try it.
There is no really sense to use Redux DevTools. Logux had own time travel algorithm. Action undo will not undo actions on the server.
It is better to create special Logux DevTools since Logux will give more feature for DevTools (like hot reload not only for the client, but also for server).
Of course, it will be nice to fix this compatibility issues, but it is low priority.

Hm. Interesting question. Maybe I need to add extra event to logux-redux to get state update after action.
Because of time travel (it is async since log could be loaded from IndexedDB), Redux DevTools will not work anyway.
Thanks for the issue. I will try to bring some solution on this weekend.

I see. Looking forward to your solution.

@ai, maybe should look reconsider the way how logux is connecting to to redux store?
It may look like this:
import { createStore } from 'redux'
import { connectedLogux, createLoguxEnhancer } from 'logux-redux'

const enhanceByLogux = createLoguxEnhancer({
  subprotocol: '1.0.0',
  server: 'wss://localhost:1337',
  userId: 10
})

const store = createStore(
  connectedLogux(reducer),
  preloadedState,
  enhanceByLogux(enhancer)
)

I think it's more natural way to enhance redux store and avoid such problems

Ah sorry, in this case it shouldn't help: store enhanced by logux will still be broken by redux-devtools-extension

But as it described in redux-devtools-extensions docs it can be fixed like this:
const store = createStore(
  connectedLogux(reducer),
  preloadedState,
  compose(
    window.__REDUX_DEVTOOLS_EXTENSION__ ? window.__REDUX_DEVTOOLS_EXTENSION__() : noop => noop,
    enhanceByLogux(enhancer)
  )
)

Hm. Interesting idea.
Logux doesn't enhance store, but replaces it completely. Is it a problem for this case? Or we just need to call prevState.dispatch to make it works?

I wondered once why logux-redux isnt a store enhancer. Regardless of this issue and if possible, being a store enhancer would fit "more" into the redux design, i think.
If this would also solve the issue i currently don't know.

Logux need to replace the store in time travel. And there is no official Redux API for it.
But maybe there are some hacks to do it. How you think we can enhance it?
We need to add extra properties to the store and add time travel.

I see, maybe its not possible with the official Redux API only.
I am still new to logux code so atm i wouldn't know how.

@namjul maybe you want to create to change create-logux-creator.js  to support Redux enhancer API?
It will be the best way to learn Logux internals and should not take a lot of the time. If you will have any questions, feel free to ask.
I will be able to try it only few weeks later (preparing a talk about Logux).

Thx for the encouragement. I like the idea and i will give it a shot.


Move .readthedocs.yml to .readthedocs.yaml

Setting up new repos with RTFD requires exactly .readthedocs.yaml:

@michaelweinold Any objections or things that would break with the docs pipeline?

Checked just now - did not find anything that would break.

Fixed in #53


new(libsinsp,libscap): Support full argument retrieval on both entry and exit for some syscalls

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature
Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area driver-kmod
/area driver-ebpf
/area libscap
/area libsinsp

/area tests

/area proposals

What this PR does / why we need it:
This PR adds support in the Falco libraries to allow the kernel module to retrieve userspace buffers on both entry and exit events for the following syscalls: connect, open, openat, openat2 and creat. Relevant changes are ported to the kernel module, eBPF probe and udig accordingly.
Currently, the Falco libraries read the arguments, especially userspace buffers, for those system calls at exit time, but there is no guarantee that those buffers will still be available and unchanged since the syscall started.
With this patch, when both entry and exit events are retrieved, libsinsp is then able to deal with the potential differences so that fd.name/fd.sip/etc are correct and rules are processed properly even if any modification to userspace memory happened in the meantime.
Performance Evaluation:
Experiments were performed by comparing performance at f05aaecd111e80ee0389bffb97c3e1309252d65f and with this patch. To do so, we ran https://github.com/falcosecurity/event-generator with options ./event-generator bench "syscall.ReadSensitiveFileUntrusted" against Falco with both versions of the Falco libs.
The selected test (syscall.ReadSensitiveFileUntrusted) exercises the open() family of syscalls which is involved in this patch. On our cloud instances, both versions started dropping events between 19000 and 20000 events per second, with no significant difference between the two.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

new(libs): added entry parameters to connect, open, openat..., creat

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: LucaGuerra
To complete the pull request process, please assign fededp after the PR has been reviewed.
You can assign the PR to them by writing /assign @fededp in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @LucaGuerra. Thanks for your PR.
I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Hi! Thanks for this huge PR!! :rocket:
/ok-to-test

LGTM label has been added.  Git tree hash: b8e4cb4b384a1e4e98dfc9aba448d43d73068b57

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, LucaGuerra
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Update create-upload-ubuntu.md

Resolved spelling and punctuation errors.

@srijang

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


E0463 question

I'm having an issue where rust/cargo can't find the timeit crate even though it's downloaded and compiled and in the deps directory. i can upload the entire project directory if it would help debugging.

Thanks for the report! Could you provide some more details like what versions of rustc/cargo you're using, the logs you're seeing, the project structure, etc? If I can reproduce locally I can try to help investigate.

Closing due to inactivity, please reopen with more information if this is still a problem!


Reduce storage footprint of acked updates of watchtower client

Also see #6885. The watchtower client currently persists all acked updates, i.e. updates already accepted by the watchtower server. On my node (c-otto.de) the wtclient.db consumes ~4 GByte on disk, and I assume most of that is related to acked updates.
lnd itself does not need this information (but it might become useful when migrating to a different watchtower server). Please consider removing this data from disk.

BackupID.CommitHeight is of type uint64 which I believe is a bit excessive to store block heights. Maybe it's a good idea to use uint32 instead?

Related to #7035


Update AcrylicRecipe_Diagram.jpg

Changed picture to reflect new recipe with the luminosity blend mode as part of the picture.

Hi @kikisaints - Microsoft authors and contributors need to make content contributions through the private repository so the content can be staged and validated by the current validation rules.
After you review staging and fix all validation issues, you can tag an author for review or add the sign-off comment to let PR reviewers know that the updates are ready to be merged.
Read about authors working in the public repo for more information.
If you need help getting set up to work in the private repo, see Set up Git repository locally for documentation.
We'll close this PR. Thank you.


Compilation problem due to gorething interface change

This is why we use Godeps for dependencies.  See https://github.com/shipyard/shipyard#contributing.  Feel free to update the Godep dependency although we'll need to check to make sure it doesn't affect anything else.

Closing as we recommend to use godep.  Thanks for the feedback!


Human-readable unit for duration in smtweb

Duration shown by smtweb such as in record_detail or record_list is in seconds always. I think it will be nice if smtweb changes them to appropriate unit. For example, "6 hours 32 minutes 12 seconds" (maybe "6:32:12" or "6h 32m 12s"?) instead of "23532s".
Imported from Bitbucket issue 86,  created by tkf on 09-12-2011 at 16:38, last modified: 10-03-2011 at 11:19

I wrote and attached a patch. Please check.
Trac comment by tkf on 09-28-2011 at 20:49

Thanks very much for the patch. There does seem to be one problem with it: the order of values returned from modf() seems to be turned around? Attached is a slightly modified patch, committed as r273
Trac comment by apdavison on 10-03-2011 at 11:19


docs(api): document appMode

I've found appMode useful when using pptr with lighthouse.
Background:
Both Lighthouse and Puppeteer emulate a viewport when you run the tools, but they use different sizes. This causes lighthouse's perf audits to fail because screenshots end up changing sizes during an audit. During an audit session, Lighthouse reloads the page several times.
example  - inject a stylesheet into the page before each lighthouse runs.
const {URL} = require('url');
const puppeteer = require('puppeteer');
const lighthouse = require('lighthouse');

(async() => {

const url = 'https://www.chromestatus.com/features';

const browser = await puppeteer.launch({
  appMode: true, // sets headless: true and does not set a viewport size. Let ligthhouse do that.
});

browser.on('targetchanged', async target => {
  const page = await target.page();
  if (page && page.url() === url) {
  await page.addStyleTag({content: 'body {color: red}'});
  }
});

const lhr = await lighthouse(url, {
  port: (new URL(browser.wsEndpoint())).port,
  output: 'json',
  logLevel: 'info',
  // disableDeviceEmulation: true,
});

console.log(`Lighthouse score: ${lhr.score}`);

await browser.close();

})();

I had to find out about this the hard way.
It would be useful to be able to not set a default viewport size and still be able to have headless setting. Related #1910.

@alixaxel @ebidel would the page.setViewport(null) to disable viewport emulation help you?

I think one of the issues we see is that that users have to remember to override the viewport in the first place. It's a source of confusion and easy to forget. It would also be nice to not have to make an API call for every page.

I think one of the issues we see is that that users have to remember to override the viewport in the first place. It's a source of confusion and easy to forget. It would also be nice to not have to make an API call for every page.

@ebidel I think this would always be the case: If we don't override the viewport by default, it's size will be unpredictable.

@aslushnikov For me, the appMode is confusing because it does too many things:
https://github.com/GoogleChrome/puppeteer/blob/e998ac93250cc7279043831328b6f4f49bc244bb/lib/Launcher.js#L68-L71
https://github.com/GoogleChrome/puppeteer/blob/e998ac93250cc7279043831328b6f4f49bc244bb/lib/Launcher.js#L83-L90
And then Page will set the viewport:
https://github.com/GoogleChrome/puppeteer/blob/e998ac93250cc7279043831328b6f4f49bc244bb/lib/Page.js#L57-L58
@ebidel In your example you have:
appMode: true, // sets headless: true and does not set a viewport size. Let ligthhouse do that.

Which doesn't agree with the docs you wrote:
- `appMode` <[boolean]> If this option is set to `true`, the browser opens in headful mode and Puppeteer does not set a default viewport of 800x600 for new pages. Overrides the `headless` option if both options are used together.

@aslushnikov For me, the appMode is confusing because it does too many things

@alixaxel that's true. appMode is purely experimental and is a subject for removal; that's the reason it's not documented yet (and shouldn't be).
I'm not sure I understand if the page.setViewport(null) would help you. Is it enough?

@aslushnikov I don't know what's the behavior/idea of page.setViewport(null) TBH. Basically, it would be helpful to find a solution for the inconsistency in #1910, which (I assume) will also affect Lighthouse.
If page.setViewport(null) would do the trick, great!

@ebidel I think this would always be the case: If we don't override the viewport by default, it's size will be unpredictable.

Guess I'm unclear why we set a viewport. Chrome seems to be fine without setting one viewport:
const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch({appMode: true});
  const page = await browser.newPage();
  await page.goto('https://www.facebook.com/');
  await page.screenshot({path: 'screenshot.png'});
  await browser.close();
})();

That produces a screenshot where the page/viewport take up the full window dimensions. That feels like the right behavior over pptr setting one for users. It's also more like the rest of the API (less magic, you opt-in to things).
Does chrome not launch with the same dimensions across platforms?

It doesn't launch with the same dimensions across headful/headless. I can't imagine its the same across platform.

Can we make a decision on this?
TLDR: we need some way to prevent pptr from setting a default viewport. It would be nice if that was a flag and not an explicit API call. The default 800x600 is a source of gotcha/bugs for us.
BTW, does page.setViewport(null) currently work?

Can we make a decision on this?

appMode is a highly experimental feature that serves as our playground; it's subject to change every other day and shouldn't be relied upon.

The default 800x600 is a source of gotcha/bugs for us.

I'm not sure I follow this. Would it be better if there are random numbers instead?

BTW, does page.setViewport(null) currently work?

It doesn't.
Closing this in favor of  https://github.com/GoogleChrome/puppeteer/issues/1910

No, it would be better if pptr didn't set a default viewport at all for users. Seems to work just fine. People run into issues with responsiveness: e.g. site not matching selectors, page layout being different for mobile, etc. It's usually b/c they don't realize we're setting a small viewport at launch.

We discussed this more offline. Many sites are clipped when screenshotted by puppeteer in a user's first hello world script.
There's a proposal for changing the default viewport width from it's current 800x600. A fresh profile headful Chrome launches at 1200px wide, so we think that's a good new width. (height TBD, not as big a deal)   This will require a major version bump, so it should go onto a list of things to change at the 2.0. :)


Adding a blog page to the website.

I have noticed that, this website has a single page which predicts the crop.
Adding a blog page about different crops and locations in which they can be grown can enhance the website.
@abhijeet141,
I would love to contribute to this issue as a part of @GSSOC'23.
Please assign it to me. Thank you.

I would like to work on this issue under GSSoC'23. Please assign this issue to me.

I am GSSOC 23 contributor assign this to me i want to work on this

I want to work on this issue as a contributor.
Pleasure Assign so that I can show my skills under GSSoC'23.

Hi @Sathvik902,
Thank you for creating the issue. I have reviewed it, and I completely agree that adding a blog page about different crops and their suitable locations would enhance the website. It's an excellent opportunity for you to contribute.
Please go ahead and start working on it. If you have any questions or need assistance during the process, feel free to ask.
Thank you for your contribution, and I'm excited to see your progress in resolving the issue.

Hi @UditSharma9999 @sijalalyy @syedawanya18
Thank you all for showing interest in working on this issue. If there will be no response within a reasonable timeframe, I will assign the issue to each of you, one by one, in the order of your comments.

Thank you so much! @abhijeet141

I'll do it in 1 days. Thanks.

@Sathvik902 Any update ?

@UditSharma9999 Are you interested in doing this issue ?

No. Thank you

It will be done by tomorrow. Thanks


Track top-level module imports in the semantic model

Summary
This is a simple idea to avoid unnecessary work in the linter, especially for rules that run on all name and/or all attribute nodes. Imagine a rule like the NumPy deprecation check. If the user never imported numpy, we should be able to skip that rule entirely -- whereas today, we do a resolve_call_path check on every name in the file. It turns out that there's basically a finite set of modules that we care about, so we now track imports on those modules as explicit flags on the semantic model. In rules that can only ever trigger if those modules were imported, we add a dedicated and extremely cheap check to the top of the rule.
We could consider generalizing this to all modules, but I would expect that not to be much faster than resolve_call_path, which is just a hash map lookup on TextSize anyway.
It would also be nice to make this declarative, such that rules could declare the modules they care about, the analyzers could call the rules as appropriate. But, I don't think such a design should block merging this.

I suspect the gains here are actually a little under-estimated, because most of our benchmark files import NumPy, and files that don't import NumPy should get a huge boost from this change.

The ecosystem changes are because I gated some of the Pandas rules to require a Pandas import. I can roll that back. It honestly might be an improvement... It's trading false positives for false negatives.

@zanieb - I decided to roll back that specific change. We can definitely consider it but it felt wrong to include in this optimization PR. (Some (not all) of the changes were false negatives.)


configuration xml

where I should put that configuration xml file, in your example that isn’t?

Your project should have an App.config file. It does there.
On Thu, May 28, 2020, 06:02 nikhallikainen<EMAIL_ADDRESS>wrote:

where I should put that configuration xml file, in your example that isn’t?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/emancipatedMind/XmodemProtocol/issues/3, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADAXIM2OXY3VL3FCATI24QDRTYZD3ANCNFSM4NM56RBA
.


High memory use, leak?

Left lazydocker running for ~3 days, memory use increased to 14 GB. There were no running containers for most of this time.
To Reproduce
Leave lazydocker running?
Expected behaviour
Memory use to remain low.
Desktop (please complete the following information):
lazydocker --version
Version: commit=cf31c23fadcc717467318689fc073ecf1bed8031, build date=2019-07-02T00:10:43Z, build source=binaryRelease, version=0.3, os=linux, arch=amd64

Ubuntu 18.04

This is fixed since v0.5.5 and you are running v0.3
Can you try to update lazydocker and see if that fixed the problem?


Shift Inplace in DF

Is it possible to add in place shifting

We generally prefer not to implement in-place operations unless there are clear performance benefits because they can lead to confusing behavior, especially with chained operations. For example df['column'].do_something_inplace() modifies the series df['column'] --- and not, necessarily, the original dataframe df.

@sirinath most in-place operations are in fact NOT inplace. This was put 'inplace' a while ago (pun intended!). as @shoyer says, not really in favor of these.

To be clear, the recommend way to do an "in-place" shift would be to write df = df.shift()

It seems like the inplace option provides added flexibility.  For example, it allows to me modify a DataFrame by calling a function, without needing to return a copy:
def my_function(frame):
    frame.some_operation(inplace=True)

@121onto inplace setting violates the purity of functions. you can certainly use it if you want. And I suppose we would accept a PR to implement. But beware, in general there is no actual benefit to doing things inplace.

Hello.
How can I write this without inplace?
xx['max'] = xx.iloc[:,250:260].idxmax(axis=1)
xx.iloc[:,269:513].loc[xx['max']==278].shift(1,axis=1, inplace=True)


Blocks that should produce lighting

This is an
A S T H E T I C
sugestion. Simply put many of the blocks i would think would have a light value of something, but have no light value. In particular all the universial cables which imo should be probably like 5 or 7 with shader color set to green, dark green. Things like the compressed glowstone block dont have fynamic lights. And even liquid tubes when glowing liquid is in them, ill kake a better list when i get home but for now this is it. (At work on phone cant be assed tk correct spelling :p)

Btw if i was told how i could help with it

Gonna throw some notes here as i work if i think of random stuff:
Reactor. Change brightness based on injection rate not dynamic,
Atomic diss: blue dynamic only
Glowstone: dynamic lighting support as it dont have it

the main part is at mekanism.common.block.BlockMachine#getLightValue - but doing block light updates like this is horrid with MC because it redraws the whole chunk iirc.
So one of the dynamic lighting systems like albedo could be usable

I meant for optifine dynamic lighting, cause for some reason it dont see it as a light source. Which is odd

ah, right I may have misunderstood your initial post. I had somehow thought you meant the existing functionality of machines that produce light like torches do.

Kinda, for the pipes yes, but it would be configurable to turn off as it would cause alot of strain on servers if someone abused it or barely didnt have enough gens to power their stuff. But for things like torcges in logistical trnasporters, that eould be on optifines side, and the green pulsing of the cables would be shader supported stuff

Is there any specific information I can help with?

Just an example of how i would do it. Mainly for the logistical transporters or mechanicalnpipes, i can probably figure out the universial cable on my own

After i see one fluid i can copy it over for like a million other mods, unless we can make a configu system to register fluids and items at launch that have light dynamic or static

most of that stuff would be handled by the renderer classes. e.g. mekanism.client.render.transmitter.RenderLogisticalTransporter
I wouldn't be adding any new stuff for block light (i.e the server side concept which prevents mob spawning) due to the hefty re-render costs

true... but machines do allow it if you enable it in the config, maybe it could be like that?

it could be but I intend to move away from that being block light to being just rendered like that

good idea... that way the server isnt strained, good idea.

well, its more of a client issue. Light updates cause the whole chunk to re-render (its otherwise cached), killing performance

O, didnt know that, also only the static light of the reactor and the either on or off of the cable would work without optifine, other fancy things like items and liquids would be optifine dynamic lights exclusive. Even then the lightweight stuff would even be configurable to be able to be dissabled client side

Unless thats a bad idea

Optifine tends to leave a bad taste in the mouth. You could alternatively use https://minecraft.curseforge.com/projects/albedo
Or of course code it to be able to work with both


Remove Id::Form

Remove Id::Form in order to remove activemodel as a dependency. Id::Form will be implemented in a new gem of it's own. This will allow the use of Id with rails versions lower than 3.

Build is failing as bundler is not compatible with rubygems 2.5.0

:+1:

👍

👌


grpc preserve_host not work

Summary
grpc preserve_host not work
Steps To Reproduce

Create a grpcs service(there is an upstream in fact)
Create a route with host of the service and preserve_host = true
grpcurl host:443 list
upstream receive
"POST /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo HTTP/2.0", host: "kong_upstream"

Additional Details & Logs

Kong version ($ kong version) 1.3.0

@ciiiii thank you for reporting this!

Thank you for quick reply, is there some temporary solution?

@ciiiii I'm currently working on a fix - will post an update soon!

@gszr Ok, thank your timely fix.

@ciiiii If you can, please test the fix linked above - https://github.com/Kong/kong/pull/5225.

@gszr I did some code change like that yesterday, it's ok.

@ciiiii The fix for this issue has just been merged into master. Thanks for reporting!


RenderIsVisible doesn't work well when items are rearranged.

Hi,
First of all, thanks for your time to create this lightweight and useful library.
I was trying to use in a project with a list that is able to be rearranged and I've found that some items are not visible after reodering the list. I've created a codesandbox for reproducing the issue:
https://codesandbox.io/s/eager-mclaren-ge3rz?file=/src/App.js
After clicking in the button some items keep invisible:

Hi @xgbuils
It looks like this is because the items come into view without the help of scrolling or resizing the window. If you click on "Reorder", then scroll down and back up again, you'll see the list items appear.
You can fix this by changing the keys according to the order. Here's an example - https://codesandbox.io/s/admiring-dewdney-sincx?file=/src/App.js
This forces the list item to be re-created (not just re-rendered) - thankfully that's a light operation because the list item is wrapped in <RenderIfVisible></RenderIfVisible>.
It would be good to have a more elegant way to handle list reordering though. I'll have a think about how that could be done.
Thanks for reporting :)

Hi @GusRuss89

This forces the list item to be re-created (not just re-rendered) - thankfully that's a light operation because the list item is wrapped in .

Then I'll take this approach in the meantime.
Thanks for answering so quickly :)


Fix #136 -- Add dependent-field support to formsets

I labeled this as minor because I didn't take into consideration all use cases but my private one, though I do think it answers most of the needs. this is django admin oriented

This is great and solve our problems. Looking forward a release


Make kubernetes/gcloud also use the generated keys (as in docker-comp…

Catch up with the latest changes (#656): Update referenced keys in kubernetes config
(see https://github.com/google/keytransparency/pull/656/files#diff-4e5e90c6228fd48698d074241c2ba760L125)
Current log output:
[...] config.go:35] Failed to open public key /trillian/log-rpc-server.pubkey.pem: failed to read: /trillian/log-rpc-server.pubkey.pem. open /trillian/log-rpc-server.pubkey.pem: no such file or directory

Codecov Report

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

@@           Coverage Diff           @@
##           master     #663   +/-   ##
=======================================
  Coverage   57.26%   57.26%
=======================================
  Files          35       35
  Lines        2490     2490
=======================================
  Hits         1426     1426
  Misses        775      775
  Partials      289      289

Continue to review full report at Codecov.

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


stop random scroll on edit playbook

Summary
When editing a playbook, the unconditional autoFocus=true on the last visible description forced the page to scroll to that element. Only do this is the description is empty, making it easy to start typing a description when adding one but not scrolling when first loading.
Ticket Link
None.
Checklist

[ ] Telemetry updated
[ ] Gated by experimental feature flag
[ ] Unit tests updated

I'm separately looking at failing Cypress tests (among other Cypress improvements), but the failure above appears to be unrelated.

Approving to unblock, but what happens when the last visible description is empty? Isn't it the same as before?

If the description is empty, it won't actually render the component, preventing the whole business. I think something similar happens with tasks, except we pre-fill them with data instead of allowing them to stay empty.


Getting ZLIB error when using folly (x64-windows-static)

When building a project with folly  (x64-windows-static) I get the error below
Error:
 $ cmake .. -DBUILD_BENCHMARKS=ON
 -- git Version: v1.5.0-01c0ab7c
 -- Version: 1.5.0
 -- Performing Test HAVE_STD_REGEX -- success
 -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
 -- Performing Test HAVE_POSIX_REGEX -- failed to compile
 -- Performing Test HAVE_STEADY_CLOCK -- success
  --
CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
C:/Program Files/CMake/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
C:/Users/pcc/Desktop/disp2/thirdparty/vcpkg/installed/x64-windows-static/share/folly/folly-config.cmake:5 (find_dependency)
benchmarks/CMakeLists.txt:22 (find_package)
  -- Configuring incomplete, errors occurred!
See also "C:/Users/pcc/Desktop/disp2/dispenso/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/pcc/Desktop/disp2/dispenso/build/CMakeFiles/CMakeError.log".`
Root cmakelists.txt:
`cmake_minimum_required(VERSION 3.12)
project(Dispenso VERSION 0.1.0)
if (WIN32)
set(CMAKE_TOOLCHAIN_FILE "../thirdparty/vcpkg/scripts/buildsystems/vcpkg.cmake")
add_compile_definitions(NOMINMAX)
set(CMAKE_CXX_STANDARD 17)
endif (WIN32)
set(CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/../thirdparty/vcpkg/installed/x64-windows-static/share/ ${CMAKE_PREFIX_PATH}")`  ** without this line find_package() for folly doesn't work **
if (WIN32)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
endif (WIN32)
# Setup VCPKG for windows
if (WIN32)
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE static)
endif (WIN32)
....
if(BUILD_BENCHMARKS)
############# Benchmarks
add_subdirectory(benchmarks)
endif (BUILD_BENCHMARKS)`
Benchmarks cmakelists.txt:
`
find_package(folly REQUIRED)
include_directories(${FOLLY_INCLUDE_DIR})
 ...
add_executable(
    future_benchmark
    ./future_benchmark.cpp
)

target_link_libraries(
    future_benchmark
    PUBLIC thread_pool
    PUBLIC task_set
    PUBLIC thread_benchmark_common
    PUBLIC folly
    PUBLIC ${Boost_LIBRARIES} ${FOLLY_LIBRARIES} ${FOLLY_LINK_LIBRARIES}
    PUBLIC concurrentqueue
    PUBLIC gflags
)
if (WIN32)
target_link_libraries(
    future_benchmark
    PUBLIC ws2_32
    PUBLIC synchronization
)
endif (WIN32)

`

Have you tried the latest commit? This issue should be fixed via #13278.
Is this the same issue as #13287 that you posted before? If the issue wasn't fixed, we can reopen it. It's not necessary to create a new one.

Git log shows I'm at last commit of: Fix ffmpeg build for PATH with spaces. (#13275), so I should have it. I literally cloned it a few hours back.

Does this issue only exist on static build or not? Have you tried to build fooly:x64-windows?

Also please try to use like this:
find_package(folly CONFIG REQUIRED)
target_link_libraries(main PRIVATE Folly::folly Folly::folly_deps Folly::follybenchmark Folly::folly_test_util)

Sorry, I cannot reproduce this on my machine.
Please use find_package(folly CONFIG REQUIRED) to find folly. Also the current issue that ZLIB cannot be found seems to be strange, which is different from this here.
Could you please try to refer to #13196 to try this again?

Hi, i have exactly the same ZLIB error when building boost for x64-windows-static on a fresh compiled vcpkg install.

Does the path you used contains Upper character or spaces on your machine?
Uppercase issue, please see #12709.
Spaces issue will fixed by #13126.

Does the path you used contains Upper character or spaces on your machine?
Uppercase issue, please see #12709.
Spaces issue will fixed by #13126.

No, the base path on my machine is c:\code\vcpkg

Sorry for the long delay, but I still cannot reproduce this issue on my machine. So I have no idea what's wrong with your environment now.
PS F:\new\vcpkg> .\vcpkg.exe install zlib:x64-windows
Computing installation plan...
The following packages will be built and installed:
    zlib[core]:x64-windows
Detecting compiler hash for triplet x64-windows...
Starting package 1/1: zlib:x64-windows
Building package zlib[core]:x64-windows...
Could not locate cached archive: C:\Users\AppData\Local\vcpkg\archives\db\dbed138fc2cf727d1d830f40646871fd12b70f4a.zip
-- Using cached F:/new/vcpkg/downloads/zlib1211.tar.gz
-- Extracting source F:/new/vcpkg/downloads/zlib1211.tar.gz
-- Applying patch cmake_dont_build_more_than_needed.patch
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch add_debug_postfix_on_mingw.patch
-- Using source at F:/new/vcpkg/buildtrees/zlib/src/1.2.11-63309e48e5.clean
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-1-any.pkg.tar.xz...
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst...
-- Using msys root at F:/new/vcpkg/downloads/tools/msys2/c809757c94447846
-- Fixing pkgconfig file: F:/new/vcpkg/packages/zlib_x64-windows/lib/pkgconfig/zlib.pc
-- Fixing pkgconfig file: F:/new/vcpkg/packages/zlib_x64-windows/debug/lib/pkgconfig/zlib.pc
-- Installing: F:/new/vcpkg/packages/zlib_x64-windows/share/zlib/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\AppData\Local\vcpkg\archives\db\dbed138fc2cf727d1d830f40646871fd12b70f4a.zip
Building package zlib[core]:x64-windows... done
Installing package zlib[core]:x64-windows...
Installing package zlib[core]:x64-windows... done
Elapsed time for package zlib:x64-windows: 1.616 min

Total elapsed time: 2.158 min

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

Hi @deleeuwict
Could you please try to update to the latest vcpkg and rebuild this port?

Hi @deleeuwict
Could you please try to update to the latest vcpkg and rebuild this port?

Hi,
Could you tell me the procedure of upgrading vckpkg without losing my installation?

Sorry for the long delay.
You can use git pull to update vcpkg to the latest version.

@deleeuwict
Is this still a problem for your after update to the latest version?

Closing this issue for now. Please feel free to reopen this issue if it is still a problem for you.


@conda-forge-admin,please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/hiclass-feedstock#7.


Install, configure, & remove extensions from web interface

Extensions are not hard to install, but it would be a little easier for newcomers if they could be installed and uninstalled from GUI.

Presumably this should include the full life cycle similar to browser extensions with the ability to enable/disable, configure, and remove extensions as well.

What would be the source for the integrated extensions installer? Could we have a repo on OpenRefine that would contain a copy of all the installable extensions? That way, we could provide some kind of control/quality of the extensions, and it would be easier to control versions installed, and their compatibility.
I also think we should have the same kind of installation commodity for services.

What would be the source for the integrated extensions installer? Could we have a repo on OpenRefine that would contain a copy of all the installable extensions? That way, we could provide some kind of control/quality of the extensions, and it would be easier to control versions installed, and their compatibility.

I think that would go against the spirit of extensions: anyone can develop them and install them without having to go through vetting by a central authority.
We could certainly have an online catalogue of known extensions, but people should not be forced to go through that, I think.

I think that would go against the spirit of extensions: anyone can develop them and install them without having to go through vetting by a central authority. We could certainly have an online catalogue of known extensions, but people should not be forced to go through that, I think.

@wetneb: I'm totally like you for not locking people in this hypothetical extension repo.
I think we should have a file, like a JSON, with a list of all known extensions. These extensions could be anywhere.
But, for the extensions that are very common, or the one that no longer have maintenance, having them in a repo could gives us better quality control. Also, since a change in the core might trigger changes in extensions, and those change would be the sames across extensions, then working them in batch might be efficient.
And, since you can put many .git repos in a single repo, we wouldn't loose the ability to send back these changes to thier respective repos.
And that way, it would also be easier to do a CD/CI that would test them automatically with newer version of OR.
Regards, Antoine

Presumably this should include the full life cycle similar to browser extensions with the ability to enable/disable, configure, and remove extensions as well.

Reading this after some time and just wondering if my hypothetical GUI needs to include some "configure" button that opens up more options via a dialog - wouldn't that be quite hard because we would need to force extension developers to expose somewhere possible configs that we would then render in the GUI? Maybe it's easy and I'm just finding it hard to imagine, so wanted to inquire further.

Presumably this should include the full life cycle similar to browser extensions with the ability to enable/disable, configure, and remove extensions as well.

I'd regard the minimal implementation as being able to do what the user can currently do via the filesystem via the GUI instead - i.e. add/remove extensions by dropping the files in the appropriate place
Enabling/disabling extensions that are already in place seems like a good additional option, but I think this would require new work on how extensions are managed by the main platform as I don't think the concept of 'installed but not enabled' exists currently.
Supporting some "Configuration" seems like a big step from where we are and I'm not sure it is currently necessary (I can't think of any existing extension that requires configuration - and any that do already have to handle configuration themselves). I think the idea of some kind of generic configuration interface that extensions could implement and the GUI could expose might be a good idea and could open up opportunities for the future - so maybe worth considering as long as not compulsory for extensions to support - BUT I'd say not necessary to deliver the user benefits envisaged by this issue - so I'd regard this as a 'stretch goal'
I'd also say having a version compatibility declaration/check would be a good stretch goal (and for me this would offer more return than support for generic extension configuration)

I think we should have a file, like a JSON, with a list of all known extensions. That would be the catalog

We already maintain a list for the website and is we could convert this to a JSON file that could be used both by the website and as a catalog then we'd not be taking on any more maintenance for this - so I'm in favour of this step. I also think that combining this with some kind of version compatibility declaration & check as I suggest above would be a step forward
I'm less sure about bringing extension code into the main repo - we've discussed this before and generally @wetneb has persuaded me this is a bad idea

Enabling/disabling extensions that are already in place seems like a good additional option, but I think this would require new work on how extensions are managed by the main platform as I don't think the concept of 'installed but not enabled' exists currently.

@ostephens: for me, enabled vs disabled could just be moving from extensions to extensions (disabled). Lot's of software do that, and I personnally also do that. No extra work, more than FS stuff.

I'd also say having a version compatibility declaration/check would be a good stretch goal (and for me this would offer more return than support for generic extension configuration)

No doing it would be a shame.

I think we should have a file, like a JSON, with a list of all known extensions. That would be the catalog

Yes, like for Recon services.

I'm less sure about bringing extension code into the main repo - we've discussed this before and generally @wetneb has persuaded me this is a bad idea

I'd like a SEPARATE repo for extensions.
Regards, Antoine


:bug: Allow pets to be bought with gems

Interestingly, this is just a UI fix.

Removed misleading check.


How make onMissingValue return previous value?

onMissingValue just receive a dateTime as param, how can I return previous value when missing value?

what do you mean? Could you explain what do you want to do ?  onMissingValue is a builder that you can use to return a value when there is no value for a specific DateTime.

I have a list of values and a interval is missing, so I want to return the previous value.
ex. [11-01-2019 -> 1, 01-01-2020 -> 3]
I want to show:
11-01-2019 -> 1
12-01-2019 -> 1
01-01-2020 -> 3
not:
11-01-2019 -> 1
12-01-2019 -> 0
01-01-2020 -> 3

what is the code of the builder onMissingValue that you are using ?

onMissingValue: (DateTime dateTime) {
                double lastValue = 0;

                for (final dataPoint in data) {
                  if (dataPoint.xAxis.isBefore(dateTime)) {
                    lastValue = dataPoint.value;
                    break;
                  }
                }

                return lastValue;
              },

did you debug your code?

What do you mean?

check if the condition is executed

Yes, it's the graph is working well, I just wanna know if there are a better way, because I create loop just to return the previous value in the graph.

ahh, no sorry, that feature is not implemented but we are accepting Pull requests :).
Also you can improve your loop using HashMaps to reduce the complexity.


Extension causes high cpu load

ms-python.python-unresponsive.cpuprofile.txt

Issue Type: Performance
Extension Name: python
Extension Version: 2020.4.74986
OS Version: Windows_NT x64 10.0.18362
VSCode version: 1.44.1

:warning: Make sure to attach this file from your home-directory:
Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

Want to add that 2020.4.74986 also causing a high CPU load on my machine.

Please create a new issue and upload the CPU profile which will help us track down the issue. Follow the steps here:
https://github.com/Microsoft/vscode/wiki/Performance-Issues#profile-the-running-extensions

@Typedef74 CPU profile states that you had this issue while getting python interpreters.
Can you please inform if you are using a network drive.
If an interpreter is on a network drive, fetching interpreters could be slow because Python process is running somewhere remote.
Although it doesn't look it like, try the using setting python.jediEnabled: true. Is this a one time thing?

I have the same issue, it happened each time I opened vscode.
It seems to come from a error on jediProxy (according to the appended log)
-1587978994800.log

Although it doesn't look like it, try the using setting python.jediEnabled: true. Is this a one time thing?

Disabling the setting removes the high CPU load

Your issue seems to be related to Language server, creating a new one for you.

Closing as no further info was provided.

Which info did you need? I’ve answered to all queries.
I still have the issue, I don’t understand why you closed it

This is referring to the original author @Typedef74 . Your issue was different which is why I opened a new one for you https://github.com/microsoft/vscode-python/issues/11439


List supported data types

In order to demo the data types we have, we need to list all supported data types and how to reference these types in create table statement.

Listed at https://docs.greptime.com/reference/data-types


hidapi error

I ran the binary on my Windows 11 build 22616.1 for my Bose 700.
I could execute bose-dfu.exe list, which return:
05a7:40fc X935501CG10809171J40020 Bose Noise Cancelling Headphones 700 [UNTESTED device in unknown mode]
But whenever I tried other commands (bose-dfu.exe enter-dfu -f or bose-dfu.exe info -f), here's what I got back:
[WARN  bose_dfu] Device has not been tested with bose-dfu; by proceeding, you risk damaging it
[WARN  bose_dfu] Cannot determine device's mode; command may damage devices not in normal mode
USB serial: X935501CG10809171J40020
Error: USB transaction error while requesting info field

Caused by:
    hidapi error: The parameter is incorrect.

Thanks so much for testing a new device! It looks like your device doesn't accept the same normal-mode commands that mine does. Hopefully, the DFU-mode commands are more similar to mine, but we won't know that until you can successfully get it into DFU mode! Can you gather the following information to help me figure out what commands your device wants?

The error message from bose-dfu when you run enter-dfu. I assume it's substantially similar to the info one you pasted, but confirmation would be nice.
A copy of the device's HID descriptor. I'm not familiar with the usual way to get this on Windows, but a quick Google indicates that https://github.com/todbot/win-hid-dump can do it.
(If possible, I know this one's a big ask.) A USB packet capture of the official updater updating your device (or even just starting up while your device is connected. You can gather this with [Wireshark)[https://www.wireshark.org/] (make sure to install USBPcap during installation).

Also, do you have the ability to build and run bose-dfu from source? It'll be easier to debug if so since I can send you patches to test. If not, I can send you prebuilt binaries, but those are harder for me to build (since I don't use Windows regularly).

Actually, I just found https://github.com/iclemens/bose which contains some of the things I asked for from someone else with the same device. I'll take a look at them in detail and let you know if it seems to speak the same protocol that bose-dfu implements.
I think it might not, from a quick skim of that repo's README and the fact that its firmware files aren't in .dfu format. If that's the case, extending bose-dfu might be just as much work as creating a whole new tool.

Thanks for looking, @iclemens! Unfortunately, that probably means that adapting this tool to support the NC 700 headphones would be nearly as much work as writing a new tool entirely. As such, I'm going to close this as WONTFIX for now since I don't have the time or hardware to undertake that effort. If someone else does, though, I am open to patches that add support for the NC 700's protocol as long as they don't make the existing protocol implementation harder to maintain.

I've published a new release, v1.1.0, which notes that we don't support NC 700 headphones in the README and prevents them from showing up in bose-dfu list.


ignition cmake  /usr/bin/ld: cannot find -lpthreads

Any guidance would be greatly appreciated.
Environment

OS Version: Ubuntu 20.04
Source
commit f043b4fc8aa234d95b570b6ad61db0c8592be007 (HEAD -> ign-rendering6, origin/ign-rendering6, origin/HEAD)

Steps to reproduce

Create build directory mkdir build
cd build
mkdir install
cmake .. -DCMAKE_INSTALL_PREFIX=./install

Output
CMake Error Log
Run Build Command(s):/usr/bin/make cmTC_4322d/fast && /usr/bin/make -f CMakeFiles/cmTC_4322d.dir/build.make CMakeFiles/cmTC_4322d.dir/build
make[1]: Entering directory '/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_4322d.dir/src.c.o
/usr/bin/cc   -fPIC -DCMAKE_HAVE_LIBC_PTHREAD   -o CMakeFiles/cmTC_4322d.dir/src.c.o   -c /home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_4322d
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_4322d.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -DCMAKE_HAVE_LIBC_PTHREAD    CMakeFiles/cmTC_4322d.dir/src.c.o  -o cmTC_4322d
/usr/bin/ld: CMakeFiles/cmTC_4322d.dir/src.c.o: in function `main':
src.c:(.text+0x46): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x52): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x63): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_4322d.dir/build.make:87: cmTC_4322d] Error 1
make[1]: Leaving directory '/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_4322d/fast] Error 2

Source file was:
#include <pthread.h>

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);
  pthread_detach(thread);
  pthread_join(thread, NULL);
  pthread_atfork(NULL, NULL, NULL);
  pthread_exit(NULL);

  return 0;
}

Run Build Command(s):/usr/bin/make cmTC_dbb13/fast && /usr/bin/make -f CMakeFiles/cmTC_dbb13.dir/build.make CMakeFiles/cmTC_dbb13.dir/build
make[1]: Entering directory '/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_dbb13.dir/CheckFunctionExists.c.o
/usr/bin/cc   -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTC_dbb13.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.16/Modules/CheckFunctionExists.c
Linking C executable cmTC_dbb13
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_dbb13.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTC_dbb13.dir/CheckFunctionExists.c.o  -o cmTC_dbb13  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_dbb13.dir/build.make:87: cmTC_dbb13] Error 1
make[1]: Leaving directory '/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_dbb13/fast] Error 2

Complete CMake output
cmake .. -DCMAKE_INSTALL_PREFIX=./install
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ignition-rendering6 version 6.2.1
-- Operating system is Linux
-- Found CPack generators: DEB
-- Looking for ignition-math6 -- found version 6.10.0
-- Searching for dependencies of ignition-math6
-- Searching for <ignition-math6> component [eigen3]
CMake Warning at /usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  By not providing "Findignition-math6-eigen3.cmake" in CMAKE_MODULE_PATH
  this project has asked CMake to find a package configuration file provided
  by "ignition-math6-eigen3", but CMake did not find one.

  Could not find a package configuration file provided by
  "ignition-math6-eigen3" (requested version 6.10.0) with any of the
  following names:

    ignition-math6-eigen3Config.cmake
    ignition-math6-eigen3-config.cmake

  Add the installation prefix of "ignition-math6-eigen3" to CMAKE_PREFIX_PATH
  or set "ignition-math6-eigen3_DIR" to a directory containing one of the
  above files.  If "ignition-math6-eigen3" provides a separate development
  package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/ignition-math6/ignition-math6-config.cmake:196 (find_dependency)
  /usr/share/cmake/ignition-cmake2/cmake2/IgnUtils.cmake:189 (find_package)
  CMakeLists.txt:33 (ign_find_package)

CMake Warning at /usr/share/cmake/ignition-cmake2/cmake2/IgnUtils.cmake:189 (find_package):
  Found package configuration file:

    /usr/lib/x86_64-linux-gnu/cmake/ignition-math6/ignition-math6-config.cmake

  but it set ignition-math6_FOUND to FALSE so package "ignition-math6" is
  considered to be NOT FOUND.  Reason given by package:

  ignition-math6 could not be found because dependency ignition-math6-eigen3
  could not be found.

Call Stack (most recent call first):
  CMakeLists.txt:33 (ign_find_package)

-- Looking for ignition-math6 - not found

-- Looking for ignition-common4 -- found version 4.5.0
-- Searching for dependencies of ignition-common4
-- Looking for dlfcn.h - found
-- Looking for libdl - found
-- Found DL: TRUE
-- Checking for module 'uuid'
--   Found uuid, version 2.34.0
-- Found UUID: TRUE
-- Searching for <ignition-common4> component [graphics]
-- Looking for ignition-common4-graphics -- found version 4.5.0
-- Searching for dependencies of ignition-common4-graphics
-- Looking for ignition-math6 -- found version 6.10.0
-- Looking for ignition-utils1 -- found version 1.4.0
-- Searching for dependencies of ignition-utils1
-- Searching for <ignition-common4> component [events]
-- Looking for ignition-common4-events -- found version 4.5.0
-- Searching for dependencies of ignition-common4-events
-- Looking for ignition-math6 -- found version 6.10.0
-- Looking for ignition-common4 - found

-- Looking for ignition-plugin1 -- found version 1.2.1
-- Searching for dependencies of ignition-plugin1
-- Searching for <ignition-plugin1> component [all]
-- Looking for all libraries of ignition-plugin1 -- found version 1.2.1
-- Looking for ignition-plugin1 -- found version 1.2.1
-- Looking for ignition-plugin1-loader -- found version 1.2.1
-- Searching for dependencies of ignition-plugin1-loader
-- Looking for ignition-plugin1-register -- found version 1.2.1
-- Searching for dependencies of ignition-plugin1-register
-- Looking for ignition-plugin1 - found

-- Found FreeImage: TRUE (Required is at least version "3.9")
-- Looking for FreeImage - found

-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
-- Looking for OpenGL - found

-- Checking for module 'OGRE-RTShaderSystem >= 1.9'
--   Found OGRE-RTShaderSystem , version 1.9.0
-- Checking for module 'OGRE-Terrain >= 1.9'
--   Found OGRE-Terrain , version 1.9.0
-- Checking for module 'OGRE-Overlay >= 1.9'
--   Found OGRE-Overlay , version 1.9.0
-- Checking for module 'OGRE-Paging >= 1.9'
--   Found OGRE-Paging , version 1.9.0
-- Looking for IgnOGRE - found

-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0")
-- -- Finding OGRE 2.2
-- Looking for IgnOGRE2 - not found

-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found CUDA: /usr (found version "10.1")
-- optix library not found.  Please locate before proceeding.
-- optix Prime library not found.  Please locate before proceeding.
-- Could NOT find OptiX (missing: OptiX_FOUND) (Required is at least version "3.8.0")
-- Looking for OptiX - not found

CMake Warning at /usr/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:55 (message):
   CONFIGURATION WARNINGS:
   -- Skipping component [ogre2]: Missing dependency [IgnOGRE2] (Components: HlmsPbs, HlmsUnlit, Overlay).
      ^~~~~ Set SKIP_ogre2=true in cmake to suppress this warning.

   -- Skipping component [optix]: Missing dependency [OptiX].
      ^~~~~ Set SKIP_optix=true in cmake to suppress this warning.

Call Stack (most recent call first):
  CMakeLists.txt:167 (ign_configure_build)

CMake Error at /usr/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:59 (message):
  -- BUILD ERRORS: These must be resolved before compiling.
Call Stack (most recent call first):
  CMakeLists.txt:167 (ign_configure_build)

CMake Error at /usr/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:61 (message):
  -- 	Missing dependency [ignition-math6] (Components: eigen3)
Call Stack (most recent call first):
  CMakeLists.txt:167 (ign_configure_build)

CMake Error at /usr/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:63 (message):
  -- END BUILD ERRORS

Call Stack (most recent call first):
  CMakeLists.txt:167 (ign_configure_build)

CMake Error at /usr/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:68 (message):
  Errors encountered in build.  Please see BUILD ERRORS above.
Call Stack (most recent call first):
  CMakeLists.txt:167 (ign_configure_build)

-- Configuring incomplete, errors occurred!
See also "/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeOutput.log".
See also "/home/thor/gsoc/ign-rendering/build/CMakeFiles/CMakeError.log".```

Upon further investigation it seems like the problem arises due to cmake using -lpthread, if I compile the code mentioned above in source file in cmake error logs and  compile it with -pthread , it compiles fine. However, I am unable to find the option to make cmake use -pthread instead of -lpthread.

set(THREADS_PREFER_PTHREAD_FLAG ON) adding this to the CMakeLists.txt does reduce the number of errors produced from lpthreads however still the sample file leads to the same error.

the main build error seems to be:
  Could not find a package configuration file provided by
  "ignition-math6-eigen3" (requested version 6.10.0) with any of the
  following names:

you'll need the eigen3 component from ign-math. You can take a look here for installation instructions:
https://ignitionrobotics.org/api/math/6.8/install.html

yes indeed it got resolved with this. Thanks.

This issue has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/gsoc-2022-texture-domain-randomization/1344/6


Tutorial Page hxe-python-django-polls.md Issue. PROD

Tutorial issue found: https://github.com/SAPDocuments/How-Tos/blob/master/tutorials/2017/01/hxe-python-django-polls/hxe-python-django-polls.md contains invalid primary tag.
Your tutorial was not updated. Please double-check primary tag property.
Each tutorial md-file shall have primary tag provided above. Example:
---
title: Text Bundles within Node.js SAP HANA applications
description: Working with text bundles in Node.js
primary_tag: products>sap-hana
tags: [ tutorial>intermediate, products>sap-hana, products>sap-hana--express-edition ]
---
Affected server: PROD

Fixed


Failed headless amplify pull does not return error code

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
npm install -g @aws-amplify/cli
If applicable, what version of Node.js are you using?
No response
Amplify CLI Version
10.0.0
What operating system are you using?
Ubuntu (GitHub Actions)
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
n/a
Amplify Categories
Not applicable
Amplify Commands
pull
Describe the bug
I'm trying to setup a GitHub Action workflow to automatically do an amplify pull and push on each commit, so that devs do not have to remember to do this on each commit.
When running amplify pull ... I'm currently getting the error:
Invalid configuration settings!
? Do you want to retry configuration? (y/N)

But the script is not exiting because amplify pull is not returning an error status code, even though it errored.
This is causing the script to move onto the next step, which is unexpected.
Here's my workflow:
# This is a basic workflow to help you get started with Actions

name: Run Integration Tests

# Controls when the workflow will run
on:
  # Triggers the workflow on push request events for the "preprod" branch
  push:
    branches: [ "preprod" ]
#  pull_request:
#    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # These permissions are needed to interact with GitHub's OIDC Token endpoint.
    permissions:
      id-token: write
      contents: read
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.10'
          cache: 'pip' # caching pip dependencies
      # Integration test expects ${AMPLIFY_STAGE} to be set, so we get that from the branch name
      # https://stackoverflow.com/a/58035262
      - name: Extract branch name
        shell: bash
        run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})"
        id: extract_branch
      # Set the env variable https://tinyurl.com/2p8tjpeu
      - name: Set AMPLIFY_STAGE env value
        run: echo "AMPLIFY_STAGE=${{ steps.extract_branch.outputs.branch }}" >> $GITHUB_ENV
      # Setup with https://www.automat-it.com/post/using-github-actions-with-aws-iam-roles
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: arn:aws:iam::[redacted]:role/github-actions-role
          aws-region: us-east-1
      - name: Amplify deploy
        run: |
          npm install -g @aws-amplify/cli
          ./scripts/headless_amplify_pull_push.sh
        env:
          AMPLIFY_APP_ID: [redacted]
      - name: Install dependencies (from Pipfile using pipenv) and run integration tests
        run: |
          pip install pipenv
          cd src/integration_tests
          pipenv install
          pipenv run python -m pytest .

And here is my script:
#!/bin/bash
set -eu # set e quits on first error, u errors if any variable is unset
IFS='|'
# This script is the headless equivalent of:
#   amplify pull --appId $AMPLIFY_APP_ID --envName $AMPLIFY_STAGE
# Meant to be used within GitHub Actions

# The following env vars are expected to be set:
# AMPLIFY_APP_ID: [redacted]
# AMPLIFY_STAGE: preprod
# AWS_REGION: us-east-1
# AWS_ACCESS_KEY_ID: ***
# AWS_SECRET_ACCESS_KEY: ***

# The last three AWS_ variables are set by aws-actions/configure-aws-credentials

# Verify all vars are set. set -u ensures these error and stop the script
: "${AMPLIFY_STAGE?Need to set AMPLIFY_STAGE}"
: "${AWS_REGION?Need to set AWS_REGION}"
: "${AWS_ACCESS_KEY_ID?Need to set AWS_ACCESS_KEY_ID}"
: "${AWS_SECRET_ACCESS_KEY?Need to set AWS_SECRET_ACCESS_KEY}"

echo "Working with branch/env ${AMPLIFY_STAGE}"

REACTCONFIG="{\
\"SourceDir\":\"src\",\
\"DistributionDir\":\"dist\",\
\"BuildCommand\":\"npm run-script build\",\
\"StartCommand\":\"npm run-script start\"\
}"
FRONTEND="{\
\"frontend\":\"javascript\",\
\"framework\":\"none\",\
\"config\":$REACTCONFIG\
}"

AWSCLOUDFORMATIONCONFIG="{\
\"configLevel\":\"general\",\
\"useProfile\":false,\
\"accessKeyId\":\"$AWS_ACCESS_KEY_ID\",\
\"secretAccessKey\":\"$AWS_SECRET_ACCESS_KEY\",\
\"region\":\"$AWS_REGION\"\
}"

AMPLIFY="{\
\"projectName\":\"ReliefBackend\",\
\"appId\":\"$AMPLIFY_APP_ID\",\
\"envName\":\"$AMPLIFY_STAGE\",\
\"defaultEditor\":\"none\"\
}"

PROVIDERS="{\
\"awscloudformation\":$AWSCLOUDFORMATIONCONFIG\
}"

echo "running: amplify pull..."

amplify pull \
--amplify $AMPLIFY \
--frontend $FRONTEND \
--providers $PROVIDERS \
--yes

### THE PREVIOUS STEP FAILS but it keeps going ###

CODEGEN="{\
\"generateCode\":true,\
\"codeLanguage\":\"javascript\",\
\"fileNamePattern\":\"src/graphql/**/*.js\",\
\"generatedFileName\":\"API\",\
\"generateDocs\":true\
}"

echo "running: amplify push..."
amplify push \
--codegen $CODEGEN \
--yes

Expected behavior
When commands have an error, they should return an error code.
It would also be great if the error gave more information than "Invalid configuration settings!" (I've been trying to debug this for days now. It runs fine locally)
Reproduction steps
run a failing amplify pull and observe the status code
GraphQL schema(s)

# Put schemas below this line

Project Identifier
No response
Log output

Run npm install -g @aws-amplify/cli

added 26 packages, and audited 27 packages in 9s

7 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Working with branch/env preprod
running: amplify pull...
Invalid configuration settings!
? Do you want to retry configuration? (y/N)
running: amplify push...
🛑 An error occurred during the push operation: /
File at path: '/home/runner/work/backend/backend/amplify/.config/project-config.json' does not exist
⚠ Review the Amplify CLI troubleshooting guide for potential next steps: https://docs.amplify.aws/cli/project/troubleshooting/

Additional information
No response

Hey @valentinrelief :wave: thanks for raising this! I have a few notes:
When working with initializing the project, amplify init may be a suitable replacement for amplify pull: https://github.com/josefaidt/amplify-with-github-actions/blob/main/.github/workflows/publish-amplify-app.yml

But the script is not exiting because amplify pull is not returning an error status code, even though it errored.

From the codebase I see where if there is not a confirmation on the retry prompt the CLI would correctly error out with a status code of 1, however it appears given the CI setting and the use of --yes it is instead auto-confirming the retry prompt and returning an empty initialization https://github.com/aws-amplify/amplify-cli/blob/dev/packages/amplify-provider-awscloudformation/src/configuration-manager.ts#L242
From your sample snippets, is AMPLIFY_APP_ID being set properly?

Thanks for the reply. Some of the snippets got a bit jumbled as I was trying to redact some private info, so here's what we're actually using.
BTW, I was able to trace the issue to the fact that amplify pull doesn't use the AWS_ env variables and instead only seems to read from the ~/.aws/ files for info.
integ_tests.yml
# This is a basic workflow to help you get started with Actions

name: Run Integration Tests

# Controls when the workflow will run
on:
  # Triggers the workflow on push request events for the "preprod" branch
  push:
    branches: [ "preprod" ]
#  pull_request:
#    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # These permissions are needed to interact with GitHub's OIDC Token endpoint.
    permissions:
      id-token: write
      contents: read
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3
      # Integration test expects ${AMPLIFY_STAGE} to be set, so we get that from the branch name
      # https://stackoverflow.com/a/58035262
      - name: Extract branch name
        shell: bash
        run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})"
        id: extract_branch
      # Set the env variable https://tinyurl.com/2p8tjpeu
      - name: Set AMPLIFY_STAGE env value
        run: echo "AMPLIFY_STAGE=${{ steps.extract_branch.outputs.branch }}" >> $GITHUB_ENV
      # Setup with https://www.automat-it.com/post/using-github-actions-with-aws-iam-roles
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ secrets.AWS_GITHUB_ACTIONS_ROLE }}
          aws-region: us-east-1
      - name: Amplify deploy
        run: |
          npm install -g @aws-amplify/cli
          ./scripts/headless_amplify_pull_push.sh
        env:
          AMPLIFY_APP_ID: ${{ secrets.AMPLIFY_APP_ID }}
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'
          cache: 'pip' # caching pip dependencies
      - name: Install dependencies (from Pipfile using pipenv) and run integration tests
        run: |
          pip install pipenv
          cd src/integration_tests
          pipenv install
          pipenv run python -m pytest .

headless_amplify_pull_push.sh
#!/bin/bash
set -eu # set e quits on first error, u errors if any variable is unset
IFS='|'
# This script is the headless equivalent of:
#   amplify pull --appId $AMPLIFY_APP_ID --envName $AMPLIFY_STAGE
# Meant to be used within GitHub Actions

# The following env vars are expected to be set:
# AMPLIFY_APP_ID: d39y0000000000
# AMPLIFY_STAGE: preprod
# AWS_REGION: us-east-1
# AWS_ACCESS_KEY_ID: ***
# AWS_SECRET_ACCESS_KEY: ***
# The last three AWS_ variables are set by aws-actions/configure-aws-credentials

# Verify all vars are set. set -u ensures these error and stop the script
: "${AMPLIFY_APP_ID?Need to set AMPLIFY_APP_ID}"
: "${AMPLIFY_STAGE?Need to set AMPLIFY_STAGE}"
: "${AWS_REGION?Need to set AWS_REGION}"
: "${AWS_ACCESS_KEY_ID?Need to set AWS_ACCESS_KEY_ID}"
: "${AWS_SECRET_ACCESS_KEY?Need to set AWS_SECRET_ACCESS_KEY}"

echo "Working with branch/env ${AMPLIFY_STAGE}"

# amplify doesn't support session tokens like the rest of AWS, so we have manually
# construct ~/.aws files:
# https://github.com/aws-amplify/amplify-cli/issues/7642#issuecomment-875881203

if [[ -n $CI && -n $AWS_ACCESS_KEY_ID && -n $AWS_SECRET_ACCESS_KEY ]]; then
    mkdir -p ~/.aws

    AWS_PROFILE=cicd
    CONFIG_PATH=~/.aws/config
    CREDENTIALS_PATH=~/.aws/credentials

cat <<-EOF >> $CONFIG_PATH
    [profile $AWS_PROFILE]
    region=$AWS_REGION
    output=json
EOF

cat <<-EOF >> $CREDENTIALS_PATH
    [$AWS_PROFILE]
    aws_access_key_id=$AWS_ACCESS_KEY_ID
    aws_secret_access_key=$AWS_SECRET_ACCESS_KEY
EOF
    if [[ -n $AWS_SESSION_TOKEN ]]; then
        echo "aws_session_token=$AWS_SESSION_TOKEN" >> $CREDENTIALS_PATH
    fi
fi

# https://docs.amplify.aws/cli/usage/headless/#sample-script-3

REACTCONFIG="{\
\"SourceDir\":\"src\",\
\"DistributionDir\":\"dist\",\
\"BuildCommand\":\"npm run-script build\",\
\"StartCommand\":\"npm run-script start\"\
}"
FRONTEND="{\
\"frontend\":\"javascript\",\
\"framework\":\"none\",\
\"config\":$REACTCONFIG\
}"

AWSCLOUDFORMATIONCONFIG="{\
\"configLevel\":\"general\",\
\"useProfile\":true,\
\"profileName\":\"${AWS_PROFILE:-default}\",\
\"region\":\"$AWS_REGION\"\
}"

AMPLIFY="{\
\"projectName\":\"ReliefBackend\",\
\"appId\":\"$AMPLIFY_APP_ID\",\
\"envName\":\"$AMPLIFY_STAGE\",\
\"defaultEditor\":\"none\"\
}"

PROVIDERS="{\
\"awscloudformation\":$AWSCLOUDFORMATIONCONFIG\
}"

echo "running: amplify pull..."

amplify push \
--codegen $CODEGEN \
--yes

BTW, I was able to trace the issue to the fact that amplify pull doesn't use the AWS_ env variables and instead only seems to read from the ~/.aws/ files for info.

Great callout! It appears there are two bugs here:

CLI should exit when configuration is invalid in a CI setting (where we're using --yes or when CI=true) instead of prompting
CLI should also use AWS_ environment variables when pulling

As a workaround, can you try changing pull to init? We likely do not need the additional information such as the project config for init

Sorry if I wasn't clear: the amplify pull command runs successfully once I got the aws credentials stored in the ~/.aws file. As a workaround, I'm creating the ~/.aws/config and credentials file
So currently, the only errors are what you listed above: #1 and #2

I suppose a tertiary issue was that the error message Invalid configuration settings! wasn't very helpful. It took a while to narrow it down to the credentials.

Amplify UI team also found this issue while setting up headless pull with GitHub Actions.
I did some root causing, and found that AWS_SESSION_TOKEN specifically were ignored in headless pull flow. I could confirm through manual dev that awsConfigInfo.config.sessionToken was undefined in
https://github.com/aws-amplify/amplify-cli/blob/9f577b9705e56e0f5e0dd0d043805f4037295801/packages/amplify-provider-awscloudformation/src/configuration-manager.ts#L467
which led to invalid configuration error. Other AWS env variables were set correctly. I could also confirm that setting sessionToken to AWS_SESSION_TOKEN in that file fixes the error.
We are currently using the workaround @valentinrelief uses, but it'd be great if this can be solved from CLI end.


Enhance build_metal.sh

Goals

Remove redundant documentation that should be in README.md
Add support for long options
Add support for --clean to remove stale build artifacts
Add support for --release, --development, --debug as aliases for Release, RelWithDebInfo, Debug build types
Add support for custom install prefix
Add support to optionally build tests

@blozano-tt ccache build appears to be broken after this change. is this something you can work on? 🙏


Increase RSA key size in RsaCheck()

32 bit is too small. 512 bit is the smallest valid length.
RSA_generate_key() will cause the following error when key size is too
small.

error:04081078:rsa routines:rsa_builtin_keygen:key size too small

As RsaCheck() fails, this causes build failure with OpenSSL 1.1.1 [1].
FreeBSD 12 's default OpenSSL is 1.1.1.

-- Alert: RsaCheck() --
OpenSSL Library Init Failed. (too old?)
Please install the latest version of OpenSSL.

Ideally, RsaCheck() should be re-written to use RSA_generate_key_ex()
since RSA_generate_key() is now deprecated but this is the easiest
workaround to fix the build with OpenSSL 1.1.1.
[1] https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20181105/946095.html
Changes proposed in this pull request:

Increase RSA key size in RsaCheck() to fix the build with OpenSSL 1.1.1

Your great patch is much appreciated. We are considering to apply your patch into the SoftEther VPN main tree.
SoftEther VPN Patch Acceptance Policy:
http://www.softether.org/5-download/src/9.patch
You have two options which are described on the above policy.
Could you please choose either option 1 or 2, and specify it clearly on the reply?

I choose contribution option 1.

Contribution option (1): Allowing us to apply the same patch into PacketiX VPN. (Default)

RSA key size has been increased at 553978c9a505c2fa427dba7633e69c8f147e9223.
https://github.com/SoftEtherVPN/SoftEtherVPN_Stable/blob/553978c9a505c2fa427dba7633e69c8f147e9223/src/Mayaqua/Encrypt.c#L2716


MudSelect: Change Visibility of "_currentIcon" to Internal

Description
This breaking change is proposed for V8, to change the visibility of MudSelect._currentIcon from public to internal.  This member appears to be for internal use by the component.
How Has This Been Tested?
This was tested by running all unit tests to ensure they still complete properly after the change.  Also, the "Select All" MudSelect example was tested, which exercises the _currentIcon property (for the "Select All" icon).
Type of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (fix or improvement to the website or code docs)

Checklist

[X] The PR is submitted to the correct branch (dev).
[X] My code follows the code style of this project.
[ ] I've added relevant tests.

Added to v8.0.0 Migration Guide
#9953


command: add new CLI command to retrieve the Ockam Orchestrator version

Depends on https://github.com/build-trust/ockam/issues/4052
We want to add a new command that retrieves the version of a given project.

Add new command in ockam_command::cloud named ockam cloud version that sends a request to the API developed at https://github.com/build-trust/ockam/issues/4052 that outputs the Ockam Orchestrator version
Add test in the commands.bats file

We love helping new contributors!
If you have questions or need help as you work on your first Ockam contribution, please leave a comment on this discussion.
If you're looking for other issues to contribute to, checkout issues labeled -  https://github.com/build-trust/ockam/labels/good first issue or https://github.com/build-trust/ockam/labels/help wanted

@adrianbenavides May I take this one?

Unfortunately, this is not read to pick up yet, as it depends on a development that must be done on the cloud side.


Add Cloud-Optimized Shapefiles

Yes, you've read that right: shapefiles.
See @calvinmetcalf's https://github.com/calvinmetcalf/coshp , and some comments at https://toot.cafe/@cwm/112680106863944942

http://blog.cleverelephant.ca/2022/04/coshp.html explains the full theory


save metadata in the filesystem

Userstory
I want the metadata (e.g. tags) to be saved in the filesystem in case the database crashes

This depends on #28 , because right now there is no connection between a Mission and a Path, or we could add a field path to a mission or give a path to the mission as an argument, which I would not prefer.


Render state notation parser: moved generated headers to build tree (…

…fixed #99)

Can you check why appveyor build fails. It did not fail in my commit.

Can you check why appveyor build fails. It did not fail in my commit.

The libclang module has no version for 32-bit python. In this case, a 32-bit version of python is launched.

The libclang module has no version for 32-bit python. In this case, a 32-bit version of python is launched.

This PR only changes the output folder of the generated files, everything else stays the same. It all worked before, so it is likely something different.


Run Fake API - Quartz Solar

Detailed Description
Test Quartz Solar UI with the API, and use Fake Data
This follows on from #354
Context

useful for people to run Quartz Solar UI with fake data. this allows them to developm new features

Possible Implementation

run api with fake api
run quartz solar ui - code is here

Cool. Thanks Peter!
I'll begin work on this in the NY


How to modify the ConfigMap file in POD

How to modify the ConfigMap file in POD

/kind support
https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically
/close


Problems while building plugin

Hi all, I try to build and run plugin, but can't succeed yet.
Firstly, I just cloned repo and executed ./gradlew assemble. It failed with such error:
$ ./gradlew assemble

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'intellij-eta'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Could not find com.typelead:gradle-eta:0.0.1-SNAPSHOT-fd00812.
     Searched in the following locations:
         file:/home/vere10/.m2/repository/com/typelead/gradle-eta/0.0.1-SNAPSHOT-fd00812/gradle-eta-0.0.1-SNAPSHOT-fd00812.pom
         file:/home/vere10/.m2/repository/com/typelead/gradle-eta/0.0.1-SNAPSHOT-fd00812/gradle-eta-0.0.1-SNAPSHOT-fd00812.jar
         https://plugins.gradle.org/m2/com/typelead/gradle-eta/0.0.1-SNAPSHOT-fd00812/gradle-eta-0.0.1-SNAPSHOT-fd00812.pom
         https://plugins.gradle.org/m2/com/typelead/gradle-eta/0.0.1-SNAPSHOT-fd00812/gradle-eta-0.0.1-SNAPSHOT-fd00812.jar
     Required by:
         project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 3.091 secs

I looked at plugins.gradle.org and noticed, that there's actually no such dependency. I found another dependency in repo and tried to fix it like this:
$ git diff
diff --git a/build.gradle b/build.gradle
index c84d00d..cea08a0 100644
--- a/build.gradle
+++ b/build.gradle
@@ -9,7 +9,7 @@ buildscript {
     mavenLocal()

     dependencies {
-      classpath 'com.typelead:gradle-eta:0.0.1-SNAPSHOT-fd00812'
+      classpath 'com.typelead.eta:com.typelead.eta.gradle.plugin:0.5.4'
     }
   }
 }

I tried to run ./gradlew assemble once again, but no luck:
$ ./gradlew assemble
Download https://plugins.gradle.org/m2/com/typelead/eta/com.typelead.eta.gradle.plugin/0.5.4/com.typelead.eta.gradle.plugin-0.5.4.pom
Download https://plugins.gradle.org/m2/gradle/plugin/com/typelead/gradle-eta/0.5.4/gradle-eta-0.5.4.pom
Download https://plugins.gradle.org/m2/gradle/plugin/org/jetbrains/intellij/plugins/gradle-intellij-plugin/0.2.17/gradle-intellij-plugin-0.2.17.jar
Download https://plugins.gradle.org/m2/gradle/plugin/com/typelead/gradle-eta/0.5.4/gradle-eta-0.5.4.jar
Download https://plugins.gradle.org/m2/org/jetbrains/intellij/plugin-repository-rest-client/0.3.21/plugin-repository-rest-client-0.3.21.jar
Download https://plugins.gradle.org/m2/org/jetbrains/intellij/plugins/intellij-plugin-structure/1.37/intellij-plugin-structure-1.37.jar
Download https://plugins.gradle.org/m2/org/jetbrains/kotlin/kotlin-stdlib/1.0.0/kotlin-stdlib-1.0.0.jar
Download https://plugins.gradle.org/m2/org/jetbrains/kotlin/kotlin-runtime/1.0.0/kotlin-runtime-1.0.0.jar
Download https://www.jetbrains.com/intellij-repository/snapshots/com/jetbrains/intellij/idea/ideaIC/LATEST-EAP-SNAPSHOT/ideaIC-LATEST-EAP-SNAPSHOT.pom
Download https://www.jetbrains.com/intellij-repository/snapshots/com/jetbrains/intellij/idea/ideaIC/LATEST-EAP-SNAPSHOT/ideaIC-LATEST-EAP-SNAPSHOT.zip
Download https://www.jetbrains.com/intellij-repository/snapshots/com/jetbrains/intellij/idea/ideaIC/LATEST-EAP-SNAPSHOT/ideaIC-LATEST-EAP-SNAPSHOT-sources.jar

FAILURE: Build failed with an exception.

* Where:
Build file '/home/vere10/dev/oss/intellij-eta/build.gradle' line: 1

* What went wrong:
Could not compile build file '/home/vere10/dev/oss/intellij-eta/build.gradle'.
> startup failed:
  build file '/home/vere10/dev/oss/intellij-eta/build.gradle': 1: unable to resolve class com.typelead.gradle.utils.EtaRuntimeUtils
   @ line 1, column 1.
     import com.typelead.gradle.utils.EtaRuntimeUtils
     ^

  1 error

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 2 mins 58.732 secs

I'm not sure, where to find this class.
Could someone help me in building plugin, please?

@carymrobbins Is in the process of migrating this project to work with the latest released Gradle plugin. The current version relies on older versions of Eta/Etlas and gradle-eta which you'd have to build from source. If you still want to build the plugin right now, you can build the fd00812 commit of gradle-eta from source.

@evis This should be resolved in the latest master; please reopen if you encounter any issues.


[Renesas RZ/A1H] Fix analogin peripheral names

This fixes definitions of peripheral names in analogin_api.c

@TomoYamanaka please review

I did code check.
I think that there is no problem.

Thanks guys


Styling changes to patient login landing page

Was doing some styling on the scheduling page on the patient landing page and there was a conflict when I went to push it. I accepted both changes and made sure the site wasn't broken but I wanted to leave the changes I made to the original scheduling buttons just in case.


Add the shutdown function to the docs (#545)

This is a suggested change to the RAML file to document the shutdown command. I am familiar with Swagger, but not RAML unfortunately, so this is untested guesswork! Happy to tweak, or feel free to use this as a base for more changes before merging.

The build error from Travis does not look like it is related to my RAML change. Any ideas?

I re-ran it and it's green now. Problem was a flakey Maven repo.

I forget where we were with this - can this be merged?

Sure

Thanks


Project Abandonment and Revitalization

Hey, if you aren't actively working on this I'd like to take over. I've rewritten color utilities at least five times now for separate projects, and I want to dedicate a crate to it once and for all.
If you require more details on what I plan to do with it, I can outline them all for you here.

Ooh, yes, would love to hear it!

Basically I want to provide what the palette crate does not: an optimal pixel storage format that is suitable for textures and GPU interactions.
Something with a C array representation, but still usable with idiomatic Rust. Using arrays internally can allow for certain SIMD optimizations in release mode and with the target CPU instruction set specified.
Fortunately, the nalgebra crate taught be about a neat trick to dereference arrays as a component structure, and that would allow code like this:
let blue = RGB::new(0.0, 0.0, 1.0);
println!("{}", blue.b);

even though the color is stored internally as [f32; 3]. nalgebra uses this for vectors and matrices.
Furthermore, useful blend operations like OpenGL ones or common photoshop blend operations would be a big plus. I've already implemented this once, so it's not a big deal to add here.
I would also like to provide a different approach to alpha channels and converting between alpha/non-alpha formats. My version would use associated types and type aliases to make Alpha<RGB<T>> equal to RGBA<T>, which is represented internally as [T; 4], like so:
pub trait WithoutAlpha: Color {
    type WithAlpha: WithAlpha;

    fn with_alpha(self, alpha: Self::Channel) -> Self::WithAlpha;
}

pub trait WithAlpha: Color {
    type WithoutAlpha: WithoutAlpha;

    fn without_alpha(self) -> Self::WithoutAlpha;
}

pub type Alpha<T> = <T as WithoutAlpha>::WithAlpha;

then implement those for the correct color formats.
Channel types will stay pretty much the same, since we both just define them as typical scalars.

Nice thinking! Have you thought about how you would (or would not) handle colour spaces?

Hmm. To be honest I still haven't fully decided. RGB is really the only color space used on the GPU, and most blending operations I've used aren't well defined for HSV/HSL, let alone the others.
However, the palette crate supports HSL, HSV, HWB, Lab, LCh, Luma, RGB, XYZ and YxY. So perhaps a better solution would be to include convenience methods for converting between Palette types and this crate's type(s), placed behind a Cargo feature flag.
What do you think? Supporting only RGB isn't bad, since it's really all I or most programmers ever need with graphics programming.
Also, the projects that I intend to use this crate with are:

whole game engine
software renderer
3D model loader (replacement for Assimp)
Custom texture format

and probably more. None of those use anything but RGB.
However, they do use sRGB, which is also something I'm unsure about handling.
If I were to use a wrapper type, it would have to perform all the operations of the normal linear colors, but do tons of conversion along the way, which would be slow.
Perhaps an alternative solution would be to place the conversion overhead on the user, and simply allow three methods for the sRGB wrapper type: new,  from_linear and to_linear, and immutable component access. That way users must convert back to linear to perform any operations, and no hidden conversions occur. In fact, the more I think about this the more I like it.

Don't get me wrong, if you would prefer we include other color spaces that's fine. However, since most of the work is already done over on the Palette crate, I'm indifferent to the extra work here.

Yeah definitely, I can appreciate you wanting to keep focused on your main domain. More thinking it might be good to leave room open to others to extend it in future contributions. PR #1 has more info if you are interested in past thoughts on the matter.

Have you thought of bringing some of your thoughts to the palette developers? Maybe there could be a possibility of joining forces with them? If not, I would be ok transferring ownership of this repo, and the crate to you. It's not likely I will get around to working on it in the near future, alas.

Hmm, interesting reading the 'What it isn't' section of the palette README:

What It Isn't
This library is only meant for color manipulation and conversion. It's not...

...an image manipulation library. It will only handle colors, and not whole images.
...an optimal pixel storage format. The colors are represented by linear floats, which is not a compact format and not meant to be displayed.

You will have to look elsewhere for those particular features. There are,
however, tools and traits in the pixel module for converting
to and from various pixel formats. These are meant to work as bridges between
Palette and other graphical libraries.

Would be interested to hear @Ogeon's thoughts on your ideas for color-rs!

I actually just opened up an issue over at Ogeon/palette/issues/71 for a new published version with all the stuff they've added in the last year. It's not a super heavy crate, so adding interoperability here with it would probably be our best bet for having additional color spaces. Palette's just not meant to be used for low level buffers and stuff.
If anything, I might attempt to fork palette and rebuild it with the stuff I'm designing for this crate, like the array-based channel representations. It shouldn't add significant developer overhead with the whole Deref component magic.

For now, though, I'm going to fork color-rs and commit everything I'm working on for it so you can get a better idea of what I'm designing.

Hi! See that other issue for my, and by extension my projects', general status. Aside from that, I'm interested in any kind of collaboration to improve its use in game development and other GPU applications. My initial goal was just to make "correct color math" easy, so I decided to prioritize that over GPU interoperability. There are still some conversion interfaces to and from array formats, but not much more.

Hmm. Kind of an extreme suggestion, but if I am able to replace the core structures in Palette with the ones I'm working on here, would you be willing to consider merging color-rs and palette?

Your suggestion sounds pretty much lite palette with a more optimal storage solution. Maybe we can do some interface changes to allow things like in place conversion and ways to choose the internal representation. I think image does something similar. I have a hunch that it's possible to find a way.

I went ahead and put the "array" type I intent to use for channels into its own crate: numeric-array.
Totally didn't spend almost four days designing that and analyzing generated assembly code...
However, now I can define generic channels like this:
pub trait ChannelAssertion {
    type Channel: Channel;
}

impl<C> ChannelAssertion for C where C: Channel {
    type Channel = C;
}

pub type SingleChannel<C> = NumericArray<<C as ChannelAssertion>::Channel, U1>;
pub type DualChannel<C> = NumericArray<<C as ChannelAssertion>::Channel, U2>;
pub type TripleChannel<C> = NumericArray<<C as ChannelAssertion>::Channel, U3>;
pub type QuadChannel<C> = NumericArray<<C as ChannelAssertion>::Channel, U4>;

and it'll automatically make the best use of SIMD and so forth when doing operations on them.
Note that all operations on NumericArray are component-wise, so actual color blending is separate.

I'm not sure I would remove support for transferring images in non-RGB formats to the GPU. I personally would benefit from running some algorithms on the GPU with colors in LAB or other spaces. I know that others in color vision research would also like this and why limit the possibilities of what one could do? I've already seen some people in the demo scene who have shader code for processing colors in LAB, LUV, and other spaces. I also know of at least one color vision researcher who uses non-RGB spaces on the GPU.

Oh, interesting. Thanks for mentioning that @rennis250!
I guess all a shader would want is a vector - it could convert it internally if needed. Of course its up to the shader to ensure that it interprets that vector correctly 🤔

RGB is really the only color space used on the GPU, and most blending operations I've used aren't well defined for HSV/HSL, let alone the others.

My use case is “have gradients that don’t look like ass”. Any color implementation that implements interpolation between two colors in sRGB space runs counter to that, since people will make the mistake to use it, resulting in gradients that look like ass.
So without color spaces, I support to firmly put interpolation as out of scope, and link a project that handles it instead.

It's been six years since I opened this issue. I've learned so much more about color since then. Color model != color space, all that jazz.
It's also been 8 years since there was a commit here, so it's kind of moot. Everyone has moved to palette or custom solutions.