Disable PEP 517 error with editable install

Issue description
pipenv install with an editable source leads to error "Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta:legacy in pyproject.toml".
However, the project doesn't use any `pyproject.toml, so I have no idea where this is coming from.
The relevant part of the pipfile is
[packages.e1839a8]
path = "."
editable = true

https://github.com/tobiasdiez/sage/blob/fe43eb81da698ab06536c6adf0694b4c508fd65f/src/Pipfile#L29-L31
Expected result
Successful installation.
Actual result
Installing 'e1839a8'
$ ['/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/bin/pip', 'install', '--verbose', '--upgrade', '--no-use-pep517', '--exists-action=i', '-r', '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pipenv-15afg11l-requirements/pipenv-rhh7sbpy-requirement.txt', '-i', 'https://pypi.org/simple']
Using source directory: '/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/src'
Using pip 20.2.1 from /Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip (python 3.8)
Non-user install by explicit request
Created temporary directory: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-ephem-wheel-cache-6w3f6p4l
Created temporary directory: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-tracker-wg3nc7wc
Initialized build tracking at /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-tracker-wg3nc7wc
Created build tracker: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-tracker-wg3nc7wc
Entered build tracker: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-tracker-wg3nc7wc
Created temporary directory: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-install-e82f8g60
Obtaining file:///Users/runner/work/sage/sage/src (from -r /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pipenv-15afg11l-requirements/pipenv-rhh7sbpy-requirement.txt (line 1))
  Added file:///Users/runner/work/sage/sage/src (from -r /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pipenv-15afg11l-requirements/pipenv-rhh7sbpy-requirement.txt (line 1)) to build tracker '/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-tracker-wg3nc7wc'
