How to use circuit-knitting-toolbox to cut circuits that are not fully connected

I'm trying to use the circuit-knitting-toolbox to cut a circuit that is not fully connected, but I'm having some problems cutting this circuit.
This is the circuit I want to cut

Here are some of the conditions I've set up for the subcircuits
cuts = cut_circuit_wires(
    circuit = test_circuit,
    method="automatic",
    max_subcircuit_width=5,
    max_cuts=5,
    num_subcircuits=[i for i in range(test_circuit.num_qubits)],
)

But something went wrong.

What is the cause of this and how can I fix it?

Hi @hang-dev , we have been seeing several different problems with cutqc. It is legacy software, and we are trying to migrate users to the newer wire cutting functionality.
We also have an implementation of an automat cut-finder which supports both gates and wire cuts in a branch here, which should be available in the upcoming release.
We'd like to know whether this new package suits your needs.

Closing all CutQC issues now that it has been removed.


Video Metadata

Could adding the program/season/episode/episode name to the video metadata title and the episode description to metadata description be posible?

@kikoreta is now in the new version v1.4.25

Thanks, downloaded and tested, works like a charm, adding a language selector for the description could be possible?

Tested and working correctly, thanks

Hi, I just want to ask where the episode description is saved to the metadata? I use v1.4.29 and enabled episode description in the settings and if i download something there is no description saved? Could it be because it don´t work with german language?  In case 1, it would be nice if someone could enlighten me :D

tthe problem here is that you are creating mp4 files - i haven't added the description muxing to that

Ah, makes sense.

but i just added it so it's in the next release

nice, thank you very much 👍


Unit test failures (in BIP-39) when building for Windows.

Description
Pursuant to #133 (and using that PR as HEAD) built the SDK in release configuration using CMake's Visual Studio 17 2022 Generator.  Got unit test failures, log attached.
:
(N.B: Running hedera-sdk-cpp-tests passes all tests.  There's a difference between ctest and hedera-sdk-cpp-tests ...)
Steps to reproduce
Having built the SDK per instructions in the README, do ctest --config Release and see the failures as in the attached log.
Additional context
sdk-ctest-fail.log
Hedera network
testnet
Version
pre-release SDK
Operating system
Windows

Addressed in #138 .


xdg-foreign: add implementation

Closes #1702
Sway branch for testing is here: cyclopsian/sway:xdg-foreign
To test, run portal-test or some other flatpak application that uses the desktop portal. Make the application fullscreen in sway and open a file dialog. Before these patches, the file dialogs would appear behind the fullscreen surface since toplevel->parent was not being set.
Both versions are supported because Mutter/GTK uses v1 and KWayland uses v2.
Possible changes that should be made (feedback requested):

Combine the v1 and v2 implementations instead of copying the file? Both implementations are exactly the same.
Use an actually secure way of generating handles, maybe use libuuid?
Store the handles in a hash table?

Combine the v1 and v2 implementations instead of copying the file? Both implementations are exactly the same.

Please keep them separate. It makes it easier to drop v1 when needed.
I wonder if it makes sense to have v1 at all. It would be nicer to update GTK to use v2.

Use an actually secure way of generating handles, maybe use libuuid?

Yeah, sounds like a good idea.

Store the handles in a hash table?

Let's keep this for later.

libuuid is, annoyingly, part of util-linux and not the most portable thing in the world. Can we instead set up a file full of platform-specific getrandom implementations, with a fallback that uses psuedorandom numbers?

I thought it was fine because FreeBSD has it: https://www.freshports.org/misc/e2fsprogs-libuuid/

Well, I don't want to make the porting story even more difficult for new platforms. Maybe we make it optional and just disable xdg-foreign if it's not supported?

Fine by me

The C libraries on FreeBSD, OpenBSD, NetBSD all implement uuid generation functions, so libuuid is not necessary there. Is there anything else that needs to be supported?

The alternative is to use getrandom on linux and arc4random on the BSDs. We probably should just do that to avoid any external dependencies.

Nah, I'd rather use a UUID. Let's add a shim somewhere, choose the appropriate implementation based on the platform, and fallback to removing xdg-foreign support on unsupported platforms.

This PR has been updated with UUIDs and with fixes for some bugs and crashes. Now the build will check for libuuid (preferred) or uuid_create. If neither is found, it disables xdg-foreign. This can be checked with  WLR_HAS_XDG_FOREIGN in wlr/config.h. The sway branch I made has been updated to reflect this.
For verification I've been using a test program to try out destroying and unexporting the parent windows while they still have imported handles open. It's GTK so it tests with the v1 protocol. The code is exactly the same between v1 and v2 so this should be adequate. Eventually I may get around to sending patches to GTK and Mutter to support v2.

Nice. Can you make an issue for tracking the status of v1 support throughout the ecosystem so we can manage its deprecation?

@ddevault I am working on getting v2 support merged into Mutter and GTK, do you want me to make the issue now?

Don't merge this yet, the two versions of the same protocol need to refer to the same data structures internally. Otherwise things will just silently not work e.g. if a program inside a flatpak speaks v1 and the importing program speaks v2.

Gentle ping: do you plan to continue working on this PR anytime soon?

I'm honestly not sure if there is a clean way to do this. Supporting both versions really complicates the code for very little benefit (the only change between v1 and v2 is the name of some symbols) and it seems like the easiest thing to do is just say with v1.

I'd prefer to only support v2. But this doesn't fix the root issue: we'll need an upgrade path for v3 or the stable version of the protocol.
Maybe it would make sense to make v1 lean on v2, ie. make wlr_xdg_foreign_v1_create take a wlr_xdg_foreign_v2 as an argument and re-use its data structures? But then v2 will get to see v1 resources, not great. Except if we add a way to register new xdg_foreign_v2 entries without providing a resource (this increases complexity).

Maybe it would make sense to make v1 lean on v2, ie. make wlr_xdg_foreign_v1_create take a wlr_xdg_foreign_v2 as an argument and re-use its data structures?

What about using an impl struct which does the correct call to either v1 or v2? And then uniting the support for v1 and v2 in the same wlroots object(s). It is unlikely that a compositor wants to export v1 but not v2 or vice-versa.

But then v2 will get to see v1 resources, not great.

Could this be resolved by adding a tag to each object, whether it belongs to v1, v2 or potentially v3/stable?
Then, if v2 client wants to set parent which uses v1, this could be denied.

I'd prefer to only support v2. But this doesn't fix the root issue: we'll need an upgrade path for v3 or the stable version of the protocol.
Maybe it would make sense to make v1 lean on v2, ie. make wlr_xdg_foreign_v1_create take a wlr_xdg_foreign_v2 as an argument and re-use its data structures? But then v2 will get to see v1 resources, not great. Except if we add a way to register new xdg_foreign_v2 entries without providing a resource (this increases complexity).

Alternatively, you could introduce a new type that is basically a hash table (handle -> wlr_surface), e.g. wlr_foreign_registry, and make wlr_xdg_foreign_v1_create() and wlr_xdg_foreign_v2_create() take it.
However, it raises a philosophical question: do we actually want different versions of the same protocol have compatibility. Currently, both v1 and v2 are very similar, but it's not guaranteed with future versions (hopefully, there won't be that many).

However, it raises a philosophical question: do we actually want different versions of the same protocol have compatibility. Currently, both v1 and v2 are very similar, but it's not guaranteed with future versions (hopefully, there won't be that many).

I've also thought about that, are there any compositors that support both v1 and v2? Do they allow this or not?

GNOME is going to let clients mix the two protocols, from IRC:

10:40:58 <ammen99_> jadahl: do you plan to allow clients to use v1 and v2 mixed?
10:41:05 <ammen99_> i.e one exports v1 and other imports with v2
10:41:21  ammen99_: yes

I suppose the use-case would be one older application from flatpak and a modern portal impl or something like that.

If we really wanted to support both, we could for instance make v1 an "add-on" for v2: all of the data structures live in v2, and v1 is just a proxy to v2.

Having v1 and v2 has two completely separate files makes it easy to remove v1 once everybody has migrated to v2. It's not unheard of for a compositor to drop v1 and keep v2, for instance Sway has removed xdg-shell-unstable-v6 support while wlroots still supports it.

Alternatively, you could introduce a new type that is basically a hash table (handle -> wlr_surface), e.g. wlr_foreign_registry, and make wlr_xdg_foreign_v1_create() and wlr_xdg_foreign_v2_create() take it.

Sounds like a reasonable idea as well, and more or less matches what we've done for e.g. primary selection.
@ammen99 @zzag If you want to move this forward, feel free to adopt this PR, I don't think @cyclopsian has plans to resume work in the near future.

Superseded by https://github.com/swaywm/wlroots/pull/2487

Superseded by https://github.com/swaywm/wlroots/pull/2487


PyPI tar file misses *.pyx file, causing pip install python-stratify to fail

