WD1.3 download cell

still haven't been able to properly get the notebook working lmao but this should more or less work as a cell for WD1.3
user_token = "<put your user token here>"

# ===============================================================================================
%store -r free_tier model_storage_dir repo_storage_dir activate_xformers
!wget --header="Authorization: Bearer {user_token}" https://huggingface.co/hakurei/waifu-diffusion-v1-3/blob/main/wd-v1-3-full.ckpt -O "{model_storage_dir}/wd-v1-3-full.ckpt"```

You don't need authentication to download it.


Readme

You can see the updated readme here: https://github.com/rdvelazquez/hyphy-gui/tree/readme

Looks nice! I was able to download and test the app. Now we need to get HyPhy to run as web asm:)


Can't import pyarrow 0.14.0 due to mismatching libcrypt

I have tried posting to the dev list, but my email seems to be not going through, since I'm not sure if it's something I'm doing wrong, I opened this issue instead of a JIRA.
Problem description
In a freshly created virtual environment, after I install pyarrow 0.14.0 (using pip), importing pyarrow from the python prompt leads to the following:
$ python3 -m pyarrow
Traceback (most recent call last):
  File "/usr/lib64/python3.7/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib64/python3.7/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib64/python3.7/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/home/suvayuali/.virtualenvs/pa-0.14.0/lib/python3.7/site-packages/pyarrow/__init__.py", line 49, in <module>
    from pyarrow.lib import cpu_count, set_cpu_count
ImportError: libcrypt.so.1: cannot open shared object file: No such file or directory

Comments
This is surprising because I have older versions of pyarrow (up to 0.13.0) working, and libcrypt on my system (Fedora 30, Python 3.7) is libcrypt.so.2!
Am I missing something?

Can you please open a JIRA issue?

Also, you need to be subscribed to the email list to post to it, so that may be your issue.

@wesm I'm subscribed, I have posted to the list before.
I'll open a JIRA issue.

Here's the issue on JIRA: https://issues.apache.org/jira/browse/ARROW-5871


Layers: Widget Position Stored as NaN

Hi,
The issue occurs when CurrentCulture displays decimals as ",". For example spanish.
Then the javascript Number function returns Nan when the operations to calculate widget position are done.

I made a PR #684


Fix method call in getter/setter example

Added this to verifyIfAmountCanBeSetted otherwise you get ReferenceError

Thanks Mark!


add 2002 primary BOE candidates

Starting on pg. 84 of this document:

WOODS, MAX
BRIERLY, ELIZABETH C
BENDICK, MARK S.
ANGELO, NORMAN
GRAHAM, J.R.
CHRISTIAN-HEISING, MARY
BAKEER, EMAD J.
WEISSMAN, KENNETH A.

Coverage remained the same at 88.552% when pulling 5ea0abc5fdbf301f1ceac40aef8b9dee7d2fb967 on cjwinchester:patch-1 into d3bae9624ecfd5e926a1ec3062f581deed37fd72 on california-civic-data-coalition:master.

You're in. Send your mailing address to<EMAIL_ADDRESS>to receive your prize.

yessssss


Add metadata component package yml

This PR adds a metadata file to the repo that specifies the component packages that are generated as part of the assets in release work flow

Withdrawing this PR as component packages that are generated as part of the assets in release work flow will be read from centralized file


move deserialize into remote finder

This addresses the issue outlined in #2352 by moving the deserialize functions into the remote finder and using them in find_nodes.
While this code passes all tests I have not actually tried it yet and would appreciate feedback from anyone who has time to experiment with it.

Codecov Report

Merging #2354 into master will decrease coverage by 0.01%.
The diff coverage is 82.92%.

@@            Coverage Diff             @@
##           master    #2354      +/-   ##
==========================================
- Coverage   79.54%   79.53%   -0.02%
==========================================
  Files          85       85
  Lines        8899     8887      -12
  Branches     1901     1899       -2
==========================================
- Hits         7079     7068      -11
+ Misses       1558     1557       -1
  Partials      262      262

Impacted Files
Coverage Δ

webapp/graphite/readers/remote.py
100% <100%> (+8.98%)
:arrow_up:

webapp/graphite/finders/remote.py
95.62% <82.5%> (-3.72%)
: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 17e2e1f...6c275a9. Read the comment docs.

just FYI: trying to create simple docker compose to test cluster from 3 nodes

The tags stuff also uses the finder request method, so I'm not going to try and shoehorn the de-serialization in there also at the moment.

As far as I can tell this is working correctly, any objections to merging it @deniszh ?

No objections. :)


Use AppVeyor for continuous integration in Windows environment

AppVeyor build currently broken - https://github.com/yandex-qatools/postgresql-embedded/issues/86

PostgreSQL problems over by using AppVeyor PostgreSQL service. There is a problem now with MySQL.


Initial draft of the tool for getting the address of a dapp’s main smart contract interface

The requirements are different for a standard contract vs. a ZOS-style delegateproxy upgradeable contract

Perhaps make use of ERC820

Related: https://api.stateofthedapps.com/dapps/augur

Paraphrasing from a convo with State of the Dapps team on Intercom:
How does State of the Dapps fetch the mainnet contract addresses for a given project? Manual curation? Crowdsourced? An API from another data source? Thanks!
All options possible. Typically a project provides it themselves when they submit their dapp, sometimes they (the State of the Dapps team) find it themselves. If it is frequently updated or if many addresses are used with typically use an API to sync it
Projects that provide their mainnet contract addresses rank higher, so there is an incentive for providing it and keeping it up to date
State of the Dapps API docs:
https://state-of-the-dapps.github.io/slate/
It's not completely documented, but sufficient for a lot of usecases.
Oh, and what API do you use?
We can hook into an API provided by projects themself to parse CSV, JSON or GraphQL endpoints to ingest their contracts
Oh okay, so it's not like Etherscan or anything
This is on a per project basis. Nothing generic


Do users feel safe paying the council online?

Worth also trying to see if GOV.UK Pay branding helps with this.

When paying via the GOV.UK Pay prototype above, yes. Need to test with more realistic payment screens

link to #566

@sanjaypoyzer as discussed with you and Stephen, please include GOV.UK Pay in the prototype for next round of user testing or later.


Remove Orphaned Constants

The following is a list of constants that appear to be defined but never referenced. This list is thought to be conservative because it was produced without being concerned by module namespaces. So if ClassOne::CONSTANT is defined, but ClassTwo::CONSTANT is all that is ever referenced, ClassOne::CONSTANT would be left off of this list because of the reference even though it does not belong to the right namespace.
We should:

Remove all of these constants from the code base
Refactor the unit test(s) that reference NEWRELIC_ID_HEADER to either have the test class define the constant or remove the tests if they only pertain to the constant
Run CI checks to verify everything still works

Constants

MYSQL_EXPLAIN_COLUMNS

./lib/new_relic/agent/database.rb:10

WEB_ROLLUP_METRIC

./lib/new_relic/agent/datastores/metric_helper.rb:9

OTHER_ROLLUP_METRIC

./lib/new_relic/agent/datastores/metric_helper.rb:10

MONGO_PRODUCT_NAME

./lib/new_relic/agent/datastores/mongo/metric_translator.rb:59

POUND

./lib/new_relic/agent/distributed_tracing/distributed_trace_payload.rb:21

ALL_QUEUE_METRIC

./lib/new_relic/agent/instrumentation/queue_time.rb:14

NEWRELIC_ID_HEADER (NOTE: used, but only by tests)

./lib/new_relic/agent/monitors/cross_app_monitor.rb:14

VALID_PREFIX_SEGMENT_COUNT is possibly orphaned.

./lib/new_relic/agent/rules_engine/segment_terms_rule.rb:13

GRANDPARENT_ID_KEY

./lib/new_relic/agent/span_event_primitive.rb:23

NO_SAMPLES

./lib/new_relic/agent/transaction/transaction_sample_buffer.rb:11

TRANSACTION_NAMING_SOURCES

./lib/new_relic/agent/transaction.rb:39

DEFAULT_PRODUCT_NAME

lib/new_relic/agent/datastores/metric_helper.rb:12

#1408 has taken care of the lion's share of these. Here's an updated list:

[ ] MYSQL_EXPLAIN_COLUMNS
./lib/new_relic/agent/database.rb:10
[X] WEB_ROLLUP_METRIC
./lib/new_relic/agent/datastores/metric_helper.rb:9
[X] OTHER_ROLLUP_METRIC
./lib/new_relic/agent/datastores/metric_helper.rb:10
[X] MONGO_PRODUCT_NAME
./lib/new_relic/agent/datastores/mongo/metric_translator.rb:59
[X] POUND
./lib/new_relic/agent/distributed_tracing/distributed_trace_payload.rb:21
[X] ALL_QUEUE_METRIC
./lib/new_relic/agent/instrumentation/queue_time.rb:14
[ ] NEWRELIC_ID_HEADER (NOTE: used, but only by tests)
./lib/new_relic/agent/monitors/cross_app_monitor.rb:14
[ ] VALID_PREFIX_SEGMENT_COUNT is possibly orphaned.
./lib/new_relic/agent/rules_engine/segment_terms_rule.rb:13
[X] GRANDPARENT_ID_KEY
./lib/new_relic/agent/span_event_primitive.rb:23
[X] NO_SAMPLES
./lib/new_relic/agent/transaction/transaction_sample_buffer.rb:11
[X] TRANSACTION_NAMING_SOURCES
./lib/new_relic/agent/transaction.rb:39
[X] DEFAULT_PRODUCT_NAME
lib/new_relic/agent/datastores/metric_helper.rb:12

All orphaned constants references in this ticket have been completed! Thanks to @esquith for wrapping this up.


Add test for "contains" with false "if" subschema

An intermediate solution to a problem I've been working on had contains failing when an if subschema failed.
My implementation only supports drafts 2019-09 and 2020-12, so I'm not 100% sure that this is a valid test for draft6 and draft7.

"contains" is valid from draft 6 onwards; please could you add these tests to draft2019-09 and draft2020-12 also? thanks.

(erroneous comment deleted)

These two commits (with slightly different messages) can be merged together into one.

Done!

@marksparkza 's implementation had a different behaviour:

An intermediate solution to a problem I've been working on had contains failing when an if subschema failed.

..so it sounds like perhaps his handling of 'if' was incorrect? perhaps the tests should be moved to if.json.

@jdesrosiers

The if/else doesn't affect the behavior of contains in any way