Exception information:
Traceback (most recent call last):
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/cli/base_command.py", line 216, in _main
    status = self.run(options, args)
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/cli/req_command.py", line 182, in wrapper
    return func(self, options, args)
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/commands/install.py", line 324, in run
    requirement_set = resolver.resolve(
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/resolution/legacy/resolver.py", line 183, in resolve
    discovered_reqs.extend(self._resolve_one(requirement_set, req))
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/resolution/legacy/resolver.py", line 388, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/resolution/legacy/resolver.py", line 326, in _get_abstract_dist_for
    return self.preparer.prepare_editable_requirement(req)
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/operations/prepare.py", line 525, in prepare_editable_requirement
    abstract_dist = _get_prepared_distribution(
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/operations/prepare.py", line 91, in _get_prepared_distribution
    abstract_dist.prepare_distribution_metadata(finder, build_isolation)
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/distributions/sdist.py", line 33, in prepare_distribution_metadata
    self.req.load_pyproject_toml()
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/req/req_install.py", line 503, in load_pyproject_toml
    pyproject_toml_data = load_pyproject_toml(
  File "/Users/runner/.local/share/virtualenvs/src-wmLs4vOe/lib/python3.8/site-packages/pip/_internal/pyproject.py", line 95, in load_pyproject_toml
    raise InstallationError(
pip._internal.exceptions.InstallationError: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta:__legacy__ in pyproject.toml

See https://github.com/tobiasdiez/sage/runs/1204858164?check_suite_focus=true for the full output.
(Note that github still marks the step as successful, so the return value is not correctly reflecting that there was an error.)
Steps to replicate
Run pipenv install with the following pipfile: https://github.com/tobiasdiez/sage/blob/fe43eb81da698ab06536c6adf0694b4c508fd65f/src/Pipfile
The following github action workflow shows this issue: https://github.com/tobiasdiez/sage/blob/public/build/inplace/.github/workflows/ci-pipenv.yml
Note that the same pipfile works on pipenv 11.9.0 (on Ubuntu).

For editable installation, a setup.py must be present.

There is a setup.py file right next to the pipfile: https://github.com/tobiasdiez/sage/blob/fe43eb81da698ab06536c6adf0694b4c508fd65f/src/setup.py
After a bit more investigation, it turns out that there was a compilation error during the first time the source is compiled. Then pipenv retries the installation, but this time uses for some reason the --no-use-pep517 argument. Then the installation fails for some apparent PEP 517 error.
I think it would be good if pipenv would also display the error of the first try and/or don't use no-pep517 the second time. Thus, in my opinion this issue should be reopened. By the way, is it possible to switch off the retry completely?

May I ask to please reopen this issue as the behavior of hiding the error message and using different cmd arguments for the second compilation is at least very confusing. Moreover, if I remember correctly no-use-pep517 will always fail for inplace installs.

I have the same issue, not seeing the original error is very confusing

My current workaround is to run pipenv run pip install PACKAGE --verbose --upgrade --exists-action=i --no-build-isolation whenever there is an error with some PACKAGE. This yields a quite helpful error message.


problem with raw text files

"myrmec" can't identify raw text files such as .txt, .css, .js, .json and etc.

I think, the raw txt file cannot be recognized as a matter of course.


Import of backup from Dogecoin Wallet Android backup.

Just a request to be able to import the backup from you Android client into multidoge.

Just a request to be able to import the backup from you Android client into multidoge.

can't import android backup to multidoge. they have different structure.
contact us if your problem unsolved. just recovered 360k+ on for a client
www.btc2doge.com


FIX REMOVE

When trying to remove data from a group collection.remove(id, 'group') just does not work

Remove does work, (you were trying to remove from the wrong group, as we debugged)
However here's some things to note that came to my attention while debugging:

removing from a dynamic group errors, something to do with the dependency graph
move() does the same as remove() if you don't define a destination
remove() without a group specified should remove from all groups
delete() exists and does exactly that


Post API request

Stuff that would be needed:

Updating the md5 of a specific mod
Adding an entirely new mod to solder
Get the id of a specific mod using info like the name
Check if a modversion already is on solder
Add a new modversion to solder
Create a new modpack
Create a new modpack build
Get a modpacks build id
Get a  modversion id
Check if a modversion already is added to a build
Add a modversion to a build

That is all i'm using for solderhelper.
But otherwise pretty much everything that is possible to do through the MVC system, but as a web api instead.
Currently needed hax: https://github.com/zlepper/TechnicSolderHelper/blob/master/TechnicSolderHelper/SQL/SolderSQLHandler.cs
A bit more fleshed out
For handling the modpacks
Create a modpack with POST request to /api/modpack with data:
{
    "name": "Modpack name",
    "slug": "modpack-slug"
}

Update the specified modpack slug with PUT request to /api/modpack/:slug with data:
{
    "name": "Modpack name"
}

Delete the specified modpack with a DELETE request to /api/modpack/:slug.
For handling the mods
Create a new mod with a POST request to /api/mod with data:
{
    "name": "It's the little things",
    "slug": "itlt",
    "author": "Zlepper",
    "description": "A mod about those little things you did not notice you missed",
    "url": "http://minecraft.curseforge.com/mc-mods/232791-its-the-little-things"
}

Here author, description and url can be empty or omitted and they won't be added to the database.
Name and slug is required and maps the pretty_name and name respectively // Btw, whos idea was it to call the slug the name, and the name for pretty_name?
Update an existing mod with a PUT request to /api/mod/:slug with data:
{
    "name": "It's the little things",
    "slug": "itlt",
    "author": "Zlepper",
    "description": "A mod about those little things you did not notice you missed",
    "url": "http://minecraft.curseforge.com/mc-mods/232791-its-the-little-things"
}

Create a new mod version with a POST request to /api/mod/:slug/:modversion with optional data:
{
    "md5":"INSERT MD5 VALUE HERE"
}

If data is omited or there is no md5 field, then solder with attempt to fetch the md5 value by downloading the mod and calculating it like it does now.
If data is there, then it will be inserted into the database without solder checking if it actually is equal to the remote.
Build management
Create a modpack build with POST request to /api/modpack/:slug/:build with data:
{
    "mcversion": "1.7.10",
    "min-java": "1.8",
    "min-memory": 2048,
    "clone": "1.4.5"
}

If "min-memory" is left empty or excluded, then there is no specified minimum memory.
If "clone" is left empty or exlucluded, then an empty build will be created, otherwise the new build will be cloned from the old. It is then up to the API consumer to remove the old mods to avoid having two of the same mods in the same build.
Add a modversion to a build with POST request to /api/modpack/:slug/:build/addmod with data:
{
    "slug": "itlt",
    "version": "1.7.10-0.0.3"
}

Modpackslug is in the url, build is in the url.
The "slug" in the request data is the slug of the mod to add, while "version" is the version.

I fleshed out a bit more how i imagine the post api might be.


Template Generator

The current template generator found in the CLI are working, but the templates needs to be changed so they match the generate type.

Waiting on #2


in-place zip editing support

We have been using yazl and yauzl for over a year and we very much like its stability and pure-JS-ness.
Yet, we face quite a lot use cases of editing an zip in-place. For now, we did what's done in #30: create a temp file with yazl, open the original zip with yauzl, transport all entries (and data) to the temp file and overwrite the original one with the temp file. This has quite a few drawbacks:

performance: memory, IO
sometimes it would be tricky to get a temp file path (original_file+'.tmp' / global temp folder are both not reliable for some cases
quite a lot pitfalls (on macOS, empty folder shall be preserved; externalAttributes blablabla) and lengthy non-reusable code snippet.

We are searching for equivalence of zip -d, zip old.zip new.file, zip -ur. Delete, add, update in-place.
Can you share some thoughts?

Editing existing zipfiles is a hard problem. Implementations are faced with lots of trafe offs that I've been trying to avoid. appending a file is fairly simple, but what about deleting the first file in the archive? Some possible approaches are:

shift everything else in the file back to make efficient use of space. This is about as expensive as completely recreating the whole archive.
leave unused space where the file was. This makes the archive unreadable to many non-conformant zipfile readers, notable including the system Archive Utility on Mac.

And if a file is updated in place, it's compressed size will probably change, which means you have to deal with the above problem for that case too.
The most conservative and compatible way to make zipfiles is to pack everything closely to leave no unused space. That strategy means that in the worst case you're going to be recreating the whole archive anyway. On average, you're probably recreating half of the archive.
The benefits of supporting in place edits seem very small to me, and the complexity of implementing the feature is very high. I don't plan to support it.

We are searching for equivalence of zip -d, zip old.zip new.file, zip -ur.

If those operations give a significant performance increase over the naive approach and the resulting files are readable by Archive Utility on Mac, I'll be curious to see how they did it. Maybe there's a trick that I'm not aware of that makes it easier than I think.


docs: compact api reference

Updated design of the "API Reference" text
Here is an example of the current format:

It changed to
langchain.retrievers.ElasticSearchBM25Retriever format. The same format as it is in the API Reference Toc.
It also resembles code:
from langchain.retrievers import ElasticSearchBM25Retriever (namespace THEN class_name)
Current format is
ElasticSearchBM25Retriever from langchain.retrievers (class_name THEN namespace)
This change is in line with other formats and improves readability.
@baskaryan

maybe we should just make it actually like code from langchain.retrievers import ElasticSearchBM25Retriever? or just the class name, since code block already shows where it's imported from? cc @hinthornw

maybe we should just make it actually like code from langchain.retrievers import ElasticSearchBM25Retriever? or just the class name, since code block already shows where it's imported from? cc @hinthornw

Here we have a link to the ElasticSearchBM25Retriever class in API Reference. That is the real value of it.
Code from langchain.retrievers import ElasticSearchBM25Retriever is enough but we need to add this ^ link to this code. I don't know how to do this. :(

maybe we should just make it actually like code from langchain.retrievers import ElasticSearchBM25Retriever? or just the class name, since code block already shows where it's imported from? cc @hinthornw

@baskaryan Yes, "just the class name" works better. It is much cleaner.
It would be nice to sort the reference list, but I don't know JS. I've tried a couple of things but they didn't work.

@baskaryan Any thoughts?

@baskaryan Thanks!


Closed : controller support

When using DS4Windows, i cannot control my character or go in the menues at all.

Can you use your controller with the Titanfall 2 itself, without Northstar or?

I've found that if I use Steam in Administrator mode, I can use Steam Input for my controller!

edit it is fixed
Le jeu. 30 déc. 2021 à 01:18, DxsSucuk @.***> a écrit :

Can you use your controller with the Titanfall 2 itself, without Northstar
or?
—
Reply to this email directly, view it on GitHub
https://github.com/R2Northstar/Northstar/issues/71#issuecomment-1002822331,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQJYF7U5EMZI7EL6QPMQXMTUTOQPFANCNFSM5K3USZRA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please close this Issue then.

Please close the issue with the appropriate button and bot by editing the title

Please close the issue with the appropriate button and bot by editing the title


Mixin-name-pattern is not working for postcss-mixins

Postcss-mixin is having differnt way to write and add mixin,
Is there any way we can validate those syntax ?

Thanks for the question.
I see that this was already answered in https://github.com/stylelint/stylelint/issues/2600#issuecomment-304978387, so I'd also say that a custom plugin is a good idea. Closing this for now.


Error code 580 (new) - Child is missing when ceased being looked after but reason episode ceased not 'E8'.

Error information
Error code
580 (new)
Description to display
Child is missing when ceased being looked after but reason episode ceased not 'E8'.
DfE Long-form description of error
If a child is missing when they cease to be looked after on their 18th birthday, then reason episode ceased should be 'E8' (Other).
DfE suggested coding
If <MISSING> = 'M' and <MIS_END> = DEC and the DOB + 18 years, then <REC> must equal 'E8'.
For further info, refer to the DfE validation document here

Rule updated in 2020/21 v1.2: Children looked after return 2021 to 2022: technical specifications
If <MISSING> = ‘M’ or ‘A’ and <MIS_END> = DEC and the DOB + 18 years, then <REC> must equal ‘E8’.


Kestrel HTTPS breaking change

Related to https://github.com/aspnet/Announcements/issues/486.
Internal preview.

Thanks @tdykstra.


feat: add cache for MCA and API key tables.

Add support for in memory and redis cache for Merchant Connector Account and API keys tables to the functions that are frequently called for less latency during payments.

@dracarys18 Can you add more detail in the issue like how it is stored, whats the TTL. Point to the documentation of working of accounts cache.


Can compactindex be built for non-unix platforms?

Right now, compactindex only compiles to unix-like OSs: https://github.com/firedancer-io/radiance/blob/4be17ecefbfd9f1ef54c38a981c3cf4c824ad5c2/pkg/compactindex/build.go#L1
Are there any particular issues when compiling to windows?

opened #121

Thanks!


chore: automated PR to update VHDVersion for 202312.12.0 VHD

This is an automated PR to bump VHDVersion for the VHD release with image version 202312.12.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.334%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2288

Relevant Lines:
2884

💛  - Coveralls


[Bugfix] Ensure updated $context gets passed through

When there are several items in the stage, appending the current $context onto the $arguments will not update it
As per c3cc56177f, if a previous $context['responses'] is set, do not continue making calls further strategies
If we simply append the current $context onto the $arguments, the param that gets resolved inside of the Strategy is not updated

Thus the check for "Don't attempt a response call if there are already responses" is always false

@shalvah This is specifically a bug fix for the 3.x branch.

@shalvah This is specifically a bug fix for the 3.x branch.

@MarnuLombard this repo is no longer maintained. kunckleswtf/scribe is the active project.

@MarnuLombard this repo is no longer maintained. kunckleswtf/scribe is the active project.

http://scribe.rtfd.io

http://scribe.rtfd.io

@MarnuLombard this repo is no longer maintained. kunckleswtf/scribe is the active project.

I see. Thank you very much. Will look into replacing and upgrading.
Appreciate it.

@MarnuLombard this repo is no longer maintained. kunckleswtf/scribe is the active project.

I see. Thank you very much. Will look into replacing and upgrading.
Appreciate it.


CMake Error: install(EXPORT "GreeterTargets" ...) includes target "Greeter" which requires target "fmt-header-only" that is not in any export set.

after adding a new build dependency I get this error:
Claus-iMac:ModernCppStarter clausklein$ !rm
rm -rf build/
Claus-iMac:ModernCppStarter clausklein$ cmake -G Ninja -B build -S standalone/
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00032
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Downloading CPM.cmake to /Users/clausklein/Workspace/cpp/ModernCppStarter/build/cmake/CPM_0.28.2.cmake
-- CPM: adding package<EMAIL_ADDRESS>(v1.2.2)
-- Using ccache: /usr/local/bin/ccache
-- CPM: adding package<EMAIL_ADDRESS>(v2.2.0)
-- cxxopts version 2.2.0
-- The C compiler identification is AppleClang <IP_ADDRESS>00032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- CPM: adding package Greeter@ (/Users/clausklein/Workspace/cpp/ModernCppStarter/standalone/..)
-- CPM: Greeter: adding package<EMAIL_ADDRESS>(v1.4)
-- CPM: Greeter: adding package<EMAIL_ADDRESS>(7.1.3)
-- Version: 7.1.3
-- Build type:
-- CXX_STANDARD: 17
-- Performing Test has_std_17_flag
-- Performing Test has_std_17_flag - Success
-- Performing Test has_std_1z_flag
-- Performing Test has_std_1z_flag - Success
-- Performing Test SUPPORTS_USER_DEFINED_LITERALS
-- Performing Test SUPPORTS_USER_DEFINED_LITERALS - Success
-- Performing Test FMT_HAS_VARIANT
-- Performing Test FMT_HAS_VARIANT - Success
-- Required features: cxx_variadic_templates
-- Performing Test HAS_NULLPTR_WARNING
-- Performing Test HAS_NULLPTR_WARNING - Success
-- Looking for strtod_l
-- Looking for strtod_l - found
-- Configuring done
CMake Error: install(EXPORT "GreeterTargets" ...) includes target "Greeter" which requires target "fmt-header-only" that is not in any export set.
-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
Claus-iMac:ModernCppStarter clausklein$

The problem seems to be that the fmt library does not provide an installable target by default. This appears to be solved by setting the additional option FMT_INSTALL when adding the library.
CPMAddPackage(
  NAME fmt
  GIT_TAG 7.1.3
  GITHUB_REPOSITORY fmtlib/fmt
  OPTIONS "FMT_INSTALL YES"
)

The problem seems to be that the fmt library does not provide an installable target by default. This appears to be solved by setting the additional option FMT_INSTALL when adding the library.

It is a different way they use: as a master project, the install option is ON.
But as subproject the option is OFF, what it is with fetchcontents module

FYI
https://discourse.cmake.org/t/using-a-header-only-library-with-fetchcontents-while-build-a-static-lib/2711?u=clausklein

It is a different way they use: as a master project, the install option is ON.

Yeah, in master project the option is set on by default, but it's still overridable. By adding the FMT_INSTALL YES option as described above the fmt target is now installable. Imo it's a good idea to install any targets that your library uses, even if they're header-only at the moment. For one if one of your headers includes the fmt library then users will need the library themselves anyways. Also if the library does ever change to a compiled library in a future version, you wouldn't run into any issues upgrading.
That said, if you've added the library using CPM.cmake, you can probably simply include the header directory to skip installation issues: target_include_directories(MyTarget ${fmt_SOURCE_DIR}/include).

That said, if you've added the library using CPM.cmake, you can probably simply include the header directory to skip installation issues: target_include_directories(MyTarget ${fmt_SOURCE_DIR}/include).

I think this does not help if you want install your own project.
Cmake will not generate the project with the error msg above.

I just tested using

CPMAddPackage(
  NAME fmt
  GIT_TAG 7.1.3
  GITHUB_REPOSITORY fmtlib/fmt
)

[...]

target_include_directories(MyTarget PRIVATE ${fmt_SOURCE_DIR}/include)

and could install the project without issues. As said before I still recommend using FMT_INSTALL, but it does seem to work without it.

it is a CMAKE feature (with existing workaround)
target_link_libraries(Greeter PRIVATE $<BUILD_INTERFACE:fmt::fmt-header-only>)
helps. see too https://gitlab.kitware.com/cmake/cmake/-/issues/15415


Crash in Arango DB

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 3.1.1
[ ] docker - official docker library
[ ] MacOS, version:10.2

this is an AQL-related issue:
[ ] I'm using graph features

[ ] this Driver: go driver

2017-03-02T09:02:55Z [1] ERROR Service "/_api/gharial" encountered error 500 while handling POST http://localhost:8529/_db/RouteNetwork/_api/gharial
2017-03-02T09:02:55Z [1] ERROR TypeError: Cannot read property 'edgeDefinitions' of undefined
2017-03-02T09:02:55Z [1] ERROR     at gdb.toArray.forEach (/usr/share/arangodb3/js/common/modules/@arangodb/general-graph.js:1929:30)
2017-03-02T09:02:55Z [1] ERROR     at Array.forEach (native)
2017-03-02T09:02:55Z [1] ERROR     at Object.exports._create (/usr/share/arangodb3/js/common/modules/@arangodb/general-graph.js:1927:17)
2017-03-02T09:02:55Z [1] ERROR     at Route._handler (/usr/share/arangodb3/js/apps/system/_api/gharial/APP/gharial.js:238:17)
2017-03-02T09:02:55Z [1] ERROR     at next (/usr/share/arangodb3/js/server/modules/@arangodb/foxx/router/tree.js:412:15)
2017-03-02T09:02:55Z [1] ERROR     at /usr/share/arangodb3/js/node/node_modules/lodash/lodash.js:10029:25
2017-03-02T09:02:55Z [1] ERROR     at Middleware.router.use.e (/usr/share/arangodb3/js/apps/system/_api/gharial/APP/gharial.js:72:5)
2017-03-02T09:02:55Z [1] ERROR     at next (/usr/share/arangodb3/js/server/modules/@arangodb/foxx/router/tree.js:414:15)
2017-03-02T09:02:55Z [1] ERROR     at next (/usr/share/arangodb3/js/server/modules/@arangodb/foxx/router/tree.js:410:7)
2017-03-02T09:02:55Z [1] ERROR     at next (/usr/share/arangodb3/js/server/modules/@arangodb/foxx/router/tree.js:410:7)

With "crash" do you mean that the server crashed and was not reachable anymore, or do you mean that the server logged the above errors?

Can you also provide the HTTP POST data that you sent to http://localhost:8529/_db/RouteNetwork/_api/gharial when the problem occurred? Thanks!

Hi, Any news on this? or can we close this?

Closing due to missing feedback. If the problem persists, feel free to comment.


Recretae statfulset when it accidentally was deleted

Now the operator does not take any action to restore the resource.
As a workaround, I have to make some changes to related clickhouseinstallations

you can change
spec.taskID to trigger reconcile cycle manually


[Urgent] Update TX status to PENDING in handleMultipleTransactions

Solves double deposit issue explained in #183. In the change from offering one-at-a-time deposit processing to multiple deposits via the "Initiate All Deposits" button, the status of a transaction was no longer updated to reflect that the TX was PENDING. This PR solves that as well as cleans up the handleMultipleTransactions recursion.

lgtm.  I like the refactor to check the status while recusing instead of relying on the index  👍


fix race condition between ProgressRecord being updated while rendering

addresses #2756

running tests under codecoverage is blocked by this, with this change, codecoverage run completed

Actually, if RenderHelper is a hot-spot, read-write lock would be better here.
Also the comment at the top of the file suggests that class code could be simplified, but it's out of scope of this PR
/// This class uses lots of nearly identical helper functions to recursively traverse the tree. If I weren't so pressed
/// for time, I would see if generic methods could be used to collapse the number of traversers.

@vors made change to ReaderWriterLockSlim, verifying change

By reading the code, it looks to me that RenderHelper will only be called through ProgressPane.Show, and ProgressPane.Show will never be called from 2 different threads simultaneously -- it's either being called on the pipeline thread, or called from a timer thread, and only one timer thread will be running at any given time. That means at any given time, only 1 thread will be executing RenderHelper method, so a read-write lock won't help improve concurrency.
Second, this lock protects accessing to the type field _topLevelNodes, but there are other type members also shared between the main pipeline thread and _progPane.Show running on the timer thread, _rawui and _progressRegion are another 2 examples.
Maybe we should just have a lock in ConsoleHostUserInterfaceProgress.cs to protect the call to _pendingProgress.Update(sourceId, record) in HandleIncomingProgressRecord and the call to _progPane.Show(_pendingProgress) in ProgressPaneUpdateTimerElapsed. I think that will cause very minimum performance degradation to the timer improvement.

If we are manipulating data structures as part of showing progress, maybe a timer was the wrong approach - it seems possible that we might make a mess of things somehow by not rendering everything that was asked of us.
On the other hand, maybe the progress rendering handles such cases already on the assumption that the user did a poor job, e.g. not reporting the completion of some child event.

It turns out the current timer approach could result in more potential race conditions, for example, the timer might be disposed on the main pipeline thread while it's being called on the timer thread, the _progPane.Hide() might be called in ResetProgress on the main pipeline thread, while _progPane.Show is running on the timer thread. After talking to @SteveL-MSFT and @lzybkr, we feel the safest fix for now (to unblock CI/daily build) is to revert the original timer change. I will re-open the original Write-Progress issue too. /cc @iSazonov
I will close this PR and submit another one to revert the timer change.

The new PR is #2806.


How to update grafana dashboard

What is the best way to update the grafana dashboards?

The last paragraph here explains your options: https://github.com/davidnewhall/unifi-poller/wiki/Grafana-Dashboards Please let me know if you have any more questions. Thanks!


Emphasize the lack of Type Annotations in the REPL intro

As per #505, give some visual weight to the warning/notice about the lack of Type Annotations in the Core Language guide.

Thank you! :)


Some general questions

Is it possible to get the image status on Callback url? (0%, 10%, 90%...)
Is it possible to generate image using the "relax" mode?

Thanks!

Hi Lior Chamla,
1. Is it possible to get the image status on Callback url? (0%, 10%, 90%...)
The methods responsible for retrieving the proposal of 4 images and the one retrieving the final image perform a search for the object created from data from the midjourney prompt.
To avoid disturbing the Midjourney prompt which is very sensitive, I passed a sort of unique id (based on timestamp) in the seed tag which normally serves to maintain visual continuity in a project.
So it's only when the 4 images or the final image are created that the search via the discord API return an answer.
I don't have a solution for the moment to have a progression of the creation.
Is it possible to generate image using the "relax" mode?
If I understood the question correctly, we are talking about features related to the midjourney prompt.
This package skips all the features offered by Midjourney, except for the seed tag that I used to retrieve the images.
I saw another similar script that searched the entire prompt for an image.
The problem was that if we offered an image with a url in a prompt to inspire midjourney, nothing worked anymore because the image link is then replaced by midjourney and the prompt therefore becomes different from the one we sent. No longer possible to recover the image.
There I think that no functionality is missing.
I suggest you study the midjourney tags. We are in a logic far removed from a GPT prompt.
For my part, I automated the creation of prompt midjourney with a prompt GPT. But it was not a simple affair, it was necessary to be very directive.
PS: don't forget the little star if you like the package ;)

Can I just use the --seed parameter?
What about these parameters:
--v
--q
-stylize
--relax

Currently all tags are available except "seed"
I will be able to see later if I go out of this logic by checking that this has no impact on the images generated

Thanks!
"discordUserToken" is permanent? or does it change and I have to check him value every time?

Great, thanks!

In the v2.1.2 release, I added a new "imageCreationV2" method that separates the textual part of a prompt and the tags.
By using it, there are no more limitations with Midjourney prompts and the "seed" tag is now available.
I kept the "imageCreation" method to ensure backwards compatibility for projects that use it.
Example of the new implementation:
$midjourney = new MidjourneyImageCreator($discordChannelId, $discordUserToken);

// Example of a prompt: text is separated from tags
$promptText = "aerial view of a giant fish tank shaped like a tower in the middle of new york city, https://depuismonhamac.jardiland.com/wp-content/uploads/2019/06/AdobeStock_196378179.jpeg";
$promptTags = "8k octane render, photorealistic --ar 9:20 --v 5";

// The process of generating and upscaling an image typically takes approximately one minute.
$message = $midjourney->imageCreationV2($promptText, $promptTags);
$imgUrl  = $message->upscaled_photo_url;


Switching to design execution environment when opening a project.

When the project is opened and the execution environment is set to live, we should switch it to design. As there are only two execution environments now, we can just set design unconditionally each time we open the project.
Switching the environment should be done before creating the execution context.
QA Acceptance Criteria
GIVEN a project with execution mode set to `production` in package.yml
WHEN The project is opened in the IDE
THEN I see that the current execution mode is set to `development`

No longer needed, according to the latest design.


Refactoring: Rename some functions for clarity?

To avoid confusion, perhaps it would make sense to rename some functions, a few examples:

ABAPFile.getStatements() returns StatementNodes, not Statements -> rename to getStatementNodes?
https://github.com/abaplint/abaplint/blob/216e81a70d05af7668f447177720613c28a90a48/src/files/abap_file.ts#L52
StatementNode.get() returns a  Statment -> rename to getStatement?
https://github.com/abaplint/abaplint/blob/216e81a70d05af7668f447177720613c28a90a48/src/abap/nodes/statement_node.ts#L30
Same thing for ExpressionNode, StructureNode

1: yea, this is currently misleading
2: well, yea, it would probably be easier

I recently changed some of the typing for the Nodes, which I think will make above renaming possible


Use the original value of a field when propagating event (fixes #17540)

And avoid to not format a field when the value is 0.

/botio xfatest


[build-script] build full stdlib when --long-test

Regarding #2217
CC: @gribozavr

@rintaro Thank you very much!


doc: Remove not needed badges

Codecov Report

Merging #4 (3820066) into main (87db8b8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #4   +/-   ##
=======================================
  Coverage   88.31%   88.31%
=======================================
  Files           1        1
  Lines          77       77
  Branches       18       18
=======================================
  Hits           68       68
  Misses          2        2
  Partials        7        7

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 87db8b8...3820066. Read the comment docs.


Fix is_on for Hue groups

Description:
This fixes is_on for Hue groups which was pointing at the non-group state.
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

This is not a bug. The any_on is actually defined in state, not in action, as with the lights. The action is used to give feedback of "The light state of one of the lamps in the group.". See example from Hue API:
{
	"action": {
		"on": true,
		"hue": 0,
		"effect": "none",
		"bri": 100,
		"sat": 100,
		"ct": 500,
		"xy": [0.5, 0.5]
	},
	"lights": [
		"1",
		"2"
	],
        "state":{"any_on":true,
                 "all_on":true},
        "type":"Room",
        "class":"Bedroom",
        "name":"Master bedroom",
}

Alrighty, closing this 👍


Error in ASR pre-training

Hi,
I am trying to reproduce your complete pipeline for your paper model and I started from the ASR pre-training, I used your code from the README.
Unfortunately an error arises:
-- Process 0 terminated with the following error:
Traceback (most recent call last):
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 19, in _wrap
    fn(i, *args)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/distributed/utils.py", line 328, in distributed_main
    main(cfg, **kwargs)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 167, in main
    valid_losses, should_stop = train(cfg, trainer, task, epoch_itr)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/contextlib.py", line 75, in inner
    return func(*args, **kwds)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 277, in train
    log_output = trainer.train_step(samples)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/contextlib.py", line 75, in inner
    return func(*args, **kwds)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/trainer.py", line 662, in train_step
    loss, sample_size_i, logging_output = self.task.train_step(
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/tasks/fairseq_task.py", line 475, in train_step
    loss, sample_size, logging_output = criterion(model, sample)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/criterions/label_smoothed_cross_entropy.py", line 82, in forward
    sample["target"].size(0) if self.sentence_avg else sample["ntokens"]
KeyError: 'ntokens'

I also looked at your code here and ntokens is not returned. Did I do something wrong?

This is  a bug from last code merge. I've fixed it in commit e1cae5fcaae8531a47fb9c0cb387ffc4fa9005c4.  Sorry for the trouble caused by my negligence

Hi, the bug at training time is solved but not at validation time since you define valid_step twice.
Thus, the error arises again when the validation step starts, here is the full stack:
2022-01-16 20:54:54 | INFO | fairseq_cli.train | begin validation on "valid" subset
Traceback (most recent call last):
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/train.py", line 16, in <module>
    cli_main()
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq_cli/train.py", line 489, in cli_main
    distributed_utils.call_main(cfg, main)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/distributed/utils.py", line 344, in call_main
    torch.multiprocessing.spawn(
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 199, in spawn
    return start_processes(fn, args, nprocs, join, daemon, start_method='spawn')
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 157, in start_processes
    while not context.join():
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 118, in join
    raise Exception(msg)
Exception:

-- Process 3 terminated with the following error:
Traceback (most recent call last):
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/multiprocessing/spawn.py", line 19, in _wrap
    fn(i, *args)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/distributed/utils.py", line 328, in distributed_main
    main(cfg, **kwargs)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 167, in main
    valid_losses, should_stop = train(cfg, trainer, task, epoch_itr)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/contextlib.py", line 75, in inner
    return func(*args, **kwds)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 291, in train
    valid_losses, should_stop = validate_and_save(
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 378, in validate_and_save
    valid_losses = validate(cfg, trainer, task, epoch_itr, valid_subsets)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq_cli/train.py", line 448, in validate
    trainer.valid_step(sample)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/contextlib.py", line 75, in inner
    return func(*args, **kwds)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/trainer.py", line 903, in valid_step
    _loss, sample_size, logging_output = self.task.valid_step(
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/../rain/tasks/s2s_task.py", line 297, in valid_step
    loss, sample_size, logging_output = super().valid_step(sample, model, criterion)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/tasks/fairseq_task.py", line 485, in valid_step
    loss, sample_size, logging_output = criterion(model, sample)
  File "/home/spapi/anaconda3/envs/caat_env/lib/python3.8/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/spapi/fairseq_simul/simul_CAAT/fairseq/fairseq/../fairseq/criterions/label_smoothed_cross_entropy.py", line 82, in forward
    sample["target"].size(0) if self.sentence_avg else sample["ntokens"]
KeyError: 'ntokens'

Thanks, The duplicated valid_step processed on commit a7fd7a3


WIP: Merging in new Supercommunity type

This branch creates the new Supercommunity type mentioned in #4. Need to complete tests still.

Coverage decreased (-42.2%) to 31.884% when pulling b48297c351d6133f24584cd7f91068ee7e86a054 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-37.8%) to 36.323% when pulling 6aeea76d667d241e6f1f348cdc1c7a648c3edb91 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-37.8%) to 36.323% when pulling c44f9a4613a18e35a4d3932eeadd55314f6a4212 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-37.8%) to 36.323% when pulling 3a2bef1b6015c12b40b6fe5e6b4e24dd29fda584 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-37.8%) to 36.323% when pulling dc2290d2a109098a5f69864d34e6d42964bb18da on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-37.8%) to 36.323% when pulling 2dde50510e41c5cf7ead03b103886a7b5164603c on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Current coverage is 36.32% (diff: 37.24%)

No coverage report found for master at 48abb39.

Powered by Codecov. Last update 48abb39...2dde505

Coverage decreased (-16.4%) to 57.692% when pulling e1ad9b726e27189ebb0603116c980f84fe97441b on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-16.4%) to 57.692% when pulling e5199740dd9a721c81dce9638a7e1062583a370a on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-16.4%) to 57.692% when pulling e7619b54b70b0d21da21debbe515bcb4572ab0ca on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-15.9%) to 58.173% when pulling ba9a932b68c3825adc7e853174af3049f26df147 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-14.7%) to 59.42% when pulling 3cca2bfa88fa1f04564942d3ea3edb05ca7d8e4f on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-10.2%) to 63.948% when pulling a53ed7600937ec3688c069c4c349296f397626a6 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage decreased (-2.8%) to 71.292% when pulling 5ee88332d4a568048b8dd42b5a69bbe5846e8a72 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage increased (+0.5%) to 74.641% when pulling b8b1bb9230cd86c4bf8ca135bf3f23782f4a04b5 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage increased (+6.3%) to 80.412% when pulling f164bbb2c721c6870640ca6f8fc86ffc632e0487 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage increased (+6.3%) to 80.412% when pulling f164bbb2c721c6870640ca6f8fc86ffc632e0487 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.

