Function name, did.register, is confusing

Registering a DID has a well known meaning.
In the context of web5-js, web5.did.register has a different meaning - it's associating a DID with a DWN.
This will lead to a confusing developer experience. Please change the name of this function to a term that's not overloaded

Appreciate the feedback and for highlighting the potential for confusion.
The name originally stemmed from the concept of having a local registry of cached DIDs that you already had the DID data for (short & long form ID, DID document, private keys, etc.).
More like add to local registry or cache... as opposed to registering a DID with a system that facilitates creation/verification/updating/deactivation of DIDs and DID Documents.  I can see where this might be confusing.
The intent behind this function (currently called web5.did.register()) is to register a local DWN/datastore associated with the DID in application state to indicate that the target DID's DWN can be access locally / in-memory... thereby bypassing the need to resolve the DID document and connect to a remote service endpoint.
We can give it more thought but what about changing the function to associate it with the DWN methods rather than DID:
web5.dwn.register()
Or something like:
web5.dwn.registerLocal()

Putting the method on dwn is a good idea

first question that comes to mind is "wait.. register wut? a dwn?" but better than web5.did.register

@csuwildcat is saying DWN handles more so maybe register should be at the top level (web5.register)

web5.consign lol

what about web5.grant?

what about web5.grant?

i like grant!

We should probably stay way from using the word "grant" in this context as it is going to get confused with granting of permissions.  The effect of the action also is not related to the "granting" of anything.
NOTE: The side-effect of including keys is only an interim approach until a proper "key store" concept is introduced, so I wouldn't focus on that aspect as the primary reason the method Web5.did.register() exists.  See below for explanation.
What web5.did.register() presently does is:

record an entry to the Web5() instance's DID cache with the following information:

did {string}: DID that is the tenant/controller of the specified DWN endpoint.
endpoint {string}: URL where the DWN endpoint can be reached for any actions.  Examples:

app://dwn for an in-memory DWN (think an in-browser DWN or DWN embedded in an desktop agent app)
http://localhost:55500/dwn for a local agent app, like desktop-agent
https://dwn.tbd.website for a cloud-hosted DWN

connected {boolean}: Does the DWA presently have an authorized connection to the endpoint?
keys: Should be a {boolean} that indicates whether the running App that contains this recorded did/endpoint/connected/keys information has the public/private keys to sign on behalf of this DID.

In the case of an in-browser app, the answer may be yes that it does have keys.
In the case of a desktop agent or cloud agent, the answer is likely that it wouldn't have the keys on the browser but would running in the agent app.
In the case of using a TPM or SecureElement, none of the running apps would have the private key material.
Currently keys is an object (JSON) containing the key pair for the tenant/controller did, which is used to sign/verify message.  As mentioned earlier, this is a temporary state that will be eliminated when a "key store" construct is introduced to Web5 JS.  At that point, keys will become a boolean.

This value is stored in memory because it can change with each invocation of the decentralized web app.  Although it is stored in memory, application developers are expected to provide automatic "registration"/"caching" of any DIDs that the app knows are addressable via a specific endpoint. For example, in the case of a remote endpoint (desktop agent, cloud, etc.), the agent may have multiple DIDs that a single human controls (think social, personal, work accounts) so the user has to select one.  We have this implemented with automatic "registration" in the desktop-agent repo today.
Whenever a call to web5.dwn.records.write() or web5.dwn.protocols.configure() is made, a target and author DID is included in the method call indicating which DID the message should be sent to for processing and which DID should sign (could be alice signing and writing to alice's DWN or could be alice signing and writing to bob's DWN).  If the target DID is a DID with a known addressable endpoint (e.g., app://dwn for in-memory or http://localhost:55500/dwn for a connected desktop agent), when Web5 JS resolves the DID, we DO NOT want it to try and send the message to the remote endpoint specified in the DID document.  This is why web5.did.register() is called -- it caches a local entry telling the app -- "hey, don't try to yeet this message to a remote endpoint...  I've got the DWN right here and I've already got keys (or don't) to sign."  When keys are not available to sign but connected is true for the author DID, that means that there's an agent available that this app can send the DWeb Message to so that it can be signed and transported to the targeted DID's endpoint (whether its your own in app memory / localhost or one that can be reached remotely via HTTP/S).

That was a lot but hopefully that context helps.  Happy to walk through an draw it out on a call.
The last bullet point above is WHY the method was put under web5.did.register()... because it impacts what data is returned from DID resolution during the processing of a DWN action (records write/query, protocols configure/query, etc.).
Effectively web5.did.register() is annotating some additional information about a specific DID to inform Web5 JS's other functions that when they try to interact with this specific DID, and particularly this DID's DWN, there is more information about how to contact their DWN (the endpoint property), whether there is currently a connection to that endpoint (the connected property), and whether keys are available to sign (the keys property).
Perhaps a more appropriate method call would be: web5.did.annotate() ?

Yes, let's do a call. I know there's a whole backstory but it remains that on sight, it's a confusing name because of what it means to "register a DID" outside of web5 js

how about web5.dwn.allowDID or web5.dwn.associateDID?

this is done now, right, @frankhinek?


Ks/bidsify

script to bidsify INsIDER_SCT_Segmentations_COR data
related to https://github.com/ivadomed/model_seg_ms_mp2rage/issues/49

Opening a PR for the script is convenient (because we can review on GH), but to be BIDS compliant, I think we should keep this script in the dataset (instead of the repository), because the script is specific to the dataset, not to the model creation. Eg: if we decide to create another model using this dataset, then the BIDS curation script will become 'invisible'.

thanks for the feedback! I'll incorporate the changes in a bit.
As per:

keep this script in the dataset

I'm guessing this would be with the reformatted dataset and not the original INsIDER_SCT_Segmentations_COR data (this folder will be removed?). So then I'll add a description of the original folder structure in the "How to use" part at the beginning

I'm guessing this would be with the reformatted dataset and not the original INsIDER_SCT_Segmentations_COR data (this folder will be removed?)

yup! 👍

Everything (incl. Script) is on ‘duke/temp/kiri/bidsify’. If everything is okay, should I just close this PR?

closing because the script will be added to the dataset (not this repository)

I added @kiristern to the WRITERS group for the data.neuro.polymtl.ca:datasets/basel-mp2rage repository, so she will be able to push these changes there.


merge from arlac77/template-arlac77-github,arlac77/template-esm-only

package.json

chore(deps): add ^3.11.0 remove ^3.10.1 (devDependencies.ava)

:tada: This PR is included in version 9.9.7 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[resotoshell][feat] Load metadata from core

Description

To-Dos

[x] Add test coverage for new or updated functionality
[x] Lint and test with tox

Issues Fixed

Fixes #XXXX

Code of Conduct
By submitting this pull request, I agree to follow the code of conduct.

Codecov Report

Merging #833 (4e1e1bd) into main (ee17313) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head 4e1e1bd differs from pull request most recent head be1c4e9. Consider uploading reports for the commit be1c4e9 to get more accurate results

@@           Coverage Diff           @@
##             main     #833   +/-   ##
=======================================
  Coverage   89.86%   89.86%
=======================================
  Files          69       69
  Lines        9993     9994    +1
=======================================
+ Hits         8980     8981    +1
  Misses       1013     1013

Flag
Coverage Δ

resotocore
89.86% <100.00%> (+<0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

resotocore/resotocore/cli/command.py
87.55% <100.00%> (ø)

resotocore/resotocore/cli/model.py
96.71% <100.00%> (+0.01%)
:arrow_up:

Continue to review full report at Codecov.

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


Fix misleading crash when view config is not found

Summary:
When a view config can not be found, it currently errors with TypeError: Cannot read property 'bubblingEventTypes' of null.. Instead invariant at the correct location and prevent further processing of the null viewConfig.
Changelog: [General][Fixed] Improved error message when no view config is found.
Differential Revision: D62756596

Merged as https://github.com/facebook/react-native/pull/46518


OpenApi schema field descriptions containing new lines

Hi,
A small possible issue I noticed by accident when testing something.
Say that I have an OpenApi schema that contains something like
"status": {
    "type": "string",
    "description": "pet status\r\nin the store",
    "enum": [
        "available",
        "pending",
        "sold"
    ]
}

Then i get this for the generated type

Which looks like the doc comment has been split over two lines, when I guess it should be collapsed in to one, or have /// on both lines? (fwiw, I have a couple of schemas that are generated from ASP.Net Core services which do that if a comment on the .NET type is multi-line).
Thanks.

Hi @Numpsy this should be an easy fix I think. We can split the description over multiple lines.
It would be awesome if you could share the schema you have or an anonymised version of it where you rename fields or remove descriptions. It would make for a good example to test this project with since I don't have proper sNSwag schema's to work with.

fwiw, I put a couple of (very) simple schemas at https://github.com/Numpsy/OpenApiExample/tree/default/generated that show how Swashbuckle and NSwag use a differing approach to allOf for subtypes (NSwag includes base/subtypes in the schema by default, where Swashbuckle merges everything into one object unless configured otherwise.), and also shows a bit of extra metadata that NSwag includes for enums that it's own client generator uses (which may or may not be of interest).
I was going to include an example TimeSpan property in the models as well as that's an extra little bit of 'fun' with ASP.Net Core, but then just kept it simple.

Thanks a lot for the example schemas 🙏 I think I can make the integer enums work with the generator. As for allOf, I think merging the properties will be the best approach by default since F# records don't like inheritance

More complicated schemas are also welcome for testing :)


document tfrobot

https://github.com/threefoldtech/tfgrid-sdk-go/tree/development/mass-deployer
the documentation already exists in the repo but needs to be visible on the manual

duplicate of #372


Allow opening menu by swiping from only far left/right

I had issues with the swipe slideout when there is a horizontal scrolling div, see issue #58 and issue #59.
This PR is based on PR #10 which has been closed and is no longer available.
It works for me. Any enhancements or ideas are welcome.
Would like to see this been merged :)

This would be very useful! +1