The if/else shouldn't affect the behavior of contains in any way, but in my implementation it did. I was passing all tests, but had a hunch that I'd missed something. So I wrote this test, which my implementation failed.
By way of explanation:
In solving a larger problem (I was losing annotations and errors for array items, even though validation was being done correctly), I'd modified my contains implementation in such a way that it did not account for the behaviour of non-asserting keywords - not if specifically, though that's the only relevant case. I've since revised my implementation such that keyword non-assertion is dealt with transparently with respect to other keywords.
@karenetheridge
This was specifically a problem with the way my contains implementation processed its own subschema, so I think contains.json is the right place for the test. I think the more general problem of a subschema not being false if if is false is probably adequately covered by the first test ("ignore if without then or else") in if-then-else.json.

If it's exposing a real bug, that's good enough for me. Carry on.

The above sounds reasonable to me (if it was a real bug an implementation had, we generally I think merge these kinds of things).
Merging, thanks!


Install hanging on loading UI components

Install hanging on loading UI component

s

Can you please send a screenshot?

[cid:2d4a719a-ce4c-4cd3-9601-39f36a7cac86]

Van: Martí Climent @.>
Verzonden: vrijdag 15 juli 2022 11:28
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
Can you please send a screenshot?
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1185358521, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJM46SZM5WSA3IIVAQLVUEVK5ANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

Hi, can't see the image

Van: Martí Climent @.>
Verzonden: vrijdag 15 juli 2022 13:08
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
Hi, can't see the image
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1185438362, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJPQYA7QANDBWM45UHDVUFBCXANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

Can you please attach the image as an URL or upload it to GitHub? It looks like email interactions don't work very well...

Hi, this hang is permanent? Or it dures for a few seconds? Because this is expected, since the program has to load appproximately 5000 software entries

Its hangs permanent after about 3250 packeges

Van: Martí Climent @.>
Verzonden: vrijdag 15 juli 2022 16:00
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
Hi, this hang is permanent? Or it dures for a few seconds? Because this is expected, since the program has to load appproximately 5000 software entries
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1185575981, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJLHWJQYNKPSHRUIRH3VUFVIVANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

What are your PC specs?

HP Intel(R) Core(TM) i7-8700T CPU @ 2.40GHz   2.40 GHz
16,0 GB (15,8 GB beschikbaar)
Windows 11 Pro Insider Preview DEV

Van: Martí Climent @.>
Verzonden: vrijdag 15 juli 2022 20:38
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
What are your PC specs?
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1185808461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJIENLGJN5JKIRXEL6LVUGV37ANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

Could you please test version 1.4.2?

I have done and issues found

Van: Martí Climent @.>
Verzonden: dinsdag 11 oktober 2022 10:34
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
Reopened #86https://github.com/martinet101/WingetUI/issues/86.
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#event-7560311052, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJLUDSONB5EGVSGQVALWCURAVANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

And no error report window pops up?
Can you try fully uninstallling, removing the .wingetui folder present in %userprofile% and then installing again?

No error report windows great app

Van: Martí Climent @.>
Verzonden: dinsdag 11 oktober 2022 10:49
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
And no error report window pops up?
Can you try fully uninstallling, removing the .wingetui folder present in %userprofile% and then installing again?
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1274334408, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJMVRDSZPFGB7COYWJLWCUS2HANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

So Is the app working again or it still fails?

The app is working again

Van: Martí Climent @.>
Verzonden: dinsdag 11 oktober 2022 16:14
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
So Is the app working again or it still fails?
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#issuecomment-1274761551, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJN32OD3FVHQQWLUDI3WCVY6BANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>

Yes perfect app thanks

