Install Dependencies with Composer failed

TASK: [wordpress-sites | Install Dependencies with Composer] ******************
failed: [default] => (item={'site_install': True, 'admin_user': 'admin', 'site_name': '.........dev', 'local_path': '../..........dev', 'system_cron': True, 'multisite': {'enabled': False}, 'site_title': 'Example Site', 'user': 'vagrant', 'env': {'db_name': 'example_dev', 'wp_env': 'development', 'db_user': 'example_dbuser', 'db_password': 'example_dbpassword', 'wp_home': 'http://.........dev', 'wp_siteurl': 'http://.............dev/wp'}, 'site_hosts': ['.......dev'], 'group': 'www-data', 'admin_email'<EMAIL_ADDRESS>'admin_password': 'admin'}) => {"changed": true, "cmd": ["composer", "install"], "delta": "0:00:00.056822", "end": "2015-01-29 08:13:55.281499", "item": {"admin_email"<EMAIL_ADDRESS>"admin_password": "admin", "admin_user": "admin", "env": {"db_name": "example_dev", "db_password": "example_dbpassword", "db_user": "example_dbuser", "wp_env": "development", "wp_home": "http://........dev", "wp_siteurl": "http://........dev/wp"}, "group": "www-data", "local_path": "../........dev", "multisite": {"enabled": false}, "site_hosts": ["...........dev"], "site_install": true, "site_name": ".........dev", "site_title": "Example Site", "system_cron": true, "user": "vagrant"}, "rc": 1, "start": "2015-01-29 08:13:55.224677", "warnings": []}
stdout: Composer could not find a composer.json file in /srv/www/......dev/current
To initialize a project, please create a composer.json file as described in the http://getcomposer.org/ "Getting Started" section

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
           to retry, use: --limit @/Users/als/site.retry

default                    : ok=61   changed=30   unreachable=0    failed=1

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

@heyalbert how did you solve this? having the same exact problem...

@heyalbert I'm also having this issue.  Please let us know how you solved this.  Thanks in advance for sharing!

@heyalbert what's your group_vars/development look like? This is erroring on development right?

Having the some problem here. Any solutions yet?

Development server using vagrant. Too obvious maybe, but have you confirmed that the composer.json is where you expect on the dev server? (e.g., using vagrant ssh, cd /srv/www/example.dev/current and ll -- that path assumes site_name: example.dev in group_vars/development)
If composer.json is not in that directory, and the other bedrock contents aren't either, it suggests a problem with the vagrant sync folder (syncs your bedrock project folder into vagrant vm). In this case, you could review whether your site_name and local_path definitions from group_vars/development will work with the config.vm.synced_folder logic in the Vagrantfile. To be safe, avoid using spaces or unusual characters in site_name and local_path.
Staging/Production server on remote host. The bedrock contents, including composer.json, won't be on the server the first time you run the site.yml playbook. See composer-related discussion in #84, #30, #135 etc.

Solved for me. My problem was that github.com wasn't among known_hosts and that I install som packages from there. Adding github.com to known hosts for root in the box solved my problem.

What @fullyint covers this issue so I'm locking this.


Consider multistage Docker building

It's explained here: https://blog.alexellis.io/mutli-stage-docker-builds/
Idea is to build Orienteer in one image and use FROM jetty for second main image which will go to repository

Implemented. Started from commit 47648e3804a5a262ac92d2d594be14ebfa8e0d68


Editor mode for marking surveyed areas

Absence of amenities does not mean the area was not surveyed. Add a fourth mode (or an overlay?) to mark surveyed areas. E.g. as level 7 geohashes (~70 m).

No. No server part, and this mode is useless, since mapping in infinite.


nonce support for defer inline scripts

Because security please :)

Looks like this is a React issue as well: https://github.com/facebook/react/issues/26026
But Deferred will need these as well I think.

Still relevant.

I'm hitting this issue too. I wasn't successful in writing any tests for <Scripts />+<Await /> (JS beginner, sorry) so unfortunately can't make a PR but a tweak to https://github.com/remix-run/remix/pull/359/files to pass the  props down through the internal DeferredHydrationScript seems to solve this issue and #5539, in case it gives someone else a head-start here.


#5800: Updated cli document, with the rebuilding ecosystem info.

Document updated with rebuild ecosystem info

tagging @jakecoffman to review


Add example of testing for Worker/Wrapper transformation

This was the way that I thought to do it. Happy to hear if there's a better way, but otherwise thought it might be a useful example

Thanks! Looks reasonable at first. Does this test actually pass, though? (The name “bad” fold doesn’t sound like it would).

Ah, sorry, bad naming! In my head, this example was for passing around monoid-ish dictionaries that are law-violating (thus 'bad'). Will rename.
It does indeed pass (and fails when optimisations are off)

Ok, no imagine to be a first-time user of inspection-testing, and you are browsing the example. Probably you don't imediatelly see which transformation is happening here that you want to check for. Care to add a few lines of comments, explaining the transformation that is happening, and why this test would detect it?
With that I’ll happily merge this :-)

Docs added

Thanks!

I am not sure why CI didn't run on the PR, but it seems stuff broke: https://travis-ci.org/github/nomeata/inspection-testing/jobs/667586556
Can you take a look?


Rethinking MonadError - new blog post

A new blog post about MonadError and its usability. Would love to hear some feedback or proofreading
:)

Thanks for the contribution, but I think you based it on the master branch. Please cherry-pick your commit on development and force push, so that these bot commits disappear in this PR.
On 14 April 2018 21:31:51 EEST, Luka Jacobowitz<EMAIL_ADDRESS>wrote:

A new blog post about MonadError and its usability. Would love to hear
some feedback or proofreading
:)
You can view, comment on, or merge this pull request online at:
https://github.com/typelevel/typelevel.github.com/pull/203
-- Commit Summary --

