Can this be compiled for earlier releases of Mac OS X ?

Can this be compiled for earlier releases of Mac OS X ?
( such as 10.10 )
It seems to need the 10.12 SDK for compilation

As far as I know, the App doesn’t use any critical feature that isn't available on 10.10.
Do you have any issue when compiling?

yes, I tried compiling on Mac OS 10.10 with the SDK for 10.10 and 10.11
but not SDK 10.12
it seems that there are unsupported language features ...
such as:
if let r = resource as? Resource<T>, r.type === type, r.identifier == identifier {

HyperCardPreview-master/HyperCardCommon/HyperCardCommon/ResourceSystem.swift:19:52: Boolean condition requires 'where' to separate it from variable binding

there are over 100 such errors ...

Ok, it won't compile because Swift 3 is not available in SDK 10.11. So the compilation is a lost cause. But the application could still run in Mac OS 10.10 because the Swift libraries are embedded.

Just to confirm, the current minimum system requirement 10.12, correct?
Perhaps that can be added to the read me file.

Can anyone please compile for Mac OS X 10.10 ?

You're right, I've added the version to the Read Me.
And Sandro, if you download the 1.0 release (in the "1 release" tab), it doesn't work?

It doesn't run on Mac OS X 10.10

which says :

You can’t use this version of the application “HyperCardPreview.app” with this version of OS X.
You have OS X 10.10.5. The application requires OS X 10.12 or later.

We can do a test I you wish, I can send you a 10.10 version to see if it works.

let's try it !


Adding API documentation for SI

API docs similar to [1] should be generated for the internal REST API of the Streaming Integrator.
[1] https://apim.docs.wso2.com/en/latest/reference/product-apis/service-catalog-apis/service-catalog-v1/service-catalog-v1/

How to start helping?


Height not working per article, seems to always be the same size even if you update it to 200px for example.

When I configure a custom height like 200px instead of 120px, the form dialog doesn't appear to change. It seems to always stay the same size no matter what I call out.

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

ID: d991c0b4-ff31-84e2-4084-f2ef82d77588
Version Independent ID: ad7a366f-8d17-82f5-ea6e-c5feee2545cf
Content: openAlertDialog (Client API reference) in model-driven apps - Power Apps
Content Source: powerapps-docs/developer/model-driven-apps/clientapi/reference/Xrm-Navigation/openAlertDialog.md
Service: powerapps
Sub-service: mda-developer
GitHub Login: @HemantGaur
Microsoft Alias: hemantg

Thanks for your comment, @jsdanie1. This issue has been assigned to the doc author for review.

@jsdanie1
Thanks for your feedback.
I believe the article is correct. Here is what I tested:

Open a model-driven app form
Open browser developer tools console
Use sample from article specifying height as 500

var alertStrings = { confirmButtonLabel: "Yes", text: "This is an alert.", title: "Sample title" };
var alertOptions = { height: 500, width: 260 };
Xrm.Navigation.openAlertDialog(alertStrings, alertOptions).then(
    function (success) {
        console.log("Alert dialog closed");
    },
    function (error) {
        console.log(error.message);
    }
);

Result: It is taller.

Maybe don't use px when setting the value?

I'm not using px, I basically copied and pasted the default script as well, left out button label and tried to adjust the height is all.
var alertStrings = {
    title: "Warning: Incorrect Quantity (Term)",
    text: "The term does not match minimum required term length on the product"
};
var alertOptions = { height: 250, width: 260 };
Xrm.Navigation.openAlertDialog(alertStrings, alertOptions).then(
    function (success) {
        formContext.data.entity.attributes.get('quantity').setValue(getTermRequired);
    },
    function (error) { console.log(error.message); }
);

but now that I'm looking at it again, its not cut off like it use to. It seems coming back to this maybe cache or something cleared out and now its displaying the proper windows lol


requirements can be defined more accuractely

Codecov Report

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

@@          Coverage Diff           @@
##           master      #2   +/-   ##
======================================
  Coverage    3.53%   3.53%
======================================
  Files           2       2
  Lines         651     651
======================================
  Hits           23      23
  Misses        628     628

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 c6e2e66...87775af. Read the comment docs.


Rework Nameplates

Clean up the nameplate

Smaller border
Name color to white
Power bar adjustment
Color tweak
Size tweak

Stretch goal

Better quest itegration with Quetie

Completed with last build.


Release 2.X

If anyone is interested in the work of merging the master branch into v2, add let us know here with a "🤚I'm interested in working on this" comment!

The comments below describe a random assortment of release 2.X concerns 📝

I'm thinking that I'll keep the current 2.0 branch as release 2.0 forever, and the very next release I make will be 2.1.

I'm also going to try to merge 2.0 into master ASAP. I may keep maintaining a 1.0 branch with bugfixes? If people are interested in that.

Isn't that a breaking change in terms of API? I am not sure its cool everyone that don't do vendoring. Also, current api and implementation is battle tested, v2 is not.

Isn't that a breaking change in terms of API? I am not sure its cool everyone that don't do vendoring.

My understanding of the go community is that the vast majority of people install from a tag, eg. 1.2.4 - and don't install from the default branch, eg master. So there's no API compatibility guarantee around the master branch.
That said, I just checked the yaml package and apparently they changed their default branch to be v2 https://github.com/go-yaml/yaml. So that may be the way to go here.

Also, current api and implementation is battle tested, v2 is not.

That's true! Are you suggesting we have a beta release period, or similar?

Got a comment via Stephen Houston in the gophers general channel on slack

Traditionally I would say you keep master based off your current stable with bugfixes added in to prepare for point releases ... I.e. if your current stable is 1.0 ... master is on 1.0 but with bugfixes added in to be able to tag 1.1 etc... you have a develop branch that is for features/future releases... when you get ready to do a new major release, i.e. v1 -> v2... master becomes develop and you tag... and then master follows 2.0 and gets bugfixes for 2.0 in order to do point releases 2.1 etc... and develop moves on to new features/future releases.

to echo @tsingson's comment here

this gopkg.in/urfave/cli.v2 is working fine for me in product about half year.

https://github.com/urfave/cli/issues/824#issuecomment-517824045

Since v2 was never officially released, it might be okay to make minimal breaking changes to the v2 branch before merging and releasing it?
I'm happy either way, but if that's more convenient then it should be okay since people know that v2 has not been released yet

There's some really good discussion in this thread about go packaging and release a V2 https://github.com/urfave/cli/pull/840#discussion_r310750414

I am not sure what the plan is here.
I am not a fan of the current "there are two different incarnations of the library in a single repo" stuff.
Ideally we'd have only one library that is the right library for everyone, and that would be on master.

Right, eventually (and hopefully sooner rather than later) the v2 branch should be merged into master branch.
But note that Go Modules completely doesn't care about either branches when you have git tags that are proper semver (which we do)
So my suggestion is the following:
you add a go.mod to the master branch with the following header module github.com/urfave/cli and then creating a new git tag: v1.22.0
and this way anyone issuing a go get github.com/urfave/cli will get the latest version (v1.22.0).
If someone wanted to get a version not yet tagged, they can still do go get github.com/urfave/cli@master and that should still work.
Now, once we merge v2 into master, anyone trying to do go get github.com/urfave/cli@master should fail since v2 is the default master branch and v2 is by definition a breaking change. I think that's totally okay, because anyone still wanting to get the regular v1 even after we merge v2 into master, can still do go get github.com/urfave/cli@latest or go get github.com/urfave/cli or even go get<EMAIL_ADDRESS>(x being whatever number they wish)
Furthermore, once we have v2 merged into master, we need to tag a new release, probably v2.0.0.  But we MUST change the go.mod file BEFORE we tag the new release to be module github.com/urfave/cli/v2 so that we maintain semantic import versioning.
And finally, everything should work. The master is the latest v2 version (which is what you suggested above), people can remain to use v1 as they wish (because Go Modules uses regular semver tags, and doesn't care about what's in the master branch). and people can also use v2 through the import path itself since it will have a v2 suffix.
The only thing missing in this process is patch branches, which we can create on the fly (if we know the exact commit before a major bump in master), or we can create stale version branches.

I am not a fan of the current "there are two different incarnations of the library in a single repo" stuff.

I agree 👍

Now, once we merge v2 into master, anyone trying to do go get github.com/urfave/cli@master should fail since v2 is the default master branch

Presumably this requires go.mod to be updated with a /v2 suffix?

@AudriusButkevicius

Presumably this requires go.mod to be updated with a /v2 suffix?

Yes, and also because I imagine the v2 has a different API than v1. Otherwise it wouldn't be v2, it would just be v1.x.x.

I guess go get github.com/urfave/cli with go version prior to module support would fetch v2 by default?

Yes, but since urfave/cli does not have sub-packages that it imports, it should continue to work. Though I'd be a fan of telling users to use modules if they want to use v2 since it'll be the default convention in 1.14 and onwards.

Seems like we're ok to merge v2 into master then.
I guess we need to compare feature parity and make sure we are happy with the API before we do that.

In case it's not clear - we will make explicitly sure that V2 has all the same features that V1 has currently 🙂

I haven't really checked what v2 actually looks like. Was it forked or rewritten? Is anyone aware of things that are missing in v1 but not v2 and vica versa?

For my part, I also don't know anything about the
current status of V2

👋  I updated the first post in this issue to reflect that fact that I specifically am not working on V2 right this moment. If anyone wants to do the work of bringing V2 up to date, let us know here!

I think merging master with v2 is going to be fun. Aside from bringing over features and bugfixes to v2, I think the two things we should consider for v2 are:
1 Getting rid of altsrc and merging the functionality into the main package
2 Restructuring the codebase to reduce the large number of files in the repo root. I thoroughly agree with @AudriusButkevicius about the need of having to clean the chaos.
I think if we can agree on this, I'd like to take this up and move forward toward a stable release. In the coming months I'd really like to see everyone working on v2 :)

Since V2 has been around for quite some time, I would slightly prefer if we made those additional breaking changes in V3? I'm fine adding them to V2 if enough people want that though!

What we can do in v2 is do the necessary refactors and still keep the existing public API using referencing our new internal API.
For v3, we can clean that up and have a brand new API
I think the more we push this back, the longer and more difficult the transition is going to be. I think we should have a date in mind and then only add new features to v2 and backport necessary features based on a vote. Otherwise, we would keep on maintaining multiple versions for a long time