Van: Martí Climent @.>
Verzonden: dinsdag 11 oktober 2022 18:06
Aan: martinet101/WingetUI @.>
CC: aadvanraamt @.>; Author @.>
Onderwerp: Re: [martinet101/WingetUI] Install hanging on loading UI components (Issue #86)
Closed #86https://github.com/martinet101/WingetUI/issues/86 as completed.
—
Reply to this email directly, view it on GitHubhttps://github.com/martinet101/WingetUI/issues/86#event-7564376212, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFPOFJMWXRLHDKTHMH5JNZ3WCWGA3ANCNFSM53UP3VXA.
You are receiving this because you authored the thread.Message ID: @.***>


Add OL-map based symbolizer preview

This adds a symbolizer preview realized as OpenLayers map. The preview component expects somes features (GeoJSON) and a symbolizer to define the style of the features on the map.
Also a predefined OpenLayers map instance or an array of OpenLayers layers can be passed in to customized the setup of the map.

Thanks for reviewing @KaiVolland!

As you can add a complete map, you could add one without the controls right?

Yes that's possible. Or would you prefer a map without (visible) controls as default?

Yes i would prefer the default to be just one feature with out controls and without a Backroundlayer. As I would like to add a preview of the complete style in a full map preview later on...
But this should not block this PR.

I just added a further commit , which removes the controls and interactions from the default map of the
SymbolizerPreview. Therefore they can be configured by the new props controls and interactions.
The background layer can be removed by setting the property showOsmBackground to false.
I am going to merge this now.


feature: 新版 IP 选择器后台接入 (closed #1040)

Codecov Report

:exclamation: No coverage uploaded for pull request base (V2.2.30-rc@6062b44). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             V2.2.30-rc    #1183   +/-   ##
=============================================
  Coverage              ?   49.03%
=============================================
  Files                 ?       91
  Lines                 ?     5651
  Branches              ?        0
=============================================
  Hits                  ?     2771
  Misses                ?     2880
  Partials              ?        0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Use ndb.Key.urlsafe() as Graph Node IDs

Coverage increased (+0.03%) to 93.722% when pulling f8bfce41d18a28b0337e5c32d885fbeae199d750 on feature/ndb_key_urlsafe_support into 82e6b5b22063a5007bc3486e7e95e64a86cdc1b6 on master.

Coverage increased (+0.03%) to 93.722% when pulling 92b372119eadcabacfe16d3cf2ffc29945676b50 on feature/ndb_key_urlsafe_support into 82e6b5b22063a5007bc3486e7e95e64a86cdc1b6 on master.


Hint about possibly-omitted "var" keyword for assignments to unknown properties?

I've found myself accidentally writing code like this on several occasions:
class Test(xyz: Integer)
{
        @xyz = xyz
}

where the var keyword is accidentally omitted before the @xyz = xyz assignment.
Lily (4973a917612c85f24be2f852af2f75f0f2722cad) gives an error like:
$ ../lily var.lly
SyntaxError: Property xyz is not in class Test.
    from var.lly:3
$

I find that it isn't immediately obvious that it's the missing "var" keyword that's causing the error.
For assignments to an unknown property like that, maybe the error message could hint that the "var" keyword may be missing, perhaps something like:
SyntaxError: Property xyz is not in class Test. ('var' keyword may be missing.)

Seems reasonable and consistent with the return missing a type message.


build: configure Renovate for v18 with shared preset

Issue or need
Update dependencies but only if compatible with Angular v18

Proposed changes
Update Renovate config with Angular v18 shared preset + use 18 major for @angular pkgs

Quick reminders

🤝 I will follow Code of Conduct
✅ No existing pull request already does almost same changes
👁 Contributing docs are something I've taken a look at
📝 Commit messages convention has been followed
💬 TSDoc comments have been added or updated indicating API visibility if API surface has changed.
🧪 Tests have been added if needed. For instance, if adding new features or fixing a bug. Or removed if removing features.
⚙ API Report has been updated if API surface is altered.

#626  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite

Notice branch name is renovate/reconfigure to trigger Renovate validation
https://docs.renovatebot.com/config-validation/


bf16 training examples

benchmark on 3090/4090

[ ] on hlb_cifar bf16 is 10% slower than half
[ ] resnet training in bf16 produces nan errors

both are fixed. bf16 is 2% faster now on resnet


DbOpener implementation in heavy traffic

Options:

LRU cache
Strategy API
Gateway sticky session routing

Not worth to use each database instance for each tenant.
Probably need PaaS instead of Saas

It is hard to change database dynamically by using the same instance datasource without database name specifically

Use LRU cache now
Gateway sticky session routing is suggested


Add edit functionality for person's phone number

Using the edit command, a person's phone number may be changed by the user.
Command Format
edit INDEX p/NEW_NUMBER
where INDEX is an int representing the current index the person is stored at, and NEW_NUMBER is a string of a new phone number, which is validated by the default parser.
The default privacy of the new phone number is set to public.

@imhongw @wengkiat to review.


Community Hub

Hey,
I just want to start by saying I think this framework is absolutely fantastic. I am just wondering if there are any plans for a discord server /slack channel to discuss topics relating to ngfx? It would be great to discuss project ideas / issues / post screenshots of cool work powered by this framework with a wider group of developers. Thanks!

Thank you so much for the feedback! Sorry for the late response, I just noticed your message.  We can start a discord channel.
Cheers,
Jeff


Great job, looking forward to the release of the code!

@utkarshmall13 Do you have an ETA on your code release?

Hi @Jack-bo1220 and @Jack-bo1220 , the code/data/pretrained mode is released now! thanks for your patience.


fix: cvflatbutton active color does not change in dialog

Fixes #233
Describe the changes you have made in this PR -
There was a bug in package:mobile_app/ui/components/cv_flat_button.dart .
The foregroundColor was set to grey by default.  That's why the color of the button was not changing on state change.
Screenshots of the changes (If any) -
https://user-images.githubusercontent.com/78409764/188433775-eb043b0b-a228-4ce7-b971-16cc1dc84d3c.mp4
Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

@Aditya-150 Run the command "flutter format ." in the project's home directory. And commit the changes.

@Aditya-150 Run the command "flutter format ." in the project's home directory. And commit the changes.

Thanks @aman-singh7  for pointing out that. I just forgot to format the file.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 4 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 66.134%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/ui/components/cv_flat_button.dart
2
4
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
4017

Relevant Lines:
6074

💛  - Coveralls

Hey, @aman-singh7 sorry for disturbing for you. But can you review it.. #240 #233

Thank you for your contributions @Aditya-150, Initial impressions of the code looks good. I will review and test it very soon.


Added movie search engine example (GSoC)

Hello @sebawita ,
-I fixed the typo error
-By example folder, I meant the folder of this code, basically where add_data.py resides. So i mentioned that in readme also
-The dowload_poster.py had no role in this demo. That was the file that was created for the poster image reverse searching feature which we initially discussed but then dropped. Somehow that file made it in the initial commit but now I have deleted it.
-I made the deleting of the schema class as conditional. It will search for all the schema classes present and delete the 'Movies' class if found.


variantFilter causing an issue.

Cloning this and opening in Android Studio 1.5.1 I get the following error:
Error:(35, 0) No signature of method: java.lang.String.variantFilter() is applicable for argument types: (build_8svktq4s2wa741jcavj9ayd99$_run_closure1_closure8) values: [build_8svktq4s2wa741jcavj9ayd99$_run_closure1_closure8@191ee85a]

This refers to the app/build.gradle line
// Remove mockRelease as it's not needed.
android.variantFilter { variant ->
    if(variant.buildType.name.equals('release')
            && variant.getFlavors().get(0).name.equals('mock')) {
        variant.setIgnore(true);
    }
}

I tried changing android.variantFilter to applicationVariants.all which then moved the problem to getFlavors().
Am I using the wrong version of gradle?

Is this still an issue with 2.0/2.1, I actually cannot reproduce it.

Closing this issue for now, please re-open if you think this is still an issue.


[build] package.json in lib/indexers has unresolved botbuilder-expression-parser

Complete the necessary portions of this template and delete the rest.
Describe the bug
Give a clear and concise description of what the bug is.
Version
What version of the Composer are you using? Paste the build SHA found on the about page (/about).
Browser
What browser are you using?

[ ] Chrome
[ ] Safari
[ ] Firefox
[ ] Edge

OS
What operating system are you using?

[ ] macOS
[ ] Windows
[ ] Ubuntu

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
Give a clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots/gif/video to help explain your problem.
Additional context
Add any other context about the problem here.

@hailiu2586 we don't think this is an issue. Can you refer to @a-b-r-o-w-n 's guidance in #1714 ?

fixed in https://github.com/microsoft/BotFramework-Composer/pull/1737


onSubmit does not seem to work

I tried to copy the example form component from examples/events and just can't get the onSubmit event to fire. I also noticed it was not covered in the tests so there was not an easy way to check if I was doing something wrong.
Example:
http://requirebin.com/?gist=99fdbeb84c1ecd0a81a3

Oh! Looks like you're trying to set the class with the element type. We removed this feature a while back. We need to update those examples.
You need to just do dom('form', ...), not dom('form.box' ...)


[BUG] MTP crashes with Synergy Extrapolation

Steps to reproduce
Create an MTP xml file with synergy extrapolation enabled.
Expected result
The GUI creates an xml file with the element <residual_categorization> under
Actual result
The generated xml does not have <residual_categorization>
(include screen grabs where appropriate)
Environment and GUI version
Windows 11, Opensim 4.5, GUI version 0.1

A couple follow up questions while fixing the code:

Do you prefer the XML comment to use lower case (task, trial, or subject)?
What is the default choice as I need to have it populated so it gets written to the file?

Thanks for the find.

Yes, we prefer the xml comment uses lowercase task, trial, or subject.
The default choices should be trial for <synergy_extrapolation_categorization> and task for <residual_categorization>

The output xml should look like this:

<synergy_extrapolation_categorization>trial</synergy_extrapolation_categorization>

<residual_categorization>task</residual_categorization>
Thank you!

Fixed in latest commit, will close to reduce clutter,  please reopen if can't be verified in next release/iteration


DHCP not working on several chips

I used SOFTAP + DHCP + HTTP server on one ESP12E module and everything worked fine. Then I flashed same firmware on other ESP12E modules and what's weird now DHCP doesn't work. When I assign static IP on host (my computer) I can succesfully connect to HTTP server. I used earlier the first ESP12E module with espressif SDK. Could it be problem with blank.bin and esp_init_data_default.bin files?

Could it be problem with blank.bin and esp_init_data_default.bin files?

Do you flash those files during the firmware download process?

On the working ESP module I did not do that and everything worked fine, but I flashed them earlier and I don't think that they were erased (it's just my guess - I don't know if while flashing whole Flash is erased or only those blocks where FW will be written) and I also do not do that on new modules.
I checked it and flashed also those files, but DHCP is still not working.

No worries, under powering devices is a useful experience ;)

However, sorry one more time, because it is not issue with power supply. :(
I'm flashing three chips with same file and dhcp won't work on two of them. I checked on the same power supply and DHCP is not working even then. What's not common in this case - I bought the working one earlier and next two ESP12E modules (those not working) in one purchase order.
On the working chip when I connect to AP I get this log output:
station: MY:MA:CA:DD:RE:SS join, AID = 1
State dump. Message type 3
Nonetheless, when I connect to AP on not working chip I get this log output:
station: MY:MA:CA:DD:RE:SS join, AID = 1
State dump. Message type 1
So there is a difference in "Message type". Implementation I use:
	sdk_wifi_set_opmode(STATIONAP_MODE);
	struct ip_info ap_ip;
	IP4_ADDR(&ap_ip.ip, 192, 168, 1, 1);
	IP4_ADDR(&ap_ip.gw, 0, 0, 0, 0);
	IP4_ADDR(&ap_ip.netmask, 255, 255, 255, 0);
	sdk_wifi_set_ip_info(1, &ap_ip);

	struct sdk_softap_config ap_config = {
		.ssid = WIFI_SSID,
		.ssid_hidden = 0,
		.channel = 9,
		.ssid_len = strlen(WIFI_SSID),
		.authmode = AUTH_WPA_WPA2_PSK,
		.password = WIFI_PASS,
		.max_connection = 3,
		.beacon_interval = 100,
	};
	//sdk_wifi_station_disconnect();
	sdk_wifi_softap_set_config(&ap_config);

	ip_addr_t first_client_ip;
	IP4_ADDR(&first_client_ip, 192, 168, 1, 2);
	dhcpserver_start(&first_client_ip, 3);

What can I do straighten this situation?

have you found any solutions to this? I am facing the same problem!

Use wireshark etc to watch what is happening on the network and look for the start of the problems. When you have some clues then hopefully it is something at a higher layer in lwip or the dhcp client that can be debugged. Try to narrow it down by restricting the mode to station mode.


Move Servers to a top-level TOC section

Fixes #28988

No page summarizes the different servers. We can add an Overview page if there is a dedicated Servers section.

We have an overview of the servers in Fundamentals - I moved that to the Overview node of the new top-level Servers section. This overview article already compares Kestrel to HTTP.sys, and we can add comparison section(s) to address #28948.
Internal review URL

I don't really understand how we decided what gets to be a top-level node and I've never actually made a web app, so take this with a grain of salt.
I like the idea of grouping those pages together, but why would we make them top-level?  They don't seem like something an implementer would immediately need to understand?  If you're not on Windows, you don't have a choice anyway and if you are, the templates provide sensible defaults.  It seems like only Advanced users or people digging into Fundamentals would need more information about the different options and why you might choose one over another.
Maybe @JamesNK has more context on why this needed to be more discoverable?

I think the current place (Host and deploy) is unexpected and unintuitive. Putting all this content under fundamentals doesn't seem right (although if we decide against top-level Servers in TOC, I think it would be an improvement). A new Server area seems the best solution to me.
re: not useful outside of Windows: Making the right server choice is the minority of content. There is lots of info that people need semi-regularly: Configuring Kestrel endpoints, TLS, troubleshooting, switching to IIS or HTTP.sys, etc. TLS and the dev cert is a common problem.
If we're worried about too many top-level items, I think "Code analysis" can be moved somewhere. Maybe "Code analysis" moves into Advanced? It doesn't seem important enough to be a featured.

But I agree that we should discuss this and get a consensus before doing anything.

My two cents on this: I'm not opposed to having more top-level nodes. I'd rather have a shallow content tree that makes it easier to discover topic areas as opposed to requiring users to parse a complex taxonomy to figure out where the info they need is.
I also suspect that shallower taxonomies play nicer with search engines, summarizers, etc.

Love it!

The overview page's Hosting Models section gives IIS specific details but isn't labeled as IIS specific. It should also cover self-hosting with Kestrel or Http.Sys. 'in-process` and 'out-of-process' should be prefixed by 'IIS'.

We have 3 votes in favor of moving Servers to a top-level TOC node (@JamesNK, @Tratcher, @captainsafia).  @amcasey yours is the only "no" vote but the other comments came in after yours -- did their comments convince you that this is a good idea?

@tdykstra Don't block on me.  There is understandably limited appetite for rejiggering the whole tree and, in the absence of that, the location of one particular node isn't that important to me.

That controls the landing page at https://learn.microsoft.com/en-us/aspnet/core/
To correspond to what we did in the TOC, I'll add a new Servers card.


Approved issues are being bot-locked

Exampels: #487, #561.

Maybe this should be solved with github actions as I'm not aware that stale bot respects certain labels.

We need to look at the settings.

Hey, a couple of weeks ago we switched momentarily to a github action for marking stale issues/prs as stalebot was not working. We have since switched back to stalebot.
I believe that when the new activity occurred (after the inactive label was applied) stalebot was not running so it did not remove the label and, since no other activity occurred on the inactive issue, it was eventually closed.
Note that the bug is more aptly described as "issues with activity were not un-labeled as inactive".
There's no way for us to find all issues in this state besides checking one by one all "inactive". I reopened the ones you pointed out and will be happy to do so on any other anyone finds.
The tag Status: Approved does not prevent an issue from becoming inactive or being closed. Only the "Retained" tag does. The reasoning behind this is that if there's no interest from the community, the issues (even approved ones) should be left behind and make way for more recent/active ones.
The retained tag is applied only to bugs, missing stuff in documentation, or very specific issues, since they are perpetual.


Cannot POST physical address merge fields

When adding a new user, I can use the post method to add a user without issue, however, if I post a new user and include the ADDRESS merge_fields, there are always errors.
Using the same data to PUT or PATCH an existing user  works, I just seem to be unable to send a physical address when creating a user.
I am not entirely convinced that this is an issue with your package and may be an issue with MailChimp, but thought I would check here first.
New user request - fails
    'body' => '{"status":"subscribed","email_address":"devonte.koelpin@smitham.net","merge_fields":{"FNAME":"Fredy","LNAME":"Reichert","PHONE":"987654321007","ADDRESS":{"addr1":"925 Isobel Reach","city":"South Lorenberg","state":"QLD","zip":4000,"country":"AU"}}}'

The error given from Mailchimp isn't very helpful,
    detail":"The resource submitted could not be validated. For field-specific details, see the \'errors\' array.","instance":"bd02cc41-1146-41a7-ad80-7aae2189f702","errors":[{"field":"merge_fields.ADDRESS","message":"Data did not match any of the schemas described in anyOf."

Yet the exact data made in 2 requests instead of one appears to work.
New User request - Works
    'body' => '{"status":"subscribed","email_address":"devonte.koelpin@smitham.net","merge_fields":{"FNAME":"Fredy","LNAME":"Reichert","PHONE":"987654321007"}}'

Update User request with address - works
    'body' => '{"status":"subscribed","email_address":"devonte.koelpin@smitham.net","merge_fields":{"FNAME":"Fredy","LNAME":"Reichert","PHONE":"987654321007","ADDRESS":{"addr1":"925 Isobel Reach","city":"South Lorenberg","state":"QLD","zip":4000,"country":"AU"}}}'

Did you get anywhere towards solving this?

No. I ended up not putting a physical address in MailChimp. It might just be a limitation of Mailchimp that it could not all be done at once. Storing the physical address was a nice to have, not a requirement so I was able to leave out that functionality.


Bump go-apk

I used errors.Join like a fool, so I had to bump to 1.20, which seems fine to me but I'm open to pushback.

Looks fine but the tests are failing in CI.

Looks fine but the tests are failing in CI.

Exposed a race, fixed.

Linter is failing to install itself, hoping to fix that by just bumping to the latest version of that.

Hallelujah.


rate(go_memstats_alloc_bytes_total) result weird

What did you do?
I started a example prom-http program like this.
package main

import (
        "net/http"

        "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
        http.Handle("/debug/metrics", promhttp.Handler())
        http.ListenAndServe(":8888", nil)
}

Start a prometheus docker image to collect data, Use grafana to present the data.
The graph is weird.

What did you expect to see?
I think the data in the graph should a line, not like these, some pulses in it, and the pulse more higher.
What did you see instead? Under which circumstances?

System information
Linux 4.14.81.bm.15-amd64 x86_64
Prometheus version
prometheus, version 2.39.1 (branch: HEAD, revision: dcd6af9e0d56165c6f5c64ebbc1fae798d24933a)
  build user:       root@273d60c69592
  build date:       20221007-15:57:09
  go version:       go1.19.2
  platform:         linux/amd64

Prometheus configuration file
global:
  scrape_interval:     5s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s

    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'gateway'

    scrape_interval: 5s
    metrics_path: /debug/metrics

    static_configs:
      - targets: ['localhost:8888']

Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

Hi @uoryon ! rate function counts the rate of the Counter, so it could be as ups and downs.
Despite the fact your app is doing nothing, it actually does debug and metrics collection, that's why the rate is increasing sometimes. You can try to use rate(go_memstats_alloc_bytes_total[5s]) for better results or even try to draw raw  go_memstats_alloc_bytes_total to see what is happening, but it looks like it is a normal golang runtime with metrics collection and garbage collection.

Hi @uoryon ! rate function counts the rate of the Counter, so it could be as ups and downs. Despite the fact your app is doing nothing, it actually does debug and metrics collection, that's why the rate is increasing sometimes. You can try to use rate(go_memstats_alloc_bytes_total[5s]) for better results or even try to draw raw go_memstats_alloc_bytes_total to see what is happening, but it looks like it is a normal golang runtime with metrics collection and garbage collection.

Thanks for your reply @m-messiah . I known the rate is increasing sometime. But why every time increasing, it would getting larger or bigger.
I think this metrics means the alloc action and the unit is bytes/second. My graph indicates this program alloc some spaces to do some job. But why it's will alloc more space than the previous job. If the value become bigger and bigger, will the os kill process by the reason OOM?
And I saw the heap stats, it's fine. It's no memory leakage.

when I use go 1.19.0 to compile my program. The question is solved.

And I also change some configs.
I set the config DisableCompression: true,. Because I found compress/flate.newwriter alloc too many bytes and it's number incress match the graph when I take a result from pprof alloc spaces page.

Hi, I think I've run into a similar issue. When I try to apply increase on go_memstats_mallocs_total metric, the graph shows spikes even though the raw metric grows linearly (see attached screenshot). The app under the test contains only a simple HTTP server exposing the metrics endpoint.
Prometheus version: 2.41.0 (c0d8a56c69014279464c0e15d8bfb0e153af0dab)


Face Recognition

Python programs to capture a user's face and generate dataset. Then detect and recognize the user's face by using opencv.

This has been already implemented


Validate a single form element

Is there any way to know if a single element of a form is valid. The scenario is, there are a couple of elements in a form and I need to enable/disable a button if a particular element is valid/invalid.

Yes, there are a couple of selectors you can use to find out if a field is valid/invalid:

getFormSyncErrors
getFormAsyncErrors
getFormSubmitErrors

Full docs on available selectors in v6.8.0
Unfortunately, you cannot use isValid/isInvalid, because it only supports testing whether the whole form is valid, and not a specific field.


Doc: Update user guide with condition and tag features

Closes #206
This PR adds the feature sections and summary table for add/delete condition and add/delete tag feature.
Some things to note:

Only the add condition features has been fully implemented as of now. The rest are still in the works.
Currently, the command syntax for all four parts do not use the options-based syntax yet i.e. addCondition PATIENT_INDEX c/CONDITION is used instead of add -p PATIENT_INDEX c/CONDITION.

Other unrelated changes made:

Omitted repetitive details like "The index must be a positive integer 1, 2, 3, …" and "The XX index refers to the index number shown in the XX list...". They are mentioned once in the section about command formats near the top of the user guide. I propose that every other feature section omit these details as well (I have not changed them because it snipes everyone else's UG contribution).
Specified the type of index in the command syntax, even if only one index is required e.g. addCondition PATIENT_INDEX c/CONDITION instead of just addCondition INDEX c/CONDITION. I think it provides more clarity to the reader, so I suggest keeping it consistent.

Codecov Report
Base: 66.53% // Head: 69.59% // Increases project coverage by +3.06% :tada:

Coverage data is based on head (0b8db52) compared to base (793a200).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #234      +/-   ##
============================================
+ Coverage     66.53%   69.59%   +3.06%
- Complexity      572      613      +41
============================================
  Files           113      116       +3
  Lines          1960     2046      +86
  Branches        219      228       +9
============================================
+ Hits           1304     1424     +120
+ Misses          587      550      -37
- Partials         69       72       +3

Impacted Files
Coverage Δ

...main/java/seedu/uninurse/model/person/Patient.java
91.11% <0.00%> (-3.63%)
:arrow_down:

...eedu/uninurse/logic/parser/UninurseBookParser.java
69.56% <0.00%> (-3.17%)
:arrow_down:

...java/seedu/uninurse/storage/JsonAdaptedPerson.java
100.00% <0.00%> (ø)

...edu/uninurse/logic/commands/AddPatientCommand.java
91.66% <0.00%> (ø)

...uninurse/logic/parser/AddPatientCommandParser.java
100.00% <0.00%> (ø)

...a/seedu/uninurse/storage/JsonAdaptedCondition.java
100.00% <0.00%> (ø)

...inurse/logic/parser/AddConditionCommandParser.java
100.00% <0.00%> (ø)

...u/uninurse/logic/commands/AddConditionCommand.java
91.66% <0.00%> (ø)

...du/uninurse/logic/commands/EditPatientCommand.java
97.10% <0.00%> (+0.04%)
:arrow_up:

...seedu/uninurse/logic/commands/EditTaskCommand.java
86.84% <0.00%> (+0.35%)
:arrow_up:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

CI check failing as AddConditionCommand is not supported in the new UI (see #235)


[challenge 05] SQL schema incompatible with databricks workbook

The databricks notebook will fail out of the box because the insert statement in Cmd 13 is not compatible with the SQL Schema.
There should be a fix to the databricks workbook or the SQL schema. The insert that fails is the following:
INSERT INTO jdbcObservationTable
SELECT id AS observationid, SUBSTRING_INDEX(subject.reference,'/',-1) AS patientid, code.coding[0].code AS observationcode, code.coding[0].display AS observation, status, valueQuantity.unit, valueQuantity.value FROM observationTable;

A simple workaround is to insert dummy data to the missing columns:
INSERT INTO jdbcObservationTable
SELECT id AS observationid, SUBSTRING_INDEX(subject.reference,'/',-1) AS patientid, code.coding[0].code AS observationcode, '' AS deviceid, code.coding[0].display AS observation, '', '', status, valueQuantity.unit, valueQuantity.value FROM observationTable;

A better workaround is to fix the SQL schema, or insert the correct data in the databricks workbook.

Could you paste the error. There a NOTE which I just clarified that changes might be needed to DDL and Notebook.
FHIR Json only has columns when there is data. And depending on the data used and challenges completed, that column might or might not be there.

@cyberuna, apologies but I have already torn down my environment and don't have easy access to the error.

@cyberuna, I'm trying to work with my team to see if anyone has a copy of this issue.


ledger: Replace saturating_add_assign with Saturating

Problem
https://github.com/anza-xyz/agave/issues/502
I'm not clear if this cleanup is still wanted, but I asked on the issue and didn't get a response.
Will work on the rest if this is still a useful cleanup.
Summary of Changes
Remove instances of saturating_add_assign from ledger
Fixes #

Great. I'll start working more. I will try and keep the reviews relatively small (larger than this though!) to make it fast and easy to review.


Alert Rules Labels do not appear in Notification Email when being used in annotations/description prometheus field

What did you do?
Labels that are defined in the alert/rule and then are used annotation/description do not appear in email notifications
Alert:

As you can see all other labels except namespace and alertname are not working
What did you expect to see?
I expect for those labels to appear in the email notifications
What did you see instead? Under which circumstances?
When the labels are defined in the alert rule and then are used in annotation/descriptions do not appear in email notifications.
Environment

System information:

Kubernetes 1.24
For the alertmanager deployment we use helm chart Kube-Prometheus-Stack:42.0.3 which use the following image from alertmanager: https://quay.io/prometheus/alertmanager:v0.24.0

Alertmanager version:

Alertmanager: https://quay.io/prometheus/alertmanager:v0.24.0

Prometheus version:

Prometheus: https://quay.io/prometheus/prometheus:v2.39.1

Alertmanager configuration file:

alertmanagerSpec = {

      priorityClassName = var.priority_class

      nodeSelector = local.stateful_node_group_config

      # See: https://github.com/helm/charts/issues/15275
      logFormat = "logfmt"

      image = {
        registry   = local.registry
        repository = local.images.alertmanager.main
      }

      resources = {
        limits = {
          cpu    = "50m"
          memory = "100Mi"
        }
        requests = {
          cpu    = "30m"
          memory = "50Mi"
        }
      }
    }

    templateFiles = {
      "sns_template.tmpl" = <<EOF
{{ define "sns.default.message" }}{{ "{" }}"receiver": "{{ .Receiver }}","status": "{{ .Status }}","alerts": [{{ range $alertIndex, $alerts := .Alerts }}{{ if $alertIndex }}, {{ end }}{{ "{" }}"status": "{{ $alerts.Status }}"{{ if gt (len $alerts.Labels.SortedPairs) 0 -}},"labels": {{ "{" }}{{ range $index, $label := $alerts.Labels.SortedPairs }}{{ if $index }}, {{ end }}"{{ $label.Name }}": "{{ $label.Value }}"{{ end }}{{ "}" }}{{- end }}{{ if gt (len $alerts.Annotations.SortedPairs ) 0 -}},"annotations": {{ "{" }}{{ range $index, $annotations := $alerts.Annotations.SortedPairs }}{{ if $index }}, {{ end }}"{{ $annotations.Name }}": "{{ $annotations.Value | reReplaceAll "\n" "\\n" }}"{{ end }}{{ "}" }}{{- end }},"startsAt": "{{ $alerts.StartsAt }}","endsAt": "{{ $alerts.EndsAt }}","generatorURL": "{{ $alerts.GeneratorURL }}","fingerprint": "{{ $alerts.Fingerprint }}"{{ "}" }}{{ end }}]{{ if gt (len .GroupLabels) 0 -}},"groupLabels": {{ "{" }}{{ range $index, $groupLabels := .GroupLabels.SortedPairs }}{{ if $index }}, {{ end }}"{{ $groupLabels.Name }}": "{{ $groupLabels.Value }}"{{ end }}{{ "}" }}{{- end }}{{ if gt (len .CommonLabels) 0 -}},"commonLabels": {{ "{" }}{{ range $index, $commonLabels := .CommonLabels.SortedPairs }}{{ if $index }}, {{ end }}"{{ $commonLabels.Name }}": "{{ $commonLabels.Value }}"{{ end }}{{ "}" }}{{- end }}{{ if gt (len .CommonAnnotations) 0 -}},"commonAnnotations": {{ "{" }}{{ range $index, $commonAnnotations := .CommonAnnotations.SortedPairs }}{{ if $index }}, {{ end }}"{{ $commonAnnotations.Name }}": "{{ $commonAnnotations.Value | reReplaceAll "\n" "\\n" }}"{{ end }}{{ "}" }}{{- end }}{{ "}" }}{{ end }}
{{ define "sns.default.subject" }}[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}]{{ end }}
EOF
    }

    config = {
      global = {
        resolve_timeout = "5m"
      }
      route = {
        group_by = [
          "job",
          "severity"
        ]
        group_wait      = "30s"
        group_interval  = "5m"
        repeat_interval = "12h"
        receiver        = "null"
        routes = concat(
          [
            for alertname in local.alertname_blacklist :
            {
              match = {
                alertname = alertname
              }
              receiver = "null"
            }
          ],
          var.platform_upgrade_ongoing ? [
            for alertname in local.alertname_blacklist_platform_upgrade_ongoing :
            {
              match = {
                alertname = alertname
              }
              receiver = "null"
            }
          ] : [],
          [
            for receiver in var.teams_alerting_channels :
            {
              match_re = {
                teams_channel_name = receiver.name
              }
              receiver   = receiver.name
              group_wait = "10s"
              group_by   = ["namespace", "mc_id", "event_id", "priority"]
              continue   = true
            }
          ],
          [
            {
              match_re = {
                namespace : "^\\S+[^ ]$"
                mc_id : "^\\S+[^ ]$"
                event_id : "^\\S+[^ ]$"
                priority : "^\\S+[^ ]$"
              }
              receiver = "itsm"
              group_by = ["namespace", "mc_id", "event_id", "priority"]
            }
          ],
          [
            for alertname in local.alertname_whitelist :
            {
              match_re = {
                namespace   = "^\\s*$"
                alertname   = alertname
                environment = "prod|e2e"
              }
              receiver       = "itsm"
              group_wait     = "10m"
              group_interval = "10m"
              group_by       = ["alertname", "product", "environment", "region", "severity"]
              continue       = true
            }
          ]
        )
      }

      receivers = concat(
        [
          {
            name = "null"
          },
        ],
        [
          merge(
            {
              name = "itsm"
            },
            local.itsm_receiver_config
          )
        ],
        [
          for receiver in var.teams_alerting_channels :
          {
            name : receiver.name,
            webhook_configs : [
              merge({
                url = "http://prometheus-msteams:2000/${receiver.name}"
              }, local.alertmanager_send_resolved)
            ]
          }
        ]
      )
    }
  }

Prometheus configuration file:

Not relevant

Notes: These are custom alerts

It's honestly pretty hard to follow this, since so much has been redacted.
Did you try querying the Alertmanager API (e.g. using amtool) or inspecting the Alertmanager web UI to verify whether the labels in question are actually present in the underlying alert, i.e. to rule out template misconfiguration?
Also, Prometheus 2.39.1 is pretty outdated.

Hello @dswarbrick, yes we have done that and everything was ok. I don't believe in template misconfiguration because the template itself works fine, just does not include those labels.
Yes I am aware it's outdated, we are working on updating at least to a latest LTS version .
Will take a look,
Thans


https://developer.mozilla.org/zh-CN/docs/MDN/Feedback

Request type

[] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x ] Correction or update

Details

I received a questionnaire from MDN web. The options of "Country" include "China", "Hong Kong,China", but "Taiwan" does not been written right.

@schalkneethling this was reported to us, but sounds like a dev issue involving the DNA. Can you look into this?

@schalkneethling this was reported to us, but sounds like a dev issue involving the DNA. Can you look into this?

Thanks for the heads up @chrisdavidmills - This is on the survey itself so @atopal would be the best person for this. Thanks for reporting this @AllanJian

Thanks for reporting this. I'll have a look


[SUPPORT] Hudi HMS Catalog hive_sync.conf.dir

Tips before filing an issue

Have you gone through our FAQs?

Join the mailing list to engage in conversations and get faster support at<EMAIL_ADDRESS>

If you have triaged this as a bug, then file an issue directly.

Describe the problem you faced
flink: 1.15, flink on yarn, submit jobgraph trough java client
hudi: 0.13.1 compile ourself with tags/0.13.1 and more logs for debug
hive: 3.1.0, kerberized
we use hudi hms catalog, and config hive_sync.conf.dir as local hive-site.xml folder, but it seems have not read the local hive-site.xml file
To Reproduce
Steps to reproduce the behavior:

compile tags/0.13.1 with more logs and no other changes
config flink sql with hive_sync.conf.dir , set to local hive conf dir include a hive-site.xml file
parse flink sql to job graph and submit job graph through java client to yarn cluster as per-job mode
find wrong hiveConf values in HiveSyncContext e.g. hive.metastore.kerberos.principal<EMAIL_ADDRESS>like same kind of default value

Expected behavior
hive_sync works as expected
should the hive_sync.conf.dir set to an hdfs path, since the code running on yarn and my hive-site.xml is in a local dir?
Environment Description

Hudi version : 0.13.1

Hive version : 3.1.0 kerberized

Hadoop version : 3.1.1

Storage (HDFS/S3/GCS..) : HDFS

Running on Docker? (yes/no) : no

hdfs path, since the code running on yarn and my hive-site.xml is in a local dir

I guess you are right, the hive conf dir is only valid for the catalog itself, not the job, the catalog does not pass around all the hive related config options to the job.
Maybe you can fire a fix for it, in the HoodieHiveCatalog, when generating a new catalog table, config the hive options through hadoop. prefix.
Another way is to config the system variable: HIVE_CONF_DIR:

hdfs path, since the code running on yarn and my hive-site.xml is in a local dir

I guess you are right, the hive conf dir is only valid for the catalog itself, not the job, the catalog does not pass around all the hive related config options to the job.
Maybe you can fire a fix for it, in the HoodieHiveCatalog, when generating a new catalog table, config the hive options through hadoop. prefix.
Another way is to config the system variable: HIVE_CONF_DIR:

thx for ur clarification, after set hive tblproperties we finally sync schema successfully
next step, we gonna try to set those properties in the HoodieHiveCatalog

hdfs path, since the code running on yarn and my hive-site.xml is in a local dir

I guess you are right, the hive conf dir is only valid for the catalog itself, not the job, the catalog does not pass around all the hive related config options to the job.

Maybe you can fire a fix for it, in the HoodieHiveCatalog, when generating a new catalog table, config the hive options through hadoop. prefix.

Another way is to config the system variable: HIVE_CONF_DIR:

thx for ur clarification, after set hive tblproperties from hive-site.xml with prefix hadoop., we finally sync schema successfully
next step, we gonna try to set those properties in the HoodieHiveCatalog

After same digging, we can add all hive-site.xml kvs in HoodieHiveCatalog.instantiateHiveTable() and it works
But there are way too many properties, and we found these ones should added

hive.metastore.uris
hive.metastore.sasl.enabled
hive.metastore.kerberos.principle

Should we add all properties or just add specifed ones

After same digging, we can add all hive-site.xml kvs in HoodieHiveCatalog.instantiateHiveTable()

Where are these options set up into, can you show use an example?

we apply a fix as follow, you may implement a general solution for the community

Okay


feat: update localpv-provisioner dependency to v4.0.0

Changes:

Bump Hostpath localpv to 4.0.0
Remove upgrade-job helm set-values for NDM container images

bors merge


Sync from upstream

Hei Hilda thanks for the comment. This is simply a sync between upstream and downstream repo. The code here was already merged thought regular prs and reviewed by the team.
This is something that periodically needs to be done to have a fresh build usable by qa and the delivery team.
I'll use Philip's comments here to improve the readme on upstream (nmstate org) first and in the next iteration will be forwarded also on downstream.
There is nothing to say about it.
I can add in the description the prs that I'm forwarding from upstream to downstream but sometimes can be few prs and something can be a hard work without any automation. Anyways you can see the actual commits here.

/hold

/unhold

/lgtm
Nice work @upalatucci


METRON-728: ReaderSpliteratorTest fails randomly and extremely rarely

This unit test is sporadic, so it's less sporadic now.

I ran the medium batch tests in question 100k times and validated that it fails without the change at least once.
I ran the medium batch tests in question 100k time after the change and validated that it does not fail.

Are we settling on "less sporadic"?  Like I noted in the ticket, I had the original test run for over a minute (~90 seconds) before the JVM decided to actually be single threaded.  It's not the usual case but I probably only ran it 20 or so times before I hit the 90 second case.
It seems more likely to fail in Travis, which is fine, but I'm not sure I want my local build failing that often.

Nevermind, I can't read.  You ran the whole test 100k times, correct?  I'm fine with that.

Yep, whole test 100k times red-green style.

Why do we need this for only one of our tests?  Why are other tests not impacted by this issue?
Do you think this is the best fix or a 'good-enough' band-aid?

We actually need it for all of the tests that ensure actual parallelism and I've strengthened the other test impacted.  We had gotten around it by being too lenient, honestly.  The rest of the test cases are non-parallel, so they are correct as implemented.
This is the correct fix, IMO.  stream.parallel() does not give any explicit guarantees about parallelism, just that it can parallelize batches across a thread pool.  This test essentially ensures that given enough tries, it does parallelize.

@cestella The more I'm thinking about this, the more I wonder if this test is inherently structured incorrectly. My thinking is that it seems more like we're testing whether or not a stream can run in parallel, rather than that the stream produced by the spliterator meets the appropriate contracts for a stream.
Is there a way to restructure this so that it just tests "Does this meet the criteria of a Java stream?", rather than "Can a stream in Java run in parallel?"

Yeah, I can get behind that, @justinleet I'd state it slightly differently though.  It's not that we want to test the Stream so much as we want to test that the Spliterator, when interacting with a stream, makes the right number of splits.  That was the core problem with Files.lines() was that it made one split, not many splits.
What we really want to test here is that the spliterator splits the expected number of times.  What we have indirectly tests that, but it relies on the ForkPool to work in a consistent way, which isn't going to happen.  Anyway, I pushed a commit, see how you like it.

@cestella that is a much better way of stating it, and exactly what I was alluding to.  I'll look through the new commit.

We actually need it for all of the tests that ensure actual parallelism and I've strengthened the other test impacted. We had gotten around it by being too lenient, honestly. The rest of the test cases are non-parallel, so they are correct as implemented.

This is the correct fix, IMO. stream.parallel() does not give any explicit guarantees about parallelism, just that it can parallelize batches across a thread pool. This test essentially ensures that given enough tries, it does parallelize.

Ok, I follow what's going on here and support the need to test for instances where you may end up with the same thread by looping.
Just for some clarification, what is the reason that we are not leveraging stream.isParallel() to check for parallelism? Would the concern here be that because we're returning an object the implements the Stream interface, the ReaderSpliterator could be changed to return something that  does not abide by the isParallel() contract?

@mmiklavc The stream can consider itself parallel without it actually functioning in parallel.  If we have one big split, only one thread will be used in the threadpool, so it'll be de facto serial.  Also, we don't actually implement Stream, we construct a stream from a Spliterator.
The issue that @justinleet alluded to was that we were testing Spliterator indirectly by testing Streams in a threadpool.  If we just did the direct test, we'd narrow the scope and remove the variability as well.  If we are, then we should be able to trust Stream.parallel() to do the right thing rather than testing that.  What we really want to know is are we splitting properly.

+1, I appreciate you going ahead and taking this ticket, given that I've been bitten by it twice now.  Looks great.

I reacted to your request, @justinleet .  Also, I would like to put out a request for the community:
The delegatingSpliterator pattern that I used uses polymorphism to construct a delegate which allows me to count splits.  I wanted to investigate using mocks to do this in a cleaner way, but I kept getting off-by-one issues.  Here's what I did as a replacement for delegatingSpliterator
    Spliterator<String> delegatingSpliterator = spy(spliterator);
    when(delegatingSpliterator.trySplit()).thenAnswer(answer -> {
      Spliterator<String> ret = spliterator.trySplit();
        if(ret != null) {
          numSplits.incrementAndGet();
        }
        return ret;
    });

What I see is that I am processing 1 fewer splits than I expect.  What we have in the PR is perfectly sufficient and inoffensive, but I wanted to learn a bit more about mockito and thought if anyone had insight, we could all get better. :)