Installation through PyPI (e.g., using pip) may fail when a wheel is not available. Pip will attempt to download and untar the file from PyPI, then build the project. Even with Cython available (i.e., this issue is independent of #25), the project can't be build, because of its dependence on the relevant *.pyx files: the C-files by themselves are not enough to automatically build the project with the current setup.py.
My guess is that either

setup.py needs to include the *.c files directly, and not the *.pyx (nor "cythonize" them; this would also fix #25)
the *.pyx need to be included instead of the *.c files

to fix this issue.

@evertrol Thanks for raising this.
Okay time to address these related installation issues...

Ping @evertrol - closed by https://github.com/SciTools-incubator/python-stratify/pull/29
I'll be tagging a patch release and updating PyPI and conda-forge with the fix :smile:

@evertrol The latest python-stratify version 0.1.1 which addresses this issue is now available on conda-forge and PyPI


IP command should not break when new fields are added to the JSON results in the REST API

As far as I can tell, nothing "breaks" when additional data is added to a response, with the exception of the fact that the text formatter will only display defined/known response fields.  If the -f switch is used, the XML and JSON responses return all data.  Closing for now and will reopen if this becomes an issue again.


redirection not working on ios safari

Login with google for instance goes into the whole process but get stuck on the redirection page from the backend, seems that postMessage is not sent to the new tab till the origin tab is in focus.
just posted a related question in so: http://stackoverflow.com/questions/31007374/window-postmessage-to-a-new-tab-in-ios-safari?stw=2

this is fixed on ios 8

I have the same problem, did you found any solution to this?

yes, the problem is that the auth_headers was not set properly, what i did is setting by hand after authenticate or submit login like this:
$auth.authenticate(provider)
        .then(function(resp) {
          ipCookie('auth_headers', {
            // save the token
            'Authorization': 'Token ' + resp['auth_token'],
            'uid': resp['uid'],
            'expiry': resp['expiry']
          });
        })

From where the ipCookie function?

https://github.com/lynndylanhurley/ng-token-auth#why-does-this-module-use-ipcookies-instead-of-ngcookies

I did this in ios 8.1 and it is not seem to work?


H1: Byte Counting Fix

Commit Message: Fix H1 byte counting due to not correctly moving the bytes meter to the stream when the stream starts.
Additional Description: We ended up invoking the copy constructor and not the move constructor => the connection level byte meter sticks before stream starts ends up accumulating bytes
Risk Level: low
Testing: integration tests using multiple req / response
Docs Changes: NA
Release Notes: NA
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @yanavlasov

/retest

/retest

/retest

/retest

/retest

/retest


build(global): enable aggressive closure optimization

Description:
This PR enables 'ADVANCED' optimization in closure compiler to generate more compressed minified global build.
Size comparsion:

gain around ~30kb of more compression.
I'm marking it as BLOCKED - cause there isn't reliable way to validate regressions of this optimization. I have filed related issue https://github.com/ReactiveX/rxjs/issues/2229, which'll allow to test global builds correctly on browsers.
Related issue (if exists):
https://github.com/ReactiveX/rxjs/issues/2229
https://github.com/ReactiveX/rxjs/pull/2227
https://github.com/ReactiveX/rxjs/pull/2225

Coverage remained the same at 97.69% when pulling 42e98743722d7a9aa202384128ba58756b268161 on kwonoj:chore-closure into 6922b16f4a297a4acbe8ad2b086c947b7c0d8315 on ReactiveX:master.

nice looking forward to this!

@kwonoj do you think we could validate regressions by somehow building and running the specs against the this optimized build? This seems like something we should prioritize.

As noted in PR, I already filed https://github.com/ReactiveX/rxjs/issues/2229 to change browser testing's target to use UMD build instead of CJS. I gave a quick shot and found it wasn't trivial though.

I'm going to close this for now and reopen once we have pipeline for testing against browser.


documentation/blog/usage-guide

Is there any blog out there which shows some use cases and examples for this extension?
The test/test.sql file is marginally useful.  The kissfft documentation doesn't really help at all.

Hi Rick,
I wrote this module years ago and actually I cannot recall my memories about pgfft. In the next week when I return from my summer holiday I will reread the stuff and try to help you.


Add test that client / CLI work with configs containing unknown modules

https://github.com/fedimint/fedimint/pull/2030#discussion_r1149884453 made it so CLI doesn't fail if it encounters unknown module ...

How's progress @Aankirz?

Still working on it , sorry for the delay 😔


Unfinished transactions are not restored on iOS

If anything bad is occurred during handling transaction in observer (like NPE, out of memory, shutdown of the device, or any other unexpected exit from the app), then transaction is not marked as finished. The consequences are:

You spent your money and gets nothing back
If you try to buy the same item (in hope it will be bought this time), you gets the message: "This item is already bought, you will get it for free.", then you press OK and nothing happens. If you press again to buy the item, it shows the same message. Even if you reinstall the app, it will not help.

It is written in the [Apple docs] (https://developer.apple.com/library/ios/documentation/StoreKit/Reference/SKPaymentQueue_Class/#//apple_ref/occ/instm/SKPaymentQueue/addTransactionObserver:), SQPaymentQueue should be called right at the app start, before any other action is performed with the queue. In the current version the transaction observer is set up after product information is fetched. I have tried to change gdx-pay to setup observer right inside PurchaseManager.install method and this helped to finish the transaction and get my gems, which I have paid for.
But the problem is SKPaymentQueue restores unfinished transactions before we have any information about products (like price and currency), which is required to fill gdxpay.Transaction object (see PurchaseManageriOSApple.transaction(SKPaymentTransaction)). So, seems it is kind of a dead loop.
Seems to fix this bug, we need an architectural change. Or do you have any other ideas?

I would generally think we should not do architectural changes unless it makes things either easier for the end-user (developer's that use gdx-pay) or we identify a problem that cannot be solved otherwise (bad architecture).
I have to admit I haven't looked much at the iOS backend.

But the problem is SKPaymentQueue restores unfinished transactions before we have any information about products (like price and currency), which is required to fill gdxpay.Transaction object (see PurchaseManageriOSApple.transaction(SKPaymentTransaction)). So, seems it is kind of a dead loop.

Seems to fix this bug, we need an architectural change. Or do you have any other ideas?

Could we just cache the unfinished transactions that are returned via SKPaymentQueue whenever our product information such as price & currencies are not available (yet)? Once we have the information available that's when we build our transaction object and finally notify about it/confirm delivery. I believe that should work?

Unfortunately no, because iOS requires to finish transactions right only
inside the observer's method, so still before we have any products
information.
We could however try to cache product info before the potential crash on
the disk. Right after we got it from Apple. That will not save us from all
possible cases, like: no space on the device, or user reinstalled the app.
But those are more unusual. In case no information is cached, we could just
pass 0.0 as a price and empty string as a currency, because anyway if user
reinstalled an app, we can't be sure which price was used to buy a product.

Not all transactions return price/currency information as documented in Transaction.java. For some backends it wasn't possible. In my opinion it is fine to return -1 (!) if the price is not known and 'null' if the currency is not know.
In my opinion that's fine. I store transactions on my server in a database. Although it's nice to have price/currency available where this is supported, leaving both -1/null is not a problem either. What's your take on that?

I send price of transaction to analytics services, so I can analyze users which spend money.
May be it is not so critical case then. So, I would just not provide real price information (-1 and null only) in case of restore of unfinished transactions, because it is unusual in general. Or what do you think?

I would think it will be quite unusual to happen. Also, you need to consider that the network might just go down when you send data to the analysis server, or the analysis server might be done. Also, there could be problems on the analysis server preventing a transaction to be processed. Even transactions with real price information might not make it to the analysis server database all the time.
In any case, we could add functionality to iOS gdx-pay which would query pricing information and only notify of the initially failed transaction once that pricing information is fully available. Still, this doesn't mean that every transaction will be recorded on the analysis server if problems there occur.
Up to you if you want to provide a workaround for the missing pricing information, i.e. query/notify only when pricing is available. I would think though it's somewhat difficult to reproduce/test and wouldn't solve all the problems.

In any case, we could add functionality to iOS gdx-pay which would query pricing information and only notify of the initially failed transaction once that pricing information is fully available.

That would require us to store transaction on the disk, because if we call SKPurchaseQueue.finishTransaction on transaction which is not known to the app yet, then gdx-pay is responsible to deliver it later - that is bad :)
So, I would still prefer to store price information before the purchase (e.g. in PurchaseManageriOSApple.purchase() method) and then use it for unfinished transaction.
But as you wrote, analytics services do not guarantee delivery of all events, so I would just pass -1 as a price in case of unfinished transaction for now. There are more important tasks than perfect fix for this issue!
And I will fix it soon.

Sounds good. Thinking about it, how you describe it, it sounds more of a shortfall of the iOS payment system not being able to obtain pricing information for purchase restores!? Maybe there is a way to still get the pricing information we are just not aware of it? There isn't much we can do on the gdx-pay side even if we were to change the gdx-pay architecture.
In any case, I agree, passing -1/null is fine for now. Not an urgent matter in my opinion.

Maybe there is a way to still get the pricing information we are just not aware of it?
No, I have double checked. But it could be there is a way to query unfinished transactions manually after we have pricing information. Sorry, my fault, I didn't mention this before, I will check it.

So, the fix was much easier than the whole conversation about it! :-D Sorry for your time and thanks for your doubts.

Great fixed - changes merged :-D


Publish m4 and use it instead conf-m4 for opam packages

opam package conf-m4 checks if m4 is available on a system. Instead we can package m4 and use it instead.
https://github.com/esy-ocaml/m4
The problem is that m4 build time is around ~90s~ 53s on my mbp.

Hmm. You could lazily build it if it's not available perhaps.


Add version to reflux object

Hey, I'm working on a older system with an unknown version of reflux which makes it kinda hard to debug stuff.
Is it possible to add a version-property to the reflux object to avoid this problem? Alternatively a banner in the disted files.
On the same note, is it possible to determine version some other way I don't know about? ;)

reflux-core exposes a version number, haven't added it into the refluxjs build yet though. It is in Reflux.version object. Obviously old versions do not expose this, you have to check the package.json file if you have it.

Can't find the package.json, oh well, I'll just upgrade. Thanks for your time :)


[WIP] service should listen on all interfaces

The API service should listen on all interfaces by default.  This hasn't been well tested, please don't merge yet.

Current coverage is 59.76%

Merging #98 into develop will not affect coverage as of b113fc0

@@            develop     #98   diff @@
=======================================
  Files            15      15
  Stmts          2324    2324
  Branches          0       0
  Methods           0       0
=======================================
  Hit            1389    1389
  Partial           0       0
  Missed          935     935

Review entire Coverage Diff as of b113fc0

Powered by Codecov. Updated on successful CI builds.

I'm going to roll this into a bigger PR.  Closing.


Ignore non-commands

Running up url copy results in https://..../copy/
I know the command is a mistake, but probably should be disregarded instead of appended to the output.
Version: v0.1.10

Friendly errors make for the best UX, no matter how much of a weird edge case the user has found

hahah oops yeah I should probably fetch the list of stages instead of blindly adding it

Another instance: up build is treated as a staging name, ergo runs ~~> up deploy build

  Error: deploying: us-west-2: "build" is invalid, must be one of:

  • development
  • staging
  • production


Propose a faster way to compute the hash of an encodable object

I also bumped to the latest version of cryptoxide. There's been a lot of performance improvements that have been made since then and this would be a shame to not leverage this (though it's mostly for Curve25519).
This PR remove the temporary (useless?) serialisation of the Encode-able object.  That way we now have a memory overhead allocation to do the hash.

[ ] there is no way this can fail minicbor::Encoder have only the Write error. In the case of Blake2b being the writeable object, there is not error possible (none we can/should handle in the code. Shall we remove the Result<(), Box<dyn Error>> ?
[ ] shall we have a pallas-crypto with the different crypto utils we will be using in our code?

my take on the above:

allocating memory for the hash was a quick and dirty solution, this is a much better approach.
yes, we should remove the Result wrapper now that the function is no longer fallible.
having a pallas-crypto would be great. Would you mind doing the first pass of the module with what you have in mind?

@scarmuega let me know if this is the right structure

I have kept the pallas_alonzo::crypto module but I remove the crypto feature. It is obviously used everywhere already.

@NicolasDP looks great! feel free to merge at your discretion.


Exception when computing Alternative

I am wondering if this has to do with the update to how the histograms read and write the bin counts to xml.
The issue is that the bin counts is 0.

I am using the Beargrass Creek study.

@rnugent3 Is it possible to have bin counts of zero? I'm thinking that maybe this is an issue when using studies that where created before the recent xml change.

bin counts of zero shouldn't be a problem.

what is the index in the image above?

@codymccoy would you send me the study?

@rnugent3 I think you were the one that sent it to me:

HEC-FDA_Version-2_Study.zip

I tried re-computing the "without" scenarios which was successful and then i tried computing the alternative and ran into a divide by zero:

oh boy. I am looking into it.

I am successfully computing scenarios and alternatives on main

ok, interesting. I bet it has something to do with the xml code that I changed then.

I think i have fixed this issue. I had changed the way the bin counts write and read to xml and didn't support the old way that it was reading from xml. I added an "else" statement that uses the old way. I made this change to both histogram and threadsafeInline...

This is fixed on branch Update_Index

confirmed to work as expected


Plot.auto_scale() shouldn't change the camera aspect unless desired

@ArjunPutcha @clewis7 Note that this changes the behavior of auto_scale(). See: https://github.com/fastplotlib/fastplotlib/pull/364/files#diff-2a0f782c81512ab17081f35fd6cac201fafd429eded696cb76981946bc6baaecR511-R513


Tutorial reviewed and ready for deploy

@acamino @shyba this is ready

is this still the link for full tutorial?
https://www.twilio.com/docs/tutorials/walkthrough/task-router/node/express
Im having some hiccups (when I call i get the bland 'There is an error').
The one on the twilio page that refers to this is not very helpful either.

Thanks for pointing that out @coding-saints. The issue was fixed here.


BronsonAVLTreeMap Usage

I am having trouble with setting up the BronsonAVLTreeMap. In particular, I observe this assertion failure:
map_test: /home/parallels/git/peloton/third_party/libcds/cds/urcu/details/gp.h:94: static bool cds::urcu::details::gp_thread_gc<GPRCUtag>::is_locked() [with GPRCUtag = cds::urcu::general_buffered_tag]: Assertion `pRec != nullptr' failed.

Relevant code snippets:
// HEADER FILE

#include "libcds/cds/init.h"
#include "libcds/cds/urcu/general_buffered.h"
#include "libcds/cds/sync/pool_monitor.h"
#include "libcds/cds/memory/vyukov_queue_pool.h"
#include "libcds/cds/container/bronson_avltree_map_rcu.h"

  // rcu implementation
  typedef cds::urcu::general_buffered<> RCUImpl;

  // rcu type
  typedef cds::urcu::gc<RCUImpl> RCUType;

  typedef cds::container::BronsonAVLTreeMap<RCUType, KeyType, MappedType> avl_tree_t;

// SOURCE FILE

MAP_TEMPLATE_ARGUMENTS
MAP_TYPE::Map(){

  // Create URCU general_buffered singleton
  RCUImpl::Construct();

}

MAP_TEMPLATE_ARGUMENTS
MAP_TYPE::~Map(){

  // Destroy URCU general_buffered singleton
  RCUImpl::Destruct();

}

// TEST FILE

TEST_F(MapTest, BasicTest) {
  size_t const element_count = 3;

  // Initialize CDS library
  cds::Initialize();

  typedef uint32_t  key_type;
  typedef uint32_t  value_type;
  typedef uint32_t* value_ptr_type;

  {
    // Attach thread
    cds::threading::Manager::attachThread();

    Map<key_type, value_type> map;

    for (size_t element = 0; element < element_count; ++element ) {
      value_ptr_type val = new value_type(element);
      auto status = map.Insert(element, val);
    }

    EXPECT_EQ(map.GetSize(), element_count);

    // Detach thread
    cds::threading::Manager::detachThread();
  }

  // Terminate CDS library
  cds::Terminate();

}

Any pointers would be helpful. Thanks.

Hi,
You should construct RCU before attachThread():
 // Initialize CDS library
  cds::Initialize();

{
    // Initialize RCU
    RCUType rcu;

    // Attach thread
    cds::threading::Manager::attachThread();

   // now yu can do all you need
   ....

    // Detach thread
    cds::threading::Manager::detachThread();
}

// Terminate CDS library
cds::Terminate();

When you call attachThread() all gc (RCU, HP) must be created

Yes, that fixed it. Thanks. Is there any reason why the container currently does not support iterators ?
We could construct one based on succNode in the paper.
http://arsenalfc.stanford.edu/papers/ppopp207-bronson.pdf

Iterators in concurrent data structs are tricky.
At the first glance, it is simple for Bronson's AVLtree under RCU. Maybe, I'll implement it in the future.
Now I'm thinking about iterators in list-based structs like MichaelMap/SplitList/SkipList. Today it is more interesing for me.

Sure, I will give it a try. Sounds good.


massif.la website seems down/unreachable?

I tried going to https://massif.la/ja and it seems like the website is timing out. Not sure if it's a DNS issue but I am getting ERR_NAME_NOT_RESOLVED
Just in case you weren't aware.

Same here

I'm not able to reproduce this, it's working fine for me. I had a couple people in other countries check and it works for them currently as well. Are you still seeing this problem? Maybe it was transient.

It's back for me as well

Yup, I can confirm it's back for me as well. Maybe it was a temporary DNS issue. I guess we can close this?

Cool, thanks for reporting tho.


organise all imports

What type of PR is this? (check all applicable)

[x] Refactor
[x] Optimization

Description
Optimized codebase by organizing and consolidating imports for improved code maintainability and readability.
Featured Covered in this PR

[x] Organise all imports

Hi @3kdeveloper , thank you for your contribution, and I really appreciate your effort. I wanted to share my thoughts on adding barrel files to our project. Let's consider both the advantages and potential challenges (feel free to add any points that I may have missed):
Pros:

Simplified imports, which can enhance code readability.

Cons:

Import collisions can be difficult to solve as same export file is imported at multiple places.
Barrel files might reduce flexibility, as Flutter provides excellent intellisense for adding automatic imports, a feature that wouldn't be possible with barrel files. Manually adding new imports to respective barrel files may introduce some overhead.
If different export files contain the same package imports, conflicts may occur when importing multiple export files.

While structured barrel files can be highly beneficial in larger projects, our project's folder structure is still evolving as we continue to add more features. Given this, now might not be the ideal time to introduce barrel files.
I'll keep your pull request open, and once we've established a stable set of features (likely by the end of this month), we'll be in a better position to consider the integration of barrel files. I also recommend raising any issues you encounter before contributing pull requests to ensure we're on the same page.
Once again, thank you for your valuable contribution!


[ci skip] adding user @cosmicBboy

Hi! This is the friendly automated conda-forge-webservice.
I've added user @cosmicBboy as instructed in #32.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #32

Welcome aboard, glad to have you.
This feedstock isn't yet in automerge mode (see #10) as y'all make relatively frequent changes to a few hard to manage deps in your release process (protobuf/grpcio) and do some relatively aggressive library version pinning. We're starting to tackle this via grayskull-based autoticks (#30), however I want to make sure these are stable for a few releases before letting this shift to automerge.
There were a few wrinkles here bringing y'all onboard as maintainers, notably a few footguns around version ticks, fork status, etc. These are documented obliquely in the PR checklist process but easy to stumble across, and most of these admin tasks should be run via conda-forge autocommands.
Please read the checklists very carefully during PR updates and other maintainers in quickly via @ mention if there's any ambiguity.

great, thanks @asford!


Update quickstart.rst

The quickstart docs include a deprecated argument. PR changes no-comments example to use output_format="xml" as opposed to xml_output=True.

Hi @dsgibbons, good catch, thanks!


need docs around version

accomodate both semver and iso dates.
lexographical sorting is the goal? inspiration from trust establishment.

has been merged.


Consider defining a bean of type 'com.auth0.jwt.JWTVerifier' in your configuration.

start error：
Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
Disconnected from the target VM, address: '<IP_ADDRESS>:62095', transport: 'socket'
2018-05-31 20:15:17.522 ERROR 10627 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of constructor in com.acm.infra.proxy.JWTFilter required a bean of type 'com.auth0.jwt.JWTVerifier' that could not be found.

Action:

Consider defining a bean of type 'com.auth0.jwt.JWTVerifier' in your configuration.

@csimplestring

@SoftwareKing Did you find any solution to the error?

@DsNextValue No

the same probleam


Connect the sash in the 2x2 grid

Testing #50458

open the 'grid 2x2' layout
move the horizontal sash: The sash only moves in one side.

It would be great if sash on the other side also moves so that the two sashed stay aligned.

Depends on the grid widget providing a way for me to build a grid layout where views are connected instead of split. I think for the beginning we could do this as a one-off for the "Grid 2x2" layout.

Started some work here: https://github.com/Microsoft/vscode/tree/joao/grid2x2
It's, of course, tougher than expected... but I think we can get something nice going.

Fixed by f9911c7446a997e9294d1612b02279741e0a9775


Feature: Add styling options to Markdown toolbar

We have the use-case that we are using the Markdown editor with technical as well as non-technical users.
The non-technical users sometimes find it a bit difficult to use the Markdown markup.
This pull request adds buttons for the following markups in the Markdown editor:

Headline
Bold
Italic
Strikethrough
Bulleted List
Numbered List

Additionally it adds a kind of snippet function to insert the following things with it:

Table
Collapsible Sections
Callouts (Info, Success, Warning, Danger)

The whole thing looks like this:

Dropdown with snippets:

In small resolutions, however, the buttons are hidden:

What do you think of the solution?
Should I adjust/remove something?

Thanks for offering this PR @phsteffen.
To be honest though, without diving specifically into the technical implementation at all, I'm not totally sure about the idea of including this as a feature.
Our primary focus for non-technical users has always been the WYSIWYG editor, with the markdown editor available to those technical enough to prefer it. I originally built BookStack as a platform to avoid non-technical users having to understand/learn specific syntax. This changes the scope an intention of the markdown editor from being technical-user focused to also, along with WYSIWYG editor, being all-technical-skill focused. I'm just not sure on that re-focusing being a good idea and/or worthwhile.  While the surface area of the PR isn't that wide as-is, It still has an impact to maintenance and the expectations of the issues and features we'd further support. In addition, if we go down this path I feel there'd be an expectation that the controls and usability matches that provided in the WYSIWYG editor, in which case quite a few more controls would need to be added to align.
To help my understand the requirement better: for your use-case, what requires the need for the markdown editor rather than just using the WYSIWYG editor?

This PR related to #1663 but the state of that issue is somewhat different nowadays, since we added the ability to jump between editors.

I would love to have this toolbar added to the markdown editor.
I write markdown way faster than using the WYSIWYG editor and it's very easy to use markdown written somewhere else and just paste it into the editor and bam, you're done.
But I sometimes don't remember specific markdown commands like how to create tables or strike-throughs. I then have to go to https://www.markdownguide.org and search there until I find what i was looking for.
Having these added to the toolbar as shortcuts would help a lot for things the user don't remember.

I'd like to see a toolbar like this :)
With my little brain i sometimes forget the syntax too :)
I agree that i could use the WYSIWYG editor, but more and more people use markdown, even beginner, so it would help.
And on page with different author, it would/may avoid, switching from MD to WYSIWYG to MD to WYSIWYG etc...
My 2 cents :)

I'm going to go ahead and close this off as per my last message.
@EmberLightVFX @gauthiersiri Thanks for your input. It'd be worth copying your thoughts to #1663, to help indicate desire for such a feature and to provide context as we can think about various solutions to suit needs. Sounds like just having a simple built-in syntax reference guide might meet most of your needs while having a relatively small maintenance impact on the project.

Too bad it got closed and not merged. Added my thoughts to the issue you linked and hoping it will get added later down the line.


[OP-79] Add automatic low-pass filter to Coulomb peak analysis

add low-pass filtering code
add automatic filtering to Coulomb peak analysis
Add example notebook for low-pass filtering

Replaced by #641


Refactor CodingStack

Organize the available status informations better

Generalize the interface CodingStack provides. Sample:
public protocol CodingStorage {

    // TODO: has multiple metas on stack or similar (rather similar)

    /**
     Access a meta at the given coding path.
     */
    subscript(codingPath: [CodingKey]) -> Meta { get set }

    func bind(meta: Meta, to codingPath: [CodingKey]) throws
    func bindPlaceholder(to codingPath: [CodingKey]) throws
    func remove(from codingPath: [CodingKey]) throws -> Meta

    func lock(codingPath: [CodingKey])
    func unlock(codingPath: [CodingKey])

}

Right now the protocolisation is pretty useless.
The refactored version could leave the implementation details open and just access metas by the coding path associated with them.
However the only scenario I can imagine, in which this would be useful, would be parallelised encoding/decoding. I don't know If anyone ever want's to do something like this, but with a parallelised coding storage multiple encoders could encode properties of one object (each holding their current coding path). This should then actually be possible without overriding MetaEncoder, if such a coding storage is implemented.
There are however a few more important issues, that relate to the CodingStack protocol.

mayPopMeta is used to check that a meta was pushed and the coding path extended (which is does not tell) (this is what the lock methods are for)
count is abused to check whether encoding has succeeded.
status is a mess. (this is partially resolved with the removal of the unused properties)
the PlaceholderMeta is far from optimal


dat.close not closing database (seg faults often)

Something in a recent hyperdrive/hypercore update (I think) made it so we are getting segfaults on db.close() a lot and close isn't calling back. I noticed this first in PR #95 but have not been able to diagnose it (or fix it).
I tried taking out db.close() and doing it manually later but it still wasn't closing.

It happened in this commit/release for hyperdrive https://github.com/mafintosh/hyperdrive/commit/eb0b9fe150fcbd5c595e342eb55855fb4987dc4b

In my understanding different changes like the one above just make it more or less likely for the segfault to appear, but none are fixing the real issue, which most likely lies in leveldown still.
Fortunately we're switching to SLEEP :) Until then though, do we even have the resources to debug leveldown code? Or would something like using dat-worker in the cli and other projects be a good intermediate solution.

I don't think it should segfault anymore because we don't use leveldb.


Vue compiler emits DUPLICATE_ATTRIBUTE error instead of ignoring duplicates

Version
3.2.20
Reproduction link
codesandbox.io
Steps to reproduce
run node src/index.js in terminal
What is expected?
According to HTML5 spec
https://html.spec.whatwg.org/multipage/parsing.html#parse-error-duplicate-attribute
parser should ignore all duplicates
What is actually happening?
Parser throws SyntaxError("Duplicate attribute.")

This problem doesn't affect work in browser or SSR with @vue/server-renderer, only prints warning. However, in vite-plugin-ssr this error causes render to fail. I understand that duplicated attributes is something abnormal but in some cases (https://github.com/vuejs/vue/issues/10837) they can occur.

The Vue 2 issue you linked to seems to be a bug in Vue 2's scoped ID handling, can you replicate the behavior in Vue 3?
Even if the same issue can be reproduced in Vue 3, it should be fixed as a scoped ID bug. There should still be no duplicated attributes and IMO it's better to warn the user instead of silently ignoring it. Alignment with HTML5 isn't a goal here since technically HTML5 will silently allow anything.

I do have the mentioned Vue 2 bug in Vue 3.0.0 project and it is related to scope ids since switching style from scoped to module solves the problem. Will try to create minimal repro with latest Vue version later this week. If succeeded, should i open separate issue or just put the link to repro here?
I agree that user should be warned about any issues but duplicated attributes with equal (or both missing) values is not really a severe problem. Moreover, duplicated attributes are removed automatically as we can see in the resulting html string in repro. So this syntax error is not actually a some fatal error which would lead to unexpected behavior of the resulting html.
At the same time, say I miss > in
<div data-f345fg data-f345fg
        Hello World
</div>

As with duplicated attrs, it will result in SyntaxError but now we will have meaningless render result
<div data-f345fg hello world < div></div>
So we have two errors being absolutely different in terms of possible impact on code behavior but equal in theirs interpretation by compiler's users since you can't distinct one error from another. Consequently, with server-renderer in production, with Vite, etc, render will fail no matter the error severity.

should I open separate issue or just put the link to repro here?

Please comment here with updated repo.
Re duplicated attributes: again, if the compiler mistakenly injects the same scopeID twice, it's a scope ID bug. If you manually author duplicated attributes in a template, it is always a mistake (because there is no legit reason to have duplicated attributes) and it should result in a compile error.

Closing as stale. If you can provide proper reproduction, please open a new issue.


merge release/1.6.5 into dev

Do NOT squash-merge, but use regular merge!
This PR merges release/1.6.5 "back into" dev. This time it contains a lot of commits as dev was a lot behind in terms of commits.
Would be good to review this one, as there were quite a bit of conflicts.

Using that fresh install, I did get this upon importing a scan report:
celeryworker_1  | 2020-06-17T16:43:35.631725283Z [2020-06-17 16:43:35,631: INFO/MainProcess] Received task: send_alert_notification[4e778a36-9b00-4d68-8a3c-e958ee955838]
celeryworker_1  | 2020-06-17T16:43:35.632987877Z [2020-06-17 16:43:35,632: ERROR/MainProcess] Task send_alert_notification[4e778a36-9b00-4d68-8a3c-e958ee955838] raised unexpected: NameError("name 'send_alert_notification' is not defined",)
celeryworker_1  | 2020-06-17T16:43:35.633005674Z Traceback (most recent call last):
celeryworker_1  | 2020-06-17T16:43:35.633011319Z   File "/usr/local/lib/python3.6/site-packages/celery/app/trace.py", line 412, in trace_task
celeryworker_1  | 2020-06-17T16:43:35.633015930Z     R = retval = fun(*args, **kwargs)
celeryworker_1  | 2020-06-17T16:43:35.633020159Z   File "/usr/local/lib/python3.6/site-packages/celery/app/trace.py", line 704, in __protected_call__
celeryworker_1  | 2020-06-17T16:43:35.633025243Z     return self.run(*args, **kwargs)
celeryworker_1  | 2020-06-17T16:43:35.633029181Z   File "/app/dojo/tasks.py", line 384, in send_alert_notification_task
celeryworker_1  | 2020-06-17T16:43:35.633033756Z     send_alert_notification(*args, **kwargs)
celeryworker_1  | 2020-06-17T16:43:35.633039618Z NameError: name 'send_alert_notification' is not defined

thanks, very good find. these errors in celery are one of the reasons I think #2377 should be merged. but that wouldn't have caught this one... we may do a grep for "ERROR" or traceback or something on the celery logs in travis to make sure there are no errors.

Two errors remaining in celery worker:
JIRA related, also occurring in 1.6.5 so not related to this merge, needs fixing in dev afterwards.
celeryworker_1_614e411330ee | [2020-06-17 21:16:42,691: ERROR/MainProcess] Task add_epic_task[b54f2cb3-30f5-4831-bc69-8f9fd9f8547b] raised unexpected: DoesNotExist('JIRA_PKey matching query does not exist.',)
celeryworker_1_614e411330ee | Traceback (most recent call last):
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/celery/app/trace.py", line 412, in trace_task
celeryworker_1_614e411330ee |     R = retval = fun(*args, **kwargs)
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/celery/app/trace.py", line 704, in __protected_call__
celeryworker_1_614e411330ee |     return self.run(*args, **kwargs)
celeryworker_1_614e411330ee |   File "/app/dojo/tasks.py", line 281, in add_epic_task
celeryworker_1_614e411330ee |     add_epic(eng, push_to_jira)
celeryworker_1_614e411330ee |   File "/app/dojo/utils.py", line 1564, in add_epic
celeryworker_1_614e411330ee |     jpkey = JIRA_PKey.objects.get(product=prod)
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/django/db/models/manager.py", line 82, in manager_method
celeryworker_1_614e411330ee |     return getattr(self.get_queryset(), name)(*args, **kwargs)
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 408, in get

notifications related, not present in 1.6.5:
celeryworker_1_614e411330ee | [2020-06-17 21:17:20,023: ERROR/MainProcess] Task send_alert_notification[19d4df31-3ce8-4110-aeae-b835fc2cfe3d] raised unexpected: KeyError('title',)
celeryworker_1_614e411330ee | Traceback (most recent call last):
celeryworker_1_614e411330ee |   File "/app/dojo/notifications/helper.py", line 72, in create_notification_message
celeryworker_1_614e411330ee |     notification = render_to_string(template, kwargs)
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/django/template/loader.py", line 61, in render_to_string
celeryworker_1_614e411330ee |     template = get_template(template_name, using=using)
celeryworker_1_614e411330ee |   File "/usr/local/lib/python3.6/site-packages/django/template/loader.py", line 19, in get_template
celeryworker_1_614e411330ee |     raise TemplateDoesNotExist(template_name, chain=chain)
celeryworker_1_614e411330ee | django.template.exceptions.TemplateDoesNotExist: notifications/product_added.tpl
celeryworker_1_614e411330ee |
celeryworker_1_614e411330ee | During handling of the above exception, another exception occurred:
celeryworker_1_614e411330ee |
celeryworker_1_614e411330ee | Traceback (most recent call last):


As a Project Coordinator, I want to be able to be able to track project location information so that I know exactly where a given project is located.

Description:
As a Project Coordinator, I want to be able to be able to track project location information so that I know exactly where a given project is located.
Acceptance Criteria:
Given
When
Then
Development Checklist:

[ ] Checklist item
[ ] Checklist item
[ ] Checklist item
[ ] Meets the DOD

Notes:

E.g., location is gps coordinates, could also include street address.

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

@elliottSlee - did project location information come up in any of our discussions or usability testing? I feel location (e.g., street address, gps coordinates) are tracked in CIF spreadsheets and I remember it being mentioned during initial discovery and yet, I don't remember this being flagged as something missing during our usability testing sessions.

FYI @nanyangpro - we might need a conversation with the tech team related to project information. I believe this relates to our conversation with Taylor on the 'other data' that CIF would like to see included in the system.

Good call, @LindsayMacfarlane. Yes, we do needs the tech team's perspectives on "other data" important to CIF.

When would the tech team become available again?
This geo information is an administrative piece to me. Maybe it's an Ops Team conversation instead?

Based on CIF prioritization session on Aug 16, 2022, CIF team agrees this is a low priority and can remain in the icebox for now.


fix compatibility issue with PhantomJs

fixes #35

Oh I'm sorry, I might have thought wrong. This fix will let the error go, but the problem is not fixed.

PhantomJs also suffers from the issue event.key !== options.key, but doesn't allow to reassign the value.


Fields to accessors in iroh client - step 2

We need to do the second step - remove the public fields so that the only way to access the subsystems are the accessors.

Implemented in #2374

Closed by #2374


Consistent naming of properties that return boolean value

While working on writing test generators based on the canonical data, I noticed a small inconsistency. The isogram canonical-data  has named its property isIsogram, which makes for a nice, readable function name. However, the leap canonical-data has named its property leapYear, which makes for a slightly less readable function name. I would much prefer to use isLeapYear, which looks clearer to me.
Of course, I could modify my test generator to prepend the "is" part, but maybe we should strive to standardize the naming for boolean properties?

I also prefer isLeapYear, @ErikSchierboom, but I think that naming conventions have a lot to do with the language and personal preferences, so I'm not sure if it is worthy a tabs vs spaces war to standardize it (two spaces using Vim, of course 😄 ).
Anyway, I'll list some alternatives that conform to the schema as a conversation starter, so that we can see if it is contentious:

leap
leapYear
IsLeap
isLeapYear
isBissextileYear
isAnIntercalaryYearInTheGregorianCalendar
f

My vote goes to: isLeapYear, which is think best communicates what we expect the function that implements it to do.

@rbasso said:

two spaces using Vim, of course

I knew you were a right-thinking person. ;)

We can use a standard here if it will help comprehension. If a test generator is able to figure things out from seeing that expected is of type boolean, then great. If some language's test generators need a small exercise-specific portion, then the consistency might help the implementor.
I acknowledge that languages will want to use different names for their functions, such as is_leap_year or leap? or leap-p (there is some language that does this, right? I could have sworn there was...). Note that is true no matter what name x-common chooses.

EBWODP: It's leapp, not leap-p. No hyphen if the name does not contain any other hyphen.

"naming conventions have a lot to do with the language" 👍
As either way we decide, some languages will end up preprocessing the resulting names, maybe we should figure out how many languages use each convention?
Ruby's naming convention is to use '?' and not a prefix.

So would having a standard here help or is the benefit not great enough? I'm not entirely sure if the benefit is great enough.

I think we should have a standard so that they all look the same. I would vote for isLeapYear.

Does this also make sense for:
luhn: valid,
custom-set : equal
clock : equal
queen-attack : canAttack
dominoes : canChain,
triangle : equilateral, isosceles, scalene
canAttack might still be a better name than isAttackable or isChainable
Perhaps this would make a better guideline than a strict rule?

@Insti I think that would be best,

Okay. Let's close this issue and just remember to keep an eye out for possibly non-optimal boolean properties.


[RFC] RPC versioning

This RFC explains how we might use the Jane Street versioned RPC to create new versions of RPC queries and broadcast messages in the Coda codebase.

Can you also speak about versioning of our models?
Additionally, it would be great if you could propose a plan to (1) make sure all serializable types are versioned properly ...

Should this be a different RFC, maybe? Seems like bin_io and RPC are somewhat different.

Created #1601 for module versioning.
My thought is we don't need anything as sophisticated for most modules as we do for RPCable data.

Is there some negotiation when they connect, or do the calls just fail when they're attempted?

I believe that's the way the Versioned_rpc library works. We're using the Both_convert module (where "both" means "caller" and "callee").
Quoting the docs:

one can smoothly add a new version of the rpc to a shared library, and it doesn't matter whether the callee or caller upgrades to the latest version of the shared library first, the new version will not be exercised until both sides support it.

I've written a [%expires_after] ppx in preparation for the landing of this PR.


Code coverage results is empty (except for download link)

Code coverage tab is empty. Expected behaviour like in #9954 (https://github.com/microsoft/azure-pipelines-tasks/issues/9954#issuecomment-572450388)
Please fix it, or add our organization to closed beta. This is critical feature for us.

Any update on when this will be released?

@TekuSP @zingaroo
Thank you for expressing interest in trying the new feature.
Due to some unforeseen circumstances, we are unable to enroll new customers for the private preview at this time.
Right now, we don’t have an ETA to share on when we can roll this out more broadly for customers to try. Sorry !

@TekuSP @zingaroo
As of now we will not be able to roll out this new feature.
For better viewing of coverage information you can use  -
1.PCC task for coverage information stored in cobertura or jacoco format :
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-code-coverage-results?view=azure-devops
2.Use report generator tool in the pipeline to generate the HTML report (which support good number of coverage formats as input) 💯
https://github.com/danielpalme/ReportGenerator
3.Furthermore, to convert .coverage format to .xml fromat :
https://github.com/danielpalme/ReportGenerator/wiki/Visual-Studio-Coverage-Tools#vstestconsoleexe

Closing this based on the comment above.

Bug is not resolved, close this bug when you finish your code coverage tab.
Until then, let it be red, bad number in your dashboard.

@anshii03 @ShreyasRmsft @ankit-arora12  Reopen the issue, or give me migration path to other service, like TeamCity and Jira, for our whole organization.
This is everything wrong

It's open from spring, promising feature
Feature is not there, but tab is
Marking bug as a question
Closing this issue, so you have clean agile plan
Almost no communication

Reopen the issue, and close it when you fixed it, not sooner.
If you have problem with that, give me email to your manager, and I will gladly write them long email explaining the situation. I am sure they would be happy to hear about no communication and half year long reported bug, closed.

@TekuSP
We had tried a closed preview of the capability to view code coverage details for a build. Based on the feedback and monitoring of the limited usage, we have now taken it back.
The behavior you are observing above is not a bug, it is the by design behavior as of now. @anshii03 shared the available alternatives earlier on this thread.
We don't have a timeline to share for when we may be working on this issue again.
Thanks

Okay, then why TAB IS STILL THERE?

If this is a feature which is not implemented, remove the whole TAB.
@shashban

I am not sure why this issue is closed. IMHO, this is a problem and a solution should be provided. As you can see below, using the PublishCodeCoverageResultsV1 and following the documentation, the artifact generated is a ".coverage" file which can be downloaded but no results are shown.
I kindly ask you to reopen this issue and provide a feedback or solution if available.


Stop using . in artifactId, use - instead, per the usual conventions.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

I still think we should drop the aws- prefix from the artifactId, it seems redundant. The AWS SDK for Java v2 just uses the basic service name, so for example the dependency is software.amazon.awssdk:s3:$VERSION. I understand there may be cases where a conflict could arise - but we should tackle the differentiation at that point rather than make every service suffer from the additional redundancy.

Discussed off-line with @kiiadi and came to the following conclusion:

Drop the aws- prefix from the artifactId will make the maven coordinates simpler & align with the Java SDK 2.0 (maybe allow it as a tie-breaker, but we don't actually have a conflict yet, so probably not)
Package names for L1/L2 libraries should be software.amazon.awscdk.services.<package name minus '@aws-cdk/aws-' prefix>
It might be a good idea to rename @aws-cdk/rtv to @aws-cdk/runtime-values, because the acronym is not standard & could confuse.

Updated PR to change artifactIds and package names as described above, and added a cdk- prefix to CDK core packages.


GH-36420: [C++] Add an sql-compatible In Function

Rationale for this change
As #36420 says, we want add an sql-compatible is_in variant, which has a different logic handling Null.
What changes are included in this PR?
Add a new Function In in scalar_set_look_up.
Are these changes tested?
No, will add ASAP.
Are there any user-facing changes?
No.

Closes: #36420

Why not improve SetLookupOptions instead to allow selecting the desired semantics?

Why not improve SetLookupOptions instead to allow selecting the desired semantics?

+1. When possible, we typically prefer to add new options to existing functions instead of adding new functions.

Why not improve SetLookupOptions instead to allow selecting the desired semantics?

Hi, here are my two considerations:

The null_handling of all the kernels of is_in is NullHandling::OUTPUT_NOT_NULL. While a sql-compatible is_in can have NULL outputs.
It's a bit weird to add an option like sql_compatible specific for is_in in SetLookupOptions.  Since SetLookupOptions is used by is_in and index_in.

But these two considerations are not strict obstacles for using an option instead. For 1, we can set null_handling to NullHandling::COMPUTED_PREALLOCATE and init the null bitmap to true in exec for un-sql-compatible is_in. And the new option could be named as sql_compatible, which is only used by is_in.
If you think the solution is ok or have a better solution, I will change code to an new option version soon.

Since no further feedback, I plan to transfer to an new option version as I have commented before. Hi, @pitrou @ianmcook Do you think it's ok?

@R-JunmingChen see my comments at https://github.com/apache/arrow/issues/36420#issuecomment-1662594221.
Based on that, here is what I recommend:
In SetLookupOptions, replace the bool option skip_nulls with an enum option:
enum NullMatchingBehavior
How to match null values.
Values:

enumerator MATCH
Any null in value_set is successfully matched to null values in the lookup set
enumerator SKIP
Any null in value_set is ignored and nulls in the input produce null (IndexIn) or false (IsIn) values in the output.
enumerator EMIT_NULL
Any null in value_set results in a null in the output.
enumerator INCONCLUSIVE
Any null in value_set results in a null in the output. Any null in the lookup set is treated as an unknown value that cannot conclusively match values in value_set and any value in value_set that cannot be conclusively matched results in a null in the output. This is consistent with the behavior of IN in SQL.

For backward compatibility:

Default to MATCH (consistent with the current default skip_nulls = false)
Continue to accept the existing boolean argument skip_nulls and respect it if the user does not use the new enum-based option. false translates to MATCH and true translates to SKIP.

I believe this should work with both is_in and index_in.
@westonpace does this look OK to you?

Hi, @ianmcook. I think it's a good solution to use an enum option , but I still have one question.
Why do we want to support EMIT_NULL?

Thanks @R-JunmingChen

Why do we want to support EMIT_NULL? MATCH, SKIP and INCONCLUSIVE seem sufficient.

It is nice to have EMIT_NULL for completeness. There are some cases where the user might want that behavior—for example, to match the behavior of DuckDB's list_contains function like I describe here: https://github.com/apache/arrow/issues/36420#issuecomment-1662660149

Since we want support skip_nulls for backward compatibility, we need an enumerator UNSET for NullMatchingBehavior, which means we only use skip_nulls instead of NullMatchingBehavior, and make it default for the enum option. Cause we can't translate when user set the skip_nulls via the way like setLookupOptions.skip_nulls = false.

I think it is possible to define 2 explicit public functions of the class SetLookupOptions:

SetLookupOptions(Datum value_set, bool skip_nulls = false) (same as currently)
SetLookupOptions(Datum value_set, NullMatchingBehavior null_matching_behavior = NullMatchingBehavior::MATCH)

I think that will give backward compatibility.

I think it is possible to define 2 explicit public functions of the class SetLookupOptions:
SetLookupOptions(Datum value_set, bool skip_nulls = false) (same as currently)
SetLookupOptions(Datum value_set, NullMatchingBehavior null_matching_behavior = NullMatchingBehavior::MATCH)

Do you mean we remove the member variable skip_nulls and make it a parameter in constructor function and then translate the skip_nulls to NullMatchingBehavior ?
I think this way will affect some users who set skip_nulls directly via member variable. Does it ok?
If we don't remove member variable `skip_nulls, the translation problem still exists. For example:
SetLookupOptions option(value_set);
option.skip_nulls = true;

I think it is possible to define 2 explicit public functions of the class SetLookupOptions:
SetLookupOptions(Datum value_set, bool skip_nulls = false) (same as currently)
SetLookupOptions(Datum value_set, NullMatchingBehavior null_matching_behavior = NullMatchingBehavior::MATCH)

Hi @ianmcook, do you mean we remove the member variable skip_nulls and make it a parameter in constructor function and then translate the skip_nulls to NullMatchingBehavior ?
I think this way will affect some users who set skip_nulls directly via member variable. Does it ok?

Yes, I think this is OK. We can mark this as a breaking change if needed, but I think it should not affect most users. @westonpace or @bkietz can you please confirm?

I would not expect there to be many direct users of the skip_nulls data member, but disentangling the corresponding cython will be annoying. Since it's a breaking change, we could compromise with:
/// Options for IsIn and IndexIn functions
class ARROW_EXPORT SetLookupOptions : public FunctionOptions {
 public:
  enum NullMatchingBehavior { MATCH, SKIP, EMIT_NULL, INCONCLUSIVE };

  explicit SetLookupOptions(Datum value_set, NullMatchingBehavior = MATCH);
  explicit SetLookupOptions(Datum value_set, bool skip_nulls);
  SetLookupOptions();
  static constexpr char const kTypeName[] = "SetLookupOptions";

  /// The set of values to look up input values into.
  Datum value_set;

  // will be overridden by skip_nulls if that is explicitly assigned
  NullMatchingBehavior null_matching_behavior;

  // DEPRECATED(use null_matching_behavior instead)
  std::optional<bool> skip_nulls;
};

with this, opts.skip_nulls = false will still work and operate as expected and (I think) cython changes will be minimal until we're ready fully to accommodate null_matching_behavior in python.

I will implement this version ASAP. Let me turn this PR to draft temporarily

Hi, @bkietz @ianmcook, please go on the review when you have time

Looks great, thanks for your effort and persistence @R-JunmingChen!
I built Arrow from your fork and created a standalone example to test this. Everything seems to be working well. https://gist.github.com/ianmcook/25bb0c82b8af4fc1bde0768863607355.
I checked whether anything needs to change on the compute.rst docs page. No changes are required there, I think.

@ursabot please benchmark

The Python failure looks like #37803.

I'm not sure why Conbench isn't working as expected here. The benchmarks should run after this merges and we can check for regressions there.

I'm not sure why Conbench isn't working as expected here.

Sorry, this looks to be a bug with the "ursabot please benchmark" workflow. Will fix today.

That should be fixed. If you push an empty commit (https://github.com/voltrondata-labs/arrow-benchmarks-ci/issues/111) and then re-run the command, you can try benchmarks again. Else, yeah, they will be run post-merge.

@bkietz if you want to go ahead and merge when you're comfortable with this, we can just look at the benchmarks post-merge


Switching the avatar to npc gives wrong interaction on new avatar

Load the street.scn
Switch the avatar with npc by pressing 'g'
You can see interaction icon 'E' around your new avatar

Duplicate: https://github.com/webaverse/app/issues/3397

Close due to duplicated


Research how long sessions should last

During usability testing, a CIF user expected to remain logged in for a long period of time--90 days or so--because they anticipate using this many times a day and don't want to log back in every time. Currently, it lasts 30 minutes, I believe.


FR: Wrap date strings into wikilink brackets

Is Your Feature Request Related to a Problem? Please Describe.
I'm using the tasks plugin but want the inserted dates to be inserted as wikilinks, however they are inserted as plaintext dates only
Describe the Solution You'd Like
The linter should recognise lone dates inside of file text and wrap dates inside wikilinks and wrap them into brackets
2023-07-19 Wednesday

[[2023-07-19 Wednesday]]

Describe Alternatives You've Considered
PR for the tasks plugin, however I feel like this may be a linter type of usecase, generally speaking

The linter should probably only validate against the date format specified, otherwise this might be hard to properly do

Hey @JulianDicken , this sounds a lot like what custom commands are designed to handle. Have you tried setting up those?

Right, forgot about those :)

I am going to close this issue since I have not seen much activity around it.
If the dates follow a specific format like YYYY-MM-DD day of week then you could probably use custom replacements/regex to make it so that they are converted to wiki links.


Track studio Don't open

hi i wanna start Track studio but its crache when i start it , can you help me ? tanks

It looks like this is still an issue with the latest release. I have this problem whenever I try to use a precompiled release on a machine that I haven't run Track Studio on before. This is probably a blind spot for the devs.
Currently, the workaround is to compile the program from scratch using the source code. This ensures all the dependencies are downloaded and installed to your PC.
Tutorials:

Downloading the source code
Compile C++ code in Visual Studio Code

For further help, reach out via the #help channel in Track Studio Discord.

Quick update: Turns out the Track Studio documentation on the website is outdated. It specifies that you need .NET Core v5.0 installed, but Track Studio wants v8.0.
Assuming you are using Windows, the easiest way to install this is to open Terminal and type the following command:
winget install Microsoft.DotNet.SDK.8
This will download and run the installer.
While you're at it, run this command to make sure C++ Redistributable is installed too:
winget install Microsoft.VCRedist.2015+.x64
NOTE: If you get an error saying the winget command cannot be found, this means you need to enable the WinGet application. In that same terminal window, use this command: Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe. Once that's done, open a new terminal window and enter the winget commands.

@KillzXGaming Made a pull request updating the dependency list on the documentation site.


implements the e2e tests

Is your feature request related to a problem? Please describe.
n/a
Describe the solution you'd like
n/a
Search

[X] I did search for other open and closed issues before opening this

Additional context
No response

See https://gist.github.com/jpillora/b480fde82bff51a06238 and https://github.com/gliderlabs/ssh/tree/master

This issue is stale because it has been open for 30 days with no activity.

This issue was closed because it has been inactive for 14 days since being marked as stale.

This issue is stale because it has been open for 30 days with no activity.

This issue was closed because it has been inactive for 14 days since being marked as stale.


transaction logic fix replace #6859

replace  #6859

test this please

Looks like you are trying to check in a file coming from a bad conflict resolution (.rej). Clearly no need for that.

sorry Eric, I made a mistake to add that file. Patch is updated

test this please


ServiceUrlRandomizer based on hostname may lead to uneven distribution of clients

Back in 2013 (here 3767d56efbabc8cf5e26fc442c7b008c841bbf19) randomizer for list of available Eureka nodes was introduced. And in this implementation reordering service URLs in fact depends on host name.
This implementation is still the only one present in Eureka client. However, if number of services per host is big, but number of hosts is not, it leads to uneven distribution of load on Eureka. For example, if there are some big hosts running numerous Docker containers.
Hence, 3 questions:

Why does this implementation depends on host name, why not just use random seed calculated once?
If reason is hard to find since the implementation is 5yo, would you mind if we support random seed?
And if you don't mind that we support random seed, do you want us to leave hostname-dependent implementation as default one and add config parameter to enable random-based, or we may just replace hostname-dependent one with random-based?

Thanks!

Any comment here guys?

@mgtriffid From your description it sounds like you are need a different randomization mechanisms for clients to find fetch or registration eureka nodes.  Or do you need different randomization for eureka nodes to find each other?  Or both?  The PR you submitted only modified the behavior for inter node communication of the eureka cluster and has no effect on client side randomization.  That change would need to be wired into ZoneAffinityClusterResolver.

@elandau , we need different randomization for clients to choose Eureka nodes. And actually with my changes if I do
        ResolverUtils.setRandomizer(new Randomizer() {
            private final int seed = new Random().nextInt();
            @Override
            public void randomize(List randomList) {
                if (randomList.size() < 2) {
                    return;
                }
                Random random = new Random(seed);
                int last = randomList.size() - 1;
                for (int i = 0; i < last; i++) {
                    int pos = random.nextInt(randomList.size() - i);
                    if (pos != i) {
                        Collections.swap(randomList, i, pos);
                    }
                }
            }
        });

somewhere before Eureka Guice module is configured, this does the trick for me: seed is different every time, but order of preference remains the same. This implementation of Randomizer just uses random number instead of local IP hashcode.

That change would need to be wired into ZoneAffinityClusterResolver.

As you can see, ZoneAffinityClusterResovler just calls ResolverUtils.randomize, so logic is actually wired into there.
Am I missing something else?

Sorry, you are correct.  Not sure why I wasn't making that connection.

Anything new about this guys? Are we ok to proceed with the PRs we submitted?


Deploy Updated Smart Contract

Description
Concise description of proposed changes, We recommend using screenshots and videos for better description

The changes are courtesy of the Metis BUILDH3R Workshops
The state of the Dapp transitioned to an updated version and deployed on the metis Sepolia network
The network was solely for testing purposes and clear to adopt on the mainnet

Additional Information

[ yes ] I have read the contributing docs (if this is your first contribution)
[ yes ] This is not a duplicate of any existing pull request

Your ENS/address: 0xdCDd4496f65A035397BfA8b6a8442507D90cab08

Closing this, I think you wanted to created PR to different origin


Error in grammar regarding in-out-expression

Location
https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/Expressions.md?plain=1#L64
Description
An in-out-expression is defined as being & identifier.
This is incorrect, and can be seen on line 51 that it's meant to be & expression. (here: https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/Expressions.md?plain=1#L51)
I'm assuming this is just a simple error that was overlooked but I will leave a demonstration below of why the version with identifier isn't correct.
Given this example program:
enum A {}

struct MyStruct {
	var a: A
}

func myFunc(_: inout A) {}

func myOtherFunc(s: inout MyStruct) {
	myFunc(&s.a)
}

This is compliable code in swiftc.
Our point of concern is the use of an in-out expression as a parameter in the call to myFunc
There is no possible derivation of this subsection of the code given the production for in-out-expression with identifier rather than expression.
Let us look at some possible derivation paths for myFunc(&s.a)
Possible derivation path: (terminals in bold)

-> function-call-expression
-> postfix-expression function-call-argument-clause
-> primary-expression function-call-argument-clause
-> identifier generic-argument-clause? function-call-argument-clause
-> myFunc generic-argument-clause? function-call-argument-clause
-> myFunc function-call-argument-clause
-> myFunc ( function-call-argument-list )
-> myFunc ( function-call-argument )
-> myFunc ( expression )
-> myFunc ( try-operator? await-operator? prefix-expression infix-expressions? )
-> myFunc ( await-operator? prefix-expression infix-expressions? )
-> myFunc ( prefix-expression infix-expressions? )
-> myFunc ( prefix-operator? postfix-expression infix-expressions? )
-> myFunc ( postfix-expression infix-expressions? )
-> myFunc ( explicit-member-expression infix-expressions? )
-> myFunc ( postfix-expression . identifier generic-argument-clause? infix-expressions? )
-> myFunc ( primary-expression . identifier generic-argument-clause? infix-expressions? )
-> myFunc ( identifier generic-argument-clause? . identifier generic-argument-clause? infix-expressions? )
-> myFunc ( ??? generic-argument-clause? . identifier generic-argument-clause? infix-expressions? )

???- cannot reach a production that will get us &s
Let's look at another possible derivation path.
Picking up from step 12 in the above derivation:
12) -> myFunc ( prefix-expression infix-expressions? )
13) -> myFunc ( in-out-expression infix-expressions? )
14) -> myFunc ( & identifier infix-expressions? )
15) -> myFunc ( & ??? infix-expressions? )
???- cannot reach a production that will get us &s.a
Correction
Line 64 should read in-out-expression → & expression