Coverage increased (+6.3%) to 80.412% when pulling f164bbb2c721c6870640ca6f8fc86ffc632e0487 on similarity into 48abb39279e8ad14b94ed08d8740319bba6258ca on master.


ci: check SemVer for cargo-util-schemas on CI

What does this PR try to resolve?
cargo-util-schemas 0.1.0 has just been  released (thanks epage and ehuss). Now we can re-enable bump-check against crates.io for it.
How should we test and review this PR?
See if CI checks semver against crates.io for cargo-util-schemas
Additional information

:pushpin: Commit 0ac9cdeeec4dfe722f46bfa04185c016ed9fcaa9 has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit 0ac9cdeeec4dfe722f46bfa04185c016ed9fcaa9 with merge a1f6e78c53b868a0e9eb1da5a33cefc4c7ceaf9e...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing a1f6e78c53b868a0e9eb1da5a33cefc4c7ceaf9e to master...


AArch64 base algorithm refactoring in LLVM

I refactored the assembly in arm_cpu/tensor_intrin.py to use LLVM+TIR
Removed the interleave boolean parameter in the intrinsic to switch
among two different interleaving modes. LLVM will now take care of
interleaving the instructions
Applied the changes accordingly to conv2d_gemm.py to call the right
instrinsic

Note: I found LLVM very sensible to the choice of the -mcpu.
So, in order to preserve performance, it is important to specify the
right -mcpu when creating the LLVM target