@cestella Spy() syntax ends up working differently than mock() from what I can tell.
This worked for me
    Spliterator<String> delegatingSpliterator = spy(spliterator);
    doAnswer(invocationOnMock -> {
      Spliterator<String> ret = spliterator.trySplit();
      if(ret != null) {
        numSplits.incrementAndGet();
      }
      return ret;
    }).when(delegatingSpliterator).trySplit();

Thanks!  I don't quite get why that works and mine returns one fewer split though.  Anyone have an insight on that?

@cestella @justinleet Hm, those should theoretically be the same in this case. doAnswer() is just a different implementation for dealing with void return methods. http://static.javadoc.io/org.mockito/mockito-core/2.7.11/org/mockito/Mockito.html#doAnswer(org.mockito.stubbing.Answer)

I figured out why
From the docs:

   List list = new LinkedList();
   List spy = spy(list);

   //Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
   when(spy.get(0)).thenReturn("foo");

   //You have to use doReturn() for stubbing
   doReturn("foo").when(spy).get(0);

So the first call to @cestella's trySplit() is in the when(), not in the lambda.  The subsequent calls are.  So everything shifts by one.
As the docs note "Sometimes it's impossible or impractical to use when(Object) for stubbing spies. Therefore when using spies please consider doReturn|Answer|Throw() family of methods for stubbing."
I just happened to try this, and now I know why it works.

