text:
(SOLARCH-523) the name entries should be internal cloud names for pup…

Updated public to private to make sure puppet uses internal dns references rather than public.
Tested with
/opt/puppetlabs/bolt/bin/bolt plan run autope project=davidsand ssh_user=centos provider=aws architecture=xlarge replica=true node_count=3 compiler_count=4 firewall_allow='[ "0.0.0.0/0" ]'
All ran correctly as per output and tested node runs and web interface successfully
Starting: plan autope Starting: task terraform::initialize on localhost Finished: task terraform::initialize with 0 failures in 0.22 sec Starting: plan terraform::apply Starting: task terraform::apply on localhost Finished: task terraform::apply with 0 failures in 248.69 sec Starting: task terraform::output on localhost Finished: task terraform::output with 0 failures in 0.9 sec Finished: plan terraform::apply in 4 min, 10 sec Starting: plan peadm::install Starting: plan peadm::subplans::install Starting: task peadm::precheck on 8 targets Finished: task peadm::precheck with 0 failures in 7.05 sec Starting: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-p74im2 to /tmp/pe.conf on ip-10-138-1-186.us-west-2.compute.internal Starting: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-41gk6f to /tmp/pe.conf on ip-10-138-1-184.us-west-2.compute.internal Starting: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-1jhjnlu to /tmp/pe.conf on ip-10-138-2-45.us-west-2.compute.internal Finished: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-1jhjnlu to /tmp/pe.conf with 0 failures in 5.53 sec Finished: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-p74im2 to /tmp/pe.conf with 0 failures in 5.55 sec Finished: file upload from /var/folders/5p/l3pkc0rs4jz_6z71mdz2gyh80000gn/T/peadm20210705-78809-41gk6f to /tmp/pe.conf with 0 failures in 5.67 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-186.us-west-2.compute.internal Starting: task peadm::mkdir_p_file on ip-10-138-1-184.us-west-2.compute.internal Starting: task peadm::mkdir_p_file on ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 5.97 sec Finished: task peadm::mkdir_p_file with 0 failures in 6.06 sec Finished: task peadm::mkdir_p_file with 0 failures in 6.1 sec Starting: task peadm::download on ip-10-138-1-186.us-west-2.compute.internal, ip-10-138-1-184.us-west-2.compute.internal, ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::download with 0 failures in 42.95 sec Starting: plan peadm::util::insert_csr_extension_requests Starting: plan peadm::util::insert_csr_extension_requests Starting: plan peadm::util::insert_csr_extension_requests Starting: task peadm::read_file on ip-10-138-1-186.us-west-2.compute.internal Starting: task peadm::read_file on ip-10-138-1-184.us-west-2.compute.internal Starting: task peadm::read_file on ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::read_file with 0 failures in 6.13 sec Finished: task peadm::read_file with 0 failures in 6.2 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-184.us-west-2.compute.internal Starting: task peadm::mkdir_p_file on ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::read_file with 0 failures in 6.56 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 5.92 sec Finished: plan peadm::util::insert_csr_extension_requests in 12.59 sec Finished: task peadm::mkdir_p_file with 0 failures in 6.08 sec Finished: plan peadm::util::insert_csr_extension_requests in 13.11 sec Finished: task peadm::mkdir_p_file with 0 failures in 6.08 sec Finished: plan peadm::util::insert_csr_extension_requests in 13.62 sec Starting: task peadm::pe_install on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::pe_install with 0 failures in 228.67 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 6.99 sec Starting: task peadm::pe_install on ip-10-138-1-184.us-west-2.compute.internal, ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::pe_install with 0 failures in 91.35 sec Starting: command 'systemctl stop pe-puppetdb' on ip-10-138-1-186.us-west-2.compute.internal Finished: command 'systemctl stop pe-puppetdb' with 0 failures in 2.34 sec Starting: command 'systemctl start pe-puppetdb' on ip-10-138-1-186.us-west-2.compute.internal Finished: command 'systemctl start pe-puppetdb' with 0 failures in 30.52 sec Starting: task peadm::rbac_token on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::rbac_token with 0 failures in 8.97 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 6.09 sec Starting: task peadm::code_manager on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::code_manager with 0 failures in 11.89 sec Starting: task peadm::puppet_runonce on ip-10-138-1-184.us-west-2.compute.internal, ip-10-138-2-45.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-1-178.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-2-193.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-3-207.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-4-252.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-2-135.us-west-2.compute.internal Finished: task peadm::agent_install with 0 failures in 35.58 sec Starting: task peadm::submit_csr on ip-10-138-4-252.us-west-2.compute.internal Finished: task peadm::puppet_runonce with 0 failures in 39.0 sec Finished: task peadm::agent_install with 0 failures in 39.52 sec Starting: task peadm::submit_csr on ip-10-138-3-207.us-west-2.compute.internal Finished: task peadm::agent_install with 0 failures in 40.23 sec Starting: task peadm::submit_csr on ip-10-138-1-178.us-west-2.compute.internal Finished: task peadm::agent_install with 0 failures in 40.85 sec Starting: task peadm::submit_csr on ip-10-138-2-193.us-west-2.compute.internal Finished: task peadm::agent_install with 0 failures in 44.02 sec Starting: task peadm::submit_csr on ip-10-138-2-135.us-west-2.compute.internal Finished: task peadm::submit_csr with 0 failures in 14.4 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::submit_csr with 0 failures in 16.3 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::submit_csr with 0 failures in 16.45 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 9.06 sec Starting: task peadm::puppet_runonce on ip-10-138-4-252.us-west-2.compute.internal Finished: task peadm::submit_csr with 0 failures in 18.25 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::submit_csr with 0 failures in 16.36 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 9.44 sec Starting: task peadm::puppet_runonce on ip-10-138-1-178.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 10.4 sec Starting: task peadm::puppet_runonce on ip-10-138-3-207.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 9.8 sec Starting: task peadm::puppet_runonce on ip-10-138-2-193.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 9.84 sec Starting: task peadm::puppet_runonce on ip-10-138-2-135.us-west-2.compute.internal Finished: task peadm::puppet_runonce with 0 failures in 22.99 sec Finished: task peadm::puppet_runonce with 0 failures in 146.79 sec Finished: task peadm::puppet_runonce with 0 failures in 159.98 sec Finished: task peadm::puppet_runonce with 0 failures in 167.93 sec Finished: task peadm::puppet_runonce with 0 failures in 170.75 sec Starting: task peadm::puppet_runonce on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::puppet_runonce with 0 failures in 79.12 sec Starting: task peadm::wait_until_service_ready on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::wait_until_service_ready with 0 failures in 6.72 sec Starting: task peadm::puppet_runonce on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::puppet_runonce with 0 failures in 55.2 sec Starting: task peadm::mkdir_p_file on ip-10-138-1-186.us-west-2.compute.internal Starting: task peadm::mkdir_p_file on ip-10-138-1-184.us-west-2.compute.internal Starting: task peadm::mkdir_p_file on ip-10-138-2-45.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 6.35 sec Finished: task peadm::mkdir_p_file with 0 failures in 6.39 sec Finished: task peadm::mkdir_p_file with 0 failures in 7.07 sec Finished: plan peadm::subplans::install in 14 min, 13 sec Starting: plan peadm::subplans::configure Starting: task peadm::read_file on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::read_file with 0 failures in 6.3 sec Starting: task peadm::mkdir_p_file on ip-10-138-2-135.us-west-2.compute.internal, ip-10-138-1-178.us-west-2.compute.internal, ip-10-138-2-193.us-west-2.compute.internal, ip-10-138-3-207.us-west-2.compute.internal, ip-10-138-4-252.us-west-2.compute.internal Finished: task peadm::mkdir_p_file with 0 failures in 6.94 sec Starting: apply catalog on ip-10-138-1-186.us-west-2.compute.internal Finished: apply catalog with 0 failures in 17.08 sec Starting: task peadm::provision_replica on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::provision_replica with 0 failures in 741.15 sec Starting: task peadm::puppet_runonce on 8 targets Finished: task peadm::puppet_runonce with 0 failures in 69.15 sec Starting: command 'systemctl start puppet' on 8 targets Finished: command 'systemctl start puppet' with 0 failures in 2.52 sec Finished: plan peadm::subplans::configure in 14 min, 3 sec Finished: plan peadm::install in 28 min, 16 sec Starting: task peadm::agent_install on ip-10-138-1-36.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-2-108.us-west-2.compute.internal Starting: task peadm::agent_install on ip-10-138-3-88.us-west-2.compute.internal Finished: task peadm::agent_install with 0 failures in 38.4 sec Finished: task peadm::agent_install with 0 failures in 40.08 sec Finished: task peadm::agent_install with 0 failures in 40.93 sec Starting: task peadm::sign_csr on ip-10-138-1-186.us-west-2.compute.internal Finished: task peadm::sign_csr with 0 failures in 9.2 sec Log into Puppet Enterprise Console: https://54.212.169.162 Finished: plan autope in 33 min, 18 sec Plan completed successfully with no result

Based on the simplicity of this change I will merge it myself

repo: puppetlabs/puppetlabs-autope


text:
大佬，已部署的想要更新怎么操作啊

部署了很久了，最近看到你这边代码有更新，怎么操作更新最快捷啊

到目前为止的更新大多是修复之前的错误，如果使用没有发现问题可以选择不更新。
更新的话，因为现在和将来都不会频繁发生，还是推荐从头部署一遍。

好，了解谢谢

source: gharchive/issue

authors: beer-on-ice pureink

repo: pureink/inkrss

license: MIT

license_type: permissive

license_source: github-api


text:
Replace explicit wrapping and unwrapping of newtypes by coercions

This adds Coercible superclasses to Newtype in order to implement most combinators with coerce.
Newtype constructors have to be exported for them to be unwrapped when solving Coercible constraints so this means that Newtype instances for types with hidden constructors won’t be usable anymore outside of their module of definition. This is mitigated by https://github.com/purescript/purescript/pull/3907 which emits a warning for such types (this warning would be turned into an error by the pull request updating the compiler support for Newtype instances deriving) and https://github.com/purescript/purescript/pull/3927 which suggests to export hidden newtype constructors when a Coercible constraint fails to solve because of that.
This also means that Newtype instances can only de declared for representationally equal types.
I reckon that releasing this along with the next compiler release is perhaps too reckless but at least it should provide more context and motivation for the mentioned warnings.

Is there a particular reason not to do this now? I think if we're going to do it at all, then the sooner the better.

I’d like to release this with the v0.14.0 too but this depends on and implies a few things:

We should merge https://github.com/purescript/purescript/pull/3930 first so we can drop one of the Coercible superclasses.
We should also merge https://github.com/purescript/purescript/pull/3907 and https://github.com/purescript/purescript/pull/3927 (which depends on the more critical https://github.com/purescript/purescript/pull/3937) for helpful warnings.
We should then update the compiler support for deriving Newtype instances. I have prepared a pull request but it depends on https://github.com/purescript/purescript/pull/3907 (to turn the warning into an error for types with hidden constructors but Newtype instances) and a new version of this package to be released (to update tests/support/bower.json in the compiler repository).

Right, ok, I didn't realise we'd have to do all that stuff too. In that case I think we should leave this out for now. If we manage to do all those things before we're ready to release v0.14.0 then that's fine, but otherwise I don't think this is an important enough change to hold v0.14.0 up.

Of the PRs @kl0tl mentioned above that need to be merged before this PR can be merged, only https://github.com/purescript/purescript/pull/3927 hasn't yet been merged (but looks like it will be soon).

I think https://github.com/purescript/purescript/pull/3927 isn't even a hard requirement for merging this, it's just a change to make certain compiler errors more helpful, so I'd be in favour of going ahead and merging this now.

Do we need to rebase this on top of current master to make GH Actions run rather than Travis?

I think so, yes.

CI is failing with this error:
[1/1 NoInstanceFound] src/Data/Newtype.purs:42:1

  42  instance newtypeMultiplicative :: Newtype (Multiplicative a) a
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  No type class instance was found for

    Prim.Coerce.Coercible (Multiplicative a0)
                          a0

  while checking that expression #dict Coercible
    has type Coercible$Dict @Type (Multiplicative a0) a0
  in value declaration newtypeMultiplicative

  where a0 is a rigid type variable
          bound at (line 0, column 0 - line 0, column 0)

           Src   Lib   All
Warnings   0     0     0
Errors     1     0     1

That will probably be because the Multiplicative constructor is not in scope, we’ll need to import it in that module.

source: gharchive/pull-request

authors: JordanMartinez hdgarrood kl0tl

repo: purescript/purescript-newtype


text:
Night Mode Feature

Is your feature request related to a problem? Please describe.

I want to give this project feature of night mode.

Describe the solution you'd like

I will give a checkbox like button by enabling it the color theme of the website changes to dark mode.

@purnima143 If valid please assign and also recommend me with the main color theme replacing the orange texture.

@purnima143 please suggest him about the color theme

@vedant-jain03 use brown color as background for dark theme...and for font use more up of orange or creame or white colors


text:
Add utility functions for the webserver

if the server file is added, we will also need some utility functions to go with them. So add necessary functions required for a full-functioning webserver.

Hi @hp77-creator, I think you need an webserver which you will connect to your frontend using APIs. I can work on this issue. My workflow will be like this:
1. create the root directory as mono-repo because there will be frontend code and backend code (server)
2. There will be a folder in root directory as `packages` under which there will we folder as `frontend` and `server`

If you have any suggestions please let me know

repo: pushpendrahpx/conversion-lamp


text:
Divide the Main.Storyboard into Multiple Storyboards

create 2 storyboard for each tab in the tabBar Controller, also could be another one created to show the details of the rockets, but not yet is ready that functionality

You have deleted the storyboards with non-present links. Do check what you are creating a pr for is actually working

repo: pushpinderpalsingh/SpaceDash


text:
Post: Les webhooks

Poke @putaindecode/owners

Please do not cut the original hero image, since it will depend of the viewport. No ?

Also configuration_webhook.jpg looks pretty bad. You probably compressed too much :/

:+1:

cool ce sujet !

Bonne idée @magsout :+1:

Il pourrait être intéressant d'ajouter un exemple de webhook très simple. Je suis sûr qu'en moins de 10 lignes tu peux avoir un truc avec express.

@magsout if you change assets (image) squash+force push is preferred so we don't keep both images in git.

yep, but I have to remove @Macxim commit ...

Please do. :)

I will tell you how to do

Il pourrait être intéressant d'ajouter un exemple de webhook très simple. Je suis sûr qu'en moins de 10 lignes tu peux avoir un truc avec express.

Est-ce pertinent de donner un exemple pour la partie serveur, vu que j'aborde pas vraiment cette notion ici ? Tu peux d'ailleurs utiliser ce que tu veux sur le serveur.

@magsout Je pense que oui car ça rend l'article moins abstrait et permettrait de montrer le genre d'infos que tu reçois. Au moins la personne intéressée n'a pas à faire le test pour savoir si oui ou non les webhooks pourraient les apporter quoi que ce soit.

Drop the image diff with something like this
$ git checkout master
$ git checkout -b post.Webhooks--fix
# your first commit
$ git cherry-pick e00802d2e364833e4353e3e4dc71e668b0347fcd
# add images, then
$ git commit -A content/posts/git/webhooks
$ git commit --amend
# get other commits and hope the image diffs will be skipped !
$ git cherry-pick c27f74cf858f261f4a081d0439f5fd580c8318e5
$ git cherry-pick 0f99e8fd14c6bcef815f7e1e87ffee62f52ab466
$ git cherry-pick b29f0805de4ed71b472f2d495cf50b7ccfd73aa6
# force push
$ git push -f origin post.Webhooks--fix post.Webhooks

Je trouve aussi que c'est intéressant d'avoir ne serait-ce qu'un exemple basique.

+1 pour un exemple

Est-ce que je rajoute un extrait du JSON reçu ?

Carrément !

:+1: avec la prop d' @ooflorent

@MoOx @lionelB @ooflorent voila un exemple et le JSON et header envoyé par Github en exemple.

Drop the image diff with something like this

Done @MoOx , thanks for you help

@Macxim pense à préfixer tes messsages de commit par "Post: {le titre}, le vrai message de commit"

Oui, en effet, c'est bien sale ce que j'ai fait.

je pense qu'il faudrait preciser dans le titre «  github webhooks » , en espérant qu'un article «  docker.hub webhooks » voie le jour.

@goabonga c'est le cas https://github.com/putaindecode/putaindecode.fr/commit/0bfe5a05c6e5fb203d5b852811ea53b2d9c8fdfd#diff-0e3a3b74523697ddc71575f44f0866b3R3
J'avais modifié suite à la remarque de @ooflorent

petit point à voir sur l'url
git/webhooks n'est pas approprié.
webhooks/github ?
env/webhooks/github ?
sysadmin/webhooks/github ?
ci/webhooks/github ?

webhooks/github

Webhooks étant une méthode , je pense qu'on peut l'avoir comme repertoire de base.

je veux bien un autre avis qu'on en finissseeee :)

on va pas avoir 50 posts sur les webhooks je pense, /posts/ci/webhooks-github.html

/posts/ci/webhooks-github.html me parait approprié.
ci c'est parlant et ça englobe pas mal de choses, et je pense pas qu'il faille catégoriser webhook.

GO pour /posts/ci/webhooks-github.html

Je suis d'accord avec @Nyalab et @kud :shipit:

go pour ci/webhooks-github. Je modifie et push

Bon @magsout on est bon, j'ai optimisé les images (index et une autre) et j'ai trouvé une meilleure technique (je découvre git tous les jours)
$ git rebase --interactive 76gh65^

Tu prends le short hash du commit que tu veux changer, tu met edit là ou tu veux éditer à la place de pick, quand t'es en édition ca te dit bien quoi faire (d'ou le interactive). C'est vraiment magnifique git.
Je merge

@MoOx je sais que tu es fan des raccourcis (à en voir comment tu écris tes commandes npm).
Il suffit de faire :
$ git rebase -i 76gh65^

Merci de la précision.

merci @MoOx :heart:
woot, cool le tips

.html ? Seriously ??
--
Florent Cailhol

http://putaindecode.fr/posts/ci/webhooks-github/

@ooflorent on sait tous que tu aurais préféré .asp.

authors: Macxim MoOx Nyalab goabonga kud lionelB magsout ooflorent

license: mit

license_source: bigquery


text:
rename series_modules, parallel_modules

The PVSystem class and the system_def function accept keyword arguments series_modules and parallel_modules. Until PR #171, pvlib code did not actually use them and they only existed for user extensions. As brought up in #171 by @jforbess, these names are confusing at best.
Now is a good time to change them since they didn't actually do anything before. I would support something like series_modules --> modules_per_string and parallel_modules --> strings.
I'd normally wait for 0.4 to implement a change that could break user code, but in this case I'm leaning towards 0.3.3 release because 1) it's unlikely that anyone is actually using these arguments and 2) #171 is going in 0.3.3.
Thoughts?

Actually, I don't think the original terms were all that bad.  At least there seemed little chance that they would be interpreted incorrectly, which is an important criterion.  "modules_per_string" is fine, but I do not think "strings" is quite enough.  Maybe "number_of_strings" could be considered, if long names are favoured.  Personaly I prefer shorter ones, like "string_length" and "n_strings".
Any of these new alternatives would seem imply one specific wiring scheme for the NxM matrix of modules, whereas the calculations for a homogenous system and conditions apply to all possible wiring schemes.

I think it's assuming the same number of modules per string behind a single
inverter. You can build up systems from inverter units. It does assume the
same number of modules per string for all strings in an inverter, which is
perhaps a bit less normal these days with multi MPPT handling.
I think parallel_modules is confusing because in my head it should be
parallel_strings, not modules. But I see what you mean.
On Fri, May 20, 2016 at 11:32 PM, Anton Driesse notifications@github.com
wrote:

Actually, I don't think the original terms were all that bad. At least
there seemed little chance that they would be interpreted incorrectly,
which is an important criterion. "modules_per_string" is fine, but I do not
think "strings" is quite enough. Maybe "number_of_strings" could be
considered, if long names are favoured. Personaly I prefer shorter ones,
like "string_length" and "n_strings".
Any of these new alternatives would seem imply one specific wiring scheme
for the NxM matrix of modules, whereas the calculations for a homogenous
system and conditions apply to all possible wiring schemes.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/176#issuecomment-220761890

My vote is for
Modules_per_string
Strings_per_inverter
Cliff
Sent from my iPhone
On May 21, 2016, at 9:33 PM, jforbess <notifications@github.commailto:notifications@github.com> wrote:
I think it's assuming the same number of modules per string behind a single
inverter. You can build up systems from inverter units. It does assume the
same number of modules per string for all strings in an inverter, which is
perhaps a bit less normal these days with multi MPPT handling.
I think parallel_modules is confusing because in my head it should be
parallel_strings, not modules. But I see what you mean.
On Fri, May 20, 2016 at 11:32 PM, Anton Driesse <notifications@github.commailto:notifications@github.com>
wrote:

Actually, I don't think the original terms were all that bad. At least
there seemed little chance that they would be interpreted incorrectly,
which is an important criterion. "modules_per_string" is fine, but I do not
think "strings" is quite enough. Maybe "number_of_strings" could be
considered, if long names are favoured. Personaly I prefer shorter ones,
like "string_length" and "n_strings".
Any of these new alternatives would seem imply one specific wiring scheme
for the NxM matrix of modules, whereas the calculations for a homogenous
system and conditions apply to all possible wiring schemes.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/176#issuecomment-220761890

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com/pvlib/pvlib-python/issues/176#issuecomment-220812400

I like Cliff's suggestions.

Yes, I think they are good. The only possible future proofing is
strings_per_mppt, (maximum power point tracker). Though the current sandia
inverter model doesn't work that way, I could see it or another model being
extended that way in the future.
Jessica
On Thu, May 26, 2016 at 12:02 PM, Will Holmgren notifications@github.com
wrote:

I like Cliff's suggestions.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/176#issuecomment-221963804

If we allow the possibiity of not having an inverter or an mppt unit, how about "strings_per_array"?

But isn't the point to allocate a set amount of kWdc to a given mppt, so
that it can be modeled? I am sure I could be overlooking a system type, so
please feel free to describe what I'm missing.
I was viewing the goal defining these parameters as the finest grain to be
handled uniquely in a model. Multiple systems can be ganged together to
make up one site's worth of PV.
Even if it is not, I think that array is too general, and would mean
different things to different people. An array could contain many inverters
or mppts, right?
On Fri, May 27, 2016 at 2:45 PM, Anton Driesse notifications@github.com
wrote:

If we allow the possibiity of not having an inverter or an mppt unit, how
about "strings_per_array"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pvlib/pvlib-python/issues/176#issuecomment-222260230,
or mute the thread
https://github.com/notifications/unsubscribe/AH66Ae658e7QTlLbdHF8R94Jqf-HL99vks5qF2YFgaJpZM4IjZx1
.

Yes, the word "array" is certainly open to interpretation.  Feel free to
ignore this suggestion!

At the risk of getting off topic... I think that at one point, maybe in #17, there was some consensus on defining a PVSystem as being a set of modules connected to a single inverter. It seemed like a fine place to start. But perhaps part of the reason for the disagreement/discussion here is that the existing PVSystem may not provide the right level of abstraction for many users. We may need a set of PVSystem-like classes to keep things reasonable. Off the top of my head, one related class could be PVPowerPlant, something that collects and aggregates multiple PVSystems. I don't see an obvious good solution for @jforbess's multi-mppt inverters using the existing PVSystem class. Let's make a new PVSystem refactoring issue if anyone wants to discuss this in more detail. Maybe we can also set aside some time at PVSC to discuss these ideas in person.
That being said, I think that our existing PVSystem can model a lot of MWs with a simple modules_per_string and strings_per_inverter (assuming the same number of modules per string for all strings behind a single inverter).
Long story short, I prefer to forge ahead with modules_per_string and strings_per_inverter for now because we may need to make much larger changes in the future. Is that reasonable?

Yes, I think it's fine for now, considering the current state of the
inverter models. Just pointing out future trends.
On Sun, May 29, 2016 at 12:29 PM, Will Holmgren notifications@github.com
wrote:

At the risk of getting off topic... I think that at one point, maybe in
#17 https://github.com/pvlib/pvlib-python/issues/17, there was some
consensus on defining a PVSystem as being a set of modules connected to a
single inverter. It seemed like a fine place to start. But perhaps part of
the reason for the disagreement/discussion here is that the existing
PVSystem may not provide the right level of abstraction for many users. We
may need a set of PVSystem-like classes to keep things reasonable. Off the
top of my head, one related class could be PVPowerPlant, something that
collects and aggregates multiple PVSystems. I don't see an obvious good
solution for @jforbess https://github.com/jforbess's multi-mppt
inverters using the existing PVSystem class. Let's make a new PVSystem
refactoring issue if anyone wants to discuss this in more detail. Maybe we
can also set aside some time at PVSC to discuss these ideas in person.
That being said, I think that our existing PVSystem can model a lot of MWs
with a simple modules_per_string and strings_per_inverter (assuming the
same number of modules per string for all strings behind a single
inverter).
Long story short, I prefer to forge ahead with modules_per_string and
strings_per_inverter for now because we may need to make much larger
changes in the future. Is that reasonable?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pvlib/pvlib-python/issues/176#issuecomment-222378138,
or mute the thread
https://github.com/notifications/unsubscribe/AH66AQBIcTP1PvOTDaZI39WiAF9HCpzVks5qGekzgaJpZM4IjZx1
.

Closed by #188.

authors: adriesse cwhanse jforbess wholmgren

repo: pvlib/pvlib-python


text:
노인인구증가추이.md 이미지  추가

인구증가율을 그래프로 나타낸 사진을 추가하여 한눈에 볼수있게 하였고, 인구수에 명 단위를 추가하였음

2명 이상 찬성하는 것으로 판단, Merge 진행하겠습니다.

authors: Roniebin wlwhsxz


text:
[Bug] unc0ver app "Share Diagnostics Data"

The UI shows just the background image of unc0ver app after pressing "Share Diagnostics Data"
To Reproduce
Steps to reproduce the behavior:

Go to unc0ver App
Click on 'Settings'
Click on 'Share Diagnostics Data'
Select 'Save in Files'
Save it. Now it jumps back to the unc0ver app and now just the background image is shown.

Screenshots

Device (please complete the following information):

iOS Version: 12.1.1b3
iOS Device: iPhone9,3
unc0ver Version: 3.2.1

Place an "x" between the brackets if true:

[X] this is a bug others will be able to reproduce
[ ] this issue is present with all tweaks uninstalled(except for default packages) or disabled
[ ] this issue is present after a rootfs restore
[X] this issue is present on the latest version of unc0ver

Logs
If applicable, add logs or error messages here.

Same here, mine shows black background as I have the dark theme. Happens every time and I have to force quit the app.
iOS 12.1.2
iPhone 10,4
Model D201AP
Unc0ver 3.2.1


text:
Feature request - add hover window for issue/PR numbers on CursorHold

