Add collapse option

Add ability to callapse fields. Docs:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-collapse.html

Hey @marcintabaka, I added collapse method, but in my implementation you can only specify a field, that will be used for collapsing. No inner hits support, because I don't process them and it makes no sense to give users ability to specify this parameter.

Hi @babenkoivan, your implementation is also sufficient for my needs and looks better because of its simplicity 👍 Thanks!


Windows SQL Server driver link in readme broken

This link in the README file goes to a non-existent page:
https://www.microsoft.com/en-us/sql-server/developer-get-started/java/windows

Hi @paix120,
You're correct, all the links in that section are dead. We'll look into correcting this.

Thanks!
On Fri, Sep 1, 2023, 12:12 PM Jeffery Wasty @.***>
wrote:

Hi @paix120 https://github.com/paix120,
You're correct, all the links in that section are dead. We'll look into
correcting this.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/mssql-jdbc/issues/2210#issuecomment-1702994053,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQFYK4JP6GQGEGATANERU3XYICNTANCNFSM6AAAAAA4HR6FCM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Just checking-in. None of the links have been fixed. Anyone have a reasonable estimate on a new URL/fixed link?

It looks like they have the replacement up, available here: https://www.microsoft.com/en-us/sql-server/developer-tools. We'll update the links in the readme as soon as we are able to.


[C++ Comm] Enable examples on Linux/macOS.

LGTM. Travis failure on MacOS unrelated to this change. Committed to master.


Add ability to print allocations from a specific allocator and visualize

Add AllocationMap::print that takes a predicate and output stream, and test it
Add umpire::print_allocator_records to output records from a specific allocator (using method above)
Add python script to plot these log files of allocation records
Add cookbook example recipe_plot_allocations.cpp showing an advanced usage with a pool

@jdahm - this needs some changes to get it working after the merge with develop. Switch from std::shared_ptr needs to be made.

This should be ready now.


Recent config changes - config moving to DB

I noticed recent commits to move various options from settings.py to the database and present them in the UI. I believe this is short-sighted and needs a re-think. It also causes rather large problems for me, and I suspect others will be in the same position too:
I use PowerDNS-Admin in a corporate setting and I have all manner of rules and legislation to abide by. I draw a clear distinction between the system admin (that's me) and the domain admins (2 other persons). I manage the hosts, the code, the name servers, PDNS, software upgrades while those other 2 answer the phones, click GUI buttons, and have full rights to create any domain and add any record the end user asks for. They can add new users to the app and give those users full domain rights or whatever lesser rights they see fit (basically, they own the zones and the content). They do not have permission to see my security settings on the name servers or get a shell to cat config.py. These new commits blur that line.
With these new changes I must expose my PDNS API secret in the GUI as well as the company AD secrets. The compliance auditor is really not going to like that and is going to have nasty things to tell me...  It's not feasible for the domain admins to not be app admins, I have 9500+ zones and am not going to give them admin rights per-zone individually.
Besides, PDNS and LDAP settings almost never change so config.py is a good place for them to remain. The new "Records" page is a neat idea, I think that one should stay, it is well within the responsibility of a domains admin.
Can we postpone this new dev work and discuss the community needs more please?

Thanks @splog123 for raising your concern about recent changes.
From system administrator view, i agree with you that the those configs should be managed in the file because of benefits such as:

easy to manage the changes (via config management system such as puppet, ansible, etc + git)
better on security since we separate the sysadmin and app admin job.

From the app administrator view, small use cases where both jobs are managed by the same person:

it is convenience to have ability to change the configuration via UI. we don't need to access the server to update the config file and reload the PDA.
config validation (as time goes, the number of PDA config keeps increasing, it will be hard to manage them).

Although I am a System Administrator, i made this change because i think it is helpful for most of people who using PDA. And since I don't have any discussion place for PDA, it is hard to hear from community. Maybe I missed something?
I am looking forward to hearing about other people for this issue.

Also, what if we have some adjustment in the PDA Role? Only super admin has permission to change the system related settings?, normal admin / editor can change / add the Zones.

I could agree with a superadmin role. What could also work is a per-user
setting to give them full read-write access to all zones without them being
a full system/app admin. It's the same thing really - three "roles", how
they are named is not too important.
I still lose the ability to do everything with ansible, and will have to
take extra special care with MySQL backups, but I can live with that.
On Tue, Aug 28, 2018 at 10:57 AM Khanh Ngo<EMAIL_ADDRESS>wrote:

Also, what if we have some adjustment in the PDA Role? Only super admin
has permission to change the system related settings?, normal admin /
editor can change / add the Zones.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngoduykhanh/PowerDNS-Admin/issues/342#issuecomment-416505534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHZ11URBNJchSuKcq1hashWuOKV6Bekmks5uVQXxgaJpZM4WPJKM
.

--
Alan McKinnon
alan dot mckinnon at gmail dot com

especially pdns_api_key in db is a big no-go here.
please give an option to read it from config.py only.

I have created PR #345 to have Operator role. Can you guys try and give feedback?


Compare INDRA and LLM Interactions and Report Percent Matching

For each sentence, compare that the interaction is the same. If subject, object, and interaction type are the same then they match and put 1 (TRUE) otherwise 0 (FALSE). Report sum(match), total interactions, and sum(match)/total (i.e., percent matching).

@cannin @dexterpratt
I got this for comparing the results gotten from the acc paper with pmid: 13086

@cannin
The statements gotten from indra was only two for this particular paper. It is shown here after i tried to format it to look like my results: https://github.com/ndexbio/gsoc_llm/blob/main/results/pmc333362/conv_indra_results.json
This is why only 2 interactions are shown in the screenshot

This is the code I used to find similarities: https://github.com/ndexbio/gsoc_llm/blob/main/python_scripts/sentence_level_comparison.py

@Favourj-bit same as on Slack. A suggestion to help you with the comparison code that builds on you you already have above. Start simple. 1 sentence at a time.
Steps

Get 100 sentences from "text" fields of INDRA results
Send 1 sentence to INDRA REACH: https://gist.github.com/cannin/949db7c5a0bbce873704fe90cc58de5a#file-use_indra_run_export_reach-py
Send the same sentence to LLM
Compare. Let's start with Jaccard (see below). Fill in 'jaccard_similarity' for each interaction.
Report the average of the jaccard_similarity over the 100 sentences.

Example Table for Comparison:
sentence|indra_subject|indra_type|indra_object|llm_...|jaccard_similarity

Example Code
def jaccard_similarity(text1, text2):
    # Tokenize the texts into sets of words
    set1 = set(text1.split())
    set2 = set(text2.split())

    # Calculate the intersection and union of the two sets
    intersection = set1.intersection(set2)
    union = set1.union(set2)

    # Compute the Jaccard similarity
    if not union:
        return 0.0
    return len(intersection) / len(union)

# Example usage
text1 = "boy has cat"
text2 = "girl has cat"

similarity = jaccard_similarity(text1, text2)
print(f"Jaccard Similarity between '{text1}' and '{text2}': {similarity:.2f}")

# Example usage; use the table above to generate text1/2
text1 = "NS1 binds HPA-1"
text2 = "NS1 activates HPA-1"

jaccard_similarity(text1, text2)

To get more columns: recall, precision, f1:
# Inspired by: https://github.com/yuhaozhang/tacred-relation/blob/master/utils/scorer.py
# and https://github.com/hitz-zentroa/GoLLIE/blob/main/notebooks/Relation%20Extraction.ipynb
def score(observations, predictions, pad_smaller=True, verbose=False):
    correct_by_relation = 0
    predicted_by_relation = 0
    observed_by_relation = 0

    # Pad the shorter vector
    if pad_smaller:
        # Determine the maximum length
        max_length = max(len(predictions), len(observations))

        if len(predictions) < max_length:
            predictions.extend([''] * (max_length - len(predictions)))
        if len(observations) < max_length:
            observations.extend([''] * (max_length - len(observations)))

    if not pad_smaller and len(predictions) != len(observations):
        print("ERROR: predictions and observations must be the same length.")
        return

    # Loop over the observations to compute a score
    for row in range(len(observations)):
        observed = observations[row]
        predicted = predictions[row]

        if observed == '' and predicted == '':
            pass
        elif observed == '' and predicted != '':
            predicted_by_relation += 1
        elif observed != '' and predicted == '':
            observed_by_relation += 1
        elif observed != '' and predicted != '':
            predicted_by_relation += 1
            observed_by_relation += 1
            if observed == predicted:
                correct_by_relation += 1

    # Print the aggregate score (micro-averaged since across all relations)
    prec_micro = 1.0
    if predicted_by_relation > 0:
        prec_micro = correct_by_relation / predicted_by_relation
    recall_micro = 0.0
    if observed_by_relation > 0:
        recall_micro = correct_by_relation / observed_by_relation
    f1_micro = 0.0
    if prec_micro + recall_micro > 0.0:
        f1_micro = 2.0 * prec_micro * recall_micro / (prec_micro + recall_micro)
    if verbose:
        print("Final Score:")
        print("Precision (micro): {:.2%}".format(prec_micro))
        print("   Recall (micro): {:.2%}".format(recall_micro))
        print("       F1 (micro): {:.2%}".format(f1_micro))

    return round(prec_micro, 3), round(recall_micro, 3), round(f1_micro, 3)

predictions = ['A_binds_B', 'A_stimulates_D', 'A_stimulates_C', 'A_activates_C', 'A_binds_E', 'A_binds_F']
observations = ['A_binds_B', 'A_stimulates_D', 'C_binds_D']
score(observations, predictions, pad_smaller=True, verbose=True)


Threading support

There's no attempt or tests for thread safety yet.
PDF now has early support for multi-threaded page construction.
This library could possibly support thread-safe fragments that can be composed concurrently for final sequential assembly, along with the pages.

In place with PDF::Tags release 0.1.2. A bit more testing/use in the field needed.

Sort of working, however t/threads.t currently produces an unstable /ParentTree ordering and /StructParents links back to the parent tree.
Ideally, this should be stable, if this can be achieved without significant concurrency bottleneck.
We'd need to somehow defer final construction of these for final sequential allocation.


Proof of concept toucan integration

Hi! I have been using raven to help me debug a new timeline render I am working on:
https://github.com/darbyjohnston/toucan
This is just a proof of concept, but I thought I would share the PR to see if there was interest in taking it further.
Note that toucan is a software renderer, so it's a bit slow compared to a playback application. However it still might be useful for previewing/inspecting frames in raven.
Here is a screenshot showing raven rendering frames from a timeline with toucan:

Thanks! Having the Raven timeline + image preview has been very helpful for troubleshooting.
One downside is that imgui doesn't support texture loading, so there would need to be three different implementations for OpenGL, Metal, and Direct3D.

@darbyjohnston Just noticed your note about texture loading ~ I've got ImGui texture loading in the bag if you ever want to have a go on that part. It can be done with very little code.

@meshula Oh nice, how does that work? I closed this since I thought cross-platform texture loading might be too much effort.

An ImTextureId is just a platform handle void casted under the hood :) It's complicated under Vulkan, but all the other targets are trivial.
Minimally, you can just cast a texture as follows

   ImGui::Image(texture, viewSize, uv0, uv1);