Good catch @justinleet! That was my next suspicion and you beat me to it.

@justinleet Thanks!  I replaced the polymorphic delegate with the cleaner mock version and I learned a bit about how mocking works.

I'm +1 on this latest incarnation. Pulled the branch locally, reviewed, and verified metron-common mvn clean install runs successfully. Thanks for taking this on @cestella. The code is cleaner and the intent is clear to me.

Yep, my +1 is still in place.


Removes the by reference toupper function.

Removing the by reference toupper function as it is very much a Cism.

You know the firmware installer doesn't work without this

@tayloryoung6396 this will probably actually work better ( @TrentHouliston has actually written the toUpper function correctly by the looks of it :P )


Neutron driver leader election etcd keys not versioned in data model

We use version numbers underneath the root calico key to ease upgrading the data model, but the leader election keys aren't under it.  Is this intentional?  If so why, if not can we fix it?
Sample etcd contents:
root@computetest1:~# etcdctl ls --recursive /calico /calico/openstack /calico/openstack/neutron_election /calico/v1 /calico/v1/policy /calico/v1/policy/profile /calico/v1/policy/profile/a0a88dc5-023d-4ce2-af95-6e442c7adfa1 /calico/v1/policy/profile/a0a88dc5-023d-4ce2-af95-6e442c7adfa1/tags /calico/v1/policy/profile/a0a88dc5-023d-4ce2-af95-6e442c7adfa1/rules /calico/v1/host /calico/v1/host/computetest1 /calico/v1/host/computetest1/workload /calico/v1/host/computetest1/workload/openstack /calico/v1/host/computetest1/workload/openstack/4e649b23-27a6-4eb8-8f70-85ff917ba28c /calico/v1/host/computetest1/workload/openstack/4e649b23-27a6-4eb8-8f70-85ff917ba28c/endpoint /calico/v1/host/computetest1/workload/openstack/4e649b23-27a6-4eb8-8f70-85ff917ba28c/endpoint/7d4454da-0ab6-42b5-890f-9ec1bce4ea58 /calico/v1/config /calico/v1/config/InterfacePrefix /calico/v1/Ready

