text:
Add: Airbnb

Company
Airbnb
Description
Airbnb operates an online marketplace focused on short-term homestays and experiences.
Link
https://ourcollective.us/airbnb-connect-software-engineering-apprenticeship/
Location
San Francisco Bay Area
Featured Image
https://upload.wikimedia.org/wikipedia/commons/6/69/Airbnb_Logo_Bélo.svg
Thanks for reading my issue.

@zliwow Thanks for sharing this apprenticeship! Do you know if there's a new iteration of this apprenticeship available? Looks like the application deadline already passed back in early 2022, and it's unclear if this will repeat again.

Thanks for addressing my issue. You are correct, a the moment, Airbnb hasn't updated it. Though their apprenticeship is a known program, I thought I put it out there so people can keep an eye out for potential updates.

@zliwow Thanks for sharing this apprenticeship! Do you know if there's a new iteration of this apprenticeship available? Looks like the application deadline already passed back in early 2022, and it's unclear if this will repeat again.

Thanks for addressing my issue. You are correct, a the moment, Airbnb hasn't updated it. Though their apprenticeship is a known program, I thought I put it out there so people can keep an eye out for potential updates.

@zliwow Thanks for sharing this apprenticeship! Do you know if there's a new iteration of this apprenticeship available? Looks like the application deadline already passed back in early 2022, and it's unclear if this will repeat again.

Thanks for addressing my issue. You are correct, a the moment, Airbnb hasn't updated it. Though their apprenticeship is a known program, I thought I put it out there so people can keep an eye out for potential updates.

Makes sense, thanks for sharing! I'll add it in when I have a chance! 👍🏽

authors: FrancesCoronel zliwow


text:
An error occurred during installation

Hi, I just downloaded the latest 2.0.2 version from the link provided here, but I am unable to install it and the error simply says "Your system has not been modified. Click "Close" to exit the Setup Wizard". What does that even mean and how do I solve it? Thank you.

Are you familiar with running something in cmd.exe?
You can run "TwitchLeecher_2.0.2.exe -l log.txt" in order to get 2 logfiles from the installation process. Post the contents here and maybe I can help.

It seems like the problem resolved itself... Sorry I could not provide the log to find out what the problem was. All I did was shutdown my pc, go to bed and it successfully installed next morning. Tried restarting pc before that, but that didn't work. Anyway, thank you for the help and I really appreciate you creating this program. This is honestly the best twitch vod downloader.

source: gharchive/issue

repo: Franiac/TwitchLeecher

license: mit

license_type: permissive

license_source: bigquery


text:
Failed to create directX device and swapchain!

https://i.imgur.com/29oFpGr.jpg
Run the game as Administrator https://i.imgur.com/rd3bg9O.jpg
Failed to create directX device and swapchain! https://i.imgur.com/Z2Nn03N.jpg

Use: https://framedsc.github.io/GeneralGuides/universal_ue4_consoleunlocker.htm instead, it surpasses this camera and has all the features this one has too, I ported everything over.

thanks

authors: Evil-Raveen FransBouma


text:
Fix for null parent of field expression, leading to missing locations.

In [1] and [2], ExpressionHandler simplifies the AST by replacing some nodes by a FieldAccessExpr. However, the newly created FieldAccessExpr lacks some properties - especially its parent, range, and tokenRange are null. This results later in an IllegalArgumentException when a rule violation is found at that node and we try to retrieve its position in the code.
This PR fixes #96. But the original author might want to review and possibly simplify the method in general.
[1] https://github.com/Fraunhofer-AISEC/cpg/blob/487558afba9539db62484b02eb23112ecc85478a/src/main/java/de/fraunhofer/aisec/cpg/frontends/java/ExpressionHandler.java#L498

Good catch. Actually it does not simplify the AST but rather create additional AST nodes (the this expression), since this is a reversal of syntactic sugar, i.e. using field instead of this.field. So I think the overall idea how to do it has some value because there might be some additional logic depending on that this expression that otherwise will not be triggered - or needs to be simulated in the name handler.
At the time, the original author - which is me ;), wrote this we did not have any additional fancy things like passes and so so, so I was not aware of any other problems.
So there are two issues here:

Obviously I was to lazy to correctly set needed values, this is now fixed, thanks to @JulianSchuette
Does this replace operation cause any other problems? For that I am not sure and I would suspect that it would be ok.

source: gharchive/pull-request

authors: JulianSchuette oxisto

repo: Fraunhofer-AISEC/cpg

license_source: github-api


text:
Postman collection has typo or the source is wrong

Executing "1. Execute the request Client/1. Get dataset for asset failed.

Error 404 Not Found

It seems that path "datasets" should be "data" or the source code for  handling this request is wrong.
Anyway, changing to "dataset" just worked fine for me.

{{consumer}}/api/automated/datasets?providerUrl={{provider-dsp}}&assetId={{asset-id}}

should be

{{consumer}}/api/automated/dataset?providerUrl={{provider-dsp}}&assetId={{asset-id}}

BreadcrumbsEDC-Extension-for-AAS/example/resources
/aas_edc_extension.postman_collection.json
         "name": "1. Get datasets for asset",
          "request": {
            "method": "GET",
            "header": [],
            "url": {
              "raw": "{{consumer}}/api/automated/datasets?providerUrl={{provider-dsp}}&assetId={{asset-id}}",
              "host": [
                "{{consumer}}"
              ],

Thanks for bringing this up!

authors: carlos-schmidt miwamasa

repo: FraunhoferIOSB/EDC-Extension-for-AAS


text:
callsigns/radio name

how do i set it up to where they radio name is there discord or steam name

did you ever figure this out?

authors: HeadDevDaniel chillicharles

repo: FrazzIe/mumble-voip-fivem

license: MIT


text:
corrected MD syntax in  readme file

Just small thing please merge it.

Apparently everyone has made these pull requests...
These are all the same: #99, #98, #97, #96, #95, #94

Fixed by #93

authors: FredKSchott fiskr jsroyal

repo: FredKSchott/CoVim


text:
Byte patch API

Implemented a new class called PatchManager that is located in the AmethystContext class.
To Add a patch all a mod needs to do is ctx->mPatchManager.ApplyPatch(ADDRESS, VALUE, COUNT) an example would be
ctx->mPatchManager.ApplyPatch(0x5000, 0x20, 1)
it also can do larger types like int and int64 automatically with ctx->mPatchManager.ApplyPatch(0x5000, 500)
A full use case of this API to extend the piston push limit is on My Github

if i were making this id use libhat's memory protector instead

I didn't realize that libhat had stuff for that, is there any particular reason why it'd be better?

It is cleaner, and you don't have to manually do the DWORD and messy windows virtual protect stuff yourself

Brady could probably give you a better list of reasons, but in my opinion it boils down to being cleaner and easier to understand/read

It is cleaner, and you don't have to manually do the DWORD and messy windows virtual protect stuff yourself

While i do agree i mostly didnt use them cuz its 1. Not much work. 2. Not using someone else code I dont fully understand. 3. It doesnt matter anyway

I'll take a look through now

I just noticed a bug in the remove all patches function
Ill fix that

See comments throughout, feel free to request another review once you're ready

Ive been fixing the issues as u have mentioned them.
I also replied to some and thoughts on why the code is setup like that

Outside of the dtor of the PatchManager class which i think should keep the call to clear up its own memory in case of another mod instancing it for example. All concerns have been addressed

To expand on mods creating their own patch manager, that would quite easily end up creating weird race conditions. I think generally mods shouldn't need / want to create their own because of that

I do agree that it shouldnt be needed per say but there is probably some use case.
Again the main thing for me is its a memory leak if that isnt called.

authors: Duckos-Mods FrederoxDev Intoprelised

repo: FrederoxDev/Amethyst


text:
Confusing Waypoint: Write Reusable JavaScript with Functions

http://www.freecodecamp.com/challenges/waypoint-write-reusable-javascript-with-functions
In this waypoint you learn functions but a few things are confusing to new people in my opinion:
1)  Showing functions written two different ways without any explanation:
On the code you see:
ourFunction = function() {
  return a - b;
};

but the description shows  a function written like this:
function functionName (a, b) {

  return(a + b);

}

If this is your first time seeing this it could bring unnecessary confusion in my mind.
2.) The function shown in the code does not pass any arguments.
This code shown again does not have anything passed in and uses the global variables.  Being new this could cause unnecessary confusion without understanding how functions work:
ourFunction = function() {
  return a - b;
};

I suggest removing the ourFunction = function() { return a -b; }; in the code or maybe explaining how the values are getting into the function by passing them or globally.

Also, the task itself does not say clearly what to write inside myFunction.

Thanks @Daynewr,
Confirmed!  Also the test does not actually run the function thus:
function(){
   return a+b;
}

will pass even though a and b aren't set

authors: ArgonCode Daynewr benschenker

repo: FreeCodeCamp/FreeCodeCamp


text:
Description is not clear

Challenge Image Search Abstraction Layer has an issue.
Description is not clear. Please give any hint from where can we get the search results.

@bunnyvishal6 the challenges are designed for you to go out and search how to complete these challenges for yourself. For challenge help and guidance, please visit our Gitter chat room focused on Back-End challenges where there will be people willing to give you hints or resources that may help. Happy coding!


text:
[beta] Top of iphone is truncated

fixed

authors: BerkeleyTrue QuincyLarson


text:
Fix consistency between questions

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[ ] Closes currently open issue (replace XXXX with an issue no): Closes #XXXX

Description

The previous step says that you must say view more, and this one doesn't have that. This pull fixes that.

Updated fixing spelling error from last commit
-        "
Click here tp view more cat photos.
",
+        "
Click here to view more cat photos.
",
                         ^


text:
codec/nsc: fix memory corruption in case of chroma subsampling

For odd number of rows, the memory copy operation was broken: after exiting
the loop, yplane points to the end of the last row data, and thus (yplane +
rw) points after the end of the last row.

@freerdp-bot what do think of it, would you mind give a test ?

authors: hardening krisztian-kovacs-balabit

repo: FreeRDP/FreeRDP


text:
Shadow big endian

@ondrejholy this should address #9925 but no way to properly test.

@freerdp-bot test

@freerdp-bot test

Thanks for looking into it. I've just made a quick test and see just a black screen now, so this is obviously not correct...

@ondrejholy ok, did have a bug in there, should be fixed now. (new function now  did work on same color)

It works fine now, except for cursor colors. The shadow_subsystem_pointer_convert_alpha_pointer_data function also needs to take the subsystem->format into account. I've just tested that reverse ordering of the https://github.com/FreeRDP/FreeRDP/blob/3.3.0/server/shadow/shadow_subsystem.c#L240-L243 lines fix cursor colors on big-endian...

@ondrejholy ok, did push a fix for the cursor color conversion function too

authors: akallabeth ondrejholy


text:
[DOC] freertos.org directs to midway-auth.amazon.com

Describe the issue
freertos.org directs to some issue page
Reference
freertos.org
Screenshot

Browser

Browser: Chrome Android
Version: 127.0.6533.103

Thanks for reporting the bug, we have recently updated the website. That might be a few links missed update.  If you can paste the exact link that leads to this, that'll be a great help to fix the issue.  Thanks