Thanks! This change looks like it's probably correct, but I'll need to find someone who can tech review to confirm this is exactly the expected behavior.

No problem. Thanks for the reply!

Keeping this issue open while we discuss a better fix in #194


Expect table column names and dtypes

This PR creates a schema test which will directly compare the column name : data type mapping of the relation with a given python dictionary.
After comparing upper cased column names and data types, it will run an EXCEPT/UNION difference type query which will return any differences found between the two mappings and returns rows containing the difference and a found_in column explaining the error

This is intended to be a complete coverage for schema changes in place more verbose workarounds like this https://madisonmae.substack.com/p/tutorial-using-dbt-to-test-for-schema

Hi, thanks for the PR! I think I understand the intent here (save time on typing a schema definition and tests), but I think the current dbt-ish way to accomplish this is to define each column in a schema.yml file and then add the appropriate type tests, which we already have with expect_column_values_to_be_of_type and expect_column_values_to_be_in_type_list.

If we were to go down this route, I would prefer not to use a Python dict, but use YAML to define structure since that's the commonly used approach in this repo and other dbt package repos.

Hi @clausherther, thanks for the reply. I have modified the mapping to be pure YAML, like this.
sources:
  - name: my_source
    tables:
      - name: my_table
        tests:
          - dbt_expectations.expect_table_column_names_and_dtypes:
              mapping:
                 name: VARCHAR
                 birthday: DATE
                 age_in_years: INTEGER