@neiljerram @spikecurtis @lukasa one of you might be able to shed some light on this?

I think the answer is that during an upgrade, we could have plugins at different levels.  But we still only want one of them to be the leader.

@neiljerram I'm not sure I understand your statement.  I agree with it, but don't see why that justifies not having a version number on that part of the data model.  My view is that is should have a version number, but that version number is separate from the version number for the main data model (the data model that Felix interacts with that is not orchestrator specific).  So I would expect /calico/openstack/v1/...

Suppose one plugin was using /calico/openstack/v1/neutron_election as its leader election key, and another plugin was using /calico/openstack/v2/neutron_election.  How would they avoid deciding both to be the leader, and so both to do periodic resyncs?

I'm not sure we have to design that now.  It's a problem to be solved later if/when we do decide we want to make a non-backcompatible change to the data model.  If we put a version number in now then the worst case scenario is we never rev it.

@neiljerram @Lukasa @spikecurtis @lxpollitt So what are we doing here (not least, given we've released the code in its current state)?

Sorry, I've been meaning to follow up...
My feeling is that it would be a bit confusing for some etcd keys to include a version number that looked like it might be the same as the main data model version number, but actually was something different.  So for that reason I'm inclined to prefer leaving it out, as the code stands at the moment.
Also I guess that it would be sufficiently hard to solve the problem sketched above - the transition between two versioned election keys - that it would be no harder to solve it so as to allow an unversioned key as well.  It sounds like possible overengineering to me, to imagine that we'll ever need to address this problem; and even more so to take some guessed step now that might or might not help, and that also costs some immediate confusion.

As @matthewdupre asked the question originally, maybe he might also want to comment?

I haven't had the time to think through the upgrade process in enough detail to come to an opinion here, but here are my current thoughts:

I'm not convinced we need to version the leader election keys independently (is it really such a bad thing if there's a separate leader for v1 and v2, each owning the appropriate parts of the data model?  I don't have the right background knowledge, but this seems nicer to me.)
If we do need these keys to be versioned independently, I'm with Neil in that I think it's better if we don't suggest that they share a version.

The OpenStack part of etcd is plug-in specific.  There will be other plug-ins.  We won't be the only people writing them.  Therefore each plug-in having its own space in the data model, versioned independently, seems like the right thing to me.  Hence me suggesting /calico/openstack/v1/  (rather than /calico/v1/openstack).
Versioning a data structure that is used to communicate between distributed components is generally good practice.  I am assuming that it is a simple change to insert this versioning.  (Small code change plus a paragraph in the next release note flagging upgrade implications for the release.)  I don't think that's over engineering.  Spending weeks discussing it might be though... ;-)

@lukasa @spikecurtis do you agree?

I think I honestly don't care.


Update magna charter experience for screen reader users

What
Alters the behaviour for magna charta rendered bar charts for screen reader users.
Currently, screen reader users will only be able to interpret the table portion of the chart, regardless of if it's visible or not, and ignore the toggle button and visualised chart entirely. This PR alters the behaviour to the following:

Screen reader users will encounter the button first, which will dictate to them "Change to table and accessible view".
If they try to interact with the chart, the message: "This content is not accessible - switch to table" will be announced.
When they click the button, "table visible" will be announced.
The user can now interact with the table.
Clicking the link again, which will now read "Change to chart view" will swap back to chart and announce "chart visible".

This PR also amends the toggle link itself to be a button element as opposed to a link and styles the element to look like a button. This is using a replication of the print link element.
Why
At the foundation, this PR is solving a WCAG failure of SC 4.1.2 because the toggle button cannot be programatically determined aka: it isn't clear what the button is for. Hiding the button and mocking a DOM of just the table for screen reader users is a risk because it impacts other assistive tech users, specifically voice control users or screen reader users who can see from interacting. The content changes along with the announcement that this solution adds communicates the intent of the button in a way that accounts for all users, meeting the success criterion.
The change to the toggle link is firstly to ensure that the toggle link is semantically correct as it behaves like a button not a link and secondly to fix a bug when screen reader users interact with this link where it will sometimes follow the hash previously applied to the link element and send the screen reader's focus to the top of the page, potentially disorienting screen reader users.
Visual changes
Before

After

Card

@chris-gds I've actioned this point on the user journey. Very salient point, the user shouldn't have to go back and forth. This is now ready for review again.

