Dynamic update of GS

PG : https://playground.babylonjs.com/#GSUTLR#8
documentation/Validation test will be done next week

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/15577/merge
Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15577/merge/index.html
To test a playground add it to the URL, for example:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15577/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15577/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15577/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15577/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15577/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15577/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15577/merge/testResults/webgpuplaywright/index.html

Doing more tests ...


Update tilePacks.jsonc

Create tiles for the Mage Training Arena for the Telekinetic puzzle room. The tiles are a refinement of the most efficient tile position to cast telegrab to save as many seconds on this horrible grind.
The tiles maximize the amount of tiles moved while the maze guardian is sliding, meaning that movement is prioritized only when unable to cast the next telegrab on the guardian. They also minimize the amount of time standing and waiting for the guardian to stop moving.
This is an improvement over the modest attempt for the tiles included in the MTA plugin when I spent time optimizing the puzzles to remove much of the inefficient standing around.

Thanks!


Add UI Support for Specifying Security groups for EKS worker nodes

Add UI Support for https://github.com/rancher/rancher/issues/15316
We will need to give the user the ability to specify security groups for their EKS worker nodes.

+1


Pkg 4586 v12.4 initial

Destination channel: defaults
Links

PKG-4586

Explanation of changes:

Part of CUDA 12.3 build, following conda-forge's pattern which was developed in conjunction with Nvidia. I don't see a need to stage these then release them all at once. They won't cause a problem released one at a time.
Please check the main branch too, this has just been forked
Changes made to adjust feedstocks for differences between conda-forge and defaults. Please see commit messages for description of changes.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_52__57pmyg/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:184: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:0: no_global_test: Global tests are ignored in multi-output recipes.

===== ERRORS =====

clone/recipe/meta.yaml:184: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:47: outputs_not_unique: output "libcublas": Output name is not unique
clone/recipe/meta.yaml:184: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:1: missing_tests: output "libcublas": No tests were found.
===== Final Report: =====
4 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_ca4kpma9yz/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:0: no_global_test: Global tests are ignored in multi-output recipes.
clone/recipe/meta.yaml:184: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:184: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:184: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:1: missing_tests: output "libcublas": No tests were found.
clone/recipe/meta.yaml:47: outputs_not_unique: output "libcublas": Output name is not unique
===== Final Report: =====
4 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_92d3hdpwq9/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:0: no_global_test: Global tests are ignored in multi-output recipes.
clone/recipe/meta.yaml:184: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:47: outputs_not_unique: output "libcublas": Output name is not unique
clone/recipe/meta.yaml:1: missing_tests: output "libcublas": No tests were found.
clone/recipe/meta.yaml:184: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:184: missing_dev_url: The recipe is missing a dev_url
===== Final Report: =====
4 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_cejn7ndu94/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:184: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:0: no_global_test: Global tests are ignored in multi-output recipes.

===== ERRORS =====

clone/recipe/meta.yaml:1: missing_tests: output "libcublas": No tests were found.
clone/recipe/meta.yaml:47: outputs_not_unique: output "libcublas": Output name is not unique
clone/recipe/meta.yaml:184: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:184: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
4 Errors and 2 Warnings were found


Follow key -> Service key and a single public API Thread key

Closes #151
Closes #104
As discussed, this changes follow key to service key and AddFollower to AddReplicator.
Additionally, this introduces a new concept: Thread Key, which is a smart wrapper around a service and read key, allowing for easy marshaling and string conversion. There are two variants, key and service-only key.
Part of the motivation for this change is to simplify the public handling of thread keys, i.e., in URLs, invites, etc. For this reason, I did not bubble these changes down in to the log store layer, which does not concern itself with this higher level thread.Key.
Very much like thread.ID, thread.Key can be represented as a base32-encoded string:
Thread Key
brv7t5l2h55uklz5qwpntcat26csaasfchzof3emmdy6povabcd3a2to2qdkqdkto2prfhizerqqudqsdvwherbiy4nazqxjejgdr4oy

Thread Service-Key
bp2vvqody5zm6yqycsnazb4kpqvycbdosos352zvpsorxce5koh7q

The full thread key string encodes both the service and read key bytes, while the service key string only encodes the service key bytes.
Creating a thread without giving a thread.Key option will result in the underlying net layer creating and storing a full thread key (with service and read components). Previously, not supplying key options (the old follow and read options), resulted in a follow-only thread. Looking back, I can't remember why I did this... doesn't feel very intuitive given that the keys are optional. So, tl;dr, if you want to create a thread where the net layer doesn't own the read key, use a thread.Key that only has a service component when calling CreateThread.
Lastly, this removes the silly nonce handling in symmetric.Key. Nonces are now created during encryption and prepended to ciphertext.

Thanks for the reviews 🎉


Jobs buffer in Source is too big, leading to too much work getting acquired

The current load test shows situations where there are too many jobs acquired and put into the in memory queue, leading to a massive number of timeouts.

Probable fix: https://github.com/zeebe-io/kafka-connect-zeebe/commit/965badc88ca78e3b66a7a03ed0e87b25b0cc16db

My only concern with this is that is that since we have two queues, the source task queue, and the job queue, the jobs in the job queue become stale (i.e. timeout) as they wait for the source task queue to be consumed. One possible way to avoid this is to check the job deadline before sending to Kafka and ignore jobs with deadlines in the past. This isn't 100% accurate but if we see we're feeding too many timed out jobs to Kafka then that would be a band-aid fix until we come up with something better.

With the latest fix from @menski the problem still persists, there are too many jobs in the queue and basically all get stale, so almost no progress is made any more, see e.g.

While the proposal to remove timed out jobs would heal some symptoms, it does not solve the root problem, that is that we acquire jobs faster than we really execute them. Probably there is a way to do a proper throttling adjusting the rate of jobs acquired?

Would be a use case for the same back pressure library we used in the broker, but unfortunately that would require changes on the client side (JobWorker/JobPoller) in order to have dynamic polling rates.


dynamically link hashed assets to index.html

Hi there,
This PR should address the static asset caching issue that @ragingsquirrel3 brought up in the last UI WG call. The problem was that assets are hard-coded in index.html, as a result one might load outdated assets/code, potentially causing problem.
The solution here is to generate assets with a hash or chunkhash, and dynamically link them to the index.html.
@ragingsquirrel3 does this address the problem?
Details:

dist/index.html (the final index.html being served) is the generated using html-webpack-plugin
using public/index.html as a template (and assets are linked to it)
publicPath is changed to "/" (otherwise it seems that all assets including index.html can only be accessed from /assets/.)
fix CSS webpack loader
let public.css go through webpack to get hash code for cache validation (special loader for public.css because it contains styles for external components and overrides, so their className must not be modified by css-modules)

Thanks for reviewing.

I'll have a look, thanks!

Thanks Sibyl, this is a nice solution to the problem, I suggested a few tweaks, but  otherwise I think it's ready to merge.
However, I want to make some points about production configuration that should go along with these changes for them to have an effect.  The cache-control headers need to be added for the JS and CSS files when served in production so that they are cached for a long time (I suggest a year).  The current staging server appears to have no caching.  The HTML file, however, can't really be cached for more than a few hours because it might change.  Assuming the contents of the dist directory are served in production using nginx (or similar), cache-control should be added to main.[contenthash].js and public.[contenthash].css, but NOT to index.html.
Once again, I maintain this would all be a lot simpler if the HTML file was produced dynamically at request time, like it was before, but that's not directly related to this pull request.

Much thanks @ragingsquirrel3 for reviewing and thoughts! I agree with you about the cache-controlled header in what can be cached and what not. I also kinda wish the production version of index.html can be dynamically generated by a server and linking assets using the manifest file. This way the entire dist/ can be cached probably indefinitely. What do you think?

@ragingsquirrel3 manifest plugin is removed from webpack.babel.config.js and package.json :)

Should be good to go after the tests finish from merging development.


[RO] Added responses

Added respones as per https://github.com/home-assistant/intents/pull/691

Too many conflicts. Starting over


Clarify List vs Array Instantiation For Array Based Adapters

Should clarify in the JavaDocs that using the array constructor leads to an unmodifiable adapter.  Where as using any other constructor does not suffer this problem.

Decided to instead of relying on Arrays.asList (which generates an un-modifiable List), just just generate a regular modifiable list.  Figured even with documentation, it makes more sense to not impose a restricting.  Avoids the confusion and bug report that Android has on it's ArrayAdapter.


Test case, After #startListeningForAdvertisements call wifiPeerAvailabilityChanged events should be emitted, fails randomly on Android

