Now requiring PHP 5.5.9

5252c82dd2abacfed19b0adc8e4dee1788d11661 did not set an upper bound on the version for Symfony dependencies. As a result, versions are being pulled in that now require a PHP minimum version of 5.5.9, which exceeds this repository's current minimum version of 5.3.

symfony/Console@9503491a59ef89b1ce78e1d14716cf6d89817842
symfony/Yaml@2daf2f6c6dc279117a4fedf32eae34f5d1d18600
symfony/Config@d3e7b5793623a322b297c4ed5c4b4a13bea62398
symfony/Stopwatch@e24eab195ce909eb25851fb9bc289f33d2411f3a

Going for ~ on Symfony dependencies instead of >= should fix this.

Indeed. See this blog post.

Here's an example of how this is undesirably affecting other projects still supporting 5.4.

That's not really how composer works.

It will just pull in the last version of symfony to support the older php version.

Or error out if there is none. Regardless, if this project purports to support PHP 5.3, as the composer.json file would suggest, it should do so by having appropriate dependency version requirements, with respect to the PHP version requirements of those dependencies.

We do have appropriate dependencies though. 2.x doesn't require php 5.5, thus our version constraints ARE appropriate.

The dependencies of 2.x as indicated by its composer.json file do not, therefore 2.x does not. It will not run in a <5.5 environment, and the Travis CI results linked in an earlier comment prove this conclusively.

Yes it will.

composer won't even install the dependencies in a 5.4 environment. So no, it won't.

That issue is actually because you are committing the lock file.
Delete the lock file.

You are causing this issue yourself by locking the dependencies on a version of symfony that php 5.4 does not support. You should not commit the lock file for libraries. That is a misuse of composer.

To my understanding, that suggestion goes against the Composer documentation on the subject.

@GrahamCampbell could it be that the no PHP version requirement in the composer.json is causing this combined with the minimum stability?

codeclimate/php-test-reporter is experiencing this issue and has no composer.lock file. Even if it did not require symfony/console>=2.0, satooshi/php-coveralls does.

To my understanding, that suggestion goes against the Composer documentation on the subject.

You haven't understood then. Sorry to be rude, but I don't have time to argue The docs clearly say application not library.

codeclimate/php-test-reporter is experiencing this issue and has no composer.lock file. Even if it did not require symfony/console>=2.0, satooshi/php-coveralls does.

I don't see what we can actually do here to fix this. If we changed the version constraint to ~2.1 it would piss people off because they now can't use coveralls with their symfony 3 code.

A good workaround for now would actually be to not use dev minimum stability. That way composer would be forced to give you 2.6.3.

Symfony 3 isn't planned to be stable until November. codeclimate/php-test-reporter is not using "minimum-stability": "dev"; it's using "php-coveralls": "0.6.*". The problem is that php-coveralls 0.6.1 changed Symfony component requirements to allow for 3.x versions, which by semantic version standards has the ability to introduce backward compatibility breaks and conflicts with the purpose of a minor or mini version change.
What you can do to fix this is tag php-coveralls 0.6.2 or 0.7.0 with the Symfony requirements referencing ~2 and modify master to reference ~3. That will allow anyone still referencing "php-coveralls": "0.6.*" to install it successfully while also allowing anyone using bleeding-edge Symfony to do the same by referencing "php-coveralls": "dev-master" until such time as a php-coveralls 1.x release is tagged that requires Symfony 3.x components.

@elazar Minimum stability is not determined by the libraries you're using. That's not how composer works. It's determined by your own project's composer/.son file.

NB, "php-coveralls": "dev-master" would be a sh**t idea. Always use version constraints.

Including "php-coveralls": "0.6.*" in a project running under PHP<5.4 will not work, at least as far as composer install is concerned, with or without "minimum-stability": "dev". That is the crux of my issue here. If you can refute that, I'm happy to stand corrected. However, I think the Travis CI job linked above was fairly conclusive in pointing that out.

@elazar That's simply not true. It does work. Let me demonstrate that...

@GrahamCampbell I can demonstrate that it doesn't:
$ cat composer.json
{
    "require": {
        "php": "5.3.*",
        "satooshi/php-coveralls": "0.6.*"
    }
}
$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package php could not be found in any version, there may be a typo in the package name.
  Problem 2
    - The requested package php could not be found in any version, there may be a typo in the package name.
  Problem 3
    - satooshi/php-coveralls v0.6.1 requires php >=5.3 -> no matching package found.
    - satooshi/php-coveralls v0.6.0 requires php >=5.3 -> no matching package found.
    - Installation request for satooshi/php-coveralls 0.6.* -> satisfiable by satooshi/php-coveralls[v0.6.0, v0.6.1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

You must be doing something massively wrong there. I cannot reproduce this.

What does the above output for you?

The above doesn't work because you've done it totally wrong. Run php -v please...

As you can see here, php-coveralls is installable on all versions of php just fine: https://travis-ci.org/GrahamTests/foo/builds/46904080.

The tests are failing because there are no phpunit tests to run.

I'm running OS X's stock version of PHP 5.5.19, but that shouldn't matter given the version constraints in this example. I also just ran composer self-update to confirm this wasn't an issue in Composer itself.
Again, including "php-coveralls": "0.6.*" in a project that requires "php":"<5.5" will not work as far as composer install is concerned. It may still work without the version constraint, but your example lacks that. If I have that requirement and "php-coveralls": "0.6.*", composer install will fail.

@elazar that composer.json will fail because its requiring php 5.3.*, so if you run it on a non-5.3 what composer will tell you is that "it cannot find php 5.3" since it cannot install php versions.
Indeed setting an un-bound version is not recommended because of semver, but in this case, given the requirement for it to allow symfony 3.0 it would indeed be justified.
But as rude as @GrahamCampbell is being (totally uncalled for btw), this should not raise the minimum requirement and composer should indeed grab the versions of symfony that do not require 5.5+.
@elazar can you give me some parameters so i can try and debug this? what system you are trying to run this on, php versions, your composer.json and your composer.lock?

I'm just really annoyed at people wasting time. :/

@GrahamCampbell you are wasting more time by giving them ridiculous replies and not addressing the actual issues. If your time is so precious, maybe don't reply, let someone with more patience reply. Its all just a big disservice.

It just took me a while to understand what was going wrong here with the bad setup. I don't see my replies as being ridiculous. They are address the issues and provide good solutions.

@rdohms The main point of issue is this Travis CI job. The output indicates that it's using PHP 5.4 and the latest version of Composer. For some reason, Symfony 3.x components are being installed, which require PHP 5.5.9, when what is expected is 2.x components, which require PHP 5.3. The repo associated with the job is not itself explicitly including Symfony 3.x components, nor does codeclimate/php-test-reporter, at least not that satooshi/php-coveralls does not itself require. I will concede that removing the composer.lock file from chrismou/phergie-irc-plugin-react-audioscrobbler does appear to work around the issue, but I'm not entirely certain I'm clear on why.

@elazar That is because of this line: https://github.com/chrismou/phergie-irc-plugin-react-audioscrobbler/blob/master/composer.json#L13.

@GrahamCampbell Thanks for this. Some interesting info here.
However, there's something I'm still unclear on.  If I run composer update locally before I push, composer.lock is updated to reflect packages relevant to my local PHP install version (5.5). In the travis config, it's set to run composer install before running, which if I understand correctly should take the composer.lock (if it exists) and attempt to install the packages listed in there. It only uses composer.json if composer.lock doesn't exist, hence in my case the build for 5.4 kept failing.
I'm hesitant to not commit the composer.lock file, as this is essentially me providing a list of the latest tested packages (and keeping in version control is recommended by composer themselves in their docs). By leaving it out, I'm risking someone installing my library along with a load of package versions I may not have yet confirmed compatible.
With that in mind, my question is that by having a requirement in php-coverall's composer.json that can potentially allow the installation of  package that isn't compatible with the version of PHP that the repo claims it is, what can I do to get around this long term?  Removing the minimum-stability line does sound like the quickest fix in this case, but unless you're planning on upping the requirements for php-coveralls to 5.5 in November (or whenever Symfony 3 is out), this seems like it could be a bit of a short term solution.
This isn't meant as a argumentative point, I'm just trying to understand. From my point of view, all I can see is that composer allowed a version of Symfony console/etc to be installed that wasn't compatible with 5.3. If coveralls is supposed to be compatible with 5.3 upwards, then what's the logic in allowing composer to install symfony 3 components? Is the symfony 3 roadmap clear enough that we can be 100% sure that no changes will be made that could break php-coveralls?

@chrismou recommendation to commit composer.lock is for applications, not packages. Also the composer.lock will not play a role whenever someone tries to install your library, only if its the "root" so, imagine your contributors, not users. The argument for keeping the lock in is to make your contributors not face random breakages due to external sources, which i made myself but have come to realize as not being too valuable in some cases.
I'm not sure why the minimum-stability flag is causing this, but it should not be. Also composer is only now fixing some details to properly ensure it installs packages according to php version, expect this to be better.
The approach of coveralls is understandable, they want to allow their library to be installed along side Sf 3, which would not be possible by binding to ~2.0 for example. If you require symfony 3 in your composer and coveralls, no matching version would be found since it cannot have 2 versions of the same libraries.
IMHO, it may be worth splitting into a symfony 3 compatible branch, as there is no real guarantee that symfony-3 will not break BC on any of the components in use, it is after all a major release.

Gotcha. That does make sense. Perhaps I took the composer docs at face value a bit too much without reading enough into it.
What you've suggested does make sense though. It would be useful for me (and perhaps anyone else who's supporting EOL PHP versions) to create a final 0.6.x tag we can reference to guarantee 5.3 compatibility and switch to 0.7 for symfony 3 support (or whatever). But in lieu of that, at least I now have a solution to get it building on 5.4.
Cheers for the info!