@chris-gds I've actioned this point on the user journey. Very salient point, the user shouldn't have to go back and forth. This is now ready for review again.


CodeBLEU

Does CodeBLEU  work on generated snippets where the generated code isn't compilable? And if not then how is CodeBLEU used in evaluating CodeT5 model if the generated code by the model might not have an AST.

Hi, from our experience in using CodeBLEU, it can still give reasonable scores when the code is not compilable. For details of how CodeBLEU is computed, please refer to the original paper and we would suggest to ask the original authors for these questions.


About the ood results

I have trained this model by STUD on ResNet (BDD as ID data) and follow your process. When I evalutate with the ood Dataset and visualize it by the cfg option '--visualize', the result pictures don't contain any "ood" labels. Could you tell me why? Thanks a lot.

hi @HopeFinder , please follow this issue https://github.com/deeplearning-wisc/stud/issues/5 and change the threshold and then visualize the results.

hi @HopeFinder , please follow this issue #5 and change the threshold and then visualize the results.

Hello! I have followed your reply in issue #5 and uncomment that two line in src/engine/myvisualizer.py. However this problem is still not solved. It looks like that there are not any instances detected as ood instances.

Hi, @HopeFinder , do you happen to change the threshold as what is discussed in issue 5?

Hi, @HopeFinder , do you happen to change the threshold as what is discussed in issue 5?

Hi, @d12306 , this problem has been solved by issue 4.Thank you all the same.


Rework configuration file

The current configuration file format is very confusing. It's not clear which parameters are necessary, and how they relate to each other. I've tried to make this clearer in the ReadTheDocs page using a table, but that's not good enough.
Since we want to keep things as "modules", which are swappable, I propose that we use a TOML file for the cfg format with a section for each module being used.
For example...
# Example cfg file with some arbitrary values

[runtime]
log_output =  true
output_folder = "path/to/folder"

[planet]
mass = 10.0
radius = 2.0
surface_bc = 2

[star]
mass = 1e5
radius = 1e4
spectrum = "path/to/file"

[modules]

    [modules.interior]
    enabled    = true
    selection  = "C_SPIDER"
    melt_curve = "path/to/file"

    [modules.atmosphere]
    enabled   = true
    selection = "JANUS"

        [modules.atmosphere.initial]
        use_params = false
        H2O_bar    = 30.0

    [modules.escape]
    enabled   = false

See more info here: https://toml.io/en/
This connects with #62, #68, #66, #56, and #71.

One thing that might also be useful: having multiple ways to specify the planetary parameters. It would be handy to be able to say planet=Earth or planet=TRAPPIST1b rather than specifying mass, radius, etc, directly.

+1 on using toml for the config format. I think striving for a model like in the JANUS config is a very good idea.

Move from .cfg to .toml
Add tables for planet, star, etc
Add validation

I also want to move away from storing the data in a dictionary towards a more structured representation of the config with validation, probably in the form of a dataclass.
For validation then, I think we have 3 options:

Python dataclasses with a big __post_init__ (most similar to what we have now). Simple, not as powerful as attrs.
attrs library, sort of a middle-ground between pydantic and dataclasses. Has some validation, but it is optional.
pydantic library, very powerful tool for validation. I have good experience with it in the past.

Currently any and all validation seems done in: /src/proteus/utils/coupler.py:ValidateInitFile although the documentation has way more rules. The idea with validation is that this is done all in one go when reading the config.
In addition, both attrs and pydantic offer inline descriptions, which could be used to single-source the documentation in the code and generate the tables on rtd.
I'm sort of keen to try attrs for this project.

The changes from .cfg to .toml are minimal. The only thing to change is to add quotation marks to any string variables.

Sounds good to me in principle; my only worry is to keep it "simple", i.e., always having in mind that students of various levels need to be able to read and (optimally) add some code piece in the years to come.

Yup, and at the same time you cannot make an omelette without breaking some eggs 😅 The goal here is to simplify existing procedures by using well established tools and standards.

Ok, do you think it's reasonable that you start making some headway with your preferred attrs library, and then we can see with some example code what this would mean in detail for the code restructuring?

Yeah, I can have a go at it when we get to that point. First we should start by moving to toml, and then as @nichollsh suggested re-organize the config with toml tables.

I have drawn up a suggestion for how we could format all of the existing parameters into a structure which achieves the following:

Allows us to add new modules and physics (e.g. aragog, structure models)
Is relatively clear to a new user which options do what
Prevents users from choosing conflicting options (I think this is really important)
Balances the software- and physics-first perspectives on formatting
Includes metadata for compatibility and authorship information
Will not require significant changes to the code

The main downside to this structure is that the TOML tables are heavily nested. This means that variable names get quite long, so it's a somewhat easier to get 'lost' in the file if you're using a lightweight editor. In VScode and Geany (and probably others) this makes it easier to navigate because you can collapse the sections as required.
Example file attached (you will need to remove the .txt extension)
new.toml.txt

That looks very good, I don't think the nesting is such an issue if it is well documented.

Looks very good to me! I went through the file (using Sublime Text) and made some changes and annotations. I think by default several of the parameters and switch options should be better described. I gave it a go in the instances it was obvious and made annotation in BOLD for things to change/clarify/double check.
new.toml_TL.txt

Thanks, both. I have tried to fill in the gaps that Tim has indicated and made some other minor tweaks.
new.toml.txt

Great! Minor final comment/addition:
H2O  = 30.0         # partial pressure of H2O [bar]
CO2  = 0.0          # partial pressure of CO2 [bar]

Stored the final template for the config file here:
https://github.com/FormingWorlds/PROTEUS/blob/3b7a3fcf878723e753a68077b4ebc501ec68ecba/input/new.toml

Nice, I will get to work on this one. Note that the config system will be modular, so we can quite easily change it in the future.

I don't think we need a translation layer. In theory, it should be easy to convert old-style to new-style by hand if necessary. Any future work should be using the new format, and if someone is really really desperate to use an old config then they can just use an old version of PROTEUS.