Thanks for reporting the bug, we have recently updated the website. That might be a few links missed update. If you can paste the exact link that leads to this, that'll be a great help to fix the issue. Thanks

It would be directly the link https://freertos.org and any link

But it seems to work now

Hello @emilfihlman,
Thank you for raising the bug report.
We were deploying some fixes to the website. The deployment failed though and caused the cloudfront distribution to be this was. We have since rolled it back. You should be able to access the website now.
Let me know if you want to keep this open or shall we close the ticket?

As the redirection is working now, I am closing this ticket. Feel free to reopen if you need anything from us.

authors: AniruddhaKanhere aggarg emilfihlman xuelix

repo: FreeRTOS/FreeRTOS


text:
finishd 144

@xliu45

Looks good. I am not familiar with JAVA, so I am not sure if you need to "delete" after you use "new" in  your main function. Or it might cause memory leakage.

@xliu45 No worries, Java has garbage collection system to manage it.
@JoannaCode Again, please fix the indentation. What kind of IDE or Text Editor you use, BTW? Is it that hard to config?

@FreeTymeKiyan Thank you for reply

This is an automatically generated message.
yanjiao@yahoo-inc.com is no longer with Yahoo! Inc.
Your message will not be forwarded.
If you have a sales inquiry, please email yahoosales@yahoo-inc.com and someone will follow up with you shortly.
If you require assistance with a legal matter, please send a message to legal-notices@yahoo-inc.com
Thank you!

@FreeTymeKiyan  I useS Eclipse. So it can automatic generate the main function(which have tab included) and  the tab in each line. So I need delete each line's tab and use space. It looks well in Eclipse.

authors: FreeTymeKiyan JoannaCode xliu45 yanjiao

repo: FreeTymeKiyan/LeetCode-Sol-Res


text:
Records page - screen reader user improvement

The table caption, heard by screen-reader users, is for example, "Information of Hackney District". To sound more natural, the "of" should be replaced with "about".

This change has already been implemented (some time ago?!), so this issue can be closed.

authors: PatReynolds richardofsussex


text:
Colour of donate

Is this the correct colour

Asset pipeline is awaiting deployment.

@Vino-S deployed latest code to t3 and  ran precomile on t3 but colour remains unchanged

@Captainkirkdawson Yes, I was asked to make the button Teal for all 3 projects.

TY @AlOneill Guess we are good to go @Vino-S

authors: AlOneill Captainkirkdawson PatReynolds

repo: FreeUKGen/FreeCENMigration


text:
🛑 Drone Sekretariat-DJPb is down

