update command

Should work as follows:

by default, gather new images only for missing states
if passed --force flag, update all images.

gather should be deprecated after this command is implemented.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2715589-update-command?utm_campaign=plugin&utm_content=tracker%2F467695&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F467695&utm_medium=issues&utm_source=github).

No need for this command, GUI solves all the problems which we intended to solve with it.

Would it be possible to include programatic hooks for this functionality? I'm looking to create a gulp task to interface with gemini, and adding/updating reference shots seems to be a challenge currently.

@SevInf any thoughts on this? I would be glad to work on the enhancement

@fenduru sorry, I'm no longer leading this project, better ask @SwinX or @sipayRT

@fenduru why don't you use gather command for your task? Can you provide more details?

@sipayRT the only problem I have with gather is that it re-creates the images. I want to be able to run the tests, see the diff, and if the diff looks correct then accept the new image. But currently I have to run the tests, see the diff, then re-generate the images with gather.
In a perfect world, all of these tests would be deterministic, so re-generating the image wouldn't concern me. However, we occasionally run into issues where an element accidentally has hover styling applied, etc, and I wouldn't want to accidentally commit incorrect images to our git repo.
The gemini-gui project looks like it has some of this functionality, however my typical workflow will be to run the tests through gulp, and then look at/accept changed images after that. Running a long-lived server does not fit nicely into my build system.
It seems that currently Gemini doesn't actually save any of the test result images to disk, but if it did, I think it would be nice to have an additional command called accept that would replace reference images that have changed. For instance:
$ gemini gather
$ git commit -am "save reference images"
$ gemini test
test passes
$ vim my-component.css
$ gemini test
test fails, inspect the diff on the HTML reporter
$ gemini accept
$ git commit -am "update changed images"

what should we do when part of fallen tests would be incorrect? For example, because of grid troubles.

I would expect the person running the tests to verify that all of the images are correct by viewing the HTML report before running the accept command. Personally I would never accept new images if the test run didn't complete without problems, but perhaps it would be useful to support the --grep option here too.

@j0tunn can you show your script here?

#!/bin/bash

find gemini-report/images/ | grep ~diff.png | while read -r f
do
    dir=`dirname "$f" | sed 's;gemini-report/images/;;g'`
    browser=`basename "$f" | sed 's;~diff.png;;g'`
    cp "gemini-report/images${dir}/${browser}~current.png" "gemini/screens${dir}/${browser}.png"
done

I haven't tried running this script yet, but it looks like the behavior I'm looking for. The problem I see with having a script like that though is that it is coupled with the reporter, which could very reasonably change the way it is structured (since its job is reporting).
How would you feel about having a gemini/screens/reference folder containing the accepted images, and a gemini/screens/pending folder containing any failed images? This would make implementing an accept command (or something similar).

Thinking about this a bit more, and I think my complaint is really that gather is overloaded for both new tests, as well as changed tests.
I think that if an accept command is created, that gather should only gather test with no existing references, and the only way to change existing references is by running test followed by accept (or, of course, by deleting the reference images).

The main thing is that you should look at new screenshots before accepting them, so it is all about reporting images. That is not the gemini's job to store images somewhere between launches. It just launches tests and gives you result. Thats it.
For the purpose of convenient updating images we've created gemini-gui.
If for some reason you can't use gemini-gui you can use the script I've posted earlier. It's a simple 6-line script, I don't think its a big deal to adopt it in case of some html-reporter (unlikely) breaking change.
And off course there is always another option for you: plugin. I can think of custom reporter that stores the images somewhere and creates the update script based on paths from gemini config. Launch that script after gemini test and boom! The job is done.

In the short term I can use that script, but I still don't think this is correct. Based off of what you are saying, then gemini gather should be deprecated, since it is not gemini's job to store the results between launches, and this logic should instead be handled by the reporter + script.
The difference between gemini and more typical test runners is that you NEED a reference image in order for the system to work. Creating and updating these reference images is integral to the system, so it seems strange to me that you'd rather this be handled outside of the system.

gather isn't quite what I need even when I want to add new tests. The problem is that it not only generates images for new tests, but it also replaces existing reference images for failing tests (without letting you see the changes).
I could work around this, but there is no way to generate new reference images without using gather because of this line.
So when I add a new test and need to generate an image, I have to just hope that nothing else changed when I run gather

You are speaking of two different cases:

gather images for new tests
accept new reference images

The first case is ok. I agree that it would be nice to be able to gather reference image only for test without one. Although I don't see the problem to do git checkout -- on existing images.
For the second case we have gemini-gui.

Summary of my issue

gather will generate new images for both existing tests AND new tests without a way of choosing between them
gather results do not appear in the HTML reporter, so I have no way of verifying changes to existing images (and no easy way to verify that brand new images are correct)
gemini-gui requires re-running all of the tests rather than just accepting the failures from the previous test run

My workflow is to make a code change, then run my test suites (image, unit, etc. tests), repeat.

Proposed changes

test runs all tests, even if no reference image exists.

Naturally new tests will fail, but I feel this is correct behavior - I've added a test and its result does not match the reference (since the reference doesn't exist).

HTML reporter shows new images

What I will do after those changes are made

Write a reporter that handles saving the previous test-run's images, and gives me the ability to write an update command on my own, outside of Gemini.
I will never run gather, since I don't want to update the screens folder until I've reviewed the changes

test runs all tests, even if no reference image exists.

Looks like current behaviour. No?

HTML reporter shows new images

Why not? LGTM

So I dug into the code a bit more, and it turns out that my proposed changes already exist - I just needed to set referenceImageAbsence to warning doh
I still very much think that without a complete story for creating and updating reference images after verification, that Gemini is lacking. That said, I should be able to add the features on my own via a plugin or reporter.

From our experience referenceImageAbsence: warning is a bad practice. With this setting tests without reference will always pass, and you can miss them. We are thinking on deprecating this feature.

@j0tunn I agree that an error would be better, however currently the only way I can see to get access to the generated image from a reporter is via the warning event.
How would you feel about tweaking this code to always fire an event - maybe a noReferenceImage event? Or perhaps have the endTest event always contain the full information, regardless of success/failure, reference images, etc.

@fenduru endTest now will fire only after test complete with result. If you do not have reference, it will not fire.
In general we may think about passing some additional info to the events.

Right now I have a local modifciation that additionally passes the referencePath to the warning event. Obviously this is not desirable.
What I need is an event that fires for every failing test (with or without a reference images) that contains the currentPath, and the referencePath (which might not exist on disk, but I need to know where I should eventually copy the generated image to).
I'd like to file a PR for this, but would like your input on which event (existing event? new event?) you would want this on.


[Timestampable] After vendor's update. Does not work with xml

After update to newer version of Doctrine\Symfony I have timestampable definition not working
it affects only xml but still works fine for annotations(I have both annotations\xml).
Actually it does not fill creationTime field so I am getting the error:
[PDOException]
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'creation_time' cannot be null

The xml mapping:
<?xml version="1.0" encoding="UTF-8"?>

<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:gedmo="http://gediminasm.org/schemas/orm/doctrine-extensions-mapping"
      xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                    https://github.com/doctrine/doctrine2/raw/master/doctrine-mapping.xsd">

    <entity name="Rj\PaymentBundle\Entity\ProductDefinition" repository-class="Rj\PaymentBundle\Entity\ProductDefinitionRepository" table="payment_product_definitions">
        <id name="id" type="integer"><generator strategy="AUTO" /></id>
        <field name="title" column="title" type="string" />
        <field name="description" column="description" type="string" />
        <field name="price" column="price" type="decimal" scale="5" />
        <field name="currency" column="currency" type="currency" />
        <field name="department" column="department" type="string" />
        <field name="department_specific_id" column="department_specific_id" type="string" nullable="true"/>
        <field name="creation_time" column="creation_time" type="datetime">
            <gedmo:timestampable on="create" />
        </field>

        <one-to-many field="invoice_products" mapped-by="definition" target-entity="InvoiceProduct">
            <cascade>
                <cascade-remove/>
                <cascade-refresh/>
            </cascade>
        </one-to-many>
    </entity>

</doctrine-mapping>

Vendors:
doctrine (2.1.0-190-g4a920d0)
l3pp4rd/DoctrineExtensions (2.1.x)
symfony (v2.0.4-502-gb876412)

This relates to:
https://github.com/l3pp4rd/DoctrineExtensions/issues/180 /
https://github.com/l3pp4rd/DoctrineExtensions/issues/181
Temporary fix can be found:
https://github.com/arnaud-lb/DoctrineExtensions/commit/f253f4c28acb8e02e2e17ddfc6b7c1cc810c4b06


When a large number of plugins are set, the left sidebar of the designer overflows.

Describe the bug

To Reproduce
Set a large number of plugins to the designer
Expected behavior
Make it scrollable
Your Environment
- pdfme package(@pdfme/generator or @pdfme/ui): @pdfme/ui
- pdfme version: latest
- Operating system: mac
- Node.js version or Browser name & version: latest chrome

Your Error Log
none

Additional context
No response

I'm sorry. I forgot to check who was assigned to the issue....


Update XCFramework logic

This hardcoded platform and architectures before, make it more generic to handle macOS on arm64.

@swift-ci please smoke test


Inferential replicates and .pq file creation

Hello !
I am new to these kind of analyses and have been running oarfish (v.0.6.2) with the following parameters/options:
--single-cell, --alignments, --model-coverage and --num-bootstraps. I wanted to generate the .pq file for follow-up analyses, but it does not get generated. I tried setting --num-bootstraps to 30 and to 100, but no .pq file was created. I also tried with and without specifying --threads but still no luck...
Can you help me solve this issue?
Thank you so much!
Kind regards

Hi @margaux-david,
Thanks for raising this issue. Right now, inferential replicates are only output in bulk RNA seq quantification mode. While it would certainly be possible to provide this information in single cell, I'm not aware of any tool that can actually take advantage of this information (i.e. full inferential replicates for single-cell analysis). I'm curious what your target analysis and proposed pipeline are.
Best,
Rob