This test does not seem to do any native calls.
Logcat log below:
04-27 05:29:52.274  3369  3455 I jxcore-log: # teardown
04-27 05:29:52.274  3369  3455 I jxcore-log:
04-27 05:29:52.294  3369  3455 I jxcore-log: # setup
04-27 05:29:52.294  3369  3455 I jxcore-log:
04-27 05:29:52.313  3369  3455 I jxcore-log: ok 610 should be in started state
04-27 05:29:52.313  3369  3455 I jxcore-log:
04-27 05:29:52.316  3369  3455 I jxcore-log: # 162. After #startListeningForAdvertisements call wifiPeerAvailabilityChanged events should be emitted
04-27 05:29:52.316  3369  3455 I jxcore-log:
04-27 05:29:52.365  3369  3455 I jxcore-log: ok 611 peer identifier should match
04-27 05:29:52.365  3369  3455 I jxcore-log:
04-27 05:29:52.366  3369  3455 I jxcore-log: ok 612 host address should match
04-27 05:29:52.366  3369  3455 I jxcore-log:
04-27 05:29:52.366  3369  3455 I jxcore-log: ok 613 port should match
04-27 05:29:52.366  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log: not ok 614 host address should be null
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log:   ---
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log:     operator: equal
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log:     expected: null
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log:     actual:   '4502e468'
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.375  3369  3455 I jxcore-log:   ...
04-27 05:29:52.375  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log: not ok 615 port should should be null
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log:   ---
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log:     operator: equal
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log:     expected: null
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log:     actual:   8080
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.379  3369  3455 I jxcore-log:   ...
04-27 05:29:52.379  3369  3455 I jxcore-log:
04-27 05:29:52.381  3369  3455 I jxcore-log: # teardown
04-27 05:29:52.381  3369  3455 I jxcore-log:
04-27 05:29:52.414  3369  3455 I jxcore-log: ok 616 should not be in started state
04-27 05:29:52.414  3369  3455 I jxcore-log:
04-27 05:29:52.418  3369  3455 I jxcore-log: # setup
04-27 05:29:52.418  3369  3455 I jxcore-log:
04-27 05:29:52.439  3369  3455 I jxcore-log: ok 617 should be in started state
04-27 05:29:52.439  3369  3455 I jxcore-log:

I looked at the sources of the test and this might be a race condition where the test fails if there is an SSDP alive message on an exact moment. A diff something like this might help:
$ git diff
diff --git a/test/www/jxcore/bv_tests/testThaliWifiInfrastructure.js b/test/www/jxcore/bv_tests/testThaliWifiInfrastructure.js
index 91bb9af..4ec3303 100644
--- a/test/www/jxcore/bv_tests/testThaliWifiInfrastructure.js
+++ b/test/www/jxcore/bv_tests/testThaliWifiInfrastructure.js
@@ -79,7 +79,8 @@ test('After #startListeningForAdvertisements call ' +
       peerAvailableListener);

     var peerUnavailableListener = function (peer) {
-      if (peer.peerIdentifier !== peerIdentifier) {
+      if (peer.peerIdentifier !== peerIdentifier ||
+          peer.hostAddress !== null) {
         return;
       }
       t.equal(peer.hostAddress, null, 'host address should be null');

Even with above change, the test would be meaningful since it would fail unless a peer unavailable message comes after the test server is stopped.

Do we even known if this is still failing?

@yaronyg I didn't face with this


Added warning if category values are too many

Added warning if category values are too many

Hi @deniskudelin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Denis Kudelin (Akvelon)). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Adds nightly serde support

There is a few things to note:

I made rustc-serialize dependency optional to allow choosing between the two crates.

Serde macros does not seem to support associated types. I had to implement the trait manually for Decomposed

I did not use syntex for stable rust support as I was unsure how to handle the build configuration with both serde_macros and serde_codegen as optional dependencies.

I forgot about my debugging file sorry :cry: ! I just removed it.

Awesome, looking now! Could you squash that debug-file deletion commit into the previous one?

Could you add the feature to the .travis.yml when building the tests on nightly? Not sure how to do that... it would also be nice to have some tests for the custom serializers/deserializers, to test that they are idempotent when composed together.

I have chosen eders similar to what the vec-map crate did chose.
For the other changes i will work them out as soon as i can. Thank you for your comments !

Should I implement ApproxEq for Decomposed or directly compare each fields for the test ?

Woo, looks good!


added requrl and requri to struct tags

This might help you out with issue #30 . I am not entirely sure what the difference between url and requrl is. There seems to be some subtle differences. Like the person in issue #30 I couldn't validate a url with a subdomain. So I added these struct tags.

IsURL more or less checks whether a given URL is a valid "web url" (like http://foo.bar) or not, while IsRequestURL and IsRequestURI uses the Stdlib "net/url" Parser (http://golang.org/pkg/net/url/) to check whether the given string is a valid URI for an HTTP Request or not. IsRequestURL also checks whether the URI Schema is conform to RFC3986 (http://tools.ietf.org/html/rfc3986) or not.

Thanks :+1: I sure that IsURL is equivalent  to IsRequestURL, but, for example, IsRequestURL require existence of scheme.


If a friend puts on a hat, it renders for them, but not for me.

Say I have the butcher hat. I put it on, and I can see it in my client. But my friend can't see it. They see me with my head armor only, or nothing if I've got no helmet on.
What's curious about this is that, if while wearing the hat I go to the nether and come back, my friend can then see it on me. It's so strange!

It seems to be an issue of trinkets mod or CCA https://github.com/emilyploszaj/trinkets/issues/113

Fixed on trinkets side


[BUG] Jitsi Logs Visible to Client

Description :
The Jisti logs are visible to the client
https://user-images.githubusercontent.com/70485812/161855655-84ff7566-5670-4c5a-9e1f-cb9ed7c36873.mp4
Expected Behavior :
Hide Jitsi Logs from Client

@Sing-Li, could you please close this issue? I don't think this is valid anymore. Thank you!

@Dnouv Closed :)


Create recommender's config classes

Create recommender config classes for each recommender.
Add from_config classmethod to use this config class to initialize recommender.

Codecov Report

Merging #76 (06b7fec) into main (99c295d) will increase coverage by 0.07%.
The diff coverage is 97.94%.

:exclamation: Current head 06b7fec differs from pull request most recent head 98fc84e. Consider uploading reports for the commit 98fc84e to get more accurate results

@@            Coverage Diff             @@
##             main      #76      +/-   ##
==========================================
+ Coverage   95.25%   95.33%   +0.07%
==========================================
  Files          68       68
  Lines        3438     3560     +122
==========================================
+ Hits         3275     3394     +119
- Misses        163      166       +3

Merged! Thank you!


Geojson CRS is not accepted in json format

For example, if it is written as
{'type': 'name', 'properties': {'name': 'urn:ogc:def:crs:OGC:1.3:CRS84'}}
Mast probably, we should replace string CRS with rasterio.crs.CRS object and make proper input from string and json.

We want the CRS to be specified in rasterio-compatible way so that we could reproject the collection
If it is not specified, it is OK and assumed by the geojson standard that it is CRS_LATLON
Else it must be read from the file, and if it does not meet any known scheme, we have 2 options:
- either throw an exception (predictable, but can fail unnecessarily)
- or ignore the CRS data and use lat-lon crs with a warning (will work better normally, but can give unexpected results)


Foreign Key Constraint Support

This pull request enables foreign key constraint support for the tengo library. It includes support for cross schema constraints and correctly handles constraints with the RESTRICT mode.

Remembered to put it into the foreign keys branch!

Hi Evan. I have completed the tests for constraints and also made an amendment to the the Constraint struct. It contained ColumnName string and I changed this to be Column *Column so it is more consistent with the rest of the application. I have performed some testing on a bunch of databases which I administer and it seems to be working very well. Obviously you would want to perform your own testing to verify that everything works.
Looking forward to hearing from you.
Chris

Awesome, this is great, thanks again Chris! I'll review and test this
weekend.
On Tue, Jul 25, 2017 at 11:18 PM, Chris Palmer<EMAIL_ADDRESS>wrote:

Hi Evan. I have completed the tests for constraints and also made an
amendment to the the Constraint struct. It contained ColumnName string
and I changed this to be Column *Column so it is more consistent with the
rest of the application. I have performed some testing on a bunch of
databases which I administer and it seems to be working very well.
Obviously you would want to perform your own testing to verify that
everything works.
Looking forward to hearing from you.
Chris
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/skeema/tengo/pull/1#issuecomment-317935975, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEY8E3ZMh05WG4E-j_BgAX84xRq2pnuks5sRrANgaJpZM4OgqlX
.

Functionality looks perfect! Thanks for adding the unit tests too, this is excellent.
I'm going to go ahead and merge this into the foreign_keys branch, and then add some quick style changes on top in a separate commit. It also looks like some recent README changes were inadvertently reverted here; I'll fix those too. (I think what happened is I updated the README here in f7108f254, but I didn't update the vendored version in skeema/skeema since it was only a documentation change.)
There are a few other things I want to look into on my end before merging foreign_keys into master, and then updating the vendored version in skeema/skeema. It's just the items I mentioned under "Future considerations on my end" in my comment on skeema/skeema#8. Might take a couple more weeks on that, apologies in advance if so -- I'm in the process of switching to a new computer at home and still have a lot of development-related things to set up :)


Non Exported Interfaces in Generated Typescript File

As a newcomer to Typescript it's confusing to see the file generated by scala-tsi to not have any exported interfaces. It's unclear how to import the interfaces from the file that is produced. Either an option should be created for the scala-tsi sbt plugin to prefix the generated interfaces with "export " or the expected method for utilizing the generated typescript file should be added to README.md.
Can @dhoepelman or @mdvanes provide some clarity on this please?

Ok, though I stumbled upon the answer, according to typescriptlang.org utilizing import './filePath' is "not recommended practice". https://www.typescriptlang.org/docs/handbook/modules.html
At least I'm able to get going but it's rather awkward to be without the ability to only import specific interfaces or to do import * as objectName from './filePath'.
What are your thoughts on this?

Thanks for the interest Anthony. The project is still in a 0.1 state, so you're right that this is not ideal.
One thing it should have is full support for modules.
Adding export is to interfaces a quick win, I'll make a version that does that

Hi @dhoepelman - I can do it also. Would you like me to send a PR? It'll take me about a week to get it to you.

No need, if my co-author agrees I'll merge #13 and release 0.1.3 with it

Great to hear, thank you so much!

0.1.3 was just released, with this change included. @anthonymichaelson Let me know if it solves your issue or if you need any more help


Close open streams in BackendUtils

This PR closes  multiple open streams in the BackendUtils.java.
Signed-off-by: Dominik Voigt<EMAIL_ADDRESS>

[x] Ensure that you followed http://eclipse.github.io/winery/dev/ToolChain#github---prepare-pull-request. Especially, we require a single commit
[x] Ensure that the commit message is a good commit message
[x] Ensure to use auto format in all files
[x] Ensure that you appear in NOTICE at Copyright Holders

Can one of the admins verify this patch?


Prune dictionary

Describe the problem
There are a lot of words in the current list that are very obscure that the user shouldn't expect to know. This can make people's games run 100+ seconds and be generally frustrating.
Describe the proposed solution
I would like to see the list pared down just a little bit to remove obscure words.
Alternatives considered
No response
Additional Information
Feel free to comment or make a PR with changes. We will track everything here.
File link: https://github.com/AlexMassenzio/wordchain/blob/main/src/lib/assets/dictionary.ts

Note: This is just for removing words for the time being. I will make a separate ticket in the future for adding words.

Immediate petitions for removal based on past chains:

humus
duchy

Other proposed removals:

dross
eking
elide
emcee (I'm used to this being the acronym MC? maybe minority opinion)
eying (more common spelling is eyeing, may be confusing)
filly (a young female horse, just niche)
frock (slang for dress?)
gipsy (usually spelled with a y, used to describe the Romani people, modern connotation as a slur)
gypsy (used to describe the Romani people, modern connotation as a slur)

okay, I'm hopping off at G

Recommendation from Capsui: swami

aping was the only 'a' word I think should be removed.

Proposals for B removals:

baler
basal
bawdy
beech
betel
billy (name?)
bobby (name?)
booby (up to desired tone of game lol, removal also reduces number of words ending in y)
borax
boule
briny (reduce number of words ending in y)
bused ("bussed" is more common I think?)
butte

Proposals for C removals:

cairn
cavil
chard
chock
copse
corer
covey
croup
crump
curio
cynic

Proposals for D Removals:

dally
datum
debar
demur
dilly
dolly
dowdy
droit
dross
duchy
dumpy

Proposals for E Removals:

eclat
edify
egret
eking
elfin
elide
emcee
ester
eying

Proposals for B removals:

baler
basal
bawdy
beech
betel
billy (name?)
bobby (name?)
booby (up to desired tone of game lol, removal also reduces number of words ending in y)
borax
boule
briny (reduce number of words ending in y)
bused ("bussed" is more common I think?)
butte

Proposals for C removals:

cairn
cavil
chard
chock
copse
corer
covey
croup
crump
curio
cynic

Proposals for D Removals:

dally
datum
debar
demur
dilly
dolly
dowdy
droit
dross
duchy
dumpy

Proposals for E Removals:

eclat
edify
egret
eking
elfin
elide
emcee
ester
eying

f words:

fetid
ficus
filly
fjord
fleck
flier (flyer)
flout
foist
folio

radii

Contentious words from the past few chains:

leant
terra
refit
tulle
renal

More contentious words:

aorta
rajah

fryer is not a word but ferry is. This confused a lot of people.


BUG: fix pivot table dtypes

What do these changes do?

Related issue number

Fixes #xxxx
Check code requirements

[ ] tests added / passed (if needed)
[ ] Ensure all linting tests pass

duplicated with #668


Fix multiply Select.js with null value

Description of the pull request:
I have a select element in template. The value value is null by default.
<select multiple as-chosen="'filterValue'" value="{{ value }}">
    {{ #each values }}
        <option value="{{ .value }}">{{ .text }}</option>
    {{ /each }}
</select>

After migrating from 0.7 to 0.8 I faced with the following error

Uncaught TypeError: Cannot read property 'length' of null
at valueContains (http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:14886:22)
at http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:14954:38
at Array.forEach (native)
at Select.sync (http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:14952:13)
at Select.render (http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:14913:9)
at http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:16471:55
at Array.forEach (native)
at Fragment.render (http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:16471:14)
at Section.render (http://static.clientobox.vagrant/js/ractive/ractive.js?vid=hash:14775:39)

Fixes the following issues:
Is breaking:
I don't think so
Reviewers:
@Rich-Harris

Looks good to me, but can you add a test case, probably here to make sure we don't regress?

@evs-chris you mean, test case for multiply select?

Yes. We generally try to add a test case(s) that covers every committed bugfix.

@evs-chris I can try.

@gam6itko thanks for the PR! It turns out that there are a few other scenarios not covered by a null check that would blow up, notably anything not an array. I've expanded this PR with an array check and a testcase and merged it.

Thanks you. I'll be waiting for fresh release.


insert<TableType> -> upsert<TableType>(... onConflict: {}) to enable updates

What kind of change does this PR introduce?

renames insert<TableType> to upsert<TableType>
adds an onConflict clause to upsert<TableType> to enable configurable insert/update/upsert

[x] introspection schema
[x] deterministic (attnum) column ordering in types
[ ] resolvers
[ ] tests

Development Stopped.
an onConflict clause is not sufficient to support all update use cases.
Example:
-- setup
create table account(
  id serial primary key,
  email varchar(255) not null,
  password_hash text not null
)

when when attempting to update an account's email address
mutation {
   upsertAccount(
    object: {
      id: 1
      email<EMAIL_ADDRESS>  	}
    onConflict: {
      conflictFields: [id]
      updateFields: [email]
    }
  ) {
    id
    email
  }
}

there is an error
{
  "data": null,
  "errors": [
    "null value in column \"password_hash\" of relation \"account\" violates not-null constraint"
  ]
}

because the password_hash was not provided.

additional food for thought: onconflict ... do nothing is also a frequent use case for insert.

onconflict ... do nothing is also a frequent use case for insert.

For sure
Conflict resolution of some kind will be added in the future
Right we're targeting getting minimal CRUD support so it can be tested by users in real-world applications. Adding an argument like onConflictDoNothing: Bool! = False would be an easy win for short term usability, but it would force backwards incompatible changes to the public API when we revisit conflict resolution later


template ref is unavailable

Version
3.0.0-beta.15
Reproduction link
https://github.com/pangao66/vite01/blob/master/src/App.vue
模板ref不可用,
Steps to reproduce
<template>

</template>

What is expected?
root.value is null
What is actually happening?
root.value is  div

you need to return root in setup so it can be used by the ref="root"


auto-detect OS, lowercase x for hexa numbers

This makes disassembler output numbers with lower-case x like 0xFA instead 0XFA which is more confusing.
It also attempts to auto-detect OS so it compiles on Linux with just "make" without any manual modifications.

OS variable is set automatically by GNU Make, please see https://renenyffenegger.ch/notes/development/make/detect-os

Uppercase X is strange, but you are right that it's like this everywhere so let's keep uppercase, at least for now.
OS is set to Windows_NT on Windows, I've updated that condition in the Makefile directly without using WIN as a constant.
Added #elseif as you requested.


[d3d9] [GTA IV] Can't set the game to Full HD on a 3080Ti

Upgraded from a 960 to a 3080Ti, the maximum resolution allowed by the game when running with dxvk (does not happen when  running without dxvk) is 1152x864 (85Hz)

This issue did not happen when running the game on a GTX 960.
Software information
GTAIV <IP_ADDRESS>
Running with the following commandline.txt:
-norestrictions
-nomemrestrict
-managed
-reservedApp 0

System information

GPU: RTX 3080Ti
Driver: 466.77
Wine version: N/A
DXVK version: 1.8.1

Apitrace file(s)

Could not reproduce while recording the apitrace, but feel free to ask if this file is needed.

Log files

d3d9.log

Duplicate of #1831


html css class completion  plugin bug, vs code not work, only close

VSCode Version: 1.3
OS Version: windows 10

Steps to Reproduce:

vs Code
tips  html css class completion; Fetching css rules from css files please wait

This issue was moved to Zignd/HTML-CSS-Class-Completion#19


Change keybinding for window reload (⌘R) or change window reload behavior

Note: this is not a bug, and I would be happy to make a PR, but I wanted to see if anyone else had the same issue first.  This is more for an open discussion.
I came to Sqlectron from using a handful of DB clients together for different needs.  Some of those clients I used (Sequel Pro comes to mind) use ⌘R as the keybinding to run a query.  With this muscle-memory, I am constantly hitting the combination that maps to refresh the window.  This results in me watching the (very good) opening animation, seeing a disconnected session, and losing whatever query and past results I had open at the time.
I am proposing a couple changes:

changing the window reload keybinding to something other than ⌘R
have ⌘R do the same thing as ⌘⏎ (command-return)
change the window reload behavior to stop the "Server configuration not found" error (unless this is intended; in which case a different error message would be preferred)

Thanks in advance everyone!

I guess we could just remove the short key for the window reload. That is more used in development environment at least. I'm ok using that for run the query as well. A PR for that would be awesome :)

hey i'm also often annoyed by this,
and as in dev we have the save-reload mechanism, i'm in favor in replacing the ⌘R behavior


Fix a bug in the JSON example for activities

Error in the JSON broke highlighting on the docs site

@ranieuwe,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@ranieuwe : Thanks for your contribution to the Azure documentation! The author, @sharonlo101, has been notified to review your proposed change.

#sign-off

#sign-off


Add documentation for topic specific partitioning configuration

I have been diving into Gobblin and found out there was an additional configuration key that was not documented which enables having topic-specific configuration.
The change includes the documentation already available in KafkaSource
Closes #936.

Coverage decreased (-0.09%) to 44.121% when pulling 5426dd7691f254639a43bc37cf9cb6cacd0f1b09 on rakanalh:master into d27910d00bee1485748cf03d4ebafc956f262146 on linkedin:master.

Minor comments, in general LGTM. Thanks for making this addition.

Thanks! your feedback has been applied.

Coverage decreased (-0.2%) to 44.104% when pulling 8ad947444ee70db1ed60233c7dfe502743bffed8 on rakanalh:master into d27910d00bee1485748cf03d4ebafc956f262146 on linkedin:master.


Feature Request - Training Progress callback

Is it possible to have a progress callback function with ETA or # completed tasks / # total tasks?

Could you clarify which task you are referring to? Do you mean for Tabular on a model-by-model basis or for generic HPO in terms of HPO trials?

Hi, I mean on a model by model basis. Just something similar to H2O-3's AutoML, how the user can query the leaderboard, get the current leader and its stats, etc. This is just useful to help track long running sessions and potentially build live graphs or dashboards.

I'll need to think about the best way to incorporate this functionality, but it is definitely do-able and useful. I will update this issue when I make progress in my implementation.

@Innixma thanks for taking up this bug. We are also interested in this and want details from all models including non-leaders while the training is going on. Would that be supported by the fix for this issue?

Yes, this is something that I plan to add as it is a natural aspect of having the callback function.

Hi @Innixma, just wondering if this is still in the plans? Thanks!

@jrdzha This is planned as a stretch goal for 0.1 release in January, but more likely as a follow-up feature likely to release sometime in late Q1 2020.


Fix README.md

"More optimal" is grammatically correct but logically meaningless. In other words, there's no grammatical problem with the phrase, but the meaning of "optimal" is logically incompatible with the meaning of "more."

Since the intended meaning of "more optimal" is fairly easy to infer, however, it's not exactly semantically meaningless, and I think the particular usage is common enough to be considered fairly idiomatic.

Since the intended meaning of "more optimal" is fairly easy to infer, however, it's not exactly semantically meaningless, and I think the particular usage is common enough to be considered fairly idiomatic.

Share Improve this answer Follow edited May 17 '13 at 22:41 answered May 17 '13 at 22:32
Pitarou

Share Improve this answer Follow edited May 17 '13 at 22:41 answered May 17 '13 at 22:32
Pitarou

I have to agree with Jack here "more optimal" is quite idiomatic and it feels superfluously verbose to replace it with "closer to the optimal amount"

I have to agree with Jack here "more optimal" is quite idiomatic and it feels superfluously verbose to replace it with "closer to the optimal amount"


Refactor src

Refactor src to make the code easier to maintain, update the documentation, and minor bug fixes.
Overall, makes the code ready for Catalyst v14.
Closes #46

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 94.33148% with 92 lines in your changes missing coverage. Please review.

Project coverage is 94.37%. Comparing base (4c794dd) to head (0ea1ef0).

Files
Patch %
Lines

src/common.jl
80.97%
43 Missing :warning:

src/piecewise.jl
83.47%
20 Missing :warning:

src/system.jl
95.79%
9 Missing :warning:

src/callbacks.jl
94.23%
6 Missing :warning:

src/rules.jl
96.92%
4 Missing :warning:

src/species.jl
96.49%
4 Missing :warning:

src/reactions.jl
97.60%
3 Missing :warning:

src/compartments.jl
90.00%
1 Missing :warning:

src/initial_assignments.jl
98.27%
1 Missing :warning:

src/load.jl
91.66%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #54      +/-   ##
==========================================
- Coverage   95.45%   94.37%   -1.09%
==========================================
  Files          16       20       +4
  Lines        1806     1636     -170
==========================================
- Hits         1724     1544     -180
- Misses         82       92      +10

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


Make interface easily customizable

Actual
Customizing the interface requires forking/modifying patternplate/patternplate-client
Target
Modifying the interface should be possible by

Settings concerning things to display/hide
Overriding LESS variables
Specifying custom icon files
Providing arbitrary static assets
A Plugin API that hooks into components via special lifecycle methods

Considerations

Consider breaking out theming into own module
Make sure less exposes a well defined API

This issue was moved to sinnerschrader/patternplate#33


Screen goes black after starting KDE

The title says most of it.
After I type in "Shell" and then "sudo startkde", the KDE boot-up screen appears, the hard drive icon appears in that sequence that plays when KDE boots up, but then the screen goes black.  Ctrl-alt-shift-back/forward do nothing. I know that my Toshiba Chromebook 2 is still working alongside the dark KDe, because I started a Youtube video before typing in "sudo startkde",  and the video continued to play normally after starting KDE and getting the black screen (well, I know the audio played ok).
How do I fix this? I would be glad to provide more anymore information that would help you help me.
Thank you in advance for helping me uphold my belief that random people on the internet are the best tech support.

Did you intend to close the bug?


Fix for #239: “Too many open files”

The underlying problem appears to have been consuming async replies too late in two places:

async.send(prefetch=True) did not pass prefetch=True to the request.send() call but instead consumed the responses after all of them had been processed, leading to an error any time the total number of requests exceeded the number of available file descriptors. acdha@495646bb6a89802a60208c2ab09749edba1f8e51 changes async.send to call request.send with the prefetch value.

Following redirects would result in only the last request in the chain being consumed, leading at least one file descriptor. acdha@67f50a0fe53765987e5a6a1c02daabe6400322af consumes each redirect response before following it.

Beautiful.

I might revisit this — there's really no need to download the content at all.

Perhaps sessions are leaving connections open when they should be killed. @shazow ?

Does this problem still exist in urllib3 1.2? The 'use poll instead of select' might fix this problem.
Can someone write code to replicate this issue in urllib3? I'll have a look then.

I believe that select is related. Unfortunately, poll is all we have on osx :(


Add support ordering for translatable fields in List

WHY
When you use translatable field, and use JSON field type in database (in my case is PostgreSQL)
Ordering in List page broken
BEFORE - What was wrong? What was happening before this PR?
when you try order data from json database field  you will get error

AFTER - What is happening after this PR?
Values in the user's current language sort fine
HOW
Added a check on the database field and a translatable field
I tested this sorting syntax on my PostgeSQL database, but as far as I know the mysql uses the same syntax to access the json
field element
Is it a breaking change or non-breaking change?
Its a path improvements and fix bugs for translatable models
FIRST PR:
https://github.com/Laravel-Backpack/revise-operation/pull/16
PS
For users who use the text format of the database, sorting does not cause an error, but it will also work incorrectly.
Therefore, I recommend using the json data format for translatable fields, it adds more options for interacting with data, including correct sorting by data when switching between languages

so I found that it is also required to add fields to the check, type jsonb for PostgreSQL
and you also need to add a check of work on other databases

I will also leave some advice for those who need sorting now
protected function setupListOperation()
    {
    CRUD::addColumn([
                'label'      => 'Label',
                'type'       => 'text',
                'name'       => 'label',
                'orderLogic' => function ($query, $column, $columnDirection) {
                    return $query->orderBy('label'.'->'.\App::currentLocale(), $columnDirection);
                }
            ]);
}

Hello @guleswine
This had conflicting issues and for me to fix them I created a new branch starting from your PR so your commits get in there too. 👍
I will be closing this one, let's keep any discussion regarding this in #4645


pds branch is a bit messy

pls not so many binaries in a repo
all files that are generated by the knitting process should be in gitignore
everything belonging to that table document should be in one sub-directory

[ ] done
[ ] doing
[ ] doing


AWS S3

Hello,
In Studio -> Settings -> Storage
I've added my S3 With my Id and secretkey and s3 bucket and with and without aws custom domain i put the url of my cloudfront.
When i add a picture in still pointing to local storage when it supposed to point to my mycloufrond and s3 bucket..
I used the same settings id key and other with an other site in the admin and it works.
Can you explain to me please how it works? and whats exactly the aws custom domain ?

Please refer to this FAQ:
https://github.com/unaio/una/wiki/FAQ#12-how-configure-amazon-s3-storage-


Repository Future

Hi @jorgenhenrichsen ,
I've been maintaining a fork of this repository - where I've done additional bug fixes and will continue building out the library with eventual support for caching, etc. We're also working on an Android audio framework.
I want to publish those changes to the community and can easily do so by creating a new pod but I wanted to first ask if you'd be open to transferring ownership of this library if you no longer plan to support it. This would allow us to keep the issues and PR history that has already been accumulated.
You can reach me by email at  david [at] dcvz . io if you're open to discuss.

Hi @jorgenhenrichsen ,
I've been maintaining a fork of this repository - where I've done additional bug fixes and will continue building out the library with eventual support for caching, etc. We're also working on an Android audio framework.
I want to publish those changes to the community and can easily do so by creating a new pod but I wanted to first ask if you'd be open to transferring ownership of this library if you no longer plan to support it. This would allow us to keep the issues and PR history that has already been accumulated.
You can reach me by email at david [at] dcvz . io if you're open to discuss.

I can bouch for dcvz. He has the best audio library in the react native community.


Use idiomatic returns

Coverage remained the same at 100.0% when pulling 8026de72fd320398dd69b8a33839e16e98a11b46 on get_id into 95f19a0c90b05801b6f45749c7ea58757e6479ed on master.

Coverage remained the same at 100.0% when pulling 8026de72fd320398dd69b8a33839e16e98a11b46 on get_id into 95f19a0c90b05801b6f45749c7ea58757e6479ed on master.

Coverage remained the same at 100.0% when pulling 8026de72fd320398dd69b8a33839e16e98a11b46 on get_id into 95f19a0c90b05801b6f45749c7ea58757e6479ed on master.


Inject secrets from AWS Secrets Manager into AWS Batch job

Resolves https://github.com/Netflix/metaflow/issues/814
Feature Overview
AWS Batch allows for the injection of secrets into jobs by pulling them from AWS Secrets Manager and exposing them as environment variables.
Users would need to provide an environment variable name where the secret should be exposed and an Amazon Resource Name (ARN) of the Secrets Manager secret. They should be able to provide multiple environment_variable:secret_arn key pairs.
This feature should help users eliminate any code calling out to Secrets Manager directly, and instead pull a secret from an environment variable directly.
Manual Integration Tests
AWS Batch
python main.py --no-pylint run --with batch:secrets='{"SNOWFLAKE_USER": "arn:aws:secretsmanager:region:123:secret:MyFlow-abc:SNOWFLAKE_USER::", "SNOWFLAKE_PASSWORD": "arn:aws:secretsmanager:region:123:secret:MyFlow-abc:SNOWFLAKE_PASSWORD::"}'

✅
AWS Step Functions
python src/main.py --no-pylint --with batch:secrets='{"SNOWFLAKE_USER": "arn:aws:secretsmanager:region:123:secret:MyFlow-abc:SNOWFLAKE_USER::", "SNOWFLAKE_PASSWORD": "arn:aws:secretsmanager:region:123:secret:MyFlow-abc:SNOWFLAKE_PASSWORD::"}' step-functions create

❌

Closing this out because I don't have enough understanding of the Metaflow codebase yet.
For anyone that wants to revive this work: the outstanding issue is that run and step-functions create hit two different code paths. Despite passing the --with batch:secrets=... flag for both, the step decoration behaves differently.
My understanding is that run will create a Worker to launch a task via the subprocess, and by doing so will hit the batch_cli.step, which is responsible for type coercion.
But step-functions create will only attach decorators in-memory, so the batch_cli.step is never invoked.
Downstream, this means the BatchClient will receive a JSON-encoded string from step-functions create and a dictionary from run.


[docs] [R-package] use CRAN-style builds when building pkgdown site

This PR proposes using CRAN-style builds of the R package on readthedocs (RTD).
Advantages of this approach over CMake builds:

(maybe) faster RTD builds, since cmake does not need to be installed
easier updates of the conda R dependencies for RTD builds
reduced risk of failures when the RTD images change (since the CRAN package is optimized for portability)
another step towards publishing vignettes on the {pkgdown} site (contributes to #1944)

I say this because I'm going to propose on #3946 that we only build vignettes for CRAN-style builds of the R package

@StrikerRUS can you please re-enable my docs/jlamb branch at readthedocs? I see it isn't being built: https://readthedocs.org/projects/lightgbm/builds/

@jameslamb
Sure, done! Just a note: we need to keep RTD versions clean (test something and then remove dev branch) because we've started to provide versions for previous releases (#4236). Excess branches might confuse users there.

we need to keep RTD versions clean (test something and then remove dev branch)

Thanks! Yep, I understand. As long as I do not have permissions on RTD to do this myself, I'll have to ask you to add and remove a dev branch when I want to test docs.

I see that the most recent build failed with an error like this.
-- Building favicons -----------------------------------------------------------
Building favicons with realfavicongenerator.net...
Error : API request failed.
...
...
...
Error: <callr_status_error: callr subprocess failed: API request failed.>
-->
<callr_remote_error in NULL:
 API request failed.>
 in process 1834

 Stack trace:

 Process 1819:
 1. pkgdown::build_site(lazy = FALSE, install = FALSE, devel = FALSE,  ...
 2. pkgdown:::build_site_external(pkg = pkg, examples = examples,  ...
 3. callr::r(function(..., crayon_enabled, crayon_colors, pkgdown_internet) { ...
 4. callr:::get_result(output = out, options)
 5. throw(newerr, parent = remerr[[2]])

 x callr subprocess failed: API request failed.

 Process 1834:
 17. (function (..., crayon_enabled, crayon_colors, pkgdown_internet)  ...
 18. pkgdown::build_site(...)
 19. pkgdown:::build_site_local(pkg = pkg, examples = examples, run_dont_run = r ...
 20. pkgdown:::init_site(pkg)
 21. pkgdown:::build_favicons(pkg)
 22. base:::stop("API request failed.", call. = FALSE)
 23. base:::.handleSimpleError(function (e)  ...
 24. h(simpleError(msg, call))

 x API request failed.

Execution halted
)

https://readthedocs.org/projects/lightgbm/builds/14472426/
That seems unrelated to the changes in this PR. I'm going to try pushing an empty commit to re-trigger the build.

ahhh ok actually, the issue about favicons WAS related to the changes here. I was able to reproduce it locally.
The CRAN-style package doesn't contain the contents of R-package/pkgdown (https://github.com/microsoft/LightGBM/tree/926526c838196a7497a85b6b8cf07657a88b69e6/R-package/pkgdown).
That includes the pkgdown/favicons directory, which was created by pkgdown::build_favicons() (mentioned in https://github.com/microsoft/LightGBM/pull/3327#issue-471319731).
I just pushed https://github.com/microsoft/LightGBM/pull/4513/commits/513894688e4271af3c5a9b129e45385c2d06ffc9, which I think should fix it.

I just pushed 5138946, which I think should fix it.

Ok yep, that worked! The RTD build is passing (https://readthedocs.org/projects/lightgbm/builds/14472810/), and the R documentation looks correct to me (https://lightgbm.readthedocs.io/en/docs-jlamb/R/index.html).
I believe this is ready for review.


Remember Options History in the Open with Options UI

It would be nice to remember the most recent overridden settings in the Open with Options UI.

Added in 3.1.3594-dev.
Feature is currently disabled by default. Enable by setting ui.recentFileOptionsLimit to a non-zero value.


Registration to GBIF UAT failing

We are on IPT v3.0.5  b3d11a2
I'm trying to publish a checklist to GBIF UAT via https://gbrds.gbif-uat.org but am getting an error upon registering:

It seems we are getting an empty response from the registry call:
DEBUG 02-Jul-2024 13:39:37 [org.gbif.utils.PreemptiveAuthenticationInterceptor] - GET /registry/network.json HTTP/1.1
DEBUG 02-Jul-2024 13:39:37 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:37 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:37 [org.gbif.ipt.action.manage.OverviewAction] - Checking if license (URL=http://creativecommons.org/licenses/by-nc/4.0/legalcode) is supported by GBIF..
DEBUG 02-Jul-2024 13:39:37 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:37 [org.gbif.ipt.action.manage.OverviewAction] - Checking if license (URL=http://creativecommons.org/licenses/by-nc/4.0/legalcode) is supported by GBIF..
DEBUG 02-Jul-2024 13:39:47 [org.gbif.utils.PreemptiveAuthenticationInterceptor] - GET /registry/network.json HTTP/1.1
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.service.registry.impl.RegistryManagerImpl] - Registering resource...
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.service.registry.impl.RegistryManagerImpl] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.service.registry.impl.RegistryManagerImpl] - Registering EML & DwC-A Checklist Service
DEBUG 02-Jul-2024 13:39:47 [org.gbif.utils.PreemptiveAuthenticationInterceptor] - POST /registry/ipt/resource HTTP/1.1
DEBUG 02-Jul-2024 13:39:47 [org.gbif.utils.PreemptiveAuthenticationInterceptor] - Authentication used for scope gbrds.gbif-uat.org
ERROR 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - The response from the Registry was empty or invalid. [https://gbrds.gbif-uat.org/registry/ipt/resource]
ERROR 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Registration of resource failed!
DEBUG 02-Jul-2024 13:39:47 [org.gbif.utils.PreemptiveAuthenticationInterceptor] - GET /registry/network.json HTTP/1.1
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Checking if license (URL=http://creativecommons.org/licenses/by-nc/4.0/legalcode) is supported by GBIF..
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Loading EML from file: /home/lwatch/ipt-data/resources/negative-eventdates/eml-1.2.xml
DEBUG 02-Jul-2024 13:39:47 [org.gbif.ipt.action.manage.OverviewAction] - Checking if license (URL=http://creativecommons.org/licenses/by-nc/4.0/legalcode) is supported by GBIF..

This is the dataset I'm trying to register: https://ipt-dev.inbo.be/resource?r=negative-eventdates
I was in communication with @MattBlissett about this over slack, this is related to a mapping question of @sannegovaert regarding negative eventDates

Thank you @PietrH
Looking into it

Let me get back to you on that in a moment, what do you need admin access for?

@mike-podolskiy90, https://ipt.gbif.org/manage/resource.do?r=bfast2 gave the same error for me.

Okay, the error message is the same, but the reason could be different? Anyway, I'll check our test IPT instead.

I've sent some credentials your way @mike-podolskiy90

It seems your installation has the key 08a0012f-5c72-429e-9f93-7df465ff9686 which is not present in our test environment:
https://api.gbif-uat.org/v1/installation/08a0012f-5c72-429e-9f93-7df465ff9686

It means your IPT installation is not actually registered in the GBIF

Aha, that seems like an easy fix. How do I go about registering it?

A slightly more informative message might be useful in the future

I'm not sure how this happened. I think you will have to reinstall the IPT.

Oh, just reinstalling with the same data directory won't help. We have to scrap the registration2.xml file.

Is there no way to get around this without reinstalling our test ipt? I'd like to avoid that if at all possible.
I wonder if we were ever registered on our test ipt to be honest

Yes, it'll work without reinstallation, but you need to manually edit IPT internal files. Namely, registration2.xml at datadir/confg. Whole registry section should be replaced with just <registry/>. Make sure IPT is stopped before editing and then started again. There is no other way to fix it I'm afraid.

I'll give that a go!

I've edited registration2.xml to the following (redacted):
<registration>
  <registry>
  <registry/>
  <organisation>
    <key>0a16da09-7719-40de-8d4f-56a15ed52fb6</key>
    <description>Test Organization for IPT</description>
    <name>Test Organization #1</name>
    <homepageURL>[https://www.gbif.org/, https://registry.gbif.org/, https://ipt.gbif.org/]</homepageURL>
    <primaryContactType>administrative</primaryContactType>
    <primaryContactName>GBIF Helpdesk</primaryContactName>
    <primaryContactAddress>Universitetsparken 15</primaryContactAddress>
<EMAIL_ADDRESS>    <primaryContactPhone>+45 35 32 14 70</primaryContactPhone>
    <password></password>
    <alias>Test Organisation #1</alias>
    <nodeKey>02c40d2a-1cba-4633-90b7-e36e5e97aba8</nodeKey>
    <nodeName>GBIF Secretariat</nodeName>
    <canHost>true</canHost>
    <agencyAccountPrimary>false</agencyAccountPrimary>
    <associatedWithDoiRegistrationAgency>false</associatedWithDoiRegistrationAgency>
  </organisation>
  <organisation>
    <key>1cd669d0-80ea-11de-a9d0-f1765f95f18b</key>
    <description>The Research Institute for Nature and Forest (INBO) is a scientific institute of the Flemish Government in Belgium. INBO has resulted from the merger of the Institute for Forestry and Game Management and the Institute of Nature Conservation on January, 1st 2006.</description>
    <name>Research Institute for Nature and Forest (INBO)</name>
    <homepageURL>[http://www.inbo.be]</homepageURL>
    <primaryContactType>technical</primaryContactType>
    <primaryContactName>Dimitri Brosens</primaryContactName>
    <primaryContactEmail></primaryContactEmail>
    <password></password>
    <alias>Research Institute for Nature and Forest (INBO)</alias>
    <nodeKey>fb11cfe1-ebc3-45af-9159-17d9fddbcdac</nodeKey>
    <nodeName>Belgian Biodiversity Platform</nodeName>
    <canHost>true</canHost>
    <agencyAccountPrimary>false</agencyAccountPrimary>
    <associatedWithDoiRegistrationAgency>false</associatedWithDoiRegistrationAgency>
    <agencyAccountPassword></agencyAccountPassword>
  </organisation>
  <organisation>
    <key>625a5522-1886-4998-be46-52c66dd566c9</key>
    <description>Installed by default, used to indicate resource is not published by any organisation</description>
    <name>No organisation</name>
    <password></password>
    <alias>No organisation</alias>
    <canHost>true</canHost>
    <agencyAccountPrimary>false</agencyAccountPrimary>
    <associatedWithDoiRegistrationAgency>false</associatedWithDoiRegistrationAgency>
  </organisation>
</registration>

Yes. Now you need to register the IPT again via Registration options.

Aha! I'll ask around for a shared token/ipt password then. Thanks for all the help, I'll post here if I'm successful.

Closing this


Remove themeable variables markdown file

Description of Issue
Remove themeable variables markdown file generation

Resolved in https://github.com/cerner/generator-terra-module/pull/52


Alternatives and Environment Matching

One question that @guybedford brought up was how this proposal could handle things like different implementations depending on the platform.
Known Use Cases
Browser/Node Split
A package that uses very specific DOM (or node) APIs and wants to provide one export for all browser and another one for all versions node. Examples:

TBD

Node Legacy Build
A package that uses newer node APIs (or JS features) wants to provide a clean export for those while still supporting older versions of node by pointing them to a pre-compiled version of its source. Examples:

yarn's legacy build.

Browser Legacy Build (dropped from scope)
A package that includes code using the latest JS features but also wants to provide code that can be imported as-is into slightly older browsers to support a compilation-less experience. Examples:

TBD

Production Build
A package that has a lot of development-specific code that would be too expensive to run in a production environment. As part of its publishing process, it generates an optimized production build but also wants to provide the original development sources for their better debugging abilities. Examples:

react-dom

Compilation Cache
A package wants to be able to be up-and-running asap so it ships a precompiled version of its source, be it binary AST/V8 compilation cache etc.. This cache may be very specific to the engine and its version, so it wants to fall back to the original code if loading the cache fails. Examples:

yarn's use of v8-compile-cache

Prior Art

Import map's array of alternative URLs
The browser field
The react-native field
Browserslist
Editions
The engines field
The syntax field
Import map feature tests

Jan's Strawman
The idea is to embrace the import map format of specifying an array of alternatives. At its simplest, it's mostly useless:
{
  // "Try each of these URLs, use the first that exists or is supported."
  "exports": ["./unpublished-file.js", "./lib/real-file.js"],
  // [...]
}

One  possible use of this form would be to expose V8 compile caches etc., falling back onto the original script. But it becomes more interesting when we allow to replace any element in the array with an object describing a set of constraints being satisfied by this version:
{
  "exports": [
    {
      "node": "6",
      "from": "./lib/real-file.js"
    },
    "./build/es5.js"
  ],
  // [...]
}

Multiple constraints can be specified for each element. The constraints themselves are considered host-defined. The only reserved property name is from. The examples below will use the following constraints:

node: The (minimum) node version this variant supports.
browserslist: A browserslist expression describing the set of browsers this variant supports.
production: A boolean constraint that specifies that this is an optimized build meant for production (e.g. NODE_ENV=production).

When evaluating the constraints, the following rules should be followed:

Entries are evaluated in the order they appear in the array, one at a time.
String entries are always considered matching.
Unrecognized constraints must be ignored.
If none of the constraints is recognized, the entry must be considered incompatible.
If there are recognized constraints and they are compatible with the targeted environment, the entry is picked.
A picked entry acts just like a simple string entry: Other entries will only be considered if loading the resource from this path fails.

Jan's Strawman: Applied to Use Cases
Browser/Node Split
{
  "exports": [
    {
      "browserslist": "100%",
      "from": "./lib/browser.mjs"
    },
    "./lib/node.mjs"
  ],
}

The issue with user agent sniffing is that it goes stale very quickly.
For example, latest 2 Chrome is a moving target. Now this is fine in your build configuration which is updated daily, but for a package published on npm, this is a recipe for something to break in future.
For this reason I'm not sure how I feel about version-based matching being designed into the system at such a low level.
This is why I tend to prefer targets being specific environment conditions, which can be known to be either "on" or "off".
User agent sniffing is generally a last resort when dealing with deployed code. Rather feature detection is much more robust here.
Feature detection without code execution though is its own can of worms.
Throwing out a new idea here - one option here might be to permit a feature detection module to be defined which can itself determine if the condition should pass:
{
  "exports": {
    "./feature.js": "./main-feature.js",
    "default": "./main.js"
  ]
}

where if the feature is a "plain name" it is an environment conditoin, and where it is a "relative name", it is a local condition module with a default export to be treated as a boolean.

What might help further as well is to try to think in terms of very tangible use cases, over the general problem space.

(where I'm saying I'm not so sure about use cases 1 and 2 in https://github.com/jkrems/proposal-pkg-exports/issues/29#issuecomment-467931233)

For example, latest 2 Chrome is a moving target.

I think it's important here that "this code supported the last 2 versions of Chrome at the time of publishing" will only break if Chrome removes support for features in the future which is pretty big "if". Building an exhaustive list of features that are being used is a worthy ideal but I'm not sure it's realistic outside of auto-generating such a field.

Throwing out a new idea here - one option here might be to permit a feature detection module to be defined which can itself determine if the condition should pass

If that check can come from a library, maybe. But even then it would most likely lead to weird boilerplate code for things like "this is the production build targeting modern browsers and node 8+". But it may allow us to just punt on this and push everything into userland.

I think it's important here that "this code supported the last 2 versions of Chrome at the time of publishing" will only break if Chrome removes support for features in the future which is pretty big "if". Building an exhaustive list of features that are being used is a worthy ideal but I'm not sure it's realistic outside of auto-generating such a field.

It's a moving target in that it means we now have to read time-based package.json metadata in combination with this field, and then work out which chrome versions these were based on the date. Publish time might not even be a reliable metric as well, say using a mirror that changed it for example (like filestamps are not reliable),
A version reference like ^chrome@32 is certainly fine though, but these are also harder for the Node.js project where versions can make breaking changes. If a user has node@^12 and the package works fine in Node 14, how can users override this? Versions just bring up a lot of problems that will require other mechanisms to fix.
Rather, I would like us to explicitly understand the use case around version matching, with specific example relating to future workflows where es modules are the baseline, and how they help. Personally I think that the standard workflow in future will always be to compile the evergreen features to the "compatibility target", and that publishing evergreen syntax is an unnecessary goal, just like publishing evergreen code to the web is an impossible goal due to supporting older browsers.

Let me take an example of a library I was working on recently: It was using the global URL object. So the library was compatible with node 10+ and browsers. For older versions of node (8 and older), it would have needed a URL object injected from a polyfill. For older browsers I wouldn't have wanted to include my own URL implementation. I would've rather broken the library (unless the app was loading a proper global URL polyfill) so I wouldn't risk needlessly including a huge chunk of code.
There's 3 possible consumers here:

The module loader in node (we'll assume all involved node versions have import support).
A bundler trying to assemble builds for different predefined sets of browsers.
A dev server trying to serve the right (ad-hoc) import map based on the browser requesting the page.

My package provides getCurrentURL, a function that returns an URL object with the current URL being served. The implementation for node is in lib/current-url.mjs. A proxy of it providing a URL polyfill is in lib/node-6.mjs. A browser implementation is in lib/browser.mjs.
If there would be a feature test script, how would I make sure that the right version of each file is picked, especially in the bundler case? Would the bundler build a fake global environment using JSDOM, representing each possible browser targeted by the build? That seems fairly unrealistic.
Under the strawman above, I can solve this use case with the following package.json#exports value:
[
  {
    "node": 10,
    "from": "./lib/current-url.mjs"
  },
  {
    "browserslist": "100%",
    "from": "./lib/browser.mjs"
  },
  "./lib/node-6.mjs"
]

The better way to handle this workflow is to have URL as a module not a global. Globals won't be used anymore in a world of standard modules in the browser.
So rather you'd just have import { URL } from 'url' and be done with it. The build tool would know that url is Node.js's standard library and include the minimal browser adaptor for it.
Note you also didn't include support for IE11 :)

In the case where URL was say a browser specific feature, where you needed to custom fork in Node.js then you might do something like:
import URL from 'url';

and then have an exports map that maps the actual plain name:
"exports": {
  "url": {
    "browser": "std:url",
    "node": "./node-url-version.js"
  }
}

within that node file, if we had top-level await, then conditional polyfilling could be done too.
(and top-level await is making progress...)

Note you also didn't include support for IE11 :)

Right, on purpose! Because otherwise the bundler may actually include my polyfill and another polyfill. It's a feature, not a bug of that config. A simple feature test would have forced me to include superfluous code if the app is doing a global polyfill (which it may).

Right, on purpose! Because otherwise the bundler may actually include my polyfill and another polyfill. It's a feature, not a bug of that config. A simple feature test would have forced me to include superfluous code if the app is doing a global polyfill (which it may).

Ahh, your polyfill is in browser.mjs? Your users might be annoyed to find out they included a polyfill they didn't want.

Are we at all certain that standard modules for built-in features will become a thing for every single feature? Also, that doesn't really cover language features, only importable APIs.

Ahh, your polyfill is in browser.mjs? Your users might be annoyed to find out they included a polyfill they didn't want.

No, but I'm including a polyfill on older versions of node that don't have the global (or not even require('url').URL for node 6).

In addition the array maps could be useful to reserve for passing directly to import maps in the browser...

If what we interact with is covered by a standard module, we don't have to get fancy:
"exports": {
  "url": ["std:url", "./node-url-version.js"]
}

Which would imply though that exports allows overriding imports inside of the module as opposed to only imports of the bare specifier itself.

Btw, for node purposes we can keep the "browserslist" as out of scope. That would be a bundler (and potentially dev server) concern. And there compilation is happening anyhow, so version ranges are less interesting.
Node versions on the other hand are more tricky.

I don't think it's practical to compile away decorators and other future JS features on install or on run. And node will continue to add new APIs and I don't think it's realistic that each feature will be exposed as exactly one module, see recursive mkdir.
NODE_ENV checks ("production builds") will stay relevant and unless we say "it's impossible to run a node app in production without bundling it first with 3rd party tools", we should have a story for it. The story could be top level await and hoping that browser bundlers can optimize it away but it's a hack. And it's still super painful in the export * from './dev.js' case (multi-export).

I'm fine updating my examples with browser: true instead of browserslist: "100%". It would encourage people to publish only the build for the current evergreen browsers and make build tooling responsible to ensure proper compilation which I think is fair.

Prior art to be aware of: https://blog.meteor.com/meteor-1-7-and-the-evergreen-dream-a8c1270b0901. It deals with many of the same issues.
Also I wouldn’t let users define custom top-level fields, that just gives us headaches like we have now with trying to recreate "module". Instead:
{
  "exports": [
    {
      "path": "/foo",
      "from": "./lib/foo.mjs",
      "target": {
        "node": "6"
      }
    }
  ]
}

Hey, I'm a big fan of this strawman. I think it could work for other things too, such as testing for the existence of another built-in module, or the presence of some property of the global object. Imagine if BigInts were in a module std:bigint, and we have both a full polyfill, as well as a polyfill for just BigInt64Array/BigUint64Array. We could  include a list like this:
{
  "exports": [
    {
      "moduleExists": "std:bigint",
      "from": [
         {
           "modulePropertyExists": "std:bigint.BigUint64Array",
           "from": "std:bigint"
         }
         "./bigint-array-polyfill.mjs"
       ]
    },
    "./full-bigint-polyfill.mjs"
  ]
}

In this example, we have to test for multiple conditions being true at the same time, so from: is allowed to be its own fallback list, with its own conditionals inside of it.

Okay, I'm starting to come around to @guybedford's point of "can we do feature testing instead of version constraints", especially if we'd have shorthands for some feature sets. E.g. for syntax features like ES20XX..?

E.g. for syntax features like ES20XX..?

That would resemble Babel's presets that users are already familiar with.
Though don't forget ES modules are part of ES2015 😢

Well, it's the babel presets people are actively encouraged to migrate away from right now... The current recommended approach is using babel-preset-env with a browserslist expression:

As of Babel v6, all the yearly presets have been deprecated. We recommend using @babel/preset-env instead.
-- Babel Docs

But yes, anything below ES2015 wouldn't really make sense, to a certain degree.

For syntax, how about something like this?
{
  "js-syntax": "import()",
  "from": "something-using-dynamic-import.mjs"
}

The string would be parsed as JS (as a Module?), and if there were no syntax errors, it would select the indicated module.

I would be a bit concerned about this from a bundler perspective. E.g. a bundler/precompiler targeting environment X would have to parse the string, analyze the result, and then match it to a set of features (and then those to the target of the bundling). Definitely possible but seems a bit involved. We could define SyntaxError during parse of the from file as a defining factor as well..?

P.S.: Yes, that last sentence would be even more tricky for bundlers but would at least also remove any uncertainty about the code and the js-syntax getting out of sync.

Node
(e.g requires Node API's, NAPI)
package.json
{
   "name": "a",
   "engines": {
     "node": ">= 10"
   },
   "main": "./src",           // Script (CJS)
   "exports": {               // Module
        ".": "./src/index.js",
         ...
    }
}

Browser
(e.g requires WEB API's)
package.json
{
   name: "b",
   engines: {
     "browser": "last 2 versions"   // Browserlists or other feature detection
   },
   "exports": {                     // Module
        ".": "./src/index.js",
        ...
    },
    "browser": "./src/index.min.js" // Script (ES5, Bundled, Minified, ...) ?
}

Dual Mode
package.json
{
  "name": "c",
   "engines": {
     "node": ">= 12",
     "browser": "last 2 versions"
   },
   "main": "./src",                 // Script (CJS)
   "exports": {                     // Module
        ".": "./src/index.js",
         ...
    },
    "browser": "./src/index.min.js" // Script (ES5, Bundled, Minified, ...) ?
}

Usage
$PWD
npm engines -n|--node ">= 10" -b|--browser "chrome 74"

[WARNING] a ... requires a node environment ...
[WARNING] c ... requires node >= 12 ...
...

@michael-ciniawsky Right, that works for specifically the case where the browser build is ES5 and where only a single file is involved and not different files with different requirements. It also encourages the use of engines which is a feature that (to me at least) was finally made completely irrelevant by yarn. Because it conflates "system that installs the package" with "target platform of this specific file load".

Added engines to prior art.

@jkrems hm, how did yarn make it irrelevant? yarn chose to error on a mismatched engines field, unlike npm which long ago learned it was best to only consider it advisory.

Just one quick thought re "js-syntax": "import()": don’t forget that many features that people might want to detect for are new methods on global objects, like String.prototype.includes. That’s valid syntax even in runtimes that don’t include that method.

hm, how did yarn make it irrelevant? yarn chose to error on a mismatched engines field, unlike npm which long ago learned it was best to only consider it advisory.

 Because there were multiple packages that said "needs node 8!" because they used modern syntax. But we never used them in node, we only used them in browser builds. So the error was just plain wrong and kept tripping people up for no good reason.

@jkrems yes, i agree that erroring on "engines" is always wrong :-) thanks for clarifying.

@GeoffreyBooth I think the argument would be that non-syntax features should be mirrored (?) by APIs that can be imported. E.g. std:String.includes as a super ad-hoc example.

That's a pretty hard problem to solve in a static way, given that the mere presence of API or syntax isn't sufficient - the semantics (including environment-specific bugs) of both also matter, including whether API methods are polyfilled or not, and how correctly.

Two more things to include in the list of ways to detect along with browserlist and Babel presets is https://node.green/ and where it gets its list, https://github.com/kangax/compat-table. That’s a list of basically every feature from ES2015 onward, and what versions of Node support what.

@ljharb It may not fill all the use cases, but it's a step along the way to satisfy many use cases. I imagine dynamic checks would be possible as well to fill the gaps.

@GeoffreyBooth I'd be skeptical of basing a system on the Kangax checks specifically. These test some particular aspects, while leaving others open.

@littledan yeah I was just pointing out prior art. But if none of these can work then that's concerning. What can we use as a feature list then?

@GeoffreyBooth I don't have a good answer; I'm not really sure how to bound the work of checking for known bugs. I'd suggest starting with tests for properties/modules existing and syntax not being a syntax error.

Hey ho 👋, just wanted to say that this is a super useful feature and I'm happy that this proposal is trying to implement this kind of switch at the package level.
Regarding the engines/compatibility discussion: I think this can get quite complex and it might be too much for this proposal. For the first iteration I think it's enough to have this kind of "node", "browser" (maybe "electron") switch that we currently have. Ideally, the syntax/proposal would be extendable in such a way that we can implement this compatibility feature in a later iteration.

Looks like from the Chrome side (@mathiasbynens and @developit), there's currently a push for a syntax field as a shorthand for the yearly spec versions: https://github.com/whatwg/html/issues/4432

The pushback on that thread seems pretty convincing; we should watch it closely.

Added @littledan's write-up in https://github.com/littledan/import-map-feature-tests/blob/master/README.md to the prior art.

Supporting arrays is as far as this proposal goes, we now have a separate proposal for a syntax to do environment matching that can be used inside of the array syntax: https://github.com/guybedford/proposal-pkg-targets/issues. Support in node for something like it would be possible to add in the future.


kmscon: set strictDeps, fix cross compilation

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[x] riscv64-linux (cross) (depends on https://github.com/NixOS/nixpkgs/pull/270542)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

Thanks! I will look into it.


channeldb: Indicate cooperative close initator

Fixes #3709.
Update channeldb to save channel statuses indicating whether the local or remote party initiated a cooperative close. These values are written to db at the time of cooperative close broadcast, and reloaded in chain watcher when we need to dispatch a cooperative close.

Updated to add a new field in the db as @halseth suggested. I think it simplifies the PR nicely, and we don't use us 2 of our 3 remaining status bits.

Ready for another look @bhandras!
A TL;DR on the changes since you last had a look:

Went back to using channel statuses since we are increasing the size of the field
The CloseSummary bucket is nasty to add fields to, channels are keys not buckets, and have a bunch of optional fields tacked on the end, decided not to use this. If we want to change it, a separate PR with full migration is in order IMO.
Since this is just an aesthetic change for rpc, I decided to use the values in the historical channel bucket, since it is now written for all channels


another attempt to add the lockfile

testing if the image can be built with the lockfile present

@dlabaj do you want to give this another try?

Fixed issue #126


Where to put the hydrogen production slide in the user interface?

There is not really a clear-cut place where the hydrogen production slide belongs, but I see the following main options:
Transport Fuels

In the 'Transport Fuels' sidebar. For now, hydrogen is only used as a transport fuel so this location makes sense. However, there are at least two points:

perhaps confusingly, there already is a 'Road Transport' slide (and merging these slides would give a mess)
all other sliders grouped in this sidebar are used to set fuel compositions - not the production techniques that yield those fuels, as this slide does.

New sidebar 'Hydrogen'

Or in a new sidebar item, 'Hydrogen'. This would - possibly - avoid some confusion and the points mentioned above. However, the question might be whether hydrogen (consisting of one slide as of now) is 'worthy' of its own sidebar (also lacking tutorial videos).
Also, we should keep in mind the P2G developments and the distinction that we have so far implicitly made between 'transport hydrogen' and 'P2G hydrogen'.
@jorisberkhout @AlexanderWirtz @ChaelKruip @dennisschoenmakers , which option has your preference or do you perhaps see a better alternative?

@jorisberkhout @AlexanderWirtz @ChaelKruip @dennisschoenmakers , which option has your preference or do you perhaps see a better alternative?

New sidebar 'Hydrogen'. Would it make sense to call it 'Hydrogen production'?
And what do the percentages mean? (market share? of what?)

Would it make sense to call it 'Hydrogen production'?

If no other slides are added to it, yes, absolutely. :smile:

And what do the percentages mean? (market share? of what?)

Percentage of total hydrogen produced that has been produced by this technology.

Percentage of total hydrogen produced that has been produced by this technology.

Do you also set the production of hydrogen (somewhere)?

Do you also set the production of hydrogen (somewhere)?

The hydrogen production converters are demand-driven.

John prefers the section option ('sidebar item') with two changes:

Rename the slide sidebar item and slide to Hydrogen production
Put the Hydrogen production sidebar item in between the Renewable heat and Transport fuels sidebar items

I agree with John.
One minor comment by John is that we have to explain carefully what input fuels go into the various technologies.

Moved to 'Hydrogen Transport' milestone.

I am not against John's preference. There are pro's and con's for everything. it only makes sense if we also put P2G there, though!

For now I did the following (John's and @jorisberkhout's preferences )

Rename the slide sidebar item and slide to Hydrogen production
Put the Hydrogen production sidebar item in between the Renewable heat and Transport fuels sidebar items

I'm keeping this issue open, since P2G has not been added to the user interface yet and we should make sure that their (relative) positions make sense.

:+1:

Moving to 'Storage' milestone.

Closing this issue as everyone seems to like the current positions and orders of the slides


Create dynamic config for localhost vs EC2

Might just be env vars. Some work exists. Production comment switches, let's not do that again. Having this work would be very helpful for new devs and local development.
Completion criteria:

a switch exists for prod or local dev. Mostly involves setting different IPs.
feature is merged to main
there is a secure and effective way to distribute these configs(IPs, hostnames, etc). Currently this is a .env file

route53 possible solution?!

Starting to lean towards yaml config files for the various configurable bits including domains, #18 and anything we aren't going to use argparse for in populate_reservations.py

I'm good with yaml configs!
That would look like loading in some parameters at the app load, and figuring out which target host to point to (local vs ec2) via a flag?

I believe @otakup0pe took on the .env vars.
Can confirm functionality to switch between dev (localhost) and prod(aws)??

decided yaml wasn't lo-fi enough. do we think it's worth it to create a set of pre-defined dev vs prod env?

This is mostly done, with production secrets stored in an encrypted file #36  and dev secrets stored in an open file #37
Calling this issue closed.


Color was added to the scroll bar.

Use the primary color for the scroll bar and from the tailwind.config.js grab the color "dark-100" for the bar track.
I hope you like it!

Good work @ivanosquis10 .  What about the browser support for this scrollbar? Is it visible on every browser?

Hi @Bitnagar, I did some research at the time and it is supposed to be the best way to do it, and in "Can I use" it has a 92% acceptance rate. So I think it should work for most of them and I hope so hahaha

url: https://caniuse.com/?search=webkit-scroll


feat: add health retrieval tasks

Draft PR to track progress on our fork.
Checklist

[ ] Run tests locally to make sure nothing is broken using make test.
[ ] Run the formatter to format the code using make lint.

Adding datasets checklist

Reason for dataset addition: ...

[ ] I have run the following models on the task (adding the results to the pr). These can be run using the mteb -m {model_name} -t {task_name} command.

[ ] sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2
[ ] intfloat/multilingual-e5-small

[ ] I have checked that the performance is neither trivial (both models gain close to perfect scores) nor random (both models gain close to random scores).
[ ] If the dataset is too big (e.g. >2048 examples), considering using self.stratified_subsampling() under dataset_transform()
[ ] I have filled out the metadata object in the dataset file (find documentation on it here).
[ ] Run tests locally to make sure nothing is broken using make test.
[ ] Run the formatter to format the code using make lint.

Adding a model checklist

[ ] I have filled out the ModelMeta object to the extent possible
[ ] I have ensured that my model can be loaded using

[ ] mteb.get_model(model_name, revision_id) and
[ ] mteb.get_model_meta(model_name, revision_id)

[ ] I have tested the implementation works on a representative set of tasks.

Closing since it's now merged in https://github.com/clinia/mteb/commit/1cc6c9e0fe62ca4e77708b641823fa1a121f048b !


FOD on free Hyper-V Server

Can FOD be installed on the free versions of Hyper-V Server?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5da35d75-87fe-4432-9a86-d07f1b4f41b5
Version Independent ID: 6e3f4dfd-d101-c26b-94a4-fe44093dba8e
Content: Server Core App Compatibility Feature on Demand (FOD)
Content Source: WindowsServerDocs/get-started-19/install-fod-19.md
Product: windows-server-threshold
Technology: server-general
GitHub Login: @JasonGerend
Microsoft Alias: jgerend

I'd say yes. It is an addition to the server product. Nowhere I read about a limitation or license requirement.
Try it out in your lab

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close