Appreciate what you are saying about the dbt way of doing things. The intent here is really to try and provide a full check on changing source schemas without the yaml getting too verbose. It's not so much to save time but to save long yaml blocks and mental overhead in reading and maintaining them. The current way seems to be a combination of the following:
sources:
  - name: my_source
    tables:
      - name: my_table
        tests:
          - dbt_expectations.expect_table_column_count_to_equal:
              value: 3
          - dbt_expectations.expect_table_columns_to_match_set:
              column_list: ["name", "birthday", "age_in_years"]
        columns:
          - name: name
            tests:
              - dbt_expectations.expect_column_to_exist
              - dbt_expectations.expect_column_values_to_be_of_type:
                    column_type: varchar
          - name: birthday
            tests:
              - dbt_expectations.expect_column_to_exist
              - dbt_expectations.expect_column_values_to_be_of_type:
                    column_type: date
          - name: age_in_years
            tests:
              - dbt_expectations.expect_column_to_exist
              - dbt_expectations.expect_column_values_to_be_of_type:
                    column_type: integer

Completely up to you, I will leave this here


Pronoun/determinative/possessive lemmas

We should standardize these and enforce in the validator. As is, e.g. "its" is sometimes lemmatized as "it".
The UD lemmatization policies have evolved and are summarized here for pronouns. Basically,

