repo: workflows planned maintenance

Description of situation
There are many workflows that are deprecated and some that not working either. We need to decide what workflows must be kept and what must be updated or deleted.
Any ideas for new structure, workflows to be made are very appreciated @andyoknen.
List of workflows
Build Dev (build.dev.yml)

[ ] Update
[ ] Delete
[ ] No changes

Build Release (build.release.yml)

[ ] Update
[ ] Delete
[ ] No changes

Delete old workflow runs (delete.old.runs.yml)

[x] Update
[ ] Delete
[ ] No changes

Deploy Dev PR (deploy.pulls.dev.yml)

[x] Update
[ ] Delete
[ ] No changes

Deploy Proxy (deploy.proxy.yml)

[x] Update
[ ] Delete
[ ] No changes

Deploy Proxy Pre (deploy.proxy.pre.yml)

[x] Update
[ ] Delete
[ ] No changes

Deploy Proxy Test (deploy.proxy.test.yml)

[x] Update
[ ] Delete
[ ] No changes

Deploy to night.bastyon.com (night.bastyon.com.yml)

[ ] Update
[ ] Delete
[ ] No changes

Deploy to night.test.bastyon.com (night.test.bastyon.com.yml)

[ ] Update
[ ] Delete
[ ] No changes

Deploy to pre.pocketnet.app (pre.pocketnet.app.yml)

[ ] Update
[ ] Delete
[ ] No changes

Deploy to test.pocketnet.app (test.pocketnet.app.yml)

[ ] Update
[ ] Delete
[ ] No changes

Deploy Web (deploy.web.yml)

[ ] Update
[ ] Delete
[ ] No changes

Tests (autotests.yml)

[x] Update
[ ] Delete
[ ] No changes

Detect PRs conflicts (deleted)

[x] Already deleted, just clean history of runs

Maybe so:

Production:

build & deploy bastyon.com and mirrors by tag "vX.Y.Z"
build binaries for releasing by tag "vX.Y.Z"

Night builds:

build main & test web from master after merge PR
deploy web night & night.test after building
build & deploy binaries main & test for public sharing

Build merged PRs:

build & deploy web & binaries for pre-testing

Clean old workflows

Build & deploy Proxy we need move to self repository


[Fixes #18] Dynamically set Ember.onerror

This takes a shot at resolving #18. It dynamically sets or clears the Ember.onerror handler depending on the state of the enabled computed property. Specifically, it will not set Ember.onerror (leave it as undefined) if enabled is false.

This problem should be already fixed in v0.5.2.


App Store issue - Safari

My app was rejected by the App Store for the following reason: Upon launching the app, a web page in mobile Safari opens for logging in LinkedIn, then returns the user to the app. The user should be able to log in without opening Safari first. Any suggestions?

see demo and oauthswift.authorize_url_handler =  ... to not open external safari

Thanks! Which file is this in?

you can search in github in the current depository
https://github.com/dongri/OAuthSwift/search?utf8=✓&q=oauthswift.authorize_url_handler+%3D
You will see
oauthswift.authorize_url_handler = WebViewController()
WebViewController is a class that you implement with an UIWebView or WKWebView
The example use UIWebView
P.S. Please close this issue when you have found the solution


I want to be able to register multiple hosts

I want to be able to register multiple hosts so that the production environment and development environment can be used simultaneously
Does this library provide such functionality?

First of all swag it's an cli application that generate OpenAPI 2.0 Specification from your go code annotations.
When ever you use the generated documentation into a http Handler (no matter what type), you can change the endpoint by assingin a new value to variable Host of SwaggerInfo object of your documentation.

import ("github.com/swaggo/swag/example/basic/docs/docs.go")

func register_routes(router) error {
   docs.SwaggerInfo.Host = "http://new.endpoint"
}

Unfortunately there is no way to do that in OpenAPI 2.0, so you will have to do that at runtime.

Just added this line ...
docs.SwaggerInfo.Host = *host + ":" + *port
host and port the flags to the application.

Thank you so much, You've been very helpful!

Is this going to be implemented for open api 3?


Introduce ESLint to catch errors

Also enforce existing conventions on indentation & semis

Thanks @edg2s, this is something I have been hoping to do. :)

Once this is merged you can got to actions, select "Create this workflow" under "Node.js", and you will now have a CI test that runs ESLint (via npm test) against every pull request.
I would make one modification to the action config which is to change
node-version: [10.x, 12.x]

to
node-version: [12.x]

as you don't really need to run the ESLint test multiple times


[WIP] Update CI-python.yml to add python 3.10 tests

Codecov Report

Merging #53 (ac29e38) into main (96b6ff9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #53   +/-   ##
=======================================
  Coverage   64.29%   64.29%
=======================================
  Files          16       16
  Lines        1056     1056
=======================================
  Hits          679      679
  Misses        377      377

Flag
Coverage Δ

unittests
64.29% <ø> (ø)

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

Continue to review full report at Codecov.

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


markdown support in descriptions

We should at least be able to render markdown from descriptions.
Does anyone actually write markdown on phone apps? Should we support that on publish/channel description inputs?

I'd say Markdown is useful on both mobile and desktop. At the very least, I'd like to be able to write Markdown URLs and add images.


python3.pkgs.pythonRuntimeDepsCheckHook: skip empty specifiers

Prevent the hook from erroring out on missing specifiers, as reported for
highspy, which currently ships with a pre-release version, triggering
the following error message:

highspy not satisfied by version 1.7.1.dev1

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thanks for the quick fix @mweinelt !

I can confirm it fixing the repro I created here - https://github.com/silky/nix-python-dev-version-issue - so I'm very happy! :)

Well, funnily this broke the limits python package at the pythonRuntimeDepsCheck stage

Fixed in 354ccf49802d3313190756444d5a824b1af89c27, but I missed cherry-picking that onto staging-next. Feel free to pick it for master.


2525D Legacy Mapping Issues

Issues with table provided at: https://github.com/Esri/joint-military-symbology-xml/blob/master/samples/legacy_support/All_ID_Mapping_C_to_D.csv
Current Issues

Name
Key 2525C
Main Icon
Notes/Corrective Action
Workaround Available?
Fixed?

Friend: Land Unit (SIGINT)
IFGP-
0_310_0
Change Unit Frame from: 0_310_0 --> Equipment: 0_315_0

Friend : Land Unit (SIGINT)
IFGA-
0_310_1
Change Unit Frame: 0_310_0 --> Equipment: 0_315_1

Many Sustainment/SUPPLY Symbol (one example here)
S-G-USSL--

Missing "SUPPLY" Horizontal Bar

No MOOTW Echelon Indicators
Ex: O****------A---
O*-*
Echelon Indicators missing for MOOTW/SASO (Appendix E)
YES

No MOOTW FD/TF Indicators
Ex: O****-----F----
O**--F
FD/TF Indicators missing for MOOTW/SASO (Appendix E)
YES

Repeated Key2525Cs (non METOC)
Ex: S-A-WM----, S-G-IMC---, S-G-UUMSEC, S-G-UUMSET, G-G-DAB---, G-G-GLF---, E-O-A-----, S-G-UCAAAS

I know we discussed that a few (~8) METOC codes with the same function code would be repeated, but I wasn't expecting the others

METOC Weather
Ex. W---OBVA--

Missing D in all Dynamic Weather SIDCs
Yes

Future Issues to Check

Name
Key 2525C
Main Icon
Notes/Corrective Action
Workaround Available?
Fixed?

Stability Operations (So), Items, Refugees
O-I-R-----
11110400
Substitute Icon

some originally from table Corrections_To_JMSML_Produced_Mapping_C_to_D

Icons/symbols that aren't showing up and should be investigated:
GFGPGAG-------X
GFGPGLC-------X
GFGPGPRM------X
GFGPPN--------X
GFMPNM--------X
GFMPOA--------X
GFMPOAD-------X
GFMPOAO-------X
OFIPAC---------
WA-DBAFF----A--
WA-DIPFF---L---
WA-DPXCV---L---
WA-DWSTSWA--A--
WAS-PHT---P----
WAS-WP----P----
WAS-WSM-MHP----
WAS-WSVE--P----
WO-DHHDK--P----
WO-DIDID---L---
WOS-HDS---P----
WOS-HHDMDBP----
WOS-HHDMDFP----