Here's an example of displaying a texture inside ImGui on Metal, with a color correction shader in an imgui callback. I haven't included the shader, we can follow up on Slack if you like.

struct InspectorShaderConstants {
    simd::float2 textureSize;
    bool forceNearestSampling;
    float inK0;
    float inPhi;
    float inLinearBias;
    float inputGamma;
    float outK0;
    float outPhi;
    float outLinearBias;
    float outputGamma;
    float exposure; // precomputed as pow(2.0, exposure)
    float lift;
    simd::float4 grid;
    simd::float2 gridWidth;
    simd::float4x4 colorTransform;
    simd::float3 backgroundColor;
    float premultiplyAlpha;
    float disableFinalAlpha;
};

void BackEnd_SetShader(const ImDrawList*, const ImDrawCmd*, const Inspector* inspector) {
    static id<MTLRenderPipelineState> rps = nil;
    NSError* error = nil;
    while (!rps) {
        LabMetalResources* mr = GetCurrentLabMetalResources();
        id<MTLDevice> device = mr.device;
        if (!device)
            break;

        id<MTLLibrary> shaderLib = [device newDefaultLibrary];
        if(!shaderLib)
        {
            NSLog(@" ERROR: Couldnt create a default shader library");
            // assert here because if the shader libary isn't loading, nothing good will happen
            break;
        }

        id<MTLFunction> vertexFunction = [shaderLib newFunctionWithName:@"textureMode_vertex_main"];
        if (!vertexFunction)
        {
            NSLog(@">> ERROR: Couldn't load vertex function from default library");
            break;
        }

        id<MTLFunction> fragmentFunction = [shaderLib newFunctionWithName:@"textureMode_fragment_main"];
        if (!fragmentFunction)
        {
            NSLog(@" ERROR: Couldn't load fragment function from default library");
            break;
        }

        // this vertex descriptor MUST match that in imgui_impl_metal
        // see renderPipelineStateForFramebufferDescriptor as a sanity check
        MTLVertexDescriptor* vertexDescriptor = [MTLVertexDescriptor vertexDescriptor];
        vertexDescriptor.attributes[0].offset = offsetof(ImDrawVert, pos);
        vertexDescriptor.attributes[0].format = MTLVertexFormatFloat2; // position
        vertexDescriptor.attributes[0].bufferIndex = 0;
        vertexDescriptor.attributes[1].offset = offsetof(ImDrawVert, uv);
        vertexDescriptor.attributes[1].format = MTLVertexFormatFloat2; // texCoords
        vertexDescriptor.attributes[1].bufferIndex = 0;
        vertexDescriptor.attributes[2].offset = offsetof(ImDrawVert, col);
        vertexDescriptor.attributes[2].format = MTLVertexFormatUChar4; // color
        vertexDescriptor.attributes[2].bufferIndex = 0;
        vertexDescriptor.layouts[0].stepRate = 1;
        vertexDescriptor.layouts[0].stepFunction = MTLVertexStepFunctionPerVertex;
        vertexDescriptor.layouts[0].stride = sizeof(ImDrawVert);

        MTLRenderPassDescriptor* rpd = mr.renderpassDescriptor;

        MTLRenderPipelineDescriptor* pipelineDescriptor = [[MTLRenderPipelineDescriptor alloc] init];
        pipelineDescriptor.vertexFunction = vertexFunction;
        pipelineDescriptor.fragmentFunction = fragmentFunction;
        pipelineDescriptor.vertexDescriptor = vertexDescriptor;
        pipelineDescriptor.rasterSampleCount = rpd.colorAttachments[0].texture.sampleCount;
        pipelineDescriptor.colorAttachments[0].pixelFormat = rpd.colorAttachments[0].texture.pixelFormat;
        pipelineDescriptor.colorAttachments[0].blendingEnabled = YES;
        pipelineDescriptor.colorAttachments[0].rgbBlendOperation = MTLBlendOperationAdd;
        pipelineDescriptor.colorAttachments[0].sourceRGBBlendFactor = MTLBlendFactorSourceAlpha;
        pipelineDescriptor.colorAttachments[0].destinationRGBBlendFactor = MTLBlendFactorOneMinusSourceAlpha;
        pipelineDescriptor.colorAttachments[0].alphaBlendOperation = MTLBlendOperationAdd;
        pipelineDescriptor.colorAttachments[0].sourceAlphaBlendFactor = MTLBlendFactorOne;
        pipelineDescriptor.colorAttachments[0].destinationAlphaBlendFactor = MTLBlendFactorOneMinusSourceAlpha;
        pipelineDescriptor.depthAttachmentPixelFormat = rpd.depthAttachment.texture.pixelFormat;
        pipelineDescriptor.stencilAttachmentPixelFormat = rpd.stencilAttachment.texture.pixelFormat;

        rps = [device newRenderPipelineStateWithDescriptor:pipelineDescriptor error:&error];
        if (error != nil) {
            rps = nil;
            NSLog(@"Error: failed to create Metal pipeline state: %@", error);
            break;
        }
    }

    if (!rps)
        return;

    const ShaderOptions* options = &inspector->CachedShaderOptions;
    static InspectorShaderConstants sc;
    sc.inK0 = options->inputK0;
    sc.inPhi = options->inputPhi;
    sc.inLinearBias = options->InputColorspace.linearBias;
    sc.inputGamma = options->InputColorspace.gamma;
    sc.outK0 = options->outputK0;
    sc.outPhi = options->outputPhi;
    sc.outLinearBias = options->OutputColorspace.linearBias;
    sc.outputGamma = options->OutputColorspace.gamma;
    sc.exposure = powf(2.0f, options->exposure);
    sc.lift = options->lift;
    sc.textureSize = {inspector->TextureSize.x, inspector->TextureSize.y};
    sc.forceNearestSampling = options->ForceNearestSampling;
    sc.grid = {options->GridColor.x, options->GridColor.y, options->GridColor.z, options->GridColor.w };
    sc.gridWidth = {options->GridWidth.x, options->GridWidth.y};
    memcpy(&sc.colorTransform, options->ColorTransform, sizeof(float) * 16);
    sc.backgroundColor = {options->BackgroundColor.x, options->BackgroundColor.y, options->BackgroundColor.z };
    sc.premultiplyAlpha = options->PremultiplyAlpha;
    sc.disableFinalAlpha = options->DisableFinalAlpha;

    auto commandEncoder = [DearImGui currentRenderCommandEncoder];
    [commandEncoder setFragmentBytes:&sc
                           length:sizeof(sc)
                          atIndex:2];
    [commandEncoder setRenderPipelineState:rps];


Update bulk

Replaces #254 for Teritori which has merge conflicts
Replaces #250 for Rebus which adds to main when it shouldn't, and has wrong ibc channel ids
-add REBUS, TORI, SOLAR to frontier, adds, stATOM to main,

@JeremyParish69 This merged PR added two different ibc denoms for SOLAR:
ibc/C2DF5C3949CA835B221C575625991F09BAB4E48FB9C11A4EE357194F736111E3 (in the denom_units)
ibc/C3FC4DED273E7D1DD2E7BAA3317EC9A53CD3252B577AA33DC00D9DF2BDF3ED5C (in the base)
I don't know which is the correct one, but doesn't seem accurate to me.


Build PyTorch and TensorFlow CUDA Notebook Images

Build PyTorch and TensorFlow CUDA Notebook Images
Description
This PR includes the instructions for building the PyTorch and TensorFlow CUDA notebooks as well as the Kustomization objects for testing them.
How Has This Been Tested?
Build the notebooks:
make cuda-jupyter-pytorch-ubi8-python-3.8

make cuda-jupyter-tensorflow-ubi8-python-3.8

Run the Image locally:
podman run --rm -it -p 8888:8888 ${IMAGE_REGISTRY}:cuda-jupyter-pytorch-ubi8-python-3.8

podman run --rm -it -p 8888:8888 ${IMAGE_REGISTRY}:cuda-jupyter-tensorflow-ubi8-python-3.8

Deploy it in your cluster:
make deploy- cuda-jupyter-pytorch-ubi8-python-3.8

make deploy- cuda-jupyter-tensorflow-ubi8-python-3.8

Run the test suite:
make test-cuda-jupyter-pytorch-ubi8-python-3.8

make test-jupyter-tensorflow-ubi8-python-3.8

Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

/hold till to configure upstream CI

/retest

/unhold

Opened a PR to fix the failed e2e test name here -> https://github.com/openshift/release/pull/33789

/retest

/test all


Issues with Redefinition and missing @key

Hey friend, thanks for sharing your code...
Im having the folowing issue:
Directive "external" already exists in the schema. It cannot be redefined.
Directive "requires" already exists in the schema. It cannot be redefined.
Directive "provides" already exists in the schema. It cannot be redefined.
Directive "key" already exists in the schema. It cannot be redefined.
Directive "extends" already exists in the schema. It cannot be redefined.

Any idea?

Yep. I'm getting that too.
Here's a quick workaround that's working for me...

Add the following to your schema:

type Query {
  … other stuff in your query root here
  _service: _Service!
}

type _Service {
  sdl: String
}

Remove your call to $federation->extendSchema but leave the one for addResolversToRootValue

Explanation:
The Apollo docs are a bit unclear on this, but the _service query is meant to return your service definition without additional directives declared:

This SDL does not include the additions of the federation spec above.

The extendSchema function adds all that stuff to the schema (which is correct), but then the resolver for _service returns the full schema unmodified, so Apollo gets upset that you didn't strip that stuff out before generating the SDL
I'll get a PR together if I have time.


Not animating when item has been visible on the screen

If the item is currently visible but not close to the leading edge, animateToIndex  would not scroll with animation.
See image:

Fixed in cfa689eb408ddd19fa90bbc381dabfdbb6aa0f62


Fix LaTeX

One more little change needed after previous two requests merged. Escapes markdown italic modifier

Plz don't merge berfre #33, I'll add the same fix for those changes

It's frustrating that GitHub's markdown + latex/mathtex/mathjax pipeline breaks like this. It especially bothers me as I render these all locally and they are fine, it is just here online that they are broken. :/
I'll hold off here until #33 is merged as requested. Could you take a look at https://github.com/ethereum/kzg-ceremony-specs/blob/master/docs/sequencer/sequencer.md#pairing-checks too please.

#33 is merged!

@CarlBeek Yep, the risk is that it may render differently outside of github.

Plz don't merge berfre https://github.com/ethereum/kzg-ceremony-specs/pull/33, I'll add the same fix for those changes

https://github.com/ethereum/kzg-ceremony-specs/pull/33 is now merged it might be useful to merge this as well now


SQL Server Profiler will not launch

Azure Data Studio Version:
Version 0.29.3
Commit 7099922c35bc3b3e223228c972cc03cee5abbe25
Date 2018-05-04T05:46:24.032Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

Steps to Reproduce:

Install SQL Server Profiler extension (Microsoft.profiler) version 0.11.0
Connect to DB
Press Ctrl + Shift + P
Type 'Profiler: Launch Profiler' and Press enter
Error message will appear in bottom right with this message: command 'profiler.newProfiler' not found

It looks like you're using a much older version of ADS - please update to the latest version and let us know if it still doesn't work for you.

@Charles-Gagnon I upgraded to 1.28.0 and that fixed the issue. I had previously just checked with the built in updater but apparently it was so old that the update mechanism no longer worked (was reaching out to https://sqlops-update.azurewebsites.net/api/update/win32-x64/stable/7099922c35bc3b3e223228c972cc03cee5abbe25 HTTP/1.1).
Thanks!


many json tests are failing with ruby 1.9

$ ruby1.9.1 --version
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
Full log here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623900#64

Ruby 1.9 is already EOL, the CI is passing for Ruby 2.0+. Feel free to reopen the issue if you still need something to be fixed


fix: segment countdown was only calculated for the first part in a se…

Segment countdown was only calculated for the first part in the previous segments.
The duration of the 2nd, 3rd, 4th, etc. parts in a segment were not used when adding up the countdown

It failed the rundown Timing Calculator › Handles budget duration test. I could hope the test was wrong, but I don't think so

Either the failing test or the fix needs some fixing 😃

I fixed the test. But I'm not sure I fully understand how the numbers are calculated

I gave it a spin, and I don't think it works as expected. Top segment has a budget of 0:20. On the screenshot it is in overtime (around 0:22). According to SOF-238, the bottom segment should show 0:00 instead of 0:20 on the right counter.

What property represents the budget in the json?
"totalTime": "16" ?

Sum of the budget durations of parts in a segment constitutes the segment's budget duration. The totalTime corresponds to segment budget duration and in our case it is applied to the first part of the segment. Technically the rest of the parts have 0 budget, but they may have expectedDurations, which are used for display and counting down servers.
When taking the screenshots, I'm on the first part of my top segment. It shouldn't matter if there are still more parts in that segment, and what their expectedDurations are. If the budget is spent, it is assumed the next segment is supposed to be taken now.
The test case was right, but only as long as the first part is on air, and didn't cover taking the next part, which had the buggy behaviour.
Note: I have the left clock, a.k.a. Segment duration in the default mode, not in the static mode used by TV 2, so that you also can see how that mode got broken.
mirror/release37.1:

develop:

I think I've found a solution to the problem. When calculating currentRemaining(time) it was using the start time of the last part so I changed that to use the start time of the first part in the segment.
I think there is multiple issues here. For some segments it doesn't use segment budget.
The countdown doesn't continue until i do a take but for other segments it does use the segment budget

After the take:

It seems like it's behaving different when it's playing the segment before the live segment

But for other segments it's using the entire budget on the first part

This is how it's working after the change. Is this acceptable?
https://user-images.githubusercontent.com/91883429/158989545-7610ef3a-07dc-4cb7-8940-8c38fddcce6e.mp4

It it briefly flashes an incorrect value when doing a take, but the rest seems fine 👍


Release v<IP_ADDRESS>

[x] create branch release and checkout it
[x] increment version number of ./randog/__init__.py
[x] build sphinx document
[ ] pull request release into develop branch
[ ] wait for merge
[ ] checkout develop and build package
[ ] publish to test.pypi
[ ] publish to pypi
[ ] pull request develop into main branch
[ ] wait for merge
[ ] create release

#3


fix(tutorial): add chat:bypass_slowchat scope to token link

The Click here to get your token link in all the tutorials automatically gives you an access token for making a simple ping/pong bot. However, a few have had trouble with this because the bot runs under the same account as the developer. The chat server sees "!ping" then "PONG!" from the same user, and then "PONG!" is blocked due to slowchat.
This adds chat:bypass_slowchat to the access token link to fix this problem, for those who want to get started making a chat bot.
Bug 3903

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


Redis Cluster Client support

Hey guys, saw that the last commit is 1y ago, is this project still maintained? Is it possible to use the redis client against a Redis cluster or does it only work against single primary instances?

Redis Cluster is supported now, use the version v1.1.0.
sample code:
rdb := redis.NewClusterClient(&redis.ClusterOptions{
    Addrs: []string{
        "<IP_ADDRESS>:6371",
        "<IP_ADDRESS>:6372",
        "<IP_ADDRESS>:6373",
    },
    Password: "1234",
})
bloom := bloomfilter.NewRedisBloomFilter(rdb, "test", 1000000)


persist snap to

License
I confirm that this contribution is made under an Apache 2.0 license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

should be loadingDone


Specific string whether keyring exists or not

Current

Wording is a little bit misleading when executing a command which look into keyring to find some credentials:

➜ rm -rf .plasmactl/keyring.yaml.age .compose                  <---- Removing keyring

➜ ./plasmactl meta dev tag -vvv
Enter passphrase to unlock the keyring:                        <---- Actually asking pw to create new keyring
(...)

String seems to be the same wether keyring already exist or not

Expected

String should be different wether keyring already exist or not:
Enter passphrase to unlock the keyring should be printed only if keyring exists
Enter passphrase to create new keyring should be printed if keyring does not exists

So after all, because of recent changes in meta command, there is no usecase where new keyring can be created (error is thrown instead and execution stops):

Keyring PR does fix issue double asking keyring passphrase
Meta PR removes un-used code, update strings, and updates deps


More performant collection handle createReference() impl

Improvements:

writeArcHostContext: 8x faster
add a new participant: 2-3x faster

Hooray!


In the evaluateion results, only pedestrian AP and AR

Hello！
I follow the prompt of Readme.md, Run the code in the following sequence: python slice3d.py -> python prepare_data.py -m train -dd './data/' ->python prepare_data.py -m test -dd './data/' -> python train_dop.py -m C3D -> python test.py -m C3D -md C3D-20200904-001923 -> python evaluate.py -md C3D-20200904-001923
In the end, there is only the indicator of pedestrians
RAMPCNN) dell@dell-Precision-7920-Tower:/media/dell/data1/radar_dl/Radar-multiple-perspective-object-detection$ python evaluate.py -md C3D-20200904-001923 -rd ./results/
true seq
./results/C3D-20200904-001923/2019_05_28_pm2s012/rod_res.txt
pedestrian: 1913 dets, 1792 gts
Average Precision  (AP) @[ OLS=0.50:0.90 ] = 0.9126
Average Recall     (AR) @[ OLS=0.50:0.90 ] = 0.9653
pedestrian: 1913 dets, 1792 gts
Average Precision  (AP) @[ OLS=0.50:0.90 ] = 0.9126
Average Precision  (AP) @[ OLS=0.50      ] = 0.9713
Average Precision  (AP) @[ OLS=0.60      ] = 0.9713
Average Precision  (AP) @[ OLS=0.70      ] = 0.9489
Average Precision  (AP) @[ OLS=0.80      ] = 0.9062
Average Precision  (AP) @[ OLS=0.90      ] = 0.7054
Average Recall     (AR) @[ OLS=0.50:0.90 ] = 0.9653
Average Recall     (AR) @[ OLS=0.50      ] = 0.9994
Average Recall     (AR) @[ OLS=0.75      ] = 0.9821
pedestrian: 1913 dets, 1792 gts
Average Precision  (AP) @[ OLS=0.50:0.90 ] = 0.9126
Average Precision  (AP) @[ OLS=0.50      ] = 0.9713
Average Precision  (AP) @[ OLS=0.60      ] = 0.9713
Average Precision  (AP) @[ OLS=0.70      ] = 0.9489
Average Precision  (AP) @[ OLS=0.80      ] = 0.9062
Average Precision  (AP) @[ OLS=0.90      ] = 0.7054
Average Recall     (AR) @[ OLS=0.50:0.90 ] = 0.9653
Average Recall     (AR) @[ OLS=0.50      ] = 0.9994
Average Recall     (AR) @[ OLS=0.75      ] = 0.9821
What is the problem caused by what is the problem？

Thanks for raising this. This is because, in the sample test set, there is only one file that contains pedestrian objects exclusively and the indications for other classes are skipped. To solve this issue, I would suggest you download more data from the dataset and append the test set in evaluate.py


add type hints to allow static code analysis using mypy

Hey
i love your package as it eases lots of printing issues with engineering units ❤
In my projects i use mypy for static code analysis. Actually quantiphy doesn't use type hints at all.
It would be great if we can add type hints and the py.typed to advertise that this package is using type hints.
http://www.mypy-lang.org/
https://peps.python.org/pep-0561/
Best regards
Tom

Well, I took another run at this and I think I have a reasonable set of type hints.  This is my first experience with them, so there may be issues I missed.  They are checked into this github repository if you would like to try them out.  I would appreciate any feedback you might have.

I have just released the latest version of QuantiPhy that includes type hint and pushed it to PyPi.


Cannot redefine property: fetch

Describe the bug
I'm trying to import a built svelte-kit site within another one, and it is not possible because importing import { handler } from 'sub-site/build/handler' has side-effects, namely calling __fetch_polyfill.
Reproduction

Create a svelte-kit website that uses adapter-node
Build this website
Create another svelte-kit website with the following configuration

import adapter from '@sveltejs/adapter-node'
import preprocess from 'svelte-preprocess'
import { handler } from 'sub-site/build/handler'

/** @type {import('@sveltejs/kit').Config} */
const config = {
  preprocess: preprocess(),
  kit: {
    adapter: adapter(),
    target: '#svelte',
    vite: {
      plugins: [
        {
          name: 'sub-site',
          configureServer({ middlewares }) {
            middlewares.use(handler) // Load the sub-site here
          },
        },
      ],
    },
  },
}

export default config

Logs
> Cannot redefine property: fetch
    at Function.defineProperties (<anonymous>)
    at __fetch_polyfill (file:///home/.../node_modules/.pnpm/@sveltejs+kit@1.0.0-next.229_svelte@3.46.1/node_modules/@sveltejs/kit/dist/install-fetch.js:6494:9)

System Info
SvelteKit v1.0.0-next.229
Adapter Node v1.0.0-next.61

Severity
annoyance
Additional Information
I'll submit a PR in a few minutes that fixes this issue, the solution is to add configurable: true to all definitions here:
https://github.com/sveltejs/kit/blob/f92c3e212dbb3247904fd5c3229c040a9650db41/packages/kit/src/install-fetch.js#L4-L23

@Rich-Harris Could you please bump adapter-node to use kit v231?

#3357 that fixes this has been merged. Closing this.

Could you please bump adapter-node to use kit v231?

I'm not sure what you mean. adapter-node doesn't have a hard version on kit?

I'm not sure what you mean. adapter-node doesn't have a hard version on kit?

That's right, but since adapter-node was built and published before #3357 was merged, the dist still contains the old __fetch_polyfill.

Ah I see. Looks like adapter vercel, node and netlify builds based on kit. I'll make a changeset for them so they get re-released.


fix(mongoose): replace NativeError with Error

Replace mongoose NativeError with Error since the latest version of mongoose no longer export NativeError
see: https://github.com/Automattic/mongoose/pull/11695#issuecomment-1104512629
Information

Type
Breaking change

Fix
No

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

v6.114.8
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.0.0-beta.13 :tada:
The release is available on:

v7.0.0-beta.13
GitHub release

Your semantic-release bot :package::rocket:


Update README.md - NeurIPS 2022

Can you please add our NeurIPS 2022 work on EPIC-Kitchens 100 and Ego4D? Thanks!

Hello @HimangiM, thank you for sharing your work with us! If available, I would request you to please add links to project page, code, additional videos, etc. Otherwise, let me know, I will merge in its current state.

Hi @Sid2697, thank you for pointing it out! I have added the links to the code and video of the work.


Mark some tests as flaky

We often have cron or PR jobs fail due to little things like a network hangup or random weird travis issues (see this from this morning, in which the entire project gets a red badge because a single DOI test failed: https://travis-ci.org/mosdef-hub/foyer/builds/500469282, or the history https://travis-ci.org/mosdef-hub/foyer/builds). Restarting jobs is fine, but it would be nice to avoid this altogether. The badge will probably turn green tomorrow when the next cron jobs run, but it should be green now. I believe marking these tests as flaky is the right approach, @mikemhenry @justinGilmer?

In general, the test suite should not be making network calls. You should be mocking out the request in the test suite using something like this:
https://requests-mock.readthedocs.io/en/latest/pytest.html
Definitely not necessary here but if you find yourself mocking out lots of requests you can reach for something heavier like this: https://github.com/kevin1024/vcrpy

I think we should mock stuff, and then keep in the real network tests but just mark them as flaky, so they can still be tested/catch issues, but won't stop things from passing.

Despite #276, took into account the changed crossref api, tests are failing. Should create mock objects to test when handling the tests. Make sure that the functions using this retry the request.get, before giving up.


SPARK-17059: Allow FileFormat to specify partition pruning strategy

fixed

@schlosna @robert3005

And yeah - i have this concurrent with the other PR

👍  LGTM, excited to test

There are no additional tests in this PR right now -- do we need to write some or does the existing test coverage already give us confidence in this change?

The tests already exist for pruning from the previous implementation
Sent from my iPhone

On Nov 17, 2016, at 5:57 PM, Andrew Ash<EMAIL_ADDRESS>wrote:
There are no additional tests in this PR right now -- do we need to write some or does the existing test coverage already give us confidence in this change?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

👍 from me. Might make sense to trim blockmetadata to just the statistics + path + type + size in the future but for simplicity can keep all of it.


Automated ref finder for asap-alchemy

Description
For asap-alchemy we don't want to have to manually find a crystal structure to use as reference for docking every time we build a network. Instead, we want to find this automatically (https://github.com/choderalab/asapdiscovery/issues/918).
Caveats:

we typically prep before we dock, but to find the correct reference we need the ligands, so this jumbles up the order a bit. I opted for loading the ligands during prep, then just re-loading them during dock. This isn't very elegant but has minimal overhead.
references may/may not be compatible with OpenMM for a variety of reasons. I built in a check that makes sure we're moving forward with a compatible reference.
I'm a horrible person so the code is a bit monolithic in its current state; @hmacdope should advise on how to move some things around, particularly in this section and this one.
I accidentally pushed to another branch (https://github.com/choderalab/asapdiscovery/pull/919) so I had to fix all that which resulted in this PR having a large bulk commit rather than incremental ones.

Developers certificate of origin

[x] I certify that this contribution is covered by the MIT license as defined in our LICENSE and adheres to the Developer Certificate of Origin.

@hmacdope can I grab a quick review? Feel free to just give some pointers on where things should be dropped if you think the current placing is off.

Codecov Report

Merging #938 (d239f5b) into main (026c320) will decrease coverage by 2.93%.
Report is 5 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files

Closing in favour of #966


babel6 decorators

I am trying to use babel 6 but it doesn't support decorators.
Decorators seem to be used within the tcomb-spa-example app at various places.
It would like to continue to use Babel6.
Can you suggest ideas for a way forward?
Is it practical to somehow comment out all the decorators or use some sort of alternative code?
thanks!

I am trying to use babel 6 but it doesn't support decorators.

Indeed, I'm an happy user of babel 5

Is it practical to somehow comment out all the decorators or use some sort of alternative code?

Just use the vanilla syntax, I guess
@mydecorator
class A {}

is (roughly) equivalent to
class A {}
mydecorator(A)


Advertise generic-claim workflow for cluster_claim

Attempting to cut over from cluster_pool+ipi-aws to cluster_claim, it took several false starts, experimentation, and pawing through docs to figure out that generic-claim was the missing piece. Beef up the docs to help future users.

/assign @petr-muller
...as I'm told you're involved in helping folks cut over to cluster_claim :)

/retest


What's new in ASP.NET Core 6.0 /3

Fixes #22852
Internal review URL
Public review  of the doc build

download https://www.dropbox.com/sh/yy994551cje0kap/AAB0tRnm7gze2kYrSYPSFHIda?dl=0
unzip
view HTML file in FF (Fire Fox). It best to view the doc with the widest window that has no left or right TOC (Table  of contents)

@JuergenGutsch I left public review instructions at the top of this PR if you'd like to review my edit of your work. Thanks for helping out.

@Rick-Anderson Your edits look absolutely fine. It is more complete than my work since you added some more information :-)

@JuergenGutsch  thanks for PRing your work, well done and it saved me a lot of time.
Be sure to check out your name as a contributor about the 6th of next month on the What's new page


#153950669 client side signin

What does this PR do?
sign in user from the client side
Description of Task to be completed?
Signin a user
How should this be manually tested?
clone the branch and sing in a new user
Any background context you want to provide?
N/A
What are the relevant pivotal tracker stories?
#153950669 users should be able to sign in from the client side
Screenshots

Questions:
N/A

Coverage remained the same at 93.145% when pulling 714a53d9763c3d4be046bc1face81d380d8ea663 on feature/#153950669/client-side-signin into d27713b2c648149925aef0f0606ab10149524cbe on develope.


About the input_embeds of autodan

Thanks for your awesome job!
I've encountered some issues with the implementation of autoDan, which appears to deviate significantly from the implementation described in the original paper. Specifically, I've observed that the input_embeds fed into the compute_candidates_loss function consists of both candidates_embeds and target_embeds. The candidates_embeds, in turn, encompass the entirety of the message content. This approach is effective when all candidates_tokens are uniformly lengthy. However, given that autoDan employs varying prompts, the lengths of candidates_tokens are inconsistent, necessitating the padding of these tokens within the code.
However, upon padding, some candidates inadvertently transform into a format that resembles "prompt-pad-target." This structure implies that padding tokens are interspersed within the overall input sequence, which could potentially alter the model's output and contribute to unstable loss calculations.
I'm uncertain if my understanding is correct, and I find the situation quite perplexing. I've reviewed the notebook containing experimental records and noticed that the optimal loss fluctuates during the experiment's progression. This is unexpected because autoDan is designed to maintain an elicitation group, so ideally, the loss should not increase. Could you please examine this issue? Thank you for your reading!

I noticed that the padding side of the tokenizer is left but I think attention mask is necessary to calculate the logits.


Switching from Madoko to AsciiDoc for P4Runtime specification

I am currently in the process of transitioning the P4Runtime specification from Madoko to AsciiDoc. Below is an overview of the remaining tasks:

I need to fix the layout of two tables in the P4Runtime-spec.adoc file.
Finalize the reorganization and changes necessary for folder structure to support the switch from Madoko to AsciiDoc.

I tried make in the docs/v1 directory on a Linux system, and got this error:
$ make
make: *** No rule to make target 'P4Runtime-Spec.adoc', needed by 'P4Runtime-Spec.pdf'.  Stop.

Note the capitalization of the S in Spec.  The file name in your PR is P4Runtime-spec.adoc with a lower-case s in spec.
I would recommend changing leaving the Makefile as it is now, and renaming the .adoc file to match the current capitalization of the Madoko source file.

The file logo.png is missing

Need to update the markup for the URL at the end of Section 1 -- in the PDF output it shows up as https://...

At least some cross-references to figures are rendered in PDF as "Figure Figure 1".  In Madoko it was necessary to say "Figure [#crossref-tag]" in the source, but the "Figure" is redundant in AsciiDoc.  Similarly for section and table references.

In the first paragraph of Section 4, a sentence in the PDF ends with "are described in a laterChapter 5."  It would be better if it were "are described in Chapter 5".

Most or all of the figures could use some tweaking on the percent of the column width they occupy, to make them smaller.  See the P4 language spec AsciiDoc source for examples.

You use [source,p4] at the beginning of snippet of Protobuf definitions.  Does Rouge support [source,protobuf]?

The paragraph at the end of Section 6.4.3 ActionProfile looks blank in the PDF, probably because in the source it has spaces at the beginning of each line.  Something should be done to improve that, probably deleting those leading spaces so the text comes out as a normal paragraph after the bullet list.
It is not clear to me, but perhaps those spaces were there intending for that text to be part of the last bullet, or something like that?  If so, there are probably different markups in AsciiDoc that can achieve that, but given that it looks like a separate paragraph in the current Madoko PDF output, making it look like a separate paragraph in the AsciiDoc PDF output is a good start.

Compare the section heading "depths" of all section headings in the current Madoko PDF output, and the AsciiDoc PDF output.  At least "Counter & DirectCounter" is Section 6.4.4 in Madoko PDF output, but Section 6.5 in AsciiDoc PDF output.

In the section titled "Extern", need whitespace after "reserved range" and before the range.

In one of the markups that should be "cite:", it is misspelled "cte:"

In the section titled "Bytestrings" there are some LaTeX math formulas.  There are a few such formulas in the P4 language spec, too, that I was able to get to render properly using AsciiDoc.  Search for occurrences of "latexmath" in the P4 language spec AsciiDoc source for examples.

There is at least one remaining occurrence of [@PSATranslation] that should be updated to cite:[PSATranslation].  Also one occurrence of [@PSAActionSelector].

One cross-reference with text [P4 Entity Messages](#sec-p4-entity-msgs) section needs to be updated to AsciiDoc.

There is an occurrence of "WriteRequests" that should be replaced with "WriteRequests" for AsciiDoc.  See here for some examples of differences I found when translating the P4 language spec: https://github.com/jafingerhut/learn-asciidoc/blob/main/p4-spec-next/README-madoko-to-asciidoc-notes.md#monospace

The section heading for the section named "Examples of StreamError Messages" needs at least one blank line before it, or else AsciiDoc does not interpret it as a section header.
There is also an old Madoko-style cross-reference markup on the line before that.

In the section "Changes in v1.4.0", the first sub-bullet item under "Actions" needs to be nested one level deeper.

In section "P4Runtime Entries files" the sequence of bash commands needs different markup.  Not sure, but maybe [source,bash] will work?

FYI, the comments were I "react"  with a thumbs-up have been addressed in https://github.com/p4lang/p4runtime/pull/510/commits/c43d9382977d06c14f8cfa07cefc76a21bec5e70

FYI, the comments were I "react" with a thumbs-up have been addressed in c43d938

Great!  Please let me know when you are ready for another round of review, i.e. when for each review comment you have either made changes, or replied in some way that you believe no changes are needed.

You use [source,p4] at the beginning of snippet of Protobuf definitions. Does Rouge support [source,protobuf]? I am guessing from the existence of a lexer for Protobuf here that it should: https://github.com/rouge-ruby/rouge/blob/master/lib/rouge/lexers/protobuf.rb

I applied it to a few proto code blocks (such as 6.1.2) so we can compare and see how it looks.

Compare the section heading "depths" of all section headings in the current Madoko PDF output, and the AsciiDoc PDF output. At least "Counter & DirectCounter" is Section 6.4.4 in Madoko PDF output, but Section 6.5 in AsciiDoc PDF output.

I fixed the  heading "depths" ; now it should be fine

@jafingerhut , There are still things I need to address/fix:

https://github.com/p4lang/p4runtime/pull/510#issuecomment-2480923989
https://github.com/p4lang/p4runtime/pull/510#issuecomment-2480921350
Images convertion via make
I need to fix the layout of two tables in the P4Runtime-spec.adoc file.

I generated PDF again from the version of AsciiDoc source for commit 6 of this PR.
Reviewing the table of contents, I see that in the AsciiDoc version, the section headings "8.2.2 ExternEntry" through "8.2.13 DigestEntry" appear in the AsciiDoc PDF table of contents, but were not in the Madoko PDF table of contents.  In the Madoko, those were level 4 headings, i.e. they were <IP_ADDRESS> thorugh <IP_ADDRESS>.  It would be good to make them level 4 headings in the AsciiDoc, too.
Same comment for sections with these titles:

Rules on setting max_size
Valid values for multicast_group_id
Valid values for session_id

I have the opposite comment for these appendix section titles.  They should be one level shallower:

A more complex value set example
P4Runtime Entries files

These figures have duplicate "Use Case: Use Case: " in their titles.  It should be just "Use case:"

Use-Case: Use-Case: Single Remote Controller
Use-Case: Use-Case: Embedded Plus Single Remote Controller

The list of tables is slightly different in Madoko and AsciiDoc PDF.  Maybe this is intentional, but it bears a closer look to see if this is a mistake in the AsciiDoc source:

AsciiDoc PDF has a table "Example of statically-assigned P4Info object IDs" that is not in the Madoko PDF list of tables
Madoko PDF has a table "P4 annotations introduced by P4Runtime" that is not in the Asciidoc PDF list of tables

You use [source,p4] at the beginning of snippet of Protobuf definitions. Does Rouge support [source,protobuf]? I am guessing from the existence of a lexer for Protobuf here that it should: https://github.com/rouge-ruby/rouge/blob/master/lib/rouge/lexers/protobuf.rb

I applied it to a few proto code blocks (such as 6.1.2) so we can compare and see how it looks.

The ones you have changed look better to me in their syntax coloring.  I would recommend replacing all remaining occurrences of [source,p4] that appear before Protobuf code snippets with [source,protobuf]

I think it was Ryan Goodfellow who found this line that can be added at the lines near the beginning, to include the current date in the title page:
:revdate: {docdate}

We should probably use that for this spec, too.

FYI, the comments were I "react" with a thumbs-up have been addressed in c43d938

And I have added a "rocket ship" reaction to those comments that I have checked, and they look like they have been fixed to me, too.

In my local copy, I have made these changes to the file docs/v1/Makefile, and they seem to help in auto-generating the needed formats of the figures when running make:
$ diff -c Makefile Makefile.next
*** Makefile	2024-11-20 03:49:48.667394894 +0000
--- Makefile.next	2024-11-20 03:49:45.839303382 +0000
***************
*** 10,20 ****
  	mkdir -p build

  # Note: Brute-force image rendering; could use more precise file-by-file make rules
! images: build resources/figs/*.odg
! 	soffice --convert-to svg --outdir build resources/figs/*.odg > /dev/null 2>&1
! 	soffice --convert-to png --outdir build resources/figs/*.odg > /dev/null 2>&1

! ${SPEC}.pdf: ${SPEC}.adoc
  	time asciidoctor-pdf -v \
  	-a pdf-fontsdir=resources/fonts \
  	-r asciidoctor-mathematical \
--- 10,20 ----
  	mkdir -p build

  # Note: Brute-force image rendering; could use more precise file-by-file make rules
! figs: build resources/figs/*.odg
! 	soffice --convert-to svg --outdir resources/figs resources/figs/*.odg > /dev/null 2>&1
! 	soffice --convert-to png --outdir resources/figs resources/figs/*.odg > /dev/null 2>&1

! ${SPEC}.pdf: ${SPEC}.adoc figs
  	time asciidoctor-pdf -v \
  	-a pdf-fontsdir=resources/fonts \
  	-r asciidoctor-mathematical \
***************
*** 22,28 ****
  	-r asciidoctor-lists \
  	-a rouge-style=$(ROUGE_STYLE) $<

! ${SPEC}.html: ${SPEC}.adoc
  	time asciidoctor -v \
  	-r asciidoctor-mathematical \
  	-r asciidoctor-bibtex \
--- 22,28 ----
  	-r asciidoctor-lists \
  	-a rouge-style=$(ROUGE_STYLE) $<

! ${SPEC}.html: ${SPEC}.adoc figs
  	time asciidoctor -v \
  	-r asciidoctor-mathematical \
  	-r asciidoctor-bibtex \

I generated PDF again from the version of AsciiDoc source for commit 6 of this PR.
Reviewing the table of contents, I see that in the AsciiDoc version, the section headings "8.2.2 ExternEntry" through "8.2.13 DigestEntry" appear in the AsciiDoc PDF table of contents, but were not in the Madoko PDF table of contents. In the Madoko, those were level 4 headings, i.e. they were <IP_ADDRESS> thorugh <IP_ADDRESS>. It would be good to make them level 4 headings in the AsciiDoc, too. (but I like very much that level 4 and 5 headings appear in the table of contents in the AsciiDoc output -- please do not do anything to remove them).
Same comment for sections with these titles:

Rules on setting max_size
Valid values for multicast_group_id
Valid values for session_id

I have the opposite comment for these appendix section titles. They should be one level shallower:

A more complex value set example
P4Runtime Entries files

I cannot make them level 4 headings. More specifically, during compilation, they are automatically adjusted to level 3

That is very odd.  I just tested on my local version, and changing those headings prefix from ==== to ===== and regenerating the PDF, and they became level 4 headings in the table of contents.
I do not know if it makes any difference, but I have the asciidoctor-pdf and other tools installed on an Ubuntu 24.04 Linux system.

I generated PDF again from the version of AsciiDoc source for commit 6 of this PR.
Reviewing the table of contents, I see that in the AsciiDoc version, the section headings "8.2.2 ExternEntry" through "8.2.13 DigestEntry" appear in the AsciiDoc PDF table of contents, but were not in the Madoko PDF table of contents. In the Madoko, those were level 4 headings, i.e. they were <IP_ADDRESS> thorugh <IP_ADDRESS>. It would be good to make them level 4 headings in the AsciiDoc, too. (but I like very much that level 4 and 5 headings appear in the table of contents in the AsciiDoc output -- please do not do anything to remove them).
Same comment for sections with these titles:

Rules on setting max_size
Valid values for multicast_group_id
Valid values for session_id

I have the opposite comment for these appendix section titles. They should be one level shallower:

A more complex value set example
P4Runtime Entries files

I cannot make them level 4 headings. More specifically, during compilation, they are automatically adjusted to level 3

That is very odd. I just tested on my local version, and changing those headings prefix from ==== to ===== and regenerating the PDF, and they became level 4 headings in the table of contents.
I do not know if it makes any difference, but I have the asciidoctor-pdf and other tools installed on an Ubuntu 24.04 Linux system.
Note: Section 8.2.1 should remain level 3 heading, not level 4, and AsciiDoc probably does not support jumping from a level 2 directly to a level 3 heading. Maybe you tried to change 8.2.1 from level 3 to level 4 heading, too?

I use Ubuntu 20.04.06

@DScano I just tested with Ubuntu 20.04.6, and I see the same behavior there.
If I change section 8.2.1 from ==== (level 3 heading) to ===== (level 4 heading), and I do the same for the many sub-sections, starting with "ExternEntry", after that, then I see that AsciiDoc makes them all level 3 in the PDF.
But that ISN"T what we should do.

The list of tables is slightly different in Madoko and AsciiDoc PDF. Maybe this is intentional, but it bears a closer look to see if this is a mistake in the AsciiDoc source:
* AsciiDoc PDF has a table "Example of statically-assigned P4Info object IDs" that is not in the Madoko PDF list of tables

* Madoko PDF has a table "P4 annotations introduced by P4Runtime" that is not in the Asciidoc PDF list of tables

Sorry Andy but I didn't get this point. Could you please explain it better?

The list of tables is slightly different in Madoko and AsciiDoc PDF. Maybe this is intentional, but it bears a closer look to see if this is a mistake in the AsciiDoc source:
* AsciiDoc PDF has a table "Example of statically-assigned P4Info object IDs" that is not in the Madoko PDF list of tables

* Madoko PDF has a table "P4 annotations introduced by P4Runtime" that is not in the Asciidoc PDF list of tables

Sorry Andy but I didn't get this point. Could you please explain it better?

The caption text on the last figure is incorrect, so of course it is also wrong in the auto-generated list of figures.  I noticed the problem by comparing old Madoko PDF list of figures to AsciiDoc PDF list of figures first, and made the comment above.  Later when I realized that the problem is that the last figure's caption text is wrong, I also added a comment directly on that caption.

The list of tables is slightly different in Madoko and AsciiDoc PDF. Maybe this is intentional, but it bears a closer look to see if this is a mistake in the AsciiDoc source:
* AsciiDoc PDF has a table "Example of statically-assigned P4Info object IDs" that is not in the Madoko PDF list of tables

* Madoko PDF has a table "P4 annotations introduced by P4Runtime" that is not in the Asciidoc PDF list of tables

Sorry Andy but I didn't get this point. Could you please explain it better?

The caption text on the last figure is incorrect, so of course it is also wrong in the auto-generated list of figures. I noticed the problem by comparing old Madoko PDF list of figures to AsciiDoc PDF list of figures first, and made the comment above. Later when I realized that the problem is that the last figure's caption text is wrong, I also added a comment directly on that caption.

Clear, thanks

Below is an overview of the remaining tasks:

From my understanding, the table style needs to be fixed.
The HTML file is not being generated due to missing file errors. I'm currently investigating the issue.

Below is an overview of the remaining tasks:

From my understanding, the table style needs to be fixed.
The HTML file is not being generated due to missing file errors. I'm currently investigating the issue.

It is not clear to me why $< works for the PDF rule, but is blank for the HTML rule.  I would recommend replacing all occurrences of $< with ${SPEC}.adoc, which should enable things to work for both targets.

In Section 6.4.5 "Meter & DirectMeter", all of the bullet items and text starting with "The meter type can be any of" is indented further than it should be.  I don't know if this is easy to figure out in AsciiDoc markup, so I can make this a separate issue to fix later after this is merged in, if it is not easy.  It is readable as is.

I looked a bit into the names of languages used by the Rouge package.  Currently as of commit 9, these are the language names used in P4Runtime-Spec.adoc:
$ grep source, P4Runtime-Spec.adoc  | sort | uniq -c
      1 execute the direct resource, and the server must return an `INVALID_ARGUMENT`
      1 [source, bash]
      4 [source,c++]
      4 [source,cpp]
     34 [source,p4]
     34 [source,proto]
     22 [source,protobuf]
      6 [source,pseudo]

According to these lines in the Rouge source code, cpp and c++ appear to both be names that can be used for C++ code: https://github.com/rouge-ruby/rouge/blob/master/lib/rouge/lexers/cpp.rb#L12-L13
I'd recommend we consistently use one of them in the spec.  I didn't flip a coin to decide, but maybe c++ ?
Similarly protobuf and proto appear to be aliases in Rouge: https://github.com/rouge-ruby/rouge/blob/master/lib/rouge/lexers/protobuf.rb#L9-L10
Again, I'd recommend we pick one of them.  I'd prefer protobuf.
There does not appear to be any Rouge language called pseudo.  I looked at all of the code snippets that use source,pseudo now, and they look like they could be legal C++ or Python.  Maybe try out [source,python] and see how the colorization looks?

Below is an overview of the remaining tasks:

From my understanding, the table style needs to be fixed.

I looked at some of the tables in the PDF output, and they look pretty much like the ones in the PDF output of the AsciiDoc for the P4 language spec.
If you have ideas on how to make them look better, that would be nice, but unless someone else objects I wouldn't want that to prevent merging in these changes.

Other cleanup things:

Please remove all of these files that are currently in the docs/v1 directory, which I believe were only used by the syntax highlighting of Madoko:

cpp.json
p4.json
proto.json
prototext.json
bibref_no_title.js
setup-for-ubuntu-linux.sh

Unless you want to update p4runtime/docs/README.md now, I'd recommend creating an issue to remind us to update it.  It has instructions on writing Madoko markup.
Remove or update the file make.bat.  I don't know who actually ever used it, but maybe someone did?

@jafingerhut Should we also remove the folder named fonts in p4runtime/docs/tools

Other cleanup things:

Please remove all of these files that are currently in the docs/v1 directory, which I believe were only used by the syntax highlighting of Madoko:

cpp.json
p4.json
proto.json
prototext.json
bibref_no_title.js
setup-for-ubuntu-linux.sh

Unless you want to update p4runtime/docs/README.md now, I'd recommend creating an issue to remind us to update it. It has instructions on writing Madoko markup.
Remove or update the file make.bat. I don't know who actually ever used it, but maybe someone did?
Remove p4runtime/tools/madokolint.py
Update p4runtime/CONTRIBUTING.md to remove references to Madoko. Add appropriate mentions of AsciiDoc, if that seems appropriate.

I have updated the installation sections in the Readme, referencing the guidelines provided at https://docs.asciidoctor.org/asciidoctor/latest/install/

Below is an overview of the remaining tasks:

From my understanding, the table style needs to be fixed.

I looked at some of the tables in the PDF output, and they look pretty much like the ones in the PDF output of the AsciiDoc for the P4 language spec.
If you have ideas on how to make them look better, that would be nice, but unless someone else objects I wouldn't want that to prevent merging in these changes.

I improved the text alignment for the table captions

@jafingerhut do we have to remove/update the README.md in

@jafingerhut Should we also remove the folder named fonts in p4runtime/docs/tools?

I'd say anything that is only needed for Madoko-to-PDF or Madoko-to-HTML should be removed.  If someone wants them for any reason, they are there in the commit history.

@jafingerhut I played a bit with the lint scripts, Madoko, and Asciidoc, and the result is asciidoclint.py. I use it to find and remove trailing whitespace in P4Runtime-Spec.adoc.

The caption for the last table, Table 7, is still wrong.  It should be "P4 annotations introduced by P4Runtime".

So in commit 14, while you did correct the caption for the last table, you also changed the caption for an earlier table, so that now that one is incorrect.

@chrispsommers @smolkaj Davide Scano has gotten this to a point where I think it is ready to merge in.  It might need some testing/tweaking for where it auto-generates the PDF and HTML files on each commit, so that they are visible in the "working draft" links on the P4.org web site Specifications page, but that seems best to fix up in a later PR if needed.
If you want to see the generated PDF and HTML files, I encourage you to check out this PR's changes locally and follow the README instructions for installing AsciiDoc tools and running make in the docs/v1 directory.  Or if you prefer to see PDF and HTML generated for you, you can find them here:

https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: https://github.com/p4lang/p4-spec/pull/1340
Ryan Goodfellow asks whether we might avoid doing this.  Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

This means that we will keep .odg images in the figures folder, along with .png and/or .svg files.  Is this correct?

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

This means that we will keep .odg images in the figures folder, along with .png and/or .svg files. Is this correct?

If we do (a), then yes.
If we do (b), then no.  Only README steps would be changed to let people know that they would need to install LibreOffice.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

This means that we will keep .odg images in the figures folder, along with .png and/or .svg files. Is this correct?

If we do (a), then yes.
If we do (b), then no. Only README steps would be changed to let people know that they would need to install LibreOffice.

I think (a) is better. In the meantime, I have created a proposal here: PR. It reuses existing documentation and incorporates commands defined in the Makefile

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

This means that we will keep .odg images in the figures folder, along with .png and/or .svg files. Is this correct?

If we do (a), then yes.
If we do (b), then no. Only README steps would be changed to let people know that they would need to install LibreOffice.

I think (a) is better. In the meantime, I have created a proposal here: PR. It reuses existing documentation and incorporates commands defined in the Makefile. If make sens for you I'm going to push also the .png and .svg files.

That approach seems fine to me.  We will still want some README steps somewhere explaining to people how to update existing figures, or add new figures, and update the .png/.svg files from those, which will require installing LibreOffice, but as figures seem to be updated fairly infrequently, most people would not need to read those.

Is the file docs/v1/libre-office.png needed for anything?  If not, I'd suggest removing it.

It's needed in the README. More in detail I kept the approach used herefor the section Document Figures.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

I am the originator of this LibreOffice workflow. In those ancient days of yore, there was a lack of open-source drawing tools and I had as a goal to store image sources vs. binary blobs (.PNGs) which was a problem then (and still is in some circles).
Since then, editable SVGs (or editable PNG) and draw.io have become almost the norm. I can think of two solutions to retire the from our workflow:

If we can export the .odg files under assets to editable .svg would they be directly usable in ASCIIDOC w/o rerendering? (Is exporting to SVG possible in LibreOffice?)
Export the .odgs as .png and store them as bitmaps. The diagrams haven't changed sine they were created, 4-6 years ago! In the unlikely case that something needs to be redrawn, someone can do it in draw.io or any other tool of choice and save as .svg.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

I am the originator of this LibreOffice workflow. In those ancient days of yore, there was a lack of open-source drawing tools and I had as a goal to store image sources vs. binary blobs (.PNGs) which was a problem then (and still is in some circles).
Since then, editable SVGs (or editable PNG) and draw.io have become almost the norm. I can think of two solutions to retire the from our workflow:

If we can export the .odg files under assets to editable .svg would they be directly usable in ASCIIDOC w/o rerendering? (Is exporting to SVG possible in LibreOffice?)
Export the .odgs as .png and store them as bitmaps. The diagrams haven't changed sine they were created, 4-6 years ago! In the unlikely case that something needs to be redrawn, someone can do it in draw.io or any other tool of choice and save as .svg.

An alternative to checking in the .png / .svg files would be to leave only the .odg files checked in, and enhance the README of this repo to mention that one must install LibreOffice when they want to generate PDF/HTML from AsciiDoc sources. What do you think of that approach?

Why "one must install LibreOffice when they want to generate PDF/HTML from AsciiDoc sources?" Can't you use the docker image? As I understand it, you need LibreOffice to create/edit the drawings, and that requires one to install it locally.

@Dscano In this PR where I propose installing LibreOffice in the script that installs required software for building HTML/PDF from AsciiDoc sources: p4lang/p4-spec#1340
Ryan Goodfellow asks whether we might avoid doing this. Right now, it is only required for the P4Runtime spec, since it is the only one keeping its image source files in LibreOffice file formats.
Two possibilities:
(a) As Ryan asks, we could check in the generated files actually used by the AsciiDoc->PDF/HTML process, and document in a README how to update them if/when LibreOffice image files are updated.
(b) We could also leave things as is, and change the README in this repo to mention that in addition to running the install-asciidoctor-linux.sh script, you must also install LibreOffice, e.g. with sudo apt-get install libreoffice on Ubuntu Linux systems.

I am the originator of this LibreOffice workflow. In those ancient days of yore, there was a lack of open-source drawing tools and I had as a goal to store image sources vs. binary blobs (.PNGs) which was a problem then (and still is in some circles).
Since then, editable SVGs (or editable PNG) and draw.io have become almost the norm. I can think of two solutions to retire the from our workflow:

If we can export the .odg files under assets to editable .svg would they be directly usable in ASCIIDOC w/o rerendering? (Is exporting to SVG possible in LibreOffice?)
Export the .odgs as .png and store them as bitmaps. The diagrams haven't changed sine they were created, 4-6 years ago! In the unlikely case that something needs to be redrawn, someone can do it in draw.io or any other tool of choice and save as .svg.

An alternative to checking in the .png / .svg files would be to leave only the .odg files checked in, and enhance the README of this repo to mention that one must install LibreOffice when they want to generate PDF/HTML from AsciiDoc sources. What do you think of that approach?

Why "one must install LibreOffice when they want to generate PDF/HTML from AsciiDoc sources?" Can't you use the docker image? As I understand it, you need LibreOffice to create/edit the drawings, and that requires one to install it locally.

If you want to have a local Ubuntu Linux development system, and not use the Docker image, then you would need to install LibreOffice.  Sorry, reaching for Docker containers still isn't my first thought :-).  I like to provide README instructions when possible that show how to do things without the Docker containers.

@jafingerhut Got it, that makes perfect sense to me. We should cater to a variety of workflows and environments. I am so used to dockerizing things so they can run in CI pipelines, plus I try hard to not impose on machine's configuration (other than installing docker). Thanks for reminding me to leave the users a choice!

@jafingerhut Got it, that makes perfect sense to me. We should cater to a variety of workflows and environments. I am so used to dockerizing things so they can run in CI pipelines, plus I try hard to not impose on machine's configuration (other than installing docker). Thanks for reminding me to leave the users a choice!

So Chris, is it true that you would prefer if this PR:
(a) does not add .svg / .png files, and
(b) does modify the README to give instructions on either using the Docker container, or to use install-asciidoctor-linux.sh and also to install LibreOffice if you prefer not using the Docker container.
?

@jafingerhut Got it, that makes perfect sense to me. We should cater to a variety of workflows and environments. I am so used to dockerizing things so they can run in CI pipelines, plus I try hard to not impose on machine's configuration (other than installing docker). Thanks for reminding me to leave the users a choice!

So Chris, is it true that you would prefer if this PR:
(a) does not add .svg / .png files, and (b) does modify the README to give instructions on either using the Docker container, or to use install-asciidoctor-linux.sh and also to install LibreOffice if you prefer not using the Docker container.
?

yes to both. Just to clarify - we don't need to add .svg and .png rendered files because the toolchain generates them on-the-fly. Storing them just creates room for confusion IMO.

@jafingerhut Got it, that makes perfect sense to me. We should cater to a variety of workflows and environments. I am so used to dockerizing things so they can run in CI pipelines, plus I try hard to not impose on machine's configuration (other than installing docker). Thanks for reminding me to leave the users a choice!

So Chris, is it true that you would prefer if this PR:
(a) does not add .svg / .png files, and (b) does modify the README to give instructions on either using the Docker container, or to use install-asciidoctor-linux.sh and also to install LibreOffice if you prefer not using the Docker container.
?

yes to both. Just to clarify - we don't need to add .svg and .png rendered files because the toolchain generates them on-the-fly. Storing them just creates room for confusion IMO.

@Dscano It would be nice to make the indicated changes to this PR based on Chris's feedback above.

@chrispsommers @smolkaj As far as I know, this is ready to merge, if you approve.  Davide made the changes suggested by Chris where we do NOT add the generated .svg/.png files, but instead continue to require the user to have LibreOffice installed to generate them.
I do not know why the CI job named "build protobufs / build (pull_request)" is failing.  I made a test PR that only modifies whitespace in the top level README.md file, and it fails that CI test in a similar way, so this PR does not seem to be affecting the outcome of that test: https://github.com/p4lang/p4runtime/pull/512

@chrispsommers @smolkaj Davide Scano has gotten this to a point where I think it is ready to merge in. It might need some testing/tweaking for where it auto-generates the PDF and HTML files on each commit, so that they are visible in the "working draft" links on the P4.org web site Specifications page, but that seems best to fix up in a later PR if needed.
If you want to see the generated PDF and HTML files, I encourage you to check out this PR's changes locally and follow the README instructions for installing AsciiDoc tools and running make in the docs/v1 directory. Or if you prefer to see PDF and HTML generated for you, you can find them here:
https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files

https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files

The bullets don't look like that when I view the PDF in any of these ways:

in the Google Chrome browser on a macOS system, on github.com
local PDF file viewed in Preview app on a macOS system.
local PDF file viewed with the Evince Document Viewer started by the command xdg-open P4Runtime-spec.pdf on an Ubuntu 24.04 Linux system

How did you view the PDF file that makes the bullets look like that?

General comment - it looks fantastic, even better than the previous Madoko specs IMO. The overall appearance is much more modern. The HTML ToC on the left sidebar is awesome. I've found a few nits here and there which shouldn't block this from approval, but it would be nice to preserve all pending feedback somewhere, perhaps in a new issue or some other reasonable method. Thanks to @Dscano and @jafingerhut for their significant efforts on this. I left some specific comments inline, below are some general ones.
Minor stuff:

The #, \and > symbols in "code" blocks are getting weird red-brown highlighting
Nested bullets sometimes use the same symbol for each level (PDF) - HTML looks like expected
HTML rendering of inline code is rather distracting - text is smaller with a rounded border and shading. I think a simple font/color change, like the PDF rendering, would be easier to read.

https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files

The bullets don't look like that when I view the PDF in any of these ways:

in the Google Chrome browser on a macOS system, on github.com
local PDF file viewed in Preview app on a macOS system.
local PDF file viewed with the Evince Document Viewer started by the command xdg-open P4Runtime-spec.pdf on an Ubuntu 24.04 Linux system

How did you view the PDF file that makes the bullets look like that?

Downloaded the PDF into a Windows machine and viewed with Chrome:

https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files

The bullets don't look like that when I view the PDF in any of these ways:

in the Google Chrome browser on a macOS system, on github.com
local PDF file viewed in Preview app on a macOS system.
local PDF file viewed with the Evince Document Viewer started by the command xdg-open P4Runtime-spec.pdf on an Ubuntu 24.04 Linux system

How did you view the PDF file that makes the bullets look like that?

Downloaded the PDF into a Windows machine and viewed with Chrome:

Sorry for crossing conversations here -- I was replying to Steffen's comment showing a screen shot where the top level bullets seemed to be much further left than what you showed.
I agree it is not ideal that all levels of bullets use the same symbol as the bullet.  This was a workaround for an earlier problem we encountered where if we tried to use different symbols, the font we were using did not have the appropriate level 2 and level 3 nested bullet characters in the font's table, and it used empty rectangles for them, which looks worse than using the same character for all levels of nesting (in my opinion).
Achieving different symbols for different levels of bullet nesting would require either using a different font with those symbols defined properly, or editing the font file we have to define those symbols with reasonable shapes.

@chrispsommers @smolkaj @jafingerhut Thank you for the comments. I will address them as soon as possible.

@chrispsommers @smolkaj @jafingerhut Thank you for the comments. I will address them as soon as possible.

And if you are willing to merge this in before the list of things you have pointed out have been changed, Davide and I can use the comments on this PR (even after it is closed, linked from a new open issue), to track the comments you have made on this PR.

@chrispsommers @smolkaj @jafingerhut Thank you for the comments. I will address them as soon as possible.

And if you are willing to merge this in before the list of things you have pointed out have been changed, Davide and I can use the comments on this PR (even after it is closed, linked from a new open issue), to track the comments you have made on this PR.

@smolkaj I'm OK with merging now and following up with the minor issues as time allows; wdyt?

I believe I have captured all of the net-yet-resolved comments on this PR in their own separate issues on this repo.  All of them have had the new label "asciidoc-issue" added to them.

I believe I have captured all of the net-yet-resolved comments on this PR in their own separate issues on this repo. All of them have had the new label "asciidoc-issue" added to them.

Thanks, I saw that. Waiting for @smolkaj 's opinion, I'm ready to merge if he is.

I had to update the Dockerfile.asciidoc because the previous version was not working correctly.

I have resolved the issues:

https://github.com/p4lang/p4runtime/issues/528
https://github.com/p4lang/p4runtime/issues/529

I have proposed a solution for issue  https://github.com/p4lang/p4runtime/issues/525

I have resolved the issues:

Use correct Asciidoc markup for em-dashes #528
Fix incorrect markup for creating links in Asciidoc output #529

I have proposed a solution for issue #525

I have regenerated the PDF and HTML files for the latest version of AsciiDoc input files on this PR as of 2024-Dec-24, with the commits Davide mentions above, and put them in the same place I put earlier versions, here: https://github.com/jafingerhut/learn-asciidoc/tree/main/p4runtime-spec-next/sample-generates-files
I spot-checked the fixes for the em-dashes and the correct link, and they both look good to me.  Thanks.


Use dotenv instead of env vars in webpack config

Use dotenv and provide only a .env.example file instead of setting everything on each webpack config file.
Something like https://github.com/lucasbento/react-relay-pokemon/blob/master/webpack.prod.config.js#L29 which is using dotenv-webpack.

Hey Lucas! Thanks for this suggestion. Is this based on you having a problem getting learnrelay up and running locally or rather in order to have a "better" tooling setup?

Hey @schickling, thanks for your quick response.
It's actually to have a better tooling setup, environment variables should probably not be available for users since GitHub Client ID, Segment Token, etc only belong to this project and/or graphqlcool's, and presumably should not be used by others.

I totally see your point! That's why we've created a dev stage for both __GITHUB_OAUTH_CLIENT_ID__ and __LAMBDA_AUTH__ which is preconfigured for convenience when running npm start.
I guess it's a good thing to keep the number of dependencies and additional tools to a minimum. If it add a lot of value in terms of DX I'd be happy though to merge it in.

Humm, I see.
Keeping the number of dependencies to a minimum definitely makes sense, I think we can close this issue then. :)

Thanks a lot for your insights and involvement though @lucasbento! 😊


Automate pushing build artifacts to open-match.dev

Like agones we have artifacts that can be served at well known places.

Kubernetes configs.
Helm chart repository
API Swagger docs.

Proposed URLs (base file for each)

Kubernetes Configs - http://open-match.dev/install/{version}/install.yaml
Helm Repostory - http://open-match.dev/chart/{version}/helm/Chart.yaml (or whatever hub.helm.sh requires the structure to be)
API Swagger docs - http://open-match.dev/api/{version}/frontend.swagger.json

https://github.com/GoogleCloudPlatform/open-match/pull/370 resolves this with the exception of Helm. That broke but it's more complicated and we should deal with that when we start serving a helm repository.


Feature users api

Description of the Change

Users API was created
Verification Process

On index page should appear a message on the console with all users and a specific user.
On index page should appear a button(Test addUser) to add a preset user.
Applicable Issues

N/A
Release Notes

N/A

I made changes to index to test API outputs but caused the checks (vercel and lint) to fail, so I reverted all changes to index
API works perfect

I think we can use squash merge to keep main branch clean of some revert commits.

Also for a future issue
TODO:
Add try/catch to have clear logs


POST API not calling on mobile [Chrome v72.0.*]

Problem

I have a login api /api/login/
It's a POST api
Format is following

{
	"username": "user",
	"password": "pass"
}

When I'm trying on web[Desktop/Laptop] browser it's working fine for me. But when I'm trying on PWA mode on my phone[Chrome 72.0.3625.105] version. Then, it's not calling the API. I have tested so many ways. I found everything is working except the POST API call.
I have written code like following,
loginSubmit() {
	fetch('http://my-server.com/api/login/', {
		method: 'POST',
		headers: {
		  'Content-Type': 'application/json'
		},
		body: JSON.stringify(this.formData)
	}).then((response) => {
		return response.json()
	}).then((data) => {
		console.log(data)
		alert(data.success)
	})
}

Please let me know if I'm doing any mistakes
UPDATE It says network error. But I have active internet connection

I found the issue. It was related to my wifi router and localhost.


Update README.md

Added new category with 2 links

name: feat: New category with 2 link
about: Inspo for people when thinking about new projects or
labels: feature

Describe the awesome thing you want to add
What is it?
What category does it belong to? (Libs and Components, Apps, Ports, Design System, Boilerplates/Templates)
Anything else? (optional) (e.g. screenshots, additional information, etc.)
Checklist

[x] I checked that it is in alphabetical order.
[x] I have checked that the awesome thing is not already listed.
[x] I have provided a clear and concise description of the awesome thing.
[x] I have provided a link to the awesome thing.
[x] I have assigned the correct category to the awesome thing.

Please note: If you are adding a new category, you will need to create a new section in the README.md file. Please make sure to update the table of contents as well.
Important: The idea of this repository is to bring together free projects for open-source contributions. If the proposed addition is an entirely paid project, the PR will be closed.

Added new category with 2 links
name: feat: New category with 2 link
about: Inspo for people when thinking about new projects or
labels: feature
Describe the awesome thing you want to add
What is it?
What category does it belong to? (Libs and Components, Apps, Ports, Design System, Boilerplates/Templates)
Anything else? (optional) (e.g. screenshots, additional information, etc.)
Checklist

[x]  I checked that it is in alphabetical order.
[x]  I have checked that the awesome thing is not already listed.
[x]  I have provided a clear and concise description of the awesome thing.
[x]  I have provided a link to the awesome thing.
[x]  I have assigned the correct category to the awesome thing.

Please note: If you are adding a new category, you will need to create a new section in the README.md file. Please make sure to update the table of contents as well.
Important: The idea of this repository is to bring together free projects for open-source contributions. If the proposed addition is an entirely paid project, the PR will be closed.

What do you think about creating a Websites and Porfolios Inspiration section? I think it would be better instead of Project & Portfolio Inspiration.

I agree with that. It sounds more better

I agree with that. It sounds more better. I made new commit for change title

Maybe if we separated it into two sections it would be even better:
Websites and Portfolio Inspirations:
Websites:

godly - Astronomically good web design inspiration. Only the best of the best.
list.swajp.me - It has never been easier to find the right projects or designs by inspiring sucessful people.

Portfolios:

birobirobiro.dev

Thats even better and less confusing! Can you add this to this PR or do I have to?

Thats even better and less confusing! Can you add this to this PR or do I have to?

You can make this change and then merge it, as in the suggested example.

Done. I also added my portfolio


fix default value pageSize

The "account/query" method didn't work, the error was "$pageSize should not be available before initialization in the file"
Add default value pageSize and fixe validate rule limit

Hi @lewrq, thanks for your submission.
Your changes to AccountQuery defeat API limit enforcement. It is sufficient to initialize pageSize in LedgerRules. Feel free to resubmit this patch with an initial page limit of 25.

fixed default pageSize to 25

Merged. Thanks!


Changelist selection

Hey!
It would be really-really useful if we could select a changelist, or set a default changelist where deleted/edited files go
Thank you very much!

Now supported. Please update to version 2.0.0

I don't really get how can I select a default changelist for checked in files. Can you help me with this please? :)

Sorry, I misunderstood your request.
The extension currently follow the same behavior as P4V, which mean all newly added/edited files go to the default changelist, where you can then moved them to other changelist, or create a new one.

this feature would still be of use: select a named changelist which checked out files will be automatically added to (with the changelist itself automatically created if it doesn't exist)
alternatively, the ability to submit the default changelist would be even better. the workflow currently requires changing a file, manually creating a new changelist, manually moving those files to the new changelist, and submitting the new changelist. for fast iterative changes, the ability so simply submit the default changelist would incredibly useful.
let me know if this doesn't fall within this feature request, and I'll write a new one.

If you can create a separate issue for the "Submit Default Changelist" feature that would be awesome.
Probably try and get it to mimic P4V behavior where you enter a name for the CL.

Feature request submitted: #72

there should be a way to select a CL and every edited file goes to that CL something similar to what Intellij does where i can mark any one given CL as "active".


Escape should close modal dialogs

I click the 'Add new slide' button, and the template selector shows. I should be able to press the escape key, and it should do the same action as hitting the close button.
This should likely be a generic action across all modals unless the focus is in a text box or some other element (not sure what the entire list would be).

There is a bug where if you are focused on an input, and press escape, it doesn't blur/revert the input, it closes the panel. If an input is focused, it should blur/revert/clear it. After it's blurred and there is no input focus, it should close the panel.
This happens on the publish panel, glossary, resources, etc....

This is still not working properly. When escape is pressed when in an input field, it should revert it and blur it. then a second escape would close the panel.


Fixed #28075 -- Prevented ChoiceWidget from localizing option values.

https://code.djangoproject.com/ticket/28075

I'm uncertain about the need to test all subclasses of ChoiceWidget but this might be considered later with a mixin so that these don't have to repeated several times.

Just to clarify, the reason I wrote the tests for all subclasses is that my first fix only fixed the Select widget. Once I considered all ChoiceWidgets would be affected, I wrote a 2nd test to demonstrate to myself that the first fix was incomplete. For that reason, I found multiple tests useful.

Thanks for the reviews. I have made the suggested changes.


How can I add user to a group?

I would like to add/remove LDAP users from an LDAP group, via ldapdb. I can't find any documentation around this. Is it possible?

Why do you think this operation should not be possible?
I somehow feel you have not read what ldapdb is ☺.

@kwill use memberof overlay and write to its OU, you should get operation attributes with memberOf as a list

I, for one, would simply add the user DN to the member attribute of the group…


Webview window makes error bell sound when using keybinds on MacOS 13.3.1

Versions
NVIM 0.10.0-dev-120+gdd8781128-Homebrew
deno 1.32.5
macOS 13.3.1

seem here

Possibly fixed by 3f7366f.

Seems to have done the trick, thanks!