in the personal pronouns, accusative pronouns are mapped to nominative and independent possessives are mapped to dependent possessives
"whom" should be mapped to "who" and "whomever" to "whoever"
in demonstratives (which in CGEL are always determinatives), plurals are mapped to singular lemma
the article "an" is mapped to "a"

(discussion at https://github.com/UniversalDependencies/docs/issues/517)
We could simply adopt the UD policies; or, because they potentially diverge from CGEL at least with regard to possessives, and as pronouns and determinatives are closed classes, we could simply omit the lemmas from the CGELBank trees, and provide a lookup table for anyone who wants them.
Also, for full nouns with a possessive ending, whether that is lemmatized to the non-possesssive form should be consistent. (The possessive ending is considered a separate syntactic word in UD, but not in CGEL; in UD-derived data this is make explicit with :subt features.)

Possible solution that would minimize manual annotation effort:

N_pro and D nodes (whether it is a standard form of a pronoun, or has a :correct feature indicating the standard form) never receive an :l feature in the .cgel file
possessive Ns (e.g. "John's", "store's") do receive an :l with the genitive ending removed (and converting plural to singular)
the cgel.py API provides access to several attributes:

the raw :l annotation (if present)
the raw :correct annotation (if present)
the :l annotation if present else :correct annotation if present else surface form
the udlemma, which is a string or list of strings additionally incorporating PRON/DET/possessive lemmatization and tokenization per UD guidelines
the cgellemma, which is a string providing a lemma per CGEL guidelines (normalizing across all pronoun cases including genitive, and removing rather than splitting off s-genitive endings)

A lemma is only sometimes provided explicitly for "its"—the annotations are inconsistent across files.
We have to decide: (1) For pronouns and determinatives, which are a closed set, do we want to ask annotators to specify the lemma explicitly in the .cgel file, or compute it automatically as part of the API? (2) If their lemmas are specified explicitly, do we want to be compatible with UD lemmas?

OK, I get it.

I see no need for annotators to specify the lemma, but it would be good if they were computed automatically.
I don't have a strong opinion on UD compatibility.

A reminder to myself that we DO want hand-specified lemmas not just for nouns and verbs, but also adjectives/adverbs inflected for grade (comparative/superlative).
Coordinators, Subordinators, Prepositions are not normally expected to inflect/have lemmas, though it is conceivable in the cases of spelling variation ("&" / "and", "@" / "at" etc.). Or the non-abbreviated form could be indicated as the :correct form.


Fixed usage examples

Fixed usage examples in DecimalsConverter, Vector, PriorityQueue, StringSet.

Codecov Report
Patch and project coverage have no change.

Comparison is base (39e2c85) 100.00% compared to head (16952cb) 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff            @@
##            master       #46   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           29        29
  Lines          952       952
  Branches       128       128
=========================================
  Hits           952       952

Impacted Files
Coverage Δ

...s-registry/pools/AbstractPoolContractsRegistry.sol
100.00% <ø> (ø)

contracts/libs/data-structures/PriorityQueue.sol
100.00% <ø> (ø)

contracts/libs/data-structures/StringSet.sol
100.00% <ø> (ø)

contracts/libs/data-structures/memory/Vector.sol
100.00% <ø> (ø)

contracts/libs/decimals/DecimalsConverter.sol
100.00% <ø> (ø)

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


train_second.py question?

https://github.com/yl4579/StyleTTS2/blob/2f2dece35b9cad63215ae38bf991b856d1d1c063/train_second.py#L681C1-L681C32
Apologies if I am misunderstanding something, but it seems this line (681) in train_second.py starts a block that refers to mel_input_length, mels, asr at two indent levels, but the loop that defines these variables per batch above (line 569) starts at three indent levels--so the block at line 681 would only process the last batch in validation?

Yes, that is the part to generate samples and log them on the tensorboard. The validation is already done before this.

OK thanks


feat(trivy): bump to v0.56.2

Looks like trivy was updated so that we can remove the ignore-comments about ssl
mode.

https://github.com/aquasecurity/trivy-checks/releases/tag/v1.1.0
https://github.com/aquasecurity/trivy/releases/tag/v0.56.0 (note the
chore(deps): Bump trivy-checks to v1.1.0)