Hi 😊
Thank you for this quick reply. We wanted to use the oarfish output as input for EdgeR, using a ‘customized’ version of the catchSalmon function.
The data will be pseudobulked for some of the analyses, so running oarfish without the ‘—single-cell’ option may be an option in this case?
Kind regards,
Margaux
From: Rob Patro @.>
Sent: 14 October 2024 16:13
To: COMBINE-lab/oarfish @.>
Cc: Margaux David @.>; Mention @.>
Subject: Re: [COMBINE-lab/oarfish] Inferential replicates and .pq file creation (Issue #34)
Hi @margaux-davidhttps://github.com/margaux-david,
Thanks for raising this issue. Right now, inferential replicates are only output in bulk RNA seq quantification mode. While it would certainly be possible to provide this information in single cell, I'm not aware of any tool that can actually take advantage of this information (i.e. full inferential replicates for single-cell analysis). I'm curious what your target analysis and proposed pipeline are.
Best,
Rob
—
Reply to this email directly, view it on GitHubhttps://github.com/COMBINE-lab/oarfish/issues/34#issuecomment-2411391433, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMDBVVJGMQGSEIKTBIMRNJTZ3PGQHAVCNFSM6AAAAABP47STH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGM4TCNBTGM.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/COMBINE-lab/oarfish/issues/34#issuecomment-2411391433", "url": "https://github.com/COMBINE-lab/oarfish/issues/34#issuecomment-2411391433", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]


MerklePathSet is using irregular path

The MerklePath structure assumes the input node is an argument of the verification
https://github.com/0xPolygonMiden/crypto/blob/6bd6b9e7ceda0af8892eac2cd8b73783dcbda27d/src/merkle/path.rs#L25-L39
But MerklePathSet injects the input node as the first element of the path
https://github.com/0xPolygonMiden/crypto/blob/66da469ec49a7a4a72631a8b553ba3470d0173fa/src/merkle/merkle_path_set.rs#L33-L64
And, when queried, it will remove it
https://github.com/0xPolygonMiden/crypto/blob/66da469ec49a7a4a72631a8b553ba3470d0173fa/src/merkle/merkle_path_set.rs#L118-L119
It should probably store the path only with the siblings, having a different strategy to store the leaf node, if required
After this refactor is done, MerklePathSet should consume the MerklePath functions to compute roots and verify openings.
https://github.com/0xPolygonMiden/crypto/pull/53#discussion_r1104479230

This is kind of intended behavior since each path actually stores both leaves.


Rollback transactions in after_commit blocks

If there is an exception in a transaction that occurs in after_commit block, we need to call ROLLBACK otherwise the connection will be unusable

Nice find :+1:


Airy CLI sha changes after the release

We update the homebrew formula with this https://airy-core-binaries.s3.amazonaws.com/0.13.0/darwin/amd64/airy_darwin_sha256sum.txt
during the release but for some reason that file has changed 3 hours after the release..

hopefully closed with #1443


Please add toggle for HitObject Combo Numbers

My skin doesn't use numbers at all and would be nice to have the option in Rewind.

Can you provide me more info on your skin? Do the number files (e.g. default-0.png) exist or are they just 1x1 empty images?
If you could provide me your skin, that would be very helpful.

Sorry for forgetting about this but I literally just have the directory for hitcircleprefix set to none in skin.ini


Throw error if there is a metadata for a symbol, but it's not available at runtime

I want to merge this in the release branch, if possible. The QAs are fine with that.

:+1: after build succeeds.

The build is failing with:
2015-10-05 04:27:08.640 xcodebuild[70584:1007] [MT] iPhoneSimulator: SimVerifier returned: Error Domain=NSPOSIXErrorDomain Code=53 "Simulator verification failed." UserInfo=0x7fde9d5046c0 {NSLocalizedFailureReason=A connection to the simulator verification service could not be established., NSLocalizedRecoverySuggestion=Ensure that Xcode.app is installed on a volume with ownership enabled., NSLocalizedDescription=Simulator verification failed.}

which is irrelevant to this PR.

Why did you choose to throw TypeError? I think ReferenceError is more appropriate, although to be frank I'm not sure there is a widespread practice of instanceof-ing error objects anyway.
This change won't affect cases when we know the symbol shouldn't be there because of availability, right?

@fealebenpae This change won't affect symbols which exist in metadata but are not exposed because of availability. These symbols hiding is handled on metadata API level, so Metadata::MetaFile::instance()->globalTable()->findMeta(symbolName) will never return such symbol.

@fealebenpae Changed it to ReferenceError. I was too used to TypeLoadException :D


Godot fails to cross-compile to Windows using MinGW, target=debug and use_lto=yes

Godot version:
3.4-beta e9909b763af
OS/device including version:
Fedora 34 host.
GCC/x86_64-w64-mingw32/10.3.1
Issue description:
[100%] Linking Program        ==> bin/godot.windows.tools.64.exe
/usr/lib/gcc/x86_64-w64-mingw32/10.3.1/../../../../x86_64-w64-mingw32/bin/ld: btAlignedAllocator.windows.tools.64.o (symbol from plugin): warning: no symbol for section '_Z14btAlignPointerIcEPT_S1_y' found
lto1: error: two or more sections for .gnu.lto__ZN4ListIPN9Octree_CLIN17VisualServerScene8InstanceELb1E16DefaultAllocatorE8PairDataES3_E5clearEv.9678572.e6925aa0daa7c15
(null):0: confused by earlier errors, bailing out
make: *** [/tmp/cchKQabt.mk:17: /tmp/godot.windows.tools.64.exe.s4Jwiu.ltrans5.ltrans.o] Error 1
make: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-w64-mingw32/10.3.1/../../../../x86_64-w64-mingw32/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.windows.tools.64.exe] Error 1
scons: building terminated because of errors.

Not sure if this should/can be supported, but the error is here. The use case is to debug issues caused by LTO, see goostengine/goost#83 (which seems to be jpgd issue).
Steps to reproduce:
scons platform=windows target=debug use_lto=yes debug_symbols=yes bits=64

debug_symbols=yes likely not needed but that's what I used while compiling.
Minimal reproduction project:
N/A

I can confirm the issue on Mageia 8 with:
mingw64-binutils-2.34-2.mga8
mingw64-gcc-10.2.1-2.mga8
mingw64-headers-8.0.0-1.mga8

For the reference, I tried with the bullet module disabled (as the error references a bullet struct), but that just moves the issue someplace else:
lto1: error: two or more sections for .gnu.lto__ZN3MapIN18CanvasItemMaterial11MaterialKeyENS0_10ShaderDataE10ComparatorIS1_E16DefaultAllocatorE5_Data10_free_rootEv.7524010.3187f6e5341ddf31

This is also a problem for a native debug LTO MinGW Windows build of 3.2.2

Still valid in 3.5-beta. I stumbled upon this by accident again when I forgot to specify target when using production=yes.

Still valid in 3.4.2 release. When use_mingw=yes target=release_debug use_lto=yes