Yea I want to get V2 into master ASAP, and ideally on backport bug fixes.

Let me get this underway from coming Monday

@asahasrabuddhe can I assign you to working only on merging V2 into master and (temporarily) un-assign you from the other tasks?
If you put up a draft PR for that work and only work inside of that PR, I can start getting a good idea of where we'll get merge conflicts and start moving all the other existing feature proposals over to V2.
In other words: I would like to help "clear the field" so that V2 can land into master cleanly 🙂

@lynncyrin yes please. I'd like that very much

Most of the changes done to v2 can be found in the CHANGELOG.md. However, for the sake of this conversation, let's take one significant change that I feel is better over the way things are done in v1.
v2 deprecates all the Global* methods of accessing global flags. Instead, it introduces the concept of the parent context. The flags now traverse through the Lineage and try to find out the flags they can access through the parent command or global app-level flags.
I think this is a good feature to have. It's more elegant. At the same time, it would break the API with v1.
If we really want to have one single source of truth of the library code in the master branch, I think we must agree to give up on v1 at some point. With the non-compatible changes in place in master, it would get difficult even to have a bug fix or a backported feature for v1 once the merge is done.
The way I see it, this is how we can do it. Fork out a branch from master at tag v1.22.1 called v1 which can be used for maintenance, backporting new features, and bug fixes. We would obviously EOL it and specify a date when it will stop receiving such fixes and urge people to move to v2. The migration is not very difficult and people who chose to do it will get on board v2 and others can safely continue to use v1.x.x.
Now, the master only has v2 code which we can continue to work on.

Fork out a branch from master at tag v1.22.1 called v1 which can be used for maintenance, backporting new features, and bug fixes. We would obviously EOL it and specify a date when it will stop receiving such fixes and urge people to move to v2. The migration is not very difficult and people who chose to do it will get on board v2 and others can safely continue to use v1.x.x.

I would like to propose a slightly more aggressive version of this plan, with some more detail!
As soon as https://github.com/urfave/cli/pull/892 is ready to land into master, we take the current master version and release it as 1.23.0. We'll also take the current documentation and changelog and maintain v1 and v2 versions. From that point on, we no longer release features for v1, but we do release bug fixes - particularly bug fixes for regressions.
We can also slightly modify the release pattern specifically for v1. Once v2 hits master, and the bug fix PRs for v1 should also update the changelog and be released immediately after being merged into the v1 branch. This will make PRs to v1 more work, but will ultimately serve to reduce maintenance burden.  PRs to v2 can continue being made the same way they are currently.
We continue in this state for exactly 1 year from the date of v2 being merged into master. After that year, we no longer accept any PRs to v1. I can be responsible for creating all of the PRs / documentation about this - in particular I want to create pull request and issue templates that explain to people how this all would work.

There's portions of the above suggestion that I feel pretty good about, since I imagine they won't be controversial 🙂  I'm going to stand up PRs for them now.

Sorry, have not red comments in full, but I vote for "once we merge v2, v1 is dead, and we only merge bug fix PR's (yet do not promise to fix stuff, people experiencing the bug can do that (unless its something tragic)).

Looking at the current state of the V2 PR https://github.com/urfave/cli/pull/892/, here's my summary of the changes:

all flags are global now
flag getnames to changed names
flgs can now return errors
many attributes changed to pointers for performance reasons
new flags added (floag 64 slice flag, path flag)
bool t flag removed
envvar string changed to envvars string[]
??? miscellaneous changes to command categories

This is me reporting on the state of that PR, not making any judgements about why changes were made / encouraging them to be shipped.

??? miscellaneous changes to command categories

☝  I'll get some more clarity on this before we merge

v1 historical branch is here => https://github.com/urfave/cli/tree/v1
I gave it similar branch protection as master, with the exception of making the number of required reviews for the v1 branch be 1 (which contrasts the 2 that master requires).

👀  I just merged all of @asahasrabuddhe's great work on the v2 PR!!!!! 🎉🎉🎉 https://github.com/urfave/cli/pull/892
Since v2 has now landed, I'll do a sweep through our open issues to see anything should be up-prioritized.
I created this ticket for a fast-follow migration guide https://github.com/urfave/cli/issues/921

I'm available at around 5 hours a day over the next ~9 days to do any fast follow IC work on potential v2 bugs, if we find any 👀  I'm going to try migrating one of my CLIs, see what I find.

@marwan-at-work v2 is now in master! I know you've been waiting for that for a while 🙏

@lynncyrin that's awesome, great work 💯💯💯 👏

I'm going to release the current master version as 2.0.0 today ✅

So excite for this to happen!

Here's the ✨Official Git Tag ✨for v2 => https://github.com/urfave/cli/tree/v2.0.0
It's now available via go get ... @v2.0.0


Creating new app with template gives error after deploy to FZ

Hi, after updating FZ to latest development branch and created demo app i get this error (that ApiTooOld). Firmware Api Version: 58. Anybody know what to do here?

@ASoldo, hi there!
I've just opened the PR to update to the lastest SDK version: #134.
Please try using its branch and test if it fixes the issue.

This is what I did but I get the same error message after moving .fap to FZ and running it.
[dependencies]
flipperzero = { git = "https://github.com/flipperzero-rs/flipperzero", branch = "sdk-0.99.1" }
flipperzero-sys = { version = "0.11.0" }
flipperzero-rt = { version = "0.11.0" }

You should also update -sys and rt references to the same repo

I did try that but it gives me this error when cargo build
[dependencies]
flipperzero = { git = "https://github.com/flipperzero-rs/flipperzero", branch = "sdk-0.99.1" }
flipperzero-sys = { git = "https://github.com/flipperzero-rs/flipperzero", branch = "sdk-0.99.1" }
flipperzero-rt = { git = "https://github.com/flipperzero-rs/flipperzero", branch = "sdk-0.99.1" }

Hmm, that's strange; I will take a look at it

Oh, I get it now.
We haven't updated the template repository yet, but the signature of the main function had changed recently. Now it accepts an Option<CStr> instead of the raw *const u8.
You just have to update it in your application as done in #125.

Oh, I get it now.
We haven't updated the template repository yet, but the signature of the main function had changed recently. Now it accepts an Option<CStr> instead of the raw *const u8.
You just have to update it in your application as done in #125.

Also, the above PR with API version bump has been merged so you can now use main branch.

Yes, now it works, I have switched to main and manually update main function.

Yes, now it works, I have switched to main and manually update main function.

After today's FZ firmware update I face the same (ApiTooOld) after successful build and run on device.

Hi @ASoldo,
Any time there is a major revision to the Flipper API, we gave to regenerate the bindings since the Flipper API is only compatible across minor API changes. Unfortunately this happens every few firmware updates (any ABI breakage triggers a new major SDK version).
One option is to manually regenerate the bindings. Typically the actual changes are pretty minor, so don't require any changes on the Rust side. The other is just sticking on the last supported SDK/firmware.
We have #41 as an issue to automate the generation of the bindings. I'd personally like to move away from bundling the bindings in the repository and have them generated at Rust build time, but we might also be able to add some better automation so someone doesn't have to manually check-in an updated version of the bindings.
I'm going to close this issue for the moment, since this will keep happening any time there's a major SDK version jump. However I'll see if I can come up with a better solution going forward.


missing temporary bam files

When running talon with my three samples i get the following error:
$ talon --f Analysis/talon/FAT11673.config --db Analysis/talon/WBcel235_gtf_talon.db --build Cel.WBcel235 --threads 12 --o FAT11673
[ 2022-08-19 11:15:36 ] Started TALON run
[E::hts_open_format] Failed to open file talon_tmp/FAT11673_nanofilt_unsorted.bam
Traceback (most recent call last):
  File "/fs/home/yeroslaviz/.local/bin/talon", line 11, in <module>
    load_entry_point('talon==5.0', 'console_scripts', 'talon')()
  File "/fs/home/yeroslaviz/.local/lib/python3.6/site-packages/talon/talon.py", line 2428, in main
    read_groups, intervals, header_file = procsams.partition_reads(sam_files, datasets)
  File "/fs/home/yeroslaviz/.local/lib/python3.6/site-packages/talon/process_sams.py", line 75, in partition_reads
    n_threads = n_threads)
  File "/fs/home/yeroslaviz/.local/lib/python3.6/site-packages/talon/process_sams.py", line 44, in preprocess_sam
    pysam.sort("-@", str(n_threads), "-o", sorted_bam, sam)
  File "/fs/home/yeroslaviz/.local/lib/python3.6/site-packages/pysam/utils.py", line 75, in __call__
    stderr))
pysam.utils.SamtoolsError: 'samtools returned with error 1: stdout=, stderr=samtools sort: can\'t open "talon_tmp/FAT11673_nanofilt_unsorted.bam": No such file or directory\n'

The config file looks like that
FAT11673_nanofilt,direct-RNA,Nanopore,Analysis/Nanopore_06.2022/talon/FAT11673_nanofilt_labeled.sam
FAT11673_porechop,direct-RNA,Nanopore,Analysis/Nanopore_06.2022/talon/FAT11673_porechop_labeled.sam
FAT11673_rawData,direct-RNA,Nanopore,Analysis/Nanopore_06.2022/talon/FAT11673_rawData_labeled.sam

CanI control the place where temporary files are written? Or how do I debug this problem?
thanks
Assa

Hi,
Can you try using the --tmpDir <your temporary directory> argument when running TALON? You may have to install the latest commits.

This problem should be solved by 15790fb96f6eb0d045bfb13be08c90df90feda37.


Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'replace')     at a.getSharePointFolderName

Hi kshitijkhanna , did you find any solution for this issue

Hello, I've been getting the same error. @kshitijkhanna @NEA-Consulting Any of you ever figured out a fix for this one?

Bump
@mikevalen3dc @kshitijkhanna @NEA-Consulting  @aymdg
Anyone found a solution for this?


python: op.write() seems have memory leak

Write a 2GiB file will need 6GiB memory.
import opendal
import asyncio
import gc

op = opendal.AsyncOperator("s3", xxx)
print(f"operator: {op}")

async def w2minio(f):
    fd = open(f,'rb')
    await op.write(f, fd.read())
    fd.close()
    gc.collect()
    print("end")