But I also noticed that https://github.com/aquasecurity/trivy/pull/7564 is not
merged yet, so not really 100% sure about this.

@alethenorio they bumped to v0.56.2 11 minutes ago, so I'm bumping again here before merging.


Make it clearer where the two .ipa files come from

where does the test.ipa come from? What path should I check when writing my saucectl config https://docs.saucelabs.com/mobile-apps/automated-testing/espresso-xcuitest/xcuitest-introduction/#sharding-xcuitest
cc @wswebcreation

irrelevant now


Conform to the SAML Schema

TheInResponseTo is optional. If it's not specified we should not render it because it will fail schema validation.

Beyond failing specs, is there anything preventing this from being merged? I've run into a situation where this has caused a problem. (I would probably also recommend pulling the logic around the InResponseTo out of the long assertion / xml strings.)

Tagging @lawrencepit (since I'm not sure if GitHub would send a notification otherwise)

Just saw that the commit got pulled into 0.3.4, thanks!


Add Fathom Analytics Stats extension

Description
A Raycast extension to browse your website analytics coming from Fathom.
Screencast
(Don't wanted to share my website analytics so here are screenshots of the extension running with pixelated areas.

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Added more detailed instructions to get an API token from Fathom (cc @peduarte, was not really clear indeed)

Hi 👋
Thanks for your contribution 🔥
Wouldn't it make sense to add to the current Fathom Analytics extension we already has in the Store by @DanielFerguson 🙂

After checking them both out, it actually makes sense to keep it as two separate extensions. We should keep this as it is.
@DanielFerguson, I DM'ed you in Slack and X. Do you have a minute? :)

Hey Per ✌
Thank you for your time and review of this new extension.
Let me know if you need anything from my side before merging. Happy to help if needed!

Hey Per 👋
I added error handling for the extension with a Toast and a Detail view to provide more details.
Also added some improvements (types, time period order, setup guide).
Let me know if you need anything else.

🔥 🔥 🔥 🔥 🔥


Fix: Missing $args when calling next pipeline from replicate()

If replicate() has more than one hook - model updating fails with exception: $args will be null for next hook call, so PHP will try to call method "->get('original)" of non-object (this was found during a very long debugging session).
Other method hooks in this class (like save()) plays well with the $args attribute, but replicate() do it wrong.

Coverage increased (+0.1%) to 93.574% when pulling f0938e4eaef6576003fc21ade8a276d6f682e35b on uniconstructor:patch-1 into fcc6415b21f099cca18eb6311aa6817328597a60 on jarektkaczyk:master.

I checked the CI warnings, and found that your Travis CI build fails because of incorrect system configuration:
HHVM is no longer supported on Ubuntu Precise. Please consider using Trusty with `dist: trusty`.

By the way - I am happy to know that my patch doesn't break anything. :)

@jarektkaczyk
Is there any problems with this pull request? Can you accept it? If you need more information about it - just tell me, I'm ready to help.

thanks, merging


Introduce secret to track hash version used by OperatingSystemConfig

How to categorize this PR?

/area control-plane
/kind enhancement
What this PR does / why we need it:
This PR implements the pool-hashes secret, proposed in https://github.com/gardener/gardener/issues/9699, that is stored in the shoot namespaces on each seed cluster. The secret contains information on which hash version is used for the OperatingSystemConfig as well as the calculated hash values. If the calculated and stored hash values differ, then the hash is upgraded to the latest version.
Currently, only hash version 1 exists. Version 2 will be introduced in a follow-up PR.
The PR includes migration code, that creates a placeholder secret in each shoot namespace. As a small difference to the proposal in https://github.com/gardener/gardener/issues/9699, that secret only contains a "migrated" field. This field causes the normal reconcile for the secret to bootstrap the secret with version 1 instead of the latest version (which currently is still 1, but version 2 will be added in a follow-up PR). This minimizes the complexity of the migration code, but might require keeping a part of it around for some time.
Which issue(s) this PR fixes:
Part of https://github.com/gardener/gardener/issues/9699
Special notes for your reviewer:
I'm somewhat unsure what the best approach is to check that the pool-hashes secret properly survives a control plane migration. I've extended the corresponding e2e test to add a special label to the secret, which will be checked by the existing test code.
Release note:

gardenlet now creates a secret called `pool-hashes` in the shoot namespace on seed clusters. This secret will be used to upgrade the operating system config key calculation in the future.

/assign
/ok-to-test

@rfranzke I've addressed the review comment. However, some E2E tests still fail, and I don't have a clue why. pull-gardener-e2e-kind now yields an HTTP 401 error which seems to be unrelated. And in pull-gardener-e2e-kind-ha-single-zone-upgrade it looks like the old API server keeps getting contacted, which looks like a flake. At least during the previous attempts, that error caused pull-gardener-e2e-kind-upgrade to fail which passes now.

Cool, looks good @MichaelEischer. Please fix the tests so that we can get this PR merged.


[Windows] Add Visual Studio Extensions versions back to documentation

Description
Currently, VS Extensions are being displayed in documentation without its versions. This issue came with this PR. In scope of this PR we are getting versions of VS Extensions back to documentation.
Related issue:
Check list

[ ] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run windows2016, windows2019


immediateSend blocks payloadRead on Android

Only affects apps that use immediateSend functionality (not DCT apps).
calling immediateSend or immediateSendAll will block. Need to null out BLEDevice.immediateSendData immediately after send.

Fixed by #114


[BUG] Recursive models generate invalid typescript

We have the following python model:
class FilterRule(BaseModel):
    value: str | list[str]
    operator: Literal["eq", "ne", "in"]
    field: str
    field_type: Literal["list", "string"] = "string"

    def __str__(self) -> str:
        if self.field_type == "list":
            if isinstance(self.value, list):
                joined_value = ", ".join([v for v in self.value])
            else:
                joined_value = self.value
            return f"{self.field}/any(g: search.in(g, '{joined_value}'))"
        else:
            if self.operator == "in":
                if isinstance(self.value, list):
                    predicate = " or ".join(
                        [f"{self.field} eq '{v}' " for v in self.value]
                    )
                else:
                    predicate = f"{self.field} eq '{self.value}'"
                return f"({predicate})" if predicate else ""

        return f"{self.field} {self.operator} '{self.value}'"

    def __bool__(self) -> bool:
        return bool(self.value) and bool(self.field)

class Filters(BaseModel):
    logical_op: Literal["and", "or", "not"] = "and"
    rules: list[Union[FilterRule, "Filters"]]

    def __str__(self) -> str:
        filter_str = f" {self.logical_op} ".join(
            [
                str(rule) if isinstance(rule, FilterRule) else f"({rule})"
                for rule in self.rules
                if bool(rule)
            ]
        )

        return filter_str.strip()

Which generates the following OpenAPI schema type:
"Filters":{
   "properties":{
      "logical_op":{
         "type":"string",
         "enum":[
            "and",
            "or",
            "not"
         ],
         "title":"Logical Op",
         "default":"and"
      },
      "rules":{
         "items":{
            "oneOf":[
               {
                  "$ref":"#/components/schemas/FilterRule"
               },
               {
                  "$ref":"#/components/schemas/Filters"
               }
            ]
         },
         "type":"array",
         "title":"Rules"
      }
   },
   "type":"object",
   "required":[
      "rules"
   ],
   "title":"Filters"
},

Which is correct. But the generated typescript file is invalid:
import type { FilterRule } from "./FilterRule.js";
import type { Filters2 } from "./Filters.js";

export type Filters = {
  logical_op?: "and" | "or" | "not";
  rules: Array<FilterRule | Filters2>;
};

There exists not "Filters2". It should simply be:
import type { FilterRule } from "./FilterRule.js";

export type Filters = {
  logical_op?: "and" | "or" | "not";
  rules: Array<FilterRule | Filters>;
};

How can this be fixed? If we manually adjust it, every time we run the client it is overwritten.

Thanks for letting me know about this! I will look at this and get it fixed ASAP.
Unfortunately, there's not yet a way to exclude a type file from being automatically recreated. That's coming soon (#886). You've also inspired me add another feature to prevent an individual file from being overwritten (#891). That will be trivial to implement so worst case I'll have a release out by the end of the day that allows you to keep your manual fix.

It's probably a matter of removing the !this.exports.has(name) part in this line.
https://github.com/pmcelhaney/counterfact/blob/84a421d7e14e31a13f7ad660fe0142fb92e74efa/src/typescript-generator/script.js#L30

Fixed in 0.40.2. Thank you for the bug report! If you have any other feedback, please don't hesitate to share.


Add helper to simplify streaming a file download

I am currently migrating one of my applications from Silex (RIP) to Slim and got to the part that streams file downloads.
Silex implemented that as an extremely succinct and convenient sendFile() helper:
return $app->sendFile($path);

While doing this seems possible just fine in Slim, from what I found it seems a lot more involved with multiple steps:

Open stream to the file
Convert it to the Slim stream
Create/adjust response object with stream body
Set significant amount of headers on the body to define it as download

I ended up with something like this (via docs and forum):
$fileStream = fopen($sendFile->getRealPath(), 'rb');

return $response->withHeader('Content-Type', 'application/force-download')
    ->withHeader('Content-Type', 'application/octet-stream')
    ->withHeader('Content-Type', 'application/download')
    ->withHeader('Content-Description', 'File Transfer')
    ->withHeader('Content-Transfer-Encoding', 'binary')
    ->withHeader('Content-Disposition', 'attachment; filename="'.$sendFile->getBasename().'"')
    ->withHeader('Expires', '0')
    ->withHeader('Cache-Control', 'must-revalidate, post-check=0, pre-check=0')
    ->withHeader('Pragma', 'public')
    ->withBody(new Stream($fileStream));

A lot more verbose and honestly on top of my head I hardly know what exactly those headers do and if they are right as my defaults.
So I would like to suggest that Slim implements a helper for simple file download in a manner that Silex did.
Thank you for considering. :)

@akrabat would you like to include that into Slim 3/4?

Issue moved to https://github.com/slimphp/Slim-Http/issues/82