I'm not sure why the minimum-stability flag is causing this, but it should not be. Also composer is only now fixing some details to properly ensure it installs packages according to php version, expect this to be better.

Let me explain what's happening here. composer install was run on php 5.6 and the min-stability was set to dev, so composer went and got the very latest version it could find that satisfied the version constraints. This meant we got symfony 3.0.x. This was then committed to a lock file. When someone now tries to run composer install with this lock file on php 5.3, they can't, because the version constraints are no longer satisfied. This is solved, for now, by not setting the min stability to dev, because they'd be getting 2.6 on any system.

Yes I understand what happens due to the lock file. However setting min
stability should not affect this. It looks like unintended behavior.

No, it absolutely should affect this, as I've explained.

The only effect removing Dev would have is to not load symfony 3 cause its
not stable. Which still means composer is not looking at the php version to
determine which package to install. Hence this is not a solution but a hack.
That is what I'm saying. Composer should be picking 2.6 for non 5.5
environments, the stability flag would make no difference there.
On Jan 14, 2015 11:24 PM, "Graham Campbell"<EMAIL_ADDRESS>wrote:

No, it absolutely should affect this, as I've explained.
—
Reply to this email directly or view it on GitHub
https://github.com/satooshi/php-coveralls/issues/81#issuecomment-70004769
.

@rdohms Composer can't do that because it's forced not to by the lock file. if it wasn't for the lock file, that's exactly what it would have done.

@GrahamCampbell unless you are saying "minimum-stability" set to stable makes it ignore the lock file, you seem to be missing the point here.

Doing that will work until php symfony 5.5 is release. By that time, php 5.4 will be eol, so everyone should be using 5.5.

@GrahamCampbell php symfony 5.5?

@GrahamCampbell This repo states that it supports 5.3, but that's been EOL for nearly 6 months.  I'm not sure the world is going to collectively abandon all 5.3 support in September
Looking at the commit history, I can see that a pull request was merged in that did pretty much exactly what @elazar suggested earlier (https://github.com/egeloen/php-coveralls/blob/234dd8d7f7bcbf2779e6cdaeaf867aa6c36fb40d/composer.json), but was reverted due to another issue.  In which case, through all this debate, perhaps asking @satooshi's opinion might be the next step, as he didn't seem too adverse to the idea originally.
I still maintain that tagging 0.6.2 to guarantee 5.3 support would be the most developer friendly way of dealing with this, then everything following this can go towards a 0.7.0 release, which would (eventually) have a min 5.5 requirement. Everything else suggested so far is akin to a timebomb set to go off the day Symfony 3 is released.

The trouble is not symfony here, it;s just that people aren't using composer. right. If you want to make sure your locked dependencies are php 5.3 friendly, than you have to actually generate the lock file by running composer on a php 5.3 install.

IMO, the composer.json file should be refine first by merging #76, second by refining minimum constraints as for now, this library does not work if you use it with the --prefer-lowest composer flag.
Regading the original issue, Symfony should be locked on 2.* versions and so, #76 should fix the issue. (Saying that this library will be compatible with Symfony 3 is a little bit too early IMO).

@egeloen That still won't fix the issue. Although we're requiring symfony 2.x components, those symfony components actually have dependencies on oher symfony components, and those version constraints will cause those components to be loaded as 3.x anyway.

Or, rather will do at some point. I don't like the idea, but the symfony core want to do it.

@GrahamCampbell Some symfony 2.x components have dependencies on 3.x components? I'm a little bit lost :) If you require "symfony/console": ~2.0", then composer can only download a 2.x.xrelease not a3.x.x`.

No. Say if you required "symfony/console": "~2.0", but symfony/console had a dependency on "symfony/foobar": "~2.0|~3.0", then you're still getting 3.x components...

then you're still getting 3.x components...

Obviously, you're still getting symfony/console 2.x, but do you see what I mean when I say the dependencies have dependencies we can't control.

Yeah, I understand! I have missed the PR which have allowed the 3.x components in Symfony. Thanks for the info!

Great. :)

Just for the record, it appears I'm not the only person running into this situation. The link in that tweet redirects to an issue that references this one and includes a work-around.

This literally isn't an issue though. It's only caused if you're using composer wrong.

@GrahamCampbell Can you clarify a couple of your responses:
"we're requiring symfony 2.x components, those symfony components actually have dependencies on oher symfony components, and those version constraints will cause those components to be loaded as 3.x anyway."
"It's only caused if you're using composer wrong."
Can both of these statements be correct?  If php-coveralls requires libraries that require symfony 3 libraries that in turn have a PHP 5.5.9 dependency, is there any long term way of fixing this? (by long term, I mean beyond the official release of symfony 3).
Using composer "correctly", however that may be, sounds like it may only be a temporary fix at best.

OK no worries, I've moved to using Scruntinizer for code inspection now and removed coveralls, so this isn't really an issue for me anymore.
For anyone who stumbles across this thread, here's the breakdown:
It's down to the composer.lock file
It's down the minimum-stability:dev
It's down to Symfony 3's dependencies
It's down to using composer wrong (which, to be fair, is a generic rephrasing of points 1 and 2)
It's literally not an issue (sorry, that one just made me chuckle)
I don't really agree with point 1, because the suggestion is that composer.lock should only be committed for applications - which it turns out is correct - but the application the originally referenced plugin is designed for can replicate the same issue using composer "correctly".  Points 2 and 4 could fix the problem, but only until Symfony 3 is released, owing to the previous point of the composer.lock remaining in the application's repo.
So unfortunately, there doesn't seem to be a long term solution to this, short of accepting that once Symfony 3 is released you either a) remove coveralls as a dependency, or b) up your own library's minimum PHP requirement to 5.5.9 (assuming this is still Symfony 3's requirement come November). But as it turns out, Scrutinizer can be pushed to straight from Travis without the need for 3rd party composer dependency, which is solves my issue at least.
If anyone does come across a permanent solution, feel free to message me directly and I'll owe you a pint.

Aside from this thread turning a bit...(negative?)...I'd like to point out a few points (throw in my two cents):

I am literally ecstatic for the ability to use this library alongside the current 3.0 development branch. Removing such support is not a solution.
Despite @GrahamCampbell 's "tone" --- which everyone must honestly take at face value and understand, from Linus to the "nicest person in the world," everyone communicates differently --- this is absolutely due to an incorrect usage of Composer.
With regard to codeclimate/php-test-reporter, specifically, codeclimate/php-test-reporter#6, I'm glad you'er working on it in some capacity, b/c I have always been able to push to Scrutinizer every single time Travis runs, but that monstrosity has literally not worked for a year (whether it's the known, but somehow not fixed, SSL error, or some other crazy output).

@chrismou
Hi, @tmatsuo here. @satooshi kindly gave me a collaborator access to this repo and I'm going to clean up the old issues and PRs.
We'll likely pin symfony 2.0 by #76.
In my opinion, you can have a separate directory to install coveralls in order to isolate the dependencies from your app and php-coveralls.
What do you guys think?

Hey @tmatsuo, the project that was affected has now dropped PHP 5.4 support, so it's not so much of an issue for me anymore. Plus I've moved all my projects to Code Climate, so I don't really use this package anymore.
Thanks for getting back to me though! Appreciated :-)

We'll likely pin symfony 2.0 by #76.

There's still no need...

For anyone who stumbles across this thread, here's the breakdown:
It's down to the composer.lock file
...It's down the minimum-stability:dev

Just add:
    "config": {
        "platform": {
            "php": "5.4"
        }
    },

to composer.json, and all systems will generate a lock file that works on php 5.4...

That stops composer update working locally because I'm on 5.6.  Isn't that flag for projects built for a specific version of PHP?

That stops composer update working locally because I'm on 5.6. Isn't that flag for projects built for a specific version of PHP?