@pazguille any news on this? I'm currently maintaining a separate fork just to have this kind of feature, bit a pain tbh.
As I reported in issue #59 it will be good to have some form of dragWidth which only allows opening the menu within the given width from the left / right side of the screen. This is critical when you have horizontal scrolling things like carousels, or overflow stuff on the page. At the moment its causing the menu to open when scrolling.
I know you can can get around this by using the beforeOpen events and detect whether to open or not based on the currentTarget etc, but that's a real pain and much harder than it needs to be.

+1

+1

+1

+1

+1

+1 + 1 +1

I needed that feature to mimic native mobile apps menu.
Since I didn't want to maintain a fork I used the following code to update slideout._preventOpen. I reused _tolerance for the size of the padding, since it was so tiny.
let panel = document.getElementById('panel');

let slideout = new Slideout({
    'panel': panel,
    'menu': document.getElementById('sideMenu'),
    'padding': 256,
    'tolerance': 50
});

panel.addEventListener('touchstart', function(eve) {
    let offset = eve.touches[0].pageX;

    if (slideout._orientation !== 1) {
        offset = window.innerWidth - offset;
    }

    slideout._preventOpen = slideout._preventOpen || (offset > slideout._tolerance && !slideout.isOpen());
});


go fmt?

Hi,
The work you're doing on this package is great. I just want to mention that it seems 'go fmt' can be run on the code (I noticed this due to vendoring the package in my own projects...)
Might have some crash reports for you soon, but in the meantime, thanks again!

Done, thanks!


First successful ubuntu 16.10 aws ansible run

Solves ansible bootstrapping problems on new Ubuntu and unix socket issues:
https://github.com/ansible/ansible/issues/11536#issuecomment-120092814
https://stackoverflow.com/questions/32429259/ansible-fails-with-bin-sh-1-usr-bin-python-not-found#34402816

Roman -- thanks so much for all these. Will be updating soon with better docs and more automation of VPC setup.


Feature:

Feature or Idea - What?
We want to use Landing zones, but have a problem, and that is that we it is required in our organization that we create environments with the region "Norway". And we cannot see that this choice is appropriate when defining the various environments under "Landing Zones". Is this something you can add, so that we can create the environment within the region "Norway"?
Feature or Idea - Why?
Most of the Norwegian organizations want to create there environments in region "Norway". As organisation iam working for cannot use Landing Zones as far we can not select "Norway" as a data region. And this is for the Norwegian Taxoffice. When this option is available it will be easy for all other organisation to use Landing Zone reference.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for the feedback! We will add this to the backlog and see if we complete the validation on our side in the next couple of days. I will revert as soon as we have an update.


MP Vision Tasks web solutions performance...

Hello,
I recently compiled WASM mediapipe build from the sources publicly available.
It worked fine for ImageSegmentation tasks with CPU SIMD backend. But unfortunately later I realized it cannot be used for GPU inferencing because there are no sources available for GLES30 backend.
So I had to stick to standard task-vision API wasm NPM builds.
But unfortunately standard library is about twice slower than my own compiled wasm module. My own module inferencing time is 4ms, standard library takes 8ms.
I suspect - problem is in multiple sync points between CPU and GPU in standard library with CPU backend. Not sure why standard API implementation always uses texture as an input. During WEB profiling I see it uses glReadPixels within wasm module and it is slow! In my own implementation I never use WebGL if CPU backend is choosed. So why default API uses webgl2 based canvas ?

Any updates regarding this issues? The situation is even worse. Today i tested the model which takes 5 ms with my own compiled WASM module.  But it takes over 22ms with default tasks vision solution. So default wasm is almost 5 times slower!

Profiled in chrome. glReadPixels takes over 10 ms in wasm module... With CPU backend!!!


[FLOC-3965] Ensure log message is written if EBS volume is not ready

Line to log a message is missing the write() method.
This is amongst the reasons it was difficult to see what is generating the AWS RequestLimitExceeded errors.

Thanks, LGTM when tests pass.

Resubmitting this PR for review, since the simple change to add a write method to the log message turns out to do lots of validation, which failed due to missing fields in the log message.
In order to add the missing fields, I moved the log message into the nested function, where the information was more readily available.  This has the effect of displaying the message one extra time. This could be considered a good thing, as it now displays a log message each time it does the check. If everything runs quickly, it now prints one log message instead of zero.
Once this change was done, I simplified the calling function by replacing with poll_until and passing the elapsed time instead of start time as a parameter. This latter change allows a sleep in the functional tests to be removed, saving 5 seconds off the test run time.

That's some quite nice refactoring :)
Interesting that even if the write() had worked in the previous code, an immediate success from _should_finish would prevent us getting the log message, so yes this is definitely an improvement.
(my fault for not checking it more thoroughly first time it went up for review, sorry! also wrongly assumed validation occurred before writing the message, so didn't occur to me errors would occur for that reason at the writing stage)
This is passing tests and looks sound, so I think it's good to merge.


Update citations samples with title and nullable uri

Updated the citations samples to include cases where the response has a title instead of a uri. This scenario was reported in https://github.com/firebase/firebase-ios-sdk/issues/13518.

cc: @hsubox76 I think the JS SDK already handles uri and title correctly. I think changing https://github.com/firebase/firebase-js-sdk/blob/f7c6dc4fe10ca3999b1499476ecf9b911c534d25/packages/vertexai/src/requests/stream-reader.test.ts#L213 from 2 to 3 will resolve the test failure when we tag the next major version.

JS Unit tests should be passing after https://github.com/firebase/firebase-js-sdk/pull/8445


The composite video is a little shaky

The composite video is a little shaky
https://user-images.githubusercontent.com/7991905/166456162-98050676-c26c-4eb2-ac30-79f0a3b3a2db.mp4

@c1a1o1
Hi,
I'm not exactly sure, but it seems to me like the order of frames might be somewhat messed up.
How did you split the video into frames?
The frames are sorted in alphabetical order, so "frame10.png" comes before "frame1.png".
The solution to that would be to add leading zeros, which the command in our README does automatically:
ffmpeg -i "video.mp4" "video_frames/out%04d.png"
Hope this helps

it maybe the 18 frames instead of 25? check the latest code.

it maybe the 18 frames instead of 25? check the latest code.

Not this reason，it should change the sorted method.
def make_dataset(dir):
    images = []
    assert os.path.isdir(dir), '%s is not a valid directory' % dir
    for fname in sorted(os.listdir(dir)):
        if is_image_file(fname):
            path = os.path.join(dir, fname)
            fname = fname.split('.')[0]
            images.append((fname, path))
    return images

This sort function which the repo used is based on string priority, so 2.png will be later than 10.png.

Thanks  for  all! @rotemtzaban @rinongal @850552586


Revert "Only allow Zookeeper access for config servers in hosted Vespa"

Reverts vespa-engine/vespa#5244

ZooKeeperWrapper.java:66 in hosted broke.


SDP-846: [auth / httphandler] Update user password

What
Support an authenticated user to update their password by providing the current password and new password
Why
In order to have a cleaner password process, we need two separate password flows for resetting passwords.
Known limitations
N/A
Checklist
PR Structure

[x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).
[x] This PR's title starts with the name of the package, area, or subject affected by the change.

Thoroughness

[x] This PR adds tests for the new functionality or fixes.
[x] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[x] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[x] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[x] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[x] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[x] This is not a breaking change.
[x] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr18.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr18.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr18.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr18.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr18.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr18.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr18.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr18.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr18.previews.kube001.services.stellar-ops.com


(homebrew cask) 1Password does not work for (homebrew cask) Firefox (but for homebrew cask Chrome)

related to: https://github.com/caskroom/homebrew-cask/issues/5674
But:

my apps get linked to /Applications
the problem only occurs for Firefox, not for (also with homebrew cask installed) Google Chrome

Although the 1Password Firefox extension is installed, when I activate the 1P window, it always offers me to install it... With Firefox installed without homebrew cask, I did not have this problem.
Any thoughts?

It shouldn’t be working with Chrome — it’s an anomaly that it is. 1Password shouldn’t work with symlinked browsers to /Applications, and there is nothing we can do to fix that.

FWIW I happily use cask-installed 1password w/ chrome and firefox. it's the Mac App Store installed 1password that has trouble.
I believe you might be able to work around this by unchecking this option:

Ah, yes should’ve specified that. It’s on Chrome’s caveat.


Fixing Slick Grid accessibility bugs.

This fixes #19864, fixes #19843, #19831
Also, this PR needs to be updated to the latest version of ADS Slick to truly fix everything. The PR for that is over here.
https://github.com/microsoft/SlickGrid.ADS/pull/7

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 107 (5.61%)  changed or added relevant lines in 3 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.01%) to 42.054%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/browser/modelComponents/table.component.ts
0
1
0.0%

src/sql/base/browser/ui/table/table.ts
0
3
0.0%

src/sql/base/browser/ui/table/plugins/checkboxSelectColumn2.plugin.ts
6
103
5.83%

Files with Coverage Reduction
New Missed Lines
%

extensions/schema-compare/src/dialogs/schemaCompareOptionsDialog.ts
3
50.46%

extensions/sql-database-projects/src/dialogs/publishOptionsDialog.ts
3
50.47%

extensions/notebook/src/jupyter/serverInstance.ts
4
75.5%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
27914

Relevant Lines:
61853

💛  - Coveralls

the file name is checkboxSelectColumn2.plugin.ts, seriously? :)
why not update the existing class?

@aasimkhan30 - FYI I believe that the current expectation is that we're not supposed to close issues ourselves. The a11y team is the one that does that. So please remove the auto-close keywords from your description so they stay open.

And is this ready for review? Please set it to draft if it's still in progress

@aasimkhan30 please remove the auto-close tags as @Charles-Gagnon pointed out.

@alanrenmsft , updated description with gifs


[ Accordion Menu ] Missing Carets

Accordion Menu not displaying caret dropdown arrows, tried multiple fresh installs using Foundation CLI.
It appears that the :after  pseudo element is not being added to DOM.
Tested Line 10 of components/_accordion-menu.scss and anything in  @if $accordionmenu-arrows { ... } is not being executed. Where am I going wrong?
Can't find any reference to @include foundation-accordion-menu in repo