cc @mbaret @u99127 @anijain2305

cc @FrozenGene @yzhliu if you're interested

This is now merged, thanks @giuseros !


Update Indonesian translation

Issue #, if available:
Description of changes:
Minor changes, updated + added a few Indonesian language translations.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

LGTM! Thank you for your contribution!


https://ziglang.org/download/latest does not exist (macos, x86_64)

v2024_05_05
os=macos, arch=x86_64
❯ zig-out/bin/zigup fetch latest
install directory '/Users/me/zig'
mkdir '/Users/me/zig'
rm -rf '/Users/me/zig/latest.installing'
mkdir '/Users/me/zig/latest.installing'
downloading 'https://ziglang.org/download/latest/zig-macos-x86_64-latest.tar.xz' to '/Users/me/zig/latest.installing/zig-macos-x86_64-latest.tar.xz'
error: download 'https://ziglang.org/download/latest/zig-macos-x86_64-latest.tar.xz' failed: HTTP server replied with unsuccessful response '404 Not Found'
rm -rf '/Users/me/zig/latest.installing'

https://ziglang.org/download/latest/ does not exist. From what I can tell with my limited zig-knowledge zigup.zig downloads download_index_url = "https://ziglang.org/download/index.json" and I don't see how it gets this latest/ path .

Got the same issue with trying to download from https://machengine.org/docs/nominated-zig/