@csmoore could you write some sort of explanatory text above the table so that this is more easily understood? I replicated the table but I think you can clarify this issue for when we get around to fixing these.

Let me know if you need clarification on any others, but here are some screenshot of some of the issues encountered:
(2525C foreground/transparent - 2525DtoLegacy Background/opaque)
Change SIGINT Unit Frame from: Land to Equipment:

Missing "SUPPLY" Horizontal Bar:

Repeated 2525C SIDCs:

I have evaluated each of the repeated key values and here are my findings:

Key
Explanation

S-A-WM----
Oversight in JMSML.  Redundant entry will be deleted

E-O-A-----
Oversight in JMSML.  Redundant entry will be deleted

S-G-IMC---
DISA's mapping xls file maps two 2525D symbols to one 2525C symbol.  JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC

S-G-UUMSEC
DISA's mapping xls file maps two 2525D symbols to one 2525C symbol.  JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC

S-G-UUMSET
DISA's mapping xls file maps two 2525D symbols to one 2525C symbol.  JMSML retains this two-to-one mapping so both 2525D SIDCs can convert to a single correct 2525C SIDC

S-G-UCAAAS
DISA's mapping xls is ambiguous, listing this as mapped AND retired.  I have contacted DISA for which is the correct choice

G-G-DAB---
A CP removing redundant control measures will fix this, when implemented

G-G-GLF---
A CP removing redundant control measures will fix this, when implemented

@abouffard - you can retain the 2-1 mapping as needed but please note that both shouldn't appear in the 2525C legacy mapping table

E-O-BJ---- needs to be fixed so the team amplifier is included as a separate part of its legacy mapping entry.
https://cloud.githubusercontent.com/assets/3090809/13637488/9884e7f8-e5d5-11e5-82bf-719175b02fb6.png

All of the redundant/repeated keys listed above have now been dealt with.  There should now be only one of each of those keys in the legacy mapping table.
Fixed this in the CSVs merged in #263

@csmoore , the SIGINT frames need to be changed from land unit to land equipment in the renderer plugin.  All SIDCs starting with "I-G-" need to be handled in this way.  Where/how do you want to track plugin issues, since this is not a JMSML issue.

@abouffard - confused - if this is the frame mapping for "I-G-" - why is this an issue with the plugin and why does it not appear in the Mapping Table this way? I.e. why is it not handled like every other frame case mapping?

@abouffard - for the "E-O-BJ----" issue mentioned in the comments - please add that to the original issue description above (we find that people don't always read through the individual comments/thread to pick out additional issues like this - especially when the comments get this lengthy - but they do read the 1st issue)

@abouffard - checking back on SIGINT frame issue - do you think this should be fixed in the data table or plugin?

@csmoore - it has been fixed in the table.  My bad for suggesting otherwise, that it was a plugin issue.  I was thinking along a different line when I suggested it was a plugin problem.  The legacy stylx I created last night should have SIGINT now drawing in equipment frames.  I'll be putting those JMSML corrections into GitHub tonight.

@abouffard - for the Sustainment/SUPPLY Symbol Bar issue noted above - rather than create completely new symbols - would it be possible to just add the "Bar" Icon to the "ExtraIcon" field in the mapping table - cases like this is what that field/column was intended for.

@csmoore, it would be one solution, but as the mapping table is being generated from JMSML and JMSML has a consistent way to handle icons that are unique to the legacy standards, this would be an inelegant exception.  Since the bar is full frame we'll both have to also contend with their being four versions of the situation, whether its four versions of a lone ExtraIcon bar or four versions of the complete barred supply icon.  It bothers me as it is that I need to handle the team amplifier on E-O-BJ.

Added to the original issue to investigate why some of the fonts are now showing as serif:

@abouffard - regarding last supply bar comment- we already handle both this full frame case and the case where a single additional icon in needed with the "special land unit entity" icons (in the "ExtraIcon" field) so I am not sure why the supply bar would be any different or less "elegant"

@csmoore , the "special land unit entity" is an exception whose alternative (creating many new SVGs that include those extra icons and the standard land unit icons together) would seriously bloat the number of SVGs in the mix.  Thus using the "ExtraIcon" approach is warranted in that case.
The "special land unit entity" icons have also already been removed from 2525D Change 1, in favor of new sector modifiers to convey the same information, so using "ExtraIcon" here as a temporary and, in my opinion, inelegant workaround is again warranted.
When we do implement the CP that removes these "special land unit entity" icons, I'd prefer to see the "ExtraIcon" concept go away completely, which could only happen if we minimize reliance on it.

I was also thinking this affected every supply icon - but on visual inspection, it looks like only the 2525C water and laundry are affected anyway (so only an extra ~10 icon):

But had we been aware of your temporary/for-special-land-unit-only intention when we developed/reviewed the legacy table - we might have taken another approach or at least named this column better.
What is the CP number for the D Change 1 mentioned? I am curious where this new/proposed modifier is going to fit into the current 20-char scheme.

It's part of a recently approved CP (16-010-AR).  @joebayles and I will be issuing a SSMC/JSP 16-1 trip report soon, and moving the recently approved CPs to Box, and as part of our engagement with the SSMC/JSP, JMSML.
16-010-AR Modify MIL-STD-2525D to Support Updates to Army Doctrinal Symbology.docx

Thanks for providing the CP here (funnily enough it also covered changing the supply bar to a modifier which would have helped with the issue above) - that does look like an improvement & I will be happy to see the "special entity subtype" exceptional case/rule go away.

Yes, although I argued against it as it creates another exception.  A full frame sector one modifier.

I guess I don't understand the exception in this case, the new/proposed (full frame) Supply Bar and Headquarters Element modifier 1's are icons that are tagged as full frame, so follow the normal full frame lookup rules.
But if it is somehow an exception (presumably because these are the only full-frame modifiers), then it is certainly the lesser of two evils

It's just that.  That the established rule for modifiers is that they are supposed to fit wholly within a sector., to ensure consistency and readability.  This becomes the lone exception, and I always counsel the committees to minimize exceptions.

Removed the list of missing symbols that need investigating and put them in a new issue #289

Closing per @Dbarnes1


Complete stories and better descriptions for most metanodes

This issue will be used to replace all issues which are effectively the same.
All processes support an elaborated:

abstract
introduction
methods
figure legend

We need to add them for most components in the platform..

This was addressed in several commits yesterday.


overnigth tests are failing: failure in [main:core activity]

See original issue on GitLab
In GitLab by [Gitlab user @jjardon] on Jun 23, 2019, 05:06
Job #238142465 failed for 2d57e14bdd8ac83ddf054ee25c1b97ceb2a2bfaf:
The only error reported seems to be:
[00:36:34][        ][    main:core activity                 ] FAILURE Build

In GitLab by [Gitlab user @juergbi] on Jun 24, 2019, 17:38
I see the following in the log (fetching of bootstrap/build/base-sdk/image.bst appears to fail):

BUG: Message handling out of sync, unable to retrieve failure message for element import element at bootstrap/build/base-sdk/image.bst [line 1 column 0]

Duplicate of #1040?

In GitLab by [Gitlab user @jjardon] on Jun 25, 2019, 08:03
Hey [Gitlab user @juergbi] I have seen that error on another pipelines that seems to go further. Maybe is related though

In GitLab by [Gitlab user @cs-shadow] on Aug 11, 2020, 22:59
Overnight tests have passed and failed and passed again many times over since the last year. Let's close this, and re-create new ones if/when those tests fail again.


Fixed issue with the process of adding a new question not properly ca…

…lling the AI function

Spoke w/ Michael via Slack and got his approval on this PR so I'm going ahead and merging


ARROW-16018: [Doc][Python] Run doctests on Python docstring examples

This PR adds doctest functionality to ensure that docstring examples are actually correct (and keep being correct).

[x] Add --doctest-module
[ ] Add --doctest-cython

There are some examples I removed from ds.dataset that I will add back as a follow-up when I will work on the docstring examples for Filesystems as they include, for example, reading from an S3 bucket and so I need a bit more time to find a good solution.

@raulcd @jorisvandenbossche the code now works for --doctest-modules (not sure about AppVeyor pyarrow test error ...). I would suggest creating a new workflow task that only runs the doctests in a separate PR following what Raul suggested when we talked.  There I would remove addopts option for doctest from setup.cfg.

Hi @AlenkaF creating a new job sounds good to me. I have checked out your PR locally and there are a couple of things that are not clear to me. If I try to run tests locally with the current setup python -m pytest python/pyarrow/tests/ no tests are collected:
$ python -m pytest python/pyarrow/tests/
============================================================== test session starts ===============================================================
platform linux -- Python 3.10.4, pytest-7.1.2, pluggy-1.0.0
rootdir: /home/raulcd/open_source/arrow/python, configfile: setup.cfg
plugins: hypothesis-6.46.3, lazy-fixture-0.6.3
collected 0 items

============================================================= no tests ran in 0.02s ==============================================================

This is because the new conftest skips collecting tests if we are using  --doctest-modules which is the default set up.
This is solved if I run tests using: pytest -r s -v --pyargs pyarrow but this is not how we have it documented on the developers guide.
I also have been able to reproduce the same appveyor failure if I remove the new conftest file, we might require some more investigation:
$ mv conftest.py no_conftest.py
$ pytest -r s -v  --pyargs pyarrow.tests
...
collected 4239 items / 2 errors / 6 skipped

===================================================================== ERRORS =====================================================================
______________________________________________ ERROR collecting pyarrow/tests/deserialize_buffer.py ______________________________________________
tests/deserialize_buffer.py:24: in <module>
    with open(sys.argv[1], 'rb') as f:
E   FileNotFoundError: [Errno 2] No such file or directory: '-r'
______________________________________________ ERROR collecting pyarrow/tests/read_record_batch.py _______________________________________________
tests/read_record_batch.py:26: in <module>
    with open(sys.argv[1], 'rb') as f:
E   FileNotFoundError: [Errno 2] No such file or directory: '-r'
============================================================ short test summary info =============================================================
SKIPPED [2] tests/test_cuda.py:32: could not import 'pyarrow.cuda': No module named 'pyarrow._cuda'
SKIPPED [2] tests/test_cuda_numba_interop.py:23: could not import 'pyarrow.cuda': No module named 'pyarrow._cuda'
SKIPPED [2] tests/test_jvm.py:27: could not import 'jpype': No module named 'jpype'
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
========================================================== 6 skipped, 2 errors in 2.69s ==========================================================

I would propose to not add --doctest-modules to the default pytest setup, this also solved the appveyor issue I was able to experience locally.

Thanks @raulcd for reviewing and testing locally!
For the first issue: python -m pytest python/pyarrow/tests/ doesn't collect any tests which is correct. The skip of all the tests is added to the conftest file on purpose as this feature should only check the docstring examples in .py files and not the unit tests. Could you try to run python -m pytest python/pyarrow/ and let me know how it goes?
For the second issue. The errors that you get when removing newly added conftest file are due to the fact that doctest collects all the .py files from pyarrow to run doctest on. Because some modules were not build (in you case cuda for example) doctest complains. For this reason new conftest file was added, to check which modules are not installed and tell doctest to skip the files that are connected to this missing modules.
The issue was solved by removing --doctest--modules from pytest setup because in that case doctest didn't run at all. So we need the conftest file to skip the files connected to the missing modules and then we should move --doctest-modules from pytest setup to a new job where we would add something similar to pytest --doctest-modules python/pyarrow/.

Thanks for helping me understand your comment better Raul and sorry for not seeing the problem! Now I get what Joris was trying to tell me yesterday also :)
Yes, tests are totally being skipped due to this change and that's not good at all.
I will remove --doctest-modules from pytest setup and this PR will be ready I think. Then I will make a separate one for --doctest-cython similar to this PR and the last one will be the PR for the CI job. @jorisvandenbossche what do you think?