Not sure if this was intentional but @include foundation-accordion-menu was not listed on app.scss added it to the include list and boom carets found.

Not intentional, thanks for catching it. Made the necessary changes to the templates here and here.


Bug: Read override config in Metrics Manager

The metrics manager has its own method of reading sink config, it does not use the Config#loadConfig method from the SPI. It should read override.yaml when reading sink config. #3287 has more details.

@nwangtw @nlu90

Refactored the changes a little to better accommodate tests. CI should pass now.

Oops, my bad, CI passed for this one, an integration test failed on #3292. I accidentally pushed a commit here, but it's an empty commit, so it shouldn't change things.


Implement Rich Indexing Specification

Your idea:
The rich indexing specification is designed for building an arbitrary number of Book Index style lists consisting of alphabetized Topics and subtopics.
The system involved is two-part. In the markdown parsing, index tokens are processed and either converted to HREF links or consumed. The snippet parses the brew source, collates duplicated entries, and inserts an alphabetized index list for each list.
The markdown takes one of two forms - each is a single line.

#Index2 List|Of|Topics - One or more Topics, separated by a | character that will be included in the user-specified  index Index2
#Index2 List|Of|Topics // Subtopic - One or more Topics, separated by a | character with a subtopic that will be included in the user-specified  index Index2

While there may be multiple topics, there may only be one subtopic in a link.
Parsing Details:
In case 1, An HREF Anchor link in the form  and consumed from the markup.
In case 2, An HREF Anchor link in the form  and consumed from the markup.
Snippet details:
This assumes that the marked run created proper anchors.
The snippet runs its own parsing against the brew text. This parsing will collect all the indexing markdown tags and the associated page number.
Duplicate Topic and Subtopic entries will be collated so that references to the same index text on multiple pages will yield an ordered list of pages in relation to the indexed text.
Topic entries will be alphabetized.
Subtopic entries will be alphabetized.
Each list will be rendered with the Lists name as an H2 header followed by the ordered contents of the index followed by a \page.
An active PR for an earlier version of this exists as https://github.com/naturalcrit/homebrewery/pull/3113 and will be updated to the new markdown shortly.
Styling will be derived from the existing Indexing snippet styles.

Your #1 and #3 are normal headers, due to the space after the #

Your #1 and #3 are normal headers, due to the space after the #.

Thank you, Corrected.

Is there a reason that tags with subtopics leave an anchor behind but without a subtopic don't? Shouldn't they all leave anchors behind?

It was a gut decision, I see no problem with having both leave anchors.

