text:
你好，我在使用您的开源项目的时候遇到了以下问题

我已经确保安装了docker
并且我可以正常的自己pull镜像并创建容器
我根据你的使用指南clone 项目以后，进入项目
执行命令docker-compose up -d nginx mysql  redis （因为看见你的说明里面，说phpfpm依赖不需要特地添加）
最后获得的错误是
WARNING: The PMA_DB_ENGINE variable is not set. Defaulting to a blank string.
WARNING: The PMA_PORT variable is not set. Defaulting to a blank string.
WARNING: The PHP_VERSION variable is not set. Defaulting to a blank string.
WARNING: The PHP_WORKER_SUPERVISORD_CONF variable is not set. Defaulting to a blank string.
WARNING: The DOCKER_HOST_IP variable is not set. Defaulting to a blank string.
WARNING: The APPLICATION variable is not set. Defaulting to a blank string.
WARNING: The PHP_IDE_CONFIG variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_XDEBUG variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_SOAP variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_ZIP_ARCHIVE variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_PHPREDIS variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_MEMCACHED variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_MONGO variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_XDEBUG_CONF variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INI_CONF variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_POOL_CONF variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_LOG_PATH variable is not set. Defaulting to a blank string.
WARNING: The NGINX_SITES_PATH variable is not set. Defaulting to a blank string.
WARNING: The NGINX_CONF variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_HTTP_PORT variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_HTTPS_PORT variable is not set. Defaulting to a blank string.
WARNING: The ELASTICSEARCH_HOST_HTTP_PORT variable is not set. Defaulting to a blank string.
WARNING: The ELASTICSEARCH_HOST_TRANSPORT_PORT variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_XDEBUG variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_NODE variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_SOAP variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_YARN variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_MONGO variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_COMPOSER_GLOBAL_INSTALL variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_WORKSPACE_SSH variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_PUID variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_PGID variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_NODE_VERSION variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_YARN_VERSION variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_TIMEZONE variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_XDEBUG_CONF variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_CRONTAB variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_DATABASE variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_USER variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_ROOT_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_CONF variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_PORT variable is not set. Defaulting to a blank string.
WARNING: The MEMCACHED_HOST_PORT variable is not set. Defaulting to a blank string.
WARNING: The MONGODB_PORT variable is not set. Defaulting to a blank string.
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.memcached.ports is invalid: Port ranges don't match in length
services.mongo.ports is invalid: Port ranges don't match in length
services.mysql.ports is invalid: Port ranges don't match in length
services.nginx.ports is invalid: Port ranges don't match in length
services.nginx.ports is invalid: Port ranges don't match in length
services.phpmyadmin.ports is invalid: Port ranges don't match in length
services.elasticsearch.ports is invalid: Port ranges don't match in length
services.elasticsearch.ports is invalid: Port ranges don't match in length
WuillydeMBP% docker-compose up -d nginx mysql redis
WARNING: The PMA_DB_ENGINE variable is not set. Defaulting to a blank string.
WARNING: The PMA_PORT variable is not set. Defaulting to a blank string.
WARNING: The PHP_VERSION variable is not set. Defaulting to a blank string.
WARNING: The PHP_WORKER_SUPERVISORD_CONF variable is not set. Defaulting to a blank string.
WARNING: The DOCKER_HOST_IP variable is not set. Defaulting to a blank string.
WARNING: The APPLICATION variable is not set. Defaulting to a blank string.
WARNING: The PHP_IDE_CONFIG variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_XDEBUG variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_SOAP variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_ZIP_ARCHIVE variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_PHPREDIS variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_MEMCACHED variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INSTALL_MONGO variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_XDEBUG_CONF variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_INI_CONF variable is not set. Defaulting to a blank string.
WARNING: The PHP_FPM_POOL_CONF variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_LOG_PATH variable is not set. Defaulting to a blank string.
WARNING: The NGINX_SITES_PATH variable is not set. Defaulting to a blank string.
WARNING: The NGINX_CONF variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_HTTP_PORT variable is not set. Defaulting to a blank string.
WARNING: The NGINX_HOST_HTTPS_PORT variable is not set. Defaulting to a blank string.
WARNING: The ELASTICSEARCH_HOST_HTTP_PORT variable is not set. Defaulting to a blank string.
WARNING: The ELASTICSEARCH_HOST_TRANSPORT_PORT variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_XDEBUG variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_NODE variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_SOAP variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_YARN variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_MONGO variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_COMPOSER_GLOBAL_INSTALL variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_INSTALL_WORKSPACE_SSH variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_PUID variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_PGID variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_NODE_VERSION variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_YARN_VERSION variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_TIMEZONE variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_XDEBUG_CONF variable is not set. Defaulting to a blank string.
WARNING: The WORKSPACE_CRONTAB variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_DATABASE variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_USER variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_ROOT_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_CONF variable is not set. Defaulting to a blank string.
WARNING: The MYSQL_PORT variable is not set. Defaulting to a blank string.
WARNING: The MEMCACHED_HOST_PORT variable is not set. Defaulting to a blank string.
WARNING: The MONGODB_PORT variable is not set. Defaulting to a blank string.
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.memcached.ports is invalid: Port ranges don't match in length
services.mongo.ports is invalid: Port ranges don't match in length
services.mysql.ports is invalid: Port ranges don't match in length
services.nginx.ports is invalid: Port ranges don't match in length
services.nginx.ports is invalid: Port ranges don't match in length
services.phpmyadmin.ports is invalid: Port ranges don't match in length
services.elasticsearch.ports is invalid: Port ranges don't match in length

仔细看文档，你漏掉了命令  cp .env.example .env

repo: RystLee/DevDock


text:
Feature/fast rdf parse

This fixes #42  and #35
Lines with errors are now skipped and ignored

may still need some clean up

source: gharchive/pull-request

repo: SANSA-Stack/SANSA-RDF

license_type: permissive

license_source: bigquery


text:
Update step-26-mock-server-configuration-bae9d90.md

missing =>

@caiwenhn2008 thanks for creating this issue. Using just a simple method definition should be fine here. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Method_definitions
Any benefits of using arrow function here?

@caiwenhn2008 thanks for creating this issue. Using just a simple method definition should be fine here. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Method_definitions
Any benefits of using arrow function here?

Thanks for quick response, this is what i see from https://sapui5.hana.ondemand.com/sdk/#/topic/bae9d90d2e9c4206889368f04edab508 , and I failed when run the sample

is there any github synch issue here?  we can either remove ":" or change to  " init: () => {"
"

Yes, nightly fixed, thanks!

@KlattG could you please check if the fix is also present in the last 1.120 version?

Just checked it, it's fixed in 1.120.2.

authors: OlMue caiwenhn2008 flovogt

license_source: github-api


text:
Matching a string until closing parenthesis

If I have a string like this:
abc(hello (world) test)def

How do I match the (hello (world) test) part with the DSL methods? I also need to have the plain string, not tokenized, in the CST

How do I match the (hello (world) test) part with the DSL methods?

Depends what you want to do with it.
You could model it as a sequence of expressions with optional parenthesis expressions:
expressionList:
  expression+
;

expression:
  "(" expressionList ")" |
  StringLiteral
;

I also need to have the plain string, not tokenized, in the CST

Have a look at https://github.com/SAP/chevrotain/issues/872

For example if we had whitespace tokens and anything tokens, and I did $.CONSUME(Anything) it would error if I gave it whitespace.

That depends on the order in the lexer definition.
That regexp match does not occur when you do the "CONSUME"
It happens earlier when the whole input is tokenized .
The "CONSUME" only matches vs the types of the Token, not the actual regexp.

I know, but the anything token doesn't work this way, so what do you recommend?

source: gharchive/issue

repo: SAP/chevrotain


text:
Fixed issues in routing documentation (missing slash for optional par…

…ameters)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant Michadelic


text:
sap.m.Table: Ability to export to a spreadsheet (Excel, CSV, ...)

OpenUI5 version: 1.120.12
Browser/version (+device/version): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Hello!
Since OpenUI5 version 1.73, sap.ui.core.util.ExportTypeCSV is deprecated and the documentation indicates that ~sap.ui.core.util.ExportTypeCSV~ sap.ui.export.Spreadsheet should be used. However, this module is only available in SAPUI5.
In my opinion, since exporting a table's data to a spreadsheat is a commonly needed operation for a business oriented framework such as OpenUI5, it should support such an operation. It could be also used as a temporary work-around to print a table's data while this feature request is implemented (users could export the table to a spreadsheet and then print the data using another software, such as Excel, Google Sheets, etc.).
Thanks!
Math

@pubmikeb You're right! I made a correction in the question's body.

As @pubmikeb mentioned, we already have this gap on our radar, as we have BLIs FIORITECHP1-13991 and FIORITECHP1-13992 on our backlog.
Unfortunately, the topic currently has not the highest priority and therefore has not seen any further development yet.
I know this answer won't satisfy you, but restricted capacity and other incoming high priority topics lead to a current hold of this topic.
I'll close this issue, as #2629 deals with the same topic and you can find updates there.

authors: DonkeyCo mathlizee


text:
OpaTest Qunit Page - ability to run a single journey feature request