I will remove --doctest-modules from pytest setup and this PR will be ready I think. Then I will make a separate one for --doctest-cython similar to this PR and the last one will be the PR for the CI job. @jorisvandenbossche what do you think?

Yes, that sounds good. Although I think you can maybe do the CI job one before tackling the cython doctests; in that way we can directly test it in CI in the cython PR.

I will do the CI one today and then we can decide which PR to close first =)

Further, I think we should still take a look whether we can deduplicate some content of the conftest.py files:

We should maybe see if it would be possible to de-duplicate the groups/defaults definitions in both conftest.py files (I suppose that if all of them are defined in the top-level conftest.py, that should be fine for the tests as well)

Yes, totally agree. Had it in mind. There is some small differences but I will try to put the code for groups/defaults definitions together in the top level (pyarrow) conftest.py file and leave the rest as is.
I will also check other comments and make changes. Thanks for reviewing!

Thanks! I would address the comments in this PR.
For the fixture scope follow-up, I will see if I will manage to put it into https://github.com/apache/arrow/pull/13216. Otherwise I will create a JIRA for it.

If the checks pass, this should be ready to merge @jorisvandenbossche.


Android. Debug build do not work as production build

Hello.
I've run into the issue where android debug build is working not the same as production build.
I made a simple app which shows only one carousel item at the time. Production build works fine. But debug with enabled/disabled remote debugging is working like this:

So, basically, I can move through all items in once during the first slide gesture (unexpected). But after that, I can slide only one item per sliding gesture (expected behaviour).
My code is simple:
<Carousel
  animationOptions={{
    easing: Easing.out(Easing.quad),
    duration: 350,
    isInteraction: false,
    useNativeDriver: true
  }}
  sliderWidth={Metrics.screenWidth}
  itemWidth={Metrics.screenWidth}
  inactiveSlideScale={1}
  inactiveSlideOpacity={1}
  slideStyle={styles.slide}
  decelerationRate={'fast'}
  swipeThreshold={5}
  scrollEndDragDebounceValue={10}
  onSnapToItem={ (index) => { this.setState({ currentStep: index }) } }
  ref={(carousel) => { this._carousel = carousel }}>
  {
    this.state.stepsData.map((step, index) => {
      return <StepInfo key={index} data={step} />
    })
  }
</Carousel>

I saw #34, but I would like to know whether I can do with my code to fix this behaviour. Am I missing something?

Hi @xvonabur,
ScrollView's performance on Android while debugging is everything but ideal. Unfortunately there is nothing we can do about it since React Native doesn't offer a proper scroll callback for its component. This means that when momentum is disabled (the default behavior), we have to rely on onScrollEndDrag and a bunch of hacks to make it work. In debug mode, onScrollEndDrag is apparently triggered a bit late, just enough to let you scroll through multiple slides...
Still, here are a few things you could try:

disabling JS Dev Mode in the dev menu, which usually result in a huge performance boost on Android
setting scrollEndDragDebounceValue to 0 for your debug build
setting enableMomentum to true for your debug build so that the callback will be triggered on onMomentumScrollEnd instead of onScrollEndDrag. Note that you will be able to scroll through multiple slides, but the callback might be more reliable.

Let me know if any of this helped!

Thanks, @br-arc.
I've already tried all your suggestions, but unfortunately neither of them suits me. It's not a big deal for me, cause production build is fine. I will use it for testing. It's really annoying to see such android only limitations, through. Hopefully some day things will be better.


feat: add generate API and Helm doc process with zh content update

What type of PR is this?
The API docs don't need to translate, so add generate API process with zh content update:

add a copy cmd to zh content after API generation both for api and helm doc.
update the docs-api-headings support zh content update

Not sure it is OK or not, please help to review.

@zirain all up to date, please help to review.


Could not find suitable distribution for devp2p

Checklist