What happens if there are two instances of adding an index marker of the same topic/subtopic on the same page?
Currently, both would receive an anchor of the same id .. any link to that id value would still work, but targetting only the first instance, and though it is invalid html to have multiple instances of the same id in the document it doesn't really cause any problems.
(BTW, I don't anticipate any duplicate collisions with other minted ids from e.g. headings, as these indexing ids incorporate an underscore _ and headings have their auto-minted ids normalised to plain text lowercase with dashes for punctuation.)

In case 3 and 4, an HREF Anchor link in the form  and consumed from the markup.

The attribute names of subjectheading and entry are not valid html. These should be data-topic and data-subtopic instead.

In case 3 and 4, an HREF Anchor link in the form  and consumed from the markup.

The attribute names of subjectheading and entry are not valid html. These should be data-topic and data-subtopic instead.

Invald? no. Non-standard? Sure.

What happens if there are two instances of adding an index marker of the same topic/subtopic on the same page?

We could probably find a way to only emit the anchor for the first one and just ignore the duplicate.

What happens if there are two instances of adding an index marker of the same topic/subtopic on the same page?

We could probably find a way to only emit the anchor for the first one and just ignore the duplicate.

Alternately, We can track and instance mark or we can consider it user error. Dunno what is entirely best.

The attribute names of subjectheading and entry are not valid html. These should be data-topic and data-subtopic instead.

Invalid? no. Non-standard? Sure.

It doesn't passes w3c's validation testing

The data-* attribute thing has been around a long time, specifically designed for adding arbitrary attributes to elements.

Some more comments:

Do we actually need the HTML attributes? If the link URL is unique, is that sufficient for this without cluttering the markup?

Is there a strong reason we don't want multiple levels of subtopics? The D&D PHB only goes one level deep but it seems like this syntax could support multiple topics and multiple subtopics:

Topic/Subtopic|Topic/Subtopic/SubSubtopic|Topic

#) I'm not sure this was fully addressed: What do we want to do as far as a "default" label? On the one hand, just putting index into the snippet might work, and requiring it to be exactly 1 word removes ambiguity. On the other hand not needing any label at all looks nicer.

This was suggested on Gitter:

...when the snippet generates the index it extracts the label from the line and outputs as a header abover the index. This assumes the label is one word only...

I like the idea of generating a header based on the label. Should we support multi-word labels?

Addressing 2 and 3, I might suggest placing the label after the topics, delimited by another #:

#Topic|Topic|Topic             // Default
#Topic|Topic|Topic #Appendix A // Supports multiple words if needed

This would allow for no label as well as multi-word labels without ambiguity.

Do we need any kind of "see X" notation?

Warhorse links back to creature statistics, but creature statistics doesn't link back to Warhorse.
Or is this something we can already infer logically using our current syntax somehow?

Do we actually need the HTML attributes? If the link URL is unique, is that sufficient for this without cluttering the markup?

I wasn't sure at the time but thought it would be better to have them present, then decide they weren't needed than the other way around. If we are forced for (currently unguessable ) reasons to parse the <pages> to build the Index, the info is there.

Is there a strong reason we don't want multiple levels of subtopics? The D&D PHB only goes one level deep but it seems like this syntax could support multiple topics and multiple subtopics:

I mostly constructed it that way because I could not recall ever seeing more than two depths in an RPG index. If we did that, I think we'd want to remove the "This subtopic can belong to multiple topics" code and force 1:1:1...  for Topics and subtopic children.

#) I'm not sure this was fully addressed: What do we want to do as far as a "default" label? On the one hand, just putting index into the snippet might work, and requiring it to be exactly 1 word removes ambiguity. On the other hand not needing any label at all looks nicer.

This was suggested on Gitter:
I like the idea of generating a header based on the label. Should we support multi-word labels?

I don't see a problem with it.

Addressing 2 and 3, I might suggest placing the label after the topics, delimited by another #:
#Topic|Topic|Topic             // Default
#Topic|Topic|Topic #Appendix A // Supports multiple words if needed
#Topic/Subtopic    #Appendix A

OOh. I like this.

Do we need any kind of "see X" notation?
Or is this something we can already infer logically using our current syntax somehow?

I don't think we can infer it reasonably, but it is something we could see about adding as another delimited column.
#Topic/Subtopic@See Also 1@SeeAlso2#Index
Maybe?

index names
Alternative syntax might be #index name: topic/subtopic.
When you have lots of indexing entries it's nicer to have the consistent string be at the front for readability
#Index name: Topic/subtopic
#Index name: Another Topic
#Index name: Another Topic/and a subtopic
#Index name: Another Topic/and second subtopic
#Index name: Another Topic/and third subtopic

cross references
With the "see also", do note that there are usually two kinds: "see also topic", and "see topic". This is indexing convention. (I know people that index books as their profession).

A couple of random thoughts.

I rather prefer // to / for the separator - it mirrors the :: for glossary and allows the use of / without escaping in a topic or subtopic
What about using a variable for a multiple-word index name? We could do something like

$[index_default](Appendix A: Indexes)
#_default Topic//Subtopic

If we have a multiple-word Index label, I think we should allow the use of the colon in that label so perhaps separate with #?  #Appendix A: Index#Topic//Subtopic

We might need to stew a little more on the See/See Also scenario. Should this decision be a block or can we push it to a different PR?

The See/See Also implementation .. it would be prudent to reserve a syntax though,

For the reservation, I suggest  appending |See|See Also where either are optional.
examples:
See reference only
#Index#Topic//Subtopic|See
See Also Only
#Index#Topic//Subtopic||See Also
Both
@#Index#Topic//Subtopic|See|See Also

An index entry wouldn't have both See and See also.
If an index entry does have a preferred term (i.e. See ...), then it is that referred index entry that would have the related concepts See also cross references.

The documentation I say, doing quick "what are these concepts" to refresh my brain of the specific meaning did both, though I think that may have been a case of poor examples.
This is clearer, from https://ugapress.org/resources/for-authors/indexing-guidelines/:
CROSS REFERENCES
The cross reference is a space saver and serves to prevent duplication. However, it is not worthwhile to use a cross reference if the length of the cross reference takes more space than listing (repeating) the page numbers. Here duplication is permissible.

In making a cross reference, be sure the exact words of the referenced heading are used. Also make sure there is such an entry. Follow the capitalization style you have used for index entries (“See also education” if common‐noun entries are lowercase, “See also Education” if all entries are capitalized).
See follows an entry with no locators—it simply refers the reader to another part of the index. See also follows an entry with locators; it refers the reader to additional information in another entry. See also under refers to the reader to a subentry under certain circumstances. See The Chicago Manual of Style for more information.
See, See also, and See also under should be underlined unless preceding an underlined (italic) cross reference, in which case use roman (“See also education” but “See also Souls of Black Folk, The”).
Separate cross references with semicolons.

With that in mind, I suggest the following
See: postfix |cross reference entry
See Also: postfix ||cross reference entry
See Also Under: postfix |||cross reference entry
This limits the prohibited characters from the Subtopic and postfix to a single character which I feel is better than three separators.
Examples.
See:
#Index#Topic//Subtopic|See
See Also:
#Index#Topic//Subtopic||See Also
See Also Under:
#Index#Topic//Subtopic|||See Also Under

I like the idea of using | to separate the main topic and the reference ("see") topic. Based on the indexing guidelines shared by @dbolack-ab, I actually think we can logically extract which see/see also/see under/see also under variation to use based on the complete accumulated index contents:
For example,:

#Index# Main Topic|Other Topic A
#Index# Main Topic/Subtopic|Other Topic B

This will drop an anchor for Main Topic and another anchor for Main Topic/Subtopic at that location (but not Other Topic A or Other Topic B).
See

If Other Topic A has no anchor dropped anywhere in the document and it is listed as a reference to a top-level topic, the index entry for Other Topic A will be use "see":

Main Topic, 12
    Subtopic, 12
Other Topic A, See Main Topic

See under

If Other Topic B has no anchor dropped anywhere in the document and it is listed as a reference to a subtopic, the index entry for Other Topic B will use "see under":

Main Topic, 12
    Subtopic, 12
Other Topic B, See under Main Topic

#Index# Other Topic A
#index# Other Topic B
...
#Index# Main Topic|Other Topic A
#Index# Main Topic/Subtopic|Other Topic B

This will drop an anchor for Other Topic A and another anchor for Other Topic B, then later also drops anchors for Main Topic and Main Topic/Subtopic.
See also

If Other Topic A does have any anchors dropped somewhere and it is listed as a reference to a top-level topic, the index entry for Other Topic A will have its own page number(s), and use "see also":

Main Topic, 12
    Subtopic, 12
Other Topic A, 5-6, 8
    See also Main Topic

See also under

If Other Topic B does have any anchors dropped somewhere and it is listed as a reference to a subtopic, the index entry for Other Topic B will  will have its own page number(s), and use "see also under":

Main Topic, 12
    Subtopic, 12
Other Topic B, 5-6, 8
    See also under Main Topic

Then users don't need to know the ins and outs of index formatting to select the correct option of | or |||, as the correct wording will be generated automatically based on what other index markers exist.

I rather prefer // to / for the separator - it mirrors the :: for glossary and allows the use of / without escaping in a topic or subtopic

I still prefer a single / because that looks cleaner to me as the well-established "subfolder"-type symbology that many are used to (and is what Obsidian uses for tags. You have probably noticed I am looking to them a lot as the driving force behind popularizing a lot of the "non-standard" Markdown.) I might be convinced otherwise, but I would rather have a simpler syntax and very rarely have to escape a slash:
#Index # Weapons\/Tools/Swords

In any case, I don't think mirroring the :: syntax should be a driving factor on this decision. If anything I think we should mirror the single | divider (after all, what if someone wants a | in their topic name?).

What about using a variable for a multiple-word index name? We could do something like

$[index_default](Appendix A: Indexes)
#_default Topic//Subtopic

I guess that should technically work but I would leave that up to the user if they want to add that step. I wouldn't make it the default.

If we have a multiple-word Index label, I think we should allow the use of the colon in that label so perhaps separate with #?  #Appendix A: Index#Topic//Subtopic

I agree. I think # is a better divider here. Limit the number of symbols a user has to memorize or workaround.

We might need to stew a little more on the See/See Also scenario. Should this decision be a block or can we push it to a different PR?

With the guidelines you posted, I think we can logic it out.

When you have lots of indexing entries it's nicer to have the consistent string be at the front for readability

I agree having things line up does help legibility. Though I will point out we can use spacing to line things up too, in which case a post-label I think ends up looking more legible overall. It also helps a "blank" index line up with the rest:
Post-label
# Topic/subtopic
# Topic/subtopic                    # Appendix A // <- This subtopic is being applied to both the default index and Appendix A now
# Another Topic                     # Appendix A
# Another Topic/and a subtopic      # Appendix A
# Another Topic/and second subtopic # Appendix A
# Another Topic/and third subtopic  # Appendix A
# Another Topic                     # Appendix BCD // <- This subtopic is now being applied to both Appendix A and Appendix BCD

vs Pre-label
#  Topic/subtopic
# Appendix A # Topic/subtopic                   // <- This subtopic is being applied to both the default index and Appendix A now
# Appendix A # Another Topic
# Appendix A # Another Topic/and a subtopic
# Appendix A # Another Topic/and second subtopic
# Appendix A # Another Topic/and third subtopic
# Appendix BCD # Another Topic                     // <- This subtopic is now being applied to both Appendix A and Appendix BCD

vs Pre-label aligned
#                Topic/subtopic
# Appendix A   # Topic/subtopic                   // <- This subtopic is being applied to both the default index and Appendix A now
# Appendix A   # Another Topic
# Appendix A   # Another Topic/and a subtopic
# Appendix A   # Another Topic/and second subtopic
# Appendix A   # Another Topic/and third subtopic
# Appendix BCD # Another Topic                     // <- This subtopic is now being applied to both Appendix A and Appendix BCD

In these examples, the post-label looks more legible to me if you are working with multiple labels nearby (even trying to line up the last one as neatly at possible).

Hmm .. whether a cross reference shows as a See or a See also shouldn't be determined by whether the referenced topic has subtopics. They should be determined by the author, as suits their intended purposes. One is a cross reference that says "this concept is more commonly known as X, go look there", and the other says "this concept is interesting in it's own right, but also go look at this other related concept for more context".
Is it possible that an author might use a See also when they mean See (and vice versa)? Yes. That's on them.

Hmm .. whether a cross reference shows as a See or a See also shouldn't be determined by whether the referenced topic has subtopics.

This is correct, and indeed, is not part of the rules I listed above. Subtopics influence only whether "see under" or "see also under" applies.

They should be determined by the author, as suits their intended purposes.

This is not correct. Each has a specific defined use case.

One is a cross reference that says "this concept is more commonly known as X, go look there", and the other says "this concept is interesting in it's own right, but also go look at this other related concept.

This is correct conceptually, but is there are actual rules that defines these more precisely:
See: The current reference does not have a page number of its own, so look at this other reference.
See also: The current reference does have a page number of its own, but look at this related reference also.

Is it possible that an author might use a See also when they mean See (and vice versa)? Yes. That's on them.

But it shouldn't need to be on them if we just generate the correct version for them, which we can do.

They should be determined by the author, as suits their intended purposes.

This is not correct. Each has a specific defined use case according to established rules.

Yes. I'm referring to the conventional use of the types of references as being the "intended purpose", to which the author should conform. I'm not suggesting the author determines the purpose.

This is correct conceptually, but there are actual rules that define these more precisely:

See: The current reference does not have a page number of its own, so look at this other reference.
See also: The current reference does have a page number of its own, but look at this related reference also.

No. These rules define (precisely) how the two uses are effected. The causality is purpose-of-reference → index entries.
A See entry that references an index entry that does not have a page number is an error. (The princess is in another castle. Which castle? Oh, it doesn't exist.) One we could likely fix by minting an index entry for the referred item, using the page the syntax was found on. (Technically fraught, as it would also be possible to write up a whole bunch of See references as a list of synonyms independent of the actual content. Indexes were traditionally constructed separate from the actual content.)

And then there's also the edge case of

Recursion,

See Recursion

(no comment)

A See entry that references an index entry that does not have a page number is an error.

Right. And with our syntax as I defined above, this should not be possible.
The whole point being, our syntax works in such a way that it always generates correct indices, and we can take advantage of that to save users the work of figuring that out themselves.

In these examples, the post-label looks more legible to me if you are working with multiple labels nearby (even trying to line up the last one as neatly at possible). But this may just be a personal style preference. Maybe we can do a poll on the gitter chat.

This is a no-value added requirement.

This will drop an anchor for Main Topic and another anchor for Main Topic/Subtopic at that location (but not Other Topic A or Other Topic B).

correct so far.

If Other Topic A has no anchor dropped anywhere in the document and it is listed as a reference to a top-level topic, the index entry for Other Topic A will be use "see":

This is absolutely not how the code works at present and I see no value in this addition. Code should, at most, warn the user about unfound/incorrect/incomplete references and make zero guesses about layout intent.

This will drop an anchor for Other Topic A and another anchor for Other Topic B, then later also drops anchors for Main Topic and Main Topic/Subtopic.

Gods no.
Create multiple entries if that is needed.

Then users don't need to know the ins and outs of index formatting to select the correct option of | or |||, as the correct wording will be generated automatically based on what other index markers exist.

No. This is not a wizard.

This is a no-value added requirement.

It is not a requirement at all. I'm not sure where you got that impression. Sometimes adding spaces to make things line up just looks nicer, and I think the Post-Label lends itself better to being  legible.

Fortunately, our our syntax doesn't suffer from any of these issues. A cross-reference will always be paired with a real, existing index entry. It is impossible to do otherwise. Thus, we can determine with certainty what the layout intent is.

If I understand the preceding proposal correctly, this is because the instance of the indexing syntax that calls for a See reference will also insert an index entry for the page the See indexing syntax occurs on if there isn't a paged index entry yet.
That's an unsafe assumption.
I could, for example, get to the end of writing my text, navigate to the page the index will be generated onto, and add a bunch of "X, see Y" syntax instances as an attempt to ensure I've covered off the likely synonyms. If the text regarding topic "Y" (which had it's own direct indexing syntax) was later deleted .. then I certainly don't want to have "X, see Y" point to an index entry for "X" with a page number of the index page itself.

Fortunately, our our syntax doesn't suffer from any of these issues, so there is no need to warn/guess anything. Using #Topic|Cross Reference, a cross-reference will always be paired with a real, existing index entry. It is impossible to do otherwise. Thus, we can determine with certainty what the layout intent is.

Okay. I read what you are suggesting backwards.
I don't care for this idea, definitions should go in one direction.

This is exactly what it is doing. It is using multiple separate entries to do this. I suspect you may have misread something here.

Yes, I did.

Are we not creating an auto-generator for indices? We have all the tools at our disposal to make this work automatically. Why not?

Index Markdown entries should be as atomic as possible., IMO, and that means you'll have a markdown for the distinct entry crossreffed and the entry that crossrefs

If I understand the preceding proposal correctly, this is because the instance of the indexing syntax that calls for a See reference will also insert an index entry for the page the See indexing syntax occurs on if there isn't a paged index entry yet.

Ok, This might be where the disconnect is coming from. Let me try to clarify how the syntax works a little more.
When you write an index marker #aaa/bbb|ccc, you supply first: the topic you are anchoring (subtopic if necessary), and second: any synonyms or references to that topic (which will not be anchored at this point). Every marker you create will drop an anchor for the topic at that position on the page, thus allowing a given index entry to point to multiple pages by placing more markers as needed. Any synonyms are not given a page anchor at that point; they would need their own index marker if you want to give them a page anchor.
Example:
// ---------------------------- Page 1

#Weapons|Equipment
This is a paragraph introducing weapons.

#Weapons/swords
This is a paragraph about swords.

// -----------------------------Page 2

#Weapons/daggers|Dual-wielding
This is a paragraph about daggers. Daggers are the only weapon you can dual-wield.

#Weapons/spears
This is a paragraph about spears

#Armor|Equipment|Defense
This is a paragraph about armor.

// ------------------------------Page 3

#Armor/shields
This is a paragraph about shields

// ------------------------------Page 4

#Equipment
This is a big list of all equipment you can find:
- Boxes
- Bags
- Ribbons
- Tags
- Weapons
- Armor

#Encumbrance | Carry capacity | Weapons | Armor
This is a paragraph about how to carry your equipment

#Repairs and Upgrades|Weapons
This is a paragraph about how to repair your weapons

// ------------------------------Page 5

#Horses
#Encumbrance | Saddle Bags
This is a paragraph about how horses can carry things

This would generate:

Armor, 2-4, see also Encumbrance
    shields, 3
Carry Capacity, see Encumbrance
Daggers, see under Weapons
Defense, see Armor
Dual-wielding, see Weapons : Daggers
Equipment, 4
    see also Armor; Weapons
Horses, 5
Saddle bags, see Encumbrance
Shields, see under Armor
Spears, see under Weapons
Swords, see under Weapons
Weapons, 1-2, 4
    see also Encumbrance; Repairs and Upgrades
    daggers, 2
    spears, 2
    swords, 1

I could, for example, get to the end of writing my text, navigate to the page the index will be generated onto, and add a bunch of "X, see Y" syntax instances as an attempt to ensure I've covered off the likely synonyms.

Yeah, you wouldn't do that with this approach, since that would place a bunch of index entries pointing to the index page itself. You would instead add synonyms as relevant to a given page. For example, on page 4 above, I decided "Carry Capacity" would be a term someone might search for to find this paragraph about encumbrance. On page 5, I decided that "Saddle Bags" would be a likely term someone would search. So both "Carry Capacity" and "Saddle Bags" will now point to "see Encumbrance".

The alternative workflow is that I have to go hunt down an actual page containing X to add the "see X" indexing syntax. Given that there might be many pages that are indexed for "X" then the "see X" might end up on any of them. I certainly don't want to putting them on each of them just to be sure (and to guard against later text deletion).

Luckily you wouldn't need to put the see X syntax on each index marker. Placing it on any one is sufficient to have it added as a synonym to the chosen topic. By providing synonyms at the site where they are likely to be searched for, the mental burden of "did I add this synonym" is handled right at the source: just visit the relevant paragraph where that synonym should apply and add it.

I don't care for this idea, definitions should go in one direction.

My syntax is going only in one direction. Topics on left, synonyms (or references) on the right. The cross-reference only points to the Topic and not vice-versa. What am I missing?

Index Markdown entries should be as atomic as possible., IMO, and that means you'll have a markdown for the distinct entry crossreffed and the entry that crossrefs

This is already part of my proposal, unless I am again totally missing something.
#Topic | cross-reference
A distinct entry for the Topic and the cross-ref. If you want a page anchor for cross-reference, it needs its own distinct markdown as well:
#cross-reference

I could, for example, get to the end of writing my text, navigate to the page the index will be generated onto, and add a bunch of "X, see Y" syntax instances as an attempt to ensure I've covered off the likely synonyms.

Yeah, you wouldn't do that with this approach, since that would place a bunch of index entries pointing to the index page itself.

That is however a very possible likely workflow, one which this tool actively interferes with. When I'm looking at the index itself, either to review or even to actually use it ... that is when I would realise that the term I have for the concept I'm looking for does not appear in the index, and that a See cross-reference is called for. And I'd rather just add it in as an synonym cross reference right there, vs navigating to one of many possible pages the preffered term is indexed on and inserting there. Especially if there's a risk that that section of text might get revised/deleted (removing the See cross-reference, despite the concept still being indexed on multiple other pages).

Luckily you wouldn't need to put the see X syntax on each index marker. Placing it on any one is sufficient to have it added as a synonym to the chosen topic.

Only sufficient if there is no risk of that particular section of the text (with attached cross references) not getting removed.

By providing synonyms at the site where they are likely to be searched for, the mental burden of "did I add this synonym" is handled right at the source: just visit the relevant paragraph where that synonym should apply and add it.

Again, there might be multiple instances of the preferred term indexed across multiple pages .. and we only need one instance of the see cross-reference .. so which page has the cross reference index marker? And when I'm editing text that does have that cross-reference index marker, and I know that the preferred term is indexed on multple other pages .. is this instance a duplicate I can safely delete (e.g. if the text is revised and is no longer referencing the preferred term concept)?
The site where I'm likely to search for particular terms is the index. That is what an index is for. Concept → term → page number | redirect to preferred term. Inserting the synonym redirections onto individual pages is fraught in either fragility (one synonym instance might get deleted despite referent concept also appear on alternative pages), or redundant duplication.
The tools should support the workflow. The workflow shouldn't have to bend to suit the tool.

I can see I am still not being understood, so I apologize that I am not able to communicate my idea in a productive way. Rather than continue trying to clarify things, I will step back from this one for a while and focus on some of the other PRs for now until some other proposal comes through.

This is what I'm working with.
#[IndexMarker][LocationMarker]
Where:
IndexMarker is
[IndexNameMarker][Topic]/[Subtopic]
IndexNameMarker is

A string ending with a :
A variable name prefixed with a _ followed by a : - e.g. _index:
Empty, indicating the default index.

Topic is a string.
Subtopic is a string.
LocationMarker is

empty, indicating the index entry should link to this location and use the current page number in the index.
A SeeCrossReference, indicating a "see X" index crossreference
A SeeAlsoCrossReference, indicating a "see also X" index crossreference
A SeeUnderCrossReference, indicating a "see under X" index crossreference
A SeeAlsoUnderCrossReference, indicating a "see alsu under X" index crossreference

SeeCrossReference is
|[IndexMarker]
where IndexMarker is identical to the Indexmarker being referenced.
SeeAlsoCrossReference is
||[IndexMarker]
where IndexMarker is identical to the Indexmarker being referenced.
SeeUnderCrossReference is
|+[IndexMarker]
where IndexMarker is identical to the Indexmarker being referenced.
SeeAlsoUnderCrossReference is
||+[IndexMarker]
where IndexMarker is identical to the Indexmarker being referenced.
If a Cross Reference's IndexAddress references the same index, the index will be omitted from the formatted address. If the IndexAddress of a SeeUnderCrossReference or SeeAlsoUnderCrossReference points to a subtopic that does not exist on the topic or the topic has less than 2 subtopics, it will be redirected to the topic and reported to the user as an inline comment .
Styling/ordering of the Crossreferences is a next stage topic and if it can't be handled purely by CSS then we want to consider having more than one Index generator function that can generate more than one style. IMO, use the Chicago manual first.
Reasoning:
An index entry should be the minimal as possible for default use cases. #Topic should be the simplest entry and a typically subtopic would be #Topic/Subtopic.

Looks good.
I'm assuming white space (tabs and spaces) are permitted either side of the separator symbols (but not within, e.g. |+). No white space following the initial # marker, of course.
Also, the IndexNameMarker needs to note that if present then it needs to start with a non-space character, and that any literal : (colon) character in the IndexNameMarker needs to be escaped (as \:).
Similarly, the [Topic] and [Subtopic] strings need to have any / (solidus) or | (pipe) characters escaped (as \/ and \|, respectively.)

I still think doubling of the pipe character || is a mistake. I get you want to reduce the number of symbols the author needs to remember and understand, but here you are asking them to distinguish meaning between | and ||, vs distinguishing | and @. The same burden, but with even less signal.

I still think doubling of the pipe character || is a mistake. I get you want to reduce the number of symbols the author needs to remember and understand, but here you are asking them to distinguish meaning between | and ||, vs distinguishing between | and @. The same burden, but with even less signal.

We sure we don't want to just deduce which one to use (see or see also) by looking if the cross reference has a page anchor of its own? Then we only need one | for both cases.

Whether a "see X" vs a "see also X" cross-reference is called for is entirely an editorial decision. It can not be deduced.
Elixirs
  ... see Potions
Potions ... page 17
Oils, magical ... page 18
  ... see also Potions

Whether a "see X" vs a "see also X" cross-reference is called for is entirely an editorial decision. It can not be deduced.
Elixirs
  ... see Potions
Oils, magical ... page 18
  ... see also Potions
Potions ... page 17
  ... see also Oils, magical

At best you could try to short-circuit forwarding chains (e.g. Philtres → Elixiers → Potions).

In these examples, they can all be deduced accurately. Elixirs has no page number of its own, so it uses "see". Oils and Potions do have page numbers, so they use "see also". Not an editorial decision (never was). It follows a defined rule. I dont understand the eagerness to avoid the rules.

The base problem is that form should follow function, not function following form.
Remember too though that the mapping of X to Y in a "X .. see Y" referral is not always a perfect mapping of concepts — sometimes Y is a broader term, sometimes Y is a narrower term, and sometimes there are multiple meanings of the term text (e.g. "pole").
In addition to the mapping of these synonyms and homonyms, an author might wish to relate a given term to related content. That related content might not exist or be indexed at the same concept level, and so the relationship to the broader/narrower concept might not fit within the homonym referrals .. and so one might end up with this:
referring-term ..
  .. see homonym-term1
  .. see homonym-term2
  .. see also broader-category
  .. see also narrower-category

Another example:
Let's say you have a term "Coding Languages" in your index. Now, "Coding Languages" could be a broad term that encompasses various specific languages. In this case, you might have:

"see Programming Languages" (indicating that for more detailed information on programming languages, one should refer to the entry for "Programming Languages").

"also see Technology Ethics" (indicating that readers interested in Coding Languages could also be interested in the broader field of Technology Ethics and perhaps look there for additional related information).

The homonym example is interesting; technically two (or more) different entries that happen to appear in the same place in the index, hence the mixing of see and see also which is usually an error. From what I can find, this is generally resolved by differentiating the name with a specifier in parentheses, rather than combining into the same entry:

Pole (nationality) see Polish
Pole (equipment) 12,13
 see also Sticks
 see also under Reach weapons

not

Pole 12,13
 see Polish
 see also Sticks
 see also under Reach weapons

I.e., each entry should use only one type of see, see under, or some combo of multiple see also/see also under. Mixing is a sign of another error case.

Let's say you have a term "Coding Languages" in your index. Now, "Coding Languages" could be a broad term that encompasses various specific languages.

Even in this case, mixing both see and see also would be an error. Either "Coding Languages" has its own pages or not. Using "see" requires that the current entry has no page number of its own. "See also" requires that the current entry has page numbers of its own.

"also see Technology Ethics" (indicating that readers interested in Coding Languages could also be interested in the broader field of Technology Ethics and perhaps look there for additional related information).

It is important to remember that "see also" is not a generic "here is a related topic" that can be applied at the editor's choice. "See also" means, very specifically, that both topics have their own page references. "See" and "see also" have quite literally the same meaning (pointing to another entry for further info), with the only distinction being whether the current index topic has its own pages. As much as an editor might want to ascribe different personal meanings to these two labels, doing so would be an error.

If we want to go out of our way to provide a more complex syntax for the sole purpose of allowing users to create erroneous indices (this logic is baffling to me), I might suggest the following:
#Topic | See
#Topic |+ See also
#Topic | See under/   <- `/` to indicate that we are pointing "under" the whole topic, but not any specific subtopic
#Topic |+ See also under/

Though this makes me consider proposing a second snippet for the index generator, so users have the option:

Snippet 1 - Manual Index: Uses the above syntax to allow for any personal deviations from style guide standards
Snippet 2 - Auto Index: Uses the simpler syntax to guarantee an error-free index

Snippet 1 - Manual Index: Uses the above syntax to allow for any personal deviations from style guide standards

I think there's some unintentionally loaded language here.
What I am trying to provide in my PR is a system that builds indexes based on the user syntax and ascribes to no particular writing style guide rules. I think this makes for a better tool long term and we can solve for some things down the road.
As first-pass compromise, I've put in dropping references to non-existent targets and collating subtopic targets to the parent topic when the parent has two or fewer subtopics. What I'd like to do in later iterations is have a couple of three "preconfigs" and then some prompts for collations and error handling ( Drop errors? Report errors? etc ) coupled with an output log that informs on broken references and rules-based cross-reference redirects ( and whatever else we want along the way )

Snippet 2 - Auto Index: Uses the simpler syntax to guarantee an error-free index

What precisely do you envision here?


Correction for raw affiliation UMR 5239, INSERM U1210, 46 allée d'Italie, 69364 Lyon, France.

Correction needed for raw affiliation UMR 5239, INSERM U1210, 46 allée d'Italie, 69364 Lyon, France.
raw_affiliation_name: UMR 5239, INSERM U1210, 46 allée d'Italie, 69364 Lyon, France.
new_rors: 02vjkv261;029brtt94;01bj4fd12
previous_rors: 02vjkv261;029brtt94
works_examples: W3009228294
contact: 7f11cc528ddf9a7641ece1f61a3d0cf4:3af79acab8ce2a43e1476cdfead2 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


NH-94756: dbo for mysql2

Description
Trace injection to mysql2 instrumentation
Other changes:

simplify some debug log to reduce the size (e.g. span_data -> span_data.to_span_data)
simplify oboe c lib check when compiling by removing unused oboe_config_get_revision
return unmodified uri when test with java-collector

Test (if applicable)
Prod

Getting verrrry close @xuan-cao-swi! Some minor suggestions and one ask--can you check whether these new patch tests are actually run? Not seeing them in the Rakefile task nor the GHA worfklow output.

I have to execute the mysql2 test case separately in test/run_tests.sh because the OtelConfig.initialize test interferes with the mysql2 patch test case. When running rake test, since it’s a single process, the defined module is shared across the entire test suite. There is no method to unprepend a module from a class, so it’s easier to run the mysql2 patch test case separately.


Toggling mini.files

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
Mini.files
Description
Is toggling this plugin possible? the one in the docs doesnt work for me any thoughts on how to do this? Im not fluent in lua yet

This solution works. You can use it to create a mapping like this:
require('mini.files').setup()
local minifiles_toggle = function()
  if not MiniFiles.close() then MiniFiles.open() end
end
vim.keymap.set('n', '<Leader>et', minifiles_toggle)


[SPARK-34087][SQL] Make ExecutionListenerManager.listenerBus removable.

What changes were proposed in this pull request?

make ExecutionListenerManager.listenerBus removable. then we can manually remove ExecutionListenerBus when its belongs session was removed.
How was this patch tested?

new test.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Jenkins, retest this please

Jenkins, retest this please


View PHD Quality Filter Failure Messages

Problem Statement
As a Sender, I would like to know if any of my submitted data could not be delivered to a PHD because the data does not meet the PHD's quality standards so that I can make changes to future submissions and send data that is acceptable to the PHD.
Design
https://www.figma.com/file/6q60xOxokTpYk1rBwIz63E/Sender-Submission-History?node-id=56%3A144
Acceptance Criteria

Given I

Am logged into ReportStream with Sender permissions

When I

Log into ReportStream
Choose to view my Submission History
Select a submission to view the confirmation & warnings

Then I

See a list of the quality filter failure messages and the rows that are affected by the failures
See that the messages are displayed in order by the rows affected (if this makes sense)

TO DO

Dev:

@inkandsound @drew-usds FYI, I don't think this story is yet captured in the wireframes


Add an Execution unique ID to Context

This will give each execution a unique reference that can be used for identifying a running workflow

I thought this would pair well with https://github.com/ManageIQ/floe/pull/223 to help solve https://github.com/ManageIQ/floe/issues/221 since we could have the execution id as part of the logger


[Feature] Create new Evaluator base and GSgnnClassificationEvaluator

Issue #757 , if available:
Description of changes:
This PR creates a new base class, GSgnnBaseEvaluator, which integrates the GSgnnInstanceEvaluator and GSgnnLPEvaluator as one.
Based on this new base class, creates a new GSgnnClassificationEvalutor, which set "accuracy" as the default evaluation metric, and False to multilabel argument.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Per discussion, will close this PR. And create a dev branch and PR there before finally merge dev branch to the main.


Fix core functional tests

Expected Behaviour
Actual Behaviour
Reproduce Scenario (including but not limited to)
Steps to Reproduce
Platform and Version
Sample Code that illustrates the problem
Logs taken while reproducing problem

Closing this. All functional tests are passing.


Cross-Site Scripting

Colleagues, I would like to report about cross-site scripting in clipboard.js.
It happens if copied payload contains a javascript. Payload will be executed.
PoC
Part of code with payload:
<div class="color-card__eyedropper js-color-copy"  data-color-name="Berg Blue" data-clipboard-text="#02a3d5<script>alert(1)</script>">
      <svg class="icon icon-eyedropper"><use xlink:href="#icon-eyedropper"></use></svg>
   </div>

as a result we can see alert with message "1" after click on eyedropper icon.
Sure, it is not a big risk in this particular case, because "data-clipboard-text" sets by authorized developers only, but this attribute will be in user controlled field, XSS will be present.
Clipboard.js could prevent this kind of XSS case by encoding copied data in a right way, prevent executions.
Thanks,
Vitalii.

Closing due to inactivity. Feel free to send a PR with suggestions on how to fix this.


[CLOSED] Consider using handles instead of pointers for resources

 Issue by Cloudef
Monday Dec 08, 2014 at 16:11 GMT
Originally opened as https://github.com/Cloudef/wlc/issues/2

This makes sense due to uncontrolled environment where dangling pointers are real problem. Handles would be simple indexes. This gives additional bonus that the underlying memory management could be optimized for iterations.

 Comment by Cloudef
Saturday Mar 07, 2015 at 11:15 GMT

Done @ refactor branch.

 Comment by Cloudef
Thursday Feb 26, 2015 at 13:06 GMT

Working on this now. Should get rid of most if not all hacks and not so nice things in wlc (excluding some internal apis, like platform abstraction that could be nicer).
Changes public API dramatically as well, however should be easier to wrap to different languages as result.


Fixing issue #84, renaming conflict_period to sim_period. Amending .g…

…itignore to include .DS_Store files.

Hi Derek, I have the changes to FabFlee as well, I'm just waiting for you to add me as a collaborator on that repo. Yes, I agree it makes sense to wait until after ITFLOWS and then also merge any changes simultaneously.


Add JReleaser as Food

Adds JReleaser to the rig

https://jreleaser.org

Tested locally
$ gofish lint Food/jreleaser.lua
🐠  No errors discovered in 'jreleaser'

@bacongobbler thank you for merging! How are updates to Food handled? I see several PRs from gofish-bot. Does the bot monitor Food releases?

Yes, assuming the package has been added to the bot. It’s maintained by a community member and you’ll need to submit a PR here: https://github.com/gofish-bot/gofish-bot


Where is the #include "stdafx.h" file in Visual Studio 2019?

[Where is the #include "stdafx.h" file in Visual Studio 2019? According to https://docs.microsoft.com/en-us/cpp/build/creating-precompiled-header-files?view=vs-2019
"When you create a new project in Visual Studio, a precompiled header file named pch.h is added to the project. (In Visual Studio 2017 and earlier, the file was called stdafx.h.) The purpose of the file is to speed up the build process. Any stable header files, for example Standard Library headers such as , should be included here. The precompiled header is compiled only when it, or any files it includes, are modified. If you only make changes in your project source code, the build will skip compilation for the precompiled header."
Is there a way to see where it is?
]

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

ID: cadd6022-4e0d-d292-de08-4b73b681f6e8
Version Independent ID: ce99a474-56fd-f48f-137e-ba6570fa3f4e
Content: Precompiled Header Files
Content Source: docs/build/creating-precompiled-header-files.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

@yeokaiwei
The location of the pch.h file or stdafx.h file depends on the project template. All the templates I checked put the file in a virtual folder named Header Files in the Solution Explorer window. On disk, it's in the project folder with your other source files. The generated PCH file is in the project build output folder, usually Debug or Release.
This question doesn't seem like something that needs to be noted in the document, so I'm closing this issue.


Only takes one image snapshot, doesn't take any further ones<EMAIL_ADDRESS>cypress-plugin-snapshots#666d7ee)

Repro case here: https://github.com/jjt/cypress-plugin-snapshots-test
It seems like it only ever takes an initial snapshot and doesn't recapture it. For example, here's after the second run after some changes, where you can see that the contents of the snapshot is a red square with the words HELLO THERE, and the contents of the DOM on the second run is a green square with the text oh hi

contents of the cypress/ dir after the second test run:
~/p/c/cypress ❯❯❯ tree
.
├── fixtures
│   └── example.json
├── integration
│   ├── __image_snapshots__
│   │   └── Test\ \ does\ more\ than\ one\ snapshot\ #0.png
│   └── test-regression.spec.js
├── plugins
│   └── index.js
├── screenshots
│   └── test-regression.spec.js
└── support
    ├── commands.js
    └── index.js

@jjt Can you retry with latest version and let me know if that fixes it?

tried with 1.2.8 and @9eafd96 and still the same behaviour
wiped yarn.lock, node_modules, reinstalled
nuked the cypress/screenshots and cypress/integration/__image_snapshots__ dirs between trials too (stopped cypress, deleted those dirs, ran the test, changed element, ran test again) - still showing the old screenshot but with new DOM as per my images above

Thanks for retesting. Will look into it.


Merging LoRA weights with base model

Hi,
Thank you for sharing the Mantis source code.
I trained your LLaMA3 model with SigLIP on my dataset. The model saves a checkpoint every 500 steps. I would like to merge the LoRA weights from these checkpoints (for example checkpoint in step 1000) with your base pretrained SigLIP-LLaMA3 model. Could you please share the source code for merging the LoRA weights?
Thank you!
Hung Nguyen

We did not explicitly merge the LoRA weights with some scripts. Instead, we directly set the model_name_or_path to be the path of the lora adapter path. Since the adapater_config.json has a parameter called base_model_name_or_path, which specifies which the path or name of which model it should be merged before use. And transformers library will automatically do this merging during the loading.

See hugging face transformers doc for more details:
https://huggingface.co/docs/transformers/en/peft#load-a-peft-adapter


relabeling ignores name when replacing address

Bug Report
What did you do?
I'm using my server ip address configuration for node_exporter.
To be able to support both node_exporter 0.14 and node_exporter 0.17 I'm renaming the metrics to 0.14.
  relabel_configs:
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: instance
      replacement: '${1}'
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: __address__
      replacement: '${1}:9100'
    - source_labels: [__name__]
      regex:  'node_disk_read_bytes_total'
      target_label: __name__
      replacement: 'node_disk_bytes_read'

What did you expect to see?
both address and names will be replaced.
What did you see instead? Under which circumstances?
Unfortunately, the names were not replaced, but the address was correct.
To verify it, I've changed the name to be replaced in the metric_relabel_configs part.
This did work.
  relabel_configs:
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: instance
      replacement: '${1}'
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: __address__
      replacement: '${1}:9100'
  metric_relabel_configs:
    - source_labels: [__name__]
      regex:  'node_disk_read_bytes_total'
      target_label: __name__
      replacement: 'node_disk_bytes_read'

Environment
Prometheus with dokcer container.

System information:
insert output of uname -srm here

Prometheus version:
checked with 2.5 and 2.7.1

Prometheus configuration file:

global:
  scrape_interval: 5s # By default, scrape targets every 5 second.
  scrape_timeout: 4s # Timeout before trying to scape a target again

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'scylla-monitor'
rule_files:
  - /etc/prometheus/prometheus.rules.yml
    #
# Alerting specifies settings related to the Alertmanager.
alerting:
        #  alert_relabel_configs:
        #    [ - <relabel_config> ... ]
  alertmanagers:
  - static_configs:
    - targets:
        - AM_ADDRESS

scrape_configs:
- job_name: scylla
  honor_labels: false
  file_sd_configs:
    - files:
      - /etc/scylla.d/prometheus/scylla_servers.yml
  relabel_configs:
    - source_labels: [__address__]
      regex:  '(.*):.+'
      target_label: instance
      replacement: '${1}'

- job_name: node_exporter
  honor_labels: false
  file_sd_configs:
    - files:
      - /etc/scylla.d/prometheus/node_exporter_servers.yml
  relabel_configs:
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: instance
      replacement: '${1}'
    - source_labels: [__address__]
      regex:  '(.*):\d+'
      target_label: __address__
      replacement: '${1}:9100'
    - source_labels: [__name__]
      regex:  'node_disk_read_bytes_total'
      target_label: __name__
      replacement: 'node_disk_bytes_read'
    - source_labels: [__name__]
      regex:  'node_disk_written_bytes_total'
      target_label: __name__
      replacement: 'node_disk_bytes_written'
    - source_labels: [__name__]
      regex:  'node_disk_reads_completed_total'
      target_label: __name__
      replacement: 'node_disk_reads_completed'
    - source_labels: [__name__]
      regex:  'node_disk_writes_completed_total'
      target_label: __name__
      replacement: 'node_disk_writes_completed'
    - source_labels: [__name__]
      regex:  'node_filesystem_avail_bytes'
      target_label: __name__
      replacement: 'node_filesystem_avail'
    - source_labels: [__name__]
      regex:  'node_network_receive_bytes_total'
      target_label: __name__
      replacement: 'node_network_receive_bytes'
    - source_labels: [__name__]
      regex:  'node_network_receive_packets_total'
      target_label: __name__
      replacement: 'node_network_receive_packets'
    - source_labels: [__name__]
      regex:  'node_network_transmit_bytes_total'
      target_label: __name__
      replacement: 'node_network_transmit_bytes'
    - source_labels: [__name__]
      regex:  'node_network_transmit_packets_total'
      target_label: __name__
      replacement: 'node_network_transmit_packets'
    - source_labels: [__name__]
      regex:  'node_filesystem_size_bytes'
      target_label: __name__
      replacement: 'node_filesystem_size'

- job_name: scylla_manager
  honor_labels: false
  file_sd_configs:
    - files:
      - /etc/scylla.d/prometheus/scylla_manager_servers.yml
  metric_relabel_configs:
    - source_labels: [host]
      target_label: instance

- job_name: 'prometheus'
  # Override the global default and scrape targets from this job every 5 seconds.
  scrape_interval: 5s
  static_configs:
    - targets:
      - localhost:9090

To verify it, I've changed the name to be replaced in the metric_relabel_configs part.

This is expected, relabel_configs applies to the label set of a target before it gets scraped so __name__ isn't known yet. You need to use metric_relabel_configs indeed.
I'm closing it for now. If you have further questions, please use our user mailing list, which you can also search.


Which loss function is used?

Which loss function is used? is it a CTC loss or seq2seq models use some other sort of loss function?

Log loss.


strandRule unnecessary/unused in process rseqc

Hello, looks like strandRule is computed unnecessarily or is at least unused in process rseqc
Best,
Andreas

Hah, correct. It looks like we used to use it for the RPKM_saturation.py command: https://github.com/nf-core/rnaseq/blob/5d65867a568946fcc34d5db8872126066423aeb8/main.nf#L644
We then later removed this call: https://github.com/nf-core/rnaseq/commit/f6f666905d28399aa0386e983414ea04235ce5ac#diff-28b7bea57b04f15beeb4c1de0ee78382L725
I'm not totally sure whether this removal was intentional or not. The rest of the commit is where we first moved geneBody_coverage.py out into its own process, so we were definitely thinking about performance issues at the time. My guess is that I said that we should remove that command because it was super slow and performance-hogging and we already had very similar QC metrics from dupRadar.
Anyway, yes I think you're right that we can remove these lines without any effect:
https://github.com/nf-core/rnaseq/blob/1cd5ab733a35727b01370de2ae8462d65f57fbb9/main.nf#L732-L737
Note that it won't change the way that the pipeline runs or is configured though, as the strandedness configuration is still used in other processes.
Phil

Oops, accidentally auto-closed the issue from my commit. Should wait for the PR to be merged really.

Done :-)