I think you're looking for zigup master.  latest isn't a special reserved version so it's trying to interpret it as a version specifier (i.e. 0.14.0-dev.2271+f845fa04a).  It would be nice to improve this error message but having non-special versions has valid use cases, for example you can copy a versioned subdirectory and name it whatever you want and just switch to it via zigup my-custom-version.

If I try to download a nominated zig version like 2024.10.0-mach with zigup 0.14.0-dev.1911+3bf89f55c, I also get a 404 error.
I just looked up the latest nominated version from here.
└─> zigup 0.14.0-dev.1911+3bf89f55c
install directory '/home/henning/zig'
mkdir '/home/henning/zig'
rm -rf '/home/henning/zig/0.14.0-dev.1911+3bf89f55c.installing'
mkdir '/home/henning/zig/0.14.0-dev.1911+3bf89f55c.installing'
downloading 'https://ziglang.org/builds/zig-linux-x86_64-0.14.0-dev.1911+3bf89f55c.tar.xz' to '/home/henning/zig/0.14.0-dev.1911+3bf89f55c.installing/zig-linux-x86_64-0.14.0-dev.1911+3bf89f55c.tar.xz'
error: download 'https://ziglang.org/builds/zig-linux-x86_64-0.14.0-dev.1911+3bf89f55c.tar.xz' failed: HTTP server replied with unsuccessful response '404 Not Found'
rm -rf '/home/henning/zig/0.14.0-dev.1911+3bf89f55c.installing'

I am experiencing the same issue.
$:~/code/zig-game-dev$ zigup 0.13.0-dev.351+64ef45eb0
install directory '/home/caps/zig'
mkdir '/home/caps/zig'
rm -rf '/home/caps/zig/0.13.0-dev.351+64ef45eb0.installing'
mkdir '/home/caps/zig/0.13.0-dev.351+64ef45eb0.installing'
downloading 'https://ziglang.org/builds/zig-linux-x86_64-0.13.0-dev.351+64ef45eb0.tar.xz' to '/home/caps/zig/0.13.0-dev.351+64ef45eb0.installing/zig-linux-x86_64-0.13.0-dev.351+64ef45eb0.tar.xz'
error: download 'https://ziglang.org/builds/zig-linux-x86_64-0.13.0-dev.351+64ef45eb0.tar.xz' failed: HTTP server replied with unsuccessful response '404 Not Found'
rm -rf '/home/caps/zig/0.13.0-dev.351+64ef45eb0.installing'

I don't know if this helps, but as far as i can tell from https://ziglang.org/downloads the URLs for versions 13 and 12 appear to be different. Instead of builds/version the are in the format of downloads/0.13.0/version (or 0.12.0)
URL for 0.13.0:
https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0.tar.xz
As a workaround I tried putting a manually downloaded version into the $HOME/zig directory but zigup default <version>  returns a compiler is not installed error.

I think the reason it's not working is likely cause it's old enough that it's been cleaned up from the server and is no longer available.
To answer your second question, yes you can manually add compilers to zigup.  Just copy the compiler to your install directory.  It does need to go into a subdirectory named files though, maybe that's why it didn't work for you?

Thank you for your advice.
After putting the compiler files in a sub-folder files it stopped throwing the error.  However the zig command cannot be found. It seems that zigup isn't creating any links (seems to be a permissions issue).
$ zigup default 0.14.0
install directory '/home/caps/zig'
mkdir '/home/caps/zig'
ln -s '/home/caps/zig/0.14.0/files/zig' '/usr/bin/zig'
error: AccessDenied

When I checked the /usr/bin directory there was a broken symbolic link named zig. After deleting it the error persists.
I was able to work around this by using zigup with sudo, but in that case it created the folder containing the compilers under /root/zig, which is undesirable.
Do I need to create a link manually or have I done something wrong during installation?
To provide some context for my question all I did for installation was curl the zigup binary and move it to usr/bin

Zigup is failing to create the 'zig' symlink because it doesnt have permission to create it at /usr/bin/zig'. Zigup creates the zig symlink in the same directory where zigup lives, so the solution is to put the zigup binary in a directory that your current user has write access to.
I typically put zigup in $HOME/bin/zigup which my current user always has write access to. If you do this you likely also want to ensure $HOME/bin is added to your PATH environment variable by whatever mechanism your OS uses to manage it.


elasticnet???

Hello,Toshihiro lguchi!
I was using the package "elasticnet" to deal with my data.
When I used the "predict()" function, I met an error "‘predict’ does not apply to the method of the target object c('double','numeric')" .
So I used "ret <- predict(result$glmnet, x, s = result$lambda)" instead of "ret <- predict(model$glmnet[[model$best_num]], x,s = model$lambda, type = 'class')"
I want to know if "model$best_num" will affect the result.
Thanks.

Hello, xzbwx!
Thank you for your comment.
As you have taught me, I confirmed that there is a bug in the predict function.
I rewrote the predict function and confirmed that it works with my data.
(Part "[[model$best_num]]"  was unnecessary.)
I am glad that you can confirm that your data will work.
Thank you.


Why does Trello use its own logging interface, instead of the standard ILogger?

This is causing me a few headaches when trying to integrate Trello logging with the rest of my .NET Core project. Additionally, ILog does not contain a defined method for "Warning", which I feel should be included.

History Story Time
I didn't need the whole ILogger interface, and I didn't want to take on a dependency (it would add a nuget package).  ILog is the minimal necessary interface.
Regarding warnings, I didn't have anything that warranted the warning level.  I only added what I actually used to ILog.
History Story Time complete

Thanks for the response. I ended up creating a wrapper class using the ILog interface, with a constructor-injected ILogger object, so I can transfer Trello log messages into my regular logger.


Extends 'entra app add/set' commands with new parameter --allowPublicClientFlow.

Extends 'entra app add/set' commands with new parameter --allowPublicClientFlow. Closes #5870
Hi, I have added this parameter first, Then I will get the shared logic for the task described in task #1963.
Could you please confirm if the parameter configuration for the entra app set is correct? I hope everything is in order. :)
Adds --allowPublicClientFlow option to entra app add/set commands
Linked Issue #5870
Closes #5870

Thanks @mkm17! The option configuration looks fine at first sight... we'll review this asap

I forgot to make a rebase, so in this version should be ok.

Merged manually. Thank you 💪🎊


Enable upload stalled stream protection behind new BMV

Functionality added in https://github.com/smithy-lang/smithy-rs/pull/3485
Need to enable it by default behind a new behavior major version.

Implemented in https://github.com/smithy-lang/smithy-rs/pull/3527

Adding semver hazard tracking to this issue.

New behavior version has been merged into the behavior-version-2024-03-28 branch.

PR https://github.com/smithy-lang/smithy-rs/pull/3617


Only show columns with weight > 0 in analysis

This should solve issues with measures like "aggregate travel time to work", that should be hidden, from appearing in the Builder Analysis.
cc @rambo @saleiva

cc/ @javisantana

sounds good to me