installed pyethapp inside a virtualenv

System/environment

OS: OS X EL Capital
python version: 2.7
pyethapp version: latest
installation method (pip & pypi/git & setup.py): env LDFLAGS="-L$(brew --prefix openssl)/lib" CFLAGS="-I$(brew --prefix openssl)/include" python setup.py install

Expected behaviour
Extracting ethereum-1.1.0-py2.7.egg to /Users/yanik/code/crypto_tickets/env2/lib/python2.7/site-packages
Adding ethereum 1.1.0 to easy-install.pth file
Installed .../env2/lib/python2.7/site-packages/ethereum-1.1.0-py2.7.egg
Searching for devp2p>=0.7.1
Reading https://pypi.python.org/simple/devp2p/
No local packages or download links found for devp2p>=0.7.1
error: Could not find suitable distribution for Requirement.parse('devp2p>=0.7.1')

I tried install devp2p manually with pip install devp2p==0.7.1 but got next extension:
https://gist.github.com/yanik5/0b46fedcd30437f47e17

Hi,
I had that problem a couple of hours ago but I just reinstalled pyethapp and pip finds pydevp2p 0.7.1
so perhaps the website has been updated.
When I encountered the problem what did was to download the pydevp2p 0.7.1 from the git repo and use pip to install from the local files.
git clone -b v0.7.1 https://github.com/ethereum/pydevp2p.git pydevp2p
pip install -e path_to_pydevp2p
Cheers,
Aldo

@doyensyd thx, but this wont help at all.
I tried re-install it and now the next error appears:
https://gist.github.com/yanik5/da2446d8dad55f067351

Hi Yanik,
Which version of python 2.7 do you have?
Those errors that you listed in the file, I had when I was using python 2.7.5, they all disappeared when I used python 2.7.11 (or 2.7.9) .
Once you install python 2.7.11  you will need to set the virtualenv with it
virtualenv --python=/path_to_python2.7.11_exec .venv
I hope that helps.
Cheers,
aldo

@doyensyd, I was using Python 2.7.10 from the beginning inside virtualenv as well .
Probably should run it in ubuntu and avoid this headache.

@yanik5 From the log you posted it looks like you might not have all the necessary system dependencies installed. Please take a look in the readme and make sure you have all the packages installed.
A lot of the python core team also uses Macs so we want to make sure installation works smoothly.

@ulope
➜  ~ brew install automake pkg-config libffi gmp

Warning: automake-1.15 already installed
Warning: pkg-config-0.29.1 already installed
Warning: libffi-3.0.13 already installed
Warning: gmp-6.1.0 already installed

I believe problem in secp256k1 lib.

Please try again with PyEthApp 1.2.0. It should solve all of these problems. Please take note of the updated installation instructions in the readme.

We believe this issue has been fixed so I'm going to close it for now. If you still experience problems please open a new issue.


Record Icinga alert counts in Graphite

Adds a collectd plugin that gets the current service alert statuses and
records them as gauges in graphite. Records warnings and criticals
seperately, along with whether they’re acknowledged or not.
The eventual keys would be e.g.
monitoring-1_blue_integration.icinga.gauge-services_critical_unacknowledged

Good catches, thanks. Updated.


Can't find organization by name

Hi guys,
I can't find how to search an organization by name though that field is unique.
Try with search like
client.organizations.search(query: "Org name").fetch
or
client.organizations.search(name: "Org name").fetch
I got this message
 WARNING: Removed restricted keys ["query"] from parameters according to whitelist
is that function available? if not should it be exist?