release: v0.11.2

Why
Want to use: https://github.com/NebraLtd/hm-pyhelper/pull/54

@posterzh could you please review this, merge, and create a new release for hm-pyhelper so I can use it tomorrow? Thanks.


Usages of classes/methods/etc. from the SDK source code are not found

Windows 10, SDK 1.22.0-dev.7.0 x64. Usages of bool class are not reported by the analysis server. Minimal file to reproduce:
bool b;

@scheglov Is this expected?

Yes, this is is a known issue.

This was a long multi-step implementation process...
The problem is fixed in fcd5f16d100937264f8949423fb0c6d4cbe0286d.

Test that it actually works and does not regress.
https://codereview.chromium.org/2651103004

https://github.com/dart-lang/sdk/commit/ebe04d131bea289b976b200c0455ebc40c71db72


Skipping slow tests

When I run ./scripts/run-tests.sh, all tests show PASSED except two:
tests/test_metrics.py::test_nubia FAILED
tests/test_metrics.py::test_gold_paragraphs SKIPPED (Parses all PDFs - very slow)

test_nubia fails with an obscure pydantic validation error, I had to add a print to understand the problem. How about adding @mark.skipif(not settings.OUGHT_INFERENCE_API_KEY, reason='...')?
Both tests have @mark.slow but this doesn't do anything by default. I assume this is why test_gold_paragraphs has a hard @mark.skip. This doesn't seem great - what do you do when you actually want to run the test? Should a way to skip slow tests by default (with or without using @mark.slow) be investigated?
-m 'not slow' correctly deselects the slow tests, but only if I directly run docker compose and pytest. ./scripts/run-tests.sh -m 'not slow' doesn't work, and the shell (tested both bash and zsh) shows it running with -m 'not\' slow. Looks like this isn't working:

https://github.com/oughtinc/ice/blob/7eab90d22b3bd8ca68f944213e6f9425ff188b3a/scripts/run-tests.sh#L8-L9

This definitely seems worth fixing as part of an overhaul of all the scripts: https://github.com/oughtinc/ice/issues/7#issuecomment-1256665522


Improvements to ping devices

Allow the user to specify the device parameter to use for the ip to ping. Defaults to summary.ip so no impacting changes to users.
Add some error checking around ping. Previously "Device is offline" would be displayed if no ip was passed in, or '(null)' was passed in. I added specific checking for this and display an alert message to the user.

I think a better solution would be to use the IP/host name extracted from connection request URL parameter. That way it would always work without the need for manual configuration. What do you think?

The backend takes care of the pinging. This makes the front end use the
proper URL, port and scheme for making a connection to the backend.
-dan
On Sun, Mar 27, 2016 at 3:26 PM, Zaid Abdulla<EMAIL_ADDRESS>wrote:

I think a better solution would be to use the IP/host name extracted from
connection request URL parameter. That way it would always work without the
need for manual configuration. What do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/zaidka/genieacs-gui/pull/38#issuecomment-202168520

Looking at the diff it looks like you've added a new config file (show_parameters.yml). What I meant is instead of using the IP from the parameter determined in that file, why not hard code it to use the IP from ConnectionRequestURL parameter which I imagine should work in all cases anyway.