We currently have 6 OPA journeys and will have more to come.
Would be nice to filter the tests related to the current development whilst coding
With Unit tests you can run by module, the same feature for Opa Tests by journey would be nice, i tired to add the qunit-testrunner-toolbar but not happening
Cheers
JSP

Hi JSP;
Since OPA is only using QUnit as runner, you can use the QUnit.module function to group the tests.
Here is a link to the test of our sample app running only one module.
Here is a qunit issue saying, that the link to the UI is missing. I did not check if they closed this gap for now. Maybe it would be a contribution to QUNit.
best regards,
Tobias

so for not getting back to you early, the example above is exactly what i was looking for
Cheers
John P

We are on 1.28.XX which has QUnit v1.10.0 as a thirdparty library
I pointed the test page to QUnit 1.18.0 + CSS and the filters work a charm
cheers @TobiasOetzel


text:
Add test and fix for issue #126

test and fix for #126

Codecov Report

Merging #181 (c06f545) into master (5731a4c) will decrease coverage by 0.55%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #181      +/-   ##
==========================================
- Coverage   92.70%   92.14%   -0.56%
==========================================
  Files           6        6
  Lines        2672     2496     -176
==========================================
- Hits         2477     2300     -177
- Misses        195      196       +1

Impacted Files
Coverage Δ

pyodata/v2/model.py
92.70% <100.00%> (-0.71%)
:arrow_down:

pyodata/v2/service.py
90.37% <0.00%> (-0.29%)
:arrow_down:

Continue to review full report at Codecov.

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

Thank you!

authors: codecov-commenter dmatula filak-sap

repo: SAP/python-pyodata


text:
Support for upsert operations via sql_alchemy?