Taken from [here].
The title basically states it. But in the web UI of GitHub you can hover over issue and PR numbers (plus users, also this isn't that interesting) which will show a summary of this object. This is incredibly useful when you read a issue or PR and see such a reference. You usually don't want to interrupt your flow and searching this issue and open it, than search the old issue and scroll to where you left earlier.

Extension: hover over reactions lists users

sample query for comment reactions:
{
  node(id: "%s") {
    ... on PullRequestReviewComment {
      reactionGroups {
        content
        users(last: 100) {
          nodes {
            login
          }
        }
      }
    }
    ... on PullRequestReview {
      reactionGroups {
        content
        users(last: 100) {
          nodes {
            login
          }
        }
      }
    }
    ... on IssueComment {
      reactionGroups {
        content
        users(last: 100) {
          nodes {
            login
          }
        }
      }
    }
  }
}

sample query for user information:
{
  user(login: "%s") {
    login
    bio
    company
    followers(first: 1) {
      totalCount
    }
    following(first: 1) {
      totalCount
    }
    hovercard {
      contexts {
        message
      }
    }
    hasSponsorsListing
    isEmployee
    isViewer
    location
    organizations(last: 5) {
      nodes {
        name
      }
    }
    name
    status {
      emoji
      message
    }
    twitterUsername
    websiteUrl
  }
}

Reactions are virtual text, aren't they? This means the user can't move the cursor on them. Or do I miss something?

They are, but I planned to show a table with all reactions/users if hovering over the reactions line.
Alternatively we can use an overlay which should allow users to move around the line. On hold, we should be able to resolve what reaction in under the cursor

Added reactions popup:

unaligned border seems to be a bug in neovim ...

User profile exmaples:

Amazing work! This issue is so damn perfectly fulfilled. 😬

authors: pwntester weilbith


text:
🛑 ITLab is down

In 81035c3, ITLab (https://www.itlab.cc/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ITLab is back up in b89b24c.

repo: pwtsai/upptime


text:
🛑 NARLabs is down

In d24a437, NARLabs (https://www.narlabs.org.tw/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NARLabs is back up in 1a6c479.


text:
Integration is Broken after update to core-2021.11.1

After Update to Core 2021.11.1 the integration does not start.
Environment Information:
Core Version 2021.11.1
Supervisor 2021.10.8
Python Version: 3.9.7
Home Assistant OS 6.6
Installed AddOns:
File editor (5.3.3), Samba share (9.3.0), Log Viewer (0.12.0), HomeMatic CCU (11.3.0), Terminal & SSH (9.2.1), Emulated HUE (0.2.10)
Error Log:
Logger: homeassistant.config_entries
Source: custom_components/gardena_smart_system/init.py:91
Integration: Gardena Smart System integration (documentation, issues)
First occurred: 09:49:48 (1 occurrences)
Last logged: 09:49:48
Error setting up entry for gardena_smart_system
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 304, in async_setup
result = await component.async_setup_entry(hass, self)  # type: ignore
File "/config/custom_components/gardena_smart_system/init.py", line 53, in async_setup_entry
await hass.async_add_executor_job(gardena_system.start)
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/gardena_smart_system/init.py", line 91, in start
self.smart_system.update_locations()
File "/usr/local/lib/python3.9/site-packages/gardena/smart_system.py", line 217, in update_locations
response_data = self.__call_smart_system_get(f"{self.SMART_HOST}/v1/locations")
File "/usr/local/lib/python3.9/site-packages/gardena/smart_system.py", line 188, in __call_smart_system_get
if self.__response_has_errors(response):
File "/usr/local/lib/python3.9/site-packages/gardena/smart_system.py", line 162, in __response_has_errors
r = response.json()
File "/usr/local/lib/python3.9/site-packages/requests/models.py", line 910, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/local/lib/python3.9/site-packages/simplejson/init.py", line 525, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.9/site-packages/simplejson/decoder.py", line 370, in decode
obj, end = self.raw_decode(s)
File "/usr/local/lib/python3.9/site-packages/simplejson/decoder.py", line 400, in raw_decode
return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Same issue here

The problem also occurs here with me.

Hi,
I think this is the same as my report  #93, where it was about disconnecting and reconnecting the API in the Husqvarna developer environment. No need to reissue the API keys, worked for me without it.
Best
Alexander

Thanks @awirtz, that worked for me!

Worked for me as well!

You are my hero @awirtz !

Hello,
Thx Arwiz for the update on the tip.
It happens sometimes, not at the same time, but by batch of people.
I will try to find the time to update the documention with this information ... it may help

authors: Azadk MoritzBuetzer awirtz bussio eich0rn grm rostikk80


text:
Multiply the digits of the number entered by the user expect zero on …

…python

PR accepted.


text:
Added Selection Sort in Golang and typo fix in contributing.md

Please do accept this PR and label it hacktoberfest-accepted

PR accepted @francojoem.
Profile Verified.
Successfully merged to HacktoberFest_22 repo.
🚀🚀👍


text:
Update .pre-commit-config.yaml

Closes #44
@sylvchev I misunderstood your message in the original issue. I though you wanted to add pre-commit hooks.
This PR updates pre-commit-config as per MOABB, and remove flake8 workflow.

Ok, this nice. My initial comment still stands, but I think this is not an issue in the case of pyriemann-qiskit

Thank you!

authors: gcattan sylvchev

repo: pyRiemann/pyRiemann-qiskit


text:
Error: secret "wazuh-api-cred" not found

Hi @pyToshka
Thank you for creating a daemonset for k8s.
after running the deamonset I faced a problem:
the pods are in CreateContainerConfigError state and when I check the reason:
Error: secret "wazuh-api-cred" not found.
what should I do now to solve this?
I really appreciate any help you can provide.

@Faarhad  hello, this error mean you have not secret named wazuh-api-cred, please configure daemon set for using credentials

@pyToshka Thank you for your quick response, I created a secret for that, but there's no svc for Wazuh deamonset.
please correct me if I'm wrong.
I installed Wazuh agent on my Linux OS, and I can see all machines logs in Wazuh manager, in order to monitor k8s I ran a deamonset just like the documentation said.
so I create a deamon set but now it's searching for a service. did I do that correctly? or for monitoring k8s components I should use Wazuh installation alternative: deployment on kubernetes?

@Faarhad  you should setup ENV based on your setup, please setup correct envs for daemonset.

Thank you @pyToshka, I fill out all envs requirements,
This is my envs parameters:
I created a secret for deamonset, which it's username is admin (as wazuh default) and it's password is my wazuh dashboard pass. this is my rest of Yaml file:
       env:         - name: JOIN_MANAGER_MASTER_HOST           value: "20.20.20.87" #this is IP address of wazuh manager dashboard         - name: JOIN_MANAGER_WORKER_HOST           value: "20.20.20.87"         - name: JOIN_MANAGER_PROTOCOL           value: "https"         - name: FLASK_BIND           value: "0.0.0.0"         - name: NODE_NAME           valueFrom:             fieldRef:               fieldPath: spec.nodeName         - name: WAZUH_GROUPS           value: default         - name: JOIN_MANAGER_USER           valueFrom:            secretKeyRef:              name: wazuh-secret              key: username         - name: JOIN_MANAGER_PASSWORD           valueFrom:             secretKeyRef:               name: wazuh-secret               key: password         - name: JOIN_MANAGER_API_PORT           value: "55000"         - name: JOIN_MANAGER_PORT           value: "1514"         - name: HEALTH_CHECK_PROCESSES           value: "ossec-execd,ossec-syscheckd,ossec-logcollector,wazuh-modulesd,ossec-authd"
now pods are created but with the state of CrashLoopBackOff
I think I'm missing a dumb point!
Thank you for your patience and kind response.

@Faarhad  for CrashLoopBackOff need to check logs what the reason

is my env configuration correct?
env:
- name: JOIN_MANAGER_MASTER_HOST
value: "20.20.20.87" #this is IP address of wazuh manager dashboard
- name: JOIN_MANAGER_WORKER_HOST
value: "20.20.20.87"
- name: JOIN_MANAGER_PROTOCOL
value: "https"
- name: FLASK_BIND
value: "0.0.0.0"
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: WAZUH_GROUPS
value: default
- name: JOIN_MANAGER_USER
valueFrom:
secretKeyRef:
name: wazuh-secret
key: username
- name: JOIN_MANAGER_PASSWORD
valueFrom:
secretKeyRef:
name: wazuh-secret
key: password
- name: JOIN_MANAGER_API_PORT
value: "55000"
- name: JOIN_MANAGER_PORT
value: "1514"
- name: HEALTH_CHECK_PROCESSES
value: "ossec-execd,ossec-syscheckd,ossec-logcollector,wazuh-modulesd,ossec-authd"

This is pods log:
2022-12-07 12:22:11.813 | INFO     | main::251 - Adding agent with name worker3
Traceback (most recent call last):
File "/var/ossec/./register_agent.py", line 252, in
agent_id, agent_key = add_agent(node_name)
File "/var/ossec/./register_agent.py", line 119, in add_agent
status_code, response = req(
File "/var/ossec/./register_agent.py", line 50, in req
token = json.loads(response.content.decode())["data"]["token"]
KeyError: 'data'
root@master1:/home/sysadm# kubectl logs -f  wazuh-agent-dj78m  -n wazuh

This is pods log:
2022-12-07 12:22:11.813 | INFO | main::251 - Adding agent with name worker3 Traceback (most recent call last): File "/var/ossec/./register_agent.py", line 252, in agent_id, agent_key = add_agent(node_name) File "/var/ossec/./register_agent.py", line 119, in add_agent status_code, response = req( File "/var/ossec/./register_agent.py", line 50, in req token = json.loads(response.content.decode())["data"]["token"] KeyError: 'data' root@master1:/home/sysadm# kubectl logs -f wazuh-agent-dj78m -n wazuh

seems like agent couldn't connect to your Wazuh server

authors: Faarhad pyToshka

repo: pyToshka/docker-wazuh-agent


text:
async_setup_platforms error in beta 2023.2.0b0

Detected integration that called async_setup_platforms instead of awaiting async_forward_entry_setups; this will fail in version 2023.3. Please report issue to the custom integration author for alarmdotcom using this method at custom_components/alarmdotcom/init.py, line 124: hass.config_entries.async_setup_platforms(config_entry, PLATFORMS)

Thanks for reporting this. It's fixed and will be included in the next release!

repo: pyalarmdotcom/alarmdotcom


text:
Reporting None for comparisons with no alignments

This partially addresses issue #140.
We show now handle comparisons that return no alignments by setting all values (e.g., sim errors, identity, coverage, alignment length, etc.) to None, rather than raising different types of errors.
Unfortunately, t took me longer than expected. I run into a small issue with the dnadiff method failing. I hadn't realised that in some cases, even when alignments are found, .qdiff files can be empty because there are "no gaps" in the alignments. Additionally, Ruff flagged some style issues in the code, so I had to come up with a different solution.
Type of change

[X] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality not to work as expected)
[ ] This change requires a documentation update
[ ] This is a documentation update

Action Checklist

[X] Work on a single issue/concept (if there are multiple separate issues to address, please use a separate pull request for each)
[X] Fork the pyani-plus repository under your own account (please allow write access for repository maintainers)
[X] Set up an appropriate development environment (please see CONTRIBUTING.md for this repository)
[X] Create a new branch with a short, descriptive name
[X] Work on this branch

[X] style guidelines have been followed (please see CONTRIBUTING.md for this repository)
[X] new code is commented, especially in hard-to-understand areas
[ ] corresponding changes to documentation have been made
[X] tests for the change have been added that demonstrate the fix or feature works

[X] Test locally with pytest-plus -v non-passing code will not be merged
[ ] Rebase against origin/master
[X] Check changes with linting/formatting tools before submission (please see CONTRIBUTING.md for this repository)
[X] Commit branch
[X] Submit pull request, describing the content and intent of the pull request
[X] Request a code review
[X] Continue the discussion at Pull requests section in the pyan-plus repository

I would lean towards a separate generation script for these examples (or can we generalise the existing script and call it with the folder name as an argument?).

Thanks @peterjc! I will change this afternoon after my meeting.

What happens with the matrices output at the end of a run with this example? Do things work or break? Perhaps that can be a follow up PR...

What happens with the matrices output at the end of a run with this example? Do things work or break? Perhaps that can be a follow up PR...

Do you mean matrixes for bad_alignments example? If so, I haven't yet looked into this. I can do this in the follow up PR. Is that ok?

Thanks @peterjc. Merging now.

authors: kiepczi peterjc

repo: pyani-plus/pyani-plus


text:
Copied Inserters are always blacklist mode

Mod source
Factorio Mod Portal
Which mod are you having an issue with?

[X] pyalienlife
[X] pyalternativeenergy
[X] pycoalprocessing
[X] pyfusionenergy
[X] pyhightech
[X] pyindustry
[X] pypetroleumhandling
[X] pypostprocessing
[X] pyrawores

Operating system

=Windows 10

What kind of issue is this?

[ ] Compatibility
[ ] Locale (names, descriptions, unknown keys)
[ ] Graphical
[ ] Crash
[ ] Progression
[ ] Balance
[ ] Pypostprocessing failure
[ ] Other

What is the problem?
Everytime an Inserter with a filter only on the right slot gets placed by a bot after copying or blueprinting the filter mode is automatically set to blacklisted.
This destroys any multiplied setup relying on whitelisting.
Steps to reproduce

Install the whole py-suite
Start any new game
Place an inserter setup with a whitelist and a filtered item only on the right filter slot
Copy/blueprint the inserter
Place the copy/blueprint
Inserter filters get switched from whitelist to blacklist

Additional context
No response
Log file
No response

I think this is a game problem. Py sets them to blacklist to retain default behavior, and cannot detect if a inserter has been placed by a blueprint.
See discord discussion:
https://discord.com/channels/560199483065892894/567718271823118347/1198240229660839966
and
https://discord.com/channels/560199483065892894/567718271823118347/1198263450921615390
As a workaround, you can make your blueprint with wire and then it does properly copy the setting.

it was an issue with it not proporly checking any other slot then the first for filters. its fixed now as of 2.1.21

authors: Dorus Tindrith kingarthur91

repo: pyanodon/pybugreports

license: Unlicense


text:
PyFluent is broken and not working

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
meshing.workflow gives below error:

and solver = session.solver.root give below one:

📝 Steps to reproduce
Try to run any test using Flute, you will see this issue. This can also be reproduced using Jupyter notebook.
💻 Which operating system are you using?
Windows
🐍 Which Python version are you using?
3.8
📦 Installed packages
python 3.8

FYI @ypatel-qa

It works fine with 22.2

repo: pyansys/pyfluent


text:
Fix URL for broadcasting tx on trest.Bitcoin.com

Currently if the Bitcash SDK tries to send raw transactions to the testnet using the trest.bitcoin.com REST service, it will fail due to an incorrect RESTful path. The commit in this PR adjusts the path to be the correct one.

@teran-mckinney let me know if you have any objections, I'll merge otherwise

Looks good to me! Thank you!

authors: merc1er nicolaiskye teran-mckinney

repo: pybitcash/bitcash


text:
Web App crashes when trying to upload new program to InventorHub.

Behavior:
Web App is able to connect to the Hub. I can start the interactive shell and execute Python code. However, when trying to upload a new Python program, by pressing the "Play-Button", the app crashes. Side note: it crashes most of the time. Some times the upload works and the Python code executes on the Hub.
The enironment works fine for me on Windows (11), but I am currently switching to Fedora Linux where the Software does not work properly any more. Could you kindly assist! Bellow you find further details - if you'd need to know anything else, let me know!
Many thanks!!
Eduard
Hub: InventorHub (flashed with PyBricks Firmware on Windows)
System: Fedora 40 (Web App executes on that system)
Browser: Google Chrom Version 126.0.6478.114 (Official Build) (64-Bit)
Error Text: ChunkLoadError
Stack Trace:
ChunkLoadError
at n.f.j (main.1bf60dfd.js:2:1662589)
at main.1bf60dfd.js:2:1658083
at Array.reduce ()
at n.e (main.1bf60dfd.js:2:1658061)
at 6938.beefce17.chunk.js:1:4061
at N (main.1bf60dfd.js:2:1380738)
at Al (main.1bf60dfd.js:2:1348027)
at wc (main.1bf60dfd.js:2:1336659)
at bc (main.1bf60dfd.js:2:1336631)
at ic (main.1bf60dfd.js:2:1331653)
fs @ main.1bf60dfd.js:2
n.callback @ main.1bf60dfd.js:2
Bi @ main.1bf60dfd.js:2
El @ main.1bf60dfd.js:2
wl @ main.1bf60dfd.js:2
bl @ main.1bf60dfd.js:2
(anonymous) @ main.1bf60dfd.js:2
_c @ main.1bf60dfd.js:2
ic @ main.1bf60dfd.js:2
_ @ main.1bf60dfd.js:2
O @ main.1bf60dfd.js:2
Then after some time:
Failed to load resource: net::ERR_CONNECTION_RESET
An unknown error occurred when fetching the script.
TypeError: Failed to register a ServiceWorker for scope ('https://code.pybricks.com/') with script ('https://code.pybricks.com/service-worker.js'): An unknown error occurred when fetching the script.
(anonymous) @ main.1bf60dfd.js:2
pyodide.asm.js:1

Thanks for reporting! Can you share the program that you're trying to run?

Certainly, it's just a quickly coded snake game using the lights of the Inventor Hub and the Lego Controller (88010). Sorry, it is a bit messy and full of debug statements. The interesting thing: I continued working sending code to my Hub, but I am getting the problem much less often now.
from pybricks.hubs import InventorHub
from pybricks.pupdevices import Remote, Motor, ColorSensor, UltrasonicSensor
from pybricks.parameters import Button, Color, Direction, Port, Side, Stop
from pybricks.robotics import DriveBase
from pybricks.tools import wait, StopWatch, Matrix
from urandom import randint

WIDTH = 5
HEIGHT = 5
SNAKE_HEAD = 1
SNAKE_BODY = 2
DOT = 3
SPEED = 1000
WAIT_BUTTON_PRESSED = 10

# initaliziere Hub und Fernbedienung
hub = InventorHub()
my_remote = Remote()

# Initialize the game state
snake = [(0, 0)]
direction = (0, 1)
dot = (randint(0, WIDTH-1), randint(0, HEIGHT-1))

# Function to draw the game state
def draw(hub, row, col):
    brightness = 0

    if (row, col) in snake:
        if (row, col) == snake[0]:
            # Draw snake head
            brightness = 100
        else:
            # Draw snake body
            brightness = 40
    elif (row, col) == dot:
        # Draw dot
        brightness = 80

    hub.display.pixel(row, col, brightness)

def beep(hub):
    hub.speaker.beep()

beep(hub)
# Get user input
# Check which buttons are pressed.
pressed = my_remote.buttons.pressed()

# Main game loop
while True:
    # Draw the game state
    for row in range(HEIGHT):
        for col in range(WIDTH):
            draw(hub, row, col)

    pressed = my_remote.buttons.pressed()
    steps = int(SPEED/WAIT_BUTTON_PRESSED) + 1
    for i in range(steps):
        if len(pressed) == 0:
            pressed = my_remote.buttons.pressed()
        wait(WAIT_BUTTON_PRESSED)

    # Show the result.
    if Button.RIGHT_MINUS in pressed: # right
        direction = (0, 1)
        print("right")
    elif Button.RIGHT_PLUS in pressed: # left
        direction = (0, -1)
        print("left")
    elif Button.LEFT_PLUS in pressed: # up
        direction = (-1, 0)
        print("up")
    elif Button.LEFT_MINUS in pressed: # down
        direction = (1, 0)
        print("down")

    # Move the snake
    head = snake[0]
    new_head = (head[0] + direction[0], head[1] + direction[1])
    snake.insert(0, new_head)

    # Check if the snake has collided with the wall or itself
    if (
        new_head[0] < 0 or new_head[0] >= HEIGHT or
        new_head[1] < 0 or new_head[1] >= WIDTH or
        new_head in snake[1:]
    ):
        print("Game Over!")
        beep(hub)
        wait(100)
        beep(hub)
        break

    # Check if the snake has caught the dot
    if new_head == dot:
        # Generate a new dot
        dot = (randint(0, WIDTH-1), randint(0, HEIGHT-1))
    else:
        # Remove the tail of the snake
        snake.pop()

SystemExit()

Strangly, it didn't occur anymore - for 30' now.

Maybe strange idea:
Could there be in the current environment more radio interference?
WiFi and Bluetooth can use the same frequencies.

Hmm, actually not that strange.
Lego uses Bluethooth LE, right? BLE could be quite susceptible to radio interference,  and indeed, I had at least 7-8 devices running over WiFi. Thus, this makes total sense.
However, as far as I know are most of them in the 5Gz radio spectrum and not in 2,4Gz anymore, where Bluethooth is sending.

ChunkLoadError

This error has to do with loading .js files that contain part of the web app implementation.  It has nothing to do with Bluetooth.
There was probably a temporary network problem that went away.

For the curious: if you peek behind the scenes you can see the actual .chunk.js files. Likely one of this did not properly download the first time.

@dlech you are right, the issue is not related to the bluetooth connection. I've been running the web app for couple of times and  "This error has to do with loading .js files that contain part of the web app implementation". The problem is that the web site itself seems to have performance issues. When connecting over a browser directly to "https://code.pybricks.com/" it is getting obvious. The application does crash because timeouts occure while fetching component code or similar from the server.
At first it only happened when uploading code to the hub but now I have the problem quite often, even when starting the application. The screen goes white, sometimes the app recovers but very often the "ChunkLoadError" occurs.

Does it persist if you open the page in a new profile or private window? Or likewise, delete the site data and reload?
I wonder if it could continue to fail if it didn't load correctly the first time.
Once loaded properly, it should remain accessible offline.

Yes, this persists if I am clearing the cache as well as using a private window - I've checked the network requests in the developer tool bar. Just for code.pybricks.com every request takes ages to download. My connection to the web seems  fine otherwise.
And once everything is downloaded everything works properly.

Thanks for sharing that. Maybe we should switch to a different host.
Are you able to share which country your accessing it from? I might be able to ask our hosting provider why certain regions are experiencing slow service.
It might also help a lot if we made packaged up the docs so it would be requesting one zip file instead hundreds of small files.

Hi guys,
I have to apologize! The problem occurred due to my network setup. Strangely, only some domains were slow when being accessed. Long story short: I have fixed everything and the connection to PyBricks works perfectly fine now, and thus, the PWA.
Thanks for your support!
Eduard

No worries! I am glad it is working now. Thank you for reporting.

authors: BertLindeman dlech hirsche laurensvalk

repo: pybricks/pybricks-code


text:
Add missing migration for sponsors

因為 Django 說它要有，所以就補上來。

[Current coverage][cc-pull] is 83.92%

Merging [#244][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #244   diff @@
==========================================
  Files            50         50
  Lines          1381       1381
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1159       1159
  Misses          222        222
  Partials          0          0

Powered by Codecov. Last updated by [af9614b...66a0622][cc-compare]
[cc-base-branch]: https://codecov.io/gh/pycontw/pycontw2016/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/pycontw/pycontw2016/compare/af9614bff8628657c8f6f026ad878a4e073b43c4...66a0622ba63d89b6cfcfa74f7b342f4df55c5045
[cc-pull]: https://codecov.io/gh/pycontw/pycontw2016/pull/244?src=pr

authors: codecov-io uranusjr


text:
Fix bug in get_attr where properties are inaccessible when pydantic_extra is populated

Change Summary
Fixes an issue where __get_attr__ for BaseModel prioritizes pydantic_extra over general attributes resulting in an inability to access class properties when any extra fields are present.
The fix is to only prioritize pydantic_extra if the attribute name is actually present in the extra keys; otherwise, just go straight to attempting to access the attribute with getattr()
Related issue number
fix #9862
Checklist

[ ] The pull request title is a good summary of the changes - it will be used in the changelog
[ ] Unit tests for the changes exist
[ ] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Could you please share an example of what currently doesn't work? The added test already passes on main.

Could you please share an example of what currently doesn't work? The added test already passes on main.

Yup, thanks for pointing this out. I attempted to simplify down my real-world repro case but got too simple! This test should actually reproduce the issue; will update the PR later:
class Model(pydantic.BaseModel):
    model_config = pydantic.ConfigDict(extra='allow')

    columns: List[str]

    @property
    def queried_columns(self) -> List[str]:
        return [c for c in self.columns if c.startswith('query')]

class SubModel(Model):
    pass

instance = SubModel.model_validate(
    dict(
        columns=['query_1', 'query_2', 'other'],
        test='extra_value',
    ))

# These have always worked
assert instance.queried_columns == ['query_1', 'query_2']
assert instance.__getattribute__('queried_columns') == ['query_1', 'query_2']

# This only works with the fix
assert instance.__getattr__('queried_columns') == ['query_1', 'query_2']

You shouldn't call Model.__getattr__ manually. When doing instance.queried_columns, Python will first call object.__getattribute__ which takes care of calling the queried_columns property's __get__ method (because properties are non-data descriptors). Please refer to this section of the documentation to understand how __getattribute__ works.
If it raises an AttributeError, Python will call our BaseModel.__getattr__, which we implemented only to enable access to private/extra attributes/values. This way, doing inst.test works: __getattribute__ raises an AttributeError because test is not in the instance's __dict__, and Python falls back to BaseModel.__geattr__ which implements the logic to look up in __pydantic_extra__.

You shouldn't call Model.__getattr__ manually. When doing instance.queried_columns, Python will first call object.__getattribute__ which takes care of calling the queried_columns property's __get__ method (because properties are non-data descriptors). Please refer to this section of the documentation to understand how __getattribute__ works.
If it raises an AttributeError, Python will call our BaseModel.__getattr__, which we implemented only to enable access to private/extra attributes/values. This way, doing inst.test works: __getattribute__ raises an AttributeError because test is not in the instance's __dict__, and Python falls back to BaseModel.__geattr__ which implements the logic to look up in __pydantic_extra__.

I'm only calling it manually in an attempt to illustrate the bug here. This issue is cropping up in real code that does not call getattr directly, I'm simply trying to recreate it in a concise test case. This is the error I'm getting in my real code, as you can see all I'm doing is accessing the property queried_columns and this error shows up:
  File "org/grafana/tools/convert_to_sift.py", line 219, in <module>
    convert_to_sift(dashboard)
  File "org/grafana/tools/convert_to_sift.py", line 36, in convert_to_sift
    if not query.queried_columns:
  File "/home/jmassucco/devel/monorepo/dist/export/python/virtualenvs/python-default/3.8.16/lib/python3.8/site-packages/pydantic/main.py", line 850, in __getattr__
    raise AttributeError(f'{type(self).__name__!r} object has no attribute {item!r}') from exc
AttributeError: 'TimescaleQuery' object has no attribute 'queried_columns'

I'm happy to share more of my code here to help get to the bottom of this, but I am quite confident there is a real bug somewhere here and I believe this was closed prematurely

Sorry, I got confused because your example shows that instance.queried_columns can be accessed. Do you happen to have an example that would lead to the AttributeError in your convert_to_sift function, when accessing queried_columns?

Sorry, I got confused because your example shows that instance.queried_columns can be accessed. Do you happen to have an example that would lead to the AttributeError in your convert_to_sift function, when accessing queried_columns?

Yeah my apologies - I am trying to work up a test case that can reproduce. My code that does reproduce is (a) quite complicated and (b) closed source, so it is a bit challenging to distill down my real failure case into something I can put in a test case. But I will work on it some more tonight and get back to you ASAP. Appreciate you reopening, looking forward to getting to the bottom of this

@Viicos I constructed a test case based on my actual failure reproduction and pulled all the various dependencies into a single python file and dropped in a gist: https://gist.github.com/jmassucco17/b291ea6bc99676d571d13f1b7789414a
Running this reproduces the error I'm seeing. Interestingly, it totally depends on string contents of raw_sql field input to the model! Empty string doesn't reproduce, the real string (a bunch of SQL) does reproduce. But there are 1000s of other queries that I'm able to parse with no trouble so there's something specific about this one that is causing an issue...

@Viicos I constructed a test case based on my actual failure reproduction and pulled all the various dependencies into a single python file and dropped in a gist: https://gist.github.com/jmassucco17/b291ea6bc99676d571d13f1b7789414a
Running this reproduces the error I'm seeing. Interestingly, it totally depends on string contents of raw_sql field input to the model! Empty string doesn't reproduce, the real string (a bunch of SQL) does reproduce. But there are 1000s of other queries that I'm able to parse with no trouble so there's something specific about this one that is causing an issue...

I progressively went through and deleted text from the SQL and was able to get a surprisingly simple version to repro; it's surprising because the repro case is now so simple that I'm kind of shocked that I haven't run into this more... there must be something I'm not seeing

OK I was able to narrow it down to an unguarded AttributeError from within the sql_metadata library that pydantic is claiming as its own.
The attribute error happens when we hit this line with the "bad" SQL: https://gist.github.com/jmassucco17/b291ea6bc99676d571d13f1b7789414a#file-repro-py-L189
I modified my code to directly access the parsed_sql.tables attribute of the instance and I get this error string:
Traceback (most recent call last):
  File "astranis/grafana/models/repro.py", line 283, in <module>
    example_instance.parsed_sql.tables
  File "/home/jmassucco/devel/monorepo/dist/export/python/virtualenvs/python-default/3.8.16/lib/python3.8/site-packages/sql_metadata/parser.py", line 345, in tables
    with_names = self.with_names
  File "/home/jmassucco/devel/monorepo/dist/export/python/virtualenvs/python-default/3.8.16/lib/python3.8/site-packages/sql_metadata/parser.py", line 451, in with_names
    token.next_token_not_comment.normalized
AttributeError: 'NoneType' object has no attribute 'normalized'

So I'm not sure if I would say this is a pydantic bug... but it does seem weird that pydantic is capturing and masking an AttributeError from another module like this. Do you think this is intended behavior, or something that could/should be handled more clearly?

Closing this in favor of #10821 which has a more clear description of the issue and a more clear test case. I no longer feel confident that the fix I had proposed here is appropriate. Appreciate your help, @Viicos !

repo: pydantic/pydantic


text:
Addition of two DateOffsets

It is convenient to be able to add one DateOffset to another one:
from pandas.tseries.offsets import DateOffset as DO
DO(hour=2) + DO(hour=3) # raises ValueError

Currently it is not supported. Note that DateOffsets basically replicates the functionality of relativedeltas from dateutil module which support addition
from dateutil.relativedelta import relativedelta as RD
RD(hour=2) + RD(hour=3) # yields relativedelta(hour=3)

In [17]: Timestamp('20130101') + DO(hour=2) + DO(hour=3)
Out[17]: Timestamp('2013-01-01 03:00:00')

These do not form composite objects. I suppose they could, but not sure if it has a useful case as these can operate directly on Series/Timestamps.
@aickley pls show the utility here.

This would be useful when 1) offsets are defined at a different place from where there are used and 2) when offsets are defined relative to each other. For instance, currently I have some code conceptually similar to
# Parameters of a study
predictors_window_bdays = 3
predictors_window_end = DateOffset(...) # offset from an event
predictors_window_start = predictors_window_start - DateOffset(bdays=predictors_window_bdays)
# response_window_{bdays,start,end} defined similarly

# The code where the real work is done
# events is a DatetimeIndex()
x = predictors.ix[events+predictors_window_end] - predictors.ix[events+predictors_window_start]
y = response.ix[events+response_window_end]  - response.ix[events+response_window_start]
# analyze the relationship between x and y

Now it is not possible to specify predictor_window_end corresponding to, say, 12:00 of a business day preceding the day of the event (in my view the most intuitive syntax for that would be DateOffset(bdays=-1, hour=12) as suggested in #10903). Additionally, it is not possible to define predictor_window_start relative to predictor_window_end using an intuitive syntax described above.
As a workaround, I am currently storing lists of DateOffsets that are being applied to the index one after the other.

This is currently not allowed because adding anything to a BusinessDays (except other business days) is not defined without an absolute reference point. E.g. if you had Timestamp('20130101 11:59:59) + BDay(1) + Second(1) it is clear what to do.
But if you have BDay(1) + Second() then these have to be kept (and applied) independently.
So aside from BusinessHours which I think could be added to a BuisinessDay I don't think this is really possible.
I'll leave it open for you to provide a reasonable proof-of-concept.

For non-business days I suppose these could be combinable as Timedeltas are.
e.g.
Day() + Hour() -> DateOffset(days=1,hours=1)

Ok, I understand that BDays is not a time unit and hence it's very different from Hour, Minute etc. That being said, in principle, DateOffset can have a bdays offset independent from the other components. When such an extended DateOffset is applied to a date the only ambiguity is whether offsetting by business days or usual time units is done first.
Apart from that, combining BDay with absolute time of the day (BDay() + DateOffset(hour=12, minute=1)) is a transparent operation which is very useful when looking at intraday financial time series.
BTW, surprisingly enough, now one can combine BDay and Second
In [33]: delta = BDay() + Second()
In [34]: (pandas.DatetimeIndex(['2015-08-24']) - delta)[0]
Out[34]: Timestamp('2015-08-21 00:00:01')

and the result is different from the direct application
In [35]: (pandas.DatetimeIndex(['2015-08-24']) - BDay() - Second())[0]
Out[35]: Timestamp('2015-08-20 23:59:59')

which is clearly a bug.

@aickley It's not so clear to me that's a bug, because offsets are not necessarily associative.
The way addition of a delta on BDay works right now is that the offset remains a BusinessDay - the additional delta is applied at the last step without regard to sign/count on the offset.
E.g:
In [5]: delta = pd.offsets.BDay() + pd.offsets.Hour()
In [6]: delta
Out[6]: <BusinessDay: offset=Timedelta('0 days 01:00:00')>

In [9]: pd.Timestamp('2015-1-1') + delta
Out[9]: Timestamp('2015-01-02 01:00:00')

In [10]: pd.Timestamp('2015-1-1') + 2 * delta
Out[10]: Timestamp('2015-01-05 01:00:00')

In [11]: pd.Timestamp('2015-1-1') - 2 * delta
Out[11]: Timestamp('2014-12-30 01:00:00')

This definition actually makes sense if your think of the delta as an 'anchored' offset - that is, 1:00 on each business day.  But it may be less surprising of the sign/count propagated to the additional delta and that maybe could be changed.  It is a bit ambiguous / surprising.
In any case, I'm not seeing why you can't just apply multiple offsets to your data?  That would avoid any ambiguity.

Yeah I think this has been disallowed specifically as it raises a TypeError now and due to https://github.com/pandas-dev/pandas/issues/10902#issuecomment-135006454 probably not easy to support so closing

authors: aickley chris-b1 jreback mroeschke

repo: pydata/pandas


text:
TST: Fix test for datetime categorical

Related to #10465, but different part.
Current test_groupby_datetime_categorical in test_groupby.py is incorrect, the actual result returns CategoricalIndex as level 0, otherwise expected result uses DatetimeIndex as level 0. Changed to use the same dtype and added explicit comparison.
Actual Result (current test case)
levels = pd.date_range('2014-01-01', periods=4)
codes = np.random.randint(0, 4, size=100)
cats = pd.Categorical.from_codes(codes, levels, name='myfactor', ordered=True)
data = pd.DataFrame(np.random.randn(100, 4))
grouped = data.groupby(cats)
desc_result = grouped.describe()
desc_result.index.get_level_values(0)
# CategoricalIndex([2014-01-01T09:00:00.000000000+0900,
#                  ...
#                   2014-01-04T09:00:00.000000000+0900],
#                  categories=[2014-01-01 00:00:00, 2014-01-02 00:00:00, 2014-01-03 00:00:00, 2014-01-04 00:00:00],
# ordered=True, name=u'myfactor', dtype='category')

Expected Result (current test case)
It must be CategoricalIndex.
idx = cats.codes.argsort()
ord_labels = np.asarray(cats).take(idx)
ord_data = data.take(idx)
expected = ord_data.groupby(ord_labels, sort=False).describe()
expected.index.names = ['myfactor', None]
expected.index.get_level_values(0)
# DatetimeIndex(['2014-01-01', '2014-01-01', '2014-01-01', '2014-01-01',
#               ...
#               '2014-01-04', '2014-01-04', '2014-01-04', '2014-01-04'],
#               dtype='datetime64[ns]', name=u'myfactor', freq=None, tz=None)

lgtm, merge when ready

Thanks, merging.

authors: jreback sinhrks


text:
Fix landmark-unique error due to in-page TOC

Fixes #1478.
🔗  Link to PR preview: https://pydata-sphinx-theme--1607.org.readthedocs.build/en/1607/

Thanks for the suggestions @trallard! I applied them

Here's the URL for the page that was added: https://pydata-sphinx-theme--1607.org.readthedocs.build/en/1607/examples/in-page-toc.html

Great CI is green and all looks good so we can merge.

authors: gabalafou trallard

repo: pydata/pydata-sphinx-theme


text:
Auto-generated API documentation

For instance in http://xarray.pydata.org/en/stable/generated/xarray.apply_ufunc.html, there is no space between the parameters and their type description, e.g. funccallable instead of func : callable.

Thanks see #3056

Thanks.

authors: davidbrochart dcherian

repo: pydata/xarray


text:
dB Parameters in dsp.spectrogram

General

pyfar version: 0.23

It was suggested to remove the dB parameters from dsp.spectrogram and only have them in plot.spectrogram. Do we want this and how would we handle the broken backwards compatability.

Until merging pull request #256 into develop the dB parameter had no effect for dsp.spectrogram, right?
So, I would consider it as a bugfix to just remove it from dsp.spectrogram and only have a dB parameter for plot.spectrogram.

Good point! We already merged #256 and decided to make this a separate issue and Pull request. But since we only merged into Develop we could still do that. Is every one fine with Simon's suggestion?

authors: f-brinkmann sikersten

repo: pyfar/pyfar


text:
Physically-Based Rendering system

Try to implement Physically-Based Rendering system.
Related & depend #309
Accomplished:

Add a PBR material MeshStandardMaterial,  support:

matelness & roughness_map
roughness & roughness_map
emissive_map & emissive_intensity
normal_map & normal_scale
ao_map & ao_map_intensity
env_map & env_map_intensity (for IBL)
...

Physically-Based Lighting
IBL ( Image-Based Lighting )
Examples: physically_base_rendering.py, physically_base_rendering2.py

Run the examples to see the specific effects.
Todo:

Refactoring this under the new architecture (#315 )
Add support for some other PBR attributes (light_map, bump_map, etc.)
Consider better APIs
Code clean

Wow!! 😳

wow indeed!

authors: Korijn almarklein panxinmiao

repo: pygfx/pygfx


text:
Bug: L/R Arrow Keys do not move Caret to ends of selection correctly

Bug
Actual Behavior
Precondition: A selection is active:

Arrow Key
Actual Action
Example Image

Left
Deselect & move caret 1 character leftward from right side of selection

Right
Deselect & move caret 1 character rightward from right side of selection

Expected behavior
Precondition: A selection is active:

The expected behavior depends on which arrow key is pressed:

Arrow Key
Expected Action
Example Image

Left
Deselect & move caret to the left side of the selection

Right
Deselect & move caret to the right side of the selection

The following should not affect this behavior:

The direction of the initial selection
The length of the initial selection

System Information
python -m pyglet.info output as a gist
How to Reproduce

Make sure you have a recent branch cloned (e.g. master or #931)
cd into the pyglet repo directory
Make sure your install + dev dependencies are up to date: pip install -I -e .[dev]
python examples/gui/widgets.py
Perform the tests in the Actual Behavior section

The fix may be to add checks for an active selection in these lines:
https://github.com/pyglet/pyglet/blob/f830d034d7c7367a89b3e57e74fb1a38855138b9/pyglet/text/caret.py#L461-L470
This issue is up for grabs since I need to take a look at #931, #928, and shader mocks.

Update: This behavior is ancient, not just something Apple or browsers standardized on recently. The following 25+ year old systems seem to follow this convention:

Notepad on Windows 3.1
A 1986 build of Microsoft Word for Mac

repo: pyglet/pyglet


text:
[ENH] xlsx_cells

PR Description
Please describe the changes proposed in the pull request:

read in xlsx file without coercing into rectangle form
each cell is assigned a row with relevant information (row number, column number, cell formatting, ...)
updates to xlsx_table and read_commandline
doctests added for xlsx_table and xlsx_cells

This PR resolves #929 .

PR Checklist

Please ensure that you have done the following:

[ ] PR in from a fork off your branch. Do not PR from <your_username>:dev, but rather from <your_username>:<feature-branch_name>.

[ ] If you're not on the contributors list, add yourself to AUTHORS.rst.

[ ] Add a line to CHANGELOG.md under the latest version header (i.e. the one that is "on deck") describing the contribution.

Do use some discretion here; if there are multiple PRs that are related, keep them in a single line.

Automatic checks
There will be automatic checks run on the PR. These include:

Building a preview of the docs on Netlify
Automatically linting the code
Making sure the code is documented
Making sure that all tests are passed
Making sure that code coverage doesn't go down.

Relevant Reviewers

Please tag maintainers to review.

@ericmjl

🚀 Deployed on https://deploy-preview-1046--pyjanitor.netlify.app

something is broken in jinja, which is affecting mkdocs. Looks like a PR to fix it will soon be merged on Jinja's end.

authors: ericmjl samukweku

repo: pyjanitor-devs/pyjanitor


text:
Chapter3: posterior_grid_approx function

Should the function posterior_grid_approx have the prior as
prior = np.repeat(1, grid_points)  # uniform
The solution has the prior as
prior = np.repeat(5, grid_points)  # uniform

The actual value does not matter, if you compute the posterior as proportional to the likelihood * prior, you will be changing the constant of proportionality, but the relative posterior values will be the same. If instead you normalize the posterior, then the normalization will take into account the 1 or 5 factor.
If you really want the prior to be a valid pmf then instead of 1 it should be np.repeat(1/grid_points, grid_points), so the sum will be 1.
1/grid_points

@sushmit86 I mean this in the kindest way. Try changing the value in the code and see what happens :)

Thanks so much. I had thought so the prior should not matter

I think the problem is not with does it work, but that a prior is a probability distribution which should have an area under the curve of 1 and not 5.

repo: pymc-devs/resources


text:
Resolve private type aliases?

Private type aliases should not appear in the docs. Replace them with their expanded value.

Resolved by #133.

repo: pyodide/sphinx-js-fork


text:
Fix finding library files

Since setuptools 63.3.0, pillow couldn't be built anymore, see https://github.com/python-pillow/Pillow/issues/6471
This was broken after refactoring: https://github.com/pypa/setuptools/commit/25dcca2902780146a1ee298f18648334eb3cddff
I am now directly creating the PR here as discussed in https://github.com/pypa/setuptools/pull/3476

closed as it's fixed now in https://github.com/pypa/distutils/commit/f700a6b5f9965b3a886827d523271a2c9388edb5

repo: pypa/distutils


text:
pipenv --three fails

Issue description
Running pipenv --three throws 'TypeError: 'NoneType' object is not iterable'
Expected result
Pipenv to be initialized with python three
Actual result
pipenv --three fails and throws an error. A log file will be included as the error is quite long.
log.txt
Steps to replicate
Run pipenv --three

$ pipenv --support
Pipenv version: '2018.11.14'
Pipenv location: '/usr/lib/python3.7/site-packages/pipenv'
Python location: '/usr/bin/python'
Python installations found:
Traceback (most recent call last):
File "/usr/bin/pipenv", line 11, in
load_entry_point('pipenv==2018.11.14', 'console_scripts', 'pipenv')()
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in call
return self.main(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
rv = self.invoke(ctx)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1114, in invoke
return Command.invoke(self, ctx)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args, **kwargs)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
return f(get_current_context(), args, **kwargs)
File "/usr/lib/python3.7/site-packages/pipenv/cli/command.py", line 142, in cli
get_pipenv_diagnostics()
File "/usr/lib/python3.7/site-packages/pipenv/help.py", line 33, in get_pipenv_diagnostics
python_paths = finder.find_all_python_versions()
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/pythonfinder.py", line 122, in find_all_python_versions
python_version_dict = getattr(self.system_path, "python_version_dict")
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/pythonfinder.py", line 54, in system_path
ignore_unsupported=self.ignore_unsupported,
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 451, in create
ignore_unsupported=ignore_unsupported,
File "<attrs generated init 75e45f144e3d5510d54dd5fca6730b98fa0220a9>", line 38, in init
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 116, in attrs_post_init
self._setup_pyenv()
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 196, in _setup_pyenv
version_glob_path="versions/", ignore_unsupported=self.ignore_unsupported
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 154, in create
sort_function=sort_function, version_glob_path=version_glob_path)
File "<attrs generated init 4cb48a43d6709d3a578ba9505d6f7e6efcc13cef>", line 17, in init
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 98, in get_versions
for p in self.get_version_order():
File "/usr/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 70, in get_version_order
version_order = [versions[v] for v in parse_pyenv_version_order()]
TypeError: 'NoneType' object is not iterable

Thanks for reporting, I believe it is fixed in master branch, can you have a try?

Tried the master branch, still produces the same error.
$ pipenv --support
Pipenv version: '2018.11.15.dev0'
Pipenv location: '/home/solarliner/.local/lib/python3.6/site-packages/pipenv'
Python location: '/usr/bin/python3'
Python installations found:
Traceback (most recent call last):
  File "/home/solarliner/.local/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.15.dev0', 'console_scripts', 'pipenv')()
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 1114, in invoke
    return Command.invoke(self, ctx)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/cli/command.py", line 142, in cli
    get_pipenv_diagnostics()
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/help.py", line 33, in get_pipenv_diagnostics
    python_paths = finder.find_all_python_versions()
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/pythonfinder.py", line 122, in find_all_python_versions
    python_version_dict = getattr(self.system_path, "python_version_dict")
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/pythonfinder.py", line 54, in system_path
    ignore_unsupported=self.ignore_unsupported,
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 451, in create
    ignore_unsupported=ignore_unsupported,
  File "<attrs generated init 75e45f144e3d5510d54dd5fca6730b98fa0220a9>", line 38, in __init__
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 116, in __attrs_post_init__
    self._setup_pyenv()
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/path.py", line 196, in _setup_pyenv
    version_glob_path="versions/*", ignore_unsupported=self.ignore_unsupported
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 154, in create
    sort_function=sort_function, version_glob_path=version_glob_path)
  File "<attrs generated init d1562b3dd8a63d3504f390eb8f2d396673d146ac>", line 17, in __init__
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 98, in get_versions
    for p in self.get_version_order():
  File "/home/solarliner/.local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 70, in get_version_order
    version_order = [versions[v] for v in parse_pyenv_version_order() if v in versions]
TypeError: 'NoneType' object is not iterable

At least on my system pyenv doesn't have the file ~/.pyenv/version. Both pipenv and pyenv installed using Homebrew.

parse_pyenv_version_order should return [] instead of None when pyenv version order file does not exist.

A workaround is to to create pyenv version file such as by pyenv global system until fix is released.

I just tried that @jxltom and got:
  File "/usr/local/Cellar/pipenv/2018.11.14/libexec/lib/python3.7/site-packages/pipenv/vendor/pythonfinder/models/python.py", line 70, in <listcomp>
    version_order = [versions[v] for v in parse_pyenv_version_order()]
KeyError: 'system'

Using a version number works.  pyenv global 3.7.1

For using pyenv global system, you have to use pipenv master branch, sorry for the trouble.
Yeah, pyenv global 3.7.1 or an empty version file will work for latest released pipenv. :smile:

After pipenv installed the version of python in my Pipfile I got this error:
Warning: The Python you just installed is not available on your PATH, apparently.

However running pyenv rehash and pipenv sync --dev again results in the creation of my virtualenv in the correct python version.

@rgant  Are your sure 3.7.1 is installed by pyenv indeed?
And can you show output of pipenv --three --verbose? So it will be easier to debug.

Sorry @jxltom I'm trying to get something done ASAP and don't really have time to assist with debugging tonight. All of my pythons are installed by pyenv. And I didn't make it clear that while 3.7.1 was a python already installed, my Pipfile specified a different version 3.6.4.
 These are the commands I ran tonight after setting the global pyenv version.
$ pipenv sync --dev
Warning: Python 3.6.4 was not found on your system…
Would you like us to install CPython 3.6.4 with pyenv? [Y/n]: Y
Installing CPython 3.6.4 with pyenv (this may take a few minutes)…
✔ Success!
python-build: use openssl from homebrew
python-build: use readline from homebrew
Downloading Python-3.6.4.tar.xz...
-> https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tar.xz
Installing Python-3.6.4...
python-build: use readline from homebrew
Installed Python-3.6.4 to /Users/rgant/.pyenv/versions/3.6.4

Warning: The Python you just installed is not available on your PATH, apparently.
$ pyenv rehash
$ ls -la /Users/rgant/.pyenv/v*
-rw-r--r--  1 rgant  staff  6 Nov 18 21:45 /Users/rgant/.pyenv/version

/Users/rgant/.pyenv/versions:
total 0
drwxr-xr-x  4 rgant  staff  128 Nov 18 21:45 .
drwxr-xr-x  5 rgant  staff  160 Nov 18 21:43 ..
drwxr-xr-x  6 rgant  staff  192 Nov 18 21:47 3.6.4
drwxr-xr-x  6 rgant  staff  192 Nov  6 16:16 3.7.1
$ echo $PATH
./node_modules/.bin:/Users/rgant/.rbenv/shims:/Users/rgant/.pyenv/shims:/Users/rgant/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:.
$ pipenv sync --dev
Creating a virtualenv for this project…
Pipfile: ./Pipfile
Using /Users/rgant/.pyenv/versions/3.6.4/bin/python3 (3.6.4) to create virtualenv…
✔ Complete
Using base prefix '/Users/rgant/.pyenv/versions/3.6.4'
New python executable in /Users/rgant/.local/share/virtualenvs/blah-TBr8V2Mx/bin/python3
Also creating executable in /Users/rgant/.local/share/virtualenvs/blah-TBr8V2Mx/bin/python
Installing setuptools, pip, wheel...
done.
Running virtualenv with interpreter /Users/rgant/.pyenv/versions/3.6.4/bin/python3
Virtualenv location: /Users/rgant/.local/share/virtualenvs/blah-TBr8V2Mx
Installing dependencies from Pipfile.lock (12f483)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 46/46 — 00:00:12
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
All dependencies are now up-to-date!

@rgant Thanks, it is already very helpful

Hello @rgant and @iboyperson and the others discussing this issue. I've read through the comments on this issue and a host of other issues for pipenv and other Python tools and I'm still not sure how we are supposed to resolve this problem. For reference, if I run pipenv locally on my Ubuntu 16.04 development machine, everything works correctly. However, if I try to run pipenv on Travis CI then I cannot find a way to ensure that the builds pass correctly. Specifically, on Travis CI I always see this error message:
TypeError: 'NoneType' object is not iterable

Here are the relevant portions of the travis.yml configuration file that I am using:
# use the Python 3.6 language
language: python
python:
  - "3.6"

# ignore the virtualenv that Travis creates
# setup a secure login to CodeCov
env:
  global:
    - PIPENV_VENV_IN_PROJECT=1
    - PIPENV_IGNORE_VIRTUALENVS=1
    - LANG=en_US.UTF-8
    - LC_ALL=en_US.UTF-8
    - secure: hnWlE/s8Vo+OM+Vz2p60+/jmMoGwnIdpVg2OUnu269TJYapPG+qF6ks1jYpb/XfRucfndZSZXy4UZfJnzf082hoQmAUGHm3yrRTDkrsGGK1bxea3Rhwj1bn8IrjcZqOAQAtpCsnhFbzrdRTtng8+PCBcYyru+IG6jwOrOv2EMe/CBVLNvSoRdtBgcz4QKl2SRsLhEQh+pjgZiUEY+d7mNfyhGzCD8xS4abj8KfNfKDIZfKHX9E1mvBuZm9GQC17wvLyOt0j4gtEZeoGLGF63fuLvMqZhpZh00lJ6wmSD9vTok7pqgpErR1yrzZmVDrD61bz0PL/b8kHjOLLd0HcOw9q0D0KPX5BojOJxVKglc8GaAI4CksnMmjfLjieZRMag8K8qI8lKkIiD/AABAjqwHJ0Ywm7ru42alY163y4ieatXDMBQpoLsSn1P4gs0LDvGe6Kby+jeM8nL8y+5L5qGTODnqYDHes0rHVMIXQAr7HLKyru6/Bwzz8woYr8WjBmTd1UxLtFcfSYr8Rj+Yklldz4Wt1p4Wnpj9Hd5S2eVLXeteTBKA4y/tFSenZTke+NlVK8zmHa06yVHTbLf14ggTe4hZgUM/mLXRnVFy73LyaBPQkDQpvc6HELMxj94z5OZ6DpDrESDDxVnGq3H876qiJfi/rMFAkTbtgeMu4MRbow=

# install mdl for checking Markdown
before_install:
  - gem install mdl

# command to install dependencies
install:
  - pip install --upgrade pip
  - pip install --upgrade pipenv
  - pipenv install --dev --three

# send emails when there is a change or failure
notifications:
  email:
    on_success: change
    on_failure: always

# use a cache to improve performance
cache: pip

# set GATORGRADER_HOME environment variable
before_script:
  - export GATORGRADER_HOME="/home/travis/build/gkapfham/gatorgrader"

# perform testing:
# --> run the test suite with pytest
# --> lint the functions with flake8
# --> lint the test suites with flake8
# --> lint the functions with pylint
# --> lint the test suites with pylint
# --> lint the README documentation with mdl
script:
  - pipenv run pytest --cov-config pytest.cov --cov
  - pipenv run flake8 tests*
  - pipenv run flake8 gatorgrader*
  - pipenv run pylint tests
  - pipenv run pylint gator
  - mdl README.md

# report coverage information to CodeCov
after_success:
  - pipenv run codecov

I should note that I have also tried things like, for instance, using Python 3.6-dev and not including the setting of the LANG and LC_ALL environment variables (which was suggested in the pipenv issue tracker sometime in 2017, if I recall correctly). The above Travis CI configuration worked throughout all of the past summer and is only now not working when I was changing my Pipfile and Pipfile.lock because of the fact that GitHub detected a security vulnerability in the requests version that I was using.
Can anyone please advise me on how to update my .travis.yml file so that I can again use pipenv? I really appreciate any assistance that you can provide! Thanks in advance!

https://github.com/pypa/pipenv/issues/3247#issuecomment-439755945

an empty version file will work for latest released pipenv.

This is the only solution that worked for me.

Hi @maxim-belkin! I saw that point earlier, but, honestly, I do not know why there is a need to specify an empty version file when I am using Python on Travis CI. I see that pyenv uses this version file in its root. Is it the case that Travis CI uses pyenv to install Python versions? (I don't see that in the documentation) Is what you are suggesting a temporary workaround until a pipenv issue is fixed? Or, is this the new standard way to use pipenv? Any follow-on tips that you can provide would be greatly appreciated. As my schedule permits, I will try more alternatives this week and report back on what seemed to work correctly.

I think there is a bug in pipenv and it expects that file to exist. Specifying anything in that file did not work for me.
Compare the version of pipenv that you have on your computer and on Travis. You probably have a "slightly outdated" (not the very latest) version of pipenv on your local machine whereas Travis installs the latest one. I think if you do pip install -U [--user] pipenv locally, you'll start getting the same error :)

While I acknowledge that this issue was already closed, I thought that I should write to confirm that the issue has been resolved for me. All of my builds on Travis CI and locally are now working correctly. Thanks for releasing a new version of pipenv that resolves the problem!

@gkapfham Thanks for your information, it helps a lot.

authors: SolarLiner frostming gkapfham iboyperson jxltom maxim-belkin rgant

repo: pypa/pipenv