To help with the implementation, I think it is helpful to have a translation layer. Moving to a new config layout will mean a ton of changes in the code. The way I want to approach this is by replacing proteus.config by the new config object. By overriding __getattr__, we can redirect attribute lookups to the new layout, so that the code works without too many changes. I will then raise a warning and update the calling code to the new config.
Below is the mapping I made this morning, it is not complete yet. Can I ask @timlichtenberg or @nichollsh to go through my mapping and check if it makes sense and fill in the blanks (labeled None or # ??)?
mapping = {
 'star_model': ('star', 'mors', 'tracks'),
 'star_mass': ('star', 'mass'),
 'star_radius_modern': ('star', 'radius'),
 'star_temperature_modern': ('star', 'Teff'),
 'star_luminosity_modern': ('star', 'Lbol'),
 'star_age_modern': ('star', 'age_now'),
 'star_rot_pctle': ('star', 'omega'),
 'star_spectrum': ('star', 'mors', 'spec',),
 'semimajoraxis': ('orbit', 'semimajoraxis'),
 'mass': ('struct', 'mass'),
 'radius': ('struct', 'radius'),
 'zenith_angle': ('orbit', 'zenith_angle'),
 'asf_scalefactor': ('orbit', 's0_factor'),
 'albedo_s': ('atmos', 'surf_albedo'),
 'albedo_pl': (None, ),  # ??
 'eccentricity': ('orbit', 'eccentricity'),
 'P_top': ('atmos', Config.atmos.module, 'p_top'),
 'iter_max': ('params', 'stop', 'iters', 'maximum'),
 'log_level': ('params', 'out', 'logging'),
 'dir_output': ('params', 'out', 'path'),
 'time_star': (None, ), # ??
 'time_target': (None, ), # ??
 'spectral_file': (  # convert to Path: 'spectral_files/{spectral_group}/{spectral_bands}/{spectral_group}.sf'
    ('atmos', Config.atmos.module, 'spectral_group'),
    ('atmos', Config.atmos.module, 'spectral_bands'),
 ),
 'stellar_heating': (None, ), # ??
 'plot_iterfreq': ('params', 'out', 'plot_mod'),
 'plot_format': ('params', 'out', 'plot_fmt'),
 'sspec_dt_update': (None, ), # ??
 'sinst_dt_update': (None, ), # ??
 'dt_maximum': ('params', 'dt', 'maximum'),
 'dt_minimum': ('params', 'dt', 'minimum'),
 'dt_method': ('params', 'dt', 'method'),
 'dt_propconst': ('params', 'dt', 'proportional', 'propconst'),
 'dt_atol': ('params', 'dt', 'adaptive', 'atol'),
 'dt_rtol': ('params', 'dt', 'adaptive', 'rtol'),
 'dt_initial': ('params', 'dt', ),
 'shallow_ocean_layer': (None, ),  # ??

 'Phi_global': (None, ),
 'CH_ratio': ('delivery', 'elements', 'CH_ratio'),
 'hydrogen_earth_oceans': ('delivery', 'elements', 'H_oceans'),
 'nitrogen_ppmw': ('delivery', 'elements', 'N_ppmw'),
 'sulfur_ppmw': ('delivery', 'elements', 'S_ppmw'),
 'H2O_included': ('outgas', 'calliope', 'include_H2O'),
 'H2O_initial_bar': ('delivery', 'volatiles', 'H2O'),
 'CO2_included': ('outgas', 'calliope', 'include_CO2'),
 'CO2_initial_bar': ('delivery', 'volatiles', 'CO2'),
 'N2_included': ('outgas', 'calliope', 'include_N2'),
 'N2_initial_bar': ('delivery', 'volatiles', 'N2'),
 'S2_included': ('outgas', 'calliope', 'include_S2'),
 'S2_initial_bar': ('delivery', 'volatiles', 'S2'),
 'SO2_included': ('outgas', 'calliope', 'include_SO2'),
 'SO2_initial_bar': ('delivery', 'volatiles', 'SO2'),
 'H2_included': ('outgas', 'calliope', 'include_H2'),
 'H2_initial_bar': ('delivery', 'volatiles', 'H2'),
 'CH4_included': ('outgas', 'calliope', 'include_CH4'),
 'CH4_initial_bar': ('delivery', 'volatiles', 'CH4'),
 'CO_included': ('outgas', 'calliope', 'include_CO'),
 'CO_initial_bar': ('delivery', 'volatiles', 'CO'),
}

I have clarified a few of the entries below. All others look okay.

'albedo_pl': ('atmos', Config.atmos.module, 'albedo_pl') This parameter should probably be avoided, but it's handy to have around. I don't think the code currently passes it onto AGNI, but a future step can easily do this.
'time_star': ('star', 'age_ini')
'time_target': ('params', 'stop', 'time', 'maximum')
'stellar_heating' This was initially used to turn the star off. I decided to drop this from the new configuration format, since there's never been a case where it has been useful. If we decide to keep it, then maybe it should be implemented by a dummy star module in the future.
'sspec_dt_update': ('params', 'dt', 'starspec')
'sinst_dt_update': ('params', 'dt', 'starinst')
'shallow_ocean_layer' This is already handled by the option atmos.surf_state = 'mixed_layer'.
'max_temperature': ('atmos', 'tmp_maximum') Similarly, we could probably move the min_temperature key directly into the atmos table, rather than storing it per-submodule.
'solvevol_use_params' This is no longer needed, as it's equivalent to choosing delivery.initial = 'elements'.
'Phi_global' This key is no longer used to initialise the code, so it can be neglected.

Oops, didn't mean to close this yet.
Thanks @nichollsh , with #189 merged and the dummy tests, I will try to see how far I get by simply swapping out the config.

Seems all good to me, thanks Harrison for the fast reply here!


the parameter include map object can't execute？

when parameter include map object it throw error： The request sent by the client was syntactically incorrect.

how can I change the mapProperty：“object”  to mapProperty：{}

@bluelovecute a Map object thats an open generic is the same as object. An object in json is represented as {}. Now that may not be what youre application is looking for. Without much detail in your issue we cant really be of much help. Have you looked at the help on how to create issues?

Closing due to lack of response.


What do I need to do if I want to display subtitles?

I need to display the videos with subtitles in .srt format. The video_player supports this. Do you plan to integrate this functionality too?

yes, we are working on it.

Hi @mploigt
Here you go!
Try out version 0.4.0-dev.3.

Thank you! I will try this out right now.


Fixed traffic metrics emit condition

Change traffic metrics emit condition from pointers to integer value comparation

Pull Request Test Coverage Report for Build 0187c069-b3e0-433a-a752-1e532c93f5d8

5 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
93 unchanged lines in 13 files lost coverage.
Overall coverage increased (+0.006%) to 57.16%

Files with Coverage Reduction
New Missed Lines
%

common/membership/hashring.go
2
83.54%

service/history/handler.go
2
47.28%

service/matching/matcher.go
2
90.65%

service/history/task/fetcher.go
3
91.75%

common/persistence/serialization/parser.go
4
63.91%

common/persistence/serialization/thrift_decoder.go
4
57.14%

common/types/history.go
4
46.26%

service/history/historyEngine.go
4
68.94%

service/history/queue/timer_queue_processor_base.go
7
77.48%

common/persistence/sql/workflowStateMaps.go
8
83.84%

Totals

Change from base Build 0187a665-ffb2-4cd2-9fb4-4bf5a478137b:
0.006%

Covered Lines:
85730

Relevant Lines:
149982

💛  - Coveralls


🏗 resolve dashboard input datasets at run-time (rather than build-time)

Until now, we have been:

importing dashboard input data statically, resolved at build time e.g.:

import exposure_stats_data from '../json/data_exposure_stats.json';

SvelteKit then compiles that input data into the hashed/ optimized dashboard .js files

This is unsuitable for a variety of reasons:

It forces us to volume mount and move data into that directory before we build the dashboard (there should be no reason to have to do this)
It results in that data being built into some random hashed .js file, making it very difficult to keep track of where the data is (and impossible to, for example, save it)

This PR suggests that we instead:

move the data to the static directory to prevent SvelteKit from compiling/ hashing it
perform an async runtime HTTP request to fetch the input JSON file(s)

In service to #64 (and also just better practice in general).
Before (currently on main)
The input data was compiled by SvelteKit into one of the build directories. This meant it gained a weird hashed prefix, and made it more difficult to keep track of:
build/
├── _app
│   ├── env.js
│   ├── immutable
│   │   ├── assets
│   │   │   ├── 0.DYD8Ds1t.css
│   │   │   ├── 2.D8EXzefy.css
│   │   │   ├── ProgressBar.Cirlo5Z8.css
│   │   │   ├── ProgressBar.c6i8ireL.css
│   │   │   ├── _layout.BPmfqdTM.css
│   │   │   └── _page.CJwvSlMY.css
│   │   ├── chunks
│   │   │   ├── ProgressBar.svelte_svelte_type_style_lang.DYACu9TL.js
│   │   │   ├── entry.cP5GDUkm.js
│   │   │   ├── index.BJIAMc6M.js
│   │   │   ├── index.CNz_BNRL.js
│   │   │   └── scheduler.bwMKOKNs.js
│   │   ├── entry
│   │   │   ├── app.BCmowJ69.js
│   │   │   └── start.BsZeAbZb.js
│   │   └── nodes
│   │       ├── 0.CqhCRf2G.js
│   │       ├── 1.Bd0HGD2Y.js
│   │       └── 2.C6I0EzVl.js    <---- the data JSON gets built into some very human-unfriendly .js file here
│   └── version.json
├── favicon.png
└── index.html

After (this PR)
Now the "user-specific" data is in the static folder, which means svelte does not try to compile it (and in fact, even if the static/data directory were empty, the dashboard would compile without problem, which is good!)
build/
├── _app
│   ├── env.js
│   ├── immutable
│   │   ├── assets
│   │   ├── chunks
│   │   ├── entry
│   │   └── nodes
│   └── version.json
├── data
│   ├── data_company_bubble.json
│   ├── data_emissions.json
│   ├── data_emissions_pie_bonds.json
│   ├── data_emissions_pie_equity.json
│   ├── data_exposure_stats.json
│   ├── data_included_table.json
│   ├── data_techexposure.json
│   ├── data_techexposure_company_companies.json
│   ├── data_techexposure_company_portfolio.json
│   ├── data_techmix_sector.json
│   ├── data_trajectory_alignment.json
│   ├── data_value_pie_bonds.json
│   └── data_value_pie_equity.json
├── favicon.png
└── index.html

Relates to (and may shift the strategy of) #64
FYI @AlexAxthelm

What you are proposing here makes sense to me and seems more robust. I am not sure if we want to merge it in, though before @AlexAxthelm has a look? Leaving it up to you @jdhoffa.

I am confident that he would be favourable to this (he asked me if it was possible to do something along these lines last week 😊 )


Difficulty Overriding Default Styles in Flowbite React for Navbar Component

[x] I have searched the Issues to see if this bug has already been reported
[x] I have tested the latest version

Steps to reproduce

Create a react typescript project.
Configure scss, tailwind and flowbite react
Create a Navbar component

import React from 'react';
import { Link, useLocation } from 'react-router-dom';
import { Navbar } from 'flowbite-react';

import logo from<EMAIL_ADDRESS>import { ROUTE_PATHS } from '@routes/paths';
import { PrimaryButton } from '@components/common/buttons';

function PublicNavBar() {
  const location = useLocation();

  return (

      <Navbar fluid rounded className="public-navbar">

          <Navbar.Brand as={Link} href={ROUTE_PATHS.PUBLIC.HOME}>

          </Navbar.Brand>

            <PrimaryButton>Log In</PrimaryButton>
            <Navbar.Toggle />

          <Navbar.Collapse>
            <Navbar.Link
              href="#"
              className={`public-navbar__link ${location.pathname === ROUTE_PATHS.PUBLIC.SIGN_IN ? 'public-navbar__link--active' : ''}`}
            >
              Home
            </Navbar.Link>
            <Navbar.Link
              as={Link}
              href="#"
              className={`public-navbar__link ${location.pathname === ROUTE_PATHS.PUBLIC.ABOUT ? 'public-navbar__link--active' : ''}`}
            >
              About
            </Navbar.Link>
            <Navbar.Link
              href="#"
              className={`public-navbar__link ${location.pathname === ROUTE_PATHS.PUBLIC.MEMBERSHIP ? 'public-navbar__link--active' : ''}`}
            >
              Membership
            </Navbar.Link>
            <Navbar.Link href={ROUTE_PATHS.PUBLIC.SIGN_IN}></Navbar.Link>
          </Navbar.Collapse>

      </Navbar>

  );
}

export default PublicNavBar;

navBar.scss
public-navbar-container {
  .public-navbar {
    &__link {
      color: red;
      &--active {
        @apply font-semibold text-primary-500;
      }

      &:hover {
        @apply font-semibold text-primary-500;
      }
    }
  }
}

Go to the page and check for custom styles.
Add !important and recheck

Current behavior
In the flowbite-react library, the default styles for the Navbar component are proving difficult to override. Specifically, the styles for the Navbar.Link elements cannot be customized as expected.

Active Link Styling: When attempting to apply custom styles to the active link using the BEM convention and SCSS, the styles do not take effect unless !important is used, the applied styles do not reflect as expected.

Usage of @apply: Tailwind CSS's @apply directive is used in the SCSS to apply utility classes for hover and active states, but these are not being applied correctly due to the specificity or !important styles in Flowbite’s CSS.

Inline Styles as a Last Resort: This doesn't work either

Expected behavior

Applying custom style class the styles must be there.

The best way to style any flowbite-react component is by passing className (which usually directs the prop to the root element of the component) and if the component has multiple internals/slots, use the theme prop.
In the docs each element has a theme section which u can follow and see what tailwind classes have been applied in order to style it.

@SutuSebastian I tried to use custom CSS classes that include @apply rules too but they failed to override default styles. So I used the theme prop instead, but this way I have to set styles like colour for each component by using theme styles. Is there a way to set the primary colour globally, the default colour is cyan.

An improved design system config is coming up, there's a lot of work involved and u'll be able to simply set a primary color in the tailwind.config.js file and it will apply in all components.

Will that be backwards compatible?

Will that be backwards compatible?

I'll try to keep as much as I can from the old API.

@SutuSebastian btw is the library stable enough to use in production-grade applications, or do we have to wait for the official release?

Best option would be to wait for v1.


ui fixes and code refactor

@jrmerz I'm just going to merge this as I'd like to see how it affects the quirks on sandbox this morning, hopefully that's ok!


Updated base image from debian slim to UBI for cni to fix s390x build issue.

Description

Updated base image from debian slim to UBI in cni docker file for s390x
debian image was older and causing cni build issue for s390x.

Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[x] Release note

Release Note

Fixed cni build issue for s390x.

Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one docs-* label.

docs-pr-required: This change requires a change to the documentation that has not been completed yet.
docs-completed: This change has all necessary documentation completed.
docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

release-note-required: This PR has user-facing changes. Most PRs should have this label.
release-note-not-required: This PR has no user-facing changes.

Other optional labels:

cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

 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.

/sem-approve

Sorry about the delay, this LGTM


Upgrade demo app, UI tests and live macOS CLI tool to Swift 4

This PR updates the demo app, UI tests and live macOS CLI tool to Swift 4.
@spotify/objc-dev

Superseded by #366.