Hello @hcuong !!
You need to use the Search endpoint for this (https://developer.zendesk.com/rest_api/docs/support/search#query-basics). E.G:
[1] pry(main)> client.search(query: "type:organization name:Zendesk").to_a
=> [#<ZendeskAPI::Organization {...}]

The search on the organizations resource only works with external_ids: https://developer.zendesk.com/rest_api/docs/support/organizations#search-organizations-by-external-id
I hope this helps!

yeah, it helps much. I am using search for external_ids. Will try with query field. Thank you!


proposal: chainable comparison operators

We certainly don't need this feature, but as I'm working on #114, I realized that it makes sense to be able to chain some comparison operators. C doesn't allow this, but we could do it and it would make perfect sense, so I'm writing this proposal to formally discuss the idea.

Chainable ==. a == b == c is equivalent to a == b and b == c (and b is evaluated only once).
Chainable < and <=. a OP b OP c is equivalent to a OP b and b OP c, where OP is one of < or <=.
Chainable > and >=. similar to above.

Python has this feature, but I'm proposing a more restrictive version than python's operator chaining. In python, you can do a != b != c, and I don't remember exactly what that does. That's a problem, so I'm proposing you can't do that in Zig. The proposal is that you can chain operators that work transitively, which is when a OP b and b OP c then it's obvious that a OP c. This is true for the above three cases, and isn't true of all any other mixture of comparison operators.
There's one subtle issue here, which is the hidden use of the short-circuit and operator. It may seem at first glance that a() == b() == c() would call all three functions when really it only needs to call the first two sometimes. That might be obvious to some readers, but might not be to all readers.
Fwiw, python has the hidden short circuit operator like I'm proposing.

I think this is one of those features that looks and sounds nice, but ultimately makes the language bigger, requires the programmer to remember more things, and isn't worth that cost.
a == b == c is barely more convenient than a == b and b == c, and plus I read that as (a == b) == c, which doesn't even make sense according to types, if a,b,c are integers. I don't find this feature worth it. I make a motion to reject this proposal.

sounds good.

At the moment its undecided whether zig switch statements should work with floating point values (#359, #3136). If we had this feature you could write expressions like this:
if (x < 0) {
} else if (0 <= x < 100) {
} else if (x >= 100) {
} else {
}

which I think is pretty elegant and more intuitive then using a switch statement. You can do this now with compound and, but it makes the code harder to read.  This change would be much simpler than the others suggested in (#359) so I think we should reconsider adding this feature.

I think this is one of those features that looks and sounds nice, but ultimately makes the language bigger, requires the programmer to remember more things, and isn't worth that cost.

This feature only needs a tiny change to the grammar of the language, and I think its worth it:
CompareOp := '<' | '<=' | '>' | '>=' | '==' | '!='

// New version
CompareExp := Exp (CompareOp Exp)+

// Old version
CompareExp_OLD := Exp CompareOp Exp

Of course there is the argument that it can be used to write confusing expressions, but in practice people won't unless they are deliberately trying to obfuscate their code.


Possibly update tutorials on data management.

They are quite out of date. Also, might be better to do on lib guides?
Hi All,
We've completed the updating of your course! Following is a list of remaining issues that need your attention (all problems with broken links). Please let us know if you have questions or require assistance.
Thank you!
Maria
Node	Issue
Introduction
https://www.e-education.psu.edu/dmpt/node/648
The two PSU library links are broken
Part 1
https://www.e-education.psu.edu/dmpt/node/654
Broken link - File Formats for Long-Term Access
Part 2
https://www.e-education.psu.edu/dmpt/node/661
Broken link - DataCite
Part 3
https://www.e-education.psu.edu/dmpt/node/666
One of the links is broken - Digital Object Identifier or DOI
https://www.e-education.psu.edu/dmpt/node/669
One of the links is broken - RA 23
Part 5
https://www.e-education.psu.edu/dmpt/node/679
broken link: ChemxSeer
https://www.e-education.psu.edu/dmpt/node/681
broken links: Penn State Access Accounts Storage Space (PASS), Tivoli Storage Manager
Next Steps
https://www.e-education.psu.edu/dmpt/node/701
librarian link broken (by consulting this list)
https://www.e-education.psu.edu/dmpt/node/702
Link on this page broken
Related Resources
https://www.e-education.psu.edu/dmpt/node/686
broken link:
Penn State Libraries' web pages on data management planning
https://www.e-education.psu.edu/dmpt/node/686
broken link: Subject Guides: Data Management and Publishing
https://www.e-education.psu.edu/dmpt/node/686
broken link: A Story Told in File Names
https://www.e-education.psu.edu/dmpt/node/686
broken link: http://datapub.cdlib.org/2013/04/24/closed-data-excuses-excuses/

It needs a lot of updating since its about 5 years old or so now. I unpublished it I think. We will get back to it after we have updated other web pages.


v3.4: Artifact Visualtions take 10s-30s to load

I'm running this in local dev. It should load instantly, but takes anywhere between 10s and 30s.
I am using my iPhone for Internet. Maybe that is problem I need to retry on Wifi.

Not actually a problem.


You're using markdown markup

Kind of ironic for an AsciiDoc project

titles using # are valid asciidoc, so why not? xd.
if they were markdown it won't compile using asciidoctor.

@clsource

if they were markdown it won't compile using asciidoctor.

That's not true. AsciiDoc accepts Markdown headers for compatibility, but they aren't the standard, and may confuse people new to AsciiDoc, reading the documentation, and wondering why hash marks aren't used everywhere.
If the purpose of this project isn't to promote AsciiDoc, then what's it for?

from the docs:

In addition to the equals sign marker used for defining section titles, Asciidoctor recognizes the hash symbol (#) from Markdown. That means the outline of a Markdown document will be converted just fine as an AsciiDoc document.

In my experience most people come from markdown syntax. So I prefer to have familiarity. Using a similar sintax gives you one less thing to learn.

from the docs:

In addition to the equals sign marker used for defining section titles, Asciidoctor recognizes the hash symbol (#) from Markdown. That means the outline of a Markdown document will be converted just fine as an AsciiDoc document.

In my experience most people come from markdown syntax. So I prefer to have familiarity. Using a similar sintax gives you one less thing to learn.

That's a valid perspective, but I suspect people looking for familiarity will avoid an AsciiDoc-based template entirely.
I don't know about your other users, but I tried this because I wanted to learn and use more AsciiDoc. I chose AsciiDoc because I wanted to get away from some of the irritants of Markdown.


Fix for Missing Swift 3.2 and Swift 4.0 Support Issue #580

Created Swift 3.2 and Swift 4.0 Folders to ensure building Earlgrey for Projects using Swift 3.2 and Swift 4.0

I signed it!

I signed it!

If they are the same, can we make a change here:
https://github.com/google/EarlGrey/blob/master/gem/lib/earlgrey/configure_earlgrey.rb#L381
so when the swift file is not found, use the backup 3.0 version?

Yes they are the same. We can use the Swift 3.0 Version. I can implement this tomorrow.

@bootstraponline Is it time for us to deprecate he 3.0 and 2.3 files for these? At least the 2.3 one?

@bootstraponline Is it time for us to deprecate he 3.0 and 2.3 files for these? At least the 2.3 one?

I think so. We should probably only support the latest stable Xcode release. Swift is changing too rapidly to support all the versions forever.

@tirodkar @wuhao5 Could we merge this if it's good to go?

I think the decision is to not add another swift file but have gem to handle it.

Hello, I thought we were waiting on the additions to the gem here. Is that to be done in a separate PR?

closing in favor of #591


Set draw order for windows

Hello!
I'm writing an FPS counter for my project. I'd like it to sit in the top left, always being drawn on top of anything else. Is there a way to specify the order in which windows are drawn, something like a z-order function?
I imagine it could be done in ColibriManager.cpp::render to just sort the list of windows, but do you know of a better way?
Thanks!

The order in which windows are created (in other words, the order of ColibriManager::m_windows for root windows) is respected.
You can call window->setVisualsEnabled( false ); which will only hide the window visually but not its children widgets. That is one way you can arrange visibility order.
Personally I use this:
// C++
m_bgWindow = m_colibriManager->createWindow( 0 );
m_bgWindow->setVisualsEnabled( false );
m_bgWindow->setSkin( "EmptyBg" );
m_bgWindow->setSize( m_colibriManager->getCanvasSize() );
m_bgWindow->m_breadthFirst = true;

// Skins.colibri.json
"EmptyBg" :
{
	"material" : "EmptyBg",
	"tex_resolution" : [1, 1],
	"grid_uv" :
	{
		"all" : [[0, 0, 1, 1], [0, 0]]
	},
	"borders" :
	{
		"all" : [0, 0]
	}
}

// Skins.material
hlms EmptyBg unlit
{
}

Currently there is no way to reorder ColibriManager::m_windows (or Window::m_childWindows for windows inside windows), but there is no technical limitation, it could be implemented as a one-time sort whenever the order gets dirty.
I'm trying to stay away from sorting every frame.

Thanks for your quick response dark_sylinc,
Unfortunately your suggestion doesn't really solve my problem. The problem is that some windows are drawn ontop of each other rather than there being problems with transparency.

You can see this in my very work in progress health bar. Assuming that even with the window background removed the text would still be drawn ontop. For my project I can't control the order in which windows are created, so I need a way to manually specify it.
I'll make an attempt at implementing a system as you suggested with dirty flags to specify changes in order and do a PR. I'll keep speed in mind, I agree we shouldn't be sorting them each frame :)

You have two ways:

A quick hack where you expose m_windows and manually manipulate it
Add Window::setZOrder()/getZOrder() which sets an uint16_t and notifies its parent that it is dirty, so that that m_windows / m_childWindows gets queued up for stable re-sorting (based on that u16) on the next update. Sable sort is needed to respect creation order if two windows have the same sort Id.

I've made progress on this.
https://github.com/edherbert/colibrigui/commit/5d3df9e36fc623c9a3fac2b83dc0561e425df2a4

Having added a example of it to the demo, it works fine. One problem I had though which makes me consider a re-think. ColibriManager stores a list of windows which are drawn in order, however for windows with child windows the important list is the widgets list. Even though they store a child windows list, they're drawn relative to the widgets list. I ended up having to sort the widgets list trying to avoid anything that wasn't a window.
This makes me think, it would probably be better if all widgets were aware of z-ordering, as then I would be able to sort that list without any of that weirdness. Considering windows inherit from widgets anyway and are attached to parent windows like widgets it makes sense. This means all widgets would have the setZOrder function and store their zOrder (I'm using 8 bits not 16). Does that sound sensible? I'm hoping that won't effect the breadth first traversal or anything (I don't think it will).

Even though they store a child windows list, they're drawn relative to the widgets list. I ended up having to sort the widgets list trying to avoid anything that wasn't a window.

I forgot about this.
The solution would be (I'm using 32 bit values but works for 16 and 8):
void setZOder( uint32 order )
{
     COLIBRI_ASSERT_LOW( !(order & ( (1u << 31) | (1u << 30) ) ) && "Invalid order value. These bits are reserved" );

     m_order = order;
     // Ensure renderables go after non-renderables
     if( isRenderable() )
         m_order |= 1u<<30u;
     // Ensure windows always go last
     if( isWindow() )
         m_order |= 1u<<31u;
}

Btw make sure the relative order of windows in m_children and m_childWindows order matches. While I don't remember that being a problem, it could be in the future. So it's best if they just match.

Even though they store a child windows list, they're drawn relative to the widgets list. I ended up having to sort the widgets list trying to avoid anything that wasn't a window.

I forgot about this.
The simple solution would be (I'm using 32 bit values but works for 16 and 8):
void setZOder( uint32 order )
{
     COLIBRI_ASSERT_LOW( !(order & ( (1u << 31) | (1u << 30) ) ) && "Invalid order value. These bits are reserved" );

     m_order = order;
     // Ensure renderables go after non-renderables
     if( isRenderable() )
         m_order |= 1u<<30u;
     // Ensure windows always go last
     if( isWindow() )
         m_order |= 1u<<31u;
}

Btw make sure the relative order of windows in m_children and m_childWindows order matches. While I don't remember that being a problem, it could be in the future. So it's best if they just match.

I've made it so widgets store the z order and the children and child windows match in their lists.
Quick question, what's the benefit of having the list ordered renderables then windows as described above? I would have thought if the user specified say a window to go behind a button then that's where it should go. Is this just a means to avoid headache later with mouse picking or something?

Having them sorted that way allows us to perform certain programming tricks such as:
itor = m_children.begin();
end = m_children.end();

while( itor != end )
{
// Work on all widgets and windows
++itor;
}

itor = m_children.begin();
end = m_children.begin() + numWindows;

while( itor != end )
{
// Work only on windows
++itor;
}

which otherwise requires virtual calls, and keeps the conceptual difference between windows and widgets. And with minimal memory footprint.
Messing up this order will mess up functionality (i.e. it could crash)
As for explicitly rendering a widget below their window, that is unwanted (for non-technical reasons). Colibri follows the desktop metaphor.
And yes, having an object that belongs to a background window being drawn on above a foreground would mess up mouse, keyboard navigation, scrolling and other sort of interactions, not to mention disorienting for users.
There may be an occasional valid case to make an exception where it'd make sense, but more often than not, everyone thinks they've got the best case to make an exception for and the functionality ends up getting abused.
Good UX is really hard. If you mess one little detail your users will notice and suffer.


code challenge 16

[x ] Top-level README “Table of Contents” is updated
[ x] README for this challenge is complete
- [x ] Summary, Description, Approach & Efficiency, Solution
- [ x] Picture of whiteboard
- [ x] Link to code
[ x] Feature tasks for this challenge are completed
[ x] Unit tests written and passing
- [ ] “Happy Path” - Expected outcome
- [ ] Expected failure
- [x ] Edge Case (if applicable/obvious)


fix: publisher_id was missing from received subscription items

Closes https://github.com/momentohq/dev-eco-issue-tracker/issues/934

Can you add a backlog issue to exercise this in an example?


No such file or directory: 'client_secret.json'

With v0.9.3, gmail-yaml-filters seems to expect client credentials even though I'm just using it to convert YAML to XML:
> pip3 install -U gmail-yaml-filters
> gmail-yaml-filters filters.yaml > filters.xml
/home/mark/.local/lib/python3.8/site-packages/oauth2client/_helpers.py:255: UserWarning: Cannot access /home/mark/.credentials/gmail_yaml_filters.json: No such file or directory
  warnings.warn(_MISSING_FILE_MESSAGE.format(filename))
Traceback (most recent call last):
  File "/home/mark/.local/lib/python3.8/site-packages/oauth2client/clientsecrets.py", line 121, in _loadfile
    with open(filename, 'r') as fp:
FileNotFoundError: [Errno 2] No such file or directory: 'client_secret.json'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mark/.local/bin/gmail-yaml-filters", line 8, in <module>
    sys.exit(main())
  File "/home/mark/.local/lib/python3.8/site-packages/gmail_yaml_filters/main.py", line 93, in main
    credentials = get_gmail_credentials(client_secret_path=args.client_secret)
  File "/home/mark/.local/lib/python3.8/site-packages/gmail_yaml_filters/upload.py", line 275, in get_gmail_credentials
    flow = oauth2client.client.flow_from_clientsecrets(client_secret_path, scopes)
  File "/home/mark/.local/lib/python3.8/site-packages/oauth2client/_helpers.py", line 133, in positional_wrapper
    return wrapped(*args, **kwargs)
  File "/home/mark/.local/lib/python3.8/site-packages/oauth2client/client.py", line 2134, in flow_from_clientsecrets
    client_type, client_info = clientsecrets.loadfile(filename,
  File "/home/mark/.local/lib/python3.8/site-packages/oauth2client/clientsecrets.py", line 165, in loadfile
    return _loadfile(filename)
  File "/home/mark/.local/lib/python3.8/site-packages/oauth2client/clientsecrets.py", line 124, in _loadfile
    raise InvalidClientSecretsError('Error opening file', exc.filename,
oauth2client.clientsecrets.InvalidClientSecretsError: ('Error opening file', 'client_secret.json', 'No such file or directory', 2)

The previous version (pip3 install -U gmail-yaml-filters==0.9.2) works fine.

Thanks for the bug report! This has been fixed in v0.9.4.


User main Menu questions

Ask user if they want to view departments, roles, employees,   add department,  add a role, add an employee,  update an employee role

completed by @gsaaad


MRG: Fix plot_projs_topomap

Fixes one bug with plot_projs_topomap but I found another that we should probably address in a different PR (when someone finds time).
@kambysese this should fix the bug you were hitting.

Current coverage is 87.40% (diff: 100%)

Merging #3694 into master will increase coverage by <.01%

@@             master      #3694   diff @@
==========================================
  Files           343        343
  Lines         60900      60904     +4
  Methods           0          0
  Messages          0          0
  Branches       9309       9309
==========================================
+ Hits          53231      53235     +4
  Misses         4912       4912
  Partials       2757       2757

Powered by Codecov. Last update 65a4eb0...869e0d6

LGTM

Thanks @Eric89GXL


Dry-run doesn't output anything

Hello,
I'm trying to use renamer without success.
So, I tried with dry-run option, but it doesn't report anything like:

the folder where it tries to search
the files it found or try to find

Is there a way to verbose the output to know what it is doing ?
Thanks in advance for your help.

have you tried the --verbose option?

I removed '' and it seems to be better.
I'm trying to rename extension like this without success:
renamer --find .v1.mp4 --replace .v5.mp4 lib/test --verbose

Could you help me a little more ?

you only passed one file to that command (lib/test).. you need to pass all the files/folders you wish to inspect for renaming.. try this:
renamer --find .v1.mp4 --replace .v5.mp4 'lib/test/**/*.mp4'  --verbose --dry-run

take care, always start with --dry-run.. major damage could be done if you get your commadn wrong..

renamer --find .v1.mp4 --replace .v5.mp4 lib/test/**/*.mp4 --verbose --dry-run

It seems to hate '' on windows!
Thank you very much. It is working now. +1

yeah, you don't need the quotes on Windows.. pleased it's working now.


OCPCLOUD-2053: Update dependencies to K8s 1.27

This updates the dependencies to the latest versions to support K8s 1.27.
TODO: update reference to machine-api-operator once https://github.com/openshift/machine-api-operator/pull/1142 merges

/hold
until https://github.com/openshift/machine-api-operator/pull/1142 merges

/test unit

/test unit

/retest

/retest

/approve
/lgtm

/approve
/lgtm

/retest

/retest

/retest

/retest

/approve
/lgtm

/retest

Bootstrap failed:
/retest

/test e2e-nutanix-operator

/override ci/prow/e2e-nutanix-operator
The tests passed barring the cluster autoscaler balance similar nodes test. This test needs to be taught about platform specific labels and as such, isn't working on Nutanix yet. I'm confident this PR is ok without that single test pass, we will make sure to update the E2E to account for Nutanix for future PRs
CC @elmiko

/label qe-approved

/hold cancel
Stale hold


FancyZones broken/buggy with Photoshop

Description of the new feature / enhancement
Title says it all. FancyZones don't work properly with newer versions of Adobe Photoshop -- the app fails to snap properly to the zone, specifically if you release the window with the top of the app somewhere in the middle of the zone. If you release the window with the top of the app near the top of the zone, it usually works. But you really have to line it up to get it to work. Which kind of defeats the purpose of FancyZones, to allow me to lazily snap apps to a specific zone.
It's worth noting that I tested an older version of Photoshop (2021) and it works fine. In fact, every other app I have trie works fine. But with Photoshop 2024, unless you intentionally line up the top of the app with the top of the zone, it sort of visually snaps to the zone for a split-second, then the window settles to wherever your mouse dropped the window. I also tested Photoshop 2023 and it also has this bug.
Scenario when this would be used?
This kind of defeats the purpose of FancyZones, to allow me to lazily snap apps to a specific zone.
Supporting information
No response

/bugreport

PowerToysReport_2023-09-22-09-12-20.zip
PowerToysReport_2023-09-22-09-12-20.zip

Thank you, here is the file.
PowerToysReport_2023-09-22-09-12-20.zip


Bug release rf count dependency when query canceled

Proposed changes
release rf count dependency when query canceled
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall


export.sh doesn't work on macOS Catalina 10.15.x -- zsh default shell (IDFGH-3301)

Environment

Development Kit: n/a
Kit version (for WroverKit/PicoKit/DevKitC):  n/a
Module or chip used: n/a
IDF version: v4.1-beta1-182-g9778b163b
Build System:  CMake
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0
Operating System:  macOS
Using an IDE?:  No
Power Supply: n/a

Problem Description
export.sh doesn't work on macOS Catalina
Expected Behavior
export.sh works on macOS Catalina
Actual Behavior
export.sh assumes bash to be the default shell. This assumption doesn't hold on macOS Catalina where the default shell is zsh.
Steps to reproduce

set zsh as default shell
run export.sh

Debug Logs
export.sh stops with
IDF_PATH must be set before sourcing this script"

Solution
Modify export.sh with the following (I can submit a PR)
diff --git a/export.sh b/export.sh
index 0408a76bb..6b692e273 100644
--- a/export.sh
+++ b/export.sh
@@ -15,7 +15,7 @@ function realpath_int() {
 function idf_export_main() {
     # The file doesn't have executable permissions, so this shouldn't really happen.
     # Doing this in case someone tries to chmod +x it and execute...
-    if [[ -n "${BASH_SOURCE}" && ( "${BASH_SOURCE[0]}" == "${0}" ) ]]; then
+    if [[ -n "${SHELL_SOURCE}" && ( "${SHELL_SOURCE[0]}" == "${0}" ) ]]; then
         echo "This script should be sourced, not executed:"
         echo ". ${BASH_SOURCE[0]}"
         return 1
@@ -24,12 +24,12 @@ function idf_export_main() {
     if [[ -z "${IDF_PATH}" ]]
     then
         # If using bash, try to guess IDF_PATH from script location
-        if [[ -n "${BASH_SOURCE}" ]]
+        if [[ -n "${SHELL_SOURCE}" ]]
         then
             if [[ "$OSTYPE" == "darwin"* ]]; then
-                script_dir="$(realpath_int $BASH_SOURCE)"
+                script_dir="$(realpath_int $SHELL_SOURCE)"
             else
-                script_name="$(readlink -f $BASH_SOURCE)"
+                script_name="$(readlink -f $SHELL_SOURCE)"
                 script_dir="$(dirname $script_name)"
             fi
             export IDF_PATH="${script_dir}"
@@ -95,7 +95,16 @@ function idf_export_main() {
     echo ""
 }

+if [ -n "$ZSH_VERSION" ]; then
+   SHELL_SOURCE=${(%):-%x}
+elif [ -n "$BASH_VERSION" ]; then
+   SHELL_SOURCE=BASH_SOURCE
+else
+   echo "This script only works on bash or zsh."
+fi
+
 idf_export_main

+
 unset realpath_int
 unset idf_export_main

Hi @tmspzz, IDF_PATH detection for zhs was implemented in https://github.com/espressif/esp-idf/commit/1c4c584e2845a34eb6d2e52e81fd5d3b9d0a73f3. Will backport this to release/v4.1

@igrr that's nice! Thanks!
Also, I'm pretty sure you're aware of it, but macOS loudly complains about using python instead of python3. And of course /usr/bin/env python defaults to python2

No, I'm not aware of that. What error are you getting with regards to python?

I think it's the same as https://github.com/espressif/esp-idf/issues/4774
But since the scripts start with #!/usr/bin/env python  there is no (good?) way to switch to python3

How about brew install python3 (or any other method of your choice), and then make sure /usr/local/bin/python symlink points to /usr/local/bin/python3?

@tmspzz if indeed the same as #4774, this solution worked for me.
I'm not sure how well that might work on a Mac.

Has been fixed on release/v4.1 with https://github.com/espressif/esp-idf/commit/6ae54e7fd29fd28698dfd5c90d43033185f0b199.

Any chance this can backport into a v3.3.5? 🙏

Hi @malachib, 3.3 releases did not use install.sh/export.sh yet, please refer to the getting started guides for that version: https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/index.html#setup-toolchain.

Really?  I see the install.sh right there in the v3.3.4 tag checkout -- but not an issue, I've already got the toolchain set up as described in that link so good to go.  Thank you for the response


[Bug report]useJack error

When i  use Jack using Gradle.
 buildToolsRevision '24.0.0-rc2'
    defaultConfig {
      // Enable the experimental Jack build tools.
      useJack = true
    }

Okhttp report the error.
04-12 14:57:38.242 11092-11152/? E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
                                                   Process: com.packageName, PID: 11092
                                                   java.lang.VerifyError: okhttp3/ResponseBody
                                                       at okhttp3.internal.http.HttpEngine.<clinit>(Unknown)
                                                       at okhttp3.RealCall.getResponse(Unknown)
                                                       at okhttp3.RealCall$ApplicationInterceptorChain.proceed(Unknown)
                                                       at okhttp3.RealCall.getResponseWithInterceptorChain(Unknown)
                                                       at okhttp3.RealCall.access$100(Unknown)
                                                       at okhttp3.RealCall$AsyncCall.execute(Unknown)
                                                       at okhttp3.internal.NamedRunnable.run(Unknown)
                                                       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
                                                       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
                                                       at java.lang.Thread.run(Thread.java:841)

This is a problem with Jack, not OkHttp. Please report to the Android team at http://b.android.com/.

I had this problem before and found https://code.google.com/p/android/issues/detail?id=82691


Rejection sampling for likelihood-based methods

API change
Old:
posterior = build_posterior(sample_with_mcmc=True)

New:
posterior = build_posterior(sample_with="mcmc")  # or "rejection"

Code structure changes
We already had a method that did something similar to rejection sampling: sample_posterior_within_prior. This method was slightly changed (add uniformly drawn random numbers for general proposals) and I added code that can (optionally) search for a factor such that the proposal is strictly above the target potential. The new method is called sbiutils/rejection_sample(). The method sample_posterior_within_prior does not exist anymore.
All three methods (SNLE, SNPE, SNRE) use rejection_sample if sample_with='rejection'. SNLE and SNRE use the prior as proposal. SNPE uses the neural net as proposal.
All changes

[x] remove sample_with_mcmc: bool in favor of sample_with: str. This parameter accepts [mcmc | rejection] but it paves the way for further sampling methods. Default is mcmc
[x] New method rejection_sample() in sbi/mcmc/rejection_sampling.py
[x] Use it also for SNPE and SNRE
[x] deal with the entire infrastructure (e.g. store as hyperparameters etc...)
[x] Test all results
[x] Make everything backward-compatible
[x] Use rejection sampling in some of our tests? (just because it's super fast)
[x] avoid three flow-passes for SNPE via binary_rejection_criterion=True and get rid of ignore_scaling
[x] gpu tests

@janfb This is ready for review now. I will be testing more extensively in my own project now -- there might still be small bugs which I will fix in the process of doing that. However, the main code is now in place. Eventually, I decided to keep two function: rejection_sample_posterior_within_prior() and rejection_sample(). They are very related, but I think you were right: it created more code to keep them as a single function. Nonetheless, the underlie the same interface:
sample_with="rejection"

If rejection_sampling_parameters={"proposal"=...} is not specified, we use rejection_sample_posterior_within_prior(). If a proposal is specified, we use rejection_sample().


Updated validations.py python script

Updated validations.py python script.
Fixed the behvior of validate_user function in validation.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

@googlebot I signed it !


add php8.3 version

Empty upcoming list until php8.4 rc comes

I've reviewd https://github.com/shivammathur/setup-php#tada-php-support indeed has 8.4 as an option

That poses an interesting challenge. Personally I only use that option when the first alpha is out and I've started building it through https://github.com/wyrihaximusnet/docker-php and then update the upcoming release here. So going to 8.4 for the upcoming release isn't an option. However, adding it as a nightly toggle is the way to forward IMHO.

I'd tend to agree with you, but as the README file states "The 4rth output is
upcoming and will be populated with the upcoming but unreleased next minor or major version of PHP" as long as that version is available in shivammathur/setup-php and thus can be used it is the next unreleased version
We can simply leave the upcoming list empty until first alpha is available or event maybe RC, but we can argue as well it is already in a separate configuration sot it is end user's responsibility for configuring it
If you want I can empty the upcoming releases array again, and you can implement a new nightly flag

I've just made the change, hope the tests pass
Of course you can tag me

Will tag you in that nightly, and got an extension detection upgrade to do as well before releasing the next version


Differentiate resources by the cluster name

Thanks @baixiac!
How does the upgrading process works with Terraform? Once this PR is merged, if I run plan and apply will everything be safely renamed to the new structure?


WalkingLoggerModule is not running properly

When trying to use the WalkingLoggerModule I get the following error

[INFO] [RPC Server] The following data will be stored:  time dcm_x dcm_y dcm_des_x dcm_des_y dcm_des_dx dcm_des_dy zmp_x zmp_y zmp_des_x zmp_des_y com_x com_y com_z com_des_x com_des_y com_des_z com_des_dx com_des_dy com_des_dz lf_x lf_y lf_z lf_roll lf_pitch lf_yaw rf_x rf_y rf_z rf_roll rf_pitch rf_yaw lf_des_x lf_des_y lf_des_z lf_des_roll lf_des_pitch lf_des_yaw rf_des_x rf_des_y rf_des_z rf_des_roll rf_des_pitch rf_des_yaw torso_pitch torso_roll torso_yaw l_shoulder_pitch l_shoulder_roll l_shoulder_yaw l_elbow l_wrist_prosup l_wrist_pitch l_wrist_yaw r_shoulder_pitch r_shoulder_roll r_shoulder_yaw r_elbow r_wrist_prosup r_wrist_pitch r_wrist_yaw l_hip_pitch l_hip_roll l_hip_yaw l_knee l_ankle_pitch l_ankle_roll r_hip_pitch r_hip_roll r_hip_yaw r_knee r_ankle_pitch r_ankle_roll torso_pitch_des torso_roll_des torso_yaw_des l_shoulder_pitch_des l_shoulder_roll_des l_shoulder_yaw_des l_elbow_des l_wrist_prosup_des l_wrist_pitch_des l_wrist_yaw_des r_shoulder_pitch_des r_shoulder_roll_des r_shoulder_yaw_des r_elbow_des r_wrist_prosup_des r_wrist_pitch_des r_wrist_yaw_des l_hip_pitch_des l_hip_roll_des l_hip_yaw_des l_knee_des l_ankle_pitch_des l_ankle_roll_des r_hip_pitch_des r_hip_roll_des r_hip_yaw_des r_knee_des r_ankle_pitch_des r_ankle_roll_des torso_pitch_ret torso_roll_ret torso_yaw_ret l_shoulder_pitch_ret l_shoulder_roll_ret l_shoulder_yaw_ret l_elbow_ret l_wrist_prosup_ret l_wrist_pitch_ret l_wrist_yaw_ret r_shoulder_pitch_ret r_shoulder_roll_ret r_shoulder_yaw_ret r_elbow_ret r_wrist_prosup_ret r_wrist_pitch_ret r_wrist_yaw_ret l_hip_pitch_ret l_hip_roll_ret l_hip_yaw_ret l_knee_ret l_ankle_pitch_ret l_ankle_roll_ret r_hip_pitch_ret r_hip_roll_ret r_hip_yaw_ret r_knee_ret r_ankle_pitch_ret r_ankle_roll_ret
[ERROR] [updateModule] The size of the vector is not the one expected. Expected:  130  received:  112
[INFO] |yarp.os.RFModule| RFModule closing.

This error seems to be because of 85cdd95ad79c079e4443b714d417b28f62702dc3.
The temporary workaround, as suggested by @S-Dafarra  is to checkout back to before 85cdd95ad79c079e4443b714d417b28f62702dc3 to be able to log and plot data properly. However this issue is to document the problem.

cc @GiulioRomualdi

Hi @mebbaid, this is actually an intrinsic problem of the implementation of the WalkingLogger. Now I try to explain to you why this is happening. The explanation is based on the latest devel commit: https://github.com/robotology/walking-controllers/commit/9d8dde45159e43187d672ad9bf4991734714d7b7.
The WalkingLogger is an application that you run and the WalkingController established the connection if the dump_data parameter is set to 1.
If you check the WalkingLogger code you will see that the logger is actually composed of a WalkingLoggerServer (this is the application that you run) and the WalkingLoggerClient (this is the library that you load in the WalkingModule)
To start logging the parameter you should call startRecord method. The first parameter of the logger is record and then the list of each element of the vector that will be saved. This is required to define the  first row of the csv table
https://github.com/robotology/walking-controllers/blob/9d8dde45159e43187d672ad9bf4991734714d7b7/src/WalkingModule/src/Module.cpp#L1354-L1384
In this case, the table is composed of the following columns

dcm_x
dcm_y
dcm_z
.....
r_ankle_pitch_ret
r_ankle_roll_ret

As you can see the code has been committed in status such that we log 29 robot joints and 29 retargeting joints (this is the status in which we log the data if the retargeting is enabled)
To log the data you send the data to logger you should call sendData
https://github.com/robotology/walking-controllers/blob/9d8dde45159e43187d672ad9bf4991734714d7b7/src/WalkingModule/src/Module.cpp#L887-L897
as you can see here the robot joint state the desired joint state and the retargeting joint states are sent using the following vectors
m_robotControlHelper->getJointPosition(),
m_qDesired,                                     m_retargetingClient->jointValues()

If you run the walking with the joypad the dimension of the three vectors is equal to 23 each.
sendData is a template variadic function that is in charge to attach all the vectors together in a long yarp::os::Vector and send it to the logger.
As a consequence, if the number of the elements is defined here is different from the sum of the size of the all vectors used here you will have an error.
I hope that the problem is now clear. Now let's move to the possible solutions:

Commit a new version of the code in which we remove some joints here to make everything work: you can do this in your local branch but it does not make sense to push it, indeed you will be able to log the data if you run the walking with the joypad but not with the xsens/oculus.
Restructure the WalkingLogger such that the size is automatically handled by configuration files: this could be a solution but since we have to spend time to implement it I would try to move the effort to something better than a logger that I wrote during the master thesis 😃
Try to adapt the YarpRobotLoggerDevice in order to accept also values data from the walking: I like this solution. It is more complex but more modular. What we can do in this case is to define yarp devices that can be used to stream matrices/vectors using thrift messages. You can check here for an example. This device can be used to collect data in the YarpRobotLoggerDevice (or also in the YarpTelemetryDevice) or also to visualize them on what @nunoguedelha is implementing

If you want to try to solve this problem it would be wonderful, you can schedule a meeting and we can discuss it together
cc @isorrentino

cc @traversaro

@GiulioRomualdi thanks for the clear explanation of the problem and the suggested solutions. Indeed for the time being I am working on a different local branch to be able to plot.
Concerning the suggested solutions, I would agree with your advice on proceeding with option (3) not least because you know better the "optimal" solution to the problem, and also for the selfish reason of wanting to get involved more with implementation aspects.
I can organize a meeting for this Friday together with you and the team members tagged if that is OK.

Great explanation @GiulioRomualdi. I would proceed with the third option :)

3. (or also in the YarpTelemetryDevice)

I guess you refer to the telemetryDeviceDumper here, right? xref https://github.com/ami-iit/bipedal-locomotion-framework/issues/189

If I am not wrong solution 3 from https://github.com/robotology/walking-controllers/issues/95#issuecomment-975332410 was implemented right? We probably can close this issue.

yes, indeed this issue was solved with this YarpLoggerDevice. Closing


Update DCR and Try Out page

Fix the review comments in sms otp page with sample configurations and try out page with valid sample request and responses.

Please check and verify if we need to add the executors shared with us.  Please set up a pack (do not run configure.sh) and see if those executors are there. If not we need to add them to the docs. If they are there, we can avoid documenting that.