The reason for that is our CPEs have two IP addresses, one on a private
management network, and the other on the public network (after the CPE has
authenticated via PPPoE). Because the PPPoE connection may not always be
up, for use the reliable way is to ping the summary.managementIp alias.
In our environment, show_parameters.yml is this:
pingIp: summary.managementIp
For my checkin, I set it to pingIp to summary.ip so existing
implementations would continue working with no changes.
-dan
On Mon, Mar 28, 2016 at 10:16 AM, Zaid Abdulla<EMAIL_ADDRESS>wrote:

Looking at the diff it looks like you've added a new config file
(show_parameters.yml). What I meant is instead of using the IP from the
parameter determined in that file, why not hard code it to use the IP from
ConnectionRequestURL parameter which I imagine should work in all cases
anyway.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/zaidka/genieacs-gui/pull/38#issuecomment-202514759

In your particular case the parameter summary.managementIp should match the IP portion in ConnectionRequestURL since connection requests ideally go through the management connection. Can you confirm?

Hmm, you're right :). I'll rework the patch in the next few days.
-dan
On Mon, Mar 28, 2016 at 11:20 AM, Zaid Abdulla<EMAIL_ADDRESS>wrote:

In your particular case the parameter summary.managementIp should match
the IP portion in ConnectionRequestURL since connection requests ideally go
through the management connection. Can you confirm?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/zaidka/genieacs-gui/pull/38#issuecomment-202540407

