Dimmer EcoDim Eco-Dim.07

Device description
Zigbee & Z-wave wall dimmer Eco-Dim.07
Zigbee2mqtt page
https://www.zigbee2mqtt.io/devices/Eco-Dim.07.html
MQTT message with device information
Device '0x086bd7fffe5cecf6' is supported, identified as: EcoDim Zigbee & Z-wave dimmer  (Eco-Dim.07)
{"dateCode":"20200701","description":"Zigbee & Z-wave dimmer ","friendly_name":"0x086bd7fffe5cecf6","hardwareVersion":1,"ieeeAddr":"0x086bd7fffe5cecf6","lastSeen":1615309065623,"manufacturerID":4714,"manufacturerName":"EcoDim BV","model":"Eco-Dim.07","modelID":"Dimmer-Switch-ZB3.0","networkAddress":63379,"powerSource":"Mains (single phase)","softwareBuildID":"3.09","type":"Router","vendor":"EcoDim"}],"type":"devices"}'
MQTT messages from device
zigbee2mqtt:info 2021-03-09 20:58:09 MQTT publish, topic: 'zigbee2mqtt/Dimmer Hal', payload: '{"brightness":79,"linkquality":87,"state":"OFF"}'
zigbee2mqtt:info 2021-03-09 20:59:11 MQTT publish, topic: 'zigbee2mqtt/Dimmer Hal', payload: '{"brightness":79,"linkquality":99,"state":"ON"}'
MQTT state change commands
If device supports state change put MQTT topics + payload examples to change device state here
Thank you so much for your great work on this plugin!
Rene

Such device is already supported by the plugin. Please make sure that you are using the latest versions of zigbee2mqtt and plugin


global: new bucket quota validation

NEW Adds bucket quota validation when files are added (closes #25).

Signed-off-by: Nicolas Harraudeau<EMAIL_ADDRESS>

Remember to add yourself to AUTHORS as well.

Coverage decreased (-0.2%) to 90.155% when pulling 11c71cd543fa6296e26c061dc922e6f3a5168f51 on nharraud:quotas into 286cda7b198f1423831ddff43510a9c8607e47e6 on inveniosoftware:master.

Coverage decreased (-0.2%) to 90.155% when pulling 9ba60ae4a0d7f5f44137393428286de154658440 on nharraud:quotas into 286cda7b198f1423831ddff43510a9c8607e47e6 on inveniosoftware:master.

Coverage decreased (-0.2%) to 90.155% when pulling 9ba60ae4a0d7f5f44137393428286de154658440 on nharraud:quotas into 286cda7b198f1423831ddff43510a9c8607e47e6 on inveniosoftware:master.

Coverage decreased (-0.2%) to 90.155% when pulling 9ba60ae4a0d7f5f44137393428286de154658440 on nharraud:quotas into 286cda7b198f1423831ddff43510a9c8607e47e6 on inveniosoftware:master.

Coverage decreased (-0.2%) to 90.155% when pulling 9ba60ae4a0d7f5f44137393428286de154658440 on nharraud:quotas into 286cda7b198f1423831ddff43510a9c8607e47e6 on inveniosoftware:master.

LGTM. Please rebase and I'll merge.

Coverage increased (+0.6%) to 90.933% when pulling eae5edc7bab2a2a21f37adc9ff0f492edd378b9d on nharraud:quotas into 4bd76d526118fac9f725e44cfce61141f5338c9e on inveniosoftware:master.

@lnielsen ready


HC-487: Test out and deploy locally a Elasticsearch service in clustered mode (multi-node)

This PR adds support for operating Elasticsearch in clustered mode. The ES cluster is composed of nodes on mozart, grq, and metrics. With this PR, Elasticsearch can still be operated in a non-clustered mode.
This addition has been tested in SWOT PCM by restoring a snapshot from operational in flight data and performing the SWOT PCM smoke test. To make sure these updates are backwards compatible, @mcayanan is currently running a force branch on the NISAR side.

I am re-running the NISAR force branch as it failed likely due to those bugs I reported on earlier: https://nisar-pcm-ci.jpl.nasa.gov/job/force-branches/job/mkarim-force_branch-E2E-test/232/
I had to re-build the Verdi docker image and pull in your bug fixes. I think that should do it?


Bugs in generating wsj0-2mix dataset

🐛 Bug
Should use mv1 instead of mv2 to get wav files
To Reproduce
https://github.com/mpariente/asteroid/blob/0bdec2644f2d770d037ce804b7f70cb98bd5c9fa/egs/wsj0-mix/DeepClustering/local/convert_sphere2wav.sh#L31
The line uses both mv2 and mv1 to get wav files. But the mv1 will be covered by mv2, resulting in the generated wav files being from mv2. The mv1 is noise-free while the mv2 is noisy. The wsj0-mix dataset is expected to use mv1.
The correct code is
wav=`echo "$line" | sed "s:wv1:wav:g" | awk -v dir=$wav_dir -F'/' '{printf("%s/%s/%s/%s", dir, $(NF-2), $(NF-1), $NF)}'`
Expected behavior
We tested the datasets generated by mv1 and mv2. It is observed that the former can reproduce the results, the latter is worse around 1-2 dB in SI-SNR.
Our results with mv1, the final validation loss was about 2950.

I am sorry that our results with mv2 were deleted, its final validation loss was about 3500.
Environment

Asteroid-master
PyTorch 1.4.0
PyTorchLightning 7.6.1

I think this is right and has been reported elsewhere as well.
I think I only had wv1 when I generated wsj0 in the first place so I didn't notice the problem.
I checked now and you're right.
Would you like to submit a PR for that please?
Thanks again !

Closed by #166


How to get the error information of engine crash on Android？

Godot version:
2.3.4
OS/device including version:
GLES2
Issue description:
How to get the error information of engine crash on Android？ win10 platform runs well and crashes on Android platform

Please don't ask support questions here, as this issue tracker is meant to be used for bug reports only. Use one of the other community channels instead.

Please don't ask support questions here, as this issue tracker is meant to be used for bug reports only. Use one of the other community channels instead.


chore: clean fee utils

This change is

Codecov Report
Attention: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.

Project coverage is 78.23%. Comparing base (702f401) to head (e440026).
Report is 2 commits behind head on main.

Files
Patch %
Lines

crates/blockifier/src/fee/actual_cost.rs
80.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1968      +/-   ##
==========================================
+ Coverage   78.17%   78.23%   +0.06%
==========================================
  Files          62       62
  Lines        8842     8854      +12
  Branches     8842     8854      +12
==========================================
+ Hits         6912     6927      +15
  Misses       1492     1492
+ Partials      438      435       -3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Intersting bug that could be a feature

Windows Build Number
19042.985
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020
Distro Version
20.04.2
Other Software
Docker Destop 3.3.3 (64133)
Repro Steps
Windows went to sleep. On wake up, the windows terminal was gone.
However all the active sessions were still running. I have now no access to them (well, using terminal that is).
Here a ps:

and the tabs actually opened after wake on:

Surprising bug but could be a nice feature, having many terminal instances with the abilities to put them in the background (a kind of ctrl-z/fg but all smoothly using terminal ;)
Not sure if it is related to Terminal or WSL but wsl uses to end all process when there is no active sessions left (daemons included).
Expected Behavior
The sessions should be killed as it was.
Actual Behavior
Sessions are kept active
Diagnostic Logs
No response

/logs


Dashboard incorrect number of hosts

So just the dashboard shows 0, but when you go to the proxy hosts list everything is correct?

yes. seems so.

Have a look at your browsers developer console, whether it shows anything that could be helpful. Also have a look at the network tab in your browsers developer console when refreshing the page. It should contain a network request with file name hosts, and if you click on it you should see it is a request to <domain>/api/reports/hosts. What is the response of this request?

Before holidays, i updated it via apt update && apt upgrade... now i came back and wanted to to i again.
but now i see that ALL space on my ~30gb VM HD is used:

when i enter df i get that:

I don't no what this is...

Maybe the log files?

Which is /var/lib/docker/overlay2/c52a5ad4ec466b99391ce1cb4d5227ff32f215473602df5a722be35be7ea48fa/merged which needs 100% ??

Maybe the server was hacked? (has no ssh connetion to port 22 in public internet)

Is your product using log4j? Was i hacked!?!?

No, nothing used by npm is Java-based so it has nothing to do with log4j. So if you were actually compromised it was most likely due to weak passwords, an insecurely set up server or (though unlikely) due to some unknown vulnerability.
But must likely you weren't hacked. Is there a specific file which is that large? It could be the logs. It so, you would have to create your own logrotate config and mount it into the container. Also have a look at the original logrotate config to see how it is set up by default, and what you can change to have the log files deleted earlier.

Makes no sense in investigate close before the "off-topic"-Problem is solved...

I also startet a new installation with must current versions (debian , docker, mariadb), but there fails something with db condig in yml file: https://github.com/jc21/nginx-proxy-manager/issues/1720

...

closed wrongly - now opend again ;-)

closed

What i see is that when i open developer tools then do a browser refresh:

...but nothing with /api/reports/hosts:

[complete new installation with debian 11 as described above.. ]

After adding one (1) "HTTP only" i see:

Does this only work if http instead of https...? Strange..

Were your screenshots from the network tab taken after the dashboard was loaded while the network tab was open? Because it seems the proxy host page was loaded, not the dashboard.
So it does work for http only hosts, but it is still not counting the https hosts? Or have you only tried http only hosts?

Visited page
Called dev tools
Refreshed the page

So it does work for http only hosts, but it is still not counting the https hosts?
Yes.
Or have you only tried http only hosts?
No. I have 4 https and 1 http host

Hm, I'm really not able to replicate it, no matter what combination of https and http hosts I have.
What database are you using? MySQL or SQLite?

SQLite

Shift-F5 for browser refresh (bypass cache in chrome / chromium [so also edge] engine based rowsers) does also not show all 5 hosts on main (entry) page

Hm, then I'm really at a loss here, I have no clue what might cause something like this

anyway..

Another question HERE: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1736


Updating-Feedback

Docs Build status updates of commit 79d1d88:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/tutorials/dragonboard.md
:white_check_mark:Succeeded

windows-iotcore/tutorials/intel.md
:white_check_mark:Succeeded

windows-iotcore/tutorials/nxp.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


[Core Request]: SameBoy for GB/SGB/GBC

mGBA is an an accurate emulator for GBA, but a par one for the GB/SGB/GBC: they don't prioritize accuracy in that department. SameBoy has a retroarch core. Not exactly sure the way to go about compiling for wasm, but from what I have read through, I think it's trivial on your end?

This should be doable, though I'm pretty sure mGBA does have pretty good accuracy for GB/GBC emulation? (At least better than Gambatte.) If you want to build it yourself, instructions are here.

mGBA's accuracy of the GB systems is functional for most things, though there are edge cases that don't work, and there are better emulators for it that focus on accuracy, rather than playability.


Invalid Tile origin when set as Bottom Left

Operating system or device - Godot version: 2.1
Issue description:
I'm not sure if I'm misunderstanding the property, but when I set the Tile Origin to Bottom Left the tile is set like Top Left but the origin is even higher and the texture is lower.
As Top Left to compare