Update site at Sun, 09 Oct 2016 20:48:07 +0000
Update site at Sun, 09 Oct 2016 20:56:00 +0000
Update site at Sun, 09 Oct 2016 21:01:13 +0000 based on
ba05a0c6cd12107e92152584640744cd378abf27
Update site at Sun, 09 Oct 2016 21:27:37 +0000 based on
dcc7e1169b8b423c7cb5b173eb7d0b50db83c3bb
Update site at Mon, 10 Oct 2016 20:33:28 +0000 based on
1c0daad66dc70d6c2b24828ca01c39b3d0324deb
Update site at Mon, 10 Oct 2016 21:26:09 +0000 based on
47f87048eab6704cb435a0801b545fd0eaff7ddb
Update site at Wed, 12 Oct 2016 18:14:44 +0000 based on
c66e83a1e340df1e6f0af1d1399e997894d6a25a
Update site at Wed, 12 Oct 2016 19:51:32 +0000 based on
19854a800ce9869ce6ca8521ed54046ee30e923c
Update site at Sat, 15 Oct 2016 19:12:34 +0000 based on
5ac9651af95e6b1c10ebc33a38ac0bccb8f2b6ea
Update site at Sun, 16 Oct 2016 08:48:27 +0000 based on
952c4bf66de236867f01a23b3ab7a68af5e86b1e
Update site at Sun, 16 Oct 2016 11:04:59 +0000 based on
c9f4c42ad2ec4519b1ce15b945aeab80789650ee
Update site at Sun, 16 Oct 2016 11:19:01 +0000 based on
20eac903c9688b80dab4342183caed2bf781f73b
Update site at Mon, 17 Oct 2016 06:32:44 +0000 based on
cff05b2968a5494b5bfd83d4560e831cf696410b
Update site at Mon, 17 Oct 2016 16:26:21 +0000 based on
dea0e519d553b9e017d8323dacfc018f8ceb6b9f
Update site at Wed, 19 Oct 2016 04:59:52 +0000 based on
4616b501a98f32a26ad4df268a95ad42ff9a2c38
Update site at Mon, 24 Oct 2016 16:34:05 +0000 based on
aa2dcdcf0b595594bac2101b179f4e9abcf54ba1
Update site at Mon, 24 Oct 2016 16:46:40 +0000 based on
0e83d13c63a6010949091696aafd63982df378df
Update site at Wed, 26 Oct 2016 18:08:23 +0000 based on
52ee31191cb34a7aa82a0f385faf6332f7832057
Update site at Sun, 13 Nov 2016 23:05:29 +0000 based on
b190f72aca75b26bb248af5f1afc6befc34e69c9
Update site at Wed, 16 Nov 2016 22:10:20 +0000 based on
b48f723a1a43badf99c9b0439a8b691fb6d59d2a
Update site at Thu, 17 Nov 2016 09:34:18 +0000 based on
55b55bbdd92384720838eb4ff51ca6782738ab7c
Update site at Thu, 17 Nov 2016 19:32:36 +0000 based on
2b9b42464c83d3d4b56aed4a14833f58b7e49dba
Update site at Fri, 25 Nov 2016 07:49:10 +0000 based on
f041d4a25e7a745e8b415eb1ec24071695e9c699
Update site at Sun, 04 Dec 2016 12:15:50 +0000 based on
9e7a093f72bd0b7a99679c78fa50d00e68187d19
Update site at Sat, 10 Dec 2016 20:12:49 +0000 based on
84ed42cad376f16aeff4cf69cf1574fafc0075c6
Update site at Sat, 17 Dec 2016 05:24:12 +0000 based on
1cad7a5b87f4c8c36b5ab25c337b4c2d8c4b5cde
Update site at Fri, 06 Jan 2017 12:48:39 +0000 based on
56f7783b7c37132a47844095157c9595858148ad
Update site at Fri, 06 Jan 2017 12:53:32 +0000 based on
4df3a7c4f796128132ff3002574a6c444a378c3d
Update site at Thu, 12 Jan 2017 07:12:18 +0000 based on
a7fac44ae346e82246487abff8fca17373f52931
Update site at Thu, 12 Jan 2017 20:02:00 +0000 based on
c6f0a9189b8eb0ab0b556ef7192093a1ef287916
Update site at Thu, 12 Jan 2017 20:03:04 +0000 based on
9fb3669a91145f0b4ca0ffdb30791a3e01d87397
Update site at Sun, 15 Jan 2017 09:46:24 +0000 based on
bef21b9e1ac2eef9d367dcbc9c3335017dbcae3f
Update site at Tue, 17 Jan 2017 17:30:19 +0000 based on
389b9745f3917711150fb108fd20eb87f893b7ec
Update site at Tue, 17 Jan 2017 18:38:16 +0000 based on
133bbf86a072c827a36d8a47c1a28d4a79af6bc2
Update site at Thu, 26 Jan 2017 20:21:30 +0000 based on
e8bb8c134451cbf9ad2c6e06b875c760c61ed292
Update site at Thu, 26 Jan 2017 20:22:49 +0000 based on
8a1d35986b9cf952a80ceddfb9f1e5ac99d0f4d8
Update site at Mon, 30 Jan 2017 15:29:27 +0000 based on
a0adc62ff3f309d8bfed01f836c81ce288d3a2f6
Update site at Mon, 30 Jan 2017 21:11:10 +0000 based on
0f5d0504a37248530d6dfa4d8237d27d792128bf
Update site at Mon, 30 Jan 2017 21:11:37 +0000 based on
e436c9305dff584fdd94101e2433a9f82bf3c6f9
Update site at Mon, 30 Jan 2017 22:07:02 +0000 based on
f790f64c27920bf8821cc252279dc1a55eecdb52
Update site at Sat, 04 Feb 2017 09:26:20 +0000 based on
63a96c4b4c319c54235d4442d3e199893be53459
Update site at Sat, 04 Feb 2017 14:37:16 +0000 based on
67d31e7fcbab8686dd367b411f699b20910ff9b8
Update site at Tue, 07 Feb 2017 20:16:34 +0000 based on
89a8525ab8e6a78eba341e2fba20cfc151c0578f
Update site at Mon, 13 Feb 2017 14:40:46 +0000 based on
821d814a9317ecf9aad8ac2d1fba674cd4816f04
Update site at Mon, 13 Feb 2017 14:48:56 +0000 based on
1f53f2c73f9a81447fa1cc4a612f1230b7fb9e77
Update site at Tue, 14 Feb 2017 07:50:16 +0000 based on
da37fefc34a40b580433cd95a46b558f9295e7ff
Update site at Sat, 25 Feb 2017 20:51:29 +0000 based on
7e020b66e2ad090d42aff9fd73766425219363d7
Update site at Mon, 27 Feb 2017 12:32:35 +0000 based on
e76292b5a1882f1b101c05c6bc22db4a0af7bede
Update site at Wed, 01 Mar 2017 01:35:42 +0000 based on
b251e367f018fa11bbcdd4210d28d12cce4d8c25
Update site at Wed, 01 Mar 2017 01:52:15 +0000 based on
fce6a0363a952f63356a80d362fafa95c80a1b12
Update site at Wed, 01 Mar 2017 11:25:29 +0000 based on
b251e367f018fa11bbcdd4210d28d12cce4d8c25
Update site at Thu, 02 Mar 2017 01:49:34 +0000 based on
a4eb3f1e24c6e59e43a7ee930a7413ee8b14736b
Update site at Sat, 04 Mar 2017 00:34:57 +0000 based on
714e9cf253f35532a6612ded9844f3ee11286424
Update site at Mon, 06 Mar 2017 08:02:06 +0000 based on
a1f9b89d1d31a2e4bca258de40313f564cb9689c
Update site at Wed, 08 Mar 2017 20:06:38 +0000 based on
cc055bb1676e6080364cfca5755c05b590b1b20c
Update site at Wed, 08 Mar 2017 21:38:44 +0000 based on
a79e15b0f81df2b8d50576c8b525e3520be15543
Update site at Tue, 14 Mar 2017 13:16:18 +0000 based on
d6d8ecff212f906ce4371703887f2f72c9a94a8e
Update site at Fri, 17 Mar 2017 16:43:12 +0000 based on
4958375a60f3b256eb899ce5bb0e5ed332d14b61
Update site at Sun, 19 Mar 2017 16:15:22 +0000 based on
f29fa3983c24893c9a3fc89c98dcc65e7982ff31
Update site at Mon, 20 Mar 2017 09:46:00 +0000 based on
c7e12c84bd118b838e9232438cb8b6668c5ecb5d
Update site at Mon, 20 Mar 2017 20:34:50 +0000 based on
b5a49a4f9bd5b1d09c99c7087ca91a697fa6a480
Update site at Wed, 22 Mar 2017 21:18:57 +0000 based on
74f036d67a3c878a00c4b87265d9c6d12d1bd636
Update site at Wed, 22 Mar 2017 21:54:51 +0000 based on
a8c9fd217d21bfa276d32edd982b3d72313f3298
Update site at Wed, 22 Mar 2017 22:07:53 +0000 based on
89473cf2e5a26b0029511bfdedb8faf2c30b863f
Update site at Wed, 22 Mar 2017 22:37:38 +0000 based on
e54cce9353be25f09da07feeabf676627ae525e1
Update site at Wed, 22 Mar 2017 22:53:23 +0000 based on
a45ae33405cbc853cb0778714d3bc4e35ded8992
Update site at Wed, 22 Mar 2017 22:58:52 +0000 based on
f666bca5c9c9ba01b42eab610dd09a5df1bd82e3
Update site at Thu, 23 Mar 2017 08:49:56 +0000 based on
597fe45eac33205b7652491006f608dc9aa80313
Update site at Thu, 23 Mar 2017 12:13:42 +0000 based on
6edabf97d7b91983f47579de0cb7df609a08c007
Update site at Thu, 23 Mar 2017 17:34:47 +0000 based on
84e2fdce8dc6dfdd583253a093c1dca0982ce9db
Update site at Sat, 25 Mar 2017 10:16:09 +0000 based on
d008d28c8ab4cf95ee8c9feca56cd8c57710696b
Update site at Sun, 02 Apr 2017 13:24:19 +0000 based on
45ac1de8d2742a058133bb693999de1990907b7d
Update site at Tue, 04 Apr 2017 20:50:36 +0000 based on
15bea93cc65d82ee7963e22a52fc82f9a6aaf7c2
Update site at Wed, 05 Apr 2017 18:10:35 +0000 based on
f68ea4418d85c5a1427fb8a0e5e4d95efee59bca
Update site at Sat, 08 Apr 2017 19:54:11 +0000 based on
898d619725faa556071b7158b7d43cf2e62d0be6
Update site at Wed, 12 Apr 2017 13:02:02 +0000 based on
1e29f09ad012cc8c0a93b558752898affd2c6a4e
New mathjax CDN (#163)
Update site at Fri, 14 Apr 2017 11:30:07 +0000 based on
862d8c7e41f9354ca243a16d608b6261eeb9d8fe
Update site at Fri, 21 Apr 2017 19:55:04 +0000 based on
8bac428965cb096ca7ad907ea870540c99ad0a55
Update site at Sat, 22 Apr 2017 07:39:38 +0000 based on
657d9389d0c6f6ba15970ae0cb113c039cbb044a
Update site at Sat, 22 Apr 2017 07:39:51 +0000 based on
7f42c7855ff9fba402cd0b316c62be758d59833c
Update site at Sun, 23 Apr 2017 17:37:35 +0000 based on
0b24900cf79d9198e7f3b4c525ca978b27aa3baf
Update site at Sun, 30 Apr 2017 09:49:26 +0000 based on
3e42ead7763954511071235cd1ef79ab47f9f2d2
Update site at Sun, 30 Apr 2017 13:51:37 +0000 based on
902fb9fcae92700fcd7f80da198239a4a90e4421
Update site at Sun, 30 Apr 2017 15:32:09 +0000 based on
5a78fdebef5e186ceade6e8d9874aeb00eb5e9f9
Update site at Sun, 30 Apr 2017 16:11:50 +0000 based on
547412c3c8d5f1902d940ba8de75126a0269b7b6
Update site at Sun, 30 Apr 2017 16:35:17 +0000 based on
09c50524282d49246cffdaeb656f11514570afa1
Update site at Mon, 01 May 2017 14:56:42 +0000 based on
9ce6271dd10fccebd99d4b21902d522970247589
Update site at Mon, 01 May 2017 15:17:49 +0000 based on
41d9272de2117e09a33ac0cc24acca11ec2938a8
Update site at Fri, 05 May 2017 13:53:49 +0000 based on
896e56205d2c5b69206f7cef68ac2b433cc7ba7b
Update site at Wed, 10 May 2017 20:53:17 +0000 based on
7095dc2332456604a5f3be20f5b5b5636abbd7b2
Update site at Fri, 12 May 2017 17:48:23 +0000 based on
dd9efdfbeb3405f4cb3a8a4414d64c966688bc2d
Update site at Sat, 13 May 2017 10:32:53 +0000 based on
b3f78f22d6aedcfa7b6dba34e713be2f4a26e1b9
Update site at Sat, 20 May 2017 04:05:43 +0000 based on
97227339d2e1f038649689f8cb660680372e9ba6
Update site at Tue, 23 May 2017 15:39:21 +0000 based on
6ec4313b7429d6ff72aa65b2e860108f5ad3103e
Update site at Tue, 23 May 2017 15:41:04 +0000 based on
5c25d53a905ce4081abcbea183983afc0526d640
Update site at Sun, 28 May 2017 09:22:26 +0000 based on
a36baf4b06d4c404616234b6bb9f3773e3dd5ffb
Update site at Sun, 28 May 2017 15:29:47 +0000 based on
930353a078a2fbabc7c28425a032b68fbdcb2ea0
Update site at Mon, 29 May 2017 06:56:26 +0000 based on
8f2bb8634ae76f194b8ce777f73245ec6bce9c93
Update site at Tue, 30 May 2017 06:18:04 +0000 based on
b0b532bbeff6b3567e73a5dc0b88e01dce3f4512
Update site at Thu, 01 Jun 2017 21:02:03 +0000 based on
5873d2b4e2ce9bae225d52539a1c0bb718a20822
Update site at Fri, 02 Jun 2017 22:23:52 +0000 based on
a615ac32d7d9160a5d83845142dfc5fedf3afa34
Update site at Mon, 05 Jun 2017 13:34:16 +0000 based on
4cf0c94f95f7f97ee440ea3464e0a4dfafadfacd
Update site at Mon, 05 Jun 2017 14:36:04 +0000 based on
86f06191767e1049e82e0519007a0cedd77db0c8
Update site at Thu, 15 Jun 2017 09:29:55 +0000 based on
773671bb2bf52ec5cbeeab3750cbc9d7831bfee6
Update site at Tue, 20 Jun 2017 19:10:06 +0000 based on
32bc6c7c6cf96fc0a403a63cd32a0794f7beba84
Update site at Thu, 22 Jun 2017 05:44:24 +0000 based on
5b32e2639ee313b6802dfce8e210a725f3514db1
Update site at Thu, 22 Jun 2017 05:51:07 +0000 based on
dcf49b5d5c9e27ba6f9189c944393c837b683fc8
Update site at Thu, 06 Jul 2017 05:25:16 +0000 based on
f8db9df61d49f8fda90f478376e2cd6a05946f98
Update site at Fri, 28 Jul 2017 21:12:46 +0000 based on
f8065ee6cbbebf730dbfeb444bf3119d014687aa
Update site at Sat, 29 Jul 2017 11:01:17 +0000 based on
24906176d31dec2c51db98a374f7b9fd6f0f03ec
Update site at Thu, 03 Aug 2017 21:31:28 +0000 based on
a3736eb1e803c31d89c645ee93fe5a9cf8de43fd
Add new monaderror blog post

-- File Changes --
M .gitignore (5)
M .travis.yml (29)
M Gemfile (2)
A LICENSE (21)
M README.md (30)
M _config.yml (2)
M _data/authors.yml (144)
M _data/incubator.yml (72)
M _events/2016-05-04-summit-oslo.md (2)
M _events/2016-09-14-lake-district-workshop.md (4)
M _events/2016-09-30-conf-cadiz.md (36)
A _events/2016-11-12-hackday.md (40)
A _events/2016-12-10-scalaxhack.md (48)
A _events/2017-01-21-hackday.md (40)
A _events/2017-03-23-summit-nyc.md (175)
A _events/2017-06-03-summit-copenhagen.md (134)
M _includes/conduct.html (2)
A _includes/license.html (4)
M _layouts/event.html (7)
M _layouts/page.html (4)
M _layouts/post.html (4)
M _posts/2013-06-24-deriving-instances-1.md (37)
M _posts/2016-09-21-edsls-part-1.md (3)
M _posts/2016-09-30-subtype-typeclasses.md (8)
A _posts/2016-10-17-minicheck.md (773)
A _posts/2016-10-18-scala-center.md (43)
A _posts/2016-10-26-edsls-part-2.md (450)
A _posts/2016-11-17-heaps.md (347)
A _posts/2016-12-17-scala-coc.md (17)
A _posts/2017-02-13-more-types-than-classes.md (727)
A _posts/2017-03-01-four-ways-to-escape-a-cake.md (594)
A _posts/2017-04-02-equivalence-vs-equality.md (280)
A _posts/2017-05-02-io-monad-for-cats.md (416)
A _posts/2017-06-13-libra.md (521)
A _posts/2017-06-21-ciris.md (502)
A _posts/2017-08-04-cats-1.0-mf.md (99)
A _projects/eff.md (9)
D _projects/ensime.md (7)
A _projects/frameless.md (7)
A _projects/monix.md (8)
M _projects/shapeless.md (3)
M about.html (26)
M blog/feed.rss (13)
M blog/index.html (2)
A build.sbt (34)
M contributors.md (3)
M css/main.scss (9)
A deploy.sh (30)
M events/index.html (2)
D gulpfile.js (67)
A img/logo-spreadshirt.png (0)
A img/logo-stickermule.png (0)
M img/logo-twitter.png (0)
M img/logo-twitter.svg (143)
M img/logo.png (0)
M img/logo.svg (32)
A img/media/cats-effect-diagram.png (0)
A img/media/copenhagen-thumb.jpg (0)
A img/media/copenhagen.jpg (0)
A img/media/london-thumb.jpg (0)
A img/media/london.jpg (0)
A img/media/nyc-thumb.jpg (0)
A img/media/nyc.jpg (0)
A img/media/speakers/andreamagnorsky.jpg (0)
A img/media/speakers/zainabali.jpg (0)
A img/media/sponsors/cake.jpg (0)
A img/media/sponsors/data-monsters.png (0)
A img/media/sponsors/driver.png (0)
A img/media/sponsors/giphy.png (0)
A img/media/sponsors/iheartradio.png (0)
A img/media/sponsors/meetup.png (0)
A img/media/sponsors/rally.png (0)
A img/media/sponsors/scalac.png (0)
A img/media/sponsors/signify.png (0)
A img/media/sponsors/soundcloud.png (0)
A img/media/sponsors/tapad.png (0)
A img/media/sponsors/weight_watchers.png (0)
M index.html (8)
D package.json (17)
A posts/2013-04-04-inauguration.md (37)
A posts/2013-06-24-deriving-instances-1.md (304)
A posts/2013-07-07-generic-numeric-programming.md (387)
A posts/2013-09-11-using-scalaz-Unapply.md (306)
A posts/2013-10-13-spires-ops-macros.md (314)
A posts/2013-10-13-towards-scalaz-1.md (252)
A posts/2013-10-18-treelog.md (193)
A posts/2013-11-17-discipline.md (184)
A posts/2013-12-15-towards-scalaz-2.md (186)
A posts/2014-01-18-implicitly_existential.md (235)
A posts/2014-02-21-error-handling.md (256)
A posts/2014-03-09-liskov_lifting.md (279)
A posts/2014-04-14-fix.md (330)
A posts/2014-06-22-mapping-sets.md (140)
A posts/2014-07-02-type_equality_to_leibniz.md (192)
A posts/2014-07-06-singleton_instance_trick_unsafe.md (305)
A posts/2014-09-02-typelevel-scala.md (74)
A posts/2014-09-20-higher_leibniz.md (363)
A posts/2014-11-10-why_is_adt_pattern_matching_allowed.md (363)
A posts/2015-02-26-rawtypes.md (395)
A posts/2015-07-13-type-members-parameters.md (232)
A posts/2015-07-16-method-equiv.md (354)
A posts/2015-07-19-forget-refinement-aux.md (160)
A posts/2015-07-23-type-projection.md (168)
A posts/2015-07-27-nested-existentials.md (398)
A posts/2015-07-30-values-never-change-types.md (299)
A posts/2015-08-06-machinist.md (433)
A posts/2015-08-07-symbolic-operators.md (181)
A posts/2015-09-21-change-values.md (589)
A posts/2015-12-11-announcement_summit.md (50)
A posts/2016-01-14-summit_assistance.md (47)
A posts/2016-01-20-summit_keynote.md (21)
A posts/2016-01-28-existential-inside.md (163)
A posts/2016-01-28-summit_programme.md (65)
A posts/2016-02-04-variance-and-functors.md (508)
A posts/2016-03-13-information-hiding.md (322)
A posts/2016-03-24-typelevel-boulder.md (26)
A posts/2016-05-10-internal-state.md (365)
A posts/2016-08-21-hkts-moving-forward.md (333)
A posts/2016-09-19-variance-phantom.md (380)
A posts/2016-09-21-edsls-part-1.md (83)
A posts/2016-09-30-subtype-typeclasses.md (385)
A posts/2016-10-17-minicheck.md (718)
A posts/2016-10-18-scala-center.md (43)
A posts/2016-10-26-edsls-part-2.md (450)
A posts/2016-11-17-heaps.md (347)
A posts/2016-12-17-scala-coc.md (17)
A posts/2017-02-13-more-types-than-classes.md (716)
A posts/2017-03-01-four-ways-to-escape-a-cake.md (0)
A posts/2017-04-02-equivalence-vs-equality.md (0)
A posts/2017-05-02-io-monad-for-cats.md (0)
A posts/2017-06-13-libra.md (0)
A posts/2017-06-21-ciris.md (0)
A posts/2017-08-04-cats-1.0-mf.md (0)
A posts/2018-04-13-rethinking-monaderror.md (0)
A project/build.properties (0)
A project/plugins.sbt (0)
M projects/index.html (0)
A src/main/scala/FrontMatter.scala (0)
A src/main/scala/Main.scala (0)
A src/main/scala/Post.scala (0)
A src/main/scala/YAML.scala (0)
A src/main/scala/package.scala (0)
-- Patch Links --
https://github.com/typelevel/typelevel.github.com/pull/203.patch
https://github.com/typelevel/typelevel.github.com/pull/203.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/typelevel/typelevel.github.com/pull/203

Oops, yeah, I dun goofed, sorry!


Allow enabling experimental features via env var

Summary of the new feature / enhancement
In CI, if someone wants to use an experimental feature, it currently is inconvenient to write to the powershell.config.json file before pwsh starts and then potentially set it back if the container instance is being reused.  Instead, it would be convenient to have pwsh also read from a env var like POWERSHELL_EXPERIMENTAL_FEATURES which is a comma separated list of the names of experimental features to enable.
The env var would override powershell.config.json for experimental features.
Proposed technical implementation details (optional)
No response

Maybe enhance Get-ExperimentalFeature cmdlet to generate the string for follow copy-paster.

I don't see a problem with this

Given the narrow purpose of this variable, I would suggest that it should be "hidden" with "__" prefix.

Once upon a time we breathed a sigh of relief when Registry appeared in Windows and replaced a huge number of configuration files and environment variables. The positive effect was terrific.
It's amazing to see that it's not being ported and there's not even a sign of it. :-(

Is there any chance that this could make it to a release of PowerShell 7.2? I'm very curious about how an upgrade path will be laid out so that PowerShell won't break CI system when the PSNativeCommandArgumentPassing feature is enabled by default on CI systems like Github actions.
Being able to enable this feature on 7.2 via environment variable would make it easier to piece by piece migrate scripts to this feature...

@krokofant that's a good use case and something that could be considered since it's opt-in

In CI, if someone wants to use an experimental feature, it currently is inconvenient to write to the powershell.config.json file before pwsh starts and then potentially set it back if the container instance is being reused.

Can you please provide an example to show how inconvenient it is today?
Take Az Pipeline as an example, every -pwsh: | step runs in a new pwsh process, so you can set experimental features at the first -pwsh: | step, then the -pwsh: | steps after that will run in the pwsh processes with that experimental feature enabled. In the end, the last pwsh: | step can restore the experimental features, so the build agent will still have the original experimental feature settings.
This doesn't seem very cumbersome to me ...

@daxian-dbw container images get reused sometimes w/o resetting them, so you would need to backup the existing config, if the config is modified, you may want to retain those settings, so you would need to modify the config file rather than clobber it, then restore everything back.  Certainly a worse case scenario, but this is exactly the scenario that was reported to me internally at Msft.

the WG discussed this and weren't quite clear on the scenario, so a little elaboration would be helpful. We also suggested that a parameter to pwsh might be just as effective and reduce the expansion of the environment. There is also a concern about being able to remove the variable(s) from within PS (we think that the way dotnet removes environment variables is to just set them to an empty string, so clearing them from pwsh and then invokign might lead to ambiguity between no experimental features and use the standard config file.
If an environment variable approach was accepted, we also suggested that we should follow the DOTNET_SettingNameHere for each experimental feature (rather than a list)

A parameter on pwsh isn't as easily used in CI where pwsh is not called directly by the yaml.  Within PS, you'd remove them as any env var by setting it to $null, so not sure how it's different here.  Having individual env vars would be fine as well as long as experimental feature names don't allow for whitespace.

The @PowerShell/wg-powershell-engine discussed this again and before committing engineering effort on this, we would like to have a good discussion on how this should work take place, especially with regard to interaction of environment variables with settings found in the config.json file. It has been an issue for us in the past, so having a discussion before the engineering takes place of the behavior would be prudent.


merge do sync 2

first commit
v1.1.0
fix typedefs
v1.1.1
work out what the weird type issue was, and test for it
v1.2.1
add coverage minimum
allow undefined in JSON
v1.4.1
expand on typescript defs
update dist
v2.1.0
fix bug where throwing proc.error would just throw undefined
fix ENOBUFS
update footguns and example
add error handling support
v3.0.1
ignore coverage
v3.0.2
guess i still havent worked out how to remove coverage lmao
Testing workflow (#4)
Bump hosted-git-info from 2.8.8 to 2.8.9 (#5)
bump to 3.0.3
upgrade some shit (#6)
Create SECURITY.md (#7)
v3.0.4
Bump ws from 7.4.5 to 7.4.6 (#8)
automatically merge security updates (#9)
Bump path-parse from 1.0.6 to 1.0.7 (#11)
Bump tar from 6.1.0 to 6.1.8 (#12)
v3.0.5 (#13)
auto release (#14)
delete automerge security (#15)
v3.0.6 (#16)
validate yaml (#17)
delete error log (#18)
v3.0.7 (#19)
v3.0.8 (#20)
test before publish (#21)
npm auth token (#22)
v3.0.9 (#23)
upgrade, v3.0.10 (#24)
v3.0.11: remove coverage (#25)
Create LICENSE (#26)
dependabot automerge (#27)
Bump tmpl from 1.0.4 to 1.0.5 (#29)
Bump tar from 6.1.8 to 6.1.11 (#28)
Bump version to 30.0.12
CI: auto bump version on dependabot change (#30)
upgrade deps (#31)
v3.0.13 (#32)
Add permission 'pull-request: write' for dependabot (#34)
dependabot automerge (#36)
Actually set up correct permissions this time... (#37)
allow merge commits for dependabot (#38)
Revert "allow merge commits for dependabot (#38)" (#39)
Bump simple-get from 3.1.0 to 3.1.1
Bump minimist from 1.2.5 to 1.2.6
Bump package version (#40)
Bump package version (#40) (#41)
ci: version bump to v3.0.15
always bump version (#42)
ci: version bump to v3.0.16
Revert to just publishing on releases (#43)
v3.0.17
Bump version and fix release flow
v3.1.0
v3.1.1
hopefully it works this time
😳
Bump sharp from 0.29.2 to 0.30.5
prepare for merging into monorepo - move into ts/do-sync
(do-sync) move ts folders into root
move doSync test to conform with monorepo format
(do-sync) remove files that are un-necessary in the monorepo
make package.json package.template.json (package.json is generated in the monorepo)
(do-sync) blast all these dotfiles that keep fucking me up
(do-sync) create testing directory
Duplicate ../cmd/svgshot/BUILD history in . history.
Duplicate BUILD history in testing history.
Duplicate ../cmd/svgshot/version history in . history.
Duplicate ../cmd/svgshot/.api.lock history in . history.
Duplicate ../cmd/svgshot/.version.lock history in . history.

Testing this change via switching the entry point to doSync.ts shows that the current way api-extractor works has issues with files importing each other. I am unsure what the root cause of that issue is, however.


devsite: add github.com/golang/protobuf to google.golang.org/protobuf migration guide

Is there a document anywhere that describes how to upgrade a v1 project to a v2 project? There is a blog post, however it isn't comprehensive. I tried searching both in this repository and in https://github.com/protocolbuffers/protobuf-go.
Currently, I'm running into this error, and I'm unsure how to resolve it. (I can open this specific instance as a separate issue. However, were an upgrade guide to exist, I presume that it would describe how to address the problem I'm running into.)
httputil/httputil.go:18:24: cannot use &pb.Empty literal (type *pb.Empty) as type protoreflect.ProtoMessage in argument to Respond:
	*pb.Empty does not implement protoreflect.ProtoMessage (missing ProtoReflect method)

I am attempting to regenerate protobuf files using the new protoc-gen-go however the generated file is identical to the old file so I'm unsure what I'm missing.

Ah, the new file is being written to a different location. I'll open another ticket.

That's an odd error. Is pb.Empty the same one as "github.com/golang/protobuf/ptypes/empty".Empty or "google.golang.org/protobuf/types/known/emptypb".Empty?

No it's a custom struct. I opened a separate ticket for that issue at #1076.

Another issue I hope an upgrade guide would cover is how or whether utility functions like ptypes.TimestampProto are being migrated.

whether utility functions like ptypes.TimestampProto are being migrated.

You'd be interested in https://go-review.googlesource.com/c/protobuf/+/225298

I'd also be interested in a migration document and status on things like ptypes. Switching imports to "google.golang.org/protobuf/proto" was seamless , but protoc-gen-go still generates pb.go files that reference v1 imports, and I don't see any new FileOptions in https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/descriptor.proto or new parameters to protoc-gen-go that would force v2 generation, so my projects all have the v1 and v2 libs in them now.

The migration plan for the well-known types is still being worked on. https://go-review.googlesource.com/c/protobuf/+/225298 generates first-class support for well-known types directly into the generated packages.

Colleagues, the ptypes.MarshalAny and ptypes.UnmarshalAny methods did not migrate to google.golang.org/protobuf, but they remained in the example and now it’s not clear how to unmarshal any on a struct.

Colleagues, the ptypes.MarshalAny and ptypes.UnmarshalAny methods did not migrate

You are correct. In the v1.20.0 release notes, there are several portions of the old API that do not yet have an equivalent replacement in the google.golang.org/protobuf module:

Some existing features present in the github.com/golang/protobuf module are currently unavailable in this module:

Manipulation of the wire format: The older module provides functionality for directly manipulating the raw wire format through methods on the proto.Buffer type.
Helper functions for well-known types: The older module provides the ptypes package containing helper functions for interacting with the well-known types such as Any or Timestamp messages.

We plan to add these features to this module in the near future and improve upon them.

A moral replacement for proto.Buffer was released in v1.21.0 with the protopack package. However, helpers for the well-known types are still not migrated and being worked on presently. It is okay to keep using ptypes for the time being.

Thank you, @dsnet!
Do you need my help?


Visual Studio Test v 2.* fails if no test sources found (used to work a few days ago with just a warning)

I have a generic task group for some of my projects in which some of them have tests and others don't.
Now every time I try to build a project with no tests asseblies the build task fails.
Previously the task would give me a warning, which was OK for me.
Is this something you've just changed in the latest version? can you put it back? or just add an option to not fail the task?
##[debug]Agent.Version=2.155.1
##[debug]Release.ReleaseUri=undefined
##[debug]Release.ReleaseId=undefined
##[debug]Build.BuildUri=vstfs:///Build/Build/2383
##[debug]Build.Buildid=2383
##[debug]telemetry area: TestExecution feature: TestExecutionTask data: {"builduri":"vstfs:///Build/Build/2383","buildid":"2383","state":"completed"}
##[debug]Processed: ##vso[telemetry.publish area=TestExecution;feature=TestExecutionTask;]{"builduri":"vstfs:///Build/Build/2383","buildid":"2383","state":"completed"}
##[error]Error: Preparing the test sources file failed. Error : Error: No test sources found matching the given filter '*test*.dll,!*TestAdapter.dll,!\obj**'
##[debug]Processed: ##vso[task.issue type=error;]Error: Preparing the test sources file failed. Error : Error: No test sources found matching the given filter '*test*.dll,!*TestAdapter.dll,!\obj**'
##[debug]task result: Failed
##[error]VsTest task failed.
##[debug]Processed: ##vso[task.issue type=error;]VsTest task failed.
##[debug]Processed: ##vso[task.complete result=Failed;done=true;]VsTest task failed.
Finishing: VsTest - testAssemblies

@gonzaloluna Thank you for the feedback.
Since this is more geared towards the product team, please move the issue to the azure-pipelines-tasks repo.

Closing the issue, please comment below if there any questions.


DNS jitter

Please provide a description of this PR:
#52877
I know we said to put it within a feature flag, but we can do the same thing by setting the env var to 0.
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ ] Ambient
[ ] Configuration Infrastructure
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ x] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@Stevenjin8: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

Do I need docs on istio.io?

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test release-notes

lint_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test release-notes

lint_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test lint

gencheck_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test lint

gencheck_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test gencheck

release-notes_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
f761a6ed5a1f7f8881287b2f3345a6d3498ae77a
link
true
/test lint

release-notes_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test release-notes

gencheck_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test release-notes

gencheck_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test gencheck

lint_istio
8ce1afdefca5ddd291d1b881d6a4c3037d4dc4f9
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.


asc: relax error

Motivation for this change
Noticed the failure in Hydra: https://hydra.nixos.org/build/140096606
Things done
removed "narrowing" error
Needs testing for the game itself.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 118118 at 06926a42 run on x86_64-linux 1

1 package built successfully:

asc

2 suggestions:

warning: build-tools-in-build-inputs
zip is a build tool so it likely goes to nativeBuildInputs, not buildInputs.
Near pkgs/games/asc/default.nix:18:3:
   |
18 |   buildInputs = [
   |   ^

warning: build-tools-in-build-inputs
pkg-config is a build tool so it likely goes to nativeBuildInputs, not buildInputs.
Near pkgs/games/asc/default.nix:18:3:
   |
18 |   buildInputs = [
   |   ^


Removing extra colon in README.md's proxy.auth

Coverage increased (+1.5%) to 93.687% when pulling 0104ad6c64c6d29cdbd801f923868994d6bf4f0a on TomyJaya:TomyJaya-patch-1 into 5630d3be55cd591cd279927616f895356a10a361 on mzabriskie:master.


Test using hidden inputs

Hello! I'm trying to test a Live page with a form with a LiveSelect component. The LiveSelect provides a component with a hidden input with value, but when I try using the fill_form or submit_form to pass the arguments, I get the following error:
######### Test #############
 form_attrs = %{
        symbol: "PETR",
        category: "stock",
        symbol_text_input: "PETR4",
        price: "12.50",
        quantity: 100,
        open_date: "2024-04-01",
        direction: "short"
      }

      conn
      |> visit("/strategy-builder")
      |> submit_form("#position_form", position: form_attrs)
      |> open_browser()

####### Error ##########
 test/myield_web/live/strategy_builder_live/index_test.exs:5
     ** (ArgumentError) value for hidden "position[symbol]" must be one of [""], got: "PETR"
     code: |> submit_form("#position_form", position: form_attrs)
     stacktrace:
       (phoenix_live_view 0.20.9) lib/phoenix_live_view/test/live_view_test.ex:1102: Phoenix.LiveViewTest.call/2
       (phoenix_test 0.2.7) lib/phoenix_test/live.ex:127: PhoenixTest.Driver.PhoenixTest.Live.submit_form/3
       test/myield_web/live/strategy_builder_live/index_test.exs:19: (test)

Is there a way to test with hidden inputs in the form?

Hi @revoltaxz, thanks for opening this issue!
I think I see why your form is failing, and I think it's something we should fix.
The problem
PhoenixTest uses LiveViewTest's render_submit/2 helper for LiveView form submissions.
From the docs we can see:

To submit a form along with some with hidden input values:
assert view
       |> form("#term", user: %{name: "hello"})
       |> render_submit(%{user: %{"hidden_field" => "example"}}) =~ "Name updated"

But right now, we're passing all the form data to form/3 -- so we use render_submit/2 without passing hidden values there.
We need to update the code to pass hidden inputs through render_submit/2's second argument.
I'll try to get to that when I can, but if someone wants to take a stab at it first, feel free!
I don't think it'll be too straightforward since we have to parse the form and pull the hidden fields. But we already do some parsing, so it might not be too complicated either.

@revoltaxz could you share the HTML form you're trying to test that's giving you that error? I'm trying to reproduce this issue, but not hitting it for some reason.

@germsvel Sorry my late! Yes, of course, I could:
 def render(assigns) do
    ~H"""

      <.simple_form
        for={@form}
        id={@id}
        phx-submit="submit"
        phx-target={@myself}
        phx-change="validate"
      >

          <.live_select
            field={@form[:symbol]}
            label="Buscar por"
            placeholder="Insira ao menos 4 letras"
            phx-target={@myself}
            phx-focus="clear"
            debounce="500"
            options={[]}
            update_min_len={4}
            dropdown_extra_class="max-h-60 overflow-y-scroll"
          />
          <.field
            field={@form[:category]}
            label="Tipo de posição"
            type="select"
            options={Helpers.asset_types()}
            phx-change="change_category"
          />
          <.field
            field={@form[:quantity]}
            label="Quantidade"
            type="number"
            step="100"
            min="100"
            value="100"
          />
          <.field field={@form[:price]} label="Valor unitário (R$)" type="text" phx-hook="MoneyMask" />
          <.field field={@form[:open_date]} label="Data de compra" type="date" />

          <%= if @category == "option" do %>
            <.field
              field={@form[:contract_type]}
              label="Tipo de opção"
              type="select"
              options={Helpers.options_types()}
            />
          <% end %>

        <.field
          field={@form[:direction]}
          label="Tipo de operação"
          type="radio-group"
          group_layout="col"
          options={Helpers.operation_types()}
        />
        <.button type="submit" phx-disable-with="Salvando..." label="Adicionar" />
      </.simple_form>

    """
  end

OBS: I'm using the LiveSelect.

@revoltaxz thanks for posting the form. I've never used LiveSelect. I don't see a hidden input there. I imagine the LiveSelect library is doing some hidden input stuff behind the scenes?
Do you know how you would test that with LiveView? Or how were you testing that previously?

@germsvel No, I was trying to write tests using PhoenixTest, but I found a PR on the Live Select repo with some instructions, so I think that it is possible to pass the hidden input as you mentioned here. Do you think this helps you?

@revoltaxz I don't think it's a matter of whether or not we can test the hidden inputs.
If you look at this branch, I added a test that passes when testing hidden inputs.
I think the issue is that whatever hidden input LiveSelect is using isn't setting a value properly (or maybe it sets it with JS or something). But that's why you're seeing the error you're seeing:
** (ArgumentError) value for hidden "position[symbol]" must be one of [""], got: "PETR"

LiveViewTest is saying that position[symbol] must be one of <potential value in html element>, but it got "PETR" instead.
So, to give you another example, if you had this HTML
<input type="hidden" name="admin" value="true"/>

And you tried testing it like this:
     |> submit_form("#position_form", admin: "Roger")

You would get the error:
** (ArgumentError) value for hidden "admin" must be one of ["true"], got: "Roger"

So, I don't think it's an issue with PhoenixTest. It's an issue of LiveSelect doing something with hidden inputs that is not matching what you're passing to your form.
Does that make sense?

Oh yes, it makes sense! So, I will close this issue and try to do a workaround with LiveSelect! Thank you for helping me!

Late to the party 😃  I just stumbled upon this thread yesterday by chance...
@revoltaxz @germsvel I have no experience with PhoenixTest (seems like a cool library btw, I will take a look!), but in order to test a form containing a LiveSelect input with the  standard Phoenix.LiveViewTest functions the following trick should work:
form_attrs = %{
        symbol: "PETR",
        category: "stock",
        symbol_text_input: "PETR4",
        price: "12.50",
        quantity: 100,
        open_date: "2024-04-01",
        direction: "short"
}

Phoenix.LiveView.send_update(
      live.pid, # live = your test's live view
      LiveSelect.Component,
      %{id: live_select_id, value: form_attrs.symbol}
     # `live_select_id` is the id of your live select input component
     # (you can pass it explicitly, otherwise, one is generated automatically from form + field name)
)

conn
|> form("#position_form", form_attrs)
|> render_submit()
|> open_browser()

I tested it and it worked for me.
Yes,LiveSelect does use a hidden input to send the value to the form, and the hidden input's value is set dynamically according to what the user has selected. The value is not set with JS, it's an ordinary LV binding.
However, the interaction with the user (i.e. opening the dropdown and selecting an element) does use JS, and that doesn't run in LV tests of course.
So the send_update/3 call above is used to bypasss the user interaction and programmatically force a selection, which will set the value for the hidden input field.
I think I will add a section to the docs documenting this, since quite a few folks asked similar questions already
Thanks!


Robust-ify SlashCommandBuilder

Make init methods throwable for ApplicationCommand and other objects it uses, so we can check for property length/size requirements, thus avoiding "Invalid Form Body" errors coming back from the API in these situations.
Some other changes regarding Codable conformance of property names (snake-case vs. camel-case).

Looks good, thanks for this!


Change 'church' in the example pages to 'elizabeth'

Not sure if you wanted this, but I saw issue #51 so I decided to edit it.

Current coverage is 98.40% (diff: 100%)

Merging #69 into master will not change coverage

@@             master        #69   diff @@
==========================================
  Files            27         27
  Lines          1444       1444
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1421       1421
  Misses           23         23
  Partials          0          0

Powered by Codecov. Last update ae172ba...b555e1c

@Uncleleech Thank you!


Get rid of deprecation warning

Part of #20 (second part is a bugfix release).

(I like to run CI with --depwarn=error since I'd like to avoid that users see deprecation warnings but that is of course a matter of taste and intended audience)

Well, I'd say I don't want to break the support for MLStyle v0.3.1, because MLStyle v0.3.1 is actually treated as an LTS thing.. I'm worry about some inactive(but useful) packages using MLStyle ~v0.3.

Well, I think I worried too much. Please update your code according to my hints and I'll merge.

I'm worry about some inactive(but useful) packages using MLStyle ~v0.3.

If they are inactive then I would think that they don't need new version of this package.


Clarifications regarding README file and YOLO-step-by-step.ipynb

Hi,
I am trying to train a custom class and have a few doubts regarding the code.
README:

What do you mean by the statement "It supports training YOLOv2 network with various backends such as MobileNet and InceptionV3". Aren't YOLO, MobileNet and InceptionV3 different architectures for classification/detection? how does MobileNet and Inception act as backend to YOLOv2?
The backend pre-trained weights that you mention, what dataset has that been trained upon?
What exactly does the gen_anchors.py file do? If I'm not mistaken, does it generate the dimensions for the 5 individual anchor-boxes prescribed by YOLO. If so, would that change from one dataset to another?
Can the custom class be any other class apart from the ones the model was pre-trained upon.

YOLO-step-by-step.ipynb

can we use this notebook to train a custom class by adding the necessary images in the train/val folder, necessary annotations to the train_ann/val_ann folders, and adding a class name to LABELS variable in the notebook? or is the notebook just a demo to train on COCO dataset
I realise that the pre-trained weights have been downloaded from the main YOLO site. Is the training donw only on the 24th layer, or are all layers trained using the pre-trained weights as initialization?
Why is the notebook using the YOLOv1 architecture instead of the YOLOv2 architecture?

These might be super noob questions, please forgive the lack of knowledge.

Hi @Kzernobog,
README:

These are very basic things. Please read the relevant papers by googling "YOLO", "MobileNet", and "InceptionV3". You will find that they are just different network architectures but all do the same thing: extract a hierarchy of features from the input image. These features can be used for very different purposes like classification and object detection.

They were trained on COCO2014.

That's right. Anchors depend on dataset.

Yes. You can use the pretrained weights to train a model to detect almost anything.

Step-by-Step

Yes, it can be used to train anything. One thing to note is that the notebook has no instructions on warming up. You can figure it out based on the instruction in the readme.

All the layers but only for detection on COCO.

No. It's YOLOv2.


Extend Socks5 TLD regex validation to support up to 63 characters

Changes:
Modified the regex pattern to support top-level domain (TLD) lengths of up to 63 characters, in accordance with RFC 1034 standards.
Purpose:
This update ensures our regex can handle the 'internal' TLD used in EC2 guest OS hostnames, thus increasing the flexibility of TLD validation.
JAVA-5490

Only question: Should there be a drivers ticket for this change (for those drivers that regex validate TLDs)? Maybe a prose test?

Only question: Should there be a drivers ticket for this change (for those drivers that regex validate TLDs)? Maybe a prose test?

Thanks for your question. There’s no need for a driver's ticket as the regex validation of domain names is only implemented in Java driver.


Parser doesn't allow <body {% block body_attributes %}{% endblock %}>

A twig template with
    <body {% block body_attributes %}{% endblock %}>
        {% block body %}
        {% endblock %}
    </body>

in it passes the linter symfony console lint:twig templates, but prettier-plugin-twig's parser reports:

[error] templates/base.html.twig: Error: ERROR: Invalid token
[error]   18 |         {% endblock %}
[error]   19 |
[error] > 20 |     <body {% block body_attributes %}{% endblock %}>
[error]      |           ^
[error]   21 |         {% block body %}
[error]   22 |         {% endblock %}
[error]   23 |
[error]
[error] A tag must consist of attributes or expressions. Twig Tags are not allowed.
[error]     at TokenStream.error (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/TokenStream.js:129:24)
[error]     at Parser.error (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:452:21)
[error]     at Parser.matchAttributes (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:442:22)
[error]     at Parser.matchElement (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:333:14)
[error]     at Parser.parse (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:207:32)
[error]     at Parser.matchElement (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:343:41)
[error]     at Parser.parse (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/melody/melody-parser/Parser.js:207:32)
[error]     at Object.parse (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/@zackad/prettier-plugin-twig/src/parser.js:82:24)
[error]     at parse4 (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/prettier/index.mjs:20685:24)
[error]     at async coreFormat (file:///C:/Users/Jason/AppData/Roaming/npm/node_modules/prettier/index.mjs:21146:7)

usage for this when calling the body_attributes block allows for passing in class and data-controller as follows:
{% block body_attributes %}
    class="bg-gray-100 font-sans leading-normal tracking-normal mt-12" data-controller="style"'%}
{% endblock %}

It looks like this dates back to https://github.com/trivago/prettier-plugin-twig-melody/issues/60

I'm not sure how to tackle this issue. Adding support for twig tag inside html element might not be complicated. Example
<div {% block class %}class="hidden"{% endblock class %}>
</div>

On the other hand, if we need to imlement support for twig tag inside attribute value, example
<div class="{% block class %}hidden{% endblock class %}">
</div>

the parser logic will be significantly more complex.
Ideally, all twig features should be supported. However we lack the skill to actually implement this features.
Should we partially implement this feature, allow twig tag inside html element? Skipping twig tag inside html attribute value. Or don't bother to add this feature if not fully implemented? Waiting for feedback.

I think there are way more elegant solutions this, like using an extension like: https://github.com/parisek/twig-attribute. And then just setting the variable that sets all the attributes via the child template.

TBH, I'm not a big fan of using twig tag inside html element. There's other solution that I think more elegant, such as using extension like example above or using something like twig-component.
In my experience, the usage of block expression on html attribute can be achived using ternary expression (which this plugin supported) in some cases. And so far I can live without this feature.
Unless there's strong opinion that this should be implemented, I don't want to add this feature. Feel free to send pull request. Maybe I can work from there.
Thanks.

I don't know what the non-existing specification (not even joking here) of Twig says about this. But in my advanced experience building with Twig, using block inside the HTML tags was never a solution for something that I couldn't have done otherwise. I saw this in use for the first time when reviewing Twig code written by sole PHP developers. I'm not a PHP developer, so I might not necessarily understand the background to this approach. I only write frontend code and I do this most of the time in Twig. So, I might be able to give some inputs on how this can be done in a way it is more readable anyway.
Here are the (mostly better) alternatives for this, from my point of view:

Using variables: Simply passing this down as a variable and rendering it with the |raw pipe, and if you want so for security, the |e pipe, is more readable in any case.
Using the block function: For example in your case {{ block('class') }}.
Pass down a key/value structure and add your own function to Twig to render it as an attribute-key/value string. I've done somethig like this with Twig Macros because my limited PHP understanding. But adding a function to Twig is pretty straight forward.
Install Symfony extensions: Like in the case of class, the HTML Extras and Extra-Bundles with the html_classes function is the cleanest approach.

Or as @zackad said, the Twig Components from Symfony's UX initiative. In case you are anyway in the Symfony ecosystem.
(my 50 cents as a Twig user using the Prettier formatter)

Just installed this in order to test it and this is the first thing I ran into. We use twig tags like this everywhere, so converting everything isn't a small task and probably not a goal of ours. I know liquid supports tags like this and they have a prettier plugin as well.


Hive and Hue

Introduction
This is a great stack, thank you! I managed to combine it with 4-node hadoop as well. Any chance you could extend this to include the same by default, and add Hive and latest Hue?
Feature
Please fill the template below.
Description
Extend to include hadoop with hdfs proper, and add Hive and Hue
Comments (optional)
Happy to send you my docker-compose with hadoop stack included. I tried adding hive and hadoop myself could not get it working, perhaps you could give it a try?

Ignore if you prefer, I managed to get local metadata store working quite well now using derby.


Add shortcuts for some common command-line arguments

What this PR does / why we need it:
Adds single-character shortcuts for some common acsengine command arguments. Tries to align them with similar flags in az aks.
Let me know if you like this--shortcuts can be a personal preference, and I'm glad to change the reserved letters or punt on this altogether.
Example (the -m, -p, and -s shortcuts are new):
$ ./bin/acs-engine deploy -h
Deploy an Azure Resource Manager template, parameters file and other assets for a cluster

Usage:
  acs-engine deploy [flags]

Flags:
  -m, --api-model string             path to the apimodel file
      --auth-method device           auth method (default:device, `client_secret`, `client_certificate`) (default "device")
      --auto-suffix                  automatically append a compressed timestamp to the dnsPrefix to ensure unique cluster name automatically
      --azure-env string             the target Azure cloud (default "AzurePublicCloud")
      --ca-certificate-path string   path to the CA certificate to use for Kubernetes PKI assets
      --ca-private-key-path string   path to the CA private key to use for Kubernetes PKI assets
      --certificate-path string      path to client certificate (used with --auth-method=client_certificate)
      --client-id string             client id (used with --auth-method=[client_secret|client_certificate])
      --client-secret string         client secret (used with --auth-mode=client_secret)
  -p, --dns-prefix string            dns prefix (unique name for the cluster)
  -f, --force-overwrite              automatically overwrite existing files in the output directory
  -h, --help                         help for deploy
      --language string              language to return error messages in (default "en-us")
  -l, --location string              location to deploy to (required)
      --output-directory string      output directory (derived from FQDN if absent)
      --private-key-path string      path to private key (used with --auth-method=client_certificate)
  -g, --resource-group string        resource group to deploy to (will use the DNS prefix from the apimodel if not specified)
      --set stringArray              set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
  -s, --subscription-id string       azure subscription id (required)

Global Flags:
      --debug   enable verbose debug logs

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
There is no GitHub issue for my frustration with extra typing.
Special notes for your reviewer:
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

Add shortcuts for some common command-line arguments

/lgtm


Forwards Compatibility-Breaking Updates

Forwards Compatibility Breaking Updates in v1.5
Soon I will release v1.4 of the API as the last packaged version of "Version 1.0" of the API. I will then begin work on v2 of the API which will start with the marker 1.5.
When I originally created the API, I failed to account for some things that would potentially impact its longevity and versatility. There are some things that need to be changed in order to make conventions and frameworks more consistent with existing rules. A lot of these changes will break lots of existing projects, which is why I am choosing to separate them into a new version specifically made for them.
The changes planned (in no particular order):

[x] Changing package names to directly package them together
This is one of the most egregious examples of not planning for a well-made API. All of the packages just have their own name rather than being prefixed by "net.dec4234.javadestinyapi" This has made and will make it difficult to identify which packages specifically belong to JDA.
[ ] Removing duplicate and often confusing methods and renaming many others
As I have covered more and more of the API I have made many functions which often overlap with existing functions to an unnecessary degree. This has made it increasingly confusing to determine which are appropriate for each situation. On top of that, the names of many methods are unnecessarily long or cryptic, which may cause first-time users to miss a functionality that they could use. Appropriately naming functions based on their use and output will make the API more accessible.
[ ] Renaming certain class names to be less cluttered and a little more relevant
This is one that I am not as sure about. I think that some class names may benefit from being renamed, but I'll need to see how it pans out and how necessary it is.
[ ] Standardizing id variable types
This one is going to impact a lot of existing infrastructure.
Just a couple days ago, I finally realized that all ids in the bungie api can fit under int64, which is a long in java. When I was originally building the API, I thought that ids could only fit under a String, because I only tested them being placed in ints. I think that it would be best if we switched all IDs referenced in the API from Strings to longs in order to make them a little more recognizable.

To Be Continued

Update: v1.4 Packaged Jar Has Been Released
All classes have been repackaged under net.dec4234.javadestinyapi (More to come)

A couple of weeks ago I completely revamped the username searching systems, narrowing it down to two methods.
getUserWithName() for names such as dec4234#9904
searchUsers() for names such as dec4234
searchGlobalDisplayName (Deprecated) - Same as first one but uses GET instead of POST

A lot of simple things need more work, for example Clan Members.
I re-discovered only recently that there are 2 pieces of vital information in the Clan Members endpoint that allows us to bypass an extra request, potentially increasing efficiency. When completed, this will be most useful for those who wish to sort clan members by inactivity, narrowing the response time from about 165 seconds and 300+ requests to just 1 and less than two seconds.
They are: lastOnlineStatusChange (A.k.a last login/logout and join date). As well as isOnline() which will also be useful.


Failed to run samples in tutorial-power-bi-custom-model

We failed to run the sample codes in the following document.
https://learn.microsoft.com/en-us/azure/machine-learning/v1/tutorial-power-bi-custom-model
After training and defining related resources, deploying to ACI must fails.
Other collogues failed, too.
Could you update inference config and scoring script to make the sample work properly?

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

ID: c3dfa0c7-942e-7120-1f84-aeec42f9b10a
Version Independent ID: 18a7dc7e-11f3-f612-d239-1682f283aff5
Content: Tutorial: Create the predictive model with a notebook (part 1 of 2) - Azure Machine Learning
Content Source: articles/machine-learning/v1/tutorial-power-bi-custom-model.md
Service: machine-learning
Sub-service: core
GitHub Login: @samuel100
Microsoft Alias: samkemp

@shohei1029
Thanks for your feedback! We will investigate and update as appropriate.

@shohei1029
Thank you for bringing this to our attention.
I've delegated this to content author @samuel100, who will review it and offer his insightful opinions.


Update roadmap

I’m thinking that maybe the only thing on our roadmap that needs to happen before we move loaders out of experimental status is the task about moving loaders off-thread (and potentially renaming flags that might come with that). These were the other two we had:

Telling Node to use particular loaders via configuration file. This seems like it might become a much bigger challenge, since it should support (eventually) most/all of Node’s configuration. But I think this can be a follow-on improvement, as it’s more of a UX convenience than a required feature.
Supporting format: 'commonjs'. I’m not sure if this is even still an issue, but if it is, it’s arguably a bug in the implementation more than anything else. We can fix it at any time without causing a breaking change, and the current scope of loaders is that they’re not expected to handle CommonJS (yet) and that traditional CommonJS loaders are still needed for now (via require.extensions or monkey-patching). So I don’t think this should really block moving loaders to stable, either, as it can be fixed (and loaders more broadly extended to support CommonJS) as later improvements.

What do you think? There’s a big benefit to getting loaders out of experimental status in that that’s what many people are waiting for to start supporting the API “officially,” such as instrumentation vendors. The sooner we can declare loaders stable, the sooner all of ESM is considered stable and ready for production use. And I think aside from the off-thread thing, we’re already there.
This doesn’t mean that work won’t continue on loaders after this last Phase 1 item; but such follow-up work would need to follow semver regarding breaking changes. But I don’t think anything remaining on our list besides the off-thread/flags change would potentially involve any breaking changes? @nodejs/loaders

Do we need the 2 package.json helpers? I think you were concerned their APIs might change (better to do during experimental stage).

Those helpers can themselves be experimental without the whole loaders API needing to be. Similar to how import.mets.resolve is experimental.


Create a troubleshooting guide/section

Some problems happen often to our users and the solution needs to be reinvented again and again. What about describing usual issues/problems/errors and their solution?
This can be very related to #415 that is targeted to the final use case, but here I would like to see a few example warnings/errors, what they mean and how to fix them when configuring Packit.

Related: https://github.com/packit/packit-service/issues/1657


Duolingo Spaced Learning

Add the Duolingo Halflife Prediction dataset.
Large like the HIGGS dataset, but different types of attributes. In particular, this dataset has text attributes which may be a bit problematic.

After discussion, at least for an initial inclusion of this dataset, to convert the text attributes to be categorical. For the lexeme categories, treat them as independent categorical attributes (even though in practice this may not make the most sense).
This is at least until we find a better way to encode the dataset.


HBW-337 Use button_text field for fallback submit-select components

For submit doesn't exist any value for fallback in forms keys. And it's look like this
https://github.com/latera/homs/blob/master/hbw/app/javascript/packs/hbw/components/form/submit.js.jsx#L43
So, what ideas for it? May be we should use just hardcoded string 'Submit' for fallback?

https://github.com/latera/homs/pull/616
https://github.com/latera/homs/pull/617


fix: use isolateObjectProperty function in createLocalReq

Description
Fixes remaining issues from https://github.com/payloadcms/payload/pull/5727 after discussion
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] Existing test suite passes locally with my changes

Another example of the kinds of bugs that this can cause: with a plain relationship in v2.12.1, you get an incorrect collection name in the deletion success/error message:
https://github.com/payloadcms/payload/assets/208149/72b18fef-7d27-4c01-aae0-ff53668efc61

Thanks for all the information here @franciscolourenco I'm surprised this issue hasn't been caught before!
Latest fix on this branch seems to handle your relationship video example and any of the other hooks

@paulpopus that looks like it should work. However I believe we might need to isolate some other properties, at least the context: https://github.com/payloadcms/payload/issues/3417

Aside:
Also I wonder if there is a reason to preserve the reference to the original req object with a proxy, instead of just creating a new object, and spreading the previous req. That way none of the changes to req properties would leak outside of the current operation. Something along the lines of:
req = {
  ...req,
  collection:  payload.collections[collection],
  context: getRequestContext(req, context),
  // etc...
}

This could have an effect on how transactions currently work though. Not sure if it would a positive or negative effect.

I can confirm that it fixed the issue with the req.collection, both outside and inside the context of a local operation, thanks everyone 🙏
As far as I can tell https://github.com/payloadcms/payload/issues/3417 might be caused by the same issue but with req.context.

If we isolate req.context then it will be a breaking change. If anything we would document how a hook could use call isolateObjectProperty on individual req.context.props so that you could manage context request lifecycles in your own project.
Right now if you isolate that the entire context property you would not longer be able to do context based conditions between local api calls.
Does that make sense?

I think I understand what you mean. Currently the docs don't have any example about sharing context between local API calls (context flowing up). I wonder in which scenarios this would be needed (just curious since that we currently don't have any). I guess not having any examples of that made me assume that context was not supposed to leak outside a local API call and flow only top-down and "sideways" between hooks. Also I've saw some people get confused about this while debugging.
I guess what comes closest is this part since it mentions setting context across multiple collections, but it's easy to miss:

Passing data between hooks and middleware or custom endpoints: Hooks could set context across multiple collections and then be used in a final postMiddleware.


cdc: fix sourcemanager.Close deadlock

What problem does this PR solve?

Issue Number: close #8329
What is changed and how it works?
There is case that might cause sourcemanager.Close deadlock, because it blocking sends error but there no goroutine receive it.
Also, I find it is nearly impossible to test this fix in unit test for now, I might send another PR for adding unit tests later.
Check List
Tests

Integration test

Questions
Will it cause performance regression or break compatibility?
No
Do you need to update user documentation, design documentation or monitoring documentation?
No
Release note
Fix an issue that might cause checkpoint stuck and TiCDC OOM during rolling upgrade

/merge

/run-kafka-integration-test
/run-integration-tests


Feature Request: chapter_id and chapter_pages

"chapter": [
{
"chapter_id": 2236269,
"chapter_pages": 12,
"chapter_title": "Chapter 70",
"chapter_endpoint": "after-transformation-mine-and-her-wild-fantasy-chapter-70-bahasa-indonesia/"
}
]

Thanks for the feature request. For chapter_id you can use chapter_endpoint instead

How do I get the manga in english


⚠ Bofrost.nl has degraded performance

In b35ccde, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1569 ms

Resolved: Bofrost.nl performance has improved in 370051d.


Example Scripts do not support Active Directory Users

The provided example scripts seem to only work with local user accounts.  I was able to modify the example pythons scripts to work with AD credentials.  Here are the changes (or, at least, my version) to get the scripts to work:
In the main definition, add:
    parser.add_argument('-d', dest='domain', required=False,
                        default='Local',
                        help='''
    HP OneView Authorized Login Domain''')

Modify the following line:
credential = {'userName': args.user, 'password': args.passwd}
to:
credential = {'authLoginDomain': args.domain.upper(), 'userName': args.user, 'password': args.passwd}

Hello Lee,
Thanks for the patch! Sorry, it took me so long to get it applied. I was waiting until I had the initial support for the 2.0 API uploaded first. In any case your patch has been applied.
Troy


Failing to run on ARM / Raspberry Pi

Hi!
Wanted to test this out on my small home server but I couldn't get it up and running.
I get the error:
Attaching to chatwithgpt-cogentapps-1
chatwithgpt-cogentapps-1  | exec /usr/local/bin/docker-entrypoint.sh: exec format error
chatwithgpt-cogentapps-1 exited with code 1

I've seen this before when the image wasn't ARM compatible.
Just FYI.

The docker image now includes a version for ARM.

The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

same here, can't be running on Raspberry Pi4
exec /usr/local/bin/docker-entrypoint.sh: exec format error

PR #109 demonstrates building the docker locally which could work as a solution. Just tried it and it is working well on a Pi4 running 64-bit Raspberry Pi OS.

The GitHub Action that I was using to deploy the ARM image was taking hours to run (and often failing), probably due to virtualization, so I removed it temporarily. I haven't had an opportunity to write a new one.
PRs for a new GitHub action are welcome, if anyone wants to take a stab at solving this.
Preferably a new workflow, separate from the existing docker build workflow, that builds and deploys in a relatively short period of time.

arm support is very much appreciated.
currently getting:
2023-05-16T23:37:26.962765142Z exec /opt/nvidia/nvidia_entrypoint.sh: exec format error
2023-05-16T23:37:32.788802356Z exec /opt/nvidia/nvidia_entrypoint.sh: exec format error
2023-05-16T23:37:38.597547827Z exec /opt/nvidia/nvidia_entrypoint.sh: exec format error
2023-05-16T23:37:44.453824339Z exec /opt/nvidia/nvidia_entrypoint.sh: exec format error


Add bladeStiffenedShell constitutive model

This PR adds a new TACSBladeStiffenedShellConstitutive class, a new implementation of the old bladeFSDT class. It also adds a panel length constraint class to the pyTACS interface.
Constitutive model
Compared to the old bladeFSDT class, the new model contains a few improvements:

The panel and stiffener laminates can now be made up of an arbitrary number of ply angles as opposed to being hardcoded to [0, -45, 45, 90] deg laminates. This means you can model more complex laminates and makes it simpler to model a shell made from an isotropic material as you no longer need to supply 4 copies of the same isotropic ply when creating the constitutive object.
The buckling failure envelope is modified in a similar manner to https://github.com/smdogroup/tacs/pull/203 so that it can be used to ensure a specified buckling margin
I fixed a bug (I think) in the critical buckling loads calculation where the $D_{12}$ entry of the bending stiffness was being used instead of $D_{22}$ to compute the $D_2$ value in Stroud and Agranoff's equations.
Almost all of the calculations in the model have been rewritten in a way that computes contributions from the panel and stiffener as if they are distinct shell and beam constitutive models. My hope is that in the future, with a little more work, we could modify this model to create a stiffened shell model using any combination of existing TACS shell and beam constitutive models.

For example, this is how the stiffness matrix for the stiffened shell is computed:
// Compute the stiffness matrix
void TACSBladeStiffenedShellConstitutive::computeStiffness(TacsScalar C[]) {
  TacsScalar* A = &C[0];
  TacsScalar* B = &C[6];
  TacsScalar* D = &C[12];
  TacsScalar* As = &C[18];
  TacsScalar* drill = &C[21];

  // --- Zero out the C matrix ---
  memset(C, 0, this->NUM_TANGENT_STIFFNESS_ENTRIES * sizeof(TacsScalar));

  // Add the panel's stiffness contributions
  this->computePanelStiffness(C);

  // Compute the stiffener's beam stiffness matrix ,then transform it to a shell
  // stiffness matrix and add it
  TacsScalar Cstiff[TACSBeamConstitutive::NUM_TANGENT_STIFFNESS_ENTRIES];
  this->computeStiffenerStiffness(Cstiff);
  this->addStiffenerStiffness(Cstiff, C);
}

This code does not make any assumptions about the form of the panel or stiffener stiffness matrices and could easily be modified so that computePanelStiffness is actually a call to another shell constitutive model, and computeStiffenerStiffness is a call to a beam constitutive model.
Panel length constraints
I also implemented a panel length constraint class that is necessary to ensure the panel length values used in the buckling failure calculations are consistent with the true geometry of each TACS component. I used numba to speed up the panel length computation and its derivatives which means we would need to add Numba as a dependency of TACS. As far as I can tell this shouldn't be too much of a stability issue, numba has a pretty wide user-base, and is officially supported by organisations like Anaconda, Intel, and NVIDIA.
ToDo before merging:

[ ] Merge #203
[x] Add numba dependency
[x] Fix Tsai-Wu derivative errors
[ ] Add integration test for panel-length constraints
[ ] Add bladeStiffenedShell model to an example case?

Any idea whats going on with the constitutive test failures?

Out of curiosity how long does it take to compute the panel length constraints for your CRM case?

Can you add a conda dependency line for numba here?

Other than that. This looks good so far. Thanks for the work @A-CGray

@timryanb on further inspection, there was no issue with the Tsai-Wu sensitivities but there was an issue with the Von Mises (not related to any changes in this PR) that I fixed. There were some issues with the finite difference tests for the blade stiffened model where the relative tolerance cannot be met because the absolute values of the derivatives are very small. To get around this I implemented a new type of pass/fail criteria for the unit tests based on numpy's assert_allclose. It basically acts like a relative tolerance when the values being compared are large but more like an absolute tolerance when the compared values are very small which fixes the issue I was facing.

I stand corrected, there were a couple of uninitialized values causing problems only in the real tests when compiled in debug mode. I've fixed those and with the new assert_allclose check I was able to get all of the constitutive model tests passing with tighter tolerances

@timryanb I think once #216 is merged, the tests here should pass and this PR will be ready to go

@A-CGray I had to rename the benchmark file to get testflo -b to work since we already had a file called benchmark_analysis.py and testflo didn't like that.


Fix broken schema view. revert change to reponse from Api.schemaServi…

…ceGetSchema

Rebased, and merged.
Thanks for your contribution !

Rebased, and merged.
Thanks for your contribution !

But PR is still open


Can I deploy prometheus on one director to monitor PCF on another?

I am trying to deploy Prometheus on on Bosh Director  but pull data from our PCF foundations.
/opt/pcf/bin/bosh2 -e cc-sand -d prometheus deploy manifests/prometheus.yml --vars-store prometheus-sand-parms.txt -o manifests/operators/monitor-bosh.yml --var-file bosh_ca_cert=pcfsand.cert -o manifests/operators/monitor-cf.yml -o manifests/operators/enable-grafana-uaa.yml  -o manifests/operators/enable-cf-route-registrar.yml  -v traffic_controller_external_port=9186 -v skip_ssl_verify=true --var-file uaa_ssl.ca=pcfsand.cert --var-file uaa_ssl.certificate=uaa.key  --var-file uaa_ssl.private_key=uaa_rsa.key
This is what I put in the vars file…
This is the info for the PCF foundation ---
bosh_ca_cert: pcfsand.cert
bosh_password: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
bosh_url: <IP_ADDRESS>
bosh_username: director
cf_deployment_name: cf-5cc834eddd3c4e259966
metron_deployment_name: cf-5cc834eddd3c4e259966
opsman_url: ycdcpcfomsand.duke-energy.com
pcf_opsman_admin_password: xxxxxxxx
pcf_opsman_admin_username: pcfadminsand
uaa_bosh_exporter_client_secret: xxxxxxxxxx
uaa_clients_cf_exporter_secret: xxxxxxx
uaa_clients_firehose_exporter_secret: xxxxxxxxx
This is cloud-config info for the non PCF bosh director
deploy_azs:

AZ1
deployment_network: CDC_PCF_Dev_Concourse_v1225
deploy_vm_type_micro: micro
deploy_vm_type_small: small

github_token: xxxxxxxxxxxxxxxxxxxxxxxx alertmanager_mesh_password: xxxxxxxxxxxxxxxxxxxxxxxx
alertmanager_password: xxxxxxxxxxxxxxxxxxxxxx
alertmanager_smtp_auth_password: xxxxxxxxxxxxxxxxxx
alertmanager_smtp_auth_username: cftst
alertmanager_smtp_from<EMAIL_ADDRESS>alertmanager_smtp_require_tls: true
alertmanager_smtp_smarthost: authenticatedsmtp.duke-energy.com:25
grafana_password: xxxxxxxxxxx
grafana_secret_key: xxxxxxxxxxxxxxx
grafana_smtp_enabled: true
grafana_smtp_host: authenticatedsmtp.duke-energy.com:25
metrics_environment: pcfsand2
prometheus_password: xxxxxxxxxxxxxxxx
skip_ssl_verify: true
system_domain: system.sand-pcf.duke-energy.com
This is based on these insructions…
If you want to monitor your Cloud Foundry platform, first update your cf-deployment adding the add-prometheus-uaa-clients.yml op file. This will add the UAA clients required to gather information from the Cloud Foundry API and Firehose.
Then add the monitor-cf.yml op file by running the following command (filling the required variables with your own values):
bosh -d prometheus deploy manifests/prometheus.yml
--vars-store tmp/deployment-vars.yml
-o manifests/operators/monitor-bosh.yml
-v bosh_url=
-v bosh_username=
-v bosh_password=
--var-file bosh_ca_cert=
-v metrics_environment=
-o manifests/operators/monitor-cf.yml
-v metron_deployment_name=
-v system_domain=
-v uaa_clients_cf_exporter_secret=
-v uaa_clients_firehose_exporter_secret=
-v traffic_controller_external_port=
-v skip_ssl_verify=
When I go to execute the deployment:
Task 1156
21:09:29 | Preparing deployment: Preparing deployment (00:00:00)
L Error: Unable to process links for deployment. Errors are:

Can't find deployment cf-5cc834eddd3c4e259966

21:09:29 | Error: Unable to process links for deployment. Errors are:

Can't find deployment cf-5cc834eddd3c4e259966

If I list the deployments for the PCF foundation:
$ /opt/pcf/bin/bosh2 -e  pcf-sandbox login
Email (): director
Password ():
Successfully authenticated with UAA
Succeeded
$ /opt/pcf/bin/bosh2 -e  pcf-sandbox deployments
Using environment '<IP_ADDRESS>' as user 'director' (bosh..read, openid, bosh..admin, bosh.read, bosh.admin)
Name                                                   Release(s)                                  Stemcell(s)                                       Team(s)                             Cloud Config
cf-5cc834eddd3c4e259966                                backup-and-restore-sdk/1.2.1                bosh-vsphere-esxi-ubuntu-trusty-go_agent/3468.21  -                                   latest
binary-offline-buildpack/1.0.15
bosh-dns/0.1.0
bosh-dns-aliases/0.0.1
bosh-system-metrics-forwarder/0.0.11
capi/1.44.20
Which leads me to believe that when it is looking for the deployment it is not logged into the PCF director.
Am I just not understanding the directions?  Is what I am trying to do possible (Bosh A running Prometheus while Bosh B is the PCF bosh deployment)?

The manifest files included in this repo are intended to be used when deployments are in the same director. As your prometheus deployment is running on a different director than the cf deployment, the BOSH links do NOT work.
You will need to create your own manifest file to support your topology (and I'm assuming there's no traffic restriction from the prometheus to the cf deployment networks). You can do this by updating the enable-cf-route-registrar.yml and overriding the nats link to use manual linking:
consumes:
  nats:
    instances:
      - address: <Your CF NATS IP Address 1>
      - address: <Your CF NATS IP Address 2>
    properties:
      port: <Your CF NATS port>
      user: <Your CF NATS user>
      password: <Your CF NATS password>

Alternativelly, you can use plain properties instead of BOSH links by removing the whole consumes section and adding the required properties:
name: route_registrar
release: routing
properties:
  nats:
    machines:
      - <Your CF NATS IP Address 1>
      - <Your CF NATS IP Address 2>
    port: <Your CF NATS port>
    user: <Your CF NATS user>
    password:  <Your CF NATS password>
  route_registrar:
  ...

Closing this issue as this topology needs manual manifest files.


Add ATX Header Support for terraform-docs

🗣 Description
This pull request:

Clones @mcdonnnj's forked branch from terraform-docs.
Builds and installs the binary from the clone.

💭 Motivation and context
This temporarily resolves #196 until @mcdonnnj's changes get merged into terraform-docs, at which point we can change back over to the standard of installing terraform-docs.

🧪 Testing
All automated tests passed. I also used act for local testing to make sure the workflow would behave like it should.

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[x] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

Thanks for taking care of this! 👍
Can you please confirm that you re-tested this workflow after making the changes requested during the PR review?

 Yes, I ran any changes to the workflow in act everything checked out locally.


K3S Rootless mode daemon-reload : Failed to connect to bus: No such file or directory

Environmental Info:
K3s Version: latest

Node(s) CPU architecture, OS, and Version: GitHub Action Ubuntu-latest

Cluster Configuration: Single instance

Describe the bug:

I want to use K3S in a GitHub Action in Rootless-mode.
I created the ~/.local/bin/k3s and download the k3s with this command: curl -sfL https://get.k3s.io -o ~/.local/bin/k3s
I created the ~/.config/systemd/user then I downloaded the k3s-rootless.service into it.
I also modified the k3s-rootless.service with this sed -i 's|ExecStart=/usr/local/bin/k3s server --rootless|ExecStart=/home/runner/.local/bin/k3s server --rootless|' ~/.config/systemd/user/k3s-rootless.service
Finally I run systemctl --user daemon-reload to reload the daemon.
Error message: Failed to connect to bus: No such file or directory

Steps To Reproduce:

Installed K3s: Failed to connect to bus: No such file or directory

Expected behavior:

K3S runs in rootless-mode
Actual behavior:

When I run systemctl --user daemon-reload to reload the daemon. I am facing the following error: Failed to connect to bus: No such file or directory
Additional context / logs:

No additional logs or contexts.

That's an error from systemctl, not k3s. I'm not sure what to suggest, I would probably check the systemd docs.


Need more samples of how to use a custom docker network configuration

[Enter feedback here]
If we have to override default moby network configuration, there is not enough documentation explaining how to do the same.
for example, if we want to run docker on a different ip range other than <IP_ADDRESS>, we don't have a clear documentation detailing the same.
Adding the same in section https://learn.microsoft.com/en-us/azure/iot-edge/configure-device?view=iotedge-1.4#moby-runtime will be highly appriciated.

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

ID: dc645151-3164-c5cb-343b-fa3c5b4ee248
Version Independent ID: 50ee6151-587a-f01f-a3ed-b8b756cf010c
Content: Configure Azure IoT Edge device settings
Content Source: articles/iot-edge/configure-device.md
Service: iot-edge
GitHub Login: @PatAltimore
Microsoft Alias: patricka

Hi @arunsl ,
You can customize the network configuration you can create a docker network with the desired configuration and then set the network to the name of the custom network you defined.
In your example, create a custom network with the range <IP_ADDRESS>. For example, "my-custom-network". See, https://docs.docker.com/engine/reference/commandline/network_create/
Then set the network in config.toml for the device:
[moby_runtime]
uri = "unix:///var/run/docker.sock"
network = "my-custom-network"
Another docker reference on creating networks: https://docs.docker.com/network/network-tutorial-standalone/
Hope that helps.
Thanks,
Pat
I'm going to close the issue. #please-close


Bump pyglet dep to v1.4.9 to ensure compat with new Python releases

See https://github.com/pyglet/pyglet/issues/112

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance. You can also try re-rendering locally.


Test duplicated code reviews

🎉 Snyk hasn't found any issues so far.
✅ security/snyk check is completed. No issues were found. (View Details)


Facebook failed with error 500

Error message: No results for this query.
Query string: action=display&bridge=Facebook&u=onespacenews&media_type=all&format=Atom

This seems to be working for me. Is this a sporadic issue?
Possibly related to #994

https://github.com/RSS-Bridge/rss-bridge/issues/2047


[BUG] No player avatars showing in discord

What happened?

No Player avatars in discord

What should happen?

MC Player avatars should show

Steps to reproduce

Turn on webhooks

Version

[ ] 1.12
[X ] 1.16

Platform

[X ] Forge
[ ] Spigot

Mod version:
Config file
REMOVE YOUR BOT TOKEN BEFORE UPLOADING!!!
Crash report if available (use https://hastebin.com)
Additional info

I found a comment on curseforge and updated the config
playerAvatarURL = "https://crafatar.com/avatars/%uuid%?randomuuid=%randomUUID%"
I now have avatars on discord.


Feature request:  metacat dataset list has an option to list the files in the dataset.  Clearer documentation on -l and -c would be useful

I'm trying to see what is in a dataset.  Here is what I get
 metacat dataset list -l schellma:protodune-sp-physics-generic
creator          created             prnt/chld files      namespace/name

schellma         2022-10-08 13:41:54    0/0               schellma:protodune-sp-physics-generic
seems to say there are not files in the dataset
 metacat dataset list -c schellma:protodune-sp-physics-generic
schellma:protodune-sp-physics-generic
ditto, seems to think it is empty
 metacat query "files from schellma:protodune-sp-physics-generic" | grep -c root
674918
Is this expected behavior?

Yes it is expected. The metacat dataset list command lists datasets by pattern, not files in the dataset


Change riscv tests to only use rust crates

For single file rust tests, powdr-riscv-runtime refers to powdr's github main branch.
This makes it hard to modify the riscv-runtime crate without breaking tests.
Once we have crates published with semver, those should be usable again.

In my opinion, even from command line the support for individual files should be removed.


Allow download of occultations with data limited to specific radii

From Matt T:
Hi.  I was talking with a user of ours at AGU yesterday and fielded the following idea:  He would find it convenient to define a range of ring radii and receive only those snippets of occultations that fall within those limits.
This is clearly a long-term goal, and not something we are set up to do in the near future.  It may require a wholesale change in how we serve data products.  However, it seems to be an example of the kind of online computing that NASA increasingly wants PDS to consider.
No action is requested at this time, except to add it to a queue of long-term project ideas.

See issue #356 which could conceivably allow downloading of profile(s) during viewing that were cropped to limited radii.


Metadata discovery with glob can't find entity with class name of "BaseEntity"

Describe the bug
When using glob for the metadata discovery like this
entities: ['dist/**/*.entity.js'],
entitiesTs: ['src/**/*.entity.ts'],

the following error is thrown: MetadataError: Entity 'Base' not found in ./dist/common/base.entity.js
The class name of the base entity is BaseEntity. When renaming the class to just Base it is working without any errors.
Stack trace
MetadataError: Entity 'Base' not found in ./dist/common/base.entity.js
    at Function.entityNotFound (/home/redacted/server/node_modules/@mikro-orm/core/errors.js:108:16)
    at MetadataDiscovery.getEntityClassOrSchema (/home/redacted/server/node_modules/@mikro-orm/core/metadata/MetadataDiscovery.js:634:42)
    at MetadataDiscovery.discoverDirectories (/home/redacted/server/node_modules/@mikro-orm/core/metadata/MetadataDiscovery.js:98:33)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async MetadataDiscovery.findEntities (/home/redacted/server/node_modules/@mikro-orm/core/metadata/MetadataDiscovery.js:73:9)
    at async MetadataDiscovery.discover (/home/redacted/server/node_modules/@mikro-orm/core/metadata/MetadataDiscovery.js:34:9)
    at async Function.init (/home/redacted/server/node_modules/@mikro-orm/core/MikroORM.js:40:24)
    at async Injector.instantiateClass (/home/redacted/server/node_modules/@nestjs/core/injector/injector.js:294:37)
    at async callback (/home/redacted/server/node_modules/@nestjs/core/injector/injector.js:77:30)
    at async Injector.resolveConstructorParams (/home/redacted/server/node_modules/@nestjs/core/injector/injector.js:118:24)

To Reproduce
Steps to reproduce the behavior:

Have a base entity base.entity.ts with the class name BaseEntity and extend an entity with it.
Start app
See error in the console

Expected behavior
Metadata discovery should be able to find the class.
Versions

Dependency
Version

node
14.11.0

typescript
4.0.2

mikro-orm
4.0.7

your-driver
postgresql

hello @squareloop1, did you check defining baseDir?, maybe your path is pointing at node_modules at the package of the mikro-orm:
entities: ['dist/**/*.entity.js'],
   baseDir: __dirname,

This is actually correct/expected/documented behaviour. Everything after the first dot is ignored from the file name. If your entity is called BaseEntity, your file name should be one of:

BaseEntity.ts
base-entity.ts
base-entity.entity.ts
base-entity.*.ts
...

You can override how this works via custom naming strategy.
We could probably to get around this limitation and base the entity name only on the usage of @Entity decorator, but that would require new decorator on base entities, which would be a breaking change, so no plans to change that now.

Alright, I'm fine if it can be customized in the naming strategy. Thanks for the information.