No.

I use it on all my big applications to ensure the lock file works on the production suite.

I think it's fixed by #76 and #114
Please feel free to re-open this if you think otherwise.

@GrahamCampbell Ah-ha, I guess I misunderstood the composer docs. And yeah, the error was from me setting it to 5.3 (which I guess evaluates to 5.3.0), not the option itself. Anyways, in this case, with no non-dev dependencies I ended up just killing the lockfile and all was good with the world.
Problem 1
    - phpunit/phpunit 4.8.9 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.8 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.7 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.19 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.18 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.17 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.16 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.15 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.14 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.13 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.12 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.11 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.10 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.7 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.7.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.9 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.8 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.7 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.10 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.6.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.5.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.5.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.4.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.3.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.2.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.1.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.9 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.8 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.7 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.6 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.5 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.4 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.3 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.20 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.2 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.19 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.18 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.17 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.16 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.15 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.14 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.13 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.12 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.11 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.10 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.1 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.0.0 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - phpunit/phpunit 4.8.19 requires php >=5.3.3 -> your PHP version (5.6.16) or "config.platform.php" value does not satisfy that requirement.
    - Installation request for phpunit/phpunit 4.* -> satisfiable by phpunit/phpunit[4.0.0, 4.0.1, 4.0.10, 4.0.11, 4.0.12, 4.0.13, 4.0.14, 4.0.15, 4.0.16, 4.0.17, 4.0.18, 4.0.19, 4.0.2, 4.0.20, 4.0.3, 4.0.4, 4.0.5, 4.0.6, 4.0.7, 4.0.8, 4.0.9, 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6, 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.6, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5, 4.5.0, 4.5.1, 4.6.0, 4.6.1, 4.6.10, 4.6.2, 4.6.3, 4.6.4, 4.6.5, 4.6.6, 4.6.7, 4.6.8, 4.6.9, 4.7.0, 4.7.1, 4.7.2, 4.7.3, 4.7.4, 4.7.5, 4.7.6, 4.7.7, 4.8.0, 4.8.1, 4.8.10, 4.8.11, 4.8.12, 4.8.13, 4.8.14, 4.8.15, 4.8.16, 4.8.17, 4.8.18, 4.8.19, 4.8.2, 4.8.3, 4.8.4, 4.8.5, 4.8.6, 4.8.7, 4.8.8, 4.8.9]


Added Stacktrace to podcasts

Your Project: Stacktrace
Project URL: _https://stacktracepodcast.fm/_
Category: Podcasts
Description: An awesome podcast about iOS development by Rambo and Sundell (already on the list as well)
:heart: Awesome iOS Contributors

@pavelshadrin Thanks for contributing!

Hi, may I ask what’s going on? I’m kind of scaredSent from my iPhoneOn Jul 24, 2023, at 10:31 AM, Vinicius Souza @.***> wrote:
@pavelshadrin Thanks for contributing!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

Hi, could you reply to inform me what’s happening here? I deleted GitHub because I couldn’t link a  node.js repository as the hackers would instantly comment and put codes in first. I reported them. They even posted the VM they built and put us and lord knows who else insideSent from my iPhoneOn Jul 24, 2023, at 10:31 AM, Vinicius Souza @.***> wrote:
@pavelshadrin Thanks for contributing!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

Why have you not told me what this is about?? Apple GitHub has been putting codes on me and won’t even tell me what they are doing so I don’t believe them to be helping my ransomware situation. I’m configured to a hackers Mac OS who’s robbing me blind and attacked me on lockdown. You deny my bounties but I got a private investigator and found their codes. I’ll submit later. But can you reverse whatever these people did without my permission This matter is going to court. I’ve lost my job and 5k. I’m coming at every company who failed me and GitHub won’t stop allowing attacks either. Sent from my iPhoneOn Jul 24, 2023, at 1:11 PM, Trisha Rohrer @.> wrote:Hi, may I ask what’s going on? I’m kind of scaredSent from my iPhoneOn Jul 24, 2023, at 10:31 AM, Vinicius Souza @.> wrote:
@pavelshadrin Thanks for contributing!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>


Better formatting for orgs:default message

For the record. It currently is:
$ heroku orgs:default personal
DEPRECATED: Use HEROKU_ORGANIZATION environment variable.

And this PR proposes:
$ heroku orgs:default
!    orgs:default is no longer in the CLI.
!    Use the HEROKU_ORGANIZATION environment variable instead.
!    See https://devcenter.heroku.com/articles/develop-orgs#default-org for more info.

@dickeyxxx Can we get rid of the reference of the Dev Center article for now? Looking at it I realized there are too many bits that are currently wrong and we should fix. I'm not sure
Unless @itchymutt or @jsimone think we could easily revisit the whole article and make it right.

@dickeyxxx Dev Center article is up to date now: https://devcenter.heroku.com/articles/1931#default-org.

great!


fix: cache problems for sale screen

This PR resolves []
Slack thread to get more context: https://artsy.slack.com/archives/C9SATFLUU/p1659353897000399?thread_ts=1659342586.520909&cid=C9SATFLUU
Description
If the lot has moved to the “bidding closed” state and the info about this lot is in the cache (for example, the user previously opened this sale screen), then this lot will not be displayed at the end of the list
I think it’s related to this problem with loadMore (when only data from the cache is used and the fresh data received by the request is ignored) and some problem with cursor paginations/cache.
For example, in the first attached video, you can observe that lot 7 and lot 8 are not displayed at the end of the list until we manually update the data (but even after manually updating the data, go back from the screen and navigate to the screen again, lot 7 and lot 8 will not be displayed)
https://user-images.githubusercontent.com/3513494/182160164-7d736eeb-6f1f-4790-a15c-309152816eae.mp4
In the second video you can observe that lot 10-lot 13 is not displayed
https://user-images.githubusercontent.com/3513494/182160287-cb9a769b-49f7-41e3-bf95-4bf3814d022e.mp4
Ways to solve the problem:

refactor the sales screen so that relay hooks are used instead of createFragmentContainer, createPaginationContainer, QueryRenderer
add some sale queries to the allowed list so that the cache is always ignored for these queries (for example, like here) 👈 Current PR

QA Test Case(s)

Test Case
Feature
Environment
Acceptance Criteria
Setup Instructions/Link

PR Checklist

[x] I tested my changes on iOS / Android.
[ ] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.
[ ] I added an app state migration.
[x] I hid my changes behind a feature flag.

To the reviewers 👀

[x] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

cache problems for sale screen - dimatretyak

Need help with something? Have a look at our docs, or get in touch with us.

what do you think about these changes? By default all changes will be hidden under the feature flag, but maybe this flag will be marked as ready for release for 8.0.3