@Atem1995 What error are you having exactly, on what OS, and with what mingw versions?
This error is about target=debug, not release_debug. Building target=debug with LTO is not really useful and unsupported, and what this issue is about (finding a fix would still be good, but there's not much reason to do such a build).

@akien-mga I tried to compile the source code for the 3.4.2 release In window 10. Use x86_64-w64-mingw32-gcc 11.2.0. Command is “Scons -j 12 platform= Windows bits=64 Tools =yes USe_mingw =yes Target = release_DEBUG USe_LTO =yes”. It took a long time in the final phase, and then ultimately no executable was generated. I did it with reference to official documentation, which could have been generated without using mingw.

Thanks, that confirms that it's not the same issue. For this issue you should see an error like the one described in the first post: warning: no symbol for section '_Z14btAlignPointerIcEPT_S1_y' found.
In your case, is there really no error in the terminal?
It's normal that it takes a very long time to link with LTO, it can easily take 30 min or more. But ultimately it should finish with scons: done building targets and you should have a binary in the bin folder. If it doesn't do that, then most likely there was an error printed in the terminal.

@akien-mga Thank you for your attention to my problems. Please wait a moment, I just tried compiling again and am waiting for the result or error. News will be posted.

Besides the warnings, this is the error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: i386 architecture of input file `platform\\windows\\godot_res.windows.opt.tools.64.o' is incompatible with i386:x86-64 output
collect2.exe: error: ld returned 1 exit status\n"

That seems to be the same issue as #40286, we should continue the discussion there.

I don't know if it's worth creating a new issue, but if compiled with the flags optimize=size use_lto=yes i got errors like:
/usr/lib/gcc/i686-w64-mingw32/10.3.1/../../../../i686-w64-mingw32/bin/ld: /tmp/godot.windows.opt.32.exe.XFme3F.ltrans127.ltrans.o:<artificial>:(.text+0x3343f): undefined reference to `GDScriptParser::DataType::DataType() [clone .lto_priv.1] [clone .lto_priv.0]'
/usr/lib/gcc/i686-w64-mingw32/10.3.1/../../../../i686-w64-mingw32/bin/ld: /tmp/godot.windows.opt.32.exe.XFme3F.ltrans127.ltrans.o:<artificial>:(.text+0x334e2): undefined reference to `GDScriptParser::DataType::DataType() [clone .lto_priv.1] [clone .lto_priv.0]'
/usr/lib/gcc/i686-w64-mingw32/10.3.1/../../../../i686-w64-mingw32/bin/ld: /tmp/godot.windows.opt.32.exe.XFme3F.ltrans127.ltrans.o:<artificial>:(.text+0x335ec): undefined reference to `GDScriptParser::DataType::DataType() [clone .lto_priv.1] [clone .lto_priv.0]'
/usr/lib/gcc/i686-w64-mingw32/10.3.1/../../../../i686-w64-mingw32/bin/ld: /tmp/godot.windows.opt.32.exe.XFme3F.ltrans127.ltrans.o:<artificial>:(.text+0x33b67): undefined reference to `Ref<GDScript>::Ref<Script>(Ref<Script> const&) [clone .lto_priv.1] [clone .lto_priv.0]'
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.windows.opt.32.exe] Error 1
scons: building terminated because of errors.

Full flags:  scons -j4 platform=windows use_mingw=yes target=release bits=32 tools=no production=yes verbose=yes warnings=no progress=no optimize=size
Compiled in Docker with Fedora 34, GCC/x86_64-w64-mingw32/10.3.1, Godot 3.4.4
Is this a documentation issue of the incompatible optimise=size and use_lto=True flags with mingw, or is this a bug?

I'll close this as wontfix, as I don't think it's fixable. GCC LTO just isn't capable of dealing with too large objects, which they inevitably are when debug symbols are enabled (hundreds of MBs for some).
It's also not a useful build configuration (LTO depends on doing optimizations, debugging depends on not doing optimizations), so aside from the theoretical wish for all build options to work, there's not much to gain here by trying to workaround GCC LTO bugs.


Demo website not working

The  Demo website is not working anymore.
@dsun9 you can see the demo website that hosted on Azure here http://freelancers-market.ml/
Originally posted by @m-elewa in https://github.com/m-elewa/freelancers-market/issues/3#issuecomment-626246839

@remissao the server is expired, I'll run the website on another server soon.

@remissao the server is expired, I'll run the website on another server soon.

Thanks!


Use case doc review comment (originally posted 13/5/19 by DFC)

Page 14. In the Figure 3, I was expecting to see inside Contacts::Address the GPS location, it is not there, same happened on Figure 4, and other documents like section 4.6.1 of the document APDS Information Model v2.0. Also in the table A.31 from the document Data Dictionary. the Lat Lon is described in section 4.7 of the “Information Model”, but I don’t see it in the figures that mention the address.

Jon - can you respond to this? There is no reference to point location on the diagrams.

Contact is associated with any element of the Place Hierarchy.  The Place Hierarchy element itself can have a point and/or area location (with GPS coordinates, actually strictly coordinate references in a specified coordinate referencing system, of which GPS (WGS84) is one).  Is there a business need to provide spatial location for specific contact roles?

Suggest this is raised as a question for public review.

MD - suggest we leave lat / lon for place hierarchy only.  Contacts have addresses, which if necessary can be used to "find the lcoation" of the contact

Moved to Phase III for inclusion in new documentation

I think it is correct to separate the concept of organisation (contact details) and any specifics of geography, but also perhaps (which would be a change - create a matrix relationship between a catalogue of organisational details and the roles that a data supplier ascribes to them (in the mode of what Transmodel does).
We should not hard code location references into the Contacts data structure itself.


elasticmq-server: 0.14.6 -> 0.15.7, add passthru.tests

Motivation for this change
Added quite a simple test to check basic operation of the queue.
Still, it's the first passthru.tests I've written, and I don't know whether e.g. detaching a process here is considered "ok". It feels a little less wrong than doing it in checkPhase.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@ofborg build elasticmq-server-bin elasticmq-server-bin.tests

@risicle please resolve the merge conflict.

@risicle please resolve the merge conflict.

@ofborg build elasticmq-server-bin elasticmq-server-bin.tests

@ofborg build elasticmq-server-bin elasticmq-server-bin.tests

Result of nixpkgs-review pr 97299 run on x86_64-linux 1

1 package built:

elasticmq-server-bin

@risicle perhaps now we should update to https://github.com/softwaremill/elasticmq/releases/tag/v1.2.0 ?

Totally forgot about this. Yes, perhaps.

Rebased, bumped, tests pass on nixos x86_64 and macos 10.15


Filter to expressed variants

In this PR:

Factored some of the df_isovar logic out of load_neoantigens into a separate _load_single_patient_isovar, to use it outside the neoantigen context.
Added _filter_variants_to_expressed to filter out any variant that isn't present in the isovar DataFrame.
Randomly made it into this branch: parameterizing variant_qc_filter.

@arahuja

Coverage decreased (-0.8%) to 58.344% when pulling 394dd61aaeb81757b46d04409e930d159641d0af on expressed_mutations into 5b1eaf6fc5e662ed2a5cb2e10b64c89ca06e4a81 on master.

My thoughts on this are I'm not sure it's worth building in the isovar filtering as special case to the load_* functions and leaving it as something to do after the fact or making a filter_fn that could handle it.

@arahuja curious why not?

We spoke offline; @arahuja clarified that the cohorts.varcode_utils functions are more general than I realized, so I can indeed plop this logic in there.

@arahuja I'm not entirely clear on the best way to do this, since my variant_expressed_filter and effect_expressed_filter need more than variant/effect and variant_metadata (the cohort, patient, variant_type, merge_type). I could put variant_expressed_filter inside a count function and make use of the closure, but that's not easily passed to load_variants.
Perhaps I should replace variant_metadata with heavier-weight object that has the VariantCollection metadata as well as cohort, patient, etc.?

Perhaps I should replace variant_metadata with heavier-weight object that has the VariantCollection metadata as well as cohort, patient, etc.?

Perhaps? I think needing cohort would be odd, but it somewhat shows that some of the load_single functions should probably be pushed into Patient

@arahuja I agree re pushing more functions to Patient; for another time, though :)

Coverage increased (+1.0%) to 60.171% when pulling 3e4d5f8ac5ff135d0f1a354d1f5337435bb31511 on expressed_mutations into 5b1eaf6fc5e662ed2a5cb2e10b64c89ca06e4a81 on master.

Coverage increased (+1.0%) to 60.171% when pulling 3e4d5f8ac5ff135d0f1a354d1f5337435bb31511 on expressed_mutations into 5b1eaf6fc5e662ed2a5cb2e10b64c89ca06e4a81 on master.

Coverage decreased (-0.5%) to 60.57% when pulling<PHONE_NUMBER>163d4aff8a1f7bca6f1425b58ea457 on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

Coverage decreased (-0.5%) to 60.57% when pulling 769a0a9b46d0590c687a19dfb30e55c268679d57 on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

12 days later, some updates to this PR:

Create FilterableVariant, FilterableEffect, etc. as a way to cleanly specify filter_fns as single-parameter functions. Also removes the need for neoantigen_qc_filter vs. variant_qc_filter since FilterableNeoantigen is a FilterableVariant.
Use the above to handle expression filtering instead of adding only_expressed everywhere.
Fix https://github.com/hammerlab/cohorts/issues/73.
Fix https://github.com/hammerlab/cohorts/issues/66.
Move merge_type and variant_type into Cohort so they aren't passed around to a million methods.
Add additional parameters to variant_qc_filter.

Back to you @arahuja

Coverage decreased (-0.5%) to 60.57% when pulling a0431883991372e1784142e907137d83053817dc on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

Coverage decreased (-0.4%) to 60.646% when pulling 709db27da1c5fa9073abf015c87300766725eded on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

Coverage decreased (-0.4%) to 60.621% when pulling 126bda4990ef88ff5186331aa29d3c728d17e171 on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

Coverage decreased (-0.4%) to 60.621% when pulling 777bf4d582984aa2ce415c53f8b9fa31f538e3e7 on expressed_mutations into fac5c92cb03ac87251b087272e45151ed692168f on master.

Coverage decreased (-0.5%) to 60.714% when pulling 946eab4d7c6318ace20bcff6f8a6fe2fff091a09 on expressed_mutations into e09195b928b3a28144d2be6ae5cf652d9fdb0257 on master.


Query Band Support

resolves #121
Description
This PR resolves the enhancement proposed for query band support in dbt-teradata for performance monitoring.
Please refer the Readme for more details on how to set configuration for query band.
Test Results:

Checklist

[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have updated the CHANGELOG.md with information about my change

It looks 1.7.3 is not backward compatible with 1.7.2 as it does introduce a default parameter value for query_band (org=teradata-internal-telem;appname=dbt;). Why not set the default value to None?

Hi @maslick
The purpose of adding query_band was to identify how many users are using the dbt-teradata and to have an idea of the load coming from dbt side. For this, the default query_band has to be set according to TCA (telemetry), which has certain key-value pairs to identify the source of the load. If query_band is set to None, this won't be possible.
This will not affect any dbt functions.
Please let us know if you have any queries or suggestions.


Added RBAC for CRD hpereplicationdeviceinfos

We plan to use the custom resource definition for the storing the replicated device information as part of supporting the 3PAR/Primera CSP 1.1 release which adds the capability of peer persistence.
For this , we need a CRD which will allow us to store details (name/value pairs) for individual array in replicated configuration like
apiVersion: storage.hpe.com/v1
kind: HPEReplicationDeviceInfo
metadata:
  name: replication-crd2
spec:
  target_array_details:
  - target_cpg: FC_r6
    target_name: CSSOS-SSA05
    target_secret: secret-r
    target_snap_cpg: FC_r6

Signed-off-by: William Durairaj<EMAIL_ADDRESS>

looks good. Can you also add RBAC under operators/hpe-csi-driver/deploy/role.yaml and deploy/olm-catalog/1.3.0/hpe-csi-operator*.yaml as well?
@shivamerla
I have added these files already , can you confirm ?

...-catalog/hpe-csi-driver-operator/1.3.0/hpe-csi-operator.v1.3.0.clusterserviceversion.yaml
operators/hpe-csi-operator/deploy/role.yaml

@wdurairaj Do we need to add mode as part of the crd


Add cfg for OpenAi @Azure - deployment

See https://github.com/Blarc/ai-commits-intellij-plugin/issues/35#issuecomment-1517634517

EDIT: Added original comment:
i am missing the "deployment name" configuration
https://learn.microsoft.com/en-us/rest/api/cognitiveservices/azureopenaistable/deployments/create?tabs=HTTP
https://learn.microsoft.com/en-us/azure/cognitive-services/openai/reference#completions

Can't you just hardcode the deployment-id parameter in the url?
https://{your-resource-name}.openai.azure.com/openai/deployments/{deployment-id}/completions?api-version={api-version}

i tried but it says "Error occurred: Illegal input"

I do not do any string validation for token. When you click on verify I just make a request to v1/models endpoint and check if response's status is 200.
Is Azure OpenAI free? Because I wanted to try it out myself, but it says it's only for business? I doubt that OpenAI and Azure OpenAI have the same endpoints. I would be prepared to add a special client for Azure OpenAI, if I had access.

I use  https://github.com/stulzq/azure-openai-proxy to convert the API of azure, and there is no problem in using it after conversion.Hope to be able to help you.

i tried but it says "Error occurred: Illegal input"
Possibly your do some "sk*" validation for the token? .. but azure token does not fit that expectation

I use  https://github.com/stulzq/azure-openai-proxy to convert the API of azure, and there is no problem in using it after conversion.Hope to be able to help you.


Missing tags on Git

Hi!
PyPi has the latest releases, and they are missing as Tags on this repository. Can you put them up?
I'm mostly interested in 2024.2.2 right now, but 2024.2.1 and 2024.1.29 are also missing.
Thanks!

PyPi is misisng the sdist for the 2024.4.3 release, so I thought I could turn back to the Git repository, but it is missing both the commits as well as the latest tags.
Please push them. Thank you!

Hey, @synesthesiam! Not sure if you're watching issues here, given that the issue is two months old already, so I thought I'd ping you. Hope that's fine.

Maybe @andrejs2 can help?

Sorry for the delay! I pushed the commits up and added the tag. I will add sdists to PyPI here shortly.

Thanks!

Home-Assistant 2024.5.0 requires version 2024.4.24 for which no tag exists.

@andrejs2?

@andrejs2?

Sorry, I think it's a mistake...I'm only (only) a language leader for Slovenian...I'm not a dev.

Sorry for the pings then!

Add tags

@synesthesiam The 2024.7.29 bump is missing :wink:

Fixed :+1:


Add semgrep rules for using replicas in resolvers

Related to https://github.com/saleor/saleor/issues/11547
(this is the subtask to prepare the semgrep rules)

We have allow_writer and middleware to log unrestricted writer access which works for now.


When using http.request(), errors are not being caught, causing vows to crash

Here's the code I'm running to test this:
'Request does something that throws an error' : {
  topic: function () {
    var req = require('http').request({
      hostname : 'www.google.com',
      port     : 80,
      path     : '/',
      method   : 'GET'
    }, function(res) {
      throw new Error('error!') // Error should be caught
    })

    req.end()
  },

  'Must reach here': function () {
    assert.ok(true); // Reach here at the end of test
  },
},

I should see something like this:
Request does something that throws an error
    ✓ Must reach here

Instead this happens:
/Users/lxe/devel/vows_test/test_request:115
                throw new Error('error!') // Error should be caught
                      ^
Error: error!
    at ClientRequest.<anonymous> (/Users/lxe/devel/vows_test/test_request.js:115:23)
    at ClientRequest.g (events.js:192:14)
    at ClientRequest.EventEmitter.emit (events.js:96:17)
    at ClientRequest.vows.describe.options.Emitter.emit (/Users/lxe/devel/vows_test/node_modules/vows/lib/vows.js:237:24)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1462:7)
    at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:111:23)
    at Socket.socketOnData [as ondata] (http.js:1367:20)
    at TCP.onread (net.js:404:27)

When I'm running a regular asynchronous function that throws an error, everything is OK:
'Regular async function does something that throws an error' : {
  topic: function () {
    (function(callback) {
      callback()
    })(function() {
      throw new Error('error!') // Error should be caught
    })
  },

  'Must reach here': function () {
    assert.ok(true); // Reach here at the end of test
  },
},

  Regular async function does something that throws an error
    ✓ Must reach here

Originally I was using https://github.com/mikeal/request and discovered this, but I since narrowed it down to http.request() call.
I'm using vows 0.7.0.

Silly me 4 years ago. You can't catch an error in a deferred function from that context!

Ha! Glad we got that all worked out.


[Do not merge]Validates https://github.com/microsoft/kiota/pull/5496

superceded by https://github.com/microsoftgraph/msgraph-beta-sdk-typescript/pull/181


ConsumerBuilder support nullable return type

Is your feature request related to a problem? Please describe.
When I use FloatingActionButton with the Consumer widget, I can't return null when I want to hide FloatingActionButton, I know I can return another widget like SizedBox, but this way no animation of the button will appear.
Describe the solution you'd like
Nullable consumerBuilder?
Describe alternatives you've considered
Return SizedBox but no animation of the button.

this makes no sense.
Although the parameter expected by FloatingButton is nullable, thr return value expected by StatelessWidget.build isn't.
That is not feasible


osx64-ARM

Comment:
Hi,
is here a plan to support osx64-arm platform? I am still trying to understand but it seemed this would be done kind of automatically? Still, the following packages are still missing an ARM version so they are not found when trying to install via mamba: r-rnaturalearth, r-rnaturalearthdata, r-rgdal, r-raster, and r-tigris.
mamba install -c conda-forge --override-channels r-rnaturalearth r-rnaturalearthdata r-rgdal r-raster r-tigris

produces the error
Looking for: ['r-rnaturalearth', 'r-rnaturalearthdata', 'r-rgdal', 'r-raster', 'r-tigris', 'libblas=[build=*accelerate]']

conda-forge/osx-arm64                                       Using cache
conda-forge/noarch                                          Using cache
r/osx-arm64                                                 Using cache
r/noarch                                                    Using cache

Pinned packages:
  - python 3.11.*

Could not solve for environment specs
The following packages are incompatible
├─ r-raster does not exist (perhaps a typo or a missing channel);
├─ r-rgdal does not exist (perhaps a typo or a missing channel);
├─ r-rnaturalearth is not installable because there are no viable options
│  ├─ r-rnaturalearth 0.3.2 would require
│  │  └─ r-sf >=0.3_4 , which does not exist (perhaps a missing channel);
│  └─ r-rnaturalearth [0.3.3|0.3.4|1.0.0|1.0.1] would require
│     └─ r-terra, which does not exist (perhaps a missing channel);
└─ r-tigris is not installable because it requires
   └─ r-sf, which does not exist (perhaps a missing channel).

Conda Forge is still building for osx-arm64 only by demand. The process to trigger a "migration" for this platform is described in the documentation and essentially involves sending a PR to the conda-forge-pinning-feedstock adding the package name to the osx_arm64.txt file.
However, some of the packages you are inquiring about have already been slated for migration (trackable on the status page) but encountered trouble. I've definitely tried working on some of these (e.g., r-terra and r-sf) to no avail. Any PRs to help get them moving are welcome!
Native osx-arm64 CI has only recently become available but policy as to usage has not been established by the Core (see https://github.com/conda-forge/conda-forge.github.io/issues/1781). So, some of these may get resolved in the near future by not having to cross-compile.


Transactions/Connections are left open in db

❗ please do not add sensitive information in issues, you can provide extra information via email using issue number as reference ❗
Describe the issue
I have adapters with EsbJmsListener that have ff configuration. In the adapter, after receiving the message I store that message in ibisstore using messageStoreSender(with maxRetries="3"). The application runs on two nodes.
Scenario:
I put 1000 messages in the ff queue then I let the adapters do the processing. After some time, I get deadlocks which happens when the two nodes insert records in ibisstore table. I see transaction timeouts in the log file.  Again after some time, I see such events in log file
nl.nn.adapterframework.core.ListenerException: cannot determine message count: (SQLException) SQLState [XAE07], errorCode [1399]: XAER_RMFAIL: The command cannot be executed when global transaction is in the  ROLLBACK ONLY state 	at nl.nn.adapterframework.jdbc.JdbcMessageBrowser.getMessageCount(JdbcMessageBrowser.java:320) ~[ibis-adapterframework-core-7.8-RC3-20230123.094613.jar:7.8-RC3-20230123.094613] 	at nl.nn.adapterframework.webcontrol.api.ShowConfigurationStatus.mapAdapter(ShowConfigurationStatus.java:720) ~[ibis-adapterframework-core-7.8-RC3-20230123.094613.jar:7.8-RC3-20230123.094613] 	at nl.nn.adapterframework.webcontrol.api.ShowConfigurationStatus.getAdapters(ShowConfigurationStatus.java:119) ~[ibis-adapterframework-core-7.8-RC3-20230123.094613.jar:7.8-RC3-20230123.094613] 	... suppressed 3 lines
Moreover, when I list the processes in the database I see lots of processes that are in sleep state for a long time(>10000 seconds).
Therefore almost any call to db gives The command cannot be executed when global transaction is in the ROLLBACK ONLY state error even if the call is not transacted
I think either the transactions or the connections are not closed properly after processing fails/ times out.
I'll send an email for the other details.
Reporter
Ali
ff: 7.8-RC3-20230123.094613, 7.8-RC3-20230221.160953
transaction manager: btm
db: mariadb 10.4.26

On first sight, this sounds reminiscent of a number of issues which we have been looking into over the past week. One issue could be that retry-delay is fighting the transaction timeout.
As a workaround, can you increase the default transaction timeout?
In the 7.8RC3 build which should come soon, the default configuration of transaction timeout should already be more in line with the retry-delay, and there are more options for pooling connections.
It is also important to see why transactions are taking such a long time -- has there been a message that had errors and was retried several times due to that?

Has this been solved by implementing #4733 ?

Not really. The error is not thrown when the process is transacted. However, for non-transacted operations the error mentioned above still occurs.

We're going to overhaul and drastically improve our pooling mechanisms as well as the ability to use non-XA and XA datasources in  #4841. As such we would like to close this issue once such a fix has been released. I'm reluctant to backport these changes to the 7.8 unless absolutely required.


"No Wikidata item matching" message remains despite items loaded

It might be hard to reproduce, but I managed to get this when searching (see red arrow):

Maybe hide the message when you load items?

Hey @nicolas-raoul although i was not able to reproduce the issue, yet i have modified the code to hide the view so that this issue won't come across any more. Here is the commit

Fixed, thanks! :-)

Strangely this problem seems to have reappeared (up-to-date structured-data branch):

@nicolas-raoul I have managed to reproduce this error. This occurs maybe due to slow internet because we are setting errorView when query list is empty as well as when error occurs while fetching from api.
Cut the internet connection while loading items and message appears. I'd fix this

@318anushka I've assigned this to you. Go for it :)

According to @macgills this is redundant after the pagination changes.


ignoreTypeOfStepName dont work with  ignoreTypeOfStepName

.

If you are going to submit an issue, please give us maintainers the courtesy of at least formatting the code and error properly.
Can you create a reproduction repo? This is not an issue with the plugin, it's configured properly so it's something with your setup, likely outdated packages.

I apologize for the formatting. It turned out that npm contains a package released 5 months ago and it does not have this functionality since it appeared only a month ago

@mrozwat I cut a new release this morning, should be available soon.


[bugfix] fix tsts

broken by https://github.com/vllm-project/vllm/pull/9958

we should unify the function signature of vllm models in the end.


Allow Routing Functions to send to multiple functions

I'm not sure if this would belong in the spring-cloud-function or spring-cloud-stream project, but this is an enhancement request to consider allowing the Routing Function to route an incoming request to multiple functions.
One such use case was discussed on stackoverflow here.
Maybe it can look something like the below where if "type" is both then it sends to both "funA" and "funB" and if type is something else it just sends to funA?  Note, not sure if a comma would be the best delimiter.
spring.cloud.function.routing-expression: "headers['type'] == 'both' ? 'funA,funB' : 'funA'"

@jaganm2018 I am not sure I follow your comment about #704. Why do you think this is relevant?

@Mrc0113 @GreenRover
Let me start with the context before I ask a question.
RoutingFunction is still a Function and as such results in the output representing which actual function needs to be invoked. And then that function is invoked and its output returned to the user. The key work here is output.
When routing to a single function there are no issues since  expectations of a single output from the function are preserved.
Routing to multiple function will result in multiple outputs at the time when user expects only one. Sure there are also questions about error handling, order, async vs sync etc. but those are n't important until the question of multiple outputs is answered.
On the flip side we would have no problem routing multiple Consumers as there are no expectations of the multiple output.
We could also route to single function and multiple consumers. . .etc
So, please provide some more context so we can answer these questions.

Hi Oleg,
thanks for your answer.
Ok i understand your problem.
Please see the stackoverrlow issue for the original use case.
In this use case we talk about multiple consumer. So there is no return.
But @Mrc0113 i dont know it this is a problem to be solved in cloud function.
Is this not a spring cloud stream problem.
Because in my world view, is what spring cloud stream habe to do, is calling multiple "-out-X" in row if defined.
Best regards Heiko

Thanks @olegz and @GreenRover for taking a look at this. Looking at this many months later I'm thinking it's probably not worth introducing new features/functionality for this. What Soby recommended on stackoverflow seems like a reasonable solution when this situation presents itself. Is that what you ended up doing @GreenRover?
Although at the same time I wonder if having Function Arity for Imperative Functions would also solve this? I haven't dug into how it works with reactive functions but in theory it allows for a Function to have multiple output bindings.
@Bean
public Function<Flux<Integer>, Tuple2<Flux<String>, Flux<String>>> myFunction() {
	return flux -> ...;
}

So you could do something so your bindings looked like this:
spring:
    stream:
      bindings:
        myFunction-out-0:
          destination: api/v1/the/topic
        myFunction-out-1:
          destination: api/v2/the/topic


So so close, but too short a git clone repo

Environment hmm, if environment means OS then I'm using Windows10. I have Git. I am using the Windows Command Line
Replace this with the output of:
C:\Users\Truman Cassady>git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/literary_fun1
Cloning into 'literary_fun1'...
aws codecommit credential-helper --profile AdministratorT $@ get: /c/Users/Truman Cassady/AppData/Local/Programs/Python/Python35-32/Scripts/aws: c:\users\truman: bad interpreter: No such file or directory
Username for 'https://git-codecommit.us-east-1.amazonaws.com/v1/repos/literary_fun1': literary_fun1
Password for<EMAIL_ADDRESS>fatal: unable to access 'https://git-codecommit.us-east-1.amazonaws.com/v1/repos/literary_fun1/': The requested URL returned error: 403
What did you do? I found out late last night that I needed in reinstall Git,and disable the Git Credential Manager Utility. I did this with no problem.
What did you expect to see? I was expecting the git clone command to accept my password for the IAM User.
What did you see instead? I looked into the error 403, and can't think of why the server did not return the url connection. It can be seen in the code above that the c:/users leads into the "Truman Cassady" folder. I initially thought there was an issue because of the the space in that directory name, so I tried installing Python and Git in the c:/windows trail, but I was prevented for reasons of not having administrator permission. Is this required for the cloning process to succeed? or is there something in the code that I am missing?

Closing, I think this has been directed to the wrong project.


Update documents

Signed-off-by: Tong Chen<EMAIL_ADDRESS>

Had some accidental modification. Better to start with a clean PR.


attachment of sources and javadoc.

As suggested by Marko in Tinkerpop ML (http://groups.google.com/group/gremlin-users/msg/779d39b65bcf7fa5), I took the freedom to update POM in order to attach sources to artifacts.
It should work on all blueprints submodules, and should also be easy to add to other Tinkerpop projects.

Done. Thanks.


[#188] refactor CI to use Docker image

This decreases the distance bewteen dev and CI, whilst ensuring that updates to test stages are reflected automatically. Note that Docker images are not used for stg or prd, since they run on Heroku.

Rescinded in favour of https://github.com/openownership/register-common/pull/16 .


Finding the right concepts to describe scenario bundles on the OEP

Description of the issue
On the OEP we already implicitly provide scenario bundles, i.e. bits and pieces of information that belong together, such as, for example a data table including metdadata with a scenario / study  factsheet. At the moment these are not yet explicitly linked to each other, neither using tags, nor using ontology functionality.
Ideas of solution
It would be great to start thinking about which concepts we need to describe the bundles on the OEP. We could use this issue to share first ideas on new concepts also to identify which concepts from the OEP may come in helpful for the bundles.  An oeo-dev meeting may also come in handy.
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

What do you mean by scenario bundles? I can't find them on the OEP.

Exactly - you can't find them explicitly yet, because information is not yet linked to each other, but we do think in these terms.
A scenario bundle is for example a data table from scenario X and a factsheet that describes scenario X, the underlying study etc. So what is missing is a depiction of something like this in the ontology AND the functionality on the OEP to make the links explicit.
Example:

scenario tables KS80: https://openenergy-platform.org/dataedit/view/scenario?query=&tags=234
scenario factsheet KS80: https://openenergy-platform.org/factsheets/scenarios/11/ (NOTE: this is the legacy version of factsheets, to be substituted by RDF factsheets)
study factsheet containing KS80: https://openenergy-platform.org/factsheets/rdf/study/KSz_2050/

And if thinking the bundle even further, information from model and framework factsheets may also belong.
This example may be too specific for how we think for the ontology, but may serve as a first idea on what kind of information on the OEP would be meant to be part of a scenario bundle.

This won't be solved until the next release. Thus I move the milestone.

This issue is rather unspecific and hasn't been worked on for quite a while. Further, we started to mark bundle-related issues with the OEKG-lables and have this issue in the OEKG-repo. Therefore I close this issue now. If there is need for another bundle-related meta-issue, please open a more specific one.


Parallel simulation

Add a parameter to MCTS that enables parallel rollouts
Look into how sklearn uses n_jobs parameter

Dear kstruempf,
In the MCTS.py file, line 80 and line 83, please add one additional control to exit the while or the for loop.
There are two scenarios that you may want to exit the while or loop earlier.

The reward is already good enough after an execute_round.
The get_possible_actions could possibly have very limited choices and a few runs of execute_round will exhaust all of them.

Please let me know if you have any questions.
Thanks,
Tom Liu


Issues with comma separated selectors

Bug report
Describe the bug
I found some issues with the selectors generation when comma separating them
To Reproduce
https://codesandbox.io/s/exciting-currying-853rx?file=/src/App.tsx
Note how in this example, hover and focus are not generated correctly. hover is missing the hash, and focus is not applying the specificity fix.
In the descendant selector example, the a is missing the parent selector.
Expected behavior
A clear and concise description of what you expected to happen.

@peduarte your sandbox is not targeting the latest canary which contains the comma-separated rules fix
so you simply need to update the sandbox to use the latest canary and then update the hover,focus bit to
  ":hover,:focus": {
    color: "black"
  }

I did however find another issue related to ampersand and the specificity fix which I'm looking into now

@hadihallak oooft, my bad. perhaps it was a tad too late to be raising issues.
the issue I was meant to raise was this:

Note how the focus selector doesn't contain the right specificity. Looks like you spotted it as well 👍
Same sandbox https://codesandbox.io/s/exciting-currying-853rx?file=/src/App.tsx

We've published a pre-release of Stitches beta 🚀
Core:
npm install<EMAIL_ADDRESS>
React:
npm install<EMAIL_ADDRESS>
This issue should have been resolved in the beta version. We'd appreciate it if you could verify it.
⚠ Please refer to this migration guide as there are some breaking changes.


Add new operator names from SQLAlchemy 1.4 (#237)

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


make top-left examples decoration take you back to the main examples site

I left it as # as I wasn't sure how/if we were going to mount this into the Roc website. So not sure what the URL would be / might take you to the home page, while /examples might take you to the examples.


Unresolved directive in userguide.pdf

Issue type
Missing information
Problem description

wget https://docs.gradle.org/current/userguide/userguide.pdf
Open Section "GETTING STARTED"
Observe Unresolved directive :leveloffset: +2

Context (optional)
No response
Page with the problem
https://docs.gradle.org/current/userguide/userguide.pdf

Thank you for your interest in Gradle!
This is a valid documentation issue that we will address.


Updated Spamming definition in the Code of Conduct

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[ ] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #9579

Description

Changed the definition of Spamming in the code of conduct
Definition approved by Quincy.

@joshghent can you please remove the closes #9579 from the commit using git commit --amend. Thanks :smiley:

@atjonathan Done! Sorry about that, didn't see that clause in the contrib.md

:sparkles: :sparkles: LGTM :+1: :sparkles: :sparkles:
:tada: Thanks for contributing @joshghent and congratulations on your first PR submission to FreeCodeCamp! :tada:


Replace "Client certificates" tab with "Access" tab in cluster details

From refinement.
The "Client certificates" tab in cluster details in the web UI currently doesn't display client certificates created via MAPI. We have a broader issue to make this possible some time in the future (current status: blocked).

Currently, this tab doesn't display any client certificates for many customers, and with the move towards CAPI, there will be even more customers who won't find any client certificates listed here.
We would like to replace this tab with an "Access" tab instead, in order to provide customers with useful information regarding how to access their workload cluster. We have also received feedback from a customer that they would navigate to the "Get started" guide for information regarding workload cluster access, so providing that information here feels like a better use of the space.
Tasks:

[ ] Spec for "Access" tab in cluster details in the web UI
[ ] Replace "Client certificate" tab with "Access" tab in cluster details (web UI implementation)

After this is implemented, we should also think about removing/replacing the Client certificates widget in cluster details overview.

With our decision to develop Backstage plugins as our web UI, we are not investing in bigger happa improvements like this one. Closing this issue.


sync main to generic-table-dev

Does this replace https://github.com/p4lang/p4runtime/pull/468 ?
Do you intend to resolve the conflicts in this PR?

thanks

It should not be too hard to resolve merge conflicts. Just reset these 2 files to the version on the main branch, update them with ./codegen/update.sh, and commit the changes. That should take care of it.

It should not be too hard to resolve merge conflicts. Just reset these 2 files to the version on the main branch, update them with ./codegen/update.sh, and commit the changes. That should take care of it.

That's what I had done with https://github.com/p4lang/p4runtime/pull/468 , but we were wondering if there was a cleaner way


[W6.2][T10-B2] Yan Wei Cheng

@Affalen
Accepting this PR with minimal review and I found no important issue.


Get javascript generated html

On a site I'm trying to scrape the html is generated by client side javascript.
Can I use node.io to scrape it or is that not supported. Thanks.

Set the jsdom option to true to enable the jsdom parser. You may also need to set the external_resources option to true if the page you're scraping needs to load any <script> tags. After requesting the page you have access to the a window object and jQuery fn $. Have a look at this code

chriso, could you explain how the window object selects elements, and how the $ which appears to be undefined, comes into play?"


Doesn't seem to be reading dbName in

Hi, I have the following docker-compose:
services:
  postgres-casdoor:
    image: docker.io/library/postgres:latest
    environment:
      POSTGRES_DB: casdoor
      POSTGRES_PASSWORD: pass
      POSTGRES_USER: admin
    ports:
      - 5433:5433
    restart: always
    networks:
      - postgres-network
    expose:
      - "5433"
    command: -p 5433
  casdoor:
    restart: always
    image: docker.io/casbin/casdoor:latest
    entrypoint: /bin/sh -c './server --createDatabase=true'
    ports:
      - "8000:8082"
      - "7000:7000"
    depends_on:
      - postgres-casdoor
    environment:
      RUNNING_IN_DOCKER: "true"
    volumes:
      - ./backend_golang/config:/conf/
    networks:
      - postgres-network

and corresponding app.conf
POSTGRES_PASSWORD=pass
POSTGRES_USER=admin
POSTGRES_DB=casdoor
appname = casdoor
httpport = 8000
runmode = dev
copyrequestbody = true
driverName = postgres
dataSourceName = "user=admin password=pass host=localhost port=5433 sslmode=disable sslmode=disable dbname=casdoor"
dbName = casdoor
tableNamePrefix =
showSql = false
redisEndpoint =
defaultStorageProvider =
isCloudIntranet = false
authState = "casdoor"
socks5Proxy = "<IP_ADDRESS>:10808"
verificationCodeTimeout = 10
initScore = 0
logPostOnly = true
origin =
originFrontend =
staticBaseUrl = "https://cdn.casbin.org"
isDemoMode = false
batchSize = 100
enableGzip = true
ldapServerPort = 389
radiusServerPort = 1812
radiusSecret = "secret"
quota = {"organization": -1, "user": -1, "application": -1, "provider": -1}
logConfig = {"filename": "logs/casdoor.log", "maxdays":99999, "perm":"0770"}
initDataFile = "./init_data.json"
frontendBaseDir = "../casdoor"

I'm running into the error message on start (when creating the DB tables)
glance-casdoor-1           | goroutine 1 [running]:
glance-casdoor-1           | github.com/casdoor/casdoor/object.InitAdapter()
glance-casdoor-1           |    /go/src/casdoor/object/ormer.go:84 +0x24b
glance-casdoor-1           | main.main()
glance-casdoor-1           |    /go/src/casdoor/main.go:35 +0x46
glance-casdoor-1           | panic: pq: database "admin" does not exist

Any idea what is going on? It doesn't seem to be reading the dbName field in the config file

@joshchang provide:

postgres version
Casdoor version

postgres:latest (16) and casdoor:latest ([v1.451.0] from docker.io

I also tried leaving the trailing dbname empty in dataSourceName and arrive at the same error:
glance-casdoor-1           | goroutine 1 [running]:
glance-casdoor-1           | github.com/casdoor/casdoor/object.InitAdapter()
glance-casdoor-1           |    /go/src/casdoor/object/ormer.go:84 +0x24b
glance-casdoor-1           | main.main()
glance-casdoor-1           |    /go/src/casdoor/main.go:35 +0x46
glance-casdoor-1           | panic: pq: database "admin" does not exist

POSTGRES_PASSWORD=pass
POSTGRES_USER=admin
POSTGRES_DB=casdoor
appname = casdoor
httpport = 8000
runmode = dev
copyrequestbody = true
driverName = postgres
dataSourceName = "user=admin password=pass host=localhost port=5433 sslmode=disable sslmode=disable dbname="
dbName = casdoor
tableNamePrefix =
showSql = false
redisEndpoint =
defaultStorageProvider =
isCloudIntranet = false
authState = "casdoor"
socks5Proxy = "<IP_ADDRESS>:10808"
verificationCodeTimeout = 10
initScore = 0
logPostOnly = true
origin =
originFrontend =
staticBaseUrl = "https://cdn.casbin.org"
isDemoMode = false
batchSize = 100
enableGzip = true
ldapServerPort = 389
radiusServerPort = 1812
radiusSecret = "secret"
quota = {"organization": -1, "user": -1, "application": -1, "provider": -1}
logConfig = {"filename": "logs/casdoor.log", "maxdays":99999, "perm":"0770"}
initDataFile = "./init_data.json"
frontendBaseDir = "../casdoor"

I tried without Docker and it goes well


fix typo

fix typo

@hecongy : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Thanks @hecongy


active dev?

Hi,
Please let me know if you are planning on actively developing this APP .
THX

I have initiated it but the app development is currently on hold

Thanks for your reply.
I’m trying to help out a local drug treatment center.
I was hoping to continue developing with this APP.
Is there any source code that would be helpful or anyone still interested in coding it?
Your comments are welcome
Best,
Don
From: Madhuri Rudrabhatla<EMAIL_ADDRESS>Sent: Friday, March 5, 2021 8:50 PM
To: madhu1607/PillPal_LP<EMAIL_ADDRESS>Cc: DP S<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [madhu1607/PillPal_LP] active dev? (#2)
Closed #2https://github.com/madhu1607/PillPal_LP/issues/2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/madhu1607/PillPal_LP/issues/2#event-4416500304, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOZS6Z6LLY77HAU63DNYR3TCGYA7ANCNFSM4YWKSVZA.


VSCode

Great theme! I'd love to use it, but I work with VSCode. Any chance you can convert your theme to vscode?

Hey @BrandTurner , sure will do.
Give me few days. 😄 👍


isRunning is always false

Because disposeTimer() that sets _isRunning to false is called after setting _isRunning to true in start() in CountdownTimerController:
  start() {
    _isRunning = true;
    disposeTimer();

.
.
.

  disposeTimer() {
    _isRunning = false;

Fixed in version 4.0.1, thanks.


fix panic of podGroup and pod delete order issue2

Ⅰ. Describe what this PR does

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/lgtm

/approve


In the updates of Readme, can you please put small picture examples

Or even links to another page that allow a "browsing person" to follow and see what a "Picture wheel" looks like?

Yes, sure, do you mean a screenshot of the example application?

I think each control as you complete it (Or when it has usable functionality)  should be enough.

Now live


fix(dev): switch to JEST_WORKER_ID environment variable

Apparently, ESLint sets the NODE_ENV to test and if you are using a eslint plugin that relies on this code you'll end up requiring when you should be importing.
Because this block is for Jest specifically, we'll instead use a known environment variable in a Jest environment.

[ ] Docs
[ ] Tests

Testing Strategy: Run CI. I also verified this solves my use case with a local patch.

Related issue: https://github.com/jenseng/eslint-plugin-remix-react-routes/issues/16

Closed this because the eslint plugin is where the fix will be, but I'm reopening because I still think this change makes sense...


Multi-cluster replicated control plane without gateway-connected clusters/ServiceEntry

Describe the feature request
I think this could probably be called "federated control plane" or something, but "federation" is so overloaded that we should probably come up with a better term.
tl;dr: I'm looking for a way to do multiple control planes but still have the same abstractions as in shared control plane - i.e. no ServiceEntry, no .global DNS pointing to an ingress gateway, etc.
I really like the Shared Control Plane model. Being able to stitch together clusters so that from the application networking perspective, cluster boundaries don't exist. However, this has the disadvantage of shared fate with cluster outages and/or having a single point of failure at the control plane.
To handle the resiliency, the recommended approach is to run multiple control planes. At the very least, people are running one-per-region. In some other cases, people are running one-per-az or one-per-cluster.
Unfortunately in the Replicated Control Plane model, clusters are connected via gateways - meaning that the abstractions that are set up in the Shared Control Plane (Service, VirtualService, Endpoint) are not the same as those in the replicated control plane (ServiceEntry). Additionally, in a flat network, the ingress gateways for service-to-service communication are extraneous.
What I am proposing is having replicated control planes, but with "cross registration" of cluster resources (Services, Endpoints, whatever else Istio does within a cluster/control plane domain currently) from one cluster to another.
During a cluster failure or network partition, the only thing that will happen is that cross registration will stop, but since each control plane operates independently, the remaining control planes will still work fine.
You may now be asking about scaling concerns, but let's ignore it for now. The scaling problems will likely be the same as that of a single large control plane.
Describe alternatives you've considered
Admiral: It doesn't handle this I believe since it still deals with ServiceEntrys
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[X] Performance and Scalability
[X] Policies and Telemetry - Gateways hide the true endpoint that is being hit and so make the system less observable
[ ] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure

@bplotnick thanks for raising this, we havesimilar thoughts as well - as you can tell from the discussion on the networking channel.  I think I agree with you with the notion of without service entries, I do think we need gateway connected clusters with auto passthrough for multi-network scenario, similar as what is in shared control plane multi network today.
I think we could possibly defer this (cross registration of istio resources) to a second phase as this can be driven from CI/CD system.
The first phase issue is how to configure Endpoint and services across clusters when each cluster has its own control plane.  @costinm mentioned by connecting to all apiservers, which I think it is doable.  let us say i have c1 in region east, and c2 in region south.   I can give c1 to access c2's API server via istio-reader-service-account as described in https://istio.io/docs/setup/install/multicluster/shared/#configure-cross-cluster-service-registries.  Similarly, I can give c2 access to c1's API server.  @costinm could you confirm that is what you are thinking?
cc @ayj @howardjohn @frankbu @esnible @mbanikazemi @dcberg

I recall seeing some discussion about how this approach is not preferred due to the n^2 connections from all control planes to all api servers? From @nmittler I believe

Agree if you have many clusters and many API servers this can be lots of connections.  I don't think this would be used often, mainly across regions.  within region, you can use single control plane.  The prob we have is we don't want to rely on single control plane across regions.

In principle there are several dimensions to multi-cluster deployment models:

shared vs. replicated (where do control planes run)
service discovery (explicit ServiceEntry vs. directly peer kube-apiservers)
number of networks

Not every combination is supported, primarily we don't test every combination. Here's what we document on istio.io:

Shared, single network, service/endpoints directly from peer kube-apiservers
Shared, multiple network, service/endpoints directly from peer kube-apiservers
Replicated, multiple network, service/endpoints explicitly from ServiceEntry

IIUC, @bplotnick is asking about the following model:

Replicated, single network, service/endpoints directly from peer kube-apiservers

This is similar to (1) and in fact easier to configure than (1). k8s services/namespaces still need to be replicated so DNS is configured correctly.
# <... install intermediate certs with common root in each cluster ...>
istioctl manifest apply --context=cluster0 --set values.global.multiCluster.clusterName=cluster0
istioctl manifest apply --context=cluster1 --set values.global.multiCluster.clusterName=cluster0
istioctl x create-remote-secret --context=cluster0 --name=cluster0 | kubectl apply -f - --context=cluster1
istioctl x create-remote-secret --context=cluster1 --name=cluster1 | kubectl apply -f - --context=cluster0

Also worth noting that multi-network variant of replicated control plane using kube-apiserver is also possible.

Replicated, multiple network, service/endpoints directly from peer kube-apiservers

This requires more steps to configure the networks. The basic idea is to follow  https://istio.io/docs/setup/install/multicluster/shared/#main-cluster to create both cluster's profile.
For example, cluster0's network config may look like:
    global:
      multiCluster:
        clusterName: cluster0
      network: network0
      meshNetworks:
        network0
          endpoints:
          # registry name for the cluster that this configuration is applied to must be "Kubernetes"
          - fromRegistry: Kubernetes
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443
        network1
          endpoints:
          # registry name must match cluster1's global.multiCluster.clusterName
          # and remote secret name
          - fromRegistry: cluster1
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

And cluster1's network config may look:
    global:
      multiCluster:
        clusterName: cluster1
      network: network1
      meshNetworks:
        network0
          endpoints:
          # registry name must match cluster0's global.multiCluster.clusterName
          # and remote secret name
          - fromRegistry: cluster0
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443
        network1
          endpoints:
          # registry name for the cluster that this configuration is applied to must be "Kubernetes"
          - fromRegistry: Kubernetes
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

Then, apply the custom profiles to each cluster and create the remote secrets.
<... install intermediate certs with common root in each cluster ...>
istioctl manifest apply --context=cluster0 -f <cluster0-profile.yaml>
istioctl manifest apply --context=cluster1 -f <cluster1-profile.yaml>
istioctl x create-remote-secret --context=cluster0 --name=cluster0 | kubectl apply -f - --context=cluster1
istioctl x create-remote-secret --context=cluster1 --name=cluster1 | kubectl apply -f - --context=cluster0

Please don't copy/paste the config/commands above :) There's likely a typo (or two) and I may have forgot some minor step. But the basic flow is still sound.
As @howardjohn mentioned, one downside to this approach is Ω(N^2) watches between clusters. The number is higher when there are multiple istiod pods per-cluster. It also introduces yet another deployment model when we're actively trying to simply multi-cluster configuration. That said, it's may still be worth exploring how to make this work without overwhelming users with options.
cc @nmittler @smawson @rcaballeromx

@ayj thanks for sharing the steps, that is pretty much I have in mind as well.  It is a mixed model with our single control plane and replicated control plane model.  Certainly I am interested in this as I don't have flat network env:

multiple control planes, multiple networks, service/endpoints directly from peer kube-apiservers

In this model, users don't need to worry about creating SEs or VSs.
Re N^2 watches between clusters, one way to tackle this is to not auto expose everything across clusters, could be only a given global namespace or only services with certain matching label e.g. gobal label.

Thanks for the discussion. And special thanks to @costinm for the discussion in Slack.

I think we could possibly defer this (cross registration of istio resources) to a second phase as this can be driven from CI/CD system.

After the discussion in slack, I agree that this is out of scope. Endpoint discovery[0] is the main thing we need. Just like ServiceEntry today, we can leave replicating namespaces, Service, VirtualService resources, etc. to the users for now.

I recall seeing some discussion about how this approach is not preferred due to the n^2 connections from all control planes to all api servers?

I think in terms of scaling, there are ways that we can bring these factors down (e.g. designated aggregators, which a networking colleague of mine likened to BGP Route Reflectors). But for now, let's acknowledge the potential scaling issues exist and move on.

It also introduces yet another deployment model when we're actively trying to simply multi-cluster configuration

I agree. The last thing Istio needs is more complexity. But I actually think this has the potential to replace the ServiceEntry approach and reduce complexity. In fact the reduction in complexity is one of the main reasons that I like this approach. Given that a ServiceEntry is for external services, it was very strange to me to use it for internal services. And to have a separate .global name. In my ideal world, something like Admiral doesn't need to exist, or would be focused on something else.
If we could annotate endpoints with the cluster/network then we could use a network topology to determine routes to endpoints - i.e. whether to go through a passthrough gateway. Though to be honest, this is irrelevant to my use-case as we have a flat network, so i don't know what this type of user wants.
[0] Terminology note (for noobs like me): Coming from the SmartStack world, we distinguished "Service Registration" from "Service Discovery". It appears that this distinction is not as relevant in the Kubernetes world because the registration is automatically done by K8s. Additionally, because Service is a separate thing from Endpoint, the term should probably be something more like "Endpoint Discovery".

If we could annotate endpoints with the cluster/network then we could use a network topology to determine routes to endpoints - i.e. whether to go through a passthrough gateway.

FWIW, this is how shared control plane works today w/single and multi-network.

But for now, let's acknowledge the potential scaling issues exist and move on.

For smaller values of N (clusters) the extra control plane redundancy is probably worth the cost of extra connections.

But I actually think this has the potential to replace the ServiceEntry approach and reduce complexity. In fact the reduction in complexity is one of the main reasons that I like this approach.

I would be interested to hear others thoughts here. It is appealing to reduce the dimensions to "shared vs. replicated" and "# of networks".

I think I'm interested in this approach too and agree it is a simplification, managing service entries aren't easy when there is more than 2 clusters.... plus it doesn't support weighted based routing for a given subset because you don't have visibility into the other cluster like the current shared control plane does.
If we can introduce a reasonable multiple control plane single or multiple network approach, i think it could possibly replace the replicated control plane and we will converge on one model and let users to decide if they choose to run shared control plane vs multiple control planes.
In summary, it would be 1 single model, while up to users to choose:

shared control plane vs dedicated control plane
single or multi networks
choose what to expose to the other control planes so not necessarily everything is exposed... Kube community already has an API in progress: https://docs.google.com/document/d/1hFtp8X7dzVS-JbfA5xuPvI_DNISctEbJSorFnY-nz6o/edit#heading=h.u7jfy9wqpd2b

(A side note, I think replicated control plane naming is pretty confusing... it is just single trust domain and multiple control planes imho.)

Please don't directly copy/paste the config/commands above :) There's likely a typo (or two) and I probably forgot some minor step.
As @howardjohn mentioned, one downside to this approach is Ω(N^2) watches between clusters. The number is higher when there are multiple istiod pods per-cluster. It also introduces yet another deployment model when we're actively trying to simply multi-cluster configuration. That said, it may still be worth exploring how to make this all work without overwhelming users with options.
cc @nmittler @smawson @rcaballeromx

Catching up on this issue which contains many subthreads...
The fascinating beauty of using a ServiceEntry to represent an external workload in an opposing mesh is that O(N^2) watches are not required on the kube-apiservers to enable service discovery.
Instead each cluster is responsible for watching its own kube-apiserver. Each cluster reads service creation/removal and communicates the results from kube-apiserver (which is a pokey rate-limited REST API with complex caching mechanics) to its opposing cluster using a high-performance well-designed gRPC between two clusters. The opposing cluster then creates service entries on the opposing end representing the services. If these are connected in opposing fashion, as all good networking is done, any network topology can be modeled.
Using this model scales, even though there are O(N^2) gRPC connections. If we can read from kube-apiserver one time for each service change, with the reading happening within each cluster, and then encode that information into gRPC transmissions, The O(N^2) that was kubeapi turns into O(1) in kubeapi and O(N^2) into gRPC calls in the worst case (where N = number of clusters). As any Kubernetes expert knows, kubeapi is what we optimize away.
Plus, we don't have to security nightmare of having 100's of kube-apiserver credentials stored across hundreds of hypothetical clusters.
Put simply, reading from kube-apiserver for every service creation and deletion is excessively expensive, and we need to offload that.  About a year ago, this was what was to be the purpose of MCP. That never materialized, and I think it is about time to solve replicated control planes in the community.
This is the most scalable path forward.
This model also offers the most availability.

@ayj small q for what you mentioned = `"k8s services/namespaces still need to be replicated so that DNS works correctly ." This is only required if i need cross cluster routing correct?

The RFC1918 networking model (what has been merged - more or less) replication problem is about discovery. For folks that haven't been following this area closely, discovery is the major problem to be solved.
The model @rshriram proposed and implemented was really really close. Where it could be improved:

service entries were not automatically managed
cloud providers with loads of extra DNS entries would run into application discovery problems.

proposal https://github.com/istio/istio/issues/22605#issuecomment-608950278 solves 1.
PR: https://github.com/istio/istio/pull/22369#issuecomment-604513008 (see the point about how global is handled in istiod instead of being added as a search domain!) solves 2.
I'll be honest when I say that I have about thrown in on the gateways approach to multicluster. @costinm, fortunately, saved the day (again) with his PR proposal. Doing 1 is fairly easy. Problem 2 seemed unsolvable.
I feel we should keep them separate a bit while longer until we can properly determine the best course of action once Costin's DNS work merges.
Cheers
-steve

There is no O(N^2) scalability issue if we don't look at replicated control plane as being an all or nothing choice (i.e., shared vs replicated). Replicated control planes are needed for HA, but that doesn't mean that we need 1 in every cluster, just more than 1. In this case, it's only O(C*N) connections, which can be much less than N^2. So I would think we should be focusing on a replicated pattern as an HA addition to the shared pattern, i.e., one where a subset, as opposed to just 1, of the clusters run a control plane. That said, @bplotnick's proposal to eliminate ServiceEntry from the pattern seems like a great simplification.

Catching up on this thread. I do agree that the important point is to support Endpoint discovery and avoid having customers define ServiceEntries to use remote services. I do agree with @linsun comment (https://github.com/istio/istio/issues/22605#issuecomment-608629319) that the customer  can have shared vs dedicated control planes and single vs multiple networks.
What is the next step here?

Just catching up as well. IIUC the root cause of this issue is that the istio.io docs conflate endpoint discovery with control plane deployments. In other words, it appears that the only way to deploy replicated control planes is with gateways + ServiceEntry.
We have already documented various dimensions of Istio deployments in the deployment models concepts page, where we identify things such as network and control plane topology. We don't currently, however, mention Endpoint Discovery as a dimension. This is probably due to the fact that it's more of a derived dimension, based on more fundamental dimensions (e.g. control plane, cluster, network).
I wonder if we could resolve this issue by simply updating the docs. We could do the following:

Add a section to the concepts page for Endpoint Discovery
Update installation instructions (for both shared and replicated control planes) to configure Endpoint Discovery based one one of two approaches (depending on network/control plane configuration).

Obviously we still have more to do WRT simplifying the multicluster installation overall, but this should at least help users avoid needless complexity in the meantime.
WDYT?

@nmittler I believe that would be a good first start (i.e., document how to achieve Endpoint discovery with the existing models).

I have a related question. If you start with a replicated deployment (2 clusters with separate meshes) can you then use one of the meshes as a shared control plane for a third cluster?

I have a related question. If you start with a replicated deployment (2 clusters with separate meshes) can you then use one of the meshes as a shared control plane for a third cluster?

To be clear, replicated control planes don't imply "separate meshes". A separate mesh typically implies a lot of other things (e.g. separate trust domain). In general, when we talk about shared vs replicated control planes, we mean that it's all a single mesh.
But to the question regarding adding a new cluster as "shared" ... Yes, absolutely. I had discussed an approach a while back with @rcaballeromx about the possibility of changing the way we document installations so that they are more "legos". The idea is:

Start with a single cluster with a control plane
Then, add a cluster to transition to another state. Here we have options for same/different network, or have a shared/replicated control plane.
From that point, adding yet another cluster is just rinse and repeat (for the most part).

This may be an option to help simplify our installation docs a bit.

@nmittler you are correct. I should have been more clear there I start with one logical service mesh with replicated control planes (shared trust).
Having the documentation where you can assemble your service mesh like legos over time would be nice. Today the documentation reads as if you are always starting from scratch and building exactly what you need from day one which is unrealistic for most users.

An initial validation through of setting up 2 clusters with multi-network and each cluster has its own istiod for xDS serving, sidecar injector and CA, it looks positive and working on IKS.  No need to create service entries in this model and endpoints are auto discovered across 2 clusters
I haven't got locality lb working which I think it is due to my clusters are both in the same zone.  I will spin another cluster in a different zone and try that too so we can ensure we use local service first and fail over to cluster in different zone/region when local isn't avail.

@ayj thank you for the steps, they were very helpful

@linsun Just curious, how do you access the service in remote cluster - more interested in how DNS works for cluster.local vs .global without service entry?

@ramaraochavali this is an area for development. Prototypes from the 1.1 branch show routing crashes when route discovery takes place with a replicated service in the replicated control plane collide. Please see this issue for more context: https://github.com/istio/istio/issues/13045. I suspect this is what @linsun was speaking about.
Cheers
-steve

@ramaraochavali @sdake If you are using multiple clusters for service failover or cross cluster routing scenarios, you will most likely have the same service in the same namespace in cluster 1 and cluster 2.  That would create the DNS entries and istio can help you with endpoint discoveries by watching kube API servers from remote clusters similarly as what is described in the "shared control plane multicluster model" except each cluster will have its own control plane.

@sdake Thank you for the details. Will take a look
@linsun The use case I was thinking is cross cluster routing i.e. foo in cluster1 -> bar in cluster 2. So IIUC, you are suggesting that foo,bar both should be in cluster1, cluster2. Is that correct?

This issue is addressed in 1.8: https://preliminary.istio.io/latest/docs/setup/install/multicluster/
Also related: https://preliminary.istio.io/latest/blog/2020/dns-proxy/


[10.0 - pos_longpoll] Adding new table doesn't sync real-time

Open table page in POS restaurant mode on two windows.
Add one table on a window. The recent added table doesn't appear in another window until I refresh it.
Thank you.

Hi @toeh101
we don't consider this as a bug. Table adding is not something you need to do every day. You can setup it once and just restart POS (refresh page).
But I see a problem here, that user may expect that tables are synced too. We consider it as low priority. One can sponsor it via bounty to speed it up


Capturing Raven Errors

Supposing I am unable to contact the Sentry server, Raven will log that it was unable to contact the server:
jruby-1.7.19 :013 > Raven.send_event({:hello => :world})
D, [2015-10-12T20:40:28.383000 #70394] DEBUG -- : ** [Raven] Sending event  to Sentry
D, [2015-10-12T20:40:28.397000 #70394] DEBUG -- : ** [Raven] Raven HTTP Transport connecting to http://example.com
W, [2015-10-12T20:40:29.501000 #70394]  WARN -- : ** [Raven] Error from Sentry server (404): <?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

		<title>404 - Not Found</title>

404 - Not Found

 => {:hello=>:world}

Is there some callback that I can register when Raven encounters an error? I would love to be able to fall-back to attempt to send an error email when Raven cannot reach a Sentry server.
Thank you kindly for maintaining this gem.

I like the idea. We could let you define a Proc to be called when we give up on sending an event.


Review registry trusting process

Currently, the trust_internal_registry just adds the CA to the host itself, but documentation:
https://docs.openshift.com/container-platform/4.10/cicd/builds/setting-up-trusted-ca.html
States that a configmap should be created and used to patch the OpenShift image config
Related with #382

:tada: This issue has been resolved in version 1.8.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


#518 feat(secrets): add support for Secrets

Add overview of secrets
Add inspect secret
Add create secret
Add remove secret

This PR also adds the ApiVersion to the rootScope to allow hiding / disabling certain features based on API version.
Secrets are not visible in the sidebar if the ApiVersion is below 1.24.
Close #518

@Glowbal join me on Slack when you're available

@Glowbal could you rebase this one on develop so I can start reviewing the changes? Obviously, changes will be required (amongst others, apiVersion is now part of the state available via StateManager thus the ApiVersion is not required).

@deviantony branch has been rebased

I'm having issues with this PR.
First one (style issue), the empty entity text is not aligned in the secrets view:

Second one, I'm not able to access the secret-creation view:

I'll do a quick tech review that may point to some issues.

Looks like the rebase went wrong. Will fix.

@Glowbal could you fix the conflict ?

First issue, when trying to access the secrets view on a Docker standalone:

Docker secrets can only be managed in Swarm mode, add an extra check to ensure the secrets section is displayed in the sidebar only when the endpoint provider is Swarm mode.

@Glowbal I've fixed the conflicts.

Hey @Glowbal
Would it be possible to add the ability to map a secret when creating a service in this PR?
A few things:

In the service-details view, missing Secrets section in the quick navigation bar

In the service-details view, the action header and delete action are not aligned

Would it be possible to add the ability to map a secret when creating a service in this PR?

Yes, I am going to work on that next.

@Glowbal could you fix the conflicts?

Rebase went wrong - I will fix this shortly.

I've solved the conflicts related to the latest PRs merged.

@deviantony I've made the requested changes.

Status / ETA? I can lend a hand if need be

First thing to do here is to rebase this PR. I'll try to handle this soon.

Replaced by #894


Async operations

Thank you for this nice library.
I see that all your functions are sync. Is there any plan to provide async commands ?

Yes, theres a plan to move to async commands, but I've got no timeframe yet.

I agree, with @Paul-DS , it will be great if you move functions to async mode, especially download function ...


feat: mark python doc pseudo-code blocks with a tag

if you're looking at ```python blocks in a file, it can be easy to end up thinking these doc blocs represent runnable code, when in fact they're just pseudocode that looks nice with syntax highlighting.

:tada: This PR is included in version 0.7.22 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


#1: add support for horses in database initialization

listo

/paulo - can you please review this pull request?

/paulo - can you check now?


Create pr-signing.md, a guide for signing PRs

Includes basic instructions on setting up GPG/SSH keys and submitting/signing PRs on the kubestellar github

Summary
Related issue(s)
Fixes #

/ok-to-test

@JonathanWentaoBao remember to add 🐛 to the title of a PR

Actually it should be ✨for this because it is a new feature.

Actually it should be ✨for this because it is a new feature.

Sorry, will update now

Thanks. Every document should be referenced from the navigation tree in docs/mkdocs.yml. Also, I suspect that this document should be referenced from a higher level document about making contributions.


Update binary to v0.8.0

Thanks!

@kevva @sindresorhus Can we tag a release with this?

@arthurvr, done.

Thanks.


Point to jest-extended in .extend

Codecov Report

Merging #7969 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7969   +/-   ##
=======================================
  Coverage   64.78%   64.78%
=======================================
  Files         256      256
  Lines       10045    10045
  Branches     1466     1466
=======================================
  Hits         6508     6508
  Misses       3218     3218
  Partials      319      319

Continue to review full report at Codecov.

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

Thanks for the contribution.
jest-extended is already mentioned at the top of the expect docs, but I'm not opposed to adding another reference right in the expect.extend section.
Could you update the versioned_docs for 22-24 with this change as well?

I think the mention at the top is enough - no reason to link to it twice in the same document. It's also quite prominent

Thanks for the PR though!

I had no idea about jest-extended, and never saw the mention at the top.
I think the assumption here is that Jest users will read the document top-to-bottom. In practice, I think they're more likely to google for something like "Jest toXXX", and jump directly to that section of the page.

That's certainly how I operate, and while I did read this expect API page a long while ago top-to-bottom, I haven't since the mention of jest-extend was added at the top.
In the light of how many users are likely to land on the "extend" section when they do a web search for that, I would suggest mentioning jest-extend in that section as well. What do we have to lose?