As Bottom Left with error

This seems right to me, the tile image is placed at the bottom left of the tile.

My bad, I was thinking in something  like this.

Til origin "Bottom Left" is specifically made for y-sorted TileMaps. In the TileSet, you manually set the origin/pivot for each tile (which is easy to do by pointing and pressing the V key). That origin is then anchored to the bottom-left (or whatever tile origin mode is selected) in the TileMap.
What this mode doesn't do is inverting Godot's y-axis. Godot has y0 on the top, so sprites and tiles are drawn below the origin. This makes Godot's coordinate system highly impractical for y-sorting, but the "Bottom Left" mode helps work around this.
This issue also has some explanation why this mode is useful #3892

I'll close this as working as expected. If you want, you can open a new issue/request to implement new origin mode that accounts for tile size.


Update companies.yml

Adds or updates the following companies, events, or universities:

DE-CIX

Checklist
Company updates

[x] I have put the most recent relevant date in the "Last Update" column
[N/A] I have linked to the article about the change, not the company's homepage (Please put N/A if there is no public post)

Closing due to rebase and staleness. Feel free to re-open after fixes, thanks for your patience.


[Tooling] Update docs with newly added maven profiles

Description:
Maven profiles are added to the maven multi module projects to facilitate building only a subset of modules at a time. Docs should be updated accordingly.
Related Issues: https://github.com/wso2/devstudio-tooling-ei/issues/888

Content already added.
[1] https://ei.docs.wso2.com/en/latest/micro-integrator/develop/create-integration-project/#building-selected-mmm-profiles


Feature request: DN pipe EN 10255

Hi,
nice tool great work
Is it possible to implement a further pipe diameter type? aka EN10255

Hi Rene,
Thanks! Sure it would be possible for someone to add another pipe schedule to fluids. I know there are lots more standards, like for PVC, ABS, cooper tube, and the standards used in different countries. I agree it would be a good feature. I don't have it on my agenda for the moment, but would be happy to merge a good PR with tests. Alternatively, next time I revisit nearest_pipe (if I did get around to increasing the number of supported pipe standards), I would only be able to include EN10255 if I had a copy of the standard as well.
Cheers,
Caleb

I think i could prepare the EN10255 addition, i see into the pipe.py.
If it is done i make a pull-request.

I added the schedules BS1387LIGHT, BS1387MEDIUM, BS1387HEAVY, they will be in the next release.
Sincerely,
Caleb


Added support for addition and concatenation

@RichieConsiglio It looks like all the changes that were going to be in this PR ultimately ended up in other branches, so we'll just close this one out without merging. I recommend that you delete your branch and then create a new one off the current for-merging branch before starting a new task.


[$500] Web - Task -  Emojis, emoji picker icon,  and edit icon are disapeared when hovering over notification from completed task

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the website
Click the + icon from LHN
Click assign task
create a task by sharing with someone
Complete the task
Hover over the completed task notification
Observe the tool-tips

Expected Result:
There should be emojis, emoji picker icon, and edit icon when hovering over the notification
Actual Result:
Emojis, emoji picker icon, and edit icon disappear after a seconds
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/9046948e-8247-4801-bc1b-02455b7a7717
https://github.com/Expensify/App/assets/93399543/333d3898-8c63-40c6-a6ef-503712e8beb7
Expensify/Expensify Issue URL:
Issue reported by: @misgana96
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1694694710329109
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01bc63337bbb697954
Upwork Job ID:<PHONE_NUMBER>154939904
Last Price Increase: 2023-10-04

@allroundexperts should this go on hold for https://github.com/Expensify/App/issues/24644?

This is no longer on hold and still reproducible:

@allroundexperts any thoughts on the proposals we've already received?

@allroundexperts any thoughts on the proposal above?

@dukenv0307 could you please share a video with the same steps as in the original video in the issue?
In your video, the task is in incomplete state when you're hovering to see emojis whereas in the video it's in completestate when the bug is happening. Just to be sure, thanks

Thank you @dukenv0307

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@lakchote] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@lakchote] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@lakchote] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@allroundexperts] Determine if we should create a regression test for this bug.
[ ] [@allroundexperts] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [@kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

🎯 ⚡ Woah @allroundexperts / @dukenv0307, great job pushing this forwards! ⚡
The pull request got merged within 3 working days of assignment, so this job is eligible for a 50% #urgency bonus 🎉

when @dukenv0307 got assigned: Oct 13 6:55am
when the PR got merged: Oct 16 10:31am

On to the next one 🚀

Payouts due:
Issue Reporter: $50 @misgana96
Contributor: $500 @dukenv0307
Contributor+: $500 @allroundexperts
Eligible for 50% #urgency bonus? Yes
Upwork job is here.

@allroundexperts can you please identify the PR that caused the bug? Thanks!

Checklist

There isn't any PR on the frontend which caused this. This was supposed to be fixed from the backend but due to time constraints, we decided to fix this on the frontend.
N/A
N/A
A regression test would be an overkill IMO given that this is really small. However, if there's a disagreement, then following are the steps.

Regression test

Create a task -> Assign it to someone -> Complete the task
Hover over the completed task notification

Verify that the options inside the mini context menu do not change with time.
Do we 👍 or 👎 ?

Closing as all tasks completed, @allroundexperts please request your payment via Newdot.

$750 payment to @allroundexperts based on summary above.


Encoding::UndefinedConversionError error in 1.4.0

Upgrading to 1.4.0 has caused my integration to break with the error
Encoding::UndefinedConversionError: "\xFF" from ASCII-8BIT to UTF-8
I'm using paperclip.

Hi @themire thanks for raising the issue.
I've found this related issue on the paperclip repo:
https://github.com/thoughtbot/paperclip/issues/2299
Please could you give me any further details regarding the API options you're using? And your version of Paperclip?
Many thanks,
Oli

@themire I think I've identified the issue. Please could you try the following branch which includes a fix?
gem "remove_bg", git: "https://github.com/remove-bg/ruby.git", branch: "binary-data-fix"

@odlp Yes, that looks to have fixed it!
I'm using it as follows:
RemoveBg.from_url(url,
        api_key: ENV.fetch('REMOVE_BG_API_KEY'),
        type: 'person',
        bg_color: '#ffffff'
      )

Thanks 👍

@themire I've released version 1.4.1 which includes this fix.
Thanks again for raising the issue & your assistance verifying the fix.


Terminal in SSH extension requires GLIBC 2.28

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: Nightly, 1.78.0
OS Version: Windows 10

Working in 1.77.3, not working in 1.78.0 and Nightly
Steps to Reproduce:

Open a Debian 9 SSH. SSH instance is Armv7
Open terminal

The terminal process failed to launch: A native exception occurred during launch (/lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by /home/linuxname/.vscode-server/bin/252e5463d60e63238250799aef7375787f68b4ee/node_modules/node-pty/build/Release/pty.node)).
Downgrade to 1.77.3, the terminal opens again.
Maybe it's caused by recent update to electron 22?
https://github.com/microsoft/vscode/commit/e5f61433b58084dcf312d9845f090ff2efc31b54

Merging to https://github.com/microsoft/vscode/issues/180798
Please refer to that issue for context.


Wiki pages are outdated

@tardypad As we merged the #74 PR, the wiki pages and README file are outdated! so I'll create this issue to update the docs!
I would appreciate if you can find a way to generate docs automatically!

Sorry, I forgot to update the README indeed.
I didn't know about those wiki pages though.
Personally I don't find any value in maintaining such a documentation in a wiki.
If you want to have some more details for each struct/function/... and have some examples, they should be added to the code in the repository in the standard Go way. Then everything will appear automatically in https://pkg.go.dev/github.com/LeaseWeb/leaseweb-go-sdk. This is where the users of the SDK will naturally expect to find all that information.


Store Sensor Data in Cloud Storage in SAP Data Hub, Trial Edition

Tutorial URL: https://developers.sap.com/tutorials/datahub-trial-v2-pipelines-part02.html
Copy any row from the output and paste it in the frame below and click on Submit Answer -
Step 4 Execute the data pipeline step is not working.
After executing the pipeline, my terminal's row values are correct over GCS.
However, the submitted answer is incorrect.
Here is any requested row from the output->
[2020-04-15 20:17:23.251] sensordata/file_177.txt
GCS output ->
0,6,25.518828381483885,59.19748467946496,569.1695216316563,0.9524518306088944,23.83941607361044,59.481948627085714,1,607.0686982802245,492.2521727728777

I am still looking for an answer, thank you.

@dimvor Can you help here?
@nilpeksen note the tutorial URL is changed to https://developers.sap.com/tutorials/dataintelligence-trial-v2-pipelines-part02.html but there is a redirect

@nilpeksen
Please put the content from the beginning of the line. Means you need to include the date time and the rest

Thank you for your feedback. The issue seems to be resolved, so I am closing the issue.
If you still have questions, feel free to reopen the issue.


Autorefresh and fire event

Keep the prices up-to-date and fire an event whenever the best bid/ask changes

We now auto-refresh and fire an event for the coins as new data comes in.


Installing sbol-utilities via pip does not add graphviz to system path

System: Ubuntu Linux 20.04.3
Steps to reproduce:

Create conda virtual environment, python version 3.9
Run pip install sbol-utilities
In python interpreter:

Python 3.9.7 (default, Sep 16 2021, 13:09:58)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sbol3
>>> from sbol_utilities.graph_sbol import graph_sbol
>>> doc = sbol3.Document()
>>> graph_sbol(doc)
Traceback (most recent call last):
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/site-packages/graphviz/backend.py", line 170, in run
    proc = subprocess.Popen(cmd, startupinfo=get_startupinfo(), **kwargs)
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/subprocess.py", line 951, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/subprocess.py", line 1821, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'dot'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/site-packages/sbol_utilities/graph_sbol.py", line 51, in graph_sbol
    dot_master.render(outfile, view=True)
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/site-packages/graphviz/files.py", line 238, in render
    rendered = backend.render(self._engine, format, filepath,
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/site-packages/graphviz/backend.py", line 235, in render
    run(cmd, capture_output=True, cwd=cwd, check=True, quiet=quiet)
  File "/home/nls119/lib/miniconda3/envs/sbol_utils/lib/python3.9/site-packages/graphviz/backend.py", line 173, in run
    raise ExecutableNotFound(cmd) from e
graphviz.backend.ExecutableNotFound: failed to execute 'dot', make sure the Graphviz executables are on your systems' PATH

However, installing graphviz from conda conda install graphviz fixes this.

@bbartley This issue is beyond my current knowledge of python requirements management --- do you know a good path to resolving it?

I don't think there's anything sbol-utilities can do about this. The python graphviz package requires a working installation of Graphviz (see https://graphviz.readthedocs.io/en/stable/manual.html#installation). Conda must automatically install that as part of the conda packaging of the graphviz python package.
I get the same error in a python interpreter if I just pip install graphviz. I do not have Graphviz installed.
Maybe this is a documentation issue. Explain that if a user is going to use graph_sbol they'll need a working installation of Graphviz.
graph_sbol could also catch this error and provide a better message to the user, like recommending an installation of Graphviz.

I've added documentation addressing this with pull #54


ERR: invalid RTP-Info: invalid key:  url with some Axis cameras

Hello,
With some Axis cameras (cannot tell exactly which ones, might be related to firmware version), RTP parsing is rejected, here is the complete log:
2021/04/02 16:55:50 [D] [15/0/14] [path 91] [rtsp source] s->c RTSP/1.0 200 OK
CSeq: 6
Date: Fri, 02 Apr 2021 14:55:49 GMT
RTP-Info: url=rtsp://<IP_ADDRESS>/axis-media/media.amp/trackID=1;seq=58477;rtptime=1020884293, url=rtsp://<IP_ADDRESS>/axis-media/media.amp/trackID=2;seq=15727;rtptime=1171661503
Range: npt=0-
Session: 21909AB6

2021/04/02 16:55:50 [I] [15/0/14] [path 91] [rtsp source] ERR: invalid RTP-Info: invalid key:  url

Running current GIT master.

Thanks, this is fixed in main and will be added to the next release

Thanks a lot, logs are indeed gone.

added in v0.15.3


Want to adapt to forge 1.18.2

This is a great mod, which is used by many people in our community. But I want to use it on forge 1.18.1. Have you considered revising and applying forge-1.18.1?
[This is a message about using translation software. The syntax and tone may not be standard. Please forgive me.]

Wait, what? Why is the title 1.18.2? Sorry, it should be a request for adaptation to 1.18.1


Adding snowflake parameters to lambda env

Relates to: https://github.com/chanzuckerberg/napari-hub/issues/695
Depends on: https://github.com/chanzuckerberg/sci-imaging-infra/pull/69
Solution
Adds the required snowflake environment variable to the lambda from secrets. Defaults to "" when values don't exist in the secrets.

Thanks for adding these!! Congrats on your first napari hub contribution 🎉


How to dynamic load Named Components?

Hi All,
I have the following route config now, I'd like to convert it to dynamic routes using System.import, any solutions there? Thanks.
<Route path='admin' components={{leftSide: LeftComp, main: Admin, rightSide: RightComp}}/>

There's no route config attached. Take a look at this for an example diff: https://github.com/mxstbr/react-boilerplate/pull/254/files#diff-6db976b763ed71154781e45807c0d4e5


cuckoo.py --clean Dababase error (MySQL)

Firstly, I'm currently testing with MySQL, not sure if there are similar issues with SQLite or Postgres.
Seems we have a FK conflict when attempting to drop tasks, because we are not dropping the guests table first:
cuckoo@cuckoo:/cuckoo/personal-cuckoo$ ./cuckoo.py --clean
2015-02-01 01:54:46,711 [lib.cuckoo.core.database] WARNING: Database error dropping all tasks: (IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`cuckoo`.`guests`, CONSTRAINT `guests_ibfk_1` FOREIGN KEY (`task_id`) REFERENCES `tasks` (`id`))') 'DELETE FROM tasks' ()
2015-02-01 01:54:46,718 [lib.cuckoo.core.database] WARNING: Database error dropping all samples: (IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`cuckoo`.`tasks`, CONSTRAINT `tasks_ibfk_1` FOREIGN KEY (`sample_id`) REFERENCES `samples` (`id`))') 'DELETE FROM samples' ()

The samples table drop subsequently fails since the task table is not dropped.

Yes, it's true. I think @skier developed this "clean" with sqlite which doesn't take care of FK. I am going to fix this hopefully today. Thanks for reporting.

https://github.com/cuckoobox/cuckoo/pull/455 should take care of MySQL, and I'm assuming Postgres, but may require further testing.


minor fix of the $interval doc

The promise can be undefined
https://github.com/angular/angular.js/blob/v1.4.3/src/ng/interval.js#L180-L188
https://github.com/angular/angular.js/blob/v1.4.3/test/ng/intervalSpec.js#L309-L312

I signed it!

I suppose this matches the docs for $timeout.cancel(), so lgtm --- the PR text is not super clear, though. The doc isn't saying anything about the type being undefined, it's saying the parameter is optional, and changing the type name. But it's fine.

@caitp Thanks for the clarification )


Feature/unify colours

Partial fix to #84:

Add an "if" block in src/home/util.js to make the "arc" layer use the colour range given by the ColourPicker.
Start and end of each arc will be the extremes of the chosen colour range.

Thanks @nbarlowATI brilliant


ACTION REQUIRED: Changes to pulling Chainguard Images

Hey there Chainguard here.
We noticed that you are using Chainguard Images, thank you! We wanted to make you aware of an upcoming change that will impact your project.
Starting August 16, 2023 public users will no longer be able to pull images from our registry (cgr.dev/chainguard) by tags other than latest or latest-dev. Please see the announcement for more information.
You are currently using the following.
In https://github.com/ortelius/ortelius/blob/57f50244555b5ab9c39b9e683d0cf30edbe35998/docker/DockerfileUI:

cgr.dev/chainguard/jdk:openjdk-17

Our goal is to prevent your project from experiencing any disruptions. Please see the migration guide for options.
If there's more we can do to help please reply to this issue or email us at<EMAIL_ADDRESS>Thank you!

This is not an issue since we use the sha in dockerfiles

Looks like this one is pulling by a tag that has been removed (openjdk-17).
https://github.com/ortelius/ortelius/blob/3475607da72e90e8c43869ce4a66f333e853dde0/docker/DockerfileUI#L8


CertificateServiceClientCredentialsFactory handles public, Gov, and private clouds

Fixes #6805
This change also handles certificate auth against private clouds as the PasswordServiceClientCredentialFactory does.

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll


Add Feature to customize the minimap

Minimap (line spacing and line scaling) Feature
Added feature that allows us to edit the line spacing and line scale of the Minimap.

https://github.com/godotengine/godot/assets/90724319/1ce6e157-3928-4a62-9389-f0d63ac69604
Why?
The current minimap in Godot is tiny and small.. This PR increased the default size and allows for customization to look more visually appealing.

Hi, please squash your commits and use a commit message that resembles your PR title.

Hi, please squash your commits and use a commit message that resembles your PR title.

Hi is it better now?

Great!, but the commits need to be squashed (always).

Thank you.. I am trying to squash them but it says there's a merge amongst the commits.. so now I don't know how to squash them or remove the merge between the commits..

Thank you.. I am trying to squash them but it says there's a merge amongst the commits.. so now I don't know how to squash them or remove the merge between the commits..

I recommend using a GUI-based git client to do it (GitKraken for example) - where you can easily select multiple commits, click the squash button in context menu and force-push it to the remote repo.

If you stuck completely - you can close this PR and recreate it (nothing bad in it, this is common problem across newcomers).

If you stuck completely - you can close this PR and recreate it (nothing bad in it, this is common problem across newcomers).

Alright I think I'll close it an create a new PR then.. since I'm struggling :)

Closing and reopening a new one.. (having problems fixing Squash Issues)...


Add various string conversion utilities

Currently six provides ensure_str, ensure_text, and ensure_binary. Typically these are used when you have a str object and want to convert to text or bytes, or the inverse.
I'd prefer to be explicit about which conversion I'm doing. For example, using six.ensure_binary should probably not be accepting text in py2 and should not be accepting binary in py3 (for most use cases). Effectively these equivalents make the code a little stricter about what types are actually expected.
They should also be more performant as they avoid an isinstance lookup on every conversion.

The main thing that makes me queasy about these is that str should usually be avoided when porting. Decide on either bytes or text. Maybe the cat is out of the bag with ensure_str, but this feels like a lot more str surface area.

IIUC @jhance found a lot of situations where these would be really handy. Maybe he can quote some here? Or you two can discuss in person. :-)


update for v8

Please,  update for v8

Yes. But, the compatibleCoreVersion make it invisible.
Can you update it?

Pushed a new manifest so it is updated for 0.8.9


Some bibliography cross-references don't render in number format

Found while working in https://github.com/metanorma/iso-690/issues/12
In iso-690 document, all bibliography cross-references are expected to render in number format.
However, the auto-fetched ones are rendering different:
DOC output:

Original source:

The behaviour you are encountering is what the Rice model document does (https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/model_document-rice_model.pdf: e..g not [1], but ISO 3696); that's why we've implemented it like that. There is no explicit discussion of citations in ISO/IEC DIR 2, but there is a general statement that standards must be referenced by standard number; if anything, the example of a citation of a  non-standard document is Author-Date (https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor114, Example 2).
In other words, the behaviour of Metanorma, overriding numbered references, appears to be the behaviour expected by ISO, and I would rather not change it to comply with a manually compiled document, nor implement an override, without explicit advice from ISO editors.

I would rather not change it to comply with a manually compiled document

ISO 690 was originally encoded in Metanorma... but updated in Word.
The issue is about reference style -- in ISO we should just follow the new ISO house style which states the following.

CROSS-REFERENCES TO A NUMBERED DOCUMENT
Always use the standard identifier (document number and type) rather than the title when referring to an ISO or IEC document in the text, including when a specific element (clause, table, figure, etc.) is referred to.
Only write “International Standard”, “Technical Specification”, etc. when making a general reference. For example, “X is specified in other International Standards, e.g. ISO 12345”. Do not write “ISO Standard”, “ISO specification” or other alternatives.
Only write out the title of a numbered document in Clause 2 and in the Bibliography.
When referring to the whole document, use an undated document number unless it is necessary that the user refers to a specific edition:
“…in accordance with ISO 12345.”
Use the order of “document number:date, element” when referring to a specific element:
“…in accordance with ISO 12345:2018, 4.3.9.”
“…in accordance with ISO/IEC TR 6789:2020, Table 3.”
“…in accordance with ISO 12345:2018/Amd.1:2019, Figure C.1.”
When referring to a document that is not published by ISO or IEC, use the same style as for an ISO or IEC document if a document number is available:
“…in accordance with IETF RFC 2046.”
“…in accordance with Rec. ITU-T X.96:2000, Annex F.”
CROSS-REFERENCES TO AN UNNUMBERED DOCUMENT
To refer to unnumbered documents in the Bibliography (e.g. a journal or literature reference), use any of the following styles:
“…see Reference [6]”
“…an initial interlaboratory test[6] was carried out…”
“…in the initial interlaboratory test[6]”
“…in the six subsequent interlaboratory tests[7]–[12]”
For non-ISO or IEC documents, it is possible to provide both a document number and a superscript callout:
“…as described in IEEE 802.3[9]”
If it is considered necessary to write the title, give the correct wording consistently throughout the text, not a shortened name or abbreviation:
“…for example, in the United Nations’ Recommendations on the Transport of Dangerous Goods – Model Regulations[1]”
It is permitted to use a mixture of these styles within the text when referring to bibliographical entries.
To refer to unnumbered documents in Clause 2, use the full title of the document without a superscript callout.

AND

###ORDER OF BIBLIOGRAPHIC REFERENCES
The Bibliography is always numbered. There are two ways of structuring bibliographical entries:
By numerical order, followed by literature references:

ISO documents followed by IEC documents and then other international standards;
regional standards;
national standards;
literature references.

In the order in which the references are cited in the text.
For any type of standard that is not published by ISO or IEC, it is possible to provide an online reference to the bibliographical entry in a footnote:

[7] Standard No I.C.C. 167[1], Determination of the protein content in cereal and cereal products for food and animal feeding stuffs according to the Dumas combustion method
[1] Available at http://www.icc.or.at.

The presentation of references follows the guidelines in ISO 690.
For a literature reference, use the format of: Author/organization name. Document title. Location: publisher, date
LEBOFFE, M.J. and PIERCE, B.E. Microbiology: laboratory theory and application. Englewood, Colorado: Morton Publishing Company, 2010
ADVANCED LIFE SUPPORT GROUP. Acute medical emergencies: the practical approach. London: BMJ Books, 2001
For a journal reference, use the format of: Author. Article title. Journal title. Date, edition number, page number. Online reference
CROPLEY, A. J. Creativity and mental health in everyday life. Creativity Research Journal. 1990, 3(3), 167–178. doi:10.1080/10400419009534351
For an online reference, use the format of: Author. Article title. Publication title. Location, date [viewed date]. URL
NUNN, G. Don’t ditch the adverb, the emoji of writing. The Guardian [online]. London, UK, 2 April 2019 [viewed 27 April 2020]. Available from: https://www.theguardian.com/commentisfree/2019/apr/29/dont-ditch-the-adverb-the-emoji-of-writing

@ronaldtse, the house style is confirming the approach I have taken: standards  are always referred to by document identifier, whether in bibliography or normative references, and numbers are only used as citations for "unnumbered' documents (by which they mean documents without a document identifier), "e.g. a journal or literature reference".
It does now explicitly confirm that "unnumbered" normative references are not referred to by document number, which we are now banning.
Numbers are optional for non-ISO/IEC standards documents, in addition to the document identifier ("it is possible to"); we're not doing that, we're just giving the document identifier.
Metanorma is complying to these guidelines, which are just clarifications of ISO/IEC DIR 2 and which were already exemplified in the Rice document. Nothing further to do here.

In any case, here "FIPS 202" should be "NIST FIPS 202", "RFC 3986" should be "IETF RFC 3986"?

The docidentifiers for NIST retrieved from relaton are inconsistent: NIST FIPS 81 has the docidentifier <docidentifier type="NIST">NIST FIPS 81</docidentifier>, while NIST FIPS 186 has the docidentifier <docidentifier type="NIST">FIPS 86</docidentifier>. But the identifier given in the references is correct (I insert the prefix if not already present), and that given to the eref should match that. Fixing.

Prefixes were only being added to ISO/IEC document identifiers; that's a bug. Removing that constraint. Will prevent prefixes being added if they are already present in the docidentifier.


Add fetching of Apple Privacy details

Apple has recently added privacy details to its app store. This comments adds this functionality to the plugin (US app store only).

Can you add some testing for the new method?

I don't have so much experience with tests or using Promises instead of async unfortunately.

I've converted this to Promises now.

And also added a test

Any updates? I've fixed all lint errors and added tests.


Mobile scaling issues

All elements on mobile are too small. Buttons and login fields especially should be larger. The layout may need to just be adjusted for mobile. Bootstrap should be used more often to handle this. Maybe consider a real navbar element. Site should be kept very simple though.

Erroneously added to wrong project.


Linux: compiling static libraries requires "-fPIC"

I was trying to compile some libraries (Remotery, glsl-optimizer) on Linux Mint 64 bit. The linker complained about missing "-fPIC" compile flags.
I've added the flag to linux.cmake, but I'm not sure if using them unconditionally is the correct thing to do.

Thanks! I'll try to find some time to play around with it. It's strange that I didn't encounter that yet, for instance I'm linking a precompiled libcurl into Oryol.
What version of Mint is this, and gcc or clang, and what compiler version?

It's a fresh install of Linux Mint 17.3, with GCC 4.8.4 (default/latest via apt-get).

hmm during fips build I get an error when java is called (it's in the path and the previous steps also worked fine):
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['java', '-cp', '../fips-jni/fips-generators/target/fips-jnigen-jar-with-dependencies.jar', 'com.codedisaster.jnigen.JNICodeGenerator', '../../java', '../../../../build/classes/main', 'generated', '--includes', '**/gdx/graphics/*.java', '**/gdx/profiler/*.java', '**/gdx/utils/*.java']' returned non-zero exit status 255

I will simply try to add -fPIC to the Linux build settings and check with Oryol. The Android build also uses -fPIC so I guess it's the right thing to do. I'll write another comment when the fix is up.

Ok, Linux builds now generally use -fPIC: https://github.com/floooh/fips/commit/8201a23ca4fe423917eb62849a2fd83926f6e6b8, it looks like this is a requirement for building shared libs.
I also noticed that the Linux build config doesn't have any special settings for linking shared libs like the Android toolchain file (CMAKE_SHARED_LINKER_FLAGS). If you stumble over other problems this might be the reason.
Let me know if the fix works :)

Confirmed.
(The compile error you've seen is a side effect of how gdx-jnigen works - it needs the Java bytecode too, so I need to build the Java code at least once first. I always forget to do that myself.)


Copy - pasting button doesn't work well with Google Spreadsheets

When a table is retrieved, if you use the copy csv to clipboard button, and then paste it into a google spreadsheets, it will paste all the rows, but with the columns collapsed into one
On the other hand, if you select (by blocking with the pointer) the table preview, copy it to the clibpboard mannually and then paste it to the Gdocs, it will work flawlessly
This last option is kind of hard in large tables.

Is this fixed by using tabs as the separator in the copied text?


pull request for e2e test at 02/06/2017 21:26:07

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


static map image only showing first step of torque animation

When generating static map images in the editor, the first step is rendered, not the one that's currently selected in the editor. This screen cap is a side-by-side comparison between a view in the editor vs. an image produced from the static maps api. No matter which step the animation is on (while paused or not), the shows a capture of only the first step. The CartoCSS used is below the image. Same effect happens whether on cumulative or linear.

/** torque visualization */

Map {
-torque-frame-count:512;
-torque-animation-duration:30;
-torque-time-attribute:"date_field";
-torque-aggregation-function:"count(cartodb_id)";
-torque-resolution:2;
-torque-data-aggregation:cumulative;
}

#tracks{
  comp-op: lighter;
  marker-fill-opacity: 0.9;
  marker-line-color: #FFF;
  marker-line-width: 0;
  marker-line-opacity: 1;
  marker-type: ellipse;
  marker-width: 3.5;
  marker-fill: #FF9900;
}
#tracks[frame-offset=1] {
 marker-width:5.5;
 marker-fill-opacity:0.45;
}
#tracks[frame-offset=2] {
 marker-width:7.5;
 marker-fill-opacity:0.225;
}

maybe cdb headquarters is too hipster rainbow ;)

Yep, known issue.
This is an enhancement.
@rochoa is this already supported on the render level? Is the UI improvement the only thing left?

The torque png renderer supports any frame, it's a matter of sending the step to render: https://github.com/CartoDB/Windshaft/blob/master/doc/MapConfig-1.3.0.md#22-torque-layers-options

I reassigned it to @javierarce as he was working on the editor integration.
Let me know if you need any further help.

@saleiva: should I add an input field in the UI to let the users choose the frame number?

Could you pick it from the current step in the map?

That might be harder, but I'll try it first (it's the solution I like too)

Hehehe, sorry :kissing:

+1 to the rochoa’s idea :)

On 21 Apr 2015, at 10:33, Raul Ochoa<EMAIL_ADDRESS>wrote:
Hehehe, sorry
—
Reply to this email directly or view it on GitHub https://github.com/CartoDB/cartodb/issues/3268#issuecomment-94816329.

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.


Merging multi-device branch to main.