Great. Thank you :)

Fixed! This requires a corresponding commit to config/parameters-sample.json (adding  "InternetGatewayDevice.ManagementServer.ConnectionRequestURL": {"alias": "summary.connectionUrl"}, ).
I have to leave for the day and won't be able to sort out my repo issues until tomorrow.

Why not use the following parameters (whichever exists):
InternetGatewayDevice.ManagementServer.ConnectionRequestURL
Device.ManagementServer.ConnectionRequestURL

I don't see a benefit in using an alias that's configured in the backend when it can never be anything other than one of these two parameters.
I see you've added a new dependency (ipaddress). This is not necessary; I believe you can extract the host name part from a URL using standard Ruby functions.

Hows this? :)

Sexy! I squashed all the commits into one and replaced the regex with the standard URL parsing function. Thanks.

I didn't even know about that! When I googled "ruby parse IP from string" the options that came up where the ipaddress lib, and regex. The route you choose is much better :).
To quote Jamie Zawinski

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Hehe. Great quote. Yeah, Ruby standard libraries are pretty comprehensive.


Multi-bit access

Hi! Do you have a plan, in the near future, to implement the access of multiple bits simultaneously? If not, do you want me to take a crack at it?  I'm going to need this within the next few weeks.

Turns out the initial need was mainly to be able to add individual input bit monitoring to an app that was already using poll() for a number of other non-GPIO file handles. This was solved pretty easily with #4
I hadn't seen it documented, but apparently the line event handle can also be used to read the current value of the bit. So it would be great to add a get_value(&self) to the LineEventHandle implementation.
And, finally, the actual multi-bit access might be implemented with a Lines (plural) struct. It would mimic the Line struct, but take a slice/array/Vec of offsets and values for each call where the Line struct only takes or returns a single value.

Down the road adding support for handles/events over multiple lines will definitely be desired.  It doesn't fit a lot of use cases as all the lines need to be configured the same way (this is a limitation of the kernel) but does have some nice performance benefits in some specific cases so it is something we'll want to do eventually.
Probably once #8 lands the next focus will be getting a release out and seeing about moving things to the rust-embedded org and getting feedback on ergonomics so we can get any breaking changes in early.

That sounds great. I've made some progress on the multi-line stuff, and might have something as early as next week. But I agree that we shouldn't hold up what we have already for a release. The multi-line stuff can come in later as v0.2 or beyond.

Done in PR #10.


overview - sort the themes depending in the stars

I think it would be helpful to impmement a sorting algorithm to see which theme has the most stars. (Using the GitHub API)
This could be expanded to mutiple search oprions.

This has been discussed before, see https://github.com/gohugoio/hugoThemesSite/issues/47

@bep Ok sorry

No problem, we have so many repositories it is hard to keep track :-)


Templates not included in pip package

After a pip install, there are no templates in `.../loghub/templates':
$ ls site-packages/loghub/templates/
__init__.py  __pycache__/

This leads to a FileNotFoundError in render_changelog

Oops :-p, used to the conda package


Wireguard IPv6 connectivity issue in main branch

Describe the bug

I was testing https://github.com/antrea-io/antrea/pull/5880 on dual-stack cluster, and found IPv6 cross-node was not working in Wireguard mode. Checked the flows and found a weird flow matching all traffic from Pod:
# ovs-ofctl dump-flows br-int table=Classifier
 cookie=0x8010000000000, duration=392.400s, table=Classifier, n_packets=0, n_bytes=0, priority=210,ip,in_port="antrea-gw0",nw_src=<IP_ADDRESS> actions=load:0x2->NXM_NX_REG0[0..3],resubmit(,SpoofGuard)
 cookie=0x8010000000000, duration=392.400s, table=Classifier, n_packets=0, n_bytes=0, priority=210,ipv6,in_port="antrea-gw0",ipv6_src=fd00:10:244:2::1 actions=load:0x2->NXM_NX_REG0[0..3],resubmit(,SpoofGuard)
 cookie=0x8000000000000, duration=392.462s, table=Classifier, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0x8010000000000, duration=392.399s, table=Classifier, n_packets=64, n_bytes=32416, priority=200 actions=load:0x1->NXM_NX_REG0[0..3],load:0x1->NXM_NX_REG0[9],resubmit(,UnSNAT)
 cookie=0x8010000000000, duration=392.399s, table=Classifier, n_packets=0, n_bytes=0, priority=200,in_port="antrea-gw0" actions=load:0x2->NXM_NX_REG0[0..3],load:0x1->NXM_NX_REG4[27],resubmit(,SpoofGuard)
 cookie=0x8010000000000, duration=383.042s, table=Classifier, n_packets=0, n_bytes=0, priority=190,in_port="connecti-cac3cb" actions=load:0x3->NXM_NX_REG0[0..3],resubmit(,SpoofGuard)

I guess it's caused by https://github.com/antrea-io/antrea/pull/5885, after which we no longer create tunnel port but we still call tunnelClassifierFlow.
To Reproduce

Try IPv6 connectvity in dual-stack cluster with Wireguard enabled.
Versions:

Antrea version (Docker image tag). main

Additional context

cc @antoninbas

I was able to reproduce. It's surprising that this only affects IPv6 traffic, and not IPv4 traffic. The main reason seems to be that IPv6 neighbor discovery in particular is failing because the ICMPv6 packets are going to the UnSNAT table, instead of going to the IPv6 table, where they would normally be handled by the NORMAL action.


Fixed install paths on *NIX

Hello, the previous build was hard to configure for packagers. This one uses a CMake module (GNUInstallDirs) to standardize it so that it works like most programs out there and the right install paths are automatically chosen. I already tested this both on my local machine and on the Open Build System (openSUSE).
The Mac part might need some fixing, I had to use the INSTALL_DIR variable for consistency but the logic should be the same as before.

Thank you for this project! :smile_cat: these plugins are already in the multimedia:proaudio repo for openSUSE, by the way, we can make you a maintainer for the package if you have an OBS account. Due to licensing issues related to the VST2 SDK, we could never really get Airwindows VSTs in our repo (@joboschetti wrote a downloader for them to get around that) and this project I think will benefit many users.

You're welcome :)
My OBS username is "hannesbraun" too in case you want to add me as a maintainer.

Done! The package name on multimedia:proaudio is reversed (lv2-airwindows) because we are trying to follow the convention plugin_type-package_name.


Multiple keywords on 'convert.keyword.rgb()'

I have tried to use 'Dark Red' as keyword but it doesn't recognize it. Do you have a list with accepted words?

Hi! You want darkred.
We use the standardized CSS color names for keywords - a full list can be seen here: https://drafts.csswg.org/css-color/#named-colors

Thank you very much @Qix- !!