for i in range(3,7):
    f=f"x{i}"
    print(f)
    asyncio.run(w2minio(f))


Dissassemble

Add dissassemble functionality and UI to go along with it.
GDB uses the frame_info object to disassemble, so it will first make sense to the "easy" thing; only allow for disassembling functions.
Adding some "godbolt'ian" features to this UI would also be preferable, but not required in first iteration of this feature.

Disassembly using VSCode Disassembly UI implemented.
Not too happy with it, but it is what VSCode provides. Having a godbolt style would be better.


better testing setup

changes for better test setup:

we also installing all requirements for tests during setup of dev container, as PIP is arleady invoked those few adidtionall installs doesnt increse time of building devcontianer too much

added script scripts/test for manual invoking test suite (dependencies are installed during setup script

added VS code config for testing:

@anarion80  can you take a look into this and https://github.com/mariusz-ostoja-swierczynski/tech-controllers/pull/87


Shift-Enter to run a cell is not cached

Description
What steps will reproduce the problem?

If you have two consecutive code cells (starting with a #%%) and you try to run them both by pressing Shift-Enter twice, only the first cell will be run.
This happens when the first cell takes some time to run, and it's still running when you press the second shift-enter. The second shift-enter is ignored.
In version 3.X it works fine, running the two cells one after the other.
Versions

Spyder version: 4.0.0b3
Python version: 3.7.3
Qt version: 5.12.3
PyQt5 version: 5.12.2
Operating System: Windows 10

Dependencies
pygments >=2.0    :  2.4.2 (OK)
qdarkstyle >=2.6.4:  2.7 (OK)
sphinx >=0.6.6    :  2.1.0 (OK)
pyls >=0.27.0     :  0.27.0 (OK)
nbconvert >=4.0   :  5.5.0 (OK)
pandas >=0.13.1   :  0.24.2 (OK)
numpy >=1.7       :  1.16.4 (OK)
sympy >=0.7.3     :  None (NOK)
cython >=0.21     :  0.29.10 (OK)
qtconsole >=4.5.0 :  4.5.1 (OK)
IPython >=4.0     :  7.5.0 (OK)
matplotlib >=2.0.0:  3.1.0 (OK)
pylint >=0.25     :  2.3.1 (OK)

Thanks for reporting.
@bcolsen, could you take a look at this one?

This behavior was introduced in runfile with #7294 in version 3.3 to fix #7293. This allowed the stop button to stop all executing tasks by not allowing additional calls to the kernel while it's executing.
When I made the codecell function for spyder4 I included this fix for code cell execution.
There is also a ux issue here with the cell being advanced to the next cell without cell execution.
I for one regularly used this unofficial queuing behavior for code cells.
Some possible resolutions:
Solution 1
Don't allow cell advancement without cell execution.
This might need some sort of error or users might think the functionality is broken.
Solution 2
Make a runcell queue.
I personally like this idea but it would be quite work to implement.
Solution 3
Remove the fix for #7293 from runcell and regain the feature from spyder3
This reintroduces #7293, and gives broken output in the console:
In [14]: runcell('Cell at line 0','/home/bcolsen/Documents/python/runcell_queue.py')

In [15]: runcell('Long cell','/home/bcolsen/Documents/python/runcell_queue.py')
running long...

Ran long
running 1...
Ran 1

In [16]: runcell('short cell 2','/home/bcolsen/Documents/python/runcell_queue.py')Ran 2

In [17]:

Testing Code:
from time import sleep

# %% Long cell
print('running long...')
sleep(5)
print('Ran long')
# %% short cell 1
print('running 1...')
sleep(3)
print('Ran 1')
# %% short cell 2
print('Ran 2')

I don't agree with reverting the fix for #7293, so the only possible solution would be to create a queue for cells (and files too). But I don't think if that's a good idea because each evaluation could change the current namespace in significant ways, which could produce odd results for future evaluations.

I don't agree with reverting the fix for #7293

Yes that solution is isn't good.

But I don't think if that's a good idea because each evaluation could change the current namespace in significant ways, which could produce odd results for future evaluations.

I can see that this could be a problem with files and cells in the same queue, but it would be less of a problem if we only queue cell execution. I think that it would cover most of the use cases for this and users would expect that the commands would be run sequetially
There will be problems with queuing the new implementation of the runcell function @impact27 is working on. It currently gets the cell from editor at runtime in the kernel using the API. If the user queues up a few long running cells and makes changes to the file in the editor the queued commands would take the changed code from the file and not the code from the cell at that time it was queued. It's likely that most users would find this unexpected. The same thing would happen if you queued a couple of files for execution and then changed them.

There will be problems with queuing the new implementation of the runcell function @impact27 is working on. It currently gets the cell from editor at runtime in the kernel using the API. If the user queues up a few long running cells and makes changes to the file in the editor the queued commands would take the changed code from the file and not the code from the cell at that time it was queued. It's likely that most users would find this unexpected. The same thing would happen if you queued a couple of files for execution and then changed them.

The solution would be to capture the code when Shift-Enter is pressed, and cache it in some way. The logic would then be:

If there is code cached, use it. (verify the cell name and file name matches, maybe a dict)
else, use the api to get the code

This poses the problem of cache invalidation of course. How do we know if the cache is still valid (What to do if the user cancelled execution of one of the cached cells?).
An alternative would be to add an argument to runcell to explicitly fetch from cache. something like:
runcell(cellname, filename, cached=True)
This way it would be clear if runcell should use the api or the cache.

The solution would be to capture the code when Shift-Enter is pressed, and cache it in some way. The logic would then be:

If there is code cached, use it. (verify the cell name and file name matches, maybe a dict)
else, use the api to get the code

An edge case would be running the same cell 5 times with 5 different edits.
One way around this and cache invalidation is to cache the code directly into the queue.

While the kernel is busy, commands(and cached code) should be added to the queue every time a command(like runcell and runline) is given in Spyder.
When the kernel is finished, the next command in the queue is run.

This can include sending cache code to the server

If at any point the user clicks the stop button the current command is stopped and the queue is flushed.
This queue would be part of the Spyder IPython plugin so it would be unique to each kernel and still be modified while the kernel is busy.

Moving this here because it's not a regression and whether we save or not might not make a difference.
@impact27 said:

Why? Do you want to let the user run a cell and then modify it while it is in the queue? This will already be difficult, as the code is fetched at execution time.

I want to modify cell and execute a cell while a previous version of the cell is in the queue but I don't want to modify the code that is already in the queue.
The front end(spyder) queue needs to contain cached code because a user would expect that when they press a button on the front end on a cell or a file that the code at that time will be the code that eventually runs.
One solution would be to have a comms queue handler in spyder kernels that gets a command and cached code from the spyder queue(a list of dictionaries with commands and code caches). The queue handler could populate a code variable in ipython that if populated would be used as the code instead of asking spyder what the code should be.  There should be a few other ways as well.

Moving this here because it's not a regression and whether we save or not might not make a difference.
@impact27 https://github.com/impact27 said:
Why? Do you want to let the user run a cell and then modify it while it is in the queue? This will already be difficult, as the code is fetched at execution time.
I want to modify cell and execute a cell while a previous version of the cell is in the queue but I don't want to modify the code that is already in the queue.
The front end(spyder) queue needs to contain cached code because a user would expect that when they press a button on the front end on a cell or a file that the code at that time will be the code that eventually runs.
One solution would be to have a comms queue handler in spyder kernels that gets a command and cached code from the spyder queue(a list of dictionaries with commands and code caches). The queue handler could populate a code variable in ipython that if populated would be used as the code instead of asking spyder what the code should be. There should be a few other ways as well.

One way I can think of would be to add something to the cell name: if we want to run the cell "do stuff", and the kernel is busy, we could cache the cell content and give it a name like "do Stuff @ cache:1234". When the line is executed, the run_cell function will ask the frontend for the code for cell "do Stuff @ cache:1234", and the frontend could pop the cache. This way we don't need to modify the kernel.

One way I can think of would be to add something to the cell name: if we want to run the cell "do stuff", and the kernel is busy, we could cache the cell content and give it a name like "do Stuff @ cache:1234". When the line is executed, the run_cell function will ask the frontend for the code for cell "do Stuff @ cache:1234", and the frontend could pop the cache. This way we don't need to modify the kernel.

Yeah that's great idea. Definitely the way to go. The queue would then be a simple list of command strings and the cache would be a dictionary of code and hashes. We can have Spyder do all the code caching separately when it adds to the queue.
We could add an optional parameter to the runcell and runfile like cache=None which would be a little cleaner than adding it to the cellname and then having to parse it. Then we would be be able to  cache whole files for runcell as well(the imported modules could still change but we have to stop somewhere).

Yeah that's great idea. Definitely the way to go. The queue would then be a simple list of command strings and the cache would be a dictionary of code and hashes. We can have Spyder do all the code caching separately when it adds to the queue.
We could add an optional parameter to the runcell and runfile like cache=None which would be a little cleaner than adding it to the cellname and then having to parse it. Then we would be be able to cache whole files for runcell as well(the imported modules could still change but we have to stop somewhere).

I think this is the correct way of doing this. I modified runfile in https://github.com/spyder-ide/spyder/pull/10115 to get the code from the editor, so we could even cache runfile. When this PR is merged, a cache parameter can be added to _handle_get_file_code and handle_run_cell.


Crash in setter of currentTime property: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[AVPlayerItem seekToTime:toleranceBefore:toleranceAfter:completionHandler:] Seeking is not possible to time {INVALID}'

Hi there,
firstly thanks for the library, it works really well.
I got one issue though with a crash pretty frequently happening in the setter of the currentTime property in line 143:
player!.seekToTime(newTime,toleranceBefore: CMTime.zero,toleranceAfter: CMTime.zero)
It crashes due to the reason of newTime being invalid.
I added a workaround which works fine for me. I just do a safety check on newTime before calling seekToTime on the player:
if !CMTIME_IS_INVALID(newTime) {          player!.seekToTime(newTime,toleranceBefore: CMTime.zero,toleranceAfter: CMTime.zero)  }`
Could you add the code to the library or do you see problems with it? Or would you like me to create a pull request for it?
Thanks in advance

Here ,you might wanna create CMTime first and then provide that value to seek() as follows.
let seekTime =  CMTime(value: CMTimeValue(seconds), timescale: 1)
here timescale has to be 1. Refer this link explaining it. After this, add following code.
player.currentItem?.seek(to: seekTime, completionHandler:  { (finished) in                 print("Seeking finished")                 self.playbackStarted()     })
Thanks

Here ,you might wanna create CMTime first and then provide that value to seek() as follows.
let seekTime =  CMTime(value: CMTimeValue(seconds), timescale: 1)
here timescale has to be 1. Refer this link explaining it. After this, add following code.
player.currentItem?.seek(to: seekTime, completionHandler:  { (finished) in                 print("Seeking finished")                 self.playbackStarted()     })


iced-winit depends on a yanked version of winit

Is there an existing issue for this?

[X] I have searched the existing issues.

Is this issue related to iced?

[X] My hardware is compatible and my graphics drivers are up-to-date.

What happened?
When I ran cargo audit on my project, I saw:
Crate:     winit
Version:   0.29.11
Warning:   yanked
Dependency tree:
winit 0.29.11
└── iced_winit 0.12.2
    └── iced 0.12.1
        ├── iced_aw 0.8.0
        │   └── flowr 0.142.0
        └── flowr 0.142.0

warning: 3 allowed warnings found

So, that version was yanked
https://crates.io/crates/winit/0.29.11

What is the expected behavior?
cargo audit to pass without watnings for iced and iced-aw (the top level crates I ues)
Version
crates.io release
Operating System
macOS
Do you have any log output?
Crate:     winit
Version:   0.29.11
Warning:   yanked
Dependency tree:
winit 0.29.11
└── iced_winit 0.12.2
    └── iced 0.12.1
        ├── iced_aw 0.8.0
        │   └── flowr 0.142.0
        └── flowr 0.142.0

warning: 3 allowed warnings found

We don't depend on a specific version of winit. Could you run cargo update?

that fixed it. I generally do that occaisionally, so this version must have snuck in between me doing it.
Fixed! thanks!


Pract.02: Add 01-02 | Tsvetelina Mancheva

Tsvetelina Mancheva
SI 3 0MI0600239

Solutions for these exercises have been uploaded


Node backport memory leak fix

Huh. I obviously signed the CLA, and @w4-sjcho signed it, but I guess the fact that I authored none of the commits confused googlebot.


Get rendered CSS from component

Is your feature request related to a problem? Please describe.
More than once I wanted to be able to access the rendered css from stitches instead of using the classNames. For example, I have an external Cookie script that creates a Cookie modal on the DOM, I don't have access to add classes to it (or atleast I don't want to query the DOM all the time), so my approach is to override the global css. I have many UI Components, and instead of writing the same CSS as of those Components (like Button), I want to get the rendered css from them to inject into the cookie modal css id
Describe the solution you'd like
Something like this will fix the problem
const buttonCss = getCssCode(
  React.createElement(Button, { variant: 'secondary' })
)

const globalStyles = globalCss({
  '#cookie button': buttonCss,
})

globalStyles()

Describe alternatives you've considered
Additional context

Would be great. I have an external html, and want to construct styles from styled/css function to target a selector:
<Box
    css={{
        '& > p': {
            /* would be great */
            ...paragraph({ size: 1 }).css,
        },
    }}
    dangerouslySetInnerHTML={{ __html: `<p>Text</p>` }}
/>;

@hadihallak is it possible somehow?

You can directly pass the component as a selector https://stitches.dev/docs/framework-agnostic#use-it


Show-and-Tell: Applying selected consumer "demographic investing"

Problem: Finding the right way to create a pareto frontier for certain consumer demographics. Weirdly enough deepcopy is needed when both frontier finding and Sharpe-optimization.
Question:

How does one turn this into Sortino or Treynor optimization?
Are there any pie charts in this repo like riskfolio-lib's pie chart and proportional chart? https://pyportfolioopt.readthedocs.io/en/latest/Plotting.html#pypfopt.plotting.plot_weights

!pip install PyPortfolioOpt yfinance --quiet --upgrade

import numpy as np
import pandas as pd
import yfinance as yf
import warnings

warnings.filterwarnings("ignore")
pd.options.display.float_format = '{:.4%}'.format

# Date range
start = '2010-01-01'
end = '2020-12-30'

# Tickers of long-term $BECKY assets
assets = ["AAPL", "ADDYY", "AMZN", "BBBY", "BBWI", "BUD", "CHD",
          "CMG", "CVS", "DECK", "DEO", "DIS", "EL", "F", "FIZZ",
          "GPS", "JWN", "LRLCY", "LULU", "LVMUY", "M",  "MO", "MTCH",
          "NFLX", "NKE", "PVH", "RL", "SBUX", "STZ", "TAP", "TGT",
          "TJX", "TPR", "UAA", "ULTA", "VFC", "WSM", "WWW", "YUM"]

# Contemporary $BECKY companies
# "ABBV", "COTY", "CRON", "EOLS", "ETSY", "FTCH", "GOOS", "INMD",
# "LEVI", "LYFT", "MC", "META", "OR", "PINS", "PLNT", "PTON",
# "SFIX", "SKIN", "SNAP", "SPOT", "TLRY", "TWTR", "YETI",

assets.sort()

# Downloading data
data = yf.download(assets, start = start, end = end)
data = data.loc[:,('Adj Close', slice(None))]
data.columns = assets

data = data.dropna()
data = data.drop(columns=['AAPL', 'AMZN', 'NFLX'])

from pypfopt.expected_returns import mean_historical_return
from pypfopt.risk_models import CovarianceShrinkage

mu = mean_historical_return(data)
S = CovarianceShrinkage(data).ledoit_wolf()

from pypfopt.efficient_frontier import EfficientFrontier

ef = EfficientFrontier(mu, S)

from copy import deepcopy
ef_frontier = deepcopy(ef)

from pypfopt.plotting import plot_efficient_frontier
plot_efficient_frontier(ef_frontier) # "BEFORE optimising an objective"
# https://pyportfolioopt.readthedocs.io/en/latest/Plotting.html

weights = ef.max_sharpe() # or min_volatility()

cleaned_weights = ef.clean_weights()
ef.save_weights_to_file("weights.txt")  # saves to file
print(cleaned_weights)

ef.portfolio_performance(verbose=True)

for i in cleaned_weights:
  if cleaned_weights[i] > 0: print(i, cleaned_weights[i])

Also weirdly enough others have created a "point system", how do they differ from volatility? https://pythoninvest.com/long-read/practical-portfolio-optimisation


Finishing-Upgrade (STATE_CHANGED) with healthcheck enabled services

Rancher Versions:
Server: 1.3.3
healthcheck: 0.2.0
ipsec: 0.0.2
network-services: 0.0.8
scheduler: 0.3.0
Docker Version: 1.12.6, 1.13.0
OS and where are the hosts located? (cloud, bare metal, etc): Debian 8 / Arch, Both under qemu
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node rancher with external db
Environment Type: (Cattle/Kubernetes/Swarm/Mesos) cattle
Steps to Reproduce:

Make a new stack
Add a service

Enable healthcheck for the service, set some long count/time for healthy checks. like; 10 times with 6 seconds interval.

When up and running, start upgrading the service
Old container will be stopped, new container will start, will first be in "Initializing" state, until enough healthchecks are succeeded.
But upgrading UI will say "Upgraded" and allow "Finish Upgrade" when before container is considered healthy.
Press "Finish Upgrade"

Results:

Upgrading state will switch to "Finishing-Upgrade (STATE_CHANGED)", and will be stuck like that
Container state will be stuck at "Initializing" even though it becomes healthy
Only "Cancel Upgrade" option is available. (edited)

Expected Behavior:
Either;

Accept "Initializing" state as OK and finish upgrade cleanly.
Or wait until all new containers are determined "healthy"/running before saying "Upgraded" and allowing "Finish Upgrade" action.

I have tried this a couple times more, and reporting for accuracy; It did recover to "Active" state after waiting for a while (10~20 seconds).
Means; state is being broken with this steps only for a short time in my last tests.

I experienced this same issue upgrading a load balancer service this morning.

Component
Version

Rancher
v1.3.4

Cattle
v0.175.10

User Interface
v1.3.6

Rancher Compose
v0.12.1

Infrastructure Services:

Service
Version

healthcheck
v0.2.0

net
v0.8.1

metadata
v0.7.0

network-manager
v0.4.0

scheduler
v0.5.1

Using rancher CLI I did an upgrade from a docker compose file to bump rancher/lb-service-haproxy from 0.4.6 to 0.4.9. When I clicked "Confirm Upgrade," the state changed to Finishing-Upgrade STATE_CHANGED. Cancelling and attempting to roll-back caused rancher to continuously start new containers (using the 0.4.9 image, not the 0.4.6 that existed previously), and stop the "old" 0.4.9 containers continuously. Eventually, it stopped, and the entire service disappeared from the stack. I was then able to redeploy via the rancher CLI, and confirm the upgrade with no issue.
Trying again on a different environment, I saw the same behavior, but waiting about 30 seconds allowed it to continue successfully.
These load balancers have scheduler affinity set to global, and a small amount of custom HAProxy config to set a default backend for redirect. The internals of the container seemed fine, logging revealed that they were continually receiving SIGTERM so I don't think that it had anything to do with the load balancer service itself, appears rancher itself just lost state.

Closing as stale.


D3.5.3 LSST+VISTA Forced Photometry Module

The renumbering of this deliverable from D3.5.2 to D3.5.3 was approved by the Exec Group on 03/DEC/20 via change request C019 (see change register)

18/NOV/22

deliverable still expected to be complete by planned due date

06/JAN/23

moved to in progress

17/FEB/23

expecting this will be ready for review in early March

24/MAY/23

as reported at 10/MAY/23 Exec mtg, updates to deliverable following review and author response, will be delayed until new hire starts.
Change request therefore required to move due date

07/JUN/23

change request C076 drafted and sent to @mandabanerji and @richardgmcmahon for comment prior to submission to Exec

12/JUN/23

@mandabanerji and @richardgmcmahon agreed to submission of C076 to the 20/JUN/23 Exec meeting for approval

28/JUN/23

Change request C076 approved at 20/JUN/23 Exec meeting
Change request moved due date from 31/MAR/23 (PM45) to 31/MAR/24 (PM57)

17/NOV/23

expect updates to happen next year

08/MAR/24

Both review reports say the the deliverable is acceptable. The author response explained he reviewer suggestions will be dealt with in future deliverables.  Agreed therefore to fix the typos identified by the reviewers and then submit to Exec for approval.

08/JUN/24

approved following 04/JUN/24 Exec Mtg
PUBLISHED


New package: Timthreetwelve.WUView version 0.5.11

Pull request has been created with Komac v1.7.0 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/110145&drop=dogfoodAlpha

This application was approved in error. It installs normally but requires a dependency to run:


Fix typo on documentation

Changes:

Changes tesnet for testnet on documentation.

Types of changes

[x] Documentation Update

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (3f03977) 86.75% compared to head (7849825) 86.75%.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #318   +/-   ##
========================================
  Coverage    86.75%   86.75%
========================================
  Files           78       78
  Lines         4582     4582
========================================
  Hits          3975     3975
  Misses         522      522
  Partials        85       85

Flag
Coverage Δ

unittests
86.75% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


cephfs: return volume not found error if volume doesnot exists

In some ceph version, if the subvolume is not present, the ceph returns does not exist and in some version not found
error message. This commit fixes issue for both error checks.
sh-4.2# ceph version
ceph version 14.2.10 (b340acf629a010a74d90da5782a2c5fe0b54ac20) nautilus (stable)

sh-4.2# ceph fs subvolume getpath myfs csi-vol-a24a3d97-c7f4-11ea-8cfc-0242ac110012 --group_name csi
Error ENOENT: subvolume 'csi-vol-a24a3d97-c7f4-11ea-8cfc-0242ac110012' does not exist

sh-4.2# ceph version
ceph version 14.2.4 (75f4de193b3ea58512f204623e6c5a16e6c1e1ba) nautilus (stable)

sh-4.2# ceph fs subvolume getpath myfs testing --group_name=csi
Error ENOENT: Subvolume 'testing' not found

Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>This should fix the issue found in https://github.com/ceph/ceph-csi/pull/1237#issuecomment-659853953
@humblec please check do we need to backport it to downstream.

@ShyamsundarR @kotreshhr PTAL looks to be a regression from the ceph fs core side.

Thanks a lot @Madhu-1 .. Sure.... Will check on the backport!

@ShyamsundarR @kotreshhr PTAL looks to be a regression from the ceph fs core side.

@Madhu-1 Yes, the error string got changed between the versions but the errno returned remains the same ENOENT. It's more robust to rely on errno rather than the error string.

@ShyamsundarR @kotreshhr PTAL looks to be a regression from the ceph fs core side.

@Madhu-1 Yes, the error string got changed between the versions but the errno returned remains the same ENOENT. It's more robust to rely on errno rather than the error string.

Error ENOENT:  will be returned only if subvolume doesnot exists?

@ShyamsundarR @kotreshhr PTAL looks to be a regression from the ceph fs core side.

@Madhu-1 Yes, the error string got changed between the versions but the errno returned remains the same ENOENT. It's more robust to rely on errno rather than the error string.

Error ENOENT:  will be returned only if subvolume or subvolumegroup doesnot exists?

Yes, that's correct. ENOENT will be returned if either subvolume or subvolumegroup doesn't exist.

@ShyamsundarR @kotreshhr PTAL looks to be a regression from the ceph fs core side.

@Madhu-1 Yes, the error string got changed between the versions but the errno returned remains the same ENOENT. It's more robust to rely on errno rather than the error string.

Error ENOENT:  will be returned only if subvolume or subvolumegroup doesnot exists?

Yes, that's correct. ENOENT will be returned if either subvolume or subvolumegroup doesn't exist.

Thanks for the confirmation, Updated the PR as per suggestion PTAL.


Show bio/review to right of browse list if wide

Currently track listings on a wide screen waste a lot of space. A 'Show review' button should be added to large toolbar to show album review to right of track listing. Similarly add a 'Show biography' button for album list. If these are show, then respecting action in the "..." menu should be hidden.

Reduced width of lists when wide, and added buttons to show bio/review to toolbar. Changed mind about separate view.


Enable compiled node function

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

34 of 34 (100.0%)  changed or added relevant lines in 2 files are covered.
20 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-1.2%) to 81.048%

Files with Coverage Reduction
New Missed Lines
%

src/utils.jl
20
78.95%

Totals

Change from base Build<PHONE_NUMBER>:
-1.2%

Covered Lines:
1407

Relevant Lines:
1736

💛  - Coveralls


[libiconv] Also build on non windows platforms

Or is there a specific reason why libiconv is only building on windows and not the other platforms?

Hi @Neumann-A
I checked the history changes for libicnv and found this seemed to be changed by this commit .
But I also don't know why we only build this on Windows.

closing since iconv can be buildtin to the c library.


PHP7 minimum?

I'd like to raise minimum requirements for upcoming Grav 2.0 to PHP 7. Note that it will likely not be released this year, which means that PHP 5.6 will be receiving security fixes for less than a year when Grav 2 comes out.
Please give thumbs up or thumbs down reaction for this post (there is a smiley icon above ^). If you are against the change, also please give a reason why something like PHP 5.6 would suit better for you.
The main issue is that most of the libraries we depend on have PHP 7 minimum for the latest version, though some of them still maintain PHP 5.5/6 compatible version.
Another reason to jump to PHP 7 minimum are a few new language features which would greatly simplify the code and improve the quality of the project.

PHP 5.5 has been End of Life since July 21st, 2016.
PHP 5.5 will receive no more bug fixes.
PHP 5.5 will receive no more security updates.
PHP 5.6 has been End of Support since January 17th, 2017.
PHP 5.6 will receive no more bug fixes.
PHP 5.6 will receive security updates until December 31st, 2018.
Obviously, LTS maintainers might support it for longer in their distributions, but that's besides the point.
Since 5.6 is no longer supported by PHP, I wholeheartedly agree: Set the minimum requirement to 7.0.

I see no reason not to have Grav 2.0 to be PHP7.0+ only.  The next version will not be out for some time, and by the time it is, we need to be thinking about the future, and ensuring that 2.0 is viable for several years to come after release.

Given the time-frame of PHP 5.6, and the time-frame of Grav 2.0, it seems there would be a very short window for where 5.6 is worthwhile. It will at any rate just be receiving security-fixes as Eihrister notes, and many newer versions of dependencies are already bumping up to 7.0 as required. Thus if Grav is to continue to utilize up-to-date versions of it has to move to PHP 7.0 along with its dependencies.
That said, like PHP and libraries Grav depends on, the obvious solution is to set a time-frame for Grav 1.0 that follows along with 5.6. Ie., Grav 1.0 will continue to receive security fixes and patches until December 2018, but once Grav 2.0 comes out it goes all in on 7.1 because that is in active development - because 7.0 stops active support in December 2017.
Ultimately: Freeze the minor-version of Grav 1.0 when 2.0 is released, and set 2.0's minimum to 7.1 (given 7.0's time-frame).

I didn't specify which PHP7 version by purpose, the minimum will be whatever release is current when we do the release. By current I mean either PHP 7.1 or even PHP 7.2 if it is really worth it.

you also have to take into account if v7.2 will be widely available on shared hostings at the time plus we need to get grav into as many autoinstall hosting scripts as possible...my current hosting provider offers 70+ one click install apps but not Grav...

Given that 5.6 will be close to EOL or actually EOL, hosts will have to move to 7.x or loose credibility. There are many cases where hosts have not even gone to 5.6, and are thus incompatible with Grav and many other scripts. 7.2 is not all that much of an issue, because 2.0 can take account for the few idiosyncrasies there are between 7.0, 7.1, and 7.2 through fallbacks - whose necessity are revealed in Travis or the like.
Though any open source project like Grav would like for hosts to upgrade their installations, it's not really a worthwhile issue to make considerations for. If programmers were to wait for hosts to catch up, we'd still be mainly using PHP 4, barely having moved into 5. If the requirement is broadly construed as PHP 7.0 for Grav 2.0, it can be pushed to 7.1 and 7.2 with minor-version upgrades to 2.0. This still leaves open the avenue of freezing the minor-version of 1.0, where users will have to accept using an outdated version if their system does not have PHP 7 available.
But to impede progress and not utilize improvements to libraries Grav depends on would be outrageous.

Please keep in mind that PHP 7.0 will be supported for 5 years for Ubuntu 16.04, and Debian 9 (stretch) that recently came out. We're talking 2021, and 2022 respectively here. I would suggest not choosing 7.1/7.2 as minimum just yet.
Reason behind my suggestion is that those that will need another kind of version will, like now, most likely have to resort to external repositories. Those external repositories like sury.org (Dotdeb will not release 7.1 and higher), are mostly maintained by one person. The native LTS versions are maintained by whole Security Teams entirely focused on these things. For many production systems in corporate environments, LTS versions are way more ideal.

https://getgrav.org/blog/raising-php-requirements-2018


Removing some white backgrounds

:lipstick: Removing some white backgrounds (on home page and search results)

@madmath03 Thanks for the PR. You've done a good job keeping this CSS up to date with Ecosia's source code.

@madmath03 Thanks for the PR.


Added utility function backend_get_qubit_params

Summary
Added utility to return all relevant single-qubit parameters as a pandas DataFrame object, which can easily be manipulated, sorted, queried.
Details and comments
Example use
### Standard import
from qiskit import IBMQ
IBMQ.load_accounts()
backend = IBMQ.get_backend('ibmq_16_melbourne')

### Example use
df = backend_get_qubit_params_df(backend)
df.sort_values('T2', ascending=False).style.set_precision(3)

Example output of qubit data sorted by T2:

So, all of this info is already in tabular form in the jupyter backend monitor. The he exception is the ability to sort. But that could be added as a selector in the widget panel that holds the table.

yes if the intention is to be able to inspect this data (not necessarily do heavy post-analysis via Pandas dataframes), then the Jupyter widget is probably a quicker solution.
Pandas is currently not a dependency of Qiskit.

I'll close this for now as I think the Jupyter backend monitor widget accomplishes this task. Feel free to reopen if you still think this is needed.


Fix usage of the Metrics Timer.

When using the Timer aggregate the measurements by status and job name rather than by status and job id.
Job id is unique to each job run and therefore in the current implementation a new summary is created for each job run which doesn't collect useful metrics data and causes excessive memory usage.

thanks! I do think it might make sense keeping the job id in the dimensions. what do you say?

The matching is on the dimensions, so that wouldn't fix the issue. Apart from the memory issue that, I've just found out, affects Prometheus 1 only I think, if you use the job id in the dimensions, you're not aggregating anything. You're getting a separate histogram made out of one data point for each run of a job.
Like this:
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer_count 1
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer_sum 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.01", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.05", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.5", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.9", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.95", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.99", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer{success="true", quantile="0.999", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer_count{success="true", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 1
eeae9ddd_b279_4bb2_8d86_a993e1b3ae71_jobdurationtimer_sum{success="true", id="EEAE9DDD-B279-4BB2-8D86-A993E1B3AE71"} 0.002279166
# TYPE 17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer summary
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.01"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.05"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.5"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.9"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.95"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.99"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{quantile="0.999"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer_count 1
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer_sum 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.01", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.05", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.5", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.9", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.95", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.99", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer{success="true", quantile="0.999", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer_count{success="true", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 1
17df1d6d_3c71_4db5_9bda_80cd8ecfb013_jobdurationtimer_sum{success="true", id="17DF1D6D-3C71-4DB5-9BDA-80CD8ECFB013"} 0.002005

I think this is the kind of output that's useful?
emailjob_jobdurationtimer_count 1002
emailjob_jobdurationtimer_sum 0.233929109
emailjob_jobdurationtimer{success="true", quantile="0.01", jobName="EmailJob"} 0.000174042
emailjob_jobdurationtimer{success="true", quantile="0.05", jobName="EmailJob"} 0.00017925
emailjob_jobdurationtimer{success="true", quantile="0.5", jobName="EmailJob"} 0.000211583
emailjob_jobdurationtimer{success="true", quantile="0.9", jobName="EmailJob"} 0.000280563
emailjob_jobdurationtimer{success="true", quantile="0.95", jobName="EmailJob"} 0.000302521
emailjob_jobdurationtimer{success="true", quantile="0.99", jobName="EmailJob"} 0.0003743125
emailjob_jobdurationtimer{success="true", quantile="0.999", jobName="EmailJob"} 0.000685083
emailjob_jobdurationtimer_count{success="true", jobName="EmailJob"} 1002
emailjob_jobdurationtimer_sum{success="true", jobName="EmailJob"} 0.233929109

@0xTim not sure if you want to give this a once over too


where did the ax-pipeline repository gone?

where did the ax-pipeline repository gone?

The project is closed.If you need, please leave your email, I will send you the last version of the compressed package.

Please<EMAIL_ADDRESS>

@BUG1989 Unfortunately, I haven't received it.


Parameters does not copy function description message.

Bug Report

🔎 Search Terms

parameters jsdoc description message
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about parameters

⏯ Playground Link
Playground link with relevant code
💻 Code
/**
 * A function that returns the number you pass to it.
 */
function myCoolFunction(x : number) {}

function basicallyTheSameFunction(...args : Parameters<typeof myCoolFunction>) {}

Then hover over basicallyTheSameFunction.
🙁 Actual behavior
The function does not have a description, whereas myCoolFunction does.
🙂 Expected behavior
The basicallyTheSameFunction would have the same description as myCoolFunction.
📃 Motivating Example
I'm not familiar with the inner workings of TypeScript, so in case this is more of a feature request rather than a bug report, please consider the following use case: playground link
When working with jsdoc only, I think the cleanest way of supporting overloaded functions for Intellisense is like this:
/**
 * This function takes a number and a string.
 * @param {number} num
 * @param {string} str
 */
function signatureA(num, str) {}

/**
 * This function takes a boolean and an object
 * @param {boolean} bool
 * @param {Object} obj
 */
function signatureB(bool, obj) {}

/**
 * @param {Parameters<typeof signatureA> | Parameters<typeof signatureB>} args
 */
function overloaded(...args) {}

Then when typing overloaded(), the parameter suggestions window will show all the possible signatures, but unfortunately descriptions are not copied this way.

Is there any other way to transfer a function description like this that I'm not aware of? I'd really like to be able to autocomplete/document overloaded functions with pure js.


Add test for controlpanel module

Connection refused

That's why other tests wait until ZNC connects to the IRCd before trying to connect to ZNC as a client.


We are looking forward to Flutter's support for linux embedded development, which will be the perfect support for the whole platform of Flutter

The Internet of Things needs Flutter to support linux embedded development

Closing as this does not describe a specific feature request; "linux embedded" is not a specific platform. And there are a number of third-party embeddings build on the officially supported embedder API that target various embedded use cases.
If you are requesting first-party support for a specific target, please file a new issue with the Feature Request template and provide a detailed description of what exactly you are requesting.


Local pipeline fails to run when using relative script

Describe the issue
Local pipeline fails to run when using relative script
To Reproduce
Steps to reproduce the behavior:
1.Create a pipeline on elyra-pipelines
2.Add a script factorial.r from a sibling directory sample-script
3.See error:

Can you draw the directory layout?
elyra-pipelines/mypipeline.pipeline
sample-script/factorial.r

If this is your scenario then you need to use a symlink.

Also likely a duplicate of https://github.com/elyra-ai/elyra/issues/1734 et al

If this is your scenario then you need to use a symlink - support for kfp/aa is already available in master. (#1689)

This is a pipeline that use to work on a released version.

This seems like an issue on how the pipeline-editor is now calculating relative paths:
Master which is using pipeline-editor 0.3.0 : 'filename': 'sample-python/factorial.r'
#1620 which is using pipeline-editor 0.5.0: 'filename': '../sample-python/factorial.r'
Just as a reminder, the relativeness here is calculated from the workdir and not from where the pipeline is.

@lresende the pipeline-editor shouldn’t change the filepaths of nodes in an existing pipeline file. I would guess this is an issue on the JupyterLab side when preparing the file for submission

@ajbozarth could you please work with @bourdakos1 on this as you worked on this originally.

fixed


Cannot create a new function app project in visual studio code using Python

I cant make a new project anymore. I could before but now not anymore.

create a new function app project clicking on the "create new project" icon

Action: azureFunctions.createNewProject
Error type: EPERM
Error Message: EPERM: operation not permitted, open 'c:\Program Files (x86)\Python38-32\host.json'
Version: 1.0.0
OS: win32
OS Release: 10.0.18363
Product: Visual Studio Code
Product Version: 1.50.1
Language: en

Cant select any interpreter

And when i manage to make a project I can only see a few of the triggers not all of them

It looks like you're trying to create a project in "c:\Program Files (x86)". I would select a different folder and try again since that folder usually has restricted permissions


add public school graduation requirements

Research the requirements to get a public school diploma in Washington state.  Make a version of reqs.js called reqspublic.js that can be used to see progress for a public school requirements diploma.  Test by changing the reference in index.html

I can do this

I got this too

Added in development version but removed from production.


Sidebar disappears when I move browser window between monitors or if I resize the browser window

Hi,
This component is great and I have been making a dashboard for my team. Normally the sidebar works great ,until I resize the browser window or if I move the browser window between multiple monitors.
Is it supposed to do so? if yes , is there a way I can make the sidebar stay ?

Hello, I deeply apologise for responding late. There have been other comments on this and I will work tonight to rectify these. I had not configured the sidebar css file for other screen sizes. I will update the style.css file to reflect these new realities.

Hello, so I seem to have figured out the issue. When you resize the screen, it seems streamlit has made it such that the sidebar is shifted -300px to the left (off screen) so it won't be visible. I have adjusted the style.css file to reflect these changes. Let me know if it works. :)


Develop better struct/mechanism to present warning/error on operatorconfig

Right now there is only one messagefield is there in operatorConfig CR to display any message. Figure out a structured way to present warnings/errors in operatorConfig CR during reconcilation.

Fixed!


Request for Camera Intrinsics and Association Details

I'm currently working on a project that makes use of the images and trajectory data from bridge data v2. To fully utilize this data, I would like to the camera intrinsics for each camera used.
Specifically, I would like to know:

Camera intrinsics for each camera being used
Association of each camera with the corresponding trajectory data.
Association between each camera and the corresponding images folder.

I see camera's assignment and depth camera's assignment from the config:
  "camera_topics": [
      "/D435/color/image_raw",
      "/yellow/image_raw",
      "/blue/image_raw"
  ],
  "depth_camera_topics": [
      "/D435/depth/image_rect_raw"
  ],

However, can you point me where I will be able to find camera intrinsics? Many thanks in advance.

We mostly used Logitech C920 webcams, though some of the data uses an Intel RealSense D435 for the fixed camera view. All of the wrist camera images are from an Arducam. The setup guide has specific links to the exact models so that you can look up the intrinsics.
Each data collection attempt folder in the raw data (e.g. bridge_data_v2/datacol2_toysink2/pnp_push_sweep/00/2023-06-13_15-08-44) has a file config.json with the camera topics. The order of the cameras in this list determines how the images get labeled. The first camera is associated with the image folder images0, the second is associated with images1 etc. The mapping between names of topics and cameras is:

"/D435/color/image_raw" -> RealSense D435
"/yellow/image_raw", "/blue/image_raw", "cam0/image_raw", "cam1/image_raw", "cam2/image_raw" -> Logitech C920
"/wrist/image_raw" -> Arducam

Hi @XuweiyiChen ,
Were you able to figure out this: "Association of each camera with the corresponding trajectory data"? How did you convert from the world coordinate system to the camera coordinate system?


luhn: update to latest canonical tests

https://github.com/exercism/x-common/blob/134e4970dfa3f1cee7e054ddcacf694609f19290/exercises/luhn/canonical-data.json
Also includes some adjustments to the example solution to fix broken edge cases.

@FridaTveit updated!

Great, thanks! :)


composite fails with empty array

was expecting a no-op

Hello,
I am trying to use your code @fulldecent and for me it doesn't work even if the composites array isn't empty. I am not sure if it's normal, but it always return a never fulfilled promised and the image is never updated ...

@fulldecent Were you able to make any progress with this?

Got it, sorry. Yes it looks like my issue was actually https://github.com/lovell/sharp/issues/2873 and I had thought the problem was the composite.
Closing.


[MM-24016] - Fix channel header when there is an announcement bar in …

Summary
One last thing to take into consideration with the header popover was the Announcement bar on top that would change the vertical positioning of the popover.
Ticket Link
https://mattermost.atlassian.net/browse/MM-24016

Creating a new SpinWick test server using Mattermost Cloud.

Mattermost test server created! :tada:
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

Account Type
Username
Password

Admin
sysadmin
Sys@dmin123

User
user-1
User-1@123

Thank you @nevyangelova
seeing one issue
After banner is dismissed, the popover position doesn't get adjusted until refresh

New commit detected. SpinWick will upgrade if the updated docker image is available.

@devinbinnie @hmhealey  please take a look again. In order to get the correct top offset we were dependent on the announcement bar count which wasn't connected to redux so there was no way for the popover to know the count.

Mattermost test server updated with git commit 2e5bf94c515c8a7a2496f4f23d28c3ef88e6ed8d.
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

New commit detected. SpinWick will upgrade if the updated docker image is available.

Mattermost test server updated with git commit a8086ec53e3e9ac32e5a8404f01d9694471dc645.
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

Test server destroyed

Creating a new SpinWick test server using Mattermost Cloud.

Mattermost test server created! :tada:
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

Account Type
Username
Password

Admin
sysadmin
Sys@dmin123

User
user-1
User-1@123

New commit detected. SpinWick will upgrade if the updated docker image is available.

New commit detected. SpinWick will upgrade if the updated docker image is available.

Test server creation failed. See the logs for more information.

Mattermost test server updated with git commit d2320aeeb25911b60bd5e3cd30d2f639ce609531.
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

New commit detected. SpinWick will upgrade if the updated docker image is available.

Is the default part of "default_announcement_bar" needed? 0/5 on that one

I am 2/5 that we add default since the main folder for all bars is called 'announcement_bar' and for me it would look weird 'announcement_bar/announcement_bar' and since this is the default one I think this is more verbose.

Mattermost test server updated with git commit d3c9403f03bc1006114cc2120e1b28b68f4970d8.
Access here: https://mattermost-webapp-pr-5291.test.mattermost.cloud

Yeah, I started to write that components/announcement_bar/announcement_bar/announcement_bar.jsx didn't seem that bad, but then I deleted that after I wrote it 😛

Test server destroyed


Improving gcmd Code Coverage

Codecov Report

Merging #1628 (8acffd1) into master (1365c1d) will increase coverage by 0.17%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1628      +/-   ##
==========================================
+ Coverage   70.90%   71.07%   +0.17%
==========================================
  Files         444      444
  Lines       42294    42294
==========================================
+ Hits        29987    30062      +75
+ Misses      10403    10338      -65
+ Partials     1904     1894      -10

Flag
Coverage Δ

go-1.15
71.03% <100.00%> (+0.16%)
:arrow_up:

go-1.16
?

go-1.17
71.04% <100.00%> (+0.15%)
:arrow_up:

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

Impacted Files
Coverage Δ

os/gcmd/gcmd_parser.go
94.73% <100.00%> (+20.30%)
:arrow_up:

os/gspath/gspath_cache.go
87.71% <0.00%> (ø)

os/gcmd/gcmd_command_object.go
50.32% <0.00%> (+2.28%)
:arrow_up:

os/gcmd/gcmd_command_help.go
78.16% <0.00%> (+4.02%)
:arrow_up:

net/gtcp/gtcp_pool.go
38.63% <0.00%> (+4.54%)
:arrow_up:

os/gcmd/gcmd_command.go
100.00% <0.00%> (+45.00%)
:arrow_up:

os/gcmd/gcmd_scan.go
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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


Avoid pytest.PytestUnknownMarkWarning

pfnCI, test this please.

Jenkins CI test (for commit 16282a164e7b7ca50ffe9af3c87549a900568b05, target branch master) succeeded!

Test failures are unrelated.

LGTM.


Reserve 'AutoFixture' package prefix on the NuGet

Currently NuGet has ability to reserve package prefix, so only owner could push packages with such a prefix (see xunit as an example). That will allow to avoid situations when third party packages are being published with identity close the original one, so clients might be unsure who published them.
Consider the AutoFixture.NUnit3.PatchedName package as an example. You might think that this package is published by AutoFixture, but that isn't so. Therefore, to avoid confusion, we should prevent possibility to push such packages. People will still be capable of pushing their libraries, however they will be forced to use the different naming.

@ploeh As far as I got it, I'll need a verified account on Nuget to proceed on this direction. Would it be possible for you to share the credentials for the AutoFixture NuGet account? I'll later try to make it verified and perform NuGet name prefix reservation.

Sorry, I don't own the AutoFixture NuGet account, and I don't know what the credentials are...
I'm not sure, but it could be that it was created by @ecampidoglio...

@ecampidoglio Could you please take a look?

@zvirja I'll DM you the credentials for the AutoFixture account.

@ecampidoglio Thank you - the credentials have been transferred.
@onovotny @diverdan92 We would like to proceed with package prefix id reservation for the AutoFixture prefix as described here. While I found the instruction, I wasn't able to find the starting point (neither on nuget.org or github) - email/place where I can issue the request. Could you please advise on this? I do imagine that procedure is following:

Verify NuGet account ownership - the AutoFixture account in our case.
Reserve the AutoFixture* prefix, so that only AutoFixture account could push.

Thank you very much!

Just send the reservation request as that is described here: https://docs.microsoft.com/en-us/nuget/reference/id-prefix-reservation. I'm waiting for the reply.

OK. I got the MS mail firewall denial 😖 Am waiting for the further clarifications now...

Done! Now our packages have the "Verified" mark 😊

Also the AutoFixture.* package prefix is reserved, so only AutoFixture, phoeh and AlexPovar accounts could create packages with that prefix.
There is also an option to open some prefix for the community, so people could create their own extensions for the AutoFixture. I came up with AutoFixture.Community.* mask. That will allow our clients to create their own extensions for the AutoFixture, while it will be clear that those packages are not owned by the AutoFixture.
@moodmosaic @adamchester Do you have any concerns regarding the AutoFixture.Community.* package name prefix opened for anybody for push? If not - I'll proceed with a request to NuGet team.

@frblondin You have pushed a set of packages with very confusing names:

AutoFixture.NUnit3.PatchedName
AutoFixture.MSTest2

From the package name it might look like those products are being developed and supported by the AutoFixture, but that isn't so. You also used our logo for those packages which makes the situation even more confusing 😕
We need to decide how to proceed with those packages.

AutoFixture.NUnit3.PatchedName - This feature is already a part of the AutoFixture. The v4 (which will be released in upcoming week or two) will contain stable name out-of-the-box, so this package is no longer required. Could you please unlist the package from NuGet, so it's invisible for the search? People who already installed the package will be still able to restore the package.

AutoFixture.MSTest2 - Here the situation is even worse as you in fact "stole" the name. If we decide to support MSTest2 in future, we will be unable to publish to NuGet as this name is already reserved. Therefore, I'd like to ask you about the following (and would highly appreciate if you agree):

Unlist all the AutoFixture.MSTest2 packages.
Pass the ownership of the AutoFixture.MSTest2 package to the AutoFixture NuGet account. If later we decide to support this package, we'll be able to push it.
If you indeed would like to publish your own package for MSTest support, please rename package to AutoFixture.Community.MSTest2 and re-publish it. This name will clearly indicate that product isn't maintained by the AutoFixture and is community-driven instead.

Thomas, do you agree with such a plan? If you see more feasible options - please advice 😉

Good news!
As per your questions:

AutoFixture.NUnit3.PatchedName: we still need it for the lazy initialization of the fixture. This last part will be delivered in v4 in a week or so and my team still need to be able to create projects and get this package easily from nuget. this AutoFixture.NUnit3.PatchedName NuGet package is there for a year so I guess it can remain visible one more week?
AutoFixture.MSTest2: I temporarily tested MSTest2 but I'm not using it any longer.

Unlist all the AutoFixture.MSTest2 packages.
Done
Pass the ownership of the AutoFixture.MSTest2 package to the AutoFixture NuGet account. If later we decide to support this package, we'll be able to push it.
I sent you an ownership proposal in NuGet.org
If you indeed would like to publish your own package for MSTest support, please rename package to AutoFixture.Community.MSTest2 and re-publish it. This name will clearly indicate that product isn't maintained by the AutoFixture and is community-driven instead.
Not planning to use it anymore

Thanks

This AutoFixture.NUnit3.PatchedName NuGet package is there for a year so I guess it can remain visible one more week?

Sure, no worries 😉 Just wanted to align our actions and ensure that we fix that somewhere in future. If you still need to perform the new installations - it's a good reason to keep that till the release.

I sent you an ownership proposal in NuGet.org

Thanks a lot for that! I've just accepted the ownership request so AutoFixture is an owner now.

I sent you an ownership proposal in NuGet.org

Thanks a lot for that! I've just accepted the ownership request so AutoFixture is an owner now.

... and I just removed myself as an owner.

... and I just removed myself as an owner.

Great. Now we can be sure that you will not accidentally remove the ownership in future 😄

@moodmosaic @adamchester Looking forward to your confirmation on this to proceed further.

I decided to proceed further and NuGet team has already opened the AutoFixture.Community.* namespace prefix to everyone. That should simplify things as now the ownership will be clear.
@moodmosaic @adamchester Let me know if you have any concerns regarding the naming.
Closing this one as no more actions are required here.

@moodmosaic @adamchester Do you have any concerns regarding the AutoFixture.Community.* package name prefix opened for anybody for push? If not - I'll proceed with a request to NuGet team.

Sounds actually like a decent idea 👍


core_validation: Lock 'global_lock' in GetBuffer(Image)MemoryRequirements

Lock 'global_lock' while looking for IMAGE_STATE/BUFFER_STATE in GetBufferMemoryRequirements/GetImageMemoryRequirements. This is needed because other threads could add/remove other VkImage handles to/from the maps concurrently. The specs say the VkImage must be externally synchronized, but this doesn't cover the internals of the layers about VkImages in general.
vkCreateImage, vkDestroyImage and vkBindImageMemory/vkBindBufferMemory correctly lock 'global_lock'.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hey @jfmarquis, you're right that the locks are missing on these APIs.  Wouldn't it be safer to remove the braces around the lock and GetXxxState calls so that the lock protects the data changes?  Also, please reformat the commit message to match the rest of the commits in the repo (as described in the contributing.md doc).

@chrisforbes, is the scope of the lock sufficient here?  Also, @jfmarquis, please click through on the CLA if you would.

@mark-lunarg As I understand it, we're already guaranteed not to race on the contents of the object (enforced by threading layer above). Only the unordered_map lookup need be protected (against races with unrelated CreateImage/CreateBuffer/DestroyBuffer/DestroyImage for a different resource)

@chrisforbes, thank you very much.  @jfmarquis, please disregard that part of my comment!  Fixup the commit msg and sign the CLA and we're good to go.

@chrisforbes @mark-lunarg This was explicitly my intent about protecting the content of IMAGE_STATE, I wanted to reduce the scope of the lock to a minimum.
Sorry, I wasn't expecting the CLA to be this big. I should have looked before. My team and I are still looking at it.
Is my commit message inconsistent mainly because it needs a prolog like "layers: " and needs to be limited in length? Or is the content incorrect? Thank you for helping me with this.

@jfmarquis, no problems on looking at the CLA, take your time.  And you are spot-on about the commit msg.  Thanks for the fixes, and please keep the PRs coming.

Ok my organisation approve the CLA.
For the commit message I did 'git commit --amend' and updated it, but the result on GitHub is unsatisfactory. What did I do wrong?

Dunno what was up with your branch -- the merge commit was empty!  Anyway, I cherry-picked the good stuff and pushed it to master.  Thanks again very much, and we hope to see more in the future.


translating labels

I'm desperately trying to I18n.translate show_for labels - but I'm not able to locate where this translation happens, and further I'm not able to setup the correct da.yml :(
tried:
show_for:
   employee:
       gender:       "Køn"

show_for:
   gender:           "Køn"

show_for:
   employee:
      labels:
         gender:      "Køn"

neither seems to work?
what am I doing wrong  or does show_for not support translating labels?

shute that was fast!
thank you very much for your prompt answer - I forked the gem and added translation ;)
merry Christmas to you
kind regards,
Walther
Den 14/12/2011 kl. 14.56 skrev Carlos Antonio da Silva:

ShowFor does not have support to label translation by itself, but it does use human attribute name from Rails to get the label based on the current model/attribute. This means that, if you translate your attributes using activemodel/activerecord, ShowFor will show the right translated label for you.
Besides that, you can always give the :label option with the label to be shown.

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3139747

No problem :).
Don't you want to send us a pull request? Perhaps that could be added to ShowFor itself and we can release a new version.
Thanks, Merry Christmas.

sure would like to - but the thing is:
I added tests and all is good - but when I use the gem in my current project and add
da:
show_for:
user:
name:

the show_for does not find my translation, even though all my other translations work just fine

so I guess I'll need to investigate this issue somewhat before I'm able to offer any 2cents ;)
(but if you've got a second or two, please fork my show_for and perhaps slip me a hint to what I am doing wrong)
(angel)
cheers,
Walther
Den 15/12/2011 kl. 11.21 skrev Carlos Antonio da Silva:

No problem :).
Don't you want to send us a pull request? Perhaps that could be added to ShowFor itself and we can release a new version.
Thanks, Merry Christmas.

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159242

Ok, cool. I'm probably going to have time only on the weekend to check your
fork, I'll let you know then.
Meanwhile, feel free to investigate that and send us a pull request if you
think you're done :).
Thanks.
On Thu, Dec 15, 2011 at 9:21 AM, wdiechmann <
<EMAIL_ADDRESS>
wrote:

sure would like to - but the thing is:
I added tests and all is good - but when I use the gem in my current
project and add
da:
show_for:
user:
name:

the show_for does not find my translation, even though all my other
translations work just fine

so I guess I'll need to investigate this issue somewhat before I'm able to
offer any 2cents ;)
(but if you've got a second or two, please fork my show_for and perhaps
slip me a hint to what I am doing wrong)
(angel)
cheers,
Walther
Den 15/12/2011 kl. 11.21 skrev Carlos Antonio da Silva:

No problem :).
Don't you want to send us a pull request? Perhaps that could be added to
ShowFor itself and we can release a new version.
Thanks, Merry Christmas.

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159242

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159818

--
At.
Carlos Antonio

Great :)
I'm off to Berlin (Germany) and woun't be back 'till monday, so it's all yours :)
cheers,
Walther
Den 15/12/2011 kl. 12.36 skrev Carlos Antonio da Silva:

Ok, cool. I'm probably going to have time only on the weekend to check your
fork, I'll let you know then.
Meanwhile, feel free to investigate that and send us a pull request if you
think you're done :).
Thanks.
On Thu, Dec 15, 2011 at 9:21 AM, wdiechmann <
<EMAIL_ADDRESS>
wrote:

sure would like to - but the thing is:
I added tests and all is good - but when I use the gem in my current
project and add
da:
show_for:
user:
name:

the show_for does not find my translation, even though all my other
translations work just fine

so I guess I'll need to investigate this issue somewhat before I'm able to
offer any 2cents ;)
(but if you've got a second or two, please fork my show_for and perhaps
slip me a hint to what I am doing wrong)
(angel)
cheers,
Walther
Den 15/12/2011 kl. 11.21 skrev Carlos Antonio da Silva:

No problem :).
Don't you want to send us a pull request? Perhaps that could be added to
ShowFor itself and we can release a new version.
Thanks, Merry Christmas.

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159242

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159818

--
At.
Carlos Antonio

Reply to this email directly or view it on GitHub:
https://github.com/plataformatec/show_for/issues/26#issuecomment-3159966


Add new feature: accessing specified services.

Signed-off-by: xuezhaojun<EMAIL_ADDRESS>https://github.com/stolostron/backlog/issues/25889

/assign @skeeey
/assign @qiujian16
This RP is about option3 in this doc: https://docs.google.com/document/d/1bBM4fStlthLxdSxtSy069u8R07hqUqXcvO86mfqW3XI/edit#.

e2e test is affect by cluster-proxy repo, retry after this PR is merged.

/test e2e

/test e2e

/lgtm


Allow Multiple Rules to Match Event

Motivation
As mentioned here - https://github.com/falcosecurity/falco/issues/1541 -  only the first rule gets triggered and once Falco matches a rule, it stops processing other rules. This is meant as a performance improvement (I'm not sure by how much and it would be great if the actual speed improvements were documented somewhere) but it has the following serious cons:

rule writers have to be very careful about rule ordering. In practice, this probably means that you can't have the default rules first unless you modify / disable rules that may possibly overshadow your own rule
rule writers have to basically understand every rule that runs before their rule to make sure it doesn't match first
if a rule writer places their rules first in a custom file (before the default rules file), they would have to copy over all the macros and lists they want to use to their new file
you might end up disabling other useful rules in the fear that they overshadow your own rules
when testing, you typically only test your own custom rule(s). This means that your rule(s) may work as intended in testing but not in production due to a default rule hiding it in production. And if your backend is configured to report only on rules with a given PRIORITY, you might end up with no alerts on either rule
when adding new rules, you typically just add them to the end of the file instead of thinking where exactly in the rule order you have to insert them. Even the official rule set basically does this (for example, the k8s Audit All Events rule isn't the last rule in the file even though it would hide the rest of the rules after it). It isn't enabled by default but even then, it should be the last rule as it has the capability of hiding all remaining rules

It would therefore be great if this was configurable. I think very few rule authors will perform the necessary mental gymnastics needed for all of the above and it makes it more difficult for those who do want to add their own rules
Feature
an option in /etc/falco/falco.yaml to turn off the default behavior and allow all rules to be processed
Alternatives

Additional context

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

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.

/remove-lifecycle rotten

Now addressed by https://github.com/falcosecurity/falco/pull/2705 from @loresuso.
/close

@jasondellaluce: Closing this issue.

In response to this:

Now addressed by https://github.com/falcosecurity/falco/pull/2705 from @loresuso.
/close

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.

/milestone 0.36.0


Building with null for site_eui not getting hatch fill

I’ve been doing some footprint reviews on the live map and I noticed a couple properties showing up as Out of Compliance, but not displaying the crosshatching. Can you remind me – how were we determining the properties that are out of compliance? Was this a static list or is this supposed to be coming from the Carto data?

Building ID is 21916, Union Bay Plaza
Definitely some overlap with 50473 as seen here

But that's not the issue - there is not another building on top of the blue, the data shows null for site_eui_wn and it should get a hatch
┆Issue is synchronized with this Asana task

Writing this out helped me understand what is happening:

The "out of compliance" message is only conditional on site_eui_wn
Map defaults to total_ghg_emissions by default, and this building has a value for that. It's low, but non null:

If you switch the map to site_eui_wn it is correctly hatched:


Can I somehow point other sys crates (during compile time) to the libs build by this crate?

I have a project that needs to be cross compiled which has two deps that both require SSL. So I added:
native-tls = { version = "0.2", features = ["vendored"] }
to my own project to make sure SSL is compiled and linked statically. But one of the deps is itself also a sys create that requires OPENSSL_ROOT_DIR to be set when it's compiling (for which it is using the cmake crate), so I was searching for a way to dynamically set that to the directory used by this crate to reuse the compiled artifacts.
I can make a PR to the sys package the update or change it's behaviour, but I fail to understand how (and if) I can find the value I need and how (and again if) I can provide that dynamically. Thanks!

You would need to update that other crate to optionally depend on openssl-src. Once it does that, it can pick up the install path and set OPENSSL_ROOT_DIR properly for cmake in its build script.

Wow, that is a fast response! Thanks for the hint, I'm going to test/try if I can make it work that way. Thanks!

I'm trying this now, but I cannot get it to work. I first tried to add openssl-sys = { version = "0.9.58", optional = true } and then openssl-src = { version = "111.0.1", optional = true }, but both don't seem to give me any env vars I can use.
The first one should expose something like DEP_OPENSSL-SYS_ROOT according to this line. But is I write out all env vars in the build script of the sys crate, it doesn't show any DEP_XXX vars. The same when adding openssl-src directly.
I'm probably doing something wrong, but I don't know what...

I moved the dependency from the build-dependencies to the dependencies and that seems to have fixed it! I did also  notice that when the dependency is set to optional = true and the other dep that requires SSL is not yet compiled, it returns an error when trying to get the env var. Is that expected behavior or can I fix that? Thanks!

Closing this as it "working" for me now 👍🏻