TLDR: nothing should break, --iree-hal-target-backends= is deprecated, use --iree-hal-target-device= and appropriate target-specific flags instead.
This reworks the target device concept in the IREE pipeline - in some cases introducing the concept (flow and HAL) and in others replacing placeholder mechanisms around stream affinity. This builds upon prior work that added support for enumerating available devices via the HAL and providing multiple devices to the runtime tools by adding the ability to define devices, allowing for execution and storage resources to be assigned a device, and upgrading passes to support multiple devices. "Multi-device" here means several things and all are accomplished with the same mechanism: a single device that may be one of multiple types (multiple CPU/GPU archs, CPU or GPU, etc), multiple homogeneous devices (4 of the same exact GPUs accessed through the same runtime HAL driver), multiple heterogeneous devices (a CPU and a GPU/NPU/etc), and optional devices (a CPU with some portions offloaded to a GPU/NPU if it's compatible and available at runtime). In this way we can provide cross-compilation/targeting, multi-targeting, and multiple devices with one set of flags, compiler analysis, passes dealing with the devices, and runtime infrastructure.
Early warning: it's strongly discouraged to use device information prior to codegen - any pass using such information earlier on is a red flag that will receive pushback. IREE is designed first and foremost as a cross-compiler with multi-targeting at its core and radically changing program behavior near the frontend makes it nearly impossible to have configuration control over the compilation pipeline. Consider specializing on device prior to codegen tantamount to using C preprocessor macros based on operating system or architecture: it means that a problem has not been solved and a workaround has been taken. There are exceptionally few cases that require device information early, and those that do can do so in generic ways that do not disturb the debuggability of the program. For example, far better than preprocessor macros in C++ are function calls and if statements (as we can do in our programs), and even better than that are virtual interfaces (ops that are only lowered to one of multiple implementations later on). That disclaimer out of the way: it's now possible to query device information after the input pipeline (global opt/preprocessing/flow). Upstream will push back against doing so in nearly all cases but it is a useful mechanism for downstream projects.
The key change here is that the --iree-hal-target-backends= compiler flag has been deprecated. It continues to work for now with the same behavior as before but usage will shift to the replacement --iree-hal-target-device= flag. A single instance of this flag defines a single device within the program and repeated uses of it will define new devices. Devices may be named ("my_device") or anonymous (in which case they will be assigned an ordinal like 0 or 1), and each device may be backed by one or more target devices (Vulkan, local host, HIP, etc). Each target device in the compiler (represented by IREE::HAL::TargetDevice) may have any number of backends with various configurations (multiple archs, different deployment formats, etc represented by one or more IREE::HAL::ExecutableTargetAttr values).
Example flags:
# Two devices, one the local host device and the other a Vulkan device:
--iree-hal-target-device=local --iree-hal-target-device=vulkan

# One device selecting between Vulkan if available and otherwise use the local host device:
--iree-hal-target-device=vulkan,local

# Two CUDA devices selected by runtime ordinal; at runtime two --device=
# flags are required to configure both devices:
--iree-hal-target-device=cuda[0] --iree-hal-target-device=cuda[1]

# A fully-defined target specification:
--iree-hal-target-device=#hal.device.target<"cuda", {...}, [#hal.executable.target<...>]>

# Named device for defining a reference by #hal.device.promise<@some_name>:
--iree-hal-target-device=some_name=vulkan

The device metadata as specified in the compiler is used to produce enumeration code that executes at runtime and queries the available devices to find the appropriate matches. This means that if the program is compiled to target two CUDA devices then at runtime there must be two CUDA devices specified - the indirection allows for the compiled artifact to work with any two CUDA devices targeted by UUID, device ordinal, etc and not just the first and second CUDA device in the system. E.g. iree-compile --iree-hal-target-device=cuda[0] --iree-hal-target-device=cuda[1] and iree-run-module --device=cuda://UUID_A --device=cuda://UUID_B. Devices targets in the compiler can now specify the ordinal of the device in order to differentiate between multiple devices at runtime (the cuda[0] and cuda[1] above indicate the first CUDA device and second CUDA device provided to the runtime).
Major new attributes:

#hal.device.promise<@device> is a reference to a device that will be provided at a later stage. Frontends can use this as a placeholder for devices that are specified on the command line without needing to say what those devices are when exporting.
#hal.device.alias<"name"> specifies an IREE::HAL::TargetDevice in the compiler (vulkan, local, hip, etc) and expands to a full #hal.device.target based on target-specific flags.
#hal.device.select<[...]> controls selection by enumerating each device in turn and matching the first found.
#hal.device.fallback<@other_device> provides a fallback reference that the device will match if no other device matches. Note that having two devices with the same target will create two copies at runtime - if wanting to use the existing device then the fallback mechanism must be used.
#hal.device.affinity<@device> (and optional queue mask) is used on ops to indicate on which device they should execute.

All of the above flags are just syntactic sugar that add the above attributes to the program IR and it's possible for frontends to insert these attributes or ops directly depending on use-case. In most cases leaving placeholders in the IR such that the exact target can be specified during compilation is ideal: this allows one output from the frontend to be used with any number of targets and configurations. Online compilers, though, may want to bake in their exact configuration and can do so without the need for flags that may lose information. The general flow of the buildHALDeviceAssignmentPassPipeline/iree-opt --iree-hal-device-assignment-pipeline is:

--iree-hal-target-device= flags are parsed and a hal.device.targets attribute is added to the module.

--iree-hal-device-target=cpu_device=local becomes hal.device.targets = [#hal.device.alias<"local"> : !hal.device]
--iree-hal-device-target=cpu_device=local --iree-hal-device-target=gpu_device=cuda,hip becomes

hal.device.targets = {
  cpu_device = #hal.device.alias<"local"> : !hal.device,
  gpu_device = #hal.device.select<[#hal.device.alias<"cuda"> : !hal.device, #hal.device.alias<"hip"> : !hal.device]> :
!hal.device
}

The hal.device.targets attribute (if any) is expanded into util.global ops for each device. These globals are initialized with one of the supported attributes which are much later turned into enumeration/selection logic. The above multi-device example becomes:

builtin.module attributes {stream.affinity.default = #hal.device.affinity<@cpu_device>} {
  util.global private @cpu_device = #hal.device.alias<"local"> : !hal.device
  util.global private @gpu_device = #hal.device.select<[#hal.device.alias<"cuda"> : !hal.device, #hal.device.alias<"hip"> : !hal.device]> :
!hal.device
}

Any #hal.device.promise attributes will be changed to reference the globals with the same name. This allows for retargeting of inputs by letting a frontend specify named devices prior to them having been passed on the command line (or inserted by some other pipeline).
Any #hal.device.alias attributes are converted to full #hal.device.target attributes using the appropriate IREE::HAL::DeviceTarget implementation.

Upon completion of the pipeline there are globals initialized with either a specific device target or a selection mechanism to pick between targets. From that point onward devices are a structural part of the program and can be referenced by symbol name via attributes like #hal.device.affinity.
Programs are expected to specify the device affinity for all operations either explicitly or implicitly. By default (as today) the first device defined will be used but going forward we will want frontends to start specifying devices. To that end the flow.tensor.transfer operation was added to allow a tensor to have a device affinity assigned to it. A new analysis is added that allows all tensors (or stream resources) and ops interacting with them to be queried for which device they should be placed on. For example, a frontend can specify multiple devices be used in a computation by transferring the tensors used:
util.func private @my_func(%arg0: tensor<4xi32>) -> tensor<4xi32> {
  %arg0_device_a = flow.tensor.transfer %arg0 : tensor<4xi32> to #hal.device.promise<@device_a>
  %compute_device_a = arith.addi %arg0_device_a, %arg0_device_a : tensor<4xi32>
  %transient_device_b = flow.tensor.transfer %compute_device_a : tensor<4xi32> to #hal.device.promise<@device_b>
  %compute_device_b = arith.muli %transient_device_b, %transient_device_b : tensor<4xi32>
  util.return %compute_device_b : tensor<4xi32>
}

To avoid copies there are also ways for frontends to indicate where argument and result tensors are placed. The best way (in that it's most general/powerful) is for the frontends to emit hal.tensor.import, hal.tensor.export, and hal.tensor.alias ops directly as they all now take affinities. When using the default ABI translation pass it's possible to add arg/result attrs to public functions, e.g. util.func public @my_func(%arg0: tensor<2xi32> {iree.abi.affinity = #hal.device.promise<@device_a>}) -> (tensor<2xi32> {iree.abi.affinity = #hal.device.promise<@device_b>}). Shorthand is provided to allow specifying an iree.abi.affinity on functions themselves for when all arguments and results are placed on the same device.
After the point devices are specified, materialized in the program as globals, and referenced either via the magic default attribute, scoped attributes, or explicit transfer operations most of the mechanics are implementation details of the stream and HAL dialect lowerings. Partitioning, allocation, and scheduling in the stream dialect were always affinity-aware and required only minor tweaks as part of this work while the HAL TODOs for multi-device were implemented by memoizing resources per-device and adding the machinery to enumerate and select devices.
This was reviewed in the following chunks and tested in a roll-up PR #17482:

https://github.com/iree-org/iree/pull/17915
https://github.com/iree-org/iree/pull/17917
https://github.com/iree-org/iree/pull/17916
https://github.com/iree-org/iree/pull/17918
https://github.com/iree-org/iree/pull/17919
https://github.com/iree-org/iree/pull/17920

Planning on a merge commit so the individual commits are preserved. Ideally there should not be any material changes to user workflows (as the existing --iree-hal-target-backends= flag still works) but there may be usage-specific bugs in cases we don't have covered in testing - especially in weirder cases of integrations with custom modules and such (though I tried to ensure no changes there).

@benvanik Would you mind providing an e2d test including iree-run-module for this ? Thanks.

Added as tools/test/iree-run-module-multi.mlir.

Added as tools/test/iree-run-module-multi.mlir.

Nice, thank you.

mi300 runners are down, and the onnx failures are fixed in a #18039. Since mi250 tests are ok I'm going to merge past the hung mi300 tests.


Package fails to load

I see this error when using TetGen:
ERROR: LoadError: UndefVarError: hascolumn not defined
Stacktrace:
 [1] include(::Function, ::Module, ::String) at ./Base.jl:380
 [2] include(::Module, ::String) at ./Base.jl:368
 [3] top-level scope at none:2
 [4] eval at ./boot.jl:331 [inlined]
 [5] eval(::Expr) at ./client.jl:467
 [6] top-level scope at ./none:3
in expression starting at /Users/eschnett/.julia/packages/TetGen/0qqtz/src/TetGen.jl:5
ERROR: LoadError: Failed to precompile TetGen [c5d3f3f7-f850-59f6-8a2e-ffc6dc1317ea] to /Users/eschnett/.julia/compiled/v1.5/TetGen/M9G11_8kmuz.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1290
 [3] _require(::Base.PkgId) at ./loading.jl:1030
 [4] require(::Base.PkgId) at ./loading.jl:928
 [5] require(::Module, ::Symbol) at ./loading.jl:923
 [6] include(::String) at ./client.jl:457
 [7] top-level scope at none:6
in expression starting at /Users/eschnett/.julia/packages/TetGen/0qqtz/test/runtests.jl:1
ERROR: Package TetGen errored during testing

I think that hascolumn is supposed to come from GeometryBasics. Maybe that package changed?

Oh, let me merge: https://github.com/JuliaGeometry/TetGen.jl/pull/14


Additional template option

It'd be nice to be able to configure additional templates to render the plugin contents, similar to djangocms-link and -picture. This would make it easier to add wrapper markup. I filed a similar issue on djangocms-style.

I'm again wishing that I could add wrapper markup around a Text plugin, without having to putting it inside a Style plugin. Any idea what the level of effort would be to add this?

Hello @bhrutledge,
I'm closing this as a won't fix.
The text plugin UI would be affected to add such option and so far we've not seen much demand/need for it.
You can override the text plugin template and add the wrapper there or you can also use the AbstractText class to create your own version of the text plugin.


Cognito IdP: Raise UsernameExistsException from sign_up when user exists

Similar to admin_create_user (#2357), the sign_up method in the Cognito identity provider client should raise a UsernameExistsException if a user already exists within the user pool

Codecov Report

Merging #3765 (c86bbfc) into master (f96ac40) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #3765      +/-   ##
==========================================
- Coverage   94.80%   94.77%   -0.03%
==========================================
  Files         437      437
  Lines       48116    48118       +2
==========================================
- Hits        45614    45605       -9
- Misses       2502     2513      +11

Flag
Coverage Δ

servertests
56.00% <0.00%> (-0.01%)
:arrow_down:

unittests
94.64% <100.00%> (-0.03%)
:arrow_down:

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

Impacted Files
Coverage Δ

moto/cognitoidp/models.py
88.28% <100.00%> (+0.03%)
:arrow_up:

moto/batch/models.py
82.84% <0.00%> (-1.46%)
:arrow_down:

moto/iam/models.py
95.13% <0.00%> (-0.15%)
:arrow_down:

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 f96ac40...c86bbfc. Read the comment docs.

This is now part of moto >= 2.0.3.dev4


How to build sdk for x86 on Windows 64 Bit Platform?

The guidelines for Windows looks like.

For Visual Studio:
cmake  -G "Visual Studio 12 Win64"
msbuild INSTALL.vcxproj /p:Configuration=Release

I believe these command produce SDK for Windows 64 bit.
What command-line options I should use to build SDK for x86(Win32)? I have Windows 10 Pro 64 Bit. Visual Studio 2015.
Appreciate you help on this.

I tried below command to
cmake -G "NMake Makefiles" -DTARGET_ARCH=WINDOWS -DANDROID_TOOLCHAIN_NAME=standalone -DANDROID_ABI=x86 -DCMAKE_BUILD_TYPE=Release -DNDK_DIR=C:/Android/android-ndk-r13b D:/AWS/aws-sdk-cpp
nmake intall
which seems to work.

For a visual studio build:
cmake -G "Visual Studio 12 2013"
For an nmake build:
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
All of the android options are not necessary and when building for the local platform (not cross-compiling), you don't need the TARGET_ARCH option either.

Thanks.


Install miniapp content

The installation of the binaries I could take or leave especially because they will not work without also installing the mesh file dependencies. But installation of the headers and library I think are potentially important for downstream applications

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#4583
@lindsayad
@tzanio
@v-dobrev + @mlstowell + @helloworld922 + @jandrej
11/12/24
⌛due 11/26/24
⌛due 12/3/24

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

@lindsayad, to start the review process for the PR, please add the ready-for-review label if/when ready. Thanks!

HI @v-dobrev. I don't believe I have permissions to apply labels

@lindsayad, I invited you to the MFEM Contributors team -- that should let you assign labels, I think.

Thanks for doing this Alex, I had it on my stack for precisely the same reasons. 😛
When I looked at what would be entailed to implement this, I spotted this line, so maybe move things around or delete it:
https://github.com/mfem/mfem/blob/a24370a2ed97856a736eb4cee4a603ee903ac2ae/CMakeLists.txt#L828

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Ok I think this is ready for further review. I've left in the GNUInstallDirs commit plus its reversion for historical purposes, but am happy to cut those out

Here is a patch with some additional tweaks:

Add a new option to use GNUInstallDirs: MFEM_USE_GNUINSTALLDIRS (OFF by default).
Remove miniapp installation from GNU make -- if someone really prefers to keep it, we can work on an improved installation procedure.
Install miniapps/common headers in <prefix>/include/mfem/miniapps/common and not in <prefix>/include/mfem/miniapps/common/common (common was repeated twice).
Install libmfem-common.* with a version suffix and link -- similar to how we install libmfem.*.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 67f37a9b5e..fe83c83afc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -615,21 +615,38 @@ set(MASTER_HEADERS
   ${PROJECT_SOURCE_DIR}/mfem.hpp
   ${PROJECT_SOURCE_DIR}/mfem-performance.hpp)

-set(_lib_path "${CMAKE_INSTALL_PREFIX}/lib")
-set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON CACHE BOOL "")
-set(CMAKE_INSTALL_RPATH "${_lib_path}" CACHE PATH "")
-set(CMAKE_INSTALL_NAME_DIR "${_lib_path}" CACHE PATH "")
-
-set(INSTALL_INCLUDE_DIR include
-  CACHE PATH "Relative path for installing header files.")
-set(INSTALL_BIN_DIR bin
-  CACHE PATH "Relative path for installing the binaries.")
-set(INSTALL_LIB_DIR lib
-  CACHE PATH "Relative path for installing the library.")
+# Installation options
+set(MFEM_USE_GNUINSTALLDIRS OFF
+  CACHE BOOL "Enable to use the GNUInstallDirs CMake module.")
+if (NOT ${MFEM_USE_GNUINSTALLDIRS})
+  set(INSTALL_INCLUDE_DIR include
+    CACHE PATH "Relative path for installing header files.")
+  set(INSTALL_BIN_DIR bin
+    CACHE PATH "Relative path for installing the binaries.")
+  set(INSTALL_LIB_DIR lib
+    CACHE PATH "Relative path for installing the library.")
+  set(INSTALL_SHARE_DIR share
+    CACHE PATH "Relative path for installing shared data.")
+else()
+  include(GNUInstallDirs)
+  set(INSTALL_INCLUDE_DIR ${CMAKE_INSTALL_INCLUDEDIR}
+    CACHE PATH "Relative path for installing header files.")
+  set(INSTALL_BIN_DIR ${CMAKE_INSTALL_BINDIR}
+    CACHE PATH "Relative path for installing the binaries.")
+  set(INSTALL_LIB_DIR ${CMAKE_INSTALL_LIBDIR}
+    CACHE PATH "Relative path for installing the library.")
+  set(INSTALL_SHARE_DIR ${CMAKE_INSTALL_DATAROOTDIR}
+    CACHE PATH "Relative path for installing shared data.")
+endif()
 # other options: "share/mfem/cmake", "lib/mfem/cmake"
 set(INSTALL_CMAKE_DIR lib/cmake/mfem
   CACHE PATH "Relative path for installing cmake config files.")

+set(_lib_path "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}")
+set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON CACHE BOOL "")
+set(CMAKE_INSTALL_RPATH "${_lib_path}" CACHE PATH "")
+set(CMAKE_INSTALL_NAME_DIR "${_lib_path}" CACHE PATH "")
+
 set(MFEM_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR} CACHE PATH
     "The MFEM source directory" FORCE)
 set(MFEM_INSTALL_DIR ${CMAKE_INSTALL_PREFIX} CACHE PATH
diff --git a/config/cmake/modules/MfemCmakeUtilities.cmake b/config/cmake/modules/MfemCmakeUtilities.cmake
index cb2d35641f..f7ecc9e6c9 100644
--- a/config/cmake/modules/MfemCmakeUtilities.cmake
+++ b/config/cmake/modules/MfemCmakeUtilities.cmake
@@ -993,9 +993,9 @@ function(mfem_export_mk_files)
     "${PROJECT_BINARY_DIR}/config/test.mk" COPYONLY)

   # Update variables for the install-tree version of 'config.mk'
-  set(MFEM_INC_DIR "${CMAKE_INSTALL_PREFIX}/include")
-  set(MFEM_LIB_DIR "${CMAKE_INSTALL_PREFIX}/lib")
-  set(MFEM_TEST_MK "${CMAKE_INSTALL_PREFIX}/share/mfem/test.mk")
+  set(MFEM_INC_DIR "${CMAKE_INSTALL_PREFIX}/${INSTALL_INCLUDE_DIR}")
+  set(MFEM_LIB_DIR "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}")
+  set(MFEM_TEST_MK "${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/test.mk")
   set(MFEM_CONFIG_EXTRA "")

   # Create the install-tree version of 'config.mk'
@@ -1005,8 +1005,9 @@ function(mfem_export_mk_files)

   # Install rules for 'config.mk' and 'test.mk'
   install(FILES ${PROJECT_SOURCE_DIR}/config/test.mk
-    DESTINATION ${CMAKE_INSTALL_PREFIX}/share/mfem/)
+    DESTINATION ${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/)
   install(FILES ${PROJECT_BINARY_DIR}/config/config-install.mk
-    DESTINATION ${CMAKE_INSTALL_PREFIX}/share/mfem/ RENAME config.mk)
+    DESTINATION ${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/
+    RENAME config.mk)

 endfunction()
diff --git a/makefile b/makefile
index d6cbcad77c..43587c09f1 100644
--- a/makefile
+++ b/makefile
@@ -629,15 +629,6 @@ install: $(if $(static),$(BLD)libmfem.a) $(if $(shared),$(BLD)libmfem.$(SO_EXT))
 	   ( $(MKINSTALLDIR) $(PREFIX_INC)/mfem/$$dir ) && \
 	   $(INSTALLDEF) $(SRC)$$dir/*.hpp $(PREFIX_INC)/mfem/$$dir; \
 	done
-# install miniapp common libraries and headers if built
-	if ls $(BLD)miniapps/common/libmfem-common.* &> /dev/null; then \
-	   $(if $(static),$(INSTALLDEF) $(BLD)miniapps/common/libmfem-common.a $(PREFIX_LIB) &&) \
-	   $(if $(shared),$(INSTALLDEF) $(BLD)miniapps/common/libmfem-common.$(SO_VER) $(PREFIX_LIB) \
-	      && chmod $(INSTALL_BIN_PERM) $(PREFIX_LIB)/libmfem-common.$(SO_VER) \
-	      && ln -sf libmfem-common.$(SO_VER) $(PREFIX_LIB)/libmfem-common.$(SO_EXT) &&) \
-	   $(MKINSTALLDIR) $(PREFIX_INC)/mfem/miniapps/common && \
-	   $(INSTALLDEF) $(SRC)miniapps/common/*.hpp $(PREFIX_INC)/mfem/miniapps/common; \
-	fi
 # install *.okl files
 	for dir in $(OKL_DIRS); do \
 	   ( $(MKINSTALLDIR) $(PREFIX_INC)/mfem/$$dir ) && \
diff --git a/miniapps/common/CMakeLists.txt b/miniapps/common/CMakeLists.txt
index 5d8f086427..2875711104 100644
--- a/miniapps/common/CMakeLists.txt
+++ b/miniapps/common/CMakeLists.txt
@@ -43,5 +43,12 @@ set(MINIAPPS_COMMON_HEADERS ${MINIAPPS_COMMON_HEADERS} ${HDRS} PARENT_SCOPE)

 mfem_add_library(mfem-common ${SRCS} ${HDRS})
 target_link_libraries(mfem-common mfem)
-install(TARGETS mfem-common ARCHIVE DESTINATION ${INSTALL_LIB_DIR} LIBRARY DESTINATION ${INSTALL_LIB_DIR})
-install(DIRECTORY ${CMAKE_SOURCE_DIR}/miniapps/common/ DESTINATION ${INSTALL_INCLUDE_DIR}/mfem/miniapps/common FILES_MATCHING PATTERN "*.hpp")
+set_target_properties(mfem-common PROPERTIES VERSION "${mfem_VERSION}")
+set_target_properties(mfem-common PROPERTIES SOVERSION "${mfem_VERSION}")
+install(TARGETS mfem-common
+  ARCHIVE DESTINATION ${INSTALL_LIB_DIR}
+  LIBRARY DESTINATION ${INSTALL_LIB_DIR}
+  RUNTIME DESTINATION ${INSTALL_BIN_DIR})
+install(DIRECTORY ${CMAKE_SOURCE_DIR}/miniapps/common
+  DESTINATION ${INSTALL_INCLUDE_DIR}/mfem/miniapps
+  FILES_MATCHING PATTERN "*.hpp")

Install miniapps/common headers in <prefix>/include/mfem/miniapps/common and not in <prefix>/include/mfem/miniapps/common/common (common was repeated twice).

Are you sure about this? I do not see this on my machine
(base) lindad@INL429698:~/projects/mfem/installed/include/mfem/miniapps/common(alex-dev)$ ls
dist_solver.hpp fem_extras.hpp  mesh_extras.hpp mfem-common.hpp pfem_extras.hpp

Install miniapps/common headers in <prefix>/include/mfem/miniapps/common and not in <prefix>/include/mfem/miniapps/common/common (common was repeated twice).

Are you sure about this? I do not see this on my machine
(base) lindad@INL429698:~/projects/mfem/installed/include/mfem/miniapps/common(alex-dev)$ ls
dist_solver.hpp fem_extras.hpp  mesh_extras.hpp mfem-common.hpp pfem_extras.hpp

I saw this behavior (common repeated twice) after I removed the last / in ${CMAKE_SOURCE_DIR}/miniapps/common/ -- maybe that is the difference?

I saw this behavior (common repeated twice) after I removed the last / in ${CMAKE_SOURCE_DIR}/miniapps/common/ -- maybe that is the difference?

Yea I verified that making this change does lead to the repeated common

I've finally had some time to study the situation thoroughly, let me try to explain it as best as I can.
First, @v-dobrev, I now understand we never really intended for INSTALL_{INCLUDE,BIN,LIB}_DIR to be set by the user in the command line, did we? We've always had hard code paths (for instance the rpath which would never respect what the user would pass in INSTALL_LIB_DIR anyway). So I think it's my bad I mislead Alex and I think yourself in this regard. The variables shouldn't be marked CACHE.
Second, the script above assumes these variables hold relative paths, which isn't true if the user tries to set them. Indeed from the manual for set():
"Furthermore, if the  is PATH or FILEPATH and the  provided on the command line is a relative path, then the set command will treat the path as relative to the current working directory and convert it to an absolute path."
So, I think this is enough evidence that we can rest assured there's nobody out there setting any of INSTALL_{INCLUDE,BIN,LIB}_DIR. Thus, if we wanted to allow the user set their preference from now on, it is indeed safe to rename these variable freely. GNUInstallDirs takes care to preserve relative paths passed on the command line, so it's not affected by the issue above.

Hi @nmnobre,
Thanks for taking a closer look at the changes I proposed. Some comments:

... we never really intended for INSTALL_{INCLUDE,BIN,LIB}_DIR to be set by the user in the command line, did we?

We did intent for these to be user-configurable, however, as you noticed they were not used in some places, so that was a bug.
As you point out, setting e.g. -DINSTALL_LIB_DIR=lib99 will not behave as one might expect (I did not realize this limitation), however, one can use either -DINSTALL_LIB_DIR:PATH=lib99 or -DINSTALL_LIB_DIR:STRING=lib99 to get the desired result. We can add logic to handle the case of -DINSTALL_LIB_DIR=lib99 as well.
The INSTALL_*_DIR variables are actually used, for example in the Fedora MFEM package, see https://src.fedoraproject.org/rpms/mfem/blob/main/f/mfem.spec. There, these variables are set to absolute paths which we should continue to support and not assume that the paths are always relative. This will require some additional tweaks which I'm looking into making -- I'll post a suggested patch for this in a little bit.
Regarding the SOVERSION: I think I have both VERSION and SOVERSION just as reminder that there are separate options that can be set independently.

We did intent for these to be user-configurable, however, as you noticed they were not used in some places, so that was a bug.

Okay, I'm glad that's the case. :)

As you point out, setting e.g. -DINSTALL_LIB_DIR=lib99 will not behave as one might expect (I did not realize this limitation), however, one can use either -DINSTALL_LIB_DIR:PATH=lib99 or -DINSTALL_LIB_DIR:STRING=lib99 to get the desired result. We can add logic to handle the case of -DINSTALL_LIB_DIR=lib99 as well.

Yes, if the user specifies the type, everything works as expected (although, in practice, I rarely see it?). So to workaround this, I suggest we have a look at the source for GNUInstallDirs, see around this line https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/GNUInstallDirs.cmake#L172. But then, it does feel a bit like we are re~inventing~writing the wheel if you know what I mean? :) But, in light of the below, I do see why we might want to do this.

The INSTALL_*_DIR variables are actually used, for example in the Fedora MFEM package

Regarding the SOVERSION: I think I have both VERSION and SOVERSION just as reminder that there are separate options that can be set independently.

Fair enough.

Here's the patch I came up with to address the issues noted by @nmnobre. I also added some documentation in the INSTALL file about the fine-tuning of the installation directories with CMake.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index fe83c83afc..da42b1528c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -618,31 +618,30 @@ set(MASTER_HEADERS
 # Installation options
 set(MFEM_USE_GNUINSTALLDIRS OFF
   CACHE BOOL "Enable to use the GNUInstallDirs CMake module.")
-if (NOT ${MFEM_USE_GNUINSTALLDIRS})
-  set(INSTALL_INCLUDE_DIR include
-    CACHE PATH "Relative path for installing header files.")
-  set(INSTALL_BIN_DIR bin
-    CACHE PATH "Relative path for installing the binaries.")
-  set(INSTALL_LIB_DIR lib
-    CACHE PATH "Relative path for installing the library.")
-  set(INSTALL_SHARE_DIR share
-    CACHE PATH "Relative path for installing shared data.")
-else()
+set(install_include_dir_default include)
+set(install_bin_dir_default bin)
+set(install_lib_dir_default lib)
+set(install_share_dir_default share)
+if (MFEM_USE_GNUINSTALLDIRS)
   include(GNUInstallDirs)
-  set(INSTALL_INCLUDE_DIR ${CMAKE_INSTALL_INCLUDEDIR}
-    CACHE PATH "Relative path for installing header files.")
-  set(INSTALL_BIN_DIR ${CMAKE_INSTALL_BINDIR}
-    CACHE PATH "Relative path for installing the binaries.")
-  set(INSTALL_LIB_DIR ${CMAKE_INSTALL_LIBDIR}
-    CACHE PATH "Relative path for installing the library.")
-  set(INSTALL_SHARE_DIR ${CMAKE_INSTALL_DATAROOTDIR}
-    CACHE PATH "Relative path for installing shared data.")
-endif()
+  set(install_include_dir_default "${CMAKE_INSTALL_INCLUDEDIR}")
+  set(install_bin_dir_default "${CMAKE_INSTALL_BINDIR}")
+  set(install_lib_dir_default "${CMAKE_INSTALL_LIBDIR}")
+  set(install_share_dir_default "${CMAKE_INSTALL_DATAROOTDIR}")
+endif()
+mfem_cache_path(INSTALL_INCLUDE_DIR "${install_include_dir_default}"
+  "Relative or absolute path for installing header files.")
+mfem_cache_path(INSTALL_BIN_DIR "${install_bin_dir_default}"
+  "Relative or absolute path for installing the binaries.")
+mfem_cache_path(INSTALL_LIB_DIR ${install_lib_dir_default}
+  "Relative or absolute path for installing the library.")
+mfem_cache_path(INSTALL_SHARE_DIR "${install_share_dir_default}"
+  "Relative or absolute path for installing shared data.")
 # other options: "share/mfem/cmake", "lib/mfem/cmake"
-set(INSTALL_CMAKE_DIR lib/cmake/mfem
-  CACHE PATH "Relative path for installing cmake config files.")
+mfem_cache_path(INSTALL_CMAKE_DIR ${INSTALL_LIB_DIR}/cmake/mfem
+  "Relative or absolute path for installing cmake config files.")

-set(_lib_path "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}")
+mfem_path_to_fullpath("${INSTALL_LIB_DIR}" "${CMAKE_INSTALL_PREFIX}" _lib_path)
 set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON CACHE BOOL "")
 set(CMAKE_INSTALL_RPATH "${_lib_path}" CACHE PATH "")
 set(CMAKE_INSTALL_NAME_DIR "${_lib_path}" CACHE PATH "")
diff --git a/INSTALL b/INSTALL
index 962e386894..d95b10c005 100644
--- a/INSTALL
+++ b/INSTALL
@@ -971,7 +971,11 @@ or
 Note that running all the tests may take a while.

 Installation prefix can be configured by setting the standard CMake variable
-CMAKE_INSTALL_PREFIX. To install the library, use
+CMAKE_INSTALL_PREFIX; for fine-tuning the installation directories the following
+variables can be used: INSTALL_INCLUDE_DIR, INSTALL_LIB_DIR, INSTALL_BIN_DIR,
+INSTALL_SHARE_DIR, and INSTALL_CMAKE_DIR; alternatively, fine-tuning can be done
+by setting MFEM_USE_GNUINSTALLDIRS=ON to use the CMake module GNUInstallDirs.
+To install the library, use

    make install
 or
diff --git a/config/cmake/modules/MfemCmakeUtilities.cmake b/config/cmake/modules/MfemCmakeUtilities.cmake
index f7ecc9e6c9..7869dbef32 100644
--- a/config/cmake/modules/MfemCmakeUtilities.cmake
+++ b/config/cmake/modules/MfemCmakeUtilities.cmake
@@ -827,6 +827,20 @@ function(mfem_get_target_options Target CompileOptsVar LinkOptsVar)
 endfunction(mfem_get_target_options)

+#
+# If ${Path} is not an absolute path, assign ${Prefix}/${Path} to the variable
+# ${OutVar}. If ${Path} is an absolute path, assign ${Path} to the variable
+# ${OutVar}.
+#
+function(mfem_path_to_fullpath Path Prefix OutVar)
+  if(IS_ABSOLUTE "${Path}")
+    set(${OutVar} "${Path}" PARENT_SCOPE)
+  else()
+    set(${OutVar} "${Prefix}/${Path}" PARENT_SCOPE)
+  endif()
+endfunction()
+
+
 #
 #   Function that creates 'config.mk' from 'config.mk.in' for the both the
 #   build- and the install-locations and define install rules for 'config.mk'
@@ -993,9 +1007,12 @@ function(mfem_export_mk_files)
     "${PROJECT_BINARY_DIR}/config/test.mk" COPYONLY)

   # Update variables for the install-tree version of 'config.mk'
-  set(MFEM_INC_DIR "${CMAKE_INSTALL_PREFIX}/${INSTALL_INCLUDE_DIR}")
-  set(MFEM_LIB_DIR "${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}")
-  set(MFEM_TEST_MK "${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/test.mk")
+  mfem_path_to_fullpath(
+    "${INSTALL_INCLUDE_DIR}" "${CMAKE_INSTALL_PREFIX}" MFEM_INC_DIR)
+  mfem_path_to_fullpath(
+    "${INSTALL_LIB_DIR}" "${CMAKE_INSTALL_PREFIX}" MFEM_LIB_DIR)
+  mfem_path_to_fullpath(
+    "${INSTALL_SHARE_DIR}/mfem/test.mk" "${CMAKE_INSTALL_PREFIX}" MFEM_TEST_MK)
   set(MFEM_CONFIG_EXTRA "")

   # Create the install-tree version of 'config.mk'
@@ -1005,9 +1022,30 @@ function(mfem_export_mk_files)

   # Install rules for 'config.mk' and 'test.mk'
   install(FILES ${PROJECT_SOURCE_DIR}/config/test.mk
-    DESTINATION ${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/)
+    DESTINATION ${INSTALL_SHARE_DIR}/mfem/)
   install(FILES ${PROJECT_BINARY_DIR}/config/config-install.mk
-    DESTINATION ${CMAKE_INSTALL_PREFIX}/${INSTALL_SHARE_DIR}/mfem/
+    DESTINATION ${INSTALL_SHARE_DIR}/mfem/
     RENAME config.mk)

 endfunction()
+
+
+#
+# Function similar to the macro _GNUInstallDirs_cache_path from the module
+# GNUInstallDirs. Used to process variables like INSTALL_LIB_DIR if they are
+# set on the cmake command line without specifying type: -DINSTALL_LIB_DIR=lib.
+# Without this special treatment, relative paths are expanded to full paths
+# and we want to avoid that.
+#
+function(mfem_cache_path PathVar DefaultPath HelpStr)
+  if(NOT DEFINED ${PathVar})
+    set(${PathVar} "${DefaultPath}" CACHE PATH "${HelpStr}")
+  endif()
+  get_property(cache_type CACHE ${PathVar} PROPERTY TYPE)
+  if(cache_type STREQUAL "UNINITIALIZED")
+    file(TO_CMAKE_PATH "${${PathVar}}" cmakepath)
+    set_property(CACHE ${PathVar} PROPERTY TYPE PATH)
+    set_property(CACHE ${PathVar} PROPERTY VALUE "${cmakepath}")
+    set_property(CACHE ${PathVar} PROPERTY HELPSTRING "${HelpStr}")
+  endif()
+endfunction()

@nmnobre, @mlstowell, @helloworld922 and @jandrej -- Can you take another look when you get a chance?

@nmnobre, your suggested patch for the main CMakeLists.txt removes the flag MFEM_USE_GNUINSTALLDIRS -- I want to have that flag do what it does in my version -- use the CMAKE_INSTALL_LIBDIR default value for INSTALL_LIB_DIR when MFEM_USE_GNUINSTALLDIRS=ON. This also affects your suggested change in INSTALL that removes MFEM_USE_GNUINSTALLDIRS -- I suppose it was not clear what this flag was meant to do, so we can add an explanation.
Also, I don't think we want to change $(PREFIX)  to <PREFIX> in the INSTALL file -- I don't think this change makes things clearer.

use the CMAKE_INSTALL_LIBDIR default value for INSTALL_LIB_DIR when MFEM_USE_GNUINSTALLDIRS=ON

What do we gain from that though? :)
I think you see GNUInstallDirs as a way of defining some defaults, whereas I see it as a way of getting 'standard' variable aliases?

Also, I don't think we want to change $(PREFIX) to <PREFIX> in the INSTALL file -- I don't think this change makes things clearer.

There's nowhere else we use the $(...) notation in that file, it's always <...>, it was just for consistency. Indeed, for GNU Make we used $(PREFIX) but for CMake we had <PREFIX> (which I changed to <CMAKE_INSTALL_PREFIX>).

The goal is to allow the user to reuse the logic in GNUInstallDirs for CMAKE_INSTALL_LIBDIR instead having to re-implement that themselves. This logic is not exactly trivial.

I can see that; it's just like this I don't have much motivation to use the functionality (I wonder if others will), because to do the same thing I now need an extra flag. I would switch to CMAKE_INSTALL_LIBDIR if it was just as easy, but not otherwise. In my mind, this would become the standard way of doing things, and the previous variables would become as if 'deprecated'. So, if we're adding this just because I suggested it and you don't know any other users who would immediately benefit, we can drop it, no problem. :)

My reasoning is as follows: <name> refers to any string whose contents is described by "name" and "name" is typically not the name of a variable, e.g. we use <mfem-source-dir>; on the other hand $(PREFIX) refers specifically to the contents of the variable PREFIX defined in the GNU make build system (typically on the command line or in config/user.mk). In the context of CMake, <PREFIX> was mean to be "the path that specifies the install prefix" which is given by ${CMAKE_INSTALL_PREFIX}. Does this clarify the distinction I'm making? We don't need to enforce this but this is my reasoning for using <name> vs using $(varname) in GNU make context vs using ${varname} in CMake context.

Okay, I understand that now, I think I might've been misled by the capitalisation and that for GNU Make we say PREFIX=<dir>; I now understand that <dir> for GNU Make and <PREFIX> for CMake  are equivalent in your logic. :)

So, if we're adding this just because I suggested it and you don't know any other users who would immediately benefit, we can drop it, no problem. :)

The use GNUInstallDirs has come up on other occasions before you brought it up, so I think having the option to use GNUInstallDirs will be useful to others. The price for users to pay is that they'll need to enable MFEM_USE_GNUINSTALLDIRS which is much simpler than reproducing the logic to set CMAKE_INSTALL_LIBDIR (or INSTALL_LIB_DIR) the same way as the default in GNUInstallDirs.
All I'm suggesting is to make the following line in your suggestion:
mfem_cache_path(CMAKE_INSTALL_LIBDIR "lib" "Object code libraries (lib)")

optional putting it in an if statement:
if(NOT MFEM_USE_GNUINSTALLDIRS)
  mfem_cache_path(CMAKE_INSTALL_LIBDIR "lib" "Object code libraries (lib)")
endif()

Also, since GNUInstallDirs is always included in your suggestion, we can get rid of all the install_*_default variables to simplify the code a bit.

if(NOT MFEM_USE_GNUINSTALLDIRS)
  mfem_cache_path(CMAKE_INSTALL_LIBDIR "lib" "Object code libraries (lib)")
endif()

Also, since GNUInstallDirs is always included in your suggestion, we can get rid of all the install_*_default variables to simplify the code a bit.

I love this, if you're happy, I'm (very) happy!
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 32cdcd01d..cd828def7 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -615,27 +615,20 @@ set(MASTER_HEADERS
   ${PROJECT_SOURCE_DIR}/mfem.hpp
   ${PROJECT_SOURCE_DIR}/mfem-performance.hpp)

-# Installation options
+# Installation options (we use GNUInstallDirs but prefer lib by default)
 set(MFEM_USE_GNUINSTALLDIRS OFF
-  CACHE BOOL "Enable to use the GNUInstallDirs CMake module.")
-set(install_include_dir_default include)
-set(install_bin_dir_default bin)
-set(install_lib_dir_default lib)
-set(install_share_dir_default share)
-if (MFEM_USE_GNUINSTALLDIRS)
-  include(GNUInstallDirs)
-  set(install_include_dir_default "${CMAKE_INSTALL_INCLUDEDIR}")
-  set(install_bin_dir_default "${CMAKE_INSTALL_BINDIR}")
-  set(install_lib_dir_default "${CMAKE_INSTALL_LIBDIR}")
-  set(install_share_dir_default "${CMAKE_INSTALL_DATAROOTDIR}")
-endif()
-mfem_cache_path(INSTALL_INCLUDE_DIR "${install_include_dir_default}"
+  CACHE BOOL "Enable to use the GNUInstallDirs CMake module defaults.")
+if(NOT MFEM_USE_GNUINSTALLDIRS)
+  mfem_cache_path(CMAKE_INSTALL_LIBDIR "lib" "Object code libraries (lib)")
+endif()
+include(GNUInstallDirs)
+mfem_cache_path(INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}"
   "Relative or absolute path for installing header files.")
-mfem_cache_path(INSTALL_BIN_DIR "${install_bin_dir_default}"
+mfem_cache_path(INSTALL_BIN_DIR "${CMAKE_INSTALL_BINDIR}"
   "Relative or absolute path for installing the binaries.")
-mfem_cache_path(INSTALL_LIB_DIR "${install_lib_dir_default}"
+mfem_cache_path(INSTALL_LIB_DIR "${CMAKE_INSTALL_LIBDIR}"
   "Relative or absolute path for installing the library.")
-mfem_cache_path(INSTALL_SHARE_DIR "${install_share_dir_default}"
+mfem_cache_path(INSTALL_SHARE_DIR "${CMAKE_INSTALL_DATAROOTDIR}"
   "Relative or absolute path for installing shared data.")
 # other options: "share/mfem/cmake", "lib/mfem/cmake"
 mfem_cache_path(INSTALL_CMAKE_DIR "${INSTALL_LIB_DIR}/cmake/mfem"
diff --git a/INSTALL b/INSTALL
index d95b10c00..96c0f17f6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -973,8 +973,13 @@ Note that running all the tests may take a while.
 Installation prefix can be configured by setting the standard CMake variable
 CMAKE_INSTALL_PREFIX; for fine-tuning the installation directories the following
 variables can be used: INSTALL_INCLUDE_DIR, INSTALL_LIB_DIR, INSTALL_BIN_DIR,
-INSTALL_SHARE_DIR, and INSTALL_CMAKE_DIR; alternatively, fine-tuning can be done
-by setting MFEM_USE_GNUINSTALLDIRS=ON to use the CMake module GNUInstallDirs.
+INSTALL_SHARE_DIR, and INSTALL_CMAKE_DIR; alternatively, with lower precedence,
+the CMake GNUInstallDirs variables can also be used: CMAKE_INSTALL_INCLUDEDIR,
+CMAKE_INSTALL_LIBDIR, CMAKE_INSTALL_BINDIR and CMAKE_INSTALL_DATAROOTDIR.
+Note that the default for INSTALL_LIB_DIR and CMAKE_INSTALL_LIBDIR is lib. This
+is in contrast to the default behavior for GNUInstallDirs, which defines a
+platform-dependent default value for CMAKE_INSTALL_LIBDIR (lib or lib64). To
+restore this behavior, the user can set MFEM_USE_GNUINSTALLDIRS=YES.
 To install the library, use

    make install

My reasoning is as follows: <name> refers to any string whose contents is described by "name" and "name" is typically not the name of a variable, e.g. we use <mfem-source-dir>; on the other hand $(PREFIX) refers specifically to the contents of the variable PREFIX defined in the GNU make build system (typically on the command line or in config/user.mk). In the context of CMake, <PREFIX> was mean to be "the path that specifies the install prefix" which is given by ${CMAKE_INSTALL_PREFIX}. Does this clarify the distinction I'm making? We don't need to enforce this but this is my reasoning for using <name> vs using $(varname) in GNU make context vs using ${varname} in CMake context.

Here I'd suggest the following since the ${...} is (luckily!) valid for both GNU make and CMake:
diff --git a/INSTALL b/INSTALL
index 96c0f17f6..80e642a7d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -220,9 +220,9 @@ An optional installation of the library and the headers can be performed with

    make install [PREFIX=<dir>]

-The library will be installed in $(PREFIX)/lib, the headers in
-$(PREFIX)/include, and the configuration makefile (config.mk) in
-$(PREFIX)/share/mfem. The PREFIX option can also be set during configuration.
+The library will be installed in ${PREFIX}/lib, the headers in
+${PREFIX}/include, and the configuration makefile (config.mk) in
+${PREFIX}/share/mfem. The PREFIX option can also be set during configuration.

 Information about the current build configuration can be viewed using

@@ -271,8 +271,8 @@ Build options:

 Installation options:
    PREFIX  - Specify the installation directory. The library (libmfem.a) will be
-             installed in $(PREFIX)/lib, the headers in $(PREFIX)/include, and
-             the configuration makefile (config.mk) in $(PREFIX)/share/mfem.
+             installed in ${PREFIX}/lib, the headers in ${PREFIX}/include, and
+             the configuration makefile (config.mk) in ${PREFIX}/share/mfem.
    INSTALL - Specify the install program, default = /usr/bin/install
    INSTALL_DEF_PERM - Specify the default install permissions. This affects
                       headers and configuration makefiles, default = 644
@@ -989,8 +989,9 @@ or
    cmake --build . --config Release --target install  [Xcode]
    cmake --build . --config Release --target INSTALL  [Visual Studio]

-The library will be installed in <PREFIX>/lib, the headers in <PREFIX>/include,
-and the configuration CMake files in <PREFIX>/lib/cmake/mfem.
+By default, the library will be installed in ${CMAKE_INSTALL_PREFIX}/lib, the
+headers in ${CMAKE_INSTALL_PREFIX}/include, and the configuration CMake files
+in ${CMAKE_INSTALL_PREFIX}/lib/cmake/mfem.

 Configuration variables (CMake)

@nmnobre, @helloworld922, I think I added all changes based on the discussions above and a few other small changes. Let me know if I missed something or if you notice anything else worth addressing here.

@nmnobre, @helloworld922, I think I added all changes based on the discussions above and a few other small changes. Let me know if I missed something or if you notice anything else worth addressing here.

I think this is perfect! 🤩
Wasn't the easiest, but we got there in the end. Thanks for the patience/perseverance everybody.
I'd just squash to tidy it up a bit now.

Tested it out and everything appears to be configuring and building correctly.

Merged in next for testing...

My contribution ended up just being the miniapp install idea ... I doubt any of my LOC ever made it in. But thank you 😄 Thanks @v-dobrev for getting it over the finish line