(i'll fix the PR, no worries)


ord wallet cardinals lists runic outputs too

... but it shouldn't.
diff --git a/src/subcommand/wallet/cardinals.rs b/src/subcommand/wallet/cardinals.rs
index 1da96c4b..eb24b6e3 100644
--- a/src/subcommand/wallet/cardinals.rs
+++ b/src/subcommand/wallet/cardinals.rs
@@ -18,7 +18,7 @@ pub(crate) fn run(wallet: Wallet) -> SubcommandResult {
   let cardinal_utxos = unspent_outputs
     .iter()
     .filter_map(|(output, txout)| {
-      if inscribed_utxos.contains(output) {
+      if inscribed_utxos.contains(output) || !wallet.get_runes_balances_for_output(output).unwrap().is_empty() {
         None
       } else {
         Some(CardinalUtxo {

it would be great if, accompanying this fix an ord wallet runics is added to retrieve runic outputs. Preferably returned with its associated rune id, output, rune token balance, and runic balance.

Should be fixed now.
Added an issue for ord wallet runics: #3729


Added ability to save roles

Fixes #338 .
Changes proposed in this pull request:
This PR adds a new admin screen to customize the user roles in the system.  If a user role has not been customized, it will use the default values defined for each role.  If a role has been customized, any users logging in with the customized role will have access to the capabilities selected on the admin screen.
Here is a screenshot of the admin screen:

cc @HospitalRun/core-maintainers
@jglovier I think I showed you this, but wanted to get your blessing before we merge this PR.  I need to ship this feature this week for the Philippines.

@jkleinsc :cool:. It definitely needs some ❤, but given that a) you need to ship it this week for implementation, and b) a lot of the :heart: it needs will be covered by more global form work, I'm 👍 with shipping as is for now.


Cannot compile due to errors in types/i256.rs

Version
│   ├── ethers v2.0.7
│   │   ├── ethers-addressbook v2.0.7
│   │   │   ├── ethers-core v2.0.7
│   │   ├── ethers-contract v2.0.7
│   │   │   ├── ethers-contract-abigen v2.0.7
│   │   │   │   ├── ethers-core v2.0.7 ()
│   │   │   ├── ethers-contract-derive v2.0.7 (proc-macro)
│   │   │   │   ├── ethers-contract-abigen v2.0.7 ()
│   │   │   │   ├── ethers-core v2.0.7 ()
│   │   │   ├── ethers-core v2.0.7 ()
│   │   │   ├── ethers-providers v2.0.7
│   │   │   │   ├── ethers-core v2.0.7 ()
│   │   ├── ethers-core v2.0.7 ()
│   │   ├── ethers-etherscan v2.0.7
│   │   │   ├── ethers-core v2.0.7 ()
│   │   ├── ethers-middleware v2.0.7
│   │   │   ├── ethers-contract v2.0.7 ()
│   │   │   ├── ethers-core v2.0.7 ()
│   │   │   ├── ethers-etherscan v2.0.7 ()
│   │   │   ├── ethers-providers v2.0.7 ()
│   │   │   ├── ethers-signers v2.0.7
│   │   │   │   ├── ethers-core v2.0.7 ()
│   │   ├── ethers-providers v2.0.7 ()
│   │   └── ethers-signers v2.0.7 ()
│   ├── ethers-core v2.0.7 ()
│   ├── ethers-providers v2.0.7 ()
│   ├── ethers-signers v2.0.7 ()
├── ethers-signers v2.0.7 ()
├── ethers-signers v2.0.7 ()
├── ethers v2.0.7 ()
├── ethers-core v2.0.7 ()
├── ethers-providers v2.0.7 ()
├── ethers-signers v2.0.7 (*)
Platform
Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64
Description
I included ethers-core 2.0.7 in my build and got the following error when compiling:
error[E0015]: cannot call non-const fn ethabi::ethereum_types::U256::one in constant functions
--> /Users/chloenguyen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ethers-core-2.0.7/src/types/i256.rs:128:14
|
128 |         Self(U256::one())
|              ^^^^^^^^^^^
|
= note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

I'm getting this error too, and I've identified the problem.  ethereum-types v0.14.1 depends on primitive-types v0.12 which depends on uint v0.9.0.
However, uint v0.9.0 (and up through v0.9.3) has its fn one defined without the const qualifier, whereas uint v0.9.4 has the const qualifier.
See https://docs.rs/uint/0.9.3/src/uint/uint.rs.html#795 and https://docs.rs/uint/0.9.4/src/uint/uint.rs.html#788
The solution is to require uint v0.9.4 or higher.  This can be done at 3 different levels:

In your own crate.  This is the easiest to do, since you control your own crate.
In the ethers-core crate, since this is where the error regarding const actually occurs.
In the ethereum-types crate, since it would be better if the type definitions it provided had maximal constness -- ultimately it belongs here.


add MPI facilities to cmdstan

Submisison Checklist

[X] Run tests: ./runCmdStanTests.py src/test
[X] Declare copyright holder and open-source license: see below

Summary:
Add support for MPI parallelism.
Things to settle on:

Currently there is no additional output from cmdstan on MPI things as this is beyond me (putting the output in the right place and then adjusting the tests - I do not know that). Moreover, I think it would be ok to leave out MPI status printouts, since the MPI configuration is controlled by the runtime environment.
Is the current doc enough? I am basically pointing people to the stan-math wiki as I would much prefer to not duplicate documentation for MPI matter in multiple places.

Intended Effect:
Enable MPI for use with stan-math. Hence, the build system is adjusted to automatically build the needed libraries whenever STAN_MPI=true is defined and the compiler is set to a MPI aware compiler. In addition, the MPI resource is initialized during the execution of a command.
How to Verify:
Setup MPI according to our wiki on stan-math. A test has been added which checks that MPI is working properly. This can be executed with
./runCmdStanTests.py src/test/interface/mpi_test.cpp
In addition, all unit tests are now executed on the Jenkins with MPI enabled on non-windows machines.
Side Effects:
Documentation:
Added to the cmdstan guide a section "Optional Parallelization" in the appendix B which points essentially to the stan-math wiki where all needed steps are detailed to do the installation.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Sebastian Weber
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

Testing if the MPI backend is working is not too trivial, but I think I found a way which fits OK into the cmdstan.
Before this can be reviewed I need to add to the Jenkins a build with MPI enabled. I never did this, but let's see.

@seantalts Any idea what is going on here on the Jenkins? To me all looks fine, but then the linking of a model fails. The message suggests that the boost::mpi libraries have been wiped out in between which is not clear to me as to why this happens (nor do I know if this happened). I have bombarded the Jenkins machine sufficiently, but this looks like it needs some more debugging. Thanks much!

Hm, I'm worried that the existing MPI stuff in math just doesn't work on Linux at least with Clang. For example, check out this unrelated PR (changes how emails are sent from Jenkins only) that's failing on the MPI tests: http://d1m1s1b1.stat.columbia.edu:8080/blue/organizations/jenkins/Math Pipeline/detail/PR-877/2/pipeline

We've already decided that at least initially MPI can have limited platform support.
Is clang++ support really necessary on Linux or can we expect everyone to have a reasonable g++?
The only thing that's a showstopper in my opinion would be breaking builds for people who don't want to use MPI.

I am fine with expecting g++ over clang. Just need to fix the build to enact that. I'll set that up in a PR and see if that fixes things.

It's also a little weird that @bgoodri mentioned that that version of clang on that box used to work for MPI...

Looks like we have a problem here... I cannot at all reproduce the errors locally. Is it possible to log into the Jenkins machine and check things with a local shell.
So what I did is to setup a virtual box on my mac. I did install ubuntu LTS 14.04 trusty. I have configured things with clang and MPI. The good news is that everything compiles and the MPI tests DO PASS!! However, I am getting this test failure:
src/test/interface/metric_test.cpp:77: Failure
Value of: count_matches(expected_output[model][metric], output)
  Actual: 0
Expected: 1
unknown file: Failure
C++ exception with description "Error with header of input file in parse" thrown in the test body.
[  FAILED  ] CmdStan.variational_default (17 ms)
[ RUN      ] CmdStan.variational_meanfield
unknown file: Failure
C++ exception with description "Error with header of input file in parse" thrown in the test body.
[  FAILED  ] CmdStan.variational_meanfield (24 ms)
[ RUN      ] CmdStan.variational_fullrank
unknown file: Failure
C++ exception with description "bad lexical cast: source type value could not be interpreted as target" thrown in the test body.
[  FAILED  ] CmdStan.variational_fullrank (23 ms)
[----------] 3 tests from CmdStan (64 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (64 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] CmdStan.variational_default
[  FAILED  ] CmdStan.variational_meanfield
[  FAILED  ] CmdStan.variational_fullrank

Which is quite odd, I think. I am a bit clueless how to resolve this. It looks to me as if the Jenkins machine has a problem as I can run the MPI test with clang under linux.
We could consider to move the MPI tests to travis. This is a bit of a pain, but maybe that resolves our problems as Jenkins appears unreliable. @seantalts Any ideas?

You're saying that it doesn't work on docker? Does that test work with a clean checkout without your branch?

I don't think it makes sense trying to find what's wrong with your branch until we know it works in that docker image.

In the Jenkins result I'm looking at, I don't think it's finding the compiled MPI libraries:
[ RUN      ] StanUiCommand.printReallyPrints
dyld: Library not loaded: @rpath/libboost_serialization.dylib
  Referenced from: /Users/Shared/Jenkins/Home/jobs/CmdStan/branches/PR-618/workspace/test/../src/test/test-models/printer
  Reason: image not found

So I think these failures are happening on Mac OS X? Were we planning to support that?

On Travis the tests also fail. There it is on Linux. I suppose the makefiles are still messed up.
I already went through the trouble of getting VirtualBox installed. I hope I get around also having to install docker (inside that VirtualBox). We should consider having a docker for macos of our testing environment.
This is a tough one for me (I guess the mistake is super stupid... once found).

Ok, I think I got this under control. There were two main issues which are resolved now:

Due to the use of relative paths, the rpath linking was failing whenever binaries were called in slightly modified ways in comparison to when compilation took place. To solve this I am suggesting to turn to absolute path's for the rpath stuff which is what the PR in stan-math is doing. In the meantime I hard-code the MATH variable to point to the absolute path location during the tests (which we should probably remove at some point).

It is impossible to call with mpirun the non-MPI tests of cmdstan. The reason is that each test is setup to call multiple times other executables (test-models) in sub-processes. Each process tries to initialize the MPI environment and upon exit tries to tear this MPI environment again down, but this only works for the very first time; once MPI is teared down that's it. Any subsequent attempt to initialize again MPI will fail (since this all happens under a single call to mpirun). Therefore, I have disabled the use of mpirun for all but the MPI tests.

This should get us closer for a review I hope.

Seems like it's still failing in a similar way (on travis at least).
re: mpirun for non-mpi tests - I thought each test executable was called by mpirun individually?

@seantalts There are still build system hickups which I need to fight.
Note that many command stan test executables call via popen multiple times command stan programs. So you have
mpirun -np 1 test/.../command_test
and then command_test does multiple tests which involve calling different programs (value_fail/domain_fail/...). This triggers multiple sub-processes and each one attempts MPI setup and tear-down.

Oh, gotcha! Forgot we're in CmdStan - probably makes sense to not run CmdStan tests with mpirun given that.

Yep, this is what I am doing now. So tests are compiled with MPI on, but I don't run them through mpirun. Only the one true MPI test which I wrote is run via mpirun.
So now I am at my (hopefully) last issue which is related to makefile quirks:
make: *** No rule to make target `/stage/lib/libboost_mpi', needed by `build'.  Stop.

some path's are not set correctly such that the target is messed up. Will fix that later. At least Travis is now happy.

Awesome! thanks :D

Finally... by now Travis is green and all tests on the Jenkins do pass. I am guessing that Jenkins is still not OK, because of some warnings? Is the Jenkins counting the compiler warnings which just happen during compilation of the boos stuff?
Other then that this can be reviewed. Things to settle on:

Is the makefile logic fine? If yes I should probably alter stan-math to make cmdstan makefiles cleaner.
Currently there is no additional output from cmdstan on MPI things as this is beyond me (putting the output in the right place and then adjusting the tests - I do not know that)
Is the current doc enough? I am basically pointing people to the stan-math wiki as I would much prefer to not duplicate documentation for MPI matter in multiple places.

I will copy those notes to the PR above as well.
@seantalts, @syclik or @bob-carpenter a review possible?

@seantalts, @syclik - what is Jenkins failing on first step (remove previous builds)?

@mitzimorris Really weird behavior:

The Jenkins appears to use different machines and configurations on these. On one machine we use a clang++ and on another it is a clang++-3.6 compiler (corresponding to the CXX environment variable). For the clang++ case the tests turn out fine ("green") while on the other the tests for MPI break ("red"). In the red case there are weird linker errors which I am not able to reproduce.

Even if we get green for all tests, the Jenkins is still upset about 3 warnings from the compiler. These could stem from building boost libraries... not sure.

When you see clang++-3.6, that means it's building on the Linux box. You can look at the error messages in the old UI (click the door in the top right): http://d1m1s1b1.stat.columbia.edu:8080/job/CmdStan/job/PR-618/44/warnings24Result/
Looks like errors from boost's iterators and python bindings...?

So you are saying that things break on Linux on work on Mac then... ok, but on Travis everything works on Linux and Mac. Moreover, I cannot reproduce the problem on Linux in my VirtualBox. Any idea on the Linux problem? Can I use a different compiler on Linux.
The warnings from boost iterator and python bindings are almost for sure triggered by the boost build needed for the boost serialization and the boost mpi library... which is not under my control. Can I just increase the threshold counter for the MPI stuff to 3 (right now it accepts 0) or can we filter it out?

Here it looks like "break" just means "generates warnings?" Is that right?
I think the ideal solution might be to build the boost libraries in a separate stage that does not have the warnings parser run on them... Does that sound doable?

Yes, you are right. The build "breaks" due to warnings with the boost build on Mac. Your suggestion sounds good to me which is to pull out the boost build into a different stage... I will try to get that implemented (though I have never written Jenkinsfiles).
We still have a mystery of failing builds on the Jenkins Linux. On the Jenkins Linux we get very weird linker errors for the diagnose_test test. I have no way to reproduce the problem. Everything passes on

Travis Mac
Travis Linux (Ubuntu 14.04LTS)
my own VirtualBox Ubuntu 14.04LTS when using clang++-3.6
my own MacOS - High Sierra

You see, I have spent a huge time into this, but I have no idea where the linker problem is coming from.

Interesting. I will dive into the 2nd issue first and see if I can't make any headway. Can you post a sort of summary / what you've tried about it on this issue? I'll also post updates here as I figure things out or discover new questions, haha.

Oh, potentially another option for issue 1 (boost lib compiler warnings): Compile just the boost libraries with warnings muted, something like -Wno-everything (I think that is a real flag).

Wait, is that issue popping up in this PR (don't see it in the current Jenkins failure)? Is it just sometimes when it happens to get put on the Linux box?

I think this is pretty suspicious: [Non-windows interface tests with MPI] Building Boost.Build engine with toolset gcc...
I suspect that building the MPI libraries with GCC and then trying to link them with binaries built with clang will have weird linking errors, and that the Linux box is the only one with both gcc and clang installed...
When I tried to build it manually using ./bootstrap.sh --with-toolset=clang, I get another error which seems to be an open bug in gcc's standard library (which --with-toolset=clang is using, for some reason): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
I hate supporting multiple C++ compilers and standard library implementations :'(

clang is not really a good choice on Linux in most cases I have seen. Let try to set as compiler mpicxx only. This way everything is getting build with the same compiler which was used to build mpi. That should solve the situation and this would actually be what I would anyway always recommend people to do. Let's see.

So for what it's worth, the symbols its complaining are missing are legitimately missing from the shared libraries that we build with boost:
seantalts@Stanubuntu16:~/cmdstan$ nm -gC /home/seantalts/cmdstan/stan/lib/stan_math/lib/boost_1.66.0/stage/lib/libboost_mpi.so | grep communicator | grep operator | less
000000000001d460 T boost::mpi::operator==(boost::mpi::communicator const&, boost::mpi::communicator const&)
000000000001bcf0 T boost::mpi::communicator::operator ompi_communicator_t*() const

Not sure why you think that these symbols are missing. My impression is that things defined in
stan/lib/stan_math/src/math/prim/arr/mpi_cluster.o
somehow don't make it. Anyway, the last build just went fine... although I don't see if on mac or on Linux; so it's with a 50% change now working on Linux :).

That ng command prints the symbols in a shared library :P I would expect boost::mpi::communicator::operator int() const to be defined in libboost_mpi.so, no?
I'm running the build on the linux box manually and it's still not working...

nm also shows us that it is stan/lib/stan_math/src/math/prim/arr/mpi_cluster.o that is looking for boost::mpi::communicator::communicator(),
seantalts@Stanubuntu16:~/cmdstan$ nm -gC stan/lib/stan_math/src/math/prim/arr/mpi_cluster.o | grep communicator
                 U boost::mpi::communicator::communicator()

(that U is for undefined I believe)

Or woops, probably boost::mpi::communicator::communicator() is different from boost::mpi::communicator::operator int(). So maybe no information about mpi_cluster.so from that.

ooooh, this thread  has a clue that seems relevant:

However, I'm guessing that the archive that we're linking against was
compiled against OpenMPI.
That linux box does have multiple MPIs installed, including OpenMPI! And it also has a binary MPI library installed globally:

seantalts@Stanubuntu16:~/cmdstan$ dpkg --list | grep boost-mpi | less
ii  libboost-mpi-dev                         <IP_ADDRESS>ubuntu1                                      amd64        C++ interface to the Message Passing Interface (MPI) (default version)
ii  libboost-mpi-python-dev                  <IP_ADDRESS>ubuntu1                                      amd64        C++ interface to the Message Passing Interface (MPI), Python Bindings (default version)
ii  libboost-mpi-python1.58-dev              1.58.0+dfsg-5ubuntu3.1                               amd64        C++ interface to the Message Passing Interface (MPI), Python Bindings
ii  libboost-mpi-python1.58.0                1.58.0+dfsg-5ubuntu3.1                               amd64        C++ interface to the Message Passing Interface (MPI), Python Bindings
ii  libboost-mpi1.58-dev                     1.58.0+dfsg-5ubuntu3.1                               amd64        C++ interface to the Message Passing Interface (MPI)
ii  libboost-mpi1.58.0                       1.58.0+dfsg-5ubuntu3.1                               amd64        C++ interface to the Message Passing Interface (MPI)

Installing multiple MPI backends is asking for trouble. Can we get rid of openMPI?
The MPI we build against is determined by boost build automatically. If you want to set which one to take it is a bit tedious to do so (but can be done). However, as a default case we do not consider this.
If using openMPI is a lot easier, we can also do that - fine for me.

It's not really our machine, it's @bgoodri's. Maybe we should try to use OpenMPI there first? I don't have much experience in this area.

Is the rpath stuff we're doing supposed to allow globally installed MPI libraries take precedence over the ones we build as part of the build process? I guess that would make sense, right? So maybe on this box we should just run with that?

Hmm... the rpath stuff makes sure that we can link to the dynamic library using absolute paths. I would guess that during building on that machine, the system wide installed boost mpi library is picked up over the one which should be taken. Can we fix that?

Static would be preferable, but I never got this to work as the boost serialization lib is really hard in that regard. On clusters you usually have on all machines the same directory structure which is done via nfs. So this all will work on our cluster

Gotcha.
Whenever I seem to fix some of the mpi symbols not found, I get a bunch of error messages that Google suggests are because I'm using two different standard libraries or versions thereof... Messages like:
stan/lib/stan_math/src/math/prim/arr/mpi_cluster.o:(.rodata._ZTINSt3__120__shared_ptr_pointerIPN4stan4math11mpi_commandENS_14default_deleteIS3_EENS_9allocatorIS3_EEEE[_ZTINSt3__120__shared_ptr_pointerIPN4stan4math11mpi_commandENS_14default_deleteIS3_EENS_9allocatorIS3_EEEE]+0x10): undefined reference to `typeinfo for std::__1::__shared_weak_count'

@seantalts maybe I have found a way to deal with difficult systems. So I think the issue with Ben's Linux box is that during compilation of the executable, the -lboost_mpi flags cause the compiler to pick-up the wrong boost mpi which resides in the system library (those come first in the search path). Now, giving the -L option only adds to the search path, but we need to have the boost_mpi linked in why we ship. This is (hopefully) possible by giving the full path to the .so dynamic library - which makes the compiler happy in the link step. The linker itself then also needs to be told to find the library and where (using -rpath).
Everything builds now fine again, but the last run was on the Mac. Can we force execution of the tests on Ben's Linux?
Also: For the moment being I increased the warnings threshold to 3 for the MPI tests only. I haven't found a way to run Jenkins in two stages and there is no pre block allowed. Giving compiler flags to the boost build process turns out cumbersome.
Amazing how much trouble we run into here...

@mitzimorris I think all trouble is now settled. If you think it is worthwhile to add some output to cmdstan which tells the user that MPI is configured and many processes are available, then it would be great if you could show me how to best add this to cmdstan (design wise in the code and how the tests need alignment).
Should we do this for MPI, then we should probably also do a similar thing for the case of threading. Thus, we can also just leave things as they are and not provide additional output as both parallelism options are runtime configuration options.
Another thing to consider is the reported run-time. This is currently the used CPU time, but not the wall-clock time. That means when parallelism is enabled the reported run-time corresponds roughly to the single-core runtime, but not the actual wall-clock runtime. This is a new distinction which we introduce due to parallelism. I am not sure what's best. Users will probably expect that a wall-clock runtime is reported instead of a CPU time (which btw is anyway misleading as it does not reflect the actual run-time which depends on overall load on the machine) - I would expect the wallclock time to be reported (or we should make the output messages more specific in this regard).

Okay, I think I got it working, but I think we need to fix the last bullet point I just added to this issue in the Math repo so we can continue testing on Linux, since we like to set a specific compiler for our tests and that setting is not percolating to the Boost libraries.

Well, I should say building is working. There are some test failures due to the spurious messages OpenMPI prints:
[ RUN      ] StanGmArgumentsConfiguration.TestOutputWithoutMethod

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "--------------------------------------------------------------------------"

Expected: expected_line

Which is: "A method must be specified!"

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "[[40262,1],0]: A high-performance Open MPI point-to-point messaging module"

Expected: expected_line

Which is: "Failed to parse arguments, terminating Stan"

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "--------------------------------------------------------------------------"

Expected: expected_line

Which is: "A method must be specified!"

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "[[40258,1],0]: A high-performance Open MPI point-to-point messaging module"

Expected: expected_line

Which is: "Failed to parse arguments, terminating Stan"

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "--------------------------------------------------------------------------"

Expected: expected_line

Which is: "A method must be specified!"

src/test/interface/arguments/argument_configuration_test.cpp:1211: Failure

Value of: actual_line

  Actual: "[[40270,1],0]: A high-performance Open MPI point-to-point messaging module"

Expected: expected_line

Which is: "Failed to parse arguments, terminating Stan"

[  FAILED  ] StanGmArgumentsConfiguration.TestOutputWithoutMethod (87 ms)

http://d1m1s1b1.stat.columbia.edu:8080/blue/organizations/jenkins/CmdStan/detail/PR-618/61/pipeline

So you have openMPI and boost mpi installed on the Linux machine? BTW, what distribution is installed on that Linux box? Ubuntu 14.04 / 16.04 / 18.04?
Hopefully I can reproduce these test failures.

OpenMPI is installed, boost was just our bundled version I think. the machine got hosed when I temporarily turned it to gcc for testing (eats too much memory and apparently fills swap in a way that is unrecoverable, amazing) so I can't check versioning right now.

hmmm... after pulling in the latest changes I get failures due to issues with the dynamic library not being found. I need to check where this is coming from.

It would really help if I knew the exact Linux distribution on that Jenkins box... anyway. What seems to be an issue is that OpenMPI is not configured correctly and is thus very verbose when starting up due to not being configured right. I suggest that OpenMPI is configured correctly on the machine so that a hello world program does not lead to any extra messages other than the hello world (in the boost mpi docs is code for this).

I almost forgot about this file, but my openMPI is configured using a file
~/.openmpi/mca-params.conf
with the content of
btl=self,vader
This tells openMPI to use a certain type of communicator. I guess this should be written into some system config file on the Jenkins in /etc/openmpi/mca-params.conf (I am guessing here, but the doc should tell us quickly).

Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-81-generic x86_64) is the distribution.
I can add that file.

Added the file, re-running on Jenkins

Thanks, @wds15 and @seantalts!
On Thu, Jun 21 2018 at 5:14 PM<EMAIL_ADDRESS>wrote:

Added the file, re-running on Jenkins
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/cmdstan/pull/618#issuecomment-399245575, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FzdnTazhCd72GE9ON5KaqO2YF8LFks5t_AywgaJpZM4T-WEg
.

I believe it often is the aforementioned ABI compiler / stdlib mismatch
issue (I think I forgot to mention that the standard library used also has
to be the same).
On Fri, Jun 22, 2018 at 8:27 AM, wds15<EMAIL_ADDRESS>wrote:

Is the segfault on the Jenkins a possible compiler mismatch problem? I
hope I can reproduce this problem in a VirtualBox machine to debug this. So
far my VirtualBox was running 14.04, but it looks like I will endup
installing all LTS at the end.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/cmdstan/pull/618#issuecomment-399348367, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7O5WmuLjlgzseBCTLZ7ognHgYN-Eks5t_JxLgaJpZM4T-WEg
.

Hmm.. stdlib also needs to match... on Travis Linux we test with mpicxx -cxx=clang++-3.8 successfully. So that would suggest that we can use clang++-3.8 without libc++ and get a working system.
Maybe using CC=mpicxx -cxx=clang++-3.8 is a good thing as this leads to an essentially failing detect_cc which will avoid the use of libc++ (maybe we should actually consider in general to drop the use of libc++ on Linux?).

I'll put in a PR to try to drop the libc++

Great. Dropping libc++ on Linux would have saved us from quite a bit of trouble (e.g. that was a problem for threading as well).

Okay so this seems to pass tests - seems like we don't need the libc++ in yet. Can you just write in the (wiki)[https://github.com/stan-dev/math/wiki/MPI-Parallelism] more about the ABI stuff we talked about and what a system that can use MPI looks like (and maybe hints on how to get a system there)?
Then I think we can merge, right?

Ok, I doc that on the wiki. The one PR you did and which I slightly updated (boost/build-2) would be nice to also merge in stan-math. This one is a nice clean-up. Then it can go out.

Gotcha, okay I'll merge your code into that math PR and then you can
approve it?
On Wed, Jun 27, 2018 at 02:48 wds15<EMAIL_ADDRESS>wrote:

Ok, I doc that on the wiki. The one PR you did and which I slightly
updated (boost/build-2) would be nice to also merge in stan-math. This one
is a nice clean-up. Then it can go out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/cmdstan/pull/618#issuecomment-400561888, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7DRrAsQSoRkRMyH6JnFjtJS-JnVSks5uAyrYgaJpZM4T-WEg
.

--
Via smol keyboard

I added some doc on the Math wiki page for MPI on the compiler stuff. I hope this scares people enough to just go with the defaults which we know work.

Whow... MPI is "in"...

Woohoo!

This PR broke the default config on Mac... See http://d1m1s1b1.stat.columbia.edu:8080/job/CmdStan Performance Tests/job/master/153/console
Seems like the default compiler has changed from clang++ to cc, and maybe the lack of -stdlib=libc++ is causing these linker errors?

Bummer...
I did add to the main makefile of cmdstan
CXX = $(CC)
which does align it with the stan-math makefile, but turns out that this is the wrong thing?! I am pretty sure we have that line in stan-math (which does not make it correct)... so we need to align.
When I remove that line, then all seems to be working again (I should really stop working on makefiles)... and there seems to be no issue with libc++.

You're right, I think there was some change in CmdStan makefiles to remove
this a while ago, and then there is still an open PR in Math (failing
tests) to refactor Math makefiles. The whole build system needs a solid
refactoring - hoping we can get someone interested in maybe even a cmake
rewrite... So don't blame yourself, haha.
On Mon, Jul 2, 2018 at 17:16 wds15<EMAIL_ADDRESS>wrote:

Bummer...
I did add to the main makefile of cmdstan
CXX = $(CC)
which does align it with the stan-math makefile, but turns out that this
is the wrong thing?! I am pretty sure we have that line in stan-math (which
does not make it correct)... so we need to align.
When I remove that line, then all seems to be working again (I should
really stop working on makefiles)... and there seems to be no issue with
libc++.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/cmdstan/pull/618#issuecomment-401938923, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7CuGqtb73JTNFRNhc2rd7FHQwtwzks5uCo2agaJpZM4T-WEg
.

--
Via smol keyboard


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29008

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29008

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/38784

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/45111

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/51168

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/52279

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/53668

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/55502

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/68628


Remove proxyquire dependency

@rpancham Can you please send a PR for this?
https://github.com/nodeshift-starters/nodejs-rest-http-crud/blob/opentel/package.json#L34

PR merged https://github.com/nodeshift-starters/nodejs-rest-http-crud/pull/311


async is a keyword on 3.7

Fixes https://github.com/elastic/elasticsearch-py-async/issues/44

I've signed the CLA, not sure how to update the CI results.

@hroncok It should be something like:
ensure_future = getattr(asyncio, 'ensure_future') or getattr(asyncio, 'async')

otherwise the following error occurs on Python 3.7:
AttributeError: module 'asyncio' has no attribute 'async'

I propose to drop None in last getattr, to make it fail eventually if neither async/ensure is available.


Update README remote execution explanations.

Buildfarm, BuildGrid and Buildbarn are all open source
remote-execution implementations and not alternatives of eachother.

Thanks!