Hi - knowing that HANA supports an UPSERT statement, I was wondering whether there is a matching construct in the dialect that would enable this operation via sql_alchemy as it is the case for specific dialects included with sql_alchemy (https://docs.sqlalchemy.org/en/20/orm/queryguide/dml.html#orm-upsert-statements).
I have used the corresponding functionality for postgresql (https://docs.sqlalchemy.org/en/20/dialects/postgresql.html#insert-on-conflict-upsert) in the past and would now like to port some of this code.
Could you please point me to any resource on how to accomplish that or do I have to fall back to constructing the query manually?
Any help is appreciated - Jan

Hi, I guess beside not using UPSERT but a kind of UPDATE/SELECT/INSERT combination with exception handling, I'm not aware of other options than adding support for UPSERT in sqlalchemy-hana. I'm currently busy working on cleanup tasks, but I can have a look in the following weeks

@therhaag I did some research and I guess we need to make a difference between SQLAlchemy core and SQLAlchemy ORM.
For SQLAlchemy core, the only way is a manual approach using SELECT, INSERT and UPDATE. Not nice and it has some roundtrips. For this, we could build an UPSERT construct.
For SQLAlchemy ORM using the Session API on the other hand it's not quite easy, because how sessions work. For this, I would recommend using session.merge.  I also found a blog explaining the idea.
So let's focus on SQLAlchemy Core. I guess it makes sense to invent a completly new construct, because neither insert nor update have a similar syntax compared to UPSERT.
As said, I'm happy to work on this in the next weeks but to be transparent, It will most likly somewhen in January

@therhaag 1.2.0 was just released 😄

authors: kasium therhaag

repo: SAP/sqlalchemy-hana


text:
test: Removes IDs From Datasource Subaccount Subscriptions Tests

Purpose

Removes fixed IDs from tests to enable landscape independent fixture recording.

Does this introduce a breaking change?
[ ] Yes
[ x ] No

Pull Request Type
What kind of change does this Pull Request introduce?
[ ] Bugfix
[ ] Feature
[ x ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Test the code via automated test

go test ./...

What to Check
Verify that the following are valid:

Automated tests are executed successfully

Checklist for reviewer
The following organizational tasks must be completed before merging this PR:

[ ] The PR is assigned to the Terraform project and a status is set (typically "in review").
[ ] The PR has the matching labels assigned to it.
[ ] The PR has a milestone assigned to it.
[ ] If the PR closes an issue, the issue is referenced.
[ ] Possible follow-up items are created and linked.

Prerequisite for #59

repo: SAP/terraform-provider-btp


text:
Create a Workflow Project from a Template

Tutorial URL: https://developers.sap.com/tutorials/cp-workflow-create-project.html
Please specify the step you are referring to
when I create a Project from template , enter project name and workflow name and click finish, the process keeps running , never creating the workflow .
I tried from IE as well as chrom , but does not work , there is no error message as well.
Please suggest .

Hi,
Please see the new tutorials at: https://developers.sap.com/group.cp-workflow-cf.html
Best regards,
Astrid

authors: AstridHerbst poonamassudani

repo: SAPDocuments/Tutorials


text:
Output which coverage thresholds are failing

When a coverage threshold fails, currently the only error guidance you get is "Coverage Failed".
This added detailed error output on exactly what is failing. Example:
Coverage for functions (86.61%) does not meet the global threshold (100%)

Coverage for lines in these files does not meet the threshold (50%):
	app/adapters/viewModel/restaurantHelpers/mapRestaurantsToFeaturePop.js
	app/plugins/routes/restaurants/handler.js
	app/plugins/routes/viewModel/handler.js
	app/serviceFacades/viewModelHelpers/allRestaurantIds.js

I wonder if maybe this should go into istanbul-coverage-checker or maybe it's own package? The code seems very generic.
cc @peterjwest

I'm fine moving this code - just let me know the approach you'd like me to take and I'll work on it.

@peterjwest @SBoudrias ping?

@duereg How about you publish this as a standalone package and we then use that package inside gulp-istanbul?

ok. I'll close this and reopen a new PR with the appropriate plugin

authors: SBoudrias duereg

repo: SBoudrias/gulp-istanbul

license: mit


text:
Print gonzales-pe context when parsing fails

Hello,
Currently when the gonzales-pe parse fails, due to a syntax error, or so, the context of the error is not printed, but only the error message and the line. Example:
Error: Please check validity of the block starting from line #3

This would be enough perhaps when working on a single CSS file, but when working with preprocessors, like less or sass, becomes quite unclear, as we need to know also ideally the file where the error is located. But as gonzales-pe does not provide information about the file, we could print the context where the error was found.
An issue about this was raised in gonzales-pe: tonyganch/gonzales-pe#222
However, they have deactivated the setting to print the error, and left it to the users of the library, to decide wether to print the error or not.
I've been digging a bit into it, but could not find documentation or a way to print the error in sc5, perhaps any of you guys have a clearer idea?
If not, then we would need to wait until the dev of gonzales-pe, answers my question in the issue, to prepare the PR.

I think that Gonzales-PE does not have API for error, does it?

Hi @varya
I actually checked as deep as I could in gonzales-pe but could not find the option when it is used with node, it is available when used as cli.
Some time ago, there was a PR (tonyganch/gonzales-pe#222) asking about this, where the author mentioned that the silent option could be set to false, so we can print the context. Asked in there if we can point us out where to find it. My assumption is that is not available for node usage yet, however I'd like to wait for his answer first.
When this is answered and solved in gonzales-pe we will need to send the option to our parser here, so we can show the context to the user in case a parsing error happens, at the moment when this happens the user needs to:

Go to gonzales-pe in node_modules
Add the context to the print message, as shown here

So they can see at least the lines around the parsing error.
Note: added the steps here, so it serves a documentation for users that are having this same problem and have troubles finding the place where a parsing error occurs.

Hello,
the gonzales-pe ParsingError contains the context and a toString method which includes the context.
The error is passed down to
https://github.com/SC5/sc5-styleguide/blob/master/lib/styleguide.js#L430
If you use console.error(error.toString()) instead of console.error(error.stack || error.message) you get an useful error message.

I'm having the same issue using LESS, unable to track down the root cause because of the poor error message. Compiling my LESS with gulp-less package works fine, so I suspect there is more at play here with gonzales-pe.

authors: DanielaValero craigmcginley macahi varya


text:
Fixing Issue #21 -  Adding aws-nodejs8.10 to supported runtime list.

This pull request adds nodejs810 to the supported runtime list, resolving Issue #21

Was about to write this myself, happy to see someone took the initiative.
Can we get this merged in?

@artoliukkonen I don't think this got published? Latest version on npmjs.com doesn't include this fix.

@artoliukkonen I don't think this got published? Latest version on npmjs.com doesn't include this fix.

I noticed the same issue, @artoliukkonen. Still receiving this error after grabbing the latest version of the plugin.

authors: alexgandy alexhwoods doubleminus magic-madrigal

license: MIT


text:
Fixed Neels Hyrogliphics

Long story short NEEL @neelp03  added Hyrogliphics Idk y but I fixed them

Nobody:
@neelp03 : "

𓀀
𓀁
𓀂
𓀃
𓀄
𓀅
𓀆
𓀇
𓀈
𓀉
𓀊
𓀋
𓀌
𓀍
𓀎
𓀏

U+1301x
𓀐
𓀑
𓀒
𓀓
𓀔
𓀕
𓀖
𓀗
𓀘
𓀙
𓀚
𓀛
𓀜
𓀝
𓀞

U+1302x
𓀠
𓀡
𓀢
𓀣
𓀤
𓀥
𓀦
𓀧
𓀨
𓀩
𓀪
𓀫
𓀬
𓀭
𓀮

U+1303x
𓀰
𓀱
𓀲
𓀳
𓀴
𓀵
𓀶
𓀷
𓀸
𓀹
𓀺
𓀻
𓀼
𓀽
𓀾

U+1304x
𓁀
𓁁
𓁂
𓁃
𓁄
𓁅
𓁆
𓁇
𓁈
𓁉
𓁊
𓁋
𓁌
𓁍
𓁎

U+1305x
𓁐
𓁑
𓁒
𓁓
𓁔
𓁕
𓁖
𓁗
𓁘
𓁙
𓁚
𓁛
𓁜
𓁝
𓁞

U+1306x
𓁠
𓁡
𓁢
𓁣
𓁤
𓁥
𓁦
𓁧
𓁨
𓁩
𓁪
𓁫
𓁬
𓁭
𓁮

U+1307x
𓁰
𓁱
𓁲
𓁳
𓁴
𓁵
𓁶
𓁷
𓁸
𓁹
𓁺
𓁻
𓁼
𓁽
𓁾

U+1308x
𓂀
𓂁
𓂂
𓂃
𓂄
𓂅
𓂆
𓂇
𓂈
𓂉
𓂊
𓂋
𓂌
𓂍
𓂎

U+1309x
𓂐
𓂑
𓂒
𓂓
𓂔
𓂕
𓂖
𓂗
𓂘
𓂙
𓂚
𓂛
𓂜
𓂝
𓂞

U+130Ax
𓂠
𓂡
𓂢
𓂣
𓂤
𓂥
𓂦
𓂧
𓂨
𓂩
𓂪
𓂫
𓂬
𓂭
𓂮

U+130Bx
𓂰
𓂱
𓂲
𓂳
𓂴
𓂵
𓂶
𓂷
𓂸
𓂹
𓂺
𓂻
𓂼
𓂽
𓂾

U+130Cx
𓃀
𓃁
𓃂
𓃃
𓃄
𓃅
𓃆
𓃇
𓃈
𓃉
𓃊
𓃋
𓃌
𓃍
𓃎

U+130Dx
𓃐
𓃑
𓃒
𓃓
𓃔
𓃕
𓃖
𓃗
𓃘
𓃙
𓃚
𓃛
𓃜
𓃝
𓃞

U+130Ex
𓃠
𓃡
𓃢
𓃣
𓃤
𓃥
𓃦
𓃧
𓃨
𓃩
𓃪
𓃫
𓃬
𓃭
𓃮

U+130Fx
𓃰
𓃱
𓃲
𓃳
𓃴
𓃵
𓃶
𓃷
𓃸
𓃹
𓃺
𓃻
𓃼
𓃽
𓃾

U+1310x
𓄀
𓄁
𓄂
𓄃
𓄄
𓄅
𓄆
𓄇
𓄈
𓄉
𓄊
𓄋
𓄌
𓄍
𓄎

U+1311x
𓄐
𓄑
𓄒
𓄓
𓄔
𓄕
𓄖
𓄗
𓄘
𓄙
𓄚
𓄛
𓄜
𓄝
𓄞

U+1312x
𓄠
𓄡
𓄢
𓄣
𓄤
𓄥
𓄦
𓄧
𓄨
𓄩
𓄪
𓄫
𓄬
𓄭
𓄮

U+1313x
𓄰
𓄱
𓄲
𓄳
𓄴
𓄵
𓄶
𓄷
𓄸
𓄹
𓄺
𓄻
𓄼
𓄽
𓄾

U+1314x
𓅀
𓅁
𓅂
𓅃
𓅄
𓅅
𓅆
𓅇
𓅈
𓅉
𓅊
𓅋
𓅌
𓅍
𓅎

U+1315x
𓅐
𓅑
𓅒
𓅓
𓅔
𓅕
𓅖
𓅗
𓅘
𓅙
𓅚
𓅛
𓅜
𓅝
𓅞

U+1316x
𓅠
𓅡
𓅢
𓅣
𓅤
𓅥
𓅦
𓅧
𓅨
𓅩
𓅪
𓅫
𓅬
𓅭
𓅮

U+1317x
𓅰
𓅱
𓅲
𓅳
𓅴
𓅵
𓅶
𓅷
𓅸
𓅹
𓅺
𓅻
𓅼
𓅽
𓅾

U+1318x
𓆀
𓆁
𓆂
𓆃
𓆄
𓆅
𓆆
𓆇
𓆈
𓆉
𓆊
𓆋
𓆌
𓆍
𓆎

U+1319x
𓆐
𓆑
𓆒
𓆓
𓆔
𓆕
𓆖
𓆗
𓆘
𓆙
𓆚
𓆛
𓆜
𓆝
𓆞

U+131Ax
𓆠
𓆡
𓆢
𓆣
𓆤
𓆥
𓆦
𓆧
𓆨
𓆩
𓆪
𓆫
𓆬
𓆭
𓆮

U+131Bx
𓆰
𓆱
𓆲
𓆳
𓆴
𓆵
𓆶
𓆷
𓆸
𓆹
𓆺
𓆻
𓆼
𓆽
𓆾

U+131Cx
𓇀
𓇁
𓇂
𓇃
𓇄
𓇅
𓇆
𓇇
𓇈
𓇉
𓇊
𓇋
𓇌
𓇍
𓇎

U+131Dx
𓇐
𓇑
𓇒
𓇓
𓇔
𓇕
𓇖
𓇗
𓇘
𓇙
𓇚
𓇛
𓇜
𓇝
𓇞

U+131Ex
𓇠
𓇡
𓇢
𓇣
𓇤
𓇥
𓇦
𓇧
𓇨
𓇩
𓇪
𓇫
𓇬
𓇭
𓇮

U+131Fx
𓇰
𓇱
𓇲
𓇳
𓇴
𓇵
𓇶
𓇷
𓇸
𓇹
𓇺
𓇻
𓇼
𓇽
𓇾

U+1320x
𓈀
𓈁
𓈂
𓈃
𓈄
𓈅
𓈆
𓈇
𓈈
𓈉
𓈊
𓈋
𓈌
𓈍
𓈎

U+1321x
𓈐
𓈑
𓈒
𓈓
𓈔
𓈕
𓈖
𓈗
𓈘
𓈙
𓈚
𓈛
𓈜
𓈝
𓈞

U+1322x
𓈠
𓈡
𓈢
𓈣
𓈤
𓈥
𓈦
𓈧
𓈨
𓈩
𓈪
𓈫
𓈬
𓈭
𓈮

U+1323x
𓈰
𓈱
𓈲
𓈳
𓈴
𓈵
𓈶
𓈷
𓈸
𓈹
𓈺
𓈻
𓈼
𓈽
𓈾

U+1324x
𓉀
𓉁
𓉂
𓉃
𓉄
𓉅
𓉆
𓉇
𓉈
𓉉
𓉊
𓉋
𓉌
𓉍
𓉎

U+1325x
𓉐
𓉑
𓉒
𓉓
𓉔
𓉕
𓉖
𓉗
𓉘
𓉙
𓉚
𓉛
𓉜
𓉝
𓉞

U+1326x
𓉠
𓉡
𓉢
𓉣
𓉤
𓉥
𓉦
𓉧
𓉨
𓉩
𓉪
𓉫
𓉬
𓉭
𓉮

U+1327x
𓉰
𓉱
𓉲
𓉳
𓉴
𓉵
𓉶
𓉷
𓉸
𓉹
𓉺
𓉻
𓉼
𓉽
𓉾

U+1328x
𓊀
𓊁
𓊂
𓊃
𓊄
𓊅
𓊆
𓊇
𓊈
𓊉
𓊊
𓊋
𓊌
𓊍
𓊎

U+1329x
𓊐
𓊑
𓊒
𓊓
𓊔
𓊕
𓊖
𓊗
𓊘
𓊙
𓊚
𓊛
𓊜
𓊝
𓊞

U+132Ax
𓊠
𓊡
𓊢
𓊣
𓊤
𓊥
𓊦
𓊧
𓊨
𓊩
𓊪
𓊫
𓊬
𓊭
𓊮

U+132Bx
𓊰
𓊱
𓊲
𓊳
𓊴
𓊵
𓊶
𓊷
𓊸
𓊹
𓊺
𓊻
𓊼
𓊽
𓊾

U+132Cx
𓋀
𓋁
𓋂
𓋃
𓋄
𓋅
𓋆
𓋇
𓋈
𓋉
𓋊
𓋋
𓋌
𓋍
𓋎

U+132Dx
𓋐
𓋑
𓋒
𓋓
𓋔
𓋕
𓋖
𓋗
𓋘
𓋙
𓋚
𓋛
𓋜
𓋝
𓋞

U+132Ex
𓋠
𓋡
𓋢
𓋣
𓋤
𓋥
𓋦
𓋧
𓋨
𓋩
𓋪
𓋫
𓋬
𓋭
𓋮

U+132Fx
𓋰
𓋱
𓋲
𓋳
𓋴
𓋵
𓋶
𓋷
𓋸
𓋹
𓋺
𓋻
𓋼
𓋽
𓋾

U+1330x
𓌀
𓌁
𓌂
𓌃
𓌄
𓌅
𓌆
𓌇
𓌈
𓌉
𓌊
𓌋
𓌌
𓌍
𓌎

U+1331x
𓌐
𓌑
𓌒
𓌓
𓌔
𓌕
𓌖
𓌗
𓌘
𓌙
𓌚
𓌛
𓌜
𓌝
𓌞

U+1332x
𓌠
𓌡
𓌢
𓌣
𓌤
𓌥
𓌦
𓌧
𓌨
𓌩
𓌪
𓌫
𓌬
𓌭
𓌮

U+1333x
𓌰
𓌱
𓌲
𓌳
𓌴
𓌵
𓌶
𓌷
𓌸
𓌹
𓌺
𓌻
𓌼
𓌽
𓌾

U+1334x
𓍀
𓍁
𓍂
𓍃
𓍄
𓍅
𓍆
𓍇
𓍈
𓍉
𓍊
𓍋
𓍌
𓍍
𓍎

U+1335x
𓍐
𓍑
𓍒
𓍓
𓍔
𓍕
𓍖
𓍗
𓍘
𓍙
𓍚
𓍛
𓍜
𓍝
𓍞

U+1336x
𓍠
𓍡
𓍢
𓍣
𓍤
𓍥
𓍦
𓍧
𓍨
𓍩
𓍪
𓍫
𓍬
𓍭
𓍮

U+1337x
𓍰
𓍱
𓍲
𓍳
𓍴
𓍵
𓍶
𓍷
𓍸
𓍹
𓍺
𓍻
𓍼
𓍽
𓍾

U+1338x
𓎀
𓎁
𓎂
𓎃
𓎄
𓎅
𓎆
𓎇
𓎈
𓎉
𓎊
𓎋
𓎌
𓎍
𓎎

U+1339x
𓎐
𓎑
𓎒
𓎓
𓎔
𓎕
𓎖
𓎗
𓎘
𓎙
𓎚
𓎛
𓎜
𓎝
𓎞

U+133Ax
𓎠
𓎡
𓎢
𓎣
𓎤
𓎥
𓎦
𓎧
𓎨
𓎩
𓎪
𓎫
𓎬
𓎭
𓎮

U+133Bx
𓎰
𓎱
𓎲
𓎳
𓎴
𓎵
𓎶
𓎷
𓎸
𓎹
𓎺
𓎻
𓎼
𓎽
𓎾

U+133Cx
𓏀
𓏁
𓏂
𓏃
𓏄
𓏅
𓏆
𓏇
𓏈
𓏉
𓏊
𓏋
𓏌
𓏍
𓏎

U+133Dx
𓏐
𓏑
𓏒
𓏓
𓏔
𓏕
𓏖
𓏗
𓏘
𓏙
𓏚
𓏛
𓏜
𓏝
𓏞

U+133Ex
𓏠
𓏡
𓏢
𓏣
𓏤
𓏥
𓏦
𓏧
𓏨
𓏩
𓏪
𓏫
𓏬
𓏭
𓏮

U+133Fx
𓏰
𓏱
𓏲
𓏳
𓏴
𓏵
𓏶
𓏷
𓏸
𓏹
𓏺
𓏻
𓏼
𓏽
𓏾

U+1340x
𓐀
𓐁
𓐂
𓐃
𓐄
𓐅
𓐆
𓐇
𓐈
𓐉
𓐊
𓐋
𓐌
𓐍
𓐎

U+1341x
𓐐
𓐑
𓐒
𓐓
𓐔
𓐕
𓐖
𓐗
𓐘
𓐙
𓐚
𓐛
𓐜
𓐝
𓐞

U+1342x
𓐠
𓐡
𓐢
𓐣
𓐤
𓐥
𓐦
𓐧
𓐨
𓐩
𓐪
𓐫
𓐬
𓐭
𓐮"

repo: SCE-Development/Quasar


text:
catalog-based m-test

the catalog-based m-test has issues when the ratio of forecasted events to observed events is large. @Serra314 can you upload the figures that you've made showing this behavior?

We discovered that the difference in the number of events between the simulated catalogues composing a forecasts and the number of observations may cause problems to the M-test.
The main reason behind is that we are estimating the score probability distribution calculating the score between the union of the simulated catalogues and each simulated catalogue. This means that if the simulated catalogues have an average of N events we are estimating the score probability distribution for a sample of length N. If the number of observations is different from N then the score between the union of the simulated catalogues and the observed events is coming from a different distribution than the one we have estimated using the forecasts. This leads to value of γ that, instead of being uniformly distributed, are very concentrated around 1 or 0 (depending on the fact that we are overestimating or underestimating the number of events).
One way to solve this is to estimate the score probability distribution using samples from the union of simulated catalogues instead of the forecasts in a bootstrap fashion. Sampling from the union of the forecasts a number of events equals to the number of observed, and calculating the score between each bootstrap sample and the union of the simulated catalogues, yelds a sample of score values under the null hypothesis that the forecast and the observation comes from the same distribution. The γ values obtained in this way are correct and this can be applied to many different scores.
Below an example in which the simulated magnitudes and the observed ones both come from a GR law with b-value equals 1. I have used an observed sample with 100 events, while each simulated catalogues has a number of events which comes from a Poisson distribution with mean 1000. I have calculated the gamma values considering 1000 different observed samples against the same forecast. They correctly look uniform in all cases.

Those are instead in cases where the forecasts come from a GR law with a different b-value, while the observations still come to a GR law with b-value equals 1. We can see how the distribution of %gamma; values departs from uniformity. The faster it departs from uniformity changing b-value the more sensitive the score is to incoherence in magnitude distribution.

I have made similar observations with the catalogue-based M-test, S-test, and PL-test. The way I think about it is that if the simulated catalogs over- or underestimate the number of events, their scores will, on average, be "more perfect" and "less perfect", respectively. (Perfect meaning being close to the overall distribution coming from all simulations.) So, I have seen two models that use the same spatial distribution pass the S-test in one case, but fail in another case, because they didn't forecast the same number of events. Same for M- and PL-test.
I think that this can even lead to an M-test being passed when it shouldn't pass, if the number of forecasted events is wrong in the right way.

Hi Leila,
Your observations are correct. It is exactly what happens and the problem is not limited to the M-test. I also  believe it is possible to find the "correct" number of forecasted event to make an incorrect magnitude forecast to pass the test ( I have not tried though).
I am currently writing a paper on this showing the problem and proposing the resampling of the union forecast as possible solution. In practice, instead of using the synthetic catalogs as they are we create the fake synthetic catalogues by sampling the union forecast as many time as observations. This solves the problem at least when the magnitude distribution is the same across different synthetic catalogues (which I believe is the most common case). I'll share a link when we are close to submitting it.

authors: Serra314 lmizrahi wsavran

repo: SCECcode/pycsep


text:
basin branch testing

error running check_files_md5.py
Checking file: cvmhvbn.tar.gz
Traceback (most recent call last):
File "./check_largefiles_md5.py", line 99, in
total_ok, total_errs = check_md5file(model,fp.name,total_ok,total_errs)
File "./check_largefiles_md5.py", line 72, in check_md5file
if res[1].decode("utf-8") == "OK":
IndexError: list index out of range

fix typo in setup/setup.list

authors: meihuisu pjmaechling

repo: SCECcode/ucvm


text:
Extend and augment the internal-use only output logging capabilities in the MSCommon module.

This PR extends and augments the internal-use debugging facilities of the MSCommon module.  The existing debug logging facility is extended.  An internal-use function call and return value trace mechanism was added for the MSCommon module.
All changes are internal-use only. None of the changes are enabled unless the appropriate undocumented environment variables are defined in an end-user's environment.
Rationale:

Due to the varied paths through the MSCommon module, there is a fairly steep learning curve for anyone unfamiliar with the msvc detection code to fully grasp the processing sequence.
While the existing debug logging facility is useful, augmenting the debug logging with a trace facility provides additional context to the processing sequence through the msvc detection code.
The trace output may prove valuable when evaluating, verifying, and validating #3717 and in supplementing the discussions concerning #3723.
It is possible via post-processing to combine the debug messages in the appropriate locations of the trace messages to provide a unified debug/trace output file subject to some limitations: debug calls originating above the MSCommon module cannot be resolved as the they do not appear in the trace output.  This happens with the Tools/msvsTests.py script.  At present, the post-processing script to combine the output is not included.
The combined debug and trace output may allow the existing README describing the processing sequence to be maintained with less manual effort.
Having an end-user enable the debug and trace output and provide the resulting files could be a useful first step in diagnosing remote msvc detection problems.

See the comments below for additional information and some output fragment examples.
Contributor Checklist:

[ ] I have created a new test or updated the unit tests to cover the new/changed functionality.
[x] I have updated CHANGES.txt (and read the README.rst)
[ ] I have updated the appropriate documentation

Debug Output
Extensions to the existing debug logging (i.e., SCONS_MSCOMMON_DEBUG=filename) functionality:

A logging filter was added to log the correct relative module path for the debug invocation.
Previously, "MSCommon/" was hard-coded into the record format.  This results in an incorrect module path when debug is called from a script "above" the MSCommon module (e.g., msvsTests.py).

Prior to the change:01456ms:MSCommon/msvsTests.py:setUp#593:THIS TYPE :test_config_generation (__main__.msvs6aTestCase):
03250ms:MSCommon/msvsTests.py:setUp#593:THIS TYPE :test_get_default_version (__main__.msvs6aTestCase):
03255ms:MSCommon/msvsTests.py:test_get_default_version#607:Testing for default version 6.0:
03256ms:MSCommon/vs.py:get_installed_visual_studios#423:trying to find VS 14.2:

After the change:01139ms:Tool/msvsTests.py:setUp#593:THIS TYPE :test_config_generation (__main__.msvs6aTestCase):
02982ms:Tool/msvsTests.py:setUp#593:THIS TYPE :test_get_default_version (__main__.msvs6aTestCase):
03015ms:Tool/msvsTests.py:test_get_default_version#607:Testing for default version 6.0:
03032ms:MSCommon/vs.py:get_installed_visual_studios#423:trying to find VS 14.2:

The filename handling was extended to allow individual log files to be created for each invocation of SCons.  When the base filename before the extension (if any) ends with the literal "-#", a "serial number" is appended to the filename based on the existing filenames in the target folder.
# Rewrite filename *ONLY* when the rootname ends in "-#":
#    root, ext = splitext(filename) -> root[:-1] + NNNN + ext
#    example: myfile-#.txt -> myfile-0001.txt
#    next consecutive number from largest number in target folder or 1
#    allows individual debug/trace file names for each launch of scons

For example, when running test test/msvs/vs-14.2-exec.py, when the debug file name is specified as "mscommon-vs142exec-debug-#.txt" the following debug files are created:

mscommon-vs142exec-debug-0001.txt
mscommon-vs142exec-debug-0002.txt
mscommon-vs142exec-debug-0003.txt
mscommon-vs142exec-debug-0004.txt
mscommon-vs142exec-debug-0005.txt

Trace Output
An environment variable (SCONS_MSCOMMON_TRACE=filename) was added as well as an optional companion environment variable (SCONS_MSCOMMON_TRACEFLAGS=bitflags) to produce trace logging of function calls and return values.
Similar to the debug handling, the trace filename may be specified as "-".  However, unlike the debug handling, all output is directed to stderr instead of stdout.  This allows stdout (debug output) and stderr (trace output) to be redirected to files independently of one another.
When using the "serial number" extension to the base filenames, the trace file number is synchronized with the debug file number.
For example, when running test test/msvs/vs-14.2-exec.py, when the debug file name is specified as "mscommon-vs142exec-debug-#.txt" and the trace file name is specified as "mscommon-vs142exec-trace-#.txt", the following pairs of debug and trace files are created:

mscommon-vs142exec-debug-0001.txt
mscommon-vs142exec-trace-0001.txt
mscommon-vs142exec-debug-0002.txt
mscommon-vs142exec-trace-0002.txt
mscommon-vs142exec-debug-0003.txt
mscommon-vs142exec-trace-0003.txt
mscommon-vs142exec-debug-0004.txt
mscommon-vs142exec-trace-0004.txt
mscommon-vs142exec-debug-0005.txt
mscommon-vs142exec-trace-0005.txt

Unlike the debug logging, the produced trace file always overwrites an existing file rather than appending to an existing file.
The optional SCONS_MSCOMMON_TRACEFLAGS environment variable can be used to alter the information logged to the trace file.  The current bit fields are:
    # bitflags for selectively enabling trace output
    TRACE_DISPLAY_FUNCTION_ARGLIST   = 0b0001
    TRACE_DISPLAY_FUNCTION_LOCATION  = 0b0010
    TRACE_DISPLAY_RETURN_VALUES      = 0b0100
    TRACE_DISPLAY_ALLFRAMES_ONEBELOW = 0b1000

    # default trace output
    TRACE_DISPLAY_DEFAULT            = 0b0111

    # Typical usage:
    #    '0b1111' or '15' display arg lists, file locations, return values, and all frames one below
    #    '0b0111' or '7'  display arg lists, file locations, and return values [default]
    #    '0b0101' or '5'  display arg lists, and return values
    #    '0b0011' or '3'  display arg lists, and file locations

    # SCONS_MSCOMMON_TRACEFLAGS is internal-use so undocumented
    TRACEFLAGS = int(os.environ.get('SCONS_MSCOMMON_TRACEFLAGS', str(TRACE_DISPLAY_DEFAULT)), 0)

Producing trace files without function file and line number locations is useful when comparing trace output differences due to code changes (i.e., function line number changes cause many differences of limited utility).
Sample output fragments:

Default trace output fragment (0b0111):
__call__(self, env) <SCons\Tool\__init__.py:269 from SCons\Environment.py:1844>
  generate(env) <SCons\Tool\default.py:40 from SCons\Tool\__init__.py:269>
    tool_list(platform, env) <SCons\Tool\__init__.py:1237 from SCons\Tool\default.py:40>
      FindTool(tools, env) <SCons\Tool\__init__.py:1140 from 1237>
        exists(env) <SCons\Tool\msvc.py:307 from SCons\Tool\__init__.py:1140>
        -----------------------------------------------------------------------------
          msvc_exists(env, version=None) <SCons\Tool\MSCommon\vc.py:950 from SCons\Tool\msvc.py:307>
            cached_get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:660 from 951>
              get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:669 from 664>
                debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:673>
                find_vc_pdir(env, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:412 from 675>
                  find_vc_pdir_vswhere(msvc_version='14.2', env) <SCons\Tool\MSCommon\vc.py:359 from 444>
                    msvc_find_vswhere() <SCons\Tool\MSCommon\vc.py:344 from 380>
                      return msvc_find_vswhere(vc.py:357) -> 'C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe'
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:387>
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:392>
                    return find_vc_pdir_vswhere(vc.py:404) -> 'C:\\Software\\MSVS142\\VC'
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:448>
                  return find_vc_pdir(vc.py:449) -> 'C:\\Software\\MSVS142\\VC'
                debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:677>
                _check_cl_exists_in_vc_dir(env, vc_dir, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:526 from 678>
                  get_host_target(env) <SCons\Tool\MSCommon\vc.py:192 from 553>
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:194>
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:207>
                    return get_host_target(vc.py:226) -> ('x86', 'x86', None)
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:561>
                  get_msvc_version_numeric(msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:176 from 563>
                    return get_msvc_version_numeric(vc.py:190) -> '14.2'
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:588>
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:590>
                  return _check_cl_exists_in_vc_dir(vc.py:591) -> True

Post-processed combined debug and trace output fragment (0b0111):
__call__(self, env) <SCons\Tool\__init__.py:269 from SCons\Environment.py:1844>
  generate(env) <SCons\Tool\default.py:40 from SCons\Tool\__init__.py:269>
    tool_list(platform, env) <SCons\Tool\__init__.py:1237 from SCons\Tool\default.py:40>
      FindTool(tools, env) <SCons\Tool\__init__.py:1140 from 1237>
        exists(env) <SCons\Tool\msvc.py:307 from SCons\Tool\__init__.py:1140>
        -----------------------------------------------------------------------------
          msvc_exists(env, version=None) <SCons\Tool\MSCommon\vc.py:950 from SCons\Tool\msvc.py:307>
            cached_get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:660 from 951>
              get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:669 from 664>
                debug(vc.py:673) trying to find VC 14.2
                find_vc_pdir(env, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:412 from 675>
                  find_vc_pdir_vswhere(msvc_version='14.2', env) <SCons\Tool\MSCommon\vc.py:359 from 444>
                    msvc_find_vswhere() <SCons\Tool\MSCommon\vc.py:344 from 380>
                      return msvc_find_vswhere(vc.py:357) -> 'C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe'
                    debug(vc.py:387) VSWHERE: C:\Program Files\Microsoft Visual Studio\Installer\vswhere.exe
                    debug(vc.py:392) running: ['C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe', '-version', '[16.0, 17.0)', '-property', 'installationPath']
                    return find_vc_pdir_vswhere(vc.py:404) -> 'C:\\Software\\MSVS142\\VC'
                  debug(vc.py:448) VC found: '14.2'
                  return find_vc_pdir(vc.py:449) -> 'C:\\Software\\MSVS142\\VC'
                debug(vc.py:677) found VC 14.2
                _check_cl_exists_in_vc_dir(env, vc_dir, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:526 from 678>
                  get_host_target(env) <SCons\Tool\MSCommon\vc.py:192 from 553>
                    debug(vc.py:194) HOST_ARCH:x86
                    debug(vc.py:207) HOST_ARCH:None
                    return get_host_target(vc.py:226) -> ('x86', 'x86', None)
                  debug(vc.py:561) host platform x86, target platform x86 for version 14.2
                  get_msvc_version_numeric(msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:176 from 563>
                    return get_msvc_version_numeric(vc.py:190) -> '14.2'
                  debug(vc.py:588) checking for cl.exe at C:\Software\MSVS142\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe
                  debug(vc.py:590) found cl.exe!
                  return _check_cl_exists_in_vc_dir(vc.py:591) -> True

All trace output fragment includes one frame below/outside MSCommon (0b1111):
__call__(self, env) <SCons\Tool\__init__.py:269 from SCons\Environment.py:1844>
  generate(env) <SCons\Tool\default.py:40 from SCons\Tool\__init__.py:269>
    tool_list(platform, env) <SCons\Tool\__init__.py:1237 from SCons\Tool\default.py:40>
      FindTool(tools, env) <SCons\Tool\__init__.py:1140 from 1237>
        exists(env) <SCons\Tool\msvc.py:307 from SCons\Tool\__init__.py:1140>
        -----------------------------------------------------------------------------
          msvc_exists(env, version=None) <SCons\Tool\MSCommon\vc.py:950 from SCons\Tool\msvc.py:307>
            cached_get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:660 from 951>
              get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:669 from 664>
                debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:673>
                find_vc_pdir(env, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:412 from 675>
                  find_vc_pdir_vswhere(msvc_version='14.2', env) <SCons\Tool\MSCommon\vc.py:359 from 444>
                    get(self, key='VSWHERE', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:379>
                      return get(Environment.py:434) -> None
                    msvc_find_vswhere() <SCons\Tool\MSCommon\vc.py:344 from 380>
                      exists(path='%ProgramFiles(x86)%\\Microsoft Visual Studio\\Installer\\vswhere.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:353>
                        return exists(genericpath.py:21) -> False
                      exists(path='C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:353>
                        return exists(genericpath.py:22) -> True
                      return msvc_find_vswhere(vc.py:357) -> 'C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe'
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:387>
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:392>
                    run() <lib\subprocess.py:447 from SCons\Tool\MSCommon\vc.py:395>
                      return run(subprocess.py:513) -> CompletedProcess(args=['C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe', '-version', '[16.0, 17.0)', '-property', 'installationPath'], returncode=0, stdout=b'C:\\Software\\MSVS142\r\n', stderr=b'')
                    __del__(self, _maxsize, _warn) <lib\subprocess.py:875 from SCons\Tool\MSCommon\vc.py:395>
                    Close(self, CloseHandle) <lib\subprocess.py:202 from SCons\Tool\MSCommon\vc.py:395>
                    _remove(item, selfref) <lib\_weakrefset.py:38 from SCons\Tool\MSCommon\vc.py:395>
                    _remove(item, selfref) <lib\_weakrefset.py:38 from SCons\Tool\MSCommon\vc.py:395>
                    join(path='C:\\Software\\MSVS142') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:404>
                      return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC'
                    return find_vc_pdir_vswhere(vc.py:404) -> 'C:\\Software\\MSVS142\\VC'
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:448>
                  return find_vc_pdir(vc.py:449) -> 'C:\\Software\\MSVS142\\VC'
                debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:677>
                _check_cl_exists_in_vc_dir(env, vc_dir, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:526 from 678>
                  get_host_target(env) <SCons\Tool\MSCommon\vc.py:192 from 553>
                    get(self, key='HOST_ARCH', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:193>
                      return get(Environment.py:434) -> 'x86'
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:194>
                    get(self, key='TARGET_ARCH', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:206>
                      return get(Environment.py:434) -> None
                    debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:207>
                    return get_host_target(vc.py:226) -> ('x86', 'x86', None)
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:561>
                  get_msvc_version_numeric(msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:176 from 563>
                    <listcomp>(.0) <SCons\Tool\MSCommon\vc.py:190 from 190>
                      return <listcomp>(vc.py:190) -> ['1', '4', '.', '2']
                    return get_msvc_version_numeric(vc.py:190) -> '14.2'
                  join(path='C:\\Software\\MSVS142\\VC') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:571>
                    return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC\\Auxiliary\\Build\\Microsoft.VCToolsVersion.default.txt'
                  getpreferredencoding(do_setlocale) <lib\_bootlocale.py:11 from SCons\Tool\MSCommon\vc.py:573>
                    return getpreferredencoding(_bootlocale.py:14) -> 'cp1252'
                  __init__(self, errors) <lib\codecs.py:260 from SCons\Tool\MSCommon\vc.py:573>
                  decode(self, input, final) <lib\encodings\cp1252.py:22 from SCons\Tool\MSCommon\vc.py:574>
                    return decode(cp1252.py:23) -> '14.26.28801\r\n'
                  decode(self, input, final) <lib\encodings\cp1252.py:22 from SCons\Tool\MSCommon\vc.py:574>
                    return decode(cp1252.py:23) -> ''
                  join(path='C:\\Software\\MSVS142\\VC') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:587>
                    return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC\\Tools\\MSVC\\14.26.28801\\bin\\Hostx86\\x86\\cl.exe'
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:588>
                  exists(path='C:\\Software\\MSVS142\\VC\\Tools\\MSVC\\14.26.28801\\bin\\Hostx86\\x86\\cl.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:589>
                    return exists(genericpath.py:22) -> True
                  debug(self, msg) <lib\logging\__init__.py:1356 from SCons\Tool\MSCommon\vc.py:590>
                  return _check_cl_exists_in_vc_dir(vc.py:591) -> True

Post-processed combined all debug and trace output fragment (0b1111):
__call__(self, env) <SCons\Tool\__init__.py:269 from SCons\Environment.py:1844>
  generate(env) <SCons\Tool\default.py:40 from SCons\Tool\__init__.py:269>
    tool_list(platform, env) <SCons\Tool\__init__.py:1237 from SCons\Tool\default.py:40>
      FindTool(tools, env) <SCons\Tool\__init__.py:1140 from 1237>
        exists(env) <SCons\Tool\msvc.py:307 from SCons\Tool\__init__.py:1140>
        -----------------------------------------------------------------------------
          msvc_exists(env, version=None) <SCons\Tool\MSCommon\vc.py:950 from SCons\Tool\msvc.py:307>
            cached_get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:660 from 951>
              get_installed_vcs(env) <SCons\Tool\MSCommon\vc.py:669 from 664>
                debug(vc.py:673) trying to find VC 14.2
                find_vc_pdir(env, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:412 from 675>
                  find_vc_pdir_vswhere(msvc_version='14.2', env) <SCons\Tool\MSCommon\vc.py:359 from 444>
                    get(self, key='VSWHERE', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:379>
                      return get(Environment.py:434) -> None
                    msvc_find_vswhere() <SCons\Tool\MSCommon\vc.py:344 from 380>
                      exists(path='%ProgramFiles(x86)%\\Microsoft Visual Studio\\Installer\\vswhere.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:353>
                        return exists(genericpath.py:21) -> False
                      exists(path='C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:353>
                        return exists(genericpath.py:22) -> True
                      return msvc_find_vswhere(vc.py:357) -> 'C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe'
                    debug(vc.py:387) VSWHERE: C:\Program Files\Microsoft Visual Studio\Installer\vswhere.exe
                    debug(vc.py:392) running: ['C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe', '-version', '[16.0, 17.0)', '-property', 'installationPath']
                    run() <lib\subprocess.py:447 from SCons\Tool\MSCommon\vc.py:395>
                      return run(subprocess.py:513) -> CompletedProcess(args=['C:\\Program Files\\Microsoft Visual Studio\\Installer\\vswhere.exe', '-version', '[16.0, 17.0)', '-property', 'installationPath'], returncode=0, stdout=b'C:\\Software\\MSVS142\r\n', stderr=b'')
                    __del__(self, _maxsize, _warn) <lib\subprocess.py:875 from SCons\Tool\MSCommon\vc.py:395>
                    Close(self, CloseHandle) <lib\subprocess.py:202 from SCons\Tool\MSCommon\vc.py:395>
                    _remove(item, selfref) <lib\_weakrefset.py:38 from SCons\Tool\MSCommon\vc.py:395>
                    _remove(item, selfref) <lib\_weakrefset.py:38 from SCons\Tool\MSCommon\vc.py:395>
                    join(path='C:\\Software\\MSVS142') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:404>
                      return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC'
                    return find_vc_pdir_vswhere(vc.py:404) -> 'C:\\Software\\MSVS142\\VC'
                  debug(vc.py:448) VC found: '14.2'
                  return find_vc_pdir(vc.py:449) -> 'C:\\Software\\MSVS142\\VC'
                debug(vc.py:677) found VC 14.2
                _check_cl_exists_in_vc_dir(env, vc_dir, msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:526 from 678>
                  get_host_target(env) <SCons\Tool\MSCommon\vc.py:192 from 553>
                    get(self, key='HOST_ARCH', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:193>
                      return get(Environment.py:434) -> 'x86'
                    debug(vc.py:194) HOST_ARCH:x86
                    get(self, key='TARGET_ARCH', default) <SCons\Environment.py:432 from SCons\Tool\MSCommon\vc.py:206>
                      return get(Environment.py:434) -> None
                    debug(vc.py:207) HOST_ARCH:None
                    return get_host_target(vc.py:226) -> ('x86', 'x86', None)
                  debug(vc.py:561) host platform x86, target platform x86 for version 14.2
                  get_msvc_version_numeric(msvc_version='14.2') <SCons\Tool\MSCommon\vc.py:176 from 563>
                    <listcomp>(.0) <SCons\Tool\MSCommon\vc.py:190 from 190>
                      return <listcomp>(vc.py:190) -> ['1', '4', '.', '2']
                    return get_msvc_version_numeric(vc.py:190) -> '14.2'
                  join(path='C:\\Software\\MSVS142\\VC') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:571>
                    return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC\\Auxiliary\\Build\\Microsoft.VCToolsVersion.default.txt'
                  getpreferredencoding(do_setlocale) <lib\_bootlocale.py:11 from SCons\Tool\MSCommon\vc.py:573>
                    return getpreferredencoding(_bootlocale.py:14) -> 'cp1252'
                  __init__(self, errors) <lib\codecs.py:260 from SCons\Tool\MSCommon\vc.py:573>
                  decode(self, input, final) <lib\encodings\cp1252.py:22 from SCons\Tool\MSCommon\vc.py:574>
                    return decode(cp1252.py:23) -> '14.26.28801\r\n'
                  decode(self, input, final) <lib\encodings\cp1252.py:22 from SCons\Tool\MSCommon\vc.py:574>
                    return decode(cp1252.py:23) -> ''
                  join(path='C:\\Software\\MSVS142\\VC') <lib\ntpath.py:75 from SCons\Tool\MSCommon\vc.py:587>
                    return join(ntpath.py:113) -> 'C:\\Software\\MSVS142\\VC\\Tools\\MSVC\\14.26.28801\\bin\\Hostx86\\x86\\cl.exe'
                  debug(vc.py:588) checking for cl.exe at C:\Software\MSVS142\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe
                  exists(path='C:\\Software\\MSVS142\\VC\\Tools\\MSVC\\14.26.28801\\bin\\Hostx86\\x86\\cl.exe') <lib\genericpath.py:16 from SCons\Tool\MSCommon\vc.py:589>
                    return exists(genericpath.py:22) -> True
                  debug(vc.py:590) found cl.exe!
                  return _check_cl_exists_in_vc_dir(vc.py:591) -> True

At some point you'd just turnon pysnooper https://github.com/cool-RR/PySnooper and not add all this extra debug output..
I'm not sure this is a good way to go from first look...
I'll look in depth later.

Part of the utility is in diagnosing remote user problems.  Even the default settings contain a fair amount of useful information concerning a user's local msvc installations via the detection code.
It is not a burden to ask an end user to:

set SCONS_MSCOMMON_TRACE=trace.txt
run SCons
email/post the trace.txt output file.

Meanwhile, I have kind of dreamt about broadening the use of the logging module.  e.g. I think it would be nice if the tool detection/init were loggable.

In fact adding full tracing to this logic is something I'm unlikely to merge.
When pysnooper is available for such, why complicate our code.

Though I could be convinced..
Right now that output looks harder to deal with than the limited debugging we'd already added.
Logging everything doesn't always make it easier to find the issue.

Depending on the complexity of their scripts, it is not always going to be feasible for an end-user to send a simple SConstruct to reproduce detection errors.  Simply setting an environment variable and sending a file is a low-energy way to get feedback.
The existing logging leaves a little to be desired. In most cases you can't necessarily tell where the calls are coming from above the MSCommon module.  The timestamps also require manual removal when comparing two logs.
An example from #3723 is below.
It is my supposition that there is an unnecessary call in the following code from vs.py:
    def find_vs_dir_by_vc(self, env):
        SCons.Tool.MSCommon.vc.get_installed_vcs(env)    # <==== THIS IS UNNECESSARY
        dir = SCons.Tool.MSCommon.vc.find_vc_pdir(env, self.vc_version)
        if not dir:
            debug('no installed VC %s' % self.vc_version)
            return None
        return os.path.abspath(os.path.join(dir, os.pardir))

I stumbled upon this solely based on reviewing the call trees for the test cases.
This morning I ran test/msvs/vs-14.2-exec.py with and without the line marked above.  Note that the line in question was commented out so that the file locations did not change so the default output content did not have to be changed.
The combined debug/trace logs are attached:
mscommon-vs142exec-base-dtrace-0001.txt
mscommon-vs142exec-rem-dtrace-0001.txt
Without debug log timestamps, the files can be compared directly.  I use Araxis Merge.
There are 8 blocks in the base file that are not in the other file: the calls to get_installed_vcs.
There are 2 lines that are different:  the installed visual studio list and the installed sdk list which contain python object addresses (which is to be expected).
The trace logs/call trees have convinced me that the call to get_installed_vcs serves no purpose.  The call to find_vc_pdir does not use the same internal logic as the code to get_installed_vcs.  I willingly admit that I could be wrong and in general this kind of analysis could be fraught with erroneous assumptions.
I did the same two tests again include one frame "below" the MSCommon module and got similar results: 8 blocks for the call to get_installed_vcs and 4 lines that contain python addresses.
I cannot for the life of me figure out why that statement is called effectively in an inner loop.  Perhaps the original code should have been run with pysnooper.
Another example example is that the current "experimental" specific version code retains compatibility with the existing master via an optional on/off flag for the experimental code.  Comparing the trace output is one way to confirm that with the experimental code disabled that the code paths are the same as in the current master.
I am okay with the decision not to be incorporated.  I for one will maintain the branch with the trace code because I find the call tree useful.

Sample files of the same two runs with all extra trace information disabled (i.e., the minimum trace information):
mscommon-vs142exec-min-dtrace-0001.txt
mscommon-vs142exec-minrem-dtrace-0001.txt
The output is little more than placing the debug statements in context: without call list arguments, file name and line number locations, return values, or one frame below.
The second output was produced with the following batch file:
@setlocal

@set MYHOME=%~dp0
@set MYSCONS=E:\Git\Contrib\scons

@call :run_test mscommon-vs142exec-minrem test/msvs/vs-14.2-exec.py

@endlocal
@goto :EOF

:run_test

    @set TEST_PREFIX=%1
    @set TEST_NAME=%2

    @set MYDEBUG=%MYHOME%%TEST_PREFIX%-debug-#.txt
    @set MYTRACE=%MYHOME%%TEST_PREFIX%-trace-#.txt
    @set MYMERGE=%MYHOME%%TEST_PREFIX%-dtrace-#.txt

    @set SCONS_MSCOMMON_DEBUG=%MYDEBUG%
    @set SCONS_MSCOMMON_TRACE=%MYTRACE%
    @set SCONS_MSCOMMON_TRACEFLAGS=0b1111
    @set SCONS_MSCOMMON_TRACEFLAGS=0b0000

    @pushd %MYSCONS%
    @python runtest.py %TEST_NAME%
    @popd

    @python _debug_trace_merge.py %MYDEBUG% %MYTRACE% %MYMERGE%
    @goto :EOF

The invocation of run_test above produces 5 "triples" of output files (debug, trace, and dtrace).

Responding here without having looked at the patch/outputs - you do know you can tune the output style at the logger init point, right?  I had fiddled that from the previous form partly from personal need, partly from desire to get location-info (function name) out of the individual debug calls, where they were (inconsistently) placed before.

I did add a custom logging filter to the existing logging that produced the correct relative filename rather than the hard-coded MSCommon/{filename} as there are debug calls from outside of MSCommon (e,g, msvsTests.py) which produced an incorrect relative path in the log file (see comment above).
My own personal preference is that call trees/stack traces are formatted with the correct indentation which I figured would wreak  havoc with the existing file format.  I also expected that the preference would be to enable the current debug logging independently of the trace information.  The debug statements that were added to the experimental specific version code are more or less consistent with the existing debug format.
If the SCONS_MSCOMMON_TRACE environment variable is not defined and the debug logging base name does not end in "-#", the logging works as before with the exception that the correct relative filename is produced.  Debug logging can be enabled by itself, trace output can be enabled by itself, or they can both be enabled at the same time.
I'm just guessing, but I doubt that it was possible to produce the README document based solely on the existing debug log output files.  I'm also guessing that it might be possible to update the README based on the default (or full) trace output.
There is a pretty serious "barrier to entry" for anyone unfamiliar with the msvc detection inner machinations.  The existing log information may not be particularly helpful.
This will likely become apparent when it comes time to review and understand the 1400 lines of new code to support specific toolset versions.  There are some serious dark and dusty corner cases when trying to get the specific toolset version to follow the "law of least astonishment".  I was looking a little further down the road than the existing master.

Okay
Sent from my Samsung Galaxy smartphone.
-------- Original message --------
From: William Deegan notifications@github.com
Date: 8/3/20 3:22 AM (GMT+05:00)
To: SCons/scons scons@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Subject: Re: [SCons/scons] Extend and augment the internal-use only output logging capabilities in the MSCommon module. (#3743)
@bdbaddog commented on this pull request.

In SCons/Tool/MSCommon/common.pyhttps://github.com/SCons/scons/pull/3743#discussion_r464130303:

TRACE_DISPLAY_FUNCTION_ARGLIST   = 0b0001

TRACE_DISPLAY_FUNCTION_LOCATION  = 0b0010
TRACE_DISPLAY_RETURN_VALUES      = 0b0100
TRACE_DISPLAY_ALLFRAMES_ONEBELOW = 0b1000

default trace output

TRACE_DISPLAY_DEFAULT            = 0b0111

Typical usage:

'0b1111' or '15' display arg lists, file locations, return values, and all frames one below

'0b0111' or '7'  display arg lists, file locations, and return values [default]

'0b0101' or '5'  display arg lists, and return values

'0b0011' or '3'  display arg lists, and file locations

SCONS_MSCOMMON_TRACEFLAGS is internal-use so undocumented

TRACEFLAGS = int(os.environ.get('SCONS_MSCOMMON_TRACEFLAGS', str(TRACE_DISPLAY_DEFAULT)), 0)

Change this to be symbolic rather than a bitflag. Having to set 0b0111 is not user friendly.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/SCons/scons/pull/3743#pullrequestreview-459683295, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOKK4FUOEFCAKHHGUR44NHDR6XRJZANCNFSM4OYXMWSQ.

The default value for the trace display flags is now specified symbolically:
 # bitflags for selectively enabling trace output
 TRACE_DISPLAY_FUNCTION_ARGLIST   = 0b0001 # 1
 TRACE_DISPLAY_FUNCTION_LOCATION  = 0b0010 # 2
 TRACE_DISPLAY_RETURN_VALUES      = 0b0100 # 4
 TRACE_DISPLAY_ALLFRAMES_ONEBELOW = 0b1000 # 8

 # default trace output (numeric)
 TRACE_DISPLAY_DEFAULT = TRACE_DISPLAY_FUNCTION_ARGLIST | \
                         TRACE_DISPLAY_FUNCTION_LOCATION | \
                         TRACE_DISPLAY_RETURN_VALUES

The default value is only used when the SCONS_MSCOMMON_TRACEFLAGS environment variable is not defined or is empty.
The definition of the SCONS_MSCOMMON_TRACEFLAGS environment variable value was expanded to allow a combination of symbolic names for the trace display bitfields, numeric literals, bitwise operators, and numeric operators.  There are full and short forms for all of the symbolic names (i.e., with and without the "TRACE_DISPLAY_" prefix).  The environment variable value may be optionally be enclosed in pairs of balanced quotes.
For example, all of the following SCONS_MSCOMMON_TRACEFLAGS environment variable specifications evaluate to "15" and will produce the same output:
set SCONS_MSCOMMON_TRACEFLAGS=15
set SCONS_MSCOMMON_TRACEFLAGS=0b1111
set SCONS_MSCOMMON_TRACEFLAGS=0xF
set SCONS_MSCOMMON_TRACEFLAGS="1+2+4+8"
set SCONS_MSCOMMON_TRACEFLAGS="1|2|4|8"
set SCONS_MSCOMMON_TRACEFLAGS="1<<0|1<<1|1<<2|1<<3"
set SCONS_MSCOMMON_TRACEFLAGS="FUNCTION_ARGLIST|FUNCTION_LOCATION|RETURN_VALUES|ALLFRAMES_ONEBELOW"
set "SCONS_MSCOMMON_TRACEFLAGS=TRACE_DISPLAY_FUNCTION_ARGLIST|TRACE_DISPLAY_FUNCTION_LOCATION|TRACE_DISPLAY_RETURN_VALUES|TRACE_DISPLAY_ALLFRAMES_ONEBELOW"

Move all this logic out of MSCommon/common.py
To MSCommon/trace.py
Or maybe this should even be in Util..
To be honest.. I'm not even still sure this is a good idea.
As I've said before pysnooper does a lot of this and we don't have to maintain it at all.
A debugger is also another way to get this info.
@mwichmann @dirkbaechle @garyo - Thoughts?

I will look into moving it out of MSCommon.  Unfortunately, it is intimately tied to the MSCommon module (and below) for reporting the trace information.  Based on the user-specified environment variables it is also tied to the debug file name (i.e., there is some code used to configure both the debug and trace filenames).
As I said above, I am okay with the decision not to be incorporated. I will maintain my own branch with the trace code because I find the limited function call tree useful.  The way it is written makes it fairly easy to merge with the master MSCommon code.
Multiple trace files can be produced for each invocation of SCons when running the msvc/msvs specific tests.  The trace files are also a vehicle for comparing the msvc detection behavior across code changes.  The proposed code was generalized based on code written for the experimental msvc specific toolset version support used to compare the specific version output directly with the master output.
Sooner or later, especially with specific toolset version support, there may come a time when it is not easy to replicate an end-user problem/configuration without putting an undue burden on the user.  There may not be the luxury of having an end-user run pysnooper or a debugger.
In the end it is a matter of philosophy:  "give me everything I need to reproduce the problem" versus "turn this on and send me the output and we'll go from there".
#3723 is a pretty good test case.
In the interest of full disclosure, I have not used pysnooper to evaluate that particular issue.  I am guessing that no one else has either.

Random cherry-picks to respond:

A debugger is also another way to get this info.

A debugger isn't great when the module is spaghetti, you pull one strand and what's at the other end isn't the answer you wanted, but more twists.
Not advocating to do this work, just commenting:

Based on the user-specified environment variables it is also tied to the debug file name (i.e., there is some code used to configure both the debug and trace filenames)

a slightly higher-level trace facility could tie modules to trace file names in a config file and the ability to turn each on/off. Would be cool. And would take work which @bdbaddog would probably (correctly) point out could be spent on actual bugs/features...  There are homegrown bits scattered all over right now.

For consideration, there is a minor organizational change to the debug output and trace output support that may be viewed as more palatable.
The debug output and trace output source code have been removed from the MSCommon/common.py source file and moved into separate source files in an internal subfolder (i.e., MSCommon/internal).
This allows independent updates to the debug and trace source code isolated from the existing MSCommon source files.
This also allows the trace output to be excised easily if and/or when it is decided that the trace functionality will not be included in the SCons source tree.
Limited testing has shown that the combined debug/trace output is effectively the same when comparing the output both before and after the code changes.
MSCommon/common.py
The debug logging code was moved to MSCommon/internal/debug.py
The debug function is imported from the internal module and therefore does not affect existing code.
from .internal import debug

MSCommon/internal/init.py
The internal MS configuration object contains a boolean flag indicating if the trace module is enabled or disabled.  The trace module is only imported when trace output is enabled.  When disabled there is no initialization processing cost.
from .config import _MSCONFIG

from .debug import debug

if _MSCONFIG.TRACE_ENABLED:
    from .trace import trace

MSCommon/internal/config.py
The internal MS configuration object is responsible for determining if the debug output is active, the trace output is active, and synchronization of the output file names if necessary.
_HAVE_DEBUG = True
_HAVE_TRACE = True

class _MSCONFIG:

    # SCONS_MSCOMMON_DEBUG is internal-use so undocumented:
    # set to '-' to print to console, else set to filename to log to
    DEBUG_LOGFILE = os.environ.get('SCONS_MSCOMMON_DEBUG')

    # SCONS_MSCOMMON_TRACE is internal-use so undocumented:
    # set to '-' to print to stderr, else set to filename to log to
    TRACE_LOGFILE = os.environ.get('SCONS_MSCOMMON_TRACE')

    # SCONS_MSCOMMON_TRACEFLAGS is internal-use so undocumented
    # refer to the internal trace source file for details
    TRACE_TRACEFLAGS = os.environ.get('SCONS_MSCOMMON_TRACEFLAGS')

    # debug configuration
    DEBUG_ENABLED = True if _HAVE_DEBUG and DEBUG_LOGFILE else False
    DEBUG_STDOUT  = True if _HAVE_DEBUG and DEBUG_ENABLED and DEBUG_LOGFILE == "-" else False
    DEBUG_LOGGING = True if _HAVE_DEBUG and DEBUG_ENABLED and not DEBUG_STDOUT else False

    # trace configuration
    TRACE_ENABLED = True if _HAVE_TRACE and TRACE_LOGFILE else False
    TRACE_STDERR  = True if _HAVE_TRACE and TRACE_ENABLED and TRACE_LOGFILE == "-" else False
    TRACE_LOGGING = True if _HAVE_TRACE and TRACE_ENABLED and not TRACE_STDERR else False

... <more code follows>

If it is decided that the trace output will not be included in the SCons distribution:

_HAVE_TRACE = False
delete trace.py from the MSCommon/internal folder

This allows the trace module to be disabled entirely without deleting the source file.  It also makes it easier to locally "patch in" the trace functionality if the trace source file is not included in the SCons distibution.
MSCommon/internal/debug.py
The debug code was moved from MSCommon/common.py to a stand-alone debug.py source file.
The debug code contains:

a few more blank lines for readability
the fix to produce the proper "module-relative" path name via the logging module
the ability to synchronize the debug output file name with the trace output file name
the ability to produce a new debug output file for each launch of SCons which is useful when running the tests

MSCommon/internal/trace.py
The trace code was moved from MSCommon/common.py to a stand-alone trace.py source file.

Both Sider issues with MSCommon/internal/__init__.py are "necessary":

'debug.debug' imported but unused
'.trace' imported but unused

debug is imported and used by the MSCommon/common module.  It is not used locally in MSCommon/internal/__init__.py (i.e., it is "passed-through").
trace is imported by MSCommon/internal/__init__.py and is "self-activated" via module initialization.

@bdbaddog go ahead an close this PR.  I don't know if I am allowed to close it or not.

You should always be able to close your own PRs

authors: BrilliantAsad007 bdbaddog jcbrill mwichmann

repo: SCons/scons


text:
Remove or change auto-email after submitting newsletter sign-up

Currently, a "thank you for contacting us" email is sent to people after signing up for Newsletter. This is very confusing and needs to either be stopped or changed.
If changed, it would need to read with a subject line: "You are now subscribed!"  And a body that starts with: "Thank you for subscribing to the SDRT newsletter."
Currently what is sent out looks like this:

@JasonTheAdams  Sorry it took me a while to get to this! So, yes, this is still happening; I just tested it out. The confirmation email is in the Caldera Forms template, so I'm thinking it is a Caldera Forms integration through Mailchimp and needs to be removed on the Mailchimp side. I will make time to look into this on Mailchimp next week; I just need to confirm login info with Melissa.

@JasonTheAdams I tested this again

@JasonTheAdams I tested this again and there now seems to be only automated emails from Mailchimp being sent and not the above Caldera forms-looking auto message.

repo: SDRefugeeTutoring/sdrt-custom-functions

license: Unlicense


text:
💡 [REQUEST] -

Start Date
11/08/2022
Implementation PR
No response
Reference Issues
No response
Summary
Create a search scene javaFX controller
Basic Example
This will allow us to control the scene's transitions and buttons
Drawbacks
No response
Unresolved questions
No response

Dependent on #21.

Superseded by #54.