In dbd3849, Drone Sekretariat-DJPb (https://drone.setditjen-djpb.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Drone Sekretariat-DJPb is back up in 6a03917.

repo: FrideyAlpha/uptime-setditjen


text:
🛑 Network is down

In eded77b, Network (https://mycloud-jkt.zettagrid.id/tenant/Org_cloud60988) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Network is back up in 8140a2a.


text:
🛑 API (DF) Sekretariat-DJPb is down

In 463a703, API (DF) Sekretariat-DJPb (https://df1.setditjen-djpb.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API (DF) Sekretariat-DJPb is back up in e1cf58c.


text:
🛑 Project Management Sekretariat-DJPb is down

In 6a2ec78, Project Management Sekretariat-DJPb (https://project.setditjen-djpb.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Project Management Sekretariat-DJPb is back up in 2981000.


text:
Multiline interfaces are not completely multiline

Bug report
Before reporting a bug, make sure PHP CS Fixer is up-to-date.
Please describe the problem and provide technical details such as:

PHP version: 7.4.12
PHP CS Fixer version: PHP CS Fixer 2.17.0 Desert Beast
the command used to run PHP CS Fixer (run with -vvv): php bin/php-cs-fixer fix --config .php_cs
the configuration (file) you used

    ->setCacheFile(__DIR__.'/.php_cs.cache')
    ->setRules([
        '@PSR2' => true,
        '@Symfony' => true,
        '@Symfony:risky' => true,
        'array_syntax' => ['syntax' => 'short'],
        'blank_line_after_opening_tag' => false,
        'class_definition' => ['single_line' => false],
        'concat_space' => ['spacing' => 'one'],
        'global_namespace_import' => [
            'import_classes' => true,
            'import_constants' => true,
            'import_functions' => true,
        ],
        'mb_str_functions' => true,
        'no_unused_imports' => true,
        'ordered_class_elements' => true,
        'ordered_imports' => [
            'sort_algorithm' => 'alpha',
            'imports_order' => ['class', 'function', 'const'],
        ],
        'phpdoc_no_empty_return' => false,
        'header_comment' => [
            'comment_type' => 'PHPDoc',
            'location' => 'after_declare_strict',
            'separate' => 'both',
            'header' => $header,
        ],
    ])
    ->setRiskyAllowed(true)
    ->setFinder($finder)
;

### Code snippet that reproduces the problem
`class CustomPage implements
    SoftDeleteableInterface,
    AuditLoggableInterface,
    UsergroupFilterableInterface,
    TranslatableInterface,
    KeyedInterface,
    ContainsRecordedEvents
{}`

When i run the phpcs fixer on version v2.16.10 everything seems to be fine. and the multiline list of interfaces looks like above, according to the psr2 standards that is the way it should be

Copy from psr 2 website: https://www.php-fig.org/psr/psr-2/
"Lists of implements MAY be split across multiple lines, where each subsequent line is indented once.
When doing so, the first item in the list MUST be on the next line, and there MUST be only one interface per line."

When i update to 2.17.0 this happens

`class CustomPage implements SoftDeleteableInterface,
    AuditLoggableInterface,
    UsergroupFilterableInterface,
    TranslatableInterface,
    KeyedInterface,
    ContainsRecordedEvents
{}`

As you can see the SoftDeleteableInterface is suddenly behind the implements. When i comment out ` '@Symfony' => true,` from the config the result is as i expect, So the first item in the list is on the next line. i was not able to find out the reason of this behaviour.

Please let me know if you need some additional information.

Thank you very much for you time

This was fixed by https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/5387.

authors: csmeets kubawerlos

repo: FriendsOfPHP/PHP-CS-Fixer


text:
GroupImportFixer - introduction

Hi guys! I just implemented feature #3143. Please check it and give me some feedback. Thanks in advance.

Can you add a test case with these imports:
use Foo\Bar;
use Foo\Baz;
use Foo\Baz\John\Doe;
use Foo\Baz\John\Smith;
use Foo\Baz\John\Smith\Junior;
use Foo\Baz\Johnny\Doe;
use Foo\Baz\Johnny\Smith;

?
Possibly other combinations.
Also I wonder what strategy should be also in such case:
use Foo\Bar;
use For\Baz\Lorem\Ipsum\Lets\Write\Some\More\Strings\One;
use For\Baz\Lorem\Ipsum\Lets\Write\Some\More\Strings\Two;

Should it group by Foo or by For\Baz\Lorem\Ipsum\Lets\Write\Some\More\Strings or make nested grouping (is that even valid syntax?)?

@kubawerlos

Added test case with your imports.
It will group by For\Baz\Lorem\Ipsum\Lets\Write\Some\More\Strings. I think in future we can implement different strategies for this :)

@keradus @SpacePossum @kubawerlos guys, can you check this PR? please? Is it OK?

I think this new rule must be added to the (known) conflicts map here
single_import_per_statement => group_import

When testing:
[09:03 AM]-[possum@zoo1]-[~/work/PHP-CS-Fixer]-[git feature-group-import-fixer]
$ php php-cs-fixer fix --dry-run --rules=group_import -vvv src/Tokenizer/Transformer/NullableTypeTransformer.php
Loaded config default.
Using cache file ".php_cs.cache".
E
Legend: ?-unknown, I-invalid file syntax, file ignored, S-Skipped, .-no changes, F-fixed, E-error

Checked all files in 0.010 seconds, 12.000 MB memory used

Files that were not fixed due to errors reported during linting after fixing:
1) /home/possum/work/PHP-CS-Fixer/src/Tokenizer/Transformer/NullableTypeTransformer.php

[PhpCsFixer\Linter\LintingException]
PHP Parse error: syntax error, unexpected 'use' (T_USE), expecting identifier (T_STRING) or function (T_FUNCTION) or const (T_CONST) on line 15.

Applied fixers: group_import

[09:03 AM]-[possum@zoo1]-[~/work/PHP-CS-Fixer]-[git feature-group-import-fixer]
$ php -v
PHP 7.2.15-0ubuntu0.18.04.2 (cli) (built: Mar 22 2019 17:05:14) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.15-0ubuntu0.18.04.2, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans

[09:03 AM]-[possum@zoo1]-[~/work/PHP-CS-Fixer]-[git feature-group-import-fixer]
$ g log
commit 77a3f327897274ffdeb61bc9f7b8066c6696b01b (HEAD -> feature-group-import-fixer, greeflas/feature-group-import-fixer)
Author: greeflas <vldmr.kuprienko@gmail.com>
Date:   Mon Apr 1 22:29:49 2019 +0300

CR fixes

[09:03 AM]-[possum@zoo1]-[~/work/PHP-CS-Fixer]-[git feature-group-import-fixer]
$ g st
On branch feature-group-import-fixer
Your branch is up to date with 'greeflas/feature-group-import-fixer'.

nothing to commit, working tree clean

It seems the rule created:
<?php
namespace PhpCsFixer\Tokenizer\Transformer;

use PhpCsFixer\Tokeniz\{use PhpCsFixer\Tokenizer\{CT, Token, Tokens};

form:
namespace PhpCsFixer\Tokenizer\Transformer;

use PhpCsFixer\Tokenizer\AbstractTransformer;
use PhpCsFixer\Tokenizer\CT;
use PhpCsFixer\Tokenizer\Token;
use PhpCsFixer\Tokenizer\Tokens;

@SpacePossum Issue was fixed. It was related to rtrim() function. In this case rtrim('PhpCsFixer\Tokenizer\AbstractTransformer', '\\AbstractTransformer') function was returned wrong namespace PhpCsFixer\Tokeniz.
Also I added test case for this.

Wasn't it merged to Master?

@basheerOct not yet.
@SpacePossum any progress on this PR?

Friendly ping @greeflas. Would you have time to continue working on this PR?

@juliendufresne yeap, I will check your comments when will have a time.

@greeflas Hey, I would like to have this fixer. Will you update your merge request?

@Okspen Yeap, waiting for @julienfalque response.

@julienfalque & @SpacePossum Could you please review?

@SpacePossum, @julienfalque Can you please merge the request or leave comments what is else required to finish it? Thanks!

This is probably out of scope for this PR at this point, but I would love to be able to configure which types of imports this fixer applies to.  e.g. I would group function and constant imports, but not classes or traits.  Just something to keep in mind.

Thanks @greeflas !
It has been almost 2 years and I'm sorry for the long wait. I'm very happy to have merge your PR and hope a lot of user will use it to their benefit!

@SpacePossum Hooray! I hope for it as well!

authors: Okspen SpacePossum basheerOct greeflas hackel julienfalque kubawerlos


text:
DX: fail on risky tests

Risky tests are e.g. when time limit was exceeded.

Coverage increased (+0.5%) to 92.061% when pulling 43fd57e4a67c1d9c778969f9776b5a1374bda6c1 on kubawerlos:fail_on_risky_tests into 714e1922c6c598c8d032f166fdfbe86217e43bfd on FriendsOfPHP:2.19.

Thank you @kubawerlos.

authors: coveralls keradus kubawerlos


text:
Multiple patch candidates does not appear in the plug-in

If I list multiple patches as candidates, only one appears in the fix list.

If there are no duplicate patch entries, it works as expected.


text:
Resolve conflict with nuxt ^3.0.0

Look like composition-api version has conflict.

Thanks @kindslayer for letting me know about that. This is probably a typical Nuxt 3 issue. Please try using instead:
npm install vue-tiny-validate --legacy-peer-deps

authors: culee kindslayer

repo: FrontLabsOfficial/vue-tiny-validate


text:
Consider using stdint types

There is some weird custom using uchar which appears to be used exactly like the std-type uint8_t from <stdint.h> (or <cstdint> in C++) .

done

authors: FrotBot JayFoxRox

repo: FrotBot/SwitchProConLinuxUSB


text:
Bind on 0.0.0.0

Hi,
When I listen on 0.0.0.0 it throw an error, do you know the reason ?
IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses that cannot be used as a target address
You need to change public string ServerAddress { get; set; } to a IPAddress to add the possibility to use IPAddress.Any or simply add a wildcard like *
Thanks

I'm unable to reproduce this problem. I remember having problems  with some older versions of the FTP server, but those should be fixed in 2.2.1.
I tested it with both Linux and Windows, with the following commands:

sudo dotnet run -- -a "0.0.0.0" in-memory
sudo dotnet run -- -a "::" in-memory
sudo dotnet run -- -a "*" in-memory

Do you have tried the library directly ?

Will do

I created a program (same as the quickstart sample) and used the library in version 2.2.1. Everything works as expected - both under Linux and Windows.
Do you use .NET Core, .NET Framework, or Mono on Windows or Linux?

.Net core / windows and linux, please send me the snippet that you use to bind on 0.0.0.0

Here's a test project that binds the server to 0.0.0.0 (without logging).
TestFtpServer.zip

Yes I confirm that it works, on linux normally I'm already in root, I will try and keep you informed

We use it for https://clicksguard.io and it works fine !

authors: clintnetwork fubar-coder

repo: FubarDevelopment/FtpServer


text:
Return Gas costs regardless of whether getTransactionCost returns an error

Currently, when calculating gas costs for a transaction, if there is an error during the dry run it is thrown and no gas costs are returned.
For many use cases this is sufficient, but there are also scenarios where a consumer may still want the gas costs even if an error happened during the dry run, such as in a DEX, here's an example use case taken from this forum post

when swapping tokens on a DEX and specifying some slippage, the simulation might fail but the user still might want to send the transaction, which can succeed in case the state of the DEX changes.

We should refactor this method to return both the error and the gas cost to accommodate for such a scenario.

@maschad this is already possible. The receipt of type script return will be present within the receipts array that will be present within the FuelError metadata property.
However, it is important to be aware that this value won't represent the real gas used.
Since the transaction failed, the Sway project code was not entirely executed, therefore the gas consumed does not represent the gas that will be consumed if the same transaction succeeds.
I believe we can close this issue

@Torres-ssf thanks for clarifying that, and upon reconsideration I think it would probably be more appropriate for the consumer to handle errors related to low gas costs and then allow the user to proceed with the transaction, rather than forcing them to handle all errors.

authors: Torres-ssf maschad

repo: FuelLabs/fuels-ts


text:
forc deploy should accept initial storage slots

forc deploy should accept initial storage slots, likely through a JSON file that contains: https://github.com/FuelLabs/fuel-specs/blob/master/specs/protocol/storage_initialization.md. The compiler will emit this file for every contract.

With https://github.com/FuelLabs/sway/pull/2078, forc deploy directly uses the storage initializers generated by the compiler. @adlerjohn do you think it's also useful to be able to override those initializers by passing a user-defined JSON to the forc deploy command?

Having that feature probably doesn't hurt.

authors: adlerjohn mohammadfawaz

repo: FuelLabs/sway


text:
feat: sway-fmt-v2 preserves newline with given threshold

Opening up for visibility.
closes #2379.
TODO:

[ ] Move threshold to config

Huge 🙌🏻 Very excited to get this in

authors: eureka-cpu kayagokalp


text:
Fix layout flicker on swap

When data is loading on the inputs or on the swap preview the layout should not resize.
Note:

When the input doesn't have an amount it didn't show it below, we could leave the space empty
When the max is not allowed yet but is loading it could show a placholder.
When inverting it has a delay between changing the values when not having a balance after it has balance on both coins only the max button is delayed.
https://user-images.githubusercontent.com/3941923/176050346-e6ac73e9-0865-411d-b198-cf0ad72023c8.mov

this may involve some different issues:

[ ]  #355

@luizstacio are we on a good shape to close this issue now?

authors: LuizAsFight luizstacio

repo: FuelLabs/swayswap


text:
[do not merge] Remove InvideoProgramming

We don't have to keep "The number of videos with in-video programming" because YouTube removed Featured annotations last month. And soon yt-annotations gem will deprecate Yt::Annotations::Featured class

do not merge until Chris says ok

repo: Fullscreen/yt-audit


text:
当课程下有较多数量的资料时，Expander显示异常

问题描述
当课程资料较多时，对 Expander 完成一次展开、收起之后，再展开就会出现渲染 Bug，

期望结果
实现正常渲染

暂时不清楚这是什么原因，由于 Expander 的展开收缩完全是 WinUI 3 进行控制的，因此怀疑是 WinUI 3 的 Bug。

repo: FuryMartin/BUAA-SpocHelper


text:
i wanna modify the stuff for the dave section

please i wanna add an bambi section
plis

This does almost nothing

This does almost nothing

^


text:
Install doesn't complete with python 3.12

Using python 3.12 I obtained the following error:
  Building wheel for faiss-cpu (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for faiss-cpu (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [93 lines of output]
...
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for faiss-cpu
Failed to build faiss-cpu
ERROR: Could not build wheels for faiss-cpu, which is required to install pyproject.toml-based projects

This could be fixed by downgrading python to 3.9 (see https://github.com/kyamagu/faiss-wheels/issues/80)
I recommend updating the README.md to state which versions of Python the software has been tested with.

Can confirm that installation was unsuccessful with 3.12 but successful with Python v3.11.6 (on an M2 Mac).

We have just released version 5, which no longer depends upon faiss. So I am going to close this out.
If you issue still persists, please reopen a new issue using paper-qa>=5

authors: jamesbraza jhrcook kfletcherelo

repo: Future-House/paper-qa


text:
🛑 FuzzyGrim is down

In 1d0b692, FuzzyGrim (https://www.fuzzygrim.com/) was down:

HTTP code: 521
Response time: 168 ms

Resolved: FuzzyGrim is back up in 2b4d1ce.

repo: FuzzyGrim/uptime-monitor


text:
{row,column}-gap, applied to multicolumn, flex, and grid layouts

CSS Align 3 redefines the row-gap and column-gap properties, extending them to layouts other than multicolumn.

multi-column elements
column-gap specifes the gutter between adjacent column boxes. See [CSS-MULTICOL-1] for details on how this affects the layout of multicol elements. row-gap does not currently apply.
flex containers
When applied to the main axis (e.g. column-gap in a row flex container), indicates minimum spacing between items, as if a fixed-size margin were inserted between adjacent flex items in a single line.
When applied to the cross axis (e.g. row-gap in a row flex container), indicates minimum spacing between adjacent flex lines.
grid containers
The row-gap and column-gap properties, when specified on a grid container, define the gutters between grid rows and grid columns, respectively. See CSS Grid Layout 1 §10.1 Gutters: the grid-column-gap, grid-row-gap, and grid-gap properties for precise details.

Furthermore, the generic properties will override the grid-row-gap and grid-column-gap properties, respectively, which are specific to grid layout only.
And lastly, the gap shorthand specifies row and column gaps at once, also overriding grid-gap.

update: Chrome has enabled this feature in v66:
https://www.chromestatus.com/feature/4986266210795520

Related: https://blogs.igalia.com/mrego/2018/04/04/getting-rid-of-grid-prefix-on-css-grid-layout-gutter-properties/#implementation

gap properties for Flexbox are only supported in Firefox Nightly (version 63.0a1) AFAIK.

This doesn't seem to be supported yet in Chrome

Chrome has renamed the CSS properties, but they do not yet work with flexbox.
Chrome's flexbox gutter support can be tracked here: https://bugs.chromium.org/p/chromium/issues/detail?id=762679.
There's no entry on https://www.chromestatus.com/ yet, so I've filed a request to add it.

I raised a PR to add this: https://github.com/Fyrd/caniuse/pull/4961
Also, I'm trying to build some momentum on this, because it's really important but few browsers are picking it up: https://twitter.com/OliverJAsh/status/1139981721879928832. Please RT!

Support in flexbox added by @OliverJAsh now available at https://caniuse.com/#feat=flexbox-gap

Shall we close this now?

@Fyrd , @OliverJAsh — Looks like all the cases covered in my OP are live. I’ll go ahead and close; feel free to reopen if there are any outstanding issues.

authors: Fyrd OliverJAsh benface chharvey dskoziol jonathantneal

repo: Fyrd/caniuse


text:
Array.prototype.includes and String.prototype.includes exists in IE 11

Found IE 11.547.16299.0
Array.prototype.includes and
String.prototype.includes evaluates to
function includes() { [native code] }

https://github.com/mdn/browser-compat-data/issues/2634

As mentioned on the browser-compat-data thread there doesn't seem to be any evidence of real support, so closing this issue.

authors: Fyrd aifrim


text:
Add :focus-ring pseudo class

Currently this is only supported in Firefox with a prefix. There’s a spec in the draft Selectors 4 module: https://drafts.csswg.org/selectors-4/#the-focusring-pseudo, and bug IDs for the other browsers’ upcoming implementations in the JSON.
A testcase can be found at https://codepen.io/anon/pen/XeeJMo.
Fixes https://github.com/Fyrd/caniuse/issues/3267.

Thanks!

authors: Fyrd robinwhittleton


text:
Added Pointer Events support in iOS 13.2

As the bugs mentioned in 526f26e has been fixed in iOS 13.2, the status can be changed to full support.
For reference, look for the according <rdar://problem/...> in the WebCore ChangeLog.

releasePointerCapture Issue: <rdar://problem/53127223>
buttons Issue: ~<rdar://problem/55394548>~ <rdar://problem/52778374>

@Fyrd I don't think I can resolve this failure...

@kiding Okay, 13.2 is now separate, thanks for discovering that.

Thanks!

authors: Fyrd kiding


text:
Load flow comparison on PEGASE case

using: case9241pegase

The .m and .mat file are both available here: https://github.com/G-PST/power-flow-exercise/tree/main/reference-matpower

[ ] PowerSystems.jl
[ ] PowerModels.jl
[ ] PowSybl
[ ] pandapower

repo: G-PST/power-flow-exercise


text:
feat: Make tests work on a separate database

On the same DB connection
unrelated: probably wrong naming of issues.

Forgot to mention this one, solved with #15


text:
Addition of Battlelore

Hello! Please let me know if any changes are required. The game is executable through BattleloreGame.java.

Hey @rdgain , I've done the review fixes, and it is ready for confirmation. Please let me know if anything else is required.

done 💯

repo: GAIGResearch/TabletopGames


text:
Suppress warning messages with a command line option for script support

I use Powershell scripts for user decommissioning. It pulls a list of Employee IDs from a file, looks them up in AD, does some work on them, then calls GAM to signout, change password, deprovision, and wipe all their mobile devices. Unfortunately the script throws an error when pulling the list of devices because of the unexpected "Getting a list of devices, may take a long time for large domains" warning.
This doesn't prevent the script from working, but it would make things a lot smoother if there were an option to suppress warnings like that in the command line. Something like "gam.exe print mobile query email:$UserEmail nowarning"
Example:
PS C:\Users\jcaldwell\Desktop\Terminate> c:\gam\gam.exe print mobile query email:myemail@mydomain.org | ConvertFrom-csv
c:\gam\gam.exe : Getting all Mobile Devices in Google Workspace account that match query (email:myemail@mydomain.org) (may take some time on a large account)...
At line:1 char:1

c:\gam\gam.exe print mobile query email:myemail@mydomain.org | Co ...

  + CategoryInfo          : NotSpecified: (Getting all Mob...rge account)...:String) [], RemoteException
  + FullyQualifiedErrorId : NativeCommandError

Got 9 Mobile Devices...
Everything between the invocation of Gam and the "Got 9 Mobile Devices..." is in red, presumably because it doesn't match the expected CSV format. Being able to suppress that warning would clean things up nicely.

In Advanced GAM you can suppress the "Getting ... " messages.
gam config show_gettings false save
Ross
On Thu, Jul 6, 2023 at 2:14 PM GuruBuckaroo @.***>
wrote:

I use Powershell scripts for user decommissioning. It pulls a list of
Employee IDs from a file, looks them up in AD, does some work on them, then
calls GAM to signout, change password, deprovision, and wipe all their
mobile devices. Unfortunately the script throws an error when pulling the
list of devices because of the unexpected "Getting a list of devices, may
take a long time for large domains" warning.
This doesn't prevent the script from working, but it would make things a
lot smoother if there were an option to suppress warnings like that in the
command line. Something like "gam.exe print mobile query email:$UserEmail
nowarning"
Example:
PS C:\Users\jcaldwell\Desktop\Terminate> c:\gam\gam.exe print mobile query
@.*** | ConvertFrom-csv
c:\gam\gam.exe : Getting all Mobile Devices in Google Workspace account
that match query @.***) (may take some time on a
large account)...
At line:1 char:1

c:\gam\gam.exe print mobile query @.*** | Co ...

 + CategoryInfo          : NotSpecified: (Getting all Mob...rge account)...:String) [], RemoteException
 + FullyQualifiedErrorId : NativeCommandError

Got 9 Mobile Devices...
Everything between the invocation of Gam and the "Got 9 Mobile Devices..."
is in red, presumably because it doesn't match the expected CSV format.
Being able to suppress that warning would clean things up nicely.
—
Reply to this email directly, view it on GitHub
https://github.com/GAM-team/GAM/issues/1641, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCTYLZ5NWYK7XXL2EUZP5DXO4TBZANCNFSM6AAAAAA2A7APCU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Ross Scroggs
@.***

repo: GAM-team/GAM


text:
Student Email not being displayed on print guardians

I am on the lastest versin of GAM :
GAM 6.58 - https://jaylee.us/gam - pyinstaller
Jay Lee jay0lee@gmail.com
Python 3.11.3 64-bit final
google-api-python-client 2.86.0
Windows 10 10.0.19045 SP0 Multiprocessor Free AMD64
I am typing this command
gam print guardians states COMPLETE or gam print guardians states PENDING
In the output the email address of the Student is shown as a dash
studentEmail,studentId,invitedEmailAddress,guardianId,guardianProfile.id,guardianProfile.name.givenName,guardianProfile.name.familyName,guardianProfile.name.fullName,guardianProfile.emailAddress,guardianProfile.photoUrl
-,113598460230650191863,sdf@gmail.com,118103346619633377974,118103346619633377974,xxx,xxx,sdf@gmail.com,//0RyfGSEezVSbo288
-,113486881024228864227,ahtg4sllis@gmail.com,A2CgcI2O2ctbgS,,,,,ahtg4sllis@gmail.com,

....

I need to correlate invitedEmailAddress with studentEmail - so missing information is a huge problem.
Is this a bug or by design.
Is there a work around to get a list of which student's guardians have been emailed ?
What I am trying to achieve is get a list of students's guardians whose guardian summaries invites are still pending (not complete) so we can resend the invitation to them. And the GAM create invite command needs parent-email and student-email for invitation.

GAM 6.58 does not supply this data when you ask for all guardians; it does supply it when you ask for guardians for a specific student.

gam user @.*** print guardians states COMPLETE

Advanced GAM can supply the studentEmail when printing all guardians.
See: https://github.com/taers232c/GAMADV-XTD3/wiki/How-to-Upgrade-from-Standard-GAM https://github.com/taers232c/GAMADV-XTD3/wiki/How-to-Upgrade-from-Standard-GAM
See: https://github.com/taers232c/GAMADV-XTD3/wiki/Classroom-Guardians#display-guardians-csv-format https://github.com/taers232c/GAMADV-XTD3/wiki/Classroom-Guardians#display-guardians-csv-format
Ross
Ross Scroggs
@.***

On Sep 29, 2023, at 12:59 AM, yasnileniarb @.***> wrote:
I am on the lastest versin of GAM :
GAM 6.58 - https://jaylee.us/gam https://jaylee.us/gam - pyinstaller
Jay Lee @.*** @.***>
Python 3.11.3 64-bit final
google-api-python-client 2.86.0
Windows 10 10.0.19045 SP0 Multiprocessor Free AMD64
I am typing this command
gam print guardians states COMPLETE or gam print guardians states PENDING
In the output the email address of the Student is shown as a dash
studentEmail,studentId,invitedEmailAddress,guardianId,guardianProfile.id,guardianProfile.name.givenName,guardianProfile.name.familyName,guardianProfile.name.fullName,guardianProfile.emailAddress,guardianProfile.photoUrl
@.@.,//0RyfGSEezVSbo288
@.@.,
....
I need to correlate invitedEmailAddress with studentEmail - so missing information is a huge problem.
Is this a bug or by design.
Is there a work around to get a list of which student's guardians have been emailed ?
—
Reply to this email directly, view it on GitHub https://github.com/GAM-team/GAM/issues/1663, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL3M63COVQ55FPCPVVTX4Z5WXANCNFSM6AAAAAA5MCT66Q.
You are receiving this because you are subscribed to this thread.


text:
ANTIGONE parameter file

When I specify a parameter for ANTIGONE (e.g. set_optimizer_attribute(model,"feas_tolerance", 1e-14)), I get the following error
*** Error Cannot open parameter file "/tmp/gams_jl_lOie8z/antigone.opt"
*** Error Error code = 2; No such file or directory
Is this error coming from my settings or the package.
Thanks!

This seems to be a duplicate of #15.

authors: renkekuhlmann schlanghorvetz


text:
🛑 IPT is down

In a7cf889, IPT (https://ipt.gbif.es) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IPT is back up in d4c4eef.

repo: GBIFes/status


text:
Add Runtime Permission Demo

Marshmallow comes with Runtime permission. Demo illustrate how to handle permission in Marshmallow and pre-Marshmallow

Thank you for pushing examples.

authors: PareshMayani rathodchintan

repo: GDGAhmedabad/Learning-Resources


text:
initial commit of alliteration filter

A simple alliteration filter that checks if a sentence is an alliteration or not.

Sorry, I did not mean to close the pull request, I wanted to force-reload from the upstream branch to undo my erroneous changes to the wrong folder, which had caused the checks to fail.

Simply superb submission! Alliteration's always an amusing attribute to amplify. I just have a few minor comments.

In your README, you don't state what your exact criterion for alliterativity is. It's clear from your code, but it's worth mentioning towards the top of the README.

That criterion's pretty strong - few people would say that "Peter Piper picked a peck of pickled peppers" isn't alliteration! I think it'd make sense to weaken it (e.g. allow one off-word for every $k$ alliterative words) or allow the user to set the filter strength (e.g. take $k$ as an argument).

For multi-sentence input, what's your rationale for ignoring all but the first sentence? I'd intuitively expect that the filter would either check whether the entire passage was alliterative on the same letter or whether each sentence is independently alliterative.

Solid work! Let me know if you have any questions.

I enjoyed this submission as well. I agree with @james-simon, but on the last point I think that it would make the most sense to treat each sentence independently, since that's probably more likely than an entire passage being alliterative.

Thanks for the submission! I think it would be good to add a few words on why sentences with alliterations are a challenge, and for which tasks; right now this is not clear to me (even if I like the idea). As mentioned previously, please also add the method you apply to select the sentences. By the way, this is tagged as "Transformation" but should probably be "Filter".

Hi @james-simon,
gratitude and greetings! Alliterations always attract audiences.

I added a few more lines in the README to explain my criterion for alliterativity. Fixed in 9940840
I have added a new variable min_alliteration_length to alleviate it. Now, a sentence is deemed an alliteration if it contains at least min_alliteration_length words starting with the (first) phoneme found. Would it make sense not to use the first phoneme but the one that occurs most in each sentence?
I wanted to avoid checking if a whole paragraph was alliterative because I thought that would practically never be the case. But I agree that ignoring the remaining sentences is not optimal either. I now fixed it to go through all the input sentences and to return true if any of the sentences are alliterative.

Does this make sense?
Thanks again!

Hello @mille-s,
thanks for your feedback! I have added a few more lines in the README to discuss alliterations and their use. Please see 9940840. Would you like me to expand on it?
Thanks again!

Ahoy! Although arguably ameliorating the aforementioned ails, your changes created certain contrasting concerns:

if the criterion for alliterativity is for any k words to start with the first phoneme, won't a lot of long sentences just satisfy this by accident? For example, if a sentence starts with "The" and includes two other "the"s later, wouldn't that count? This doesn't seem like it actually checks for alliteration; I think the alliterative words do have to be close together. If you agree, you should rethink the rule. As an example, a criterion I might choose would be to take two arguments, min_alliteration_length and allowable_offwords, and then check if a sentence contains any long run (not necessarily starting with the first word) of min_alliteration_length alliterative words, allowing allowable_offwords offwords breaking up the run. For example, the sentence Look, guys: Peter Piper picked a peck of pickled peppers would satisfy min_alliteration_length=6 with allowable_offwords=2 (i.e. "a" and "of"). This criterion seems like it gets much closer to what the typical reader would actually call an alliterative sentence. Does that make sense?
the header "Why is it a challenge?" doesn't seem right; I'd say something like "Why is this filter important?" instead
typo in the README: "will they not be removed"

I think checking for a single alliterative sentence makes sense.

@ahoimarie thank for the details, I agree it could be used in a generation setting to see if a model manages to create alliterations, although I suspect that the subpopulations with alliterations in the datasets we are using will be extremely small. But with other (more literary) datasets that could be nice.

Hello! Hopefully having handled your handy help here, I imagine it indeed improved its impact.

Instead of checking the first phoneme of the sentence, I now use a rolling window of size min_alliteration_length+allowable_offwords to check if it contains one phoneme of at least the frequency min_alliteration_length in it. If the sentence is shorter than min_alliteration_length+allowable_offwords, the window reduces to min_alliteration_length.
Agreed, and changed.
Yes, thanks!

Thanks! Thorough thoughtful things!
The thing is, the theme of this thrilling thread thrives without thumbing through a thick thesaurus.

Amazing! Apt augmentations, all. Two tiny things:

I think "If the windowlen is smaller than the length of the data" in your docstring is meaning-reversed
Is allowable_offwords a parameter the user can specify, or is it always 2? It'd be better if it could be chosen

After the aforementioned alterations are achieved, I'll animatedly accept.

Awesome as always. Appreciated!

Impressive inspection! I immediately edited it.
allowed_offwords is indeed a parameter the user can specify. For example print(Alliteration(stopwords = False, min_alliteration_length=5, allowed_offwords=3).filter("Illuminating illustration of this inane but interesting instruction.")) will return True but calling it with allowed_offwords=2 won't.

Any additional amendments?

Ja, I'm happy! Great filter; every doubt's crushed. Bravo! Accept.

All looks good. Please fix the makefile and I am happy to merge :)

The makefile still shows in the tracking as deleted.

Hi @kaustubhdhole, sorry for the delay, I have been on sick leave because of an injury.
I've added the Makefile again -- does it work now or shall I create a new PR?

@ahoimarie I missed this message somehow. Please create a separate PR and link this PR in the comment.

Ensure that when you click "Files Changed", the makefile remains untouched.

@kaustubhdhole I removed the makefile with this little trick mentioned on stackoverflow, as creating a separate PR kept failing. But this should solve it too, shouldn't it?

authors: ahoimarie james-simon kaustubhdhole mille-s rteehas

repo: GEM-benchmark/NL-Augmenter


text:
Add htop to gdp-dev packagegroup

[GDP-436] Add htop to GDP Image

Builds ok for me on qemu. Nice to have - though might you want to leave it out so that it's available as an adding example in a future hands on?

Looks good. but i'll test today on raspberrypi3.

@RobertAJMarshall I think 6 months is too far away to consider that, I'm sure another example could be produced for then etc :)

This still needs +- 1

Sorry. I didn't test yet. I'll test soon. :)

I works fine on rpi3.

It works fine on rpi3.

authors: RobertAJMarshall chbae locust2001 tom--pollard

repo: GENIVI/meta-genivi-dev


text:
Updated community support PR

Hi everyone,
This is an updated 0-diff structural PR for changes that make MAPL buildable in external projects like GCHPctm (replacing #29, and #31). This PR make it possible for external project to use ESMA_cmake without modification, while preserving ESMA_cmake's existing functionality. Note that currently external projects that use MAPL have to implement equivalent functionality to use MAPL's build system.
The problem is that projects that depend on MAPL have to include(esma.cmake) to get the macros MAPL and its supporting infrastructure use in their CMakeLists, but include(esma.cmake) relies on FindBaselibs.cmake which assumes your environment was set up with ESMA-Baselibs (there are hardcoded paths to places where Baselibs installs things).
This problem is solvable though because one of the things CMake is best at is resolving dependencies through find_package() modules.
The feature of this PR are:

Dependencies are resolved with find_package() calls
The "requiredness" of dependencies can be modified from super-projects
Transitive usage requirements control compiler options, definitions, and link libraries.

A target called Baselibs is used to control "GMAO-wide" compiler options, definitions, link libraries, include directories, etc. (you can think of the Baselibs target as a property sheet).
This replaces the current method of using global functions like add_definition() and include_libraries() which is widely regarded as an anti-pattern in CMake.

As for testing, we test GCHPctm's build in >10 environments with combinations of CentOS, Ubuntu, Intel, GCC, OpenMPI, MVAPICH, MPICH, and Intel MPI. I haven't been able to test GEOSgcm's build, but I'm happy to help with any problems that are encountered.
Related issues: #50, #30, #28, #16
Accompanying PRs
Because of that 3rd point (above) there are some minor changes to MAPL and GMAO_Shared that are necessary (mainly "linking" the Baselibs target to compiler definitions, options, link libraries, etc. using its transitive usage requirements ). Below are the PRs that accompany this one. Note that these are also 0-diff structural.

https://github.com/GEOS-ESM/MAPL/pull/226
https://github.com/GEOS-ESM/GMAO_Shared/pull/74

Thanks! Let me know if there's anything I can do to make merging this PR easier!
Liam

@LiamBindle I'm mostly fine with this, but am debating with myself the merits of lumping all of baselibs into one pseudo target.    Isn' the long term strategy to have a find_package() fore each dependency and list the dependencies explicitly at each level.   (Only those that are directly used.  Implicit dependencies are through transitivity, of course.)
Please see my comments/questions in the PRs.

@tclune Sorry, I accidentally closed this PR while cleaning up branches on geoschem/ESMA_cmake.

I'm mostly fine with this, but am debating with myself the merits of lumping all of baselibs into one pseudo target.

Yeah, I'd agree—a single target isn't ideal. Perhaps a separating a base target (for GMAO-wide build properties e.g. compiler options which are set here) from the monolithic Baselibs target (whose transitive properties are inherited here) would be better?

Isn' the long term strategy to have a find_package() fore each dependency and list the dependencies explicitly at each level.

I think so. My thinking with this PR is the first step towards that goal though. I was worried breaking it up too much would lead to a diff that was too big (FindBaselibs.cmake would be removed and there would be more diffs to other GEOS-ESM repos). Maybe that's not right though? I guess axing Baselibs all together and then linking the individual dependency targets where I'm currently linking Baselibs would do the trick. What do you think?
This PR is aimed at being a minimal diff implementation of the functionality necessary for external projects to use ESMA_cmake (abstracting dependency resolution to find_package() calls, and controlling the scope of GMAO-wide build options through a base target) while still working for everything that's built on top of ESMA_cmake.

@tclune @mathomp4 Thanks for the comments. Below is a list of updates I noted

[X] Remove legacy FLAP variables (24097922a81f0a8e1d03ce658c6a8f0b4eedcfc1)
[ ] Readd OS X build logic
[ ] Remove the Baselibs interface target

Replace with an interface target with build properties (compiler options, and preprocessor definitions)
Explicitly link individual libraries

[X] Use NATIVE_COMMAND in separate_arguments() (cca5310e74780f5efea8988cc8c5d6ed436a354c)
[ ] Add cached variable controlling ESMF library that gets linked

Did I miss anything?
For the new interface target with build properties, I was thinking of something like
add_library(GEOS_BuildProperties INTERFACE)
target_compile_options(GEOS_BuildProperties INTERFACE
	$<$<COMPILE_LANGUAGE:Fortran>:
		$<$<OR:$<CONFIG:Release>,$<CONFIG:RelWithDebInfo>,$<CONFIG:MinSizeRel>>:${GEOS_Fortran_FLAGS_RELEASE}>
  		$<$<CONFIG:Debug>:${GEOS_Fortran_FLAGS_DEBUG}>
	>
	""
  )
target_compile_definitions(GEOS_BuildProperties INTERFACE
  HAS_NETCDF4
  HAS_NETCDF3
  H5_HAVE_PARALLEL
  NETCDF_NEED_NF_MPIIO
  HAS_NETCDF3
  )

And then this GEOS_BuildProperties gets "linked" into all the leaves in the dependency tree with the INTERFACE keyword? (INTERFACE keyword means the build properties will propagate up through the tree)
Let me know what you think. I'll make these changes and let you know when it's ready for review again.

@mathomp4 I just pushed some commits with the updates mentioned above.
Note that libraries in MAPL, GMAO_Shared, etc. have to "link" GEOS_BuildProperties to get the GEOS compiler options and definitions (this PR only provides the targets to be linked against). They also have to link their own external dependencies (e.g. MPI::MPI_Fortran, MPI::MPI_CXX, ESMF, OpenMP::OpenMP_Fortran, etc.; again this PR only provides the targets to be linked against).
Let me know what you think.

Friendly bump to keep this PR from getting lost at the bottom of the GH notification stack.
@mathomp4 @tclune

@LiamBindle Not to worry.   It is not forgotten so much as I fear limitations in my cmake knowledge.   I was hoping to have some quiet time this weekend to properly assess.  But managed to distract myself with other things.
I'll definitely jump on it by tomorrow morning.   Coronamuting is mostly freeing my time other than all the playing with MS Teams.  (NASA's approach to slack.)

@tclune Sounds good, no worries. Let me know if there's anything I can do.

@mathomp4 I've reminded myself of the various issues raised in this thread, and am fine performing the merge.   The caveat is that this has been tested with a build of GEOS.   Let me know if you have or can do quickly.  Otherwise, I can take that on (just less efficiently).

@mathomp4 I've reminded myself of the various issues raised in this thread, and am fine performing the merge. The caveat is that this has been tested with a build of GEOS. Let me know if you have or can do quickly. Otherwise, I can take that on (just less efficiently).

Something seems off. I just took our current GEOSgcm, merged in the branches from @LiamBindle for ESMA_cmake and MAPL. Note that since Liam's bits in MAPL went into release/2.0.0, I did another merge into current master.
The cmake step looks okay, but the model is not happy. It dies instantly with make install in CFIO:
Scanning dependencies of target MAPL_cfio_r4
[  0%] Building Fortran object src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/ESMF_CFIOBaseMod.f.o
/discover/swdev/mathomp4/Models/GEOSgcm-LiamBaselibs/GEOSgcm/src/Shared/@MAPL/MAPL_cfio/ESMF_CFIOBaseMod.f(3): error #5102: Cannot open include file 'netcdf.inc'
       include "netcdf.inc"
---------------^
compilation aborted for /discover/swdev/mathomp4/Models/GEOSgcm-LiamBaselibs/GEOSgcm/src/Shared/@MAPL/MAPL_cfio/ESMF_CFIOBaseMod.f (code 1)
src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/build.make:62: recipe for target 'src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/ESMF_CFIOBaseMod.f.o' failed
make[2]: *** [src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/ESMF_CFIOBaseMod.f.o] Error 1
CMakeFiles/Makefile2:1244: recipe for target 'src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/all' failed
make[1]: *** [src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

@LiamBindle Do we need to explicitly add INC_NETCDF? You seemed to remove them in your MAPL branch. Well, you removed:
target_include_directories (${lib} PUBLIC ${INC_NETCDF} ${INC_ESMF})

@mathomp4 Yeah you'll have to add target_xxxx() calls to satisfy all libraries dependencies. This is what I was referring to here

Note that targets in other GEOS-ESM repos like MAPL, GMAO_Shared, etc. are going to have to "link" GEOS_BuildProperties to get the GEOS compiler options and definitions (this PR only provides the targets to be linked against). They are also going to have to link their own external dependencies (e.g. MPI::MPI_Fortran, MPI::MPI_CXX, ESMF, OpenMP::OpenMP_Fortran, etc.; again this PR only provides the targets to be linked against). This could be done transitively (with the PUBLIC keyword) or explicitly (with the PRIVATE keyword) depending on which paradigm you guys think is best.

So for most targets in GEOS you'll be able to fill their build properties (compiler options, preprocessor definitions, include directories, link libraries, etc.) by simple target_link_libraries() calls. For example if target libA depends on ESMF (note that FindESMF.cmake imports the target ESMF) you can resolve all of ESMF's usage requirements (include directories, link libraries, etc.) by doing
target_link_libraries(libA PUBLIC ESMF)

This is a nice and clean way of bundling and passing on dependencies' usage requirements to higher-level targets. Using the PUBLIC keyword will mean targets that link libA automatically get all of ESMF's usage requirements too, and using the PRIVATE keyword will mean target that link libA also have to explicitly have the ESMF target in their list of link libraries.
Note that the GEOS_BuildProperties target is the target that bundles GEOS compiler options and definitions. This is why I usually put the work "link" in quotes--because the CMake terminology unfortunately used the word "link" even though it's really more of a dependency declaration.
Below is a list of targets that are imported by the find package calls in FindBaselibs.cmake and esma.cmake:

MPI::MPI_C, MPI::MPI_CXX, MPI::MPI_Fortran
ESMF
OpenMP::OpenMP_C, OpenMP::OpenMP_CXX, OpenMP::OpenMP_Fortran
FLAP::FLAP
fargparse, gFTL, and gFTL-shared are all config module so they import targets, but I'm not sure what the name of those targets are off the top of my head
Others I missed?

Unfortunately, the FindNetCDF.cmake module provided my ecbuild doesn't supply an imported target. Instead, you'll have to resort to calls like target_include_directories(${lib} PUBLIC ${NETCDF_INCLUDE_DIR}). The list of NetCDF variables are documented here but in summary:

${NETCDF_INCLUDE_DIRS}
${NETCDF_CXX_LIBRARIES} or ${NETCDF_F90_LIBRARIES} or ${NETCDF_LIBRARIES}

So in the specific case you asked about, you would add
# ESMF depends on NetCDFs, so "linking" ESMF fill also fills NetCDF include
#  dirs, link libraries etc. in ${lib}
target_link_libraries(${lib} PUBLIC ESMF)

The following lines are then redundent but optional
target_link_libraries(${lib} PUBLIC ${NETCDF_F90_LIBRARIES})       # redundant but ok
target_include_directories(${lib} PUBLIC ${NETCDF_INCLUDE_DIRS})   # redundant but ok

Does that make sense?

@LiamBindle I see. I was just confused as you removed the netcdf include bits from MAPL_cfio, so I figured the ESMF target would satisfy it. How did it build for you?

As a gentle reminder to myself and Matt:    We want to explicitly list all direct dependencies of a layer.   So even if target A gets netcdf via ESMF,  we want to put it in the target_link_libraries if A directly calls netcdf.  (And not otherwise.)

@mathomp4 Oh yeah, you're right! The ESMF target is missing NETCDF_INCLUDE_DIRS. I just pushed a commit which adds ${NETCDF_INCLUDE_DIRS} to the ESMF target's interface include directories.

As a gentle reminder to myself and Matt: We want to explicitly list all direct dependencies of a layer. So even if target A gets netcdf via ESMF, we want to put it in the target_link_libraries if A directly calls netcdf. (And not otherwise.)

Sounds good! You should use the PRIVATE keyword then (not PUBLIC) in target_link_libraries() then (and other calls like target_include_directories()). Also, every GEOS target should explicitly link GEOS_BuildProperties too then.

Good point about PRIVATE - I've been a bit sloppy about my thinking on that.    One side of brain reasoning as above, and the other thinking "make it PUBLIC so that components get access via transitivity".
There may be some caveats down the road.   E.g., NAG does some interesting transitivity things in their .mod files that CMake developers would not believe me when I reported.    So we may need to make .mod files (include_directories) PUBLIC  even when the dependence is only indirect.    Of course, we may never get to the point that we can actually build the model with NAG.    (Won't be surprised if Flang (F18) does something similar with their .mod files though.)

Next error, which might be due to not spreading the changes everywhere:
[  1%] Building Fortran object src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/AbstractDataReference.F90.o
AbstractDataReference.F90(468): #error: can't find include file: templates/vector.inc
src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/build.make:842: recipe for target 'src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/AbstractDataReference.F90.o' failed
make[2]: *** [src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/AbstractDataReference.F90.o] Error 1
CMakeFiles/Makefile2:1414: recipe for target 'src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/all' failed
make[1]: *** [src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

Yes - this means there is a missing dependency on gFTL that was being inappropriately obtained via transitivity of a PUBLIC in the past.
OTOH, this is pFIO which is pretty much at the bottom of the food chain.  I'd have thought it would have the explicit mention.

@LiamBindle We haven't forgotten this. I'm going to do some tests today. Due to all the changes we've made recently there are conflicts, but I've made a first try at merging/resolving those with develop in the branch: feature/mathomp4/liam-baselibs-develop-merge
I'll keep you up to date.

And we have our first error on CMake step:
CMake Error in src/Shared/@MAPL/MAPL/CMakeLists.txt:
  Target "MAPL" INTERFACE_INCLUDE_DIRECTORIES property contains path:

    "/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-LiamBaselibs/GEOSgcm/src/Shared/@MAPL/MAPL/"

  which is prefixed in the source directory.

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

I was able to sidestep the issue Matt encountered by commenting out an INCLUDE for a completely unrelated directory.
But then got lots of shell errors:
...
/bin/sh: unused: command not found
/bin/sh: -init=snan,arrays: command not found
/bin/sh: -save-temps: command not found
/bin/sh: -traceback: command not found
/bin/sh: SHELL:-assume: command not found
/bin/sh: -fpe0: command not found
/bin/sh: -fp-model: command not found

Apparently due to constructs like:
set (BYTERECLEN "\"SHELL:-assume byterecl\"")

Reverting Intel.cmake to make progress.

@LiamBindle The expedient solution might be to teach you how to build our GCM and let you trouble shoot.    But I'll give it a bit more effort before punting.

The next issue is that GEOS_BuildProperties is not propagating as expected.  E.g. , in MAPL_Base, I have updated the link to be:
target_link_libraries (${this} PUBLIC ${GEOS_BuildProperties} ${ESMF_LIBRARIES} ${MPI_Fortran_LIBRARIES})

(And ... I know the other 2 elements are now obsolete, but one thing at a time.)
I still find that H5_HAVE_PARALLEL is not being passed to the compiler and thus breaking the build.

The next issue is that GEOS_BuildProperties is not propagating as expected. E.g. , in MAPL_Base, I have updated the link to be:
target_link_libraries (${this} PUBLIC ${GEOS_BuildProperties} ${ESMF_LIBRARIES} ${MPI_Fortran_LIBRARIES})

(And ... I know the other 2 elements are now obsolete, but one thing at a time.)
I still find that H5_HAVE_PARALLEL is not being passed to the compiler and thus breaking the build.

My bad.  I had put "${}" around GEOS_...

I've resolved the "SHELL" issue.   Some of the DEBUG flags were not being guarded.

@LiamBindle Unfortunately this SHELL issue propagates into lots of other CMakeLists.txt files where we do things like:
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

Which now does not evaluate cleanly.     Why was this duplicate arguments issue not plaguing us before?

@tclune @mathomp4 Thanks for the updates. Sorry about this turning into a bit of a project.
I'm confused why the missing "SHELL:" prefixes didn't cause problems for you guys before as well. When we omit them we get errors because a lot of first words of multi-word arguments get removed. And currently, we aren't able to build GCHPctm in the Debug build type because these "SHELL:" prefixes haven't been added to all the multi-word debug arguments yet.
Perhaps the reason it didn't cause issues for you before is because the compiler flags were actually being set as one big string, rather than a list of strings. For example, this
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

Appends the string "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}" to rsg3_vinterp.F's COMPILE_FLAGS property—so rsg3_vinterp.F's COMPILE_FLAGS property is actually just one big string. And perhaps this is registered by CMake's de-duplicate filter as a single long argument (and hence, the de-duplicator doesn't do anything).
What's the problem with how
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

is being evaluated? Can separate_arguments() property parse and split rsg3_vinterp.F's COMPILE_FLAGS property?

Also, note that the other way to do what you did above would be
set_property(SOURCE rsg3_vinterp.F APPEND PROPERTY COMPILE_FLAGS ${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE})

which would append ${FREAL8},${BYTERECLEN},${EXTENDED_SOURCE} as elements to rsg3_vinterp.F's COMPILE_FLAGS property (which is a list here).

Also, note that the other way to do what you did above would be
set_property(SOURCE rsg3_vinterp.F APPEND PROPERTY COMPILE_FLAGS ${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE})

which would append ${FREAL8},${BYTERECLEN},${EXTENDED_SOURCE} as elements to rsg3_vinterp.F's COMPILE_FLAGS property (which is a list here).

Ok - I'll try that.   At least it is cleaner than the kludge I came up with which was to have 2 vars for each such flag.

Spoke too soon.   The flags are passed through an ecbuild macro ...

OK - I was able to produce GEOSgcm.x which is a useful milestone.  The changes were few but generally undesirable.  Will discuss at the telecon this afternoon.
And ... it looks like something is wrong with the linkage for the libraries produced with F2PY.   Unfortunately the error message is short and useless.   Best guess is that it is related to the other wonkiness with NetCDF.

@LiamBindle @tclune The f2py business will be quite twitchy and might need help from both of you.
Essentially f2py is not good at...is not good. We already have a very fragile system for it. What I do right now is like this:
if (F2PY_FOUND)
   if (precision STREQUAL "r4")
   add_f2py_module(GFIO_ SOURCES GFIO_py.F90
      DESTINATION lib/Python
      ONLY gfioopen gfiocreate gfiodiminquire gfioinquire
      gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime
      gfiointerpxy gfiointerpnn gfiocoordnn gfioclose
      LIBRARIES GMAO_gfio_r4 ${NETCDF_LIBRARIES}
      INCLUDEDIRS ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/lib ${BASEDIR}/lib ${include_${this}} ${INC_NETCDF}
      USE_MPI
      )
   add_dependencies(GFIO_ ${this})
   endif ()
endif (F2PY_FOUND)

The main issue is I need something that looks like ${NETCDF_LIBRARIES} looked like before and what ${INC_NETCDF} looked like before. Staring at the file in ecbuild, it looks like we should still have ${NETCDF_LIBRARIES}, but ${INC_NETCDF} is now ${NETCDF_INCLUDE_DIRS}

Okay. f2py is not due to the include bits. It's a library issue. Before, f2py was seeing the -lfoo style:
-L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/src/Shared/@GMAO_Shared/GMAO_gfio_r4 -L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/lib -L/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib -L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/include/GMAO_gfio_r4 -L/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/include/netcdf -lGMAO_gfio_r4 -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lmfhdf -ldf -lsz -ljpeg -lgpfs -ldl -lcurl -lssl -lcrypto -lz -lm -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib -lmpifort -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib/release -lmpi -L/usr/lib64 -ldl -L/usr/lib64 -lrt -L/usr/lib64 -lpthread only: gfioopen gfiocreate gfiodiminquire gfioinquire gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime gfiointerpxy gfiointerpnn gfiocoordnn gfioclose

Now though, it's seeing full path static libraries:
-l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libnetcdf.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libnetcdff.a -loptimized -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libnetcdf.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libnetcdff.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libhdf5.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libsz.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libz.so -l/usr/lib64/libdl.so -l/usr/lib64/libm.so -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libhdf5.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libsz.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_18.0.5.274-intelmpi_19.1.0.166/Linux/lib/libz.so -l/usr/lib64/libdl.so -l/usr/lib64/libm.so -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib -lmpifort -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib/release -lmpi -L/usr/lib64 -ldl -L/usr/lib64 -lrt -L/usr/lib64 -lpthread only: gfioopen gfiocreate gfiodiminquire gfioinquire gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime gfiointerpxy gfiointerpnn gfiocoordnn gfioclose

I think I have a first good shot at fixing the f2py biz.

@mathomp4
I didn't realize this before, but it seems the deduplicator might only affect properties (i.e. not variables like CMake_Fortran_FLAGS; only the COMPILE_FLAGS property instead). IIUC the variables like CMake_Fortran_FLAGS are initialized by the FFLAGS environment variable and the similar flags for other languages (ref). IIUC the deduplicator is meant to prevent COMPILE_FLAGS from accumulating duplicate properties, and the SHELL: prefix was added to prevent the deduplicator from splitting multiword arguments (ref). I'm reading a bit between the lines here, but I think my interpretation is consistent with the documentation because add_compile_options' documentation mentions the deduplicator, whereas the CMAKE_<LANG>_FLAGS documentation doesn't.
Is there a reason the CMAKE_<LANG>_FLAGS variables have to be used? If not, you could prevent these variables from taking on their default values (i.e. CFLAGS, CXXFLAGS, FFLAGS) by setting them to an empty string. Doing this in your top-level directory would set it empty for the entire tree. This way, only the compile flags in targets' properties should be used.
If you guys would prefer to continue using the CMAKE_<LANG>_FLAGS variables, the goal of this PR can still be accomplished. But, each repo would have to set CMAKE_<LANG>_FLAGS variables itself (i.e. ESMA_cmake shouldn't set CMake_Fortran_FLAGS). If this were the case, no SHELL: prefixes should be used.

I'm not sure if my explanation of how I think target properties could be used to set compiler options was clear, so here's a more detailed explanation.

Compiler flags in ESMA_cmake should be stored as lists (i.e. in the semicolon separated format) with "SHELL:xxxx yyyy wrapping multiword arguments
In the top level directory, CMAKE_Fortran_FLAGS should be initialized to "" to prevent CMake from using the environment's FFLAGS
Compiler flags are specified with the target_compile_options() like so (note that common_Fortran_flags is a list; below it's expanded as multiple arguments (i.e. it isn't wrapped in "")

target_compile_options(targetA  PUBLIC|PRIVATE ${common_Fortran_flags})

Does that make sense? Let me know if I can clarify anything.

@mathomp4 @tclune I just learned this, and I think it might be of interest to you two. There's a generator expression, $<LINK_ONLY:...>, which can be used in target_link_libraries() calls to link a target but not use it's transitive usage requirements (ref). I just learned about this and thought it might be of interest to you guys because it allows for finer control over transitive requirements.

Thanks.   I recently went a bit deeper in this direction to enable a situation where my tests are linked with a mock library while the app itself is linked to a real library.   Cant's say I find the syntax intuitive though.
On a related front, I've had to start making more target_include_directories() use PUBLIC.   The latest Intel compiler is now chaining some interface information through secondary .mod files.   E.g., if package A produces a.mod, and Package B uses a.mod and produces b.mod, then if Package C uses b.mod it may need the include dirs for A.

Random query for @LiamBindle : is it possible this is now taken care of in MAPL/ESMA_cmake? All the changes and stuff we made for UFS/NOAA seemed to be aimed at "UFS doesn't use Baselibs".

@mathomp4 Yeah, I suspect so. I bet a lot of that work fulfills what we need---I haven't had a chance to rebase and try out all the new work, but coincidentally I am hoping to do that this afternoon.
Sorry, I didn't realize this PR was still open. I'll close it.
If new things arise, I will open new issues/PR, but I think the contents of this PR are outdated/redundant now.

@LiamBindle Sounds good. Though realize any "no-Baselibs" changes will now also need to work with UFS/NOAA. The "fun" of a multi-organization library! But we'll get there. Thanks for the patience

authors: LiamBindle mathomp4 tclune


text:
Update GEOSadas to be in line with GEOSgcm v10.19.3

In the time since #103 was made, the GCM updated to v10.19.3. This PR would update the GEOSadas as well. The updates are:
GMAO_Shared v1.4.6
MAPL v2.8.0
GEOSgcm_GridComp v1.12.4
fvdycore v1.1.7
GEOSgcm_App v1.5.3
Note that this is potentially non-zero-diff. Per the GEOSgcm release notes:

Potential Non-0-diff Change:

Upgrade to MAPL v2.8.0. For the MERRA2 GOCART Emissions, all testing shows it is zero-diff. But for the Ops GOCART Emissions, it there are very small roundoff differences. The results are non-zero-diff due to a bug fix (to a race condition) in this version of MAPL on how grids are handled.

@bena-nasa can explain the MAPL bug fix better than I can if needed.

Yes, as Matt said with the ops emissions there was a small non-zero diff. The issue was that I had previously made a change to ExtData that caused the order the variable to be provided get processed to change. Well it turned out there were two emissions files that were identified as having "equal" lat-lon grids but on close inspection they have ever so slightly different lons and lats (i'm talking very small differences). Well, which ever file got opened first, that lat-lon grid won our grid manger so when the next file was opened it saw, I've already created a grid with that factory. So depending on which was opened first you would get slightly different lons and lats. So this change I made caused this order of these to flip during processing and indeed just change the order these two entries were in the ExtData file would change which got used. So when we realized this we tightened up the lat-lon grid factory so inconsistencies would not happen like this again.

Call me crazy ... but I can no longer find the repo for fvdycore! What happened to it? I am trying to see the diff between what I have in develop (geos/v1.1.6) and what you have here ... but I can find the repo!

Call me crazy ... but I can no longer find the repo for fvdycore! What happened to it? I am trying to see the diff between what I have in develop (geos/v1.1.6) and what you have here ... but I can find the repo!

Ah yeah, that was one where the actual repo has a really different name than what GEOS called it. NOAA calls it "GFDL_atmos_cubed_sphere":
https://github.com/GEOS-ESM/GFDL_atmos_cubed_sphere
So the difference would be:
https://github.com/GEOS-ESM/GFDL_atmos_cubed_sphere/compare/geos/v1.1.6...GEOS-ESM:geos/v1.1.7
The reason for this was documented by @bena-nasa  here: https://github.com/GEOS-ESM/GFDL_atmos_cubed_sphere/pull/43

It's really odd how and why an optional variable needs to be ifdef'ed around it! Anyway, I will assume this is as the change claims - to be zero-diff. Thanks Matt.

Another odd event in which I get:
git checkout v1.1.7
error: pathspec 'v1.1.7' did not match any file(s) known to git
What's the trick here?

Another odd event in which I get:
git checkout v1.1.7
error: pathspec 'v1.1.7' did not match any file(s) known to git
What's the trick here?

The tag is actuall geos/v1.1.7. We called it that just in case GFDL had an "official" tag of v1.1.7 (since our code isn't exactly theirs).

@rtodling   The summary at the top definitely states that the differences are not always 0-diff.  Probably should have made the statements in the reverse order to minimize communication.   And we should have noticed that your Aug. 3rd comment suggest you had missed the non-zero diff aspect.

Now included in GEOSadas-5_29_3:
MAPL v2.8.0
GEOSgcm_GridComp v1.12.4
fvdycore v1.1.7
As for Shared ... I need feature/rtodling/cascase for the DAS; I think the DAS supersede the version pointed to here: v1.4.6
As for GEOSgcm_App: The DAS uses what's under: feature/rtodling/v1_5_4_onlXoffl_flags which (as far as I can tell) supersedes v1.5.3

@rtodling Indeed, this is probably out of date. I'll close this as your branches are probably above this.

authors: bena-nasa mathomp4 rtodling tclune

repo: GEOS-ESM/GEOSadas


text:
Timer Initialize pair issue with MAPL 2.6.4 using ifort19 in GCHP

I am running GCHP using MAPL v2.6.4 and am getting a run-time error when using ifort19.0.5 with OpenMPI 4.0.2. Strangely I have not encountered any run issues when using GNU fortran compilers.
The traceback is as follows:
pe=00000 FAIL at line=00168    BaseProfiler.F90                         <Timer Initialize likely does not find its pair>
pe=00000 FAIL at line=01851    MAPL_Generic.F90                         <status=1>
pe=00000 FAIL at line=00629    MAPL_CapGridComp.F90                     <status=1>
pe=00000 FAIL at line=00931    MAPL_CapGridComp.F90                     <status=1>
pe=00000 FAIL at line=00245    MAPL_Cap.F90                             <status=1>
pe=00000 FAIL at line=00211    MAPL_Cap.F90                             <status=1>
pe=00000 FAIL at line=00154    MAPL_Cap.F90                             <status=1>
pe=00000 FAIL at line=00129    MAPL_Cap.F90                             <status=1>
pe=00000 FAIL at line=00030    GCHPctm.F90                              <status=1>

The error is caught in subroutine stop_name (see code here).
Have you seen this type of error before and do you know a fix?

@lizziel You are stumping @tclune and myself. But it is interesting that it's hitting the same code as we are looking at in #762.
Is this reproducible for you? We tried looking through the call stack and we don't see any compiler dependence throughout it!

Yes this is reproducible. I rebuilt from scratch with the same libraries and got exactly the same error. I then tried with ifort 18.0.5. That gives me a different error, specifically when loading the logging yaml file here. Are the libraries I am using all expected to be compatible with ifort18?
forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types
Image              PC                Routine            Line        Source
gchp               0000000002DE89C6  Unknown               Unknown  Unknown
libMAPL.shared.so  00002B04BD5AB957  fy_lexer_mp_pop_t     Unknown  Unknown
libMAPL.shared.so  00002B04BD5A9857  fy_lexer_mp_get_t     Unknown  Unknown
libMAPL.shared.so  00002B04BD574C29  fy_parser_mp_top_     Unknown  Unknown
libMAPL.shared.so  00002B04BD57294E  fy_parser_mp_load     Unknown  Unknown
libMAPL.shared.so  00002B04BD4D8431  pfl_loggermanager     Unknown  Unknown
gchp               00000000018F5C16  mapl_applications         108  ApplicationSupport.F90
gchp               00000000018F5F0C  mapl_applications          39  ApplicationSupport.F90
gchp               0000000000F4D61A  mapl_capmod_mp_ne         106  MAPL_Cap.F90
gchp               000000000053A60C  MAIN__                     29  GCHPctm.F90
gchp               00000000005393DE  Unknown               Unknown  Unknown
libc-2.17.so       00002B04C0651555  __libc_start_main     Unknown  Unknown
gchp               00000000005392E9  Unknown               Unknown  Unknown

For the ifort18 run I then used the logger work-around I used for pFlogger issue 54 (comment out setting logging file in cap_options). Doing that fixes the new problem, but the run then crashes. The traceback points to the same source as the issue with ifort19. For ifort 18 the symptom is a seg fault rather than graceful fail in BaseProfiler.F90 with ifort19.
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
gchp               0000000002E07D6D  Unknown               Unknown  Unknown
libpthread-2.17.s  00002B069F01F630  Unknown               Unknown  Unknown
libMAPL.profiler.  00002B069BC91DAE  mapl_baseprofiler     Unknown  Unknown
gchp               0000000001577312  mapl_genericmod_m        1851  MAPL_Generic.F90

I have been doing RELEASE for all my builds. I'll try DEBUG and see if that gives more information.

Thanks @tclune. I'll try that and see if it fixes it. In the meantime yesterday I switched MAPL to v2.6.3 and that resolved the problem. I still get the LHS and RHS of an assignment statement have incompatible types error when using ifort18 however. Have you tested with ifort18, or is the minimum expected to be 2019?

I have not used 18 in a while (Intel makes it hard to sustain older compilers across the mandatory OS X upgrades on my laptop).       That particular error sounds familiar though, and I don't think I ever came up with a workaround.   If you can remind me where you are getting that error message, I can take a fresh look and suggest some possible variants.

Here is the traceback for the ifort18 issue in MAPL v2.6.3 and v2.6.4. The last version used in GCHP was v2.2.7 so this could have come in any of the versions since.
forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types
Image              PC                Routine            Line        Source
gchp               0000000002DE89C6  Unknown               Unknown  Unknown
libMAPL.shared.so  00002B04BD5AB957  fy_lexer_mp_pop_t     Unknown  Unknown
libMAPL.shared.so  00002B04BD5A9857  fy_lexer_mp_get_t     Unknown  Unknown
libMAPL.shared.so  00002B04BD574C29  fy_parser_mp_top_     Unknown  Unknown
libMAPL.shared.so  00002B04BD57294E  fy_parser_mp_load     Unknown  Unknown
libMAPL.shared.so  00002B04BD4D8431  pfl_loggermanager     Unknown  Unknown
gchp               00000000018F5C16  mapl_applications         108  ApplicationSupport.F90
gchp               00000000018F5F0C  mapl_applications          39  ApplicationSupport.F90
gchp               0000000000F4D61A  mapl_capmod_mp_ne         106  MAPL_Cap.F90
gchp               000000000053A60C  MAIN__                     29  GCHPctm.F90
gchp               00000000005393DE  Unknown               Unknown  Unknown
libc-2.17.so       00002B04C0651555  __libc_start_main     Unknown  Unknown
gchp               00000000005392E9  Unknown               Unknown  Unknown

Here's a quick link to the location in ApplicationSupport.F90.

And this is with the default logging.yaml file?   (Sounding more and more familiar.)

Not quite default. It the file you gave to Seb a while back, although I had to change propagate from 0 to false: https://github.com/geoschem/geos-chem/blob/dev/run/GCHP/logging.yaml.
My understanding is the only difference from the one you use in GEOSgcm is this.

I was able to parse your yaml file with a standalone driver using the latest yaFyaml (main branch) and ifort 18.0.5 on Linux.
There is a separate problem with this yaFyaml because I accidentally made it require pFUnit which was not my intent.   I'll to a hotfix for this shortly.
The conclusion is that I either entered a workaround for the problem you described, or it is a bit harder to reproduce.

Could not find anything in the commit history.  Indeed the relevant file has not been touched in 7 months.   But Liam already at an unrelated PR that fixes the pFUnit issue.   So I'll roll out a new release and request that you try it in your code.

Thanks @tclune. I'll look for that release.

Ah, just saw it's already released. I'll try it and let you know how it goes.

Unfortunately that doesn't fix it. Would changing anything in logging.yaml provide more information? Compiling with -DCMAKE_BUILD_TYPE=Debug does not.

I only use -DCMAKE_BUILD_TYPE=Debug in my own work.
I'm going to attach
reproducer.tar.gz
my reproducer.  It would be interesting if you could try it in your environment?   You'll  need to copy your yaml file into the build dir and run driver.x.

I haven't gotten that to work yet. We do not use yaFyaml as an external library and I'm taking a break from messing around with cmake. But I did isolate the issue to this line: https://github.com/geoschem/yaFyaml/blob/7f16059ebc95083dd1e77954296798c745f9a287/src/Lexer.F90#L316

Yes - definitely a compiler bug, but I can't attempt a workaround unless I can reproduce it.
You don't have to use cmake.  You could just add my small program within the project that is using yafyaml or even make it a subroutine that gets called from the top of an existing program.  Just want to see if it is a difference in your environment vs something to do with the state of the code when it gets down in there.

Gotcha. I added this to the very top of main GCHPctm.F90.
   type (Parser)  :: p
   type (Configuration) :: cfg
   p = Parser('Core')
   cfg = p%load(FileStream('logging.yaml'))

This also trips the error, but with better traceback, although to the line I already figured out was the issue:
forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types
Image              PC                Routine            Line        Source
gchp               0000000008B38A36  Unknown               Unknown  Unknown
libMAPL.shared.so  00002B8D5EDE3324  fy_lexer_mp_pop_t         316  Lexer.F90
libMAPL.shared.so  00002B8D5EDDE2B0  fy_lexer_mp_get_t         183  Lexer.F90
libMAPL.shared.so  00002B8D5ED3E80B  fy_parser_mp_top_         107  Parser.F90
libMAPL.shared.so  00002B8D5ED3CDA2  Unknown               Unknown  Unknown
gchp               000000000053FF59  MAIN__                     32  GCHPctm.F90
gchp               000000000053BCDE  Unknown               Unknown  Unknown
libc-2.17.so       00002B8D62421555  __libc_start_main     Unknown  Unknown
gchp               000000000053BBE9  Unknown               Unknown  Unknown

I don't think I mentioned what libraries I'm using yet. Here they are in case it makes a difference.
    gFTL-Shared v1.2.0 (includes gFTL v1.3.1)
    pFlogger v1.5.0
    pFUnit v4.2.0
    yaFyaml v0.5.1
    ESMA_cmake v3.0.6
    ecbuild geos/v1.0.5

I found an Intel forum discussion on this error being encountered in ifort18 here.

Unfortunately, I cannot follow your ifort18 link.  I'm in a spiral where it keeps making me register.
The only versions of libraries that can possibly matter are gFTL and gFTL-shared.    I'll try again with the tags you mention for those when I get onto discover.

OK, I rebuilt using the specified versions of gFTL, gFTL-Shared and the latest yaFyaml with 18.0.5.  I was able to process your yaml file.
For now, the one obvious workaround to try is to replace the failing line with
allocate(token, source=tokens%at(1))

And if that does not work, let's try to limit the advanced syntax to see if that helps.  Replace the entire procedure with:
  function pop_token(this) result(token)
    class(AbstractToken), allocatable :: token
    class(Lexer), intent(inout) :: this

    class(AbstractToken), pointer :: p_token

    p_token => this%processed_tokens%at(1)
    token = p_token

  end function pop_token

No luck with either. I'm fine with requiring ifort19+ for Intel compilers unless you want to keep pursing this. The link should work unless the VPN you have is interfering.

OK - if you can move to 19 that would be best.    I hate inflicting compiler version creep on others.   These days I can more often workaround compiler defects, but still.   Currently the latest GFE stack works with both 19 and 21 (don't ask about Intel's numbering here).   GEOS uses 19 and I develop using 21.

Sounds good. At this point ifort18 is more than three years old (release Jan 2017) so it seems reasonable discontinue support. Especially when gfortran is an option.

authors: lizziel mathomp4 tclune

repo: GEOS-ESM/MAPL


text:
CMake installation issue: Most users just want vk_mem_alloc.h

I think this issue is worth bringing up since I've seen the same pattern in 2 places. When shipping the Vulkan SDK and with vcpgk.
NOTE: I believe Conan also doesn't use the default installation either (https://github.com/conan-io/conan-center-index/tree/master/recipes/vulkan-memory-allocator/all). But I'm not as familiar with Conan.
Problem: Most users just want vk_mem_alloc.h
Here is the current port code for vcpkg:
vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator
    REF a6bfc237255a6bac1513f7c1ebde6d8aed6b5191 #v3.0.1
    SHA512  14361ff201fd660c22b60de54c648ff20a2e2a7f65105f66853a9a4dbffbeca2ae42098dcb1528bb4e524639b92fa4ff27ebd3940c42ccfaf7c99c08bdd0d8ce
    HEAD_REF master
    PATCHES
        gcc13.patch # https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/commit/29d492b60c84ca784ea0943efc7d2e6e0f3bdaac
)

file(COPY "${SOURCE_PATH}/include/vk_mem_alloc.h" DESTINATION "${CURRENT_PACKAGES_DIR}/include")

file(COPY "${CMAKE_CURRENT_LIST_DIR}/unofficial-vulkan-memory-allocator-config.cmake" DESTINATION "${CURRENT_PACKAGES_DIR}/share/unofficial-vulkan-memory-allocator")

configure_file("${SOURCE_PATH}/LICENSE.txt" "${CURRENT_PACKAGES_DIR}/share/${PORT}/copyright" COPYONLY)

It's ignoring the installation method natively provided by VulkanMemoryAllocator and providing it's own method instead.
Same applies to the Vulkan SDK. We also ignore the installation provided by VulkanMemoryAllocator and just manually copy the include file. We don't want to ship binaries for the VulkanMemoryAllocator.

VMA is designed as a single-header library and so I agree that it is recommended to just take the "vk_mem_alloc.h" file instead of building it as a separate library.
What is your request here? What do you propose to change in VMA repository?

What is your request here? What do you propose to change in VMA repository?

Ideally VMA would behave like Vulkan-Headers and install only the header files. See the CMake code for Vulkan-Headers for reference.
https://github.com/KhronosGroup/Vulkan-Headers

VMA is intended to be used as a single self-contained file to be included in user's project. Cmake script was an external contribution. Since it was accepted, it became a never-ending story of issues and pull requests proposed to modify it. I would prefer to not refactor it so significantly. I will consider removing it completely in the future.
The script you showed above which does vcpkg_from_github can probably just #include ".../vk_mem_alloc.h" file wherever needed in the main project code without the need for the library to have its own Cmake script.

VMA is intended to be used as a single self-contained file to be included in user's project.

I agree. Currently however it also installs binaries. This is a problem regardless of what build system VMA uses. This isn't a CMake exclusive problem this is a packaging problem.
juan@pop-os:~/projects/vma$ cmake --install build/ --prefix build/install
-- Installing: /home/.../install/lib/libVulkanMemoryAllocator.a <- This is the issue.
-- Installing: /home/.../install/include/vk_mem_alloc.h

The script you showed above which does vcpkg_from_github can probably just #include ".../vk_mem_alloc.h" file wherever needed in the main project code without the need for the library to have its own Cmake script.

That is basically what vcpkg/conan and the vulkan-sdk do to avoid installing the aforementioned binary.

Closing since it seems like CMake support will be removed in the future.

Re-opening due to misinterpreting conversation.

authors: adam-sawicki-a juan-lunarg