do you think we should release these changes in 8.0.3 (the changes are hidden under the feature flag, we will carefully QA it and make changes available to everyone if we don't find anything serious) or is it better to postpone them for the next version?


fix compilation on 32 bit platforms

ref: https://ci.debian.net/data/autopkgtest/testing/i386/r/rust-num-bigint-dig/34894463/log.gz

thanks


Figure out a HTTP client

Blocker for InfluxDB
REST client is the problematic part here:

ktor-client is not yet ported to linux-arm: https://youtrack.jetbrains.com/issue/KTOR-872 ;

however there are unofficial builds for arm: https://github.com/Kotlin/kotlinx.coroutines/issues/855#issuecomment-1242878799 - this could be the easiest way
Example build.gradle file: https://github.com/Kotlin/kotlinx.coroutines/issues/855#issuecomment-1022070660
Documentation: https://ktor.io/docs/create-client.html#configure-client

okio doesn't support sockets in kotlin-native yet; therefore okhttp can't work in kotlin native
https://github.com/e5l/http-client-common is deprecated in favor of ktor
http4k doesn't support kotlin-native: https://github.com/http4k/http4k/issues/186
Maybe via this? https://kotlinlang.org/docs/native-app-with-c-and-libcurl.html - also a possibility
Even easier would probably be to just run curl with proper params. - also a possibility

I have a ktor demo working at https://github.com/danbrough/kotlinxtras/tree/main/demos/repos/ktor.
It has a simple demo for ktor client (curl) and a server demo too.
It supports linuxArm32Hfp, linuxArm64, linuxX64  but not android native targets yet.
It relies on modified kotlinx coroutines, serialization, atomicfu,okio   but those are mostly trivial modifications
and they are all in the sub modules at https://github.com/danbrough/kotlinxtras/tree/main/repos.


grammar corrections

This corrects some mistakes in the grammar:

Even though § 4.14, 4.15 do not mention it, the examples make it clear that a meta-identifier can contain spaces.
Allow for a syntactic-primary to be an empty-sequence, as stated in § 4.10 (g). This now correctly allows the syntax used in an example in § 5.8 : {"A"}-
Although § 7.5 states "in the ISO/IEC 646:1991 character set", it makes more sense to allow full Unicode in a Rust environment. Thus the definition for other-character was changed to allow any Unicode character that is not an other terminal-character. (See also added comments in the grammar)

Its been a while since I reviewed the standard. But I trust you on this! LGTM. Thanks for the contribution. Support arbitrary characters is interesting.


[Publication][Versioning]: New version of chat can not be published if it contains file which was already published

EPAM AI DIAL chat version
0.18.0
How to reproduce
Steps:

create chat01 with file01
create publication request for chat01 with file01
by admin approve request
by user create publication request for chat01 with new version , with contains file01
submit request

Actual result
Error message displayed

request was not created
Expected result
Need to allow create publication request for new version of chat with attached file which was already published
Confidential information

[X] I confirm that do not share any confidential information

related issue #2632

verified on staging


OneFuzz Instance Custom Configuration

The CoSTR team is working with the OneFuzz team to build out the infrastructure to support 'custom configurations' for OneFuzz instances. This particular feature request includes only an MVP concept for custom configurations, but ideally this work could be expanded upon to support all kinds of instance-specific custom configs in the future.
This feature request came about after the CoSTR team ran a proof of concept to include new, Microsoft-internal extensions for VMSS. Currently, one of the first configurable settings that will be supported in this custom config is custom extensions.
(Created for tracking)

@nharper285, is this completed?


Redirects overview paging issue

Steps:

go to page X on redirects overview
perform a search which has less than X amount of pages
overview renders blank + paging control (if there are more than 1 pages atleast)

Solution:
seems current page has to reset to 1 on a new search

Fixed by PR


Is there maximum stakeholder limit for free license?

We understood the limitation of stakeholder license.Each DevOps organization has 5 Free basic license. We would like to add about 800-1200 free stakeholders.   I would like to know is there maximum free stakeholder count.

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

ID: 17e7fef2-40df-4923-e62e-74ac556cbc6a
Version Independent ID: af9269b4-1db4-df1f-2520-78ad20baf17b
Content: Get started with Stakeholder access - Azure DevOps
Content Source: docs/organizations/security/get-started-stakeholder.md
Product: devops
Technology: devops-new-user
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

This article states:

Stakeholder: Provides partial access, can be assigned to unlimited users for free. Assign to users with no license or subscriptions who need access to a limited set of features.

Thank you!


Display icons of the entries

Please show in the result window in front of each entry the icon that is stored in KeePass.

I can try to do this. The API doesn't seem to make it very easy to get the icon for an entry though 😞

Perfect, thank you!


Bugs in Reock function in scores.py

I've found 2 issues with the Reock function in scores.py:
(1) Importing the Graph function from networkx overrides the gerrychain Graph function and causes some of its features not to work.
(2) Computing boundary nodes as only cut edges neglects any boundary nodes for a district that are part of the boundary of the state.  I discovered this when computing the score for a district that contains a long peninsula, and the score came back greater than 1 because the purported boundary circle didn't contain most of the peninsula.

I just pushed a fix that I think addresses your second reported issue (#14).
If I'm understanding your report, I think the first issue that you have may be something inherent to Python namespaces (name conflicts in imports will result in overwriting).   I’m importing Graph from gerrychain, and then when I run the scores.py code, the networkx version overrides it.  I actually tried doing it in the other order, but then I got an error in the reock code.
On Dec 14, 2021, at 11:57 PM, Max Fan<EMAIL_ADDRESS>wrote:
I just pushed a fix that I think addresses your second reported issue (#14https://github.com/mggg/plan-evaluation-processing/pull/14).
If I'm understanding your report, I think the first issue that you have may be something inherent to Python namespaces (name conflicts in imports will result in overwriting).
Reply to this email directly, view it on GitHubhttps://github.com/mggg/plan-evaluation-processing/issues/13#issuecomment-994390932, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASHKDDARXIAKXIFEMXU442TURA347ANCNFSM5KCC7TYA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Experimentally, changing my local version of the reock code to import Graph from gerrychain rather than networkx seemed to fix the issue for me, but it sound like this may not be what you want for your use case.
-Jeanne
On Dec 15, 2021, at 6:49 AM, Jeanne Nielsen Clelland<EMAIL_ADDRESS>wrote:
Yes, that’s exactly it.  I’m importing Graph from gerrychain, and then when I run the scores.py code, the networkx version overrides it.  I actually tried doing it in the other order, but then I got an error in the reock code.
On Dec 14, 2021, at 11:57 PM, Max Fan<EMAIL_ADDRESS>wrote:
I just pushed a fix that I think addresses your second reported issue (#14https://github.com/mggg/plan-evaluation-processing/pull/14).
If I'm understanding your report, I think the first issue that you have may be something inherent to Python namespaces (name conflicts in imports will result in overwriting).
Reply to this email directly, view it on GitHubhttps://github.com/mggg/plan-evaluation-processing/issues/13#issuecomment-994390932, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASHKDDARXIAKXIFEMXU442TURA347ANCNFSM5KCC7TYA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Ah, I understand the issue now. I think then https://github.com/mggg/plan-evaluation-processing/blob/ef45897b6028c4040349064999a96d9509b73337/evaltools/geography/scores.py#L6
was meant to be
from typing import TYPE_CHECKING
if TYPE_CHECKING:
    from networkx import Graph

since networkx is only imported for the type-checking to work out nicely. Either way,
from gerrychain import Graph

should be more appropriate.


Implicit cast PointIdentifier to MultiThreaderBase::SizeValueType

Don't cast to PointIdentifier. This causes a warning on MSVC 2015.

PR Checklist

[ ] No API changes were made (or the changes have been approved)
[ ] No major design changes were made (or the changes have been approved)
[ ] Added test (or behavior not changed)
[ ] Updated API documentation (or API not changed)
[ ] Added license to new files (if any)
[ ] Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
[ ] Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

Why close PR immediately?


Fix BPF programs build with clang 14

Fixes #164

We pushed this through another PR thanks @sh7dm for kickign this off. Should be good to go now with clang14.


Split five columns

We need to show the budget fixed to the left. Since the budget is comprised of four columns (unit, quantity, unit cost, and total cost) we need to fix five columns to the left.
I also removed the selection which was added in https://github.com/BuildingConnected/exceljs/commit/eea2df7dbf8744de462c1f828a657a2ce591ffd5 but seemingly just selects a cell for no reason. @cannoneyed hoping you can confirm that it's safe to remove that line.
Test Plan:
Setting up exceljs as an NPM local module (DO THIS FIRST)

Clone exceljs as a sibling to your BC repo
Check out this five-fixed-columns branch of the exceljs repo
Edit your BC repo's package.json, changing the version string of "@buildingconnected/bid-form/util" from "git://github.com/BuildingConnected/exceljs.git" to "file:../exceljs"
From within your client repo run rm -rf node_modules/\exceljs && npm i exceljs --no-shrinkwrap
Restart your npm start BC process

Actually test it works

Go to a bid package's budget and proposal tab (checkout budget-1 in the client repo)
Click "download excel"
Ensure the excel has five columns fixed to the left (I'll merge this after I have the target bid actually rendering in the 2-5 columns)

Tear down

Revert the change you made to package.json
Run rm -rf node_modules/\exceljs && npm i exceljs again

@alurim Looks solid 🎺  - Are there backend changes that need to be merged in before/after this?

@cannoneyed these two PRs add a Budget and percentage difference columns to the excel spreadsheet.
https://github.com/BuildingConnected/BC/pull/1998
https://github.com/BuildingConnected/BC/pull/2000
Step 1 in Actually test it works involves checking out the branch in the first PR above. Swing by if you want to see it live instead of actually going through the test plans.

marking don't merge until at least the first of the above PRs lands.

This work should be subsumed by the ability to configure the split that I add here.


[BUG] pf: error: unrecognized arguments: --user-agent prompt-flow-extension/1.6.0

Describe the bug
C:\Users\paulsh\Documents\promptflow-samples-ozguler\sample_gallery\evaluate_semantic_kernel_planner\python_evalution\promptflow_evaluation>C:\Users\paulsh\AppData\Local\miniconda3\envs\promptflow-samples-ozguler\python.exe -m promptflow._cli._pf.entry flow test --flow c:\Users\paulsh\Documents\promptflow-samples-ozguler\sample_gallery\evaluate_semantic_kernel_planner\python_evalution\promptflow_evaluation --user-agent "prompt-flow-extension/1.6.0 (win32; x64) VSCode/1.84.2"
usage: pf [-h] [-v] {flow,connection,run,config,tool} ...
pf: error: unrecognized arguments: --user-agent prompt-flow-extension/1.6.0 (win32; x64) VSCode/1.84.2
How To Reproduce the bug
Steps to reproduce the behavior, how frequent can you experience the bug:

Using the latest PF CLI and VS Code extension, run a flow.

Could you please share your prompt flow sdk cli version?
pf -v

Hi @paulshealy1 , the issue is caused because unmatched version between VS Code extension and SDK/CLI. Could you upgrade promptflow SDK under environment "promptflow-samples-ozguler" to >= 1.1.0?
pip install promptflow>=1.1.0

Installing the latest promptflow 1.1.1 worked for me.
Just mentioning for others, another workaround would be to manually run pf flow test --flow flow_file (without the offending --user-agent argument)

(promptflow-samples-ozguler) C:\Users\paulsh\Documents\promptflow-samples-ozguler\sample_gallery\evaluate_semantic_kernel_planner\python_evalution\promptflow_evaluation>pf -v
promptflow                       1.1.1

Executable 'C:\Users\paulsh\AppData\Local\anaconda3\python.exe'
Python (Windows) 3.11.4 | packaged by Anaconda, Inc. | (main, Jul  5 2023, 13:38:37) [MSC v.1916 64 bit (AMD64)]

@ttthree, @D-W-, @spygi, I think there is an issue activating the right environment when running from the extension. I'm happy to hop on a call with one of you to debug.

Offline syncing, the issue seems because mixed usage with miniconda and anaconda.

Hi @paulshealy1 , I'm closing this since it's a local environment issue. Feel free to reopen if there's still issue.


WIP: chore: remove eol python 3.7

Description

Types of Changes

[ ] Core
[ ] Bugfix
[ ] New feature
[ ] Enhancement/optimization
[ ] Documentation

Issues Fixed or Closed by This PR

Checklist

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Hi, thanks for contributing to Strawberry 🍓!
We noticed that this PR is missing a RELEASE.md file. We use that to automatically do releases here on GitHub and, most importantly, to PyPI!
So as soon as this PR is merged, a release will be made 🚀.
Here's an example of RELEASE.md:
Release type: patch

Description of the changes, ideally with some examples, if adding a new feature.

Release type can be one of patch, minor or major. We use semver, so make sure to pick the appropriate type. If in doubt feel free to ask :)
Here's the tweet text:
🆕 Release (next) is out! Thanks to Alexander for the PR 👏

Get it here 👉 https://github.com/strawberry-graphql/strawberry/releases/tag/(next)

this PR also updates the dependencies (required because of python update)

If 3.7 is dropped, then the special handling of asyncio.CancelledError can be removed, since it becomes a direct child of  BaseException with 3.8

as far as I can see, asyncio.CancelledError are not special handled (only for cleanup they are suppressed but for a good reason)

as far as I can see, asyncio.CancelledError are not special handled (only for cleanup they are suppressed but for a good reason)

Code like this:
        try:
            ...
        except asyncio.CancelledError:
            raise
        except Exception as error:
            await self.handle_task_exception(error)  # pragma: no cover

is written for 3.7 compatibility, where asyncio.CancelledError is a subclass of Exeption yet should not be handled but re-raised.
In 3.8 it is a direct BaseException and the above clause can be omitted (because there is no except BaseException anywhere in sight)

as said:
asyncio.CancelledError is propagated
the other errors are handled in:
handle_task_exception
It is quite a change of the logic if you handle now asyncio.CancelledError in handle_task_exception

is something like
--- a/strawberry/subscriptions/protocols/graphql_transport_ws/handlers.py
+++ b/strawberry/subscriptions/protocols/graphql_transport_ws/handlers.py
@@ -108,8 +108,6 @@ class BaseGraphQLTransportWSHandler(ABC):
             self.connection_timed_out = True
             reason = "Connection initialisation timeout"
             await self.close(code=4408, reason=reason)
-        except asyncio.CancelledError:
-            raise
         except Exception as error:
             await self.handle_task_exception(error)  # pragma: no cover
         finally:
@@ -118,7 +116,10 @@ class BaseGraphQLTransportWSHandler(ABC):
             self.completed_tasks.append(task)

     async def handle_task_exception(self, error: Exception) -> None:
-        self.task_logger.exception("Exception in worker task", exc_info=error)
+        if isinstance(error, asyncio.CancelledError):
+            self.task_logger.exception("Worker task cancelled", exc_info=error)
+        else
+            self.task_logger.exception("Exception in worker task", exc_info=error)

     async def handle_message(self, message: dict) -> None:
         handler: Callable

right?
Handling CancelledErrors  in handle_task_exception is quite a change

Just the first part. In 3.8 CancelledError won't be caught by "except Exception" because it isn't an "Exception"

I think I may have confused you with my talk about "CancelledError".  Basically, we never want to catch it.
Previously, for 3.7, to ensure that we didn't, we had to add in except asyncio.CancelledError: raise clauses, in order to avoid catching it.   for 3.8 and above, this is no longer necessary, as long as you are not catching BaseException (which you should almost never do).
So, the only thing required, is to simply drop the except asyncio.CancelledError: raise clauses

I think I may have confused you with my talk about "CancelledError". Basically, we never want to catch it. Previously, for 3.7, to ensure that we didn't, we had to add in except asyncio.CancelledError: raise clauses, in order to avoid catching it. for 3.8 and above, this is no longer necessary, as long as you are not catching BaseException (which you should almost never do).
So, the only thing required, is to simply drop the except asyncio.CancelledError: raise clauses

n some new python versions asyncio.CancelledError inherits from Exception, so we need it

cleaned up and rebased.
Also add the updated dependencies in the release.md

in some new python versions asyncio.CancelledError inherits from Exception, so we need it

This is incorrect.  as the documentation clearly states:  "Changed in version 3.8: CancelledError is now a subclass of BaseException."

technically this stanca would be also right, if they inherit from Exception, so it is implementation specific

technically this stanca would be also right, if they inherit from Exception, so it is implementation specific

No it isn't.  Yes, you could deliberately mis-interpret it, but it indicates a change from the 3.7 behaviour.  It is not implementation specific.  I don't quite understand why you are being so stubborn about this, it is a well known fact of Python asyncio programming.   If you like, I can have it fixed in the documentation.

Thing is: vscode says something different. Maybe the stubs are wrong.
If you say it works, then I give it a try.
I just don't want to break anything as I have not so much time with two children

this too?
        except asyncio.CancelledError:
            # CancelledErrors are expected during task cleanup.
            pass
```

It is fine, I can clean this all up later, I just wanted to mention this in the PR since this was about deprecating 3.7 and I have been wanting to get this out of the way for a long time.
Fwiw, I made a change to the docs, and here you have it from the horse's mouth:
https://github.com/python/cpython/pull/106453#pullrequestreview-1514751783

Also uvicorn can be updated with editing this PR

@devkral can you rebase this? 😊

done

I hope it is ok to add an editorconfig as my defaults always wreck the yaml formatting.

there were some new refs to python 3.7 which had to be removed (tests/pyright).
Hope we can end the never ending PR soon ;)


commands: remove diy, add lc alias for livecheck

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally? (Ran brew tests --online, all checks passed.)

This PR makes two minor changes:

It removes the default alias for brew diy (configure) which no longer exists.
It adds lc as a default alias for livecheck, similar to tc for typecheck. The reason I'm proposing this (rather than using brew alias just for myself) is because there are 7 l* commands and 4 li* commands, so at least 4 characters (i.e. liv<TAB>) are required to autocomplete to livecheck. I think users of livecheck would like having a short alias like lc, which is convenient and unambiguous (to my knowledge).

Review period will end on 2021-07-15 at 16:38:44 UTC.

Review period ended.


HDDS-7076. Log container file path when container cannot be written.

What changes were proposed in this pull request?
Add container file path to error message when writing to container encounters an error
What is the link to the Apache JIRA
HDDS-7076
How was this patch tested?
Reproduce the error on a local cluster via taking away the write permission on container data by making its folder read only.

Thanks @Galsza for updating the patch.  Thanks @duongnguyen0 for the review.


Gandlf ov integration

Fixes #ISSUE_NUMBER
Proposed Changes

Checklist

[ ] I have read the CONTRIBUTING guide
[ ] My PR is based from the current GaNDLF master
[ ] Non-breaking change (would not break existing functionality): please provide as many details as possible for any breaking change
[ ] Function/class source code documentation added/updated
[ ] Code has been blacked for style consistency
[ ] If applicable, version information has been updated in GANDLF/version.py
[ ] If adding a git submodule, add to list of exceptions for black styling in pyproject.toml file
[ ] Usage documentation has been updated, if appropriate
[ ] History has been updated, if appropriate
[ ] Tests added or modified to cover the changes; if coverage is reduced, please give explanation

I’m having this error from the test:
ModuleNotFoundError: No module named 'opm'
Do you see this before?

@sarthakpati Testing is getting the error FileNotFoundError: File not found: "/home/runner/work/GaNDLF/GaNDLF/testing/data_output/histo_patches/histo_patches_output/1/image/image_patch_2624-2304.png" for the test case testing/test_full.py::test_train_segmentation_rad_2d. Any insights on how should this be fixed?

Hey @junwenwu, I fixed it in: https://github.com/junwenwu/GaNDLF/pull/6

Should be good to merge after https://github.com/junwenwu/GaNDLF/pull/8


Is SomeOf() and Sometimes() from the IAA namespace available like OneOf()

Thanks,

No, they are not available, we mainly focus on Compose functionality.

Is there an equivalent way to achieve Sometimes? @albu


compile failed without root access

Hi, how can I install mxnet on a server as a user. I got following error after make.
mkdir: cannot create directory `/build': Permission denied
make: *** [/build/tmp/gpu_global_mem_gpu.o] Error 1

did you set EXTRA_OPERATORS?

what is EXTRA_OPERATORS? The error is caused when it try to create a directory without root access.

I have never seen this situation if follow the guide https://mxnet.readthedocs.org/en/latest/build.html
The makefile do create a build folder, but is in current path.

You are right, the build is created in the current path. But since I can not run
sudo apt-get update
sudo apt-get install -y build-essential git libatlas-base-dev libopencv-dev
this might be why I have this weird issue.

@antinucleon I it's probably due the EXTRA_OPERATORS feature I added a week ago. https://github.com/dmlc/mxnet/blob/master/Makefile#L101 It looks like his EXTRA_OPERATORS is NONE but some how passed the if

should be fixed once https://github.com/dmlc/mxnet/pull/1048 is merged. For now, you can fix it by adding EXTRA_OPERATORS = NONE to the end of your config.mk

Thanks, that fix the problem


fix(ChatKnowledge): summary support zhipu message_converter

Description

summary module set DefaultLLMClient auto_convert_message=True
change the role that zhipu support

How Has This Been Tested?

set LLM_MODEL=zhipu_proxyllm in your .env file
upload file to document summary

Snapshots:
Include snapshots for easier review.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have already rebased the commits and make the commit message conform to the project standard.
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] Any dependent changes have been merged and published in downstream modules

r+


Add zsh completion for 'docker inspect --type=plugin' and other missing ones

ref. #28967
Signed-off-by: Steve Durrheimer<EMAIL_ADDRESS>

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "zsh-completion-inspect-types" git@github.com:sdurrheimer/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353942632
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

@vdemeester Done


[merger] Cursive attachment merging fails when all anchors are NULL

Carried over from https://github.com/googlefonts/fontmake/issues/1022.
When all anchors in all masters are of the form:
    pos cursive _0 <anchor NULL> <anchor 25 0>;

the merger creates an ExitEntryAnchor like this:
        rec = ot.EntryExitRecord()
        rec.EntryAnchor = ot.Anchor()
        rec.EntryAnchor.Format = 1
        rec.ExitAnchor = ot.Anchor()
        rec.ExitAnchor.Format = 1
        self.EntryExitRecord.append(rec)

This means that deep inside mergeThings, when trying to merge the entry anchors, we hit this code path:
            if allNone(lst):
                if out is not None:
                    raise FoundANone(self, got=lst)

All entry anchors are None, but the target entry anchor is an Anchor so merging fails.

Confirmed, it works at 56731a9f1 but not at b14a29c35.
Bad Behdad. ;-)

how does one reproduces exactly? could you push a failing test case in varLib/merger_test.py so Behdad can fix it

Will do. I could probably fix it myself, TBH; it just needs a custom merger for EntryAnchor/ExitAnchors.


use this library in android module

When the library is used in a library, when there is a custom layout in an Activity layout xml file in the library, a crash occurs: java.lang.NullPointerException: Attempt to invoke virtual method'java.lang.Object java.lang.reflect .Field.get(java.lang.Object)' on a null object reference

https://github.com/chrisjenx/Calligraphy/issues/475#issue-480666801


Client Encryption : Adds support to Migrate Data Encryption Key via Rewrap from Legacy Algorithm to MDE Algorithm

Description
This PR  brings in the following changes/Features.

Migrating Legacy Keys which are wrapped using Legacy Algorithm/Lib and configured to Encrypt data using legacy algorithm to MDE based algorithm/Lib by rewrapping and updating the Data Encryption Key properties.

If EncryptionOption is configured with an Invalid path we now ignore this path and continue rather than throw an Exception.

Serialization change from SqlNvarcharSerializer ( UTF-16 encoding ) to SqlVarcharSerializer ( with UTF-8 encoding ).

Type of change

[] Bug fix (non-breaking change which fixes an issue)
[] New feature (non-breaking change which adds functionality)

If EncryptionOption is configured with an Invalid path we now ignore this path and continue rather than throw an Exception

Is it to support optional payloasd?

If EncryptionOption is configured with an Invalid path we now ignore this path and continue rather than throw an Exception

Is it to support optional payloasd?

Hi Kiran, this was an ask from MS Teams, where in they say it sometimes (more so often) that some documents may not have the intended fields since they have a filter based on the document w.r.t to  'paths to encrypt' rather than a static set of paths to encrypt and throwing an exception was not very optimal and friendly.


[Question] Routing and Communications.

Hello there.
I am a newbie of Kotlin and Ktor.
I developed a webserver for connecting with a persistence layer that provides via JDBC.
And that server is working fine.
However its routing definition convention seems not good at legibility.
I just wonder What is the best practice to make routing.
For instance, My routing sample code is as follows
routing {
    route("/a") {
        route("/b") {
            post("c") {
                // many logics
            }

            // many route codes
        }

        // many route codes
    }

    route("/d") {
        route("e") {
            post("f") {
                // many logics
            }

            // many route codes
        }

        // many route codes
    }
}

When my routing codes are growing up,
This code will occurs many confusing.
I want to make each function corresponding to each route.
This is node express routing code.
var express = require('express');

var index = require('./routes/index');
var route = require('./routes/a/index');
var routeAB = require('./routes/a/b');
var routeD = require('./routes/d');

var app = express();

...

app.use('/', index);
app.use('/a/', route);
app.use('/a/b/', routeAB);
app.use('/d/', routeD);

This code helps to separate all controller codes to each of directory and files.
Does Ktor support these features?

And this is another question.
A documentation of Ktor seems insufficient.
So, I think i will have many questions about Ktor.
Then, Where i can ask that question? (GitHub Issue?, Stackoverflow? or JetBrains community?)
Thank you.

You can extract a function from your routing, it's just normal code, you can put it whenever you like. See samples for YouKube and Kweet for some ideas.
For questions, it's better to ask in kotl.in/slack on #ktor channel.


Add network status alert notification bar

the linter is failing for electron code i have already added a fix for that in #178

the linter is failing for electron code i have already added a fix for that in #178

@ashu8912 , I have merged the #178 and re-run the CI jobs here but it's still failing.
I have also noticed that the red bar is still showing on the main area instead of on the entire page. This is fine as my request for it to be in the entire page had to do with it being easier to re-use in the login screen.
However, in the login screen I don't see the bar.
@illume , if you can, please review this PR's code as I cannot do it ATM.

@ashu8912 , I have merged the #178 and re-run the CI jobs here but it's still failing.
I have also noticed that the red bar is still showing on the main area instead of on the entire page. This is fine as my request for it to be in the entire page had to do with it being easier to re-use in the login screen.
However, in the login screen I don't see the bar.
@illume , if you can, please review this PR's code as I cannot do it ATM.

Another thing is that if the network is off, we see the bar, and when it comes back online, the bar disappears but the views showing "Error" remain as such.
I am starting to think we need something more than just the bar, like a central setting showing the status, and requests taking that into account when performing their tasks.

Another thing is that if the network is off, we see the bar, and when it comes back online, the bar disappears but the views showing "Error" remain as such.
I am starting to think we need something more than just the bar, like a central setting showing the status, and requests taking that into account when performing their tasks.


New asset: Group

Contains

New asset: Group
Updates the build with gestalt version 5.1.4 (required by asset structure)

Objective

The new Group asset allows group configurations to be loaded from JSON files (assets/groups/.group).
Gestalt 5.1.4 contains a fix to a bug that would sometimes prevent an asset file to be loaded. This error appears as an java.security.AccessControlException exception ("access denied"), with the stack trace leading to org.terasology.assets.format.AssetDataFile.openStream(AssetDataFile.java:99) .

Changes

New asset structure: Group, GroupBuilder, GroupData, GroupFactory, and GroupFormat. The new implementation is hermetic and shouldn't affect any of the existing classes.
Updates both gestalt-module and gestalt-asset-core  to version 5.1.4 in build.gradle

Usage

Make sure to thoroughly rebuild the project to avoid broken references using gradlew clean cleanIdea idea jar (so that the new gestalt version can be properly used)
The new asset structure is demonstrated in the WildAnimalsMadness module

Can one of the admins please verify this patch?

@GooeyHub: add to whitelist

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Removed leftovers from the previous gestalt debugging (including generic exceptions, replaced with more appropriate ones) and included javadoc for classes/fields. Also rebased to remove merge commits.

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!

Briefly validated that the game still works after the merge, looking forward to trying it out in WildAnimalsMadness soon 👍


Support for Tree Tiger Hash and Merkle Hash Tree

https://github.com/multiformats/multihash/issues/55
Merkle Hash Tree multihash
<merkle-hash-tree-mc>-<len>-(<hash-tree-type>-(<multihash>[<multihash>...]))
<0x0400>-<len>-(<0x01>-(<multihash>[<multihash>...]))
0x0400 - Merkle Hash Tree (1024 decimal) multicodec value
0x01 - Hash Tree Type with this settings:

Data segment size - 1024 bytes
Data prefix - one byte with value 0 (0x00)
Hash pair prefix - one byte with value 1 (0x01)
Unpaired hashes move on next level unchanged.
Multihashes in tree multihash packed in breadth-first order from root to leafs.

Tiger multihash:
<tiger-mc>-<len>-<hash>
<0x7A>-<0x18>-<0x3293ac630c13f0245f92bbb1766e16167a4e58492dde73f3>
0x7A - Tiger-hash multicodec value
Tree Tiger multihash:
<merkle-hash-tree-mc>-<len>-(<hash-tree-type>-(<tiger-root-multihash>[<tiger-multihash>...]))
Tree sha2-256 multihash:
<merkle-hash-tree-mc>-<len>-(<hash-tree-type>-(<sha2-256-root-multihash>[<sha2-256-multihash>...]))
Links:
Tree Hash EXchange format (THEX)
Tiger:
A Fast New Cryptographic Hash Function (Designed in 1995)
wikipedia: Tiger (cryptography)
wikipedia: Merkle tree#Tiger tree hash
License: MIT
Signed-off-by: Ivan<EMAIL_ADDRESS>

I write package that calc hash tree root: https://github.com/ivan386/go-hash-tree


[v9rc3] Usability Improvement: remove annoying extra click in Dashboard

If a package has Dashboard pages with a number of sub-pages, clicking on any of them changes the right panel and only shows sub-pages, so to go back to the main package page you have to do 2 more click: Dashboard then to scroll all the way down then click on the page. You can't simply click and go to the main page.

But that's really about any Dashboard link. In v8 all it took is just a click and you still had the same menu on the right. Now you have to click twice every time for every main menu item plus to scroll all the way down after coming back. Very very very annoying.

+1. I can see why this has been done, the v8 all-in-1 dashboard panel could get so long as to be equally annoying.
Perhaps there is a middle ground, showing a partial tree or breadcrumb together with the current subsection, or fully expanding the tree if there are only a few grandchildren, so we can avoid some of the second click changes the current v9 dashboard pane imposes.

At the very least the main (top) page must be made as a link to be able to go to that page from the shortened panel list without exiting and scrolling down

In your example, @linuxoid – are you saying that "Forum" should actually link to the forum page? That's interesting – most of the core examples never do this, because whenever you click on the top level page you're actually just redirecting into the first child – so having Forum be linkable would be redundant. But if Forum actually takes you in your example to its own page that's separate from the other child pages and doesn't redirect away, I could see why that would be annoying.

My package installs a Forum Dashboard page and its children: Categories, Topics, Users and Settings. Yje Forum page lists all forum posts and their controls. So that Forum page must be accessible from that panel as a link, not just plain text.

I have a similar situation where my dashboard page actually has no child pages.

This will be resolved by https://github.com/concrete5/concrete5/pull/9825 when it's merged in.


Splitting V1 and V2 into their own routes and page

Hi guys. Thanks for creating a great gem.
Recently I had to create a define_group in my config because I now have a v2 api. I wish to create a page for devs to view v1 and v2. I did the following set up but ended up with an error.
By looking at the source code it appears there's no resource.
class Apitome::DocsController
  def resources
    @resources ||= JSON.parse(file_for("index.json"))["resources"]
  end

Any ideas or help would be greatly appreciated? Cheers.
Error
undefined method `gsub' for nil:NilClass

<%= render 'example', locals: { example: example, link: example['link'].gsub('.json', '') } %>
apitome (0.1.0) app/views/apitome/docs/show.html.erb:2:in

Code Setup
RspecApiDocumentation.configure do |config|
  API_VERSIONS = [:v1, :v2]
  API_LAST_VERSION = API_VERSIONS.last

  config.format = [:json, :open_api]
  config.curl_host = "http://__.staging.__.com"
  config.api_name = "___ API"
  config.curl_headers_to_filter = ["Cookie", "Host"]
  config.request_headers_to_include = ["Accept"]
  config.response_headers_to_include = ["Content-Type", "Cache-Control", "Content-Length"]

  API_VERSIONS.each do |version|
    config.define_group(version) do |config|
      config.api_name = "#{version.to_s} storefront api"
      config.docs_dir = Rails.root.join('doc', 'api', version.to_s)
    end
  end
end

routes.rb

  [:v1, :v2].each do |version|
    mount Apitome::Engine => "/api/docs/#{ version }/index",
      as: "apitome-#{ version }",
      constraints: ApitomeVersion.new(version)
  end

class ApitomeVersion
  def initialize(version)
    @path = "doc/api/#{ version }/index"
  end

  def matches?(request)
    # Load doc files from the right version folder
    Apitome.configuration.doc_path = @path
    # Mount all routes on the current request path (including simulated responses)
    Apitome.configuration.mount_at = request.path
    # Return a match
    true
  end
end

@joeyk16 This seems like its more appropriately asked in the epitome repo here: https://github.com/jejacks0n/apitome


Replacement of the logo

Replaced logos with simple, flat icons.

Thanks for the PR. Unfortunately I would ask some revisions as the new icon uses the Bitcoin logo and I would like to avoid the association with any specific coins. I updated the issue #1 to reflect this, sorry I haven't added that earlier!

Would something like this work instead?

Pickaxe icon by Guvnor Co from the Noun Project

Additionally, I can make a more detailed version for promotion if required.

I like the idea! I would maybe suggest a less detailed pickaxe to make the icon recognizable in a lower resolution. What do you think?

I'll get on that!

How about this one.
when NoCoin is inactive

when NoCoin is active

Hi Suhail - I think this icon is too complicated. It needs to be recognisable at much smaller sizes (32x32px).
What do the hexagons represent? Why is the shield a castle?
Probably just the center section, tidied, would be a better choice for an app icon.

Thanks for the input OZARIN.
The hexagon represent different crypto currencies. Thought of adding individual logos of crypto currency, then again it would make the logo complicated.
The castle shield represent a user's computer( castle in the virtual world ).

Thanks for the PR @OZARIN, I'll merge it now and adapt the logo to the different states as described in #3 sometime later today or tomorrow.
@suhail-sullad as @OZARIN mentioned, the logo is too detailed and wouldn't look good at smaller resolutions (in fact I did the same comment for @OZARIN a little higher). I think for now I will go with the pickaxe coin idea as I like the idea and will accept improvement along those lines.


for updating the navbar brand.

Is your feature request related to a problem? Please describe.
No its not a problem. I tried to enhancing the look of sidenav.
Describe the solution you'd like
I have updated sidenav.html and added sidenav.css for changing current sidenav project into animated sidenav
Additional context
Add any other context about the feature request here.

@mdatif796 Please refer any design or something?
How will it look after modifications

@mdatif796 You can raise the PR or show the design here itself

@mdatif796 Whats the update,
Reply within 2 days on we have to close this issue.

I'm working on it.
On Thu, 15 Apr, 2021, 4:19 am Harsh Gupta, @.***> wrote:

@mdatif796 https://github.com/mdatif796 Whats the update,
Reply within 2 days on we have to close this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Vishal-raj-1/Awesome-JavaScript-Projects/issues/636#issuecomment-819898676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASJBEEJNNRHQYW4S44RMOMDTIYLXRANCNFSM4ZWWJ5KQ
.

@mdatif796 It's been a month that you haven't sent the PR, you have to send the PR within a week.

I will send it soon.
On Mon, 26 Apr, 2021, 12:23 am Harsh Gupta, @.***>
wrote:

@mdatif796 https://github.com/mdatif796 It's been a month that you
haven't sent the PR, you have to send the PR within a week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Vishal-raj-1/Awesome-JavaScript-Projects/issues/636#issuecomment-826371965,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASJBEEKOAIM4SSHJM572LCDTKRQLLANCNFSM4ZWWJ5KQ
.

@mdatif796 What's the update? Since it will been 2 months for this issue, we can't give you more time on this, Kindly send PR within a week or I have to close the issue.

@mdatif796 Any update?

@mdatif796 no problem, you can just give updates about the project, so that we can keep a record of your issue.

@mdatif796 Its been a long time you didn't sent the PR till now, Kindly respond within a week.


The interactive version of Graffiti Grapher, now with deletion!

Now we can:

Create a form with as many corners as you want (if you want more than three)
Delete any selected shape (this is the cool one)
Drag and drop any shape
Add as many shapes as you want (theoretically, there's probably performance issues if you add 8 bajillion shapes)

Someone needs to lint.

Looks good, don't worry about skateboarder.


influxdb with authentication

Your projects looks really nice. Is there a way to use it if my influxdb is configured to use credentials?
I tried to add my credentials to the url but it looks like they get cut.
https://docs.influxdata.com/influxdb/v1.7/administration/authentication_and_authorization/

Excellent question.  Right now, the app only supports instances without authentication ... although looking at the docs, it might be easy to add.


feat(demandeId): Change toaster text on save

https://jira-mcas.atlassian.net/jira/software/c/projects/VAO/boards/336?selectedIssue=VAO-431

:tada: This PR is included in version 1.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


BPF tests should be easier to run and be able to run without root

BPF tests currently require root access to run and break out of the bazel sandbox.
We can try using something like qemu to provide an isolated environment that can be run with bazel support.

bazel test --config=qemu-bpf will now run BPF tests inside of qemu. This configuration still requires the user to have kvm permissions but no longer requires root.


fix --typed-override paths

Motivation
We were handling --typed-override by doing naive path matching, which meant it was very easy for it to fail to work, and in fact rarely works in a project context unless your override .yaml file included a prefixed ./ on every path. This PR adds ./ to non-absolute paths, which bypasses this problem. (It does not fully solve the problem of path-matching: e.g. foo/./bar and foo/bar are still understood to be different, but that's a big can of worms.)
Test plan

See included automated tests. This expands a test of --typed-override to avoid regressions, as well.

Oh, it's kind of funky. What's prevent this logic from supporting a glob or a directory?

I admit, I don't love it either. I feel like my instinct would be to see if there's some library function we can lean on—that might give us globbing simultaneously, too. As it is, this will unblock people who need it, but I don't think this is a solution at all.

Making some changes as per conversation with @DarkDimius: we're going to make all yaml files require explicitly-relative paths instead of implicitly relative paths.


Support for maven-shade-plugin and launch4j-maven-plugin

Hi,
If you take a look at https://github.com/StegmannSystems/javafx.demo you can see that your mechanism mvnw clean javafx:run works fine. However that's just interesting for the purpose of testing.
See the following problem:
C:\Checkouts\javafx.demo>java -jar target\javafx-demo-0.0.1-SNAPSHOT-shaded.jar
Error: JavaFX runtime components are missing, and are required to run this application

I can solve it like this:
C:\Checkouts\javafx.demo>java --module-path c:\tools\javafx-sdk-11.0.2\lib  --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.media -jar target\javafx-demo-0.0.1-SNAPSHOT-shaded.jar

The main point here is that I already fetched all Java FX dependencies via pom.xml and I shouldn't be forced to specify those two parameters (at least not the module path). Do you have any clever trick on how this can be done more comfortable for maven-shade-plugin and launch4j (at least javafx:run seems to know)?

Late answer but i had a similar problem, that i could solve by using a Main-class that did not extend Application, so hat no direct JavaFX-dependencies. This just called App::main(), which did extend Application. This works for some reason.


T.must autocorrect doesn't operate on constructor kwargs

Input
→ View on sorbet.run
# typed: true
class A
    extend T::Sig

  sig {params(package: Integer).void}
  def initialize(package)
  end

  def self.foo
    pkg = T.let(nil, T.nilable(Integer))

    A.new(package: pkg)
    5.coerce(pkg)
    end
end

Observed output
editor.rb:12: Expected Integer but found {package: T.nilable(Integer)} for argument package https://srb.help/7002
    12 |    A.new(package: pkg)
                  ^^^^^^^^^^^^
    editor.rb:5: Method A#initialize has specified package as Integer
     5 |  sig {params(package: Integer).void}
                      ^^^^^^^
  Got {package: T.nilable(Integer)} originating from:
    editor.rb:12:
    12 |    A.new(package: pkg)
                  ^^^^^^^^^^^^

editor.rb:13: Expected Numeric but found T.nilable(Integer) for argument arg0 https://srb.help/7002
    13 |    5.coerce(pkg)
            ^^^^^^^^^^^^^
    https://github.com/sorbet/sorbet/tree/master/rbi/core/integer.rbi#L643: Method Integer#coerce has specified arg0 as Numeric
     643 |        arg0: Numeric,
                  ^^^^
  Got T.nilable(Integer) originating from:
    editor.rb:10:
    10 |    pkg = T.let(nil, T.nilable(Integer))
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Autocorrect: Use `-a` to autocorrect
    editor.rb:13: Replace with T.must(pkg)
    13 |    5.coerce(pkg)
                     ^^^
Errors: 2

Expected behavior
Only one incorrect nilable is autocorrect. T.must should be equally valid in both cases.

Relates to #1474

I looked at this a little this morning.  There are a couple different issues here:

We have overly-broad location information for keyword arguments, which I filed as #4387
Related to the above, we pass in Loc::none() for matching keyword argument types:

https://github.com/sorbet/sorbet/blob/16403b337aa621a15ae731e0c6d367926033560d/core/types/calls.cc#L997-L1005
which causes the type-driven autocorrect in matchArgType:
https://github.com/sorbet/sorbet/blob/16403b337aa621a15ae731e0c6d367926033560d/core/types/calls.cc#L188-L200
to not kick in:
https://github.com/sorbet/sorbet/blob/16403b337aa621a15ae731e0c6d367926033560d/core/TypeDrivenAutocorrect.cc#L7-L11
as Loc::none() is !exists(). Fixing #4387 will automagically add the autocorrect.

But the third issue is that in the original testcase, we never actually hit that code, because initialize takes a positional arg and the A.new call uses a keyword arg, so we go through:

https://github.com/sorbet/sorbet/blob/16403b337aa621a15ae731e0c6d367926033560d/core/types/calls.cc#L872-L885
Notice the shape type in the error message:
  Got {package: T.nilable(Integer)} originating from:
    editor.rb:12:
    12 |    A.new(package: pkg)
                  ^^^^^^^^^^^^

So I think the right answer for this particular bug is to...maybe detect that the user is passing keyword arguments but the method actually takes positional ones?  I don't think we could offer an autocorrect in that case.

On further inspection, it looks like there was a typo on line 6 (package -> package:) which would be required for the original request in the bug report to make sense. With that typo fix, @froydnj 's change in #4400 actually fixes this, so we can close! 🎉


nixos/picom: add useLocalConfig option

Description of changes
This option is to allow user to use their own picom config.
The current cfg does not include all picoms options, so user have to use services.picom.settings for some options like blur-*, considering most picom users alreay have their own picom config, it's easier for them by this option.
For reference from picom man page https://github.com/yshui/picom/blob/next/man/picom.1.asciidoc#configuration-files
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

@rnhmjoj summon maintainer in here,  could you give some inputs for this PR

I've been using the compton (now picom) for quite some time, but I have to say I don't quite like this option.
I'm not aware of any other NixOS option to explicitely make the configuration impure.

so user have to use services.picom.settings for some options like blur-*,

I don't see this as a negative, it's actually the recommended way to implement most options since RFC 0042.

considering most picom users alreay have their own picom config, it's easier for them by this option.

In that case why not ad an option to provide the configFile? This is more common and would be pure.

I had a read for RFC 0042,  indeed I can't say it's a negative for that context. ( I was not aware of the setting is a general  pattern  before). will close this PR.
back to the configFile, any suggestion for the pattern I should follow?  asking as seems it's different strategy between  non-x11 and x11 packages:
e.g. loki must use an exist config either from configFile or cfg.configuration
https://github.com/NixOS/nixpkgs/blob/634141959076a8ab69ca2cca0f266852256d79ee/nixos/modules/services/monitoring/loki.nix#L102
and the x11 package like  bspwm just reply on bspwm itself to search the config file in $HOME folder if not configFile:
https://github.com/NixOS/nixpkgs/blob/634141959076a8ab69ca2cca0f266852256d79ee/nixos/modules/services/x11/window-managers/bspwm.nix#L62

and the x11 package like bspwm just rely on bspwm itself to search the config file in $HOME folder if no configFile: in there

Desktop/window managers are kind of an exception: they can't be even configured declarative (without major hacks) in most cases. Personally, I would have the service fail when configFile is missing/broken rather than it trying to fall back to some dot file.

Thanks for your inputs! Will create another PR for the configFile.