Self Referenced Span

Resolves #397

Which problem is this PR solving?

This allows client to initialize a span from an already identified ("offline") context.

Short description of the changes

Introduces a Jaeger specific span reference type "self"
Allows client to pass in an already established SpanContext, if so, will use the passed in SpanContext for the span instead of generating span/trace ids

TODO

[x] remove extra pointer, e.g. store ref.ReferencedContext instead
[x] self reference should continue the loop because a span may have multiple happens-before ancestors
[x] self reference unit tests
[x] needs documentation in the comments and a section in the README
[x] move self ref constants.go is a better place

lgtm, pending changes in the comments

@yurishkuro updated! Thank you.  Are there any other test cases that I should add?

@yurishkuro updated, thank you for all your help with this

thanks 🎉

please let us know how it works out end to end

@dm03514 Do you think it's correct that the sampling decision is also inherited from the Self span reference? It makes it difficult to use this mechanism for people who want to provide their own trace IDs.


Broken dependency klauspost/cpuid

Hi there - I believe this dependency was very recently refactored and is now breaking certmagic master (line 330, crypto.go).

Why do you think this? What are you trying to do? What commands are you running? What is your code? What are the errors?

Sorry. It's compilation that is broken. Line 330, crypto.go refers to a method AesNi() in klauspost/cpuid that has been removed.

certmagic shouldn't be using cpuid v2 yet 🤔
The AesNi() method was removed in https://github.com/klauspost/cpuid/commit/43f4c41326096a3d90b250136a41d7e0c46bbcd8
When upgrading to v2 though, looks like it should be changed to cpuid.CPU.Supports(cpuid.AESNI).

Yeah, I'm not sure what the problem is. CertMagic compiles fine because it does not use v2 of cpuid.

I can confirm that this issue still persists. Here's how to reproduce it:
Install latest version of go.
Run go get github.com/caddyserver/certmagic.
This is the output:
anon@server1:~/go$ go get github.com/caddyserver/certmagic
# github.com/caddyserver/certmagic
src/github.com/caddyserver/certmagic/crypto.go:336:14: cpuid.CPU.AesNi undefined (type cpuid.CPUInfo has no field or method AesNi)

@cryptopragmatic CertMagic is not a command, it is a library. Please ensure you are in a Go project, as usual: https://golang.org/doc/code.html


Handle SIGPIPE gracefully

The SIGPIPE issue in #1457 will occur for all backends, it's just that some are... less reliable than others ;)
The problem is that registering a SIGPIPE handler removes the Go runtime logic that only crashes on SIGPIPE on fd 0/1/2, and not on SIGPIPE caused by i.e. TCP connection resets.
https://github.com/golang/go/blob/78074f6850c34a955d69f578e363d1d3f3e00e25/src/os/signal/doc.go#L91-L110
This was reverted in 2579fe6b7bd55f341f333f4d2dab7f3a539652a5, but for a solution that also fixes #1413, you can check the file descriptor like the runtime does, and ignore for > 2.
Also, I think the fix in 2579fe6b7bd55f341f333f4d2dab7f3a539652a5 should have its own CHANGELOG line and maybe even a minor version release, as I basically can't finish a backup to B2 without a TCP reset.
(Some decent background reading is also https://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly)

@fd0 you're right, the best thing to do is to always ignore the signal, and do complete error handling + cleanup on EPIPE (or any other non-Timeout) errors from stdin/out/err.
That's also what the runtime does.
https://github.com/golang/go/blob/415349575dec277fbadf08b9d690d07fe313b288/src/os/file_unix.go#L143-L150

Good points, thanks for the analysis. I'll add an entry to the CHANGELOG now. We'll leave this issue open until writing stdout/stderr failures are checked everywhere and handled correctly.
@armhold you mentioned in #1413 that sometimes your backups fail and leave a lock file. How do you typically run restic?

Done, https://github.com/restic/restic/blob/master/CHANGELOG.md#important-changes-in-0xy

I think most (perhaps all?) of the lock situations I encountered were due to me flubbing a command line where I was piping restic output to a filter of some sort. Like this:

restic -r ~/repo cat index 8a32887 |jq'.'

This results in "command not found" and also a lock not cleaned up.

This hit me today. When trying to automate restic I run
restic forget --keep-within 1h --dry-run | grep -q '^remove [[:digit:]]* snapshots:$'

to see if there's any snapshots that'd be cleaned up. This causes the repository to get locked. Temporary workaround is to use
restic forget --keep-within 1h --dry-run | grep '^remove [[:digit:]]* snapshots:$' &>/dev/null

but it'd be nice not having to scratch my head wondering what's happening.
Since it's an old report - are there any plans on fixing it? Depending on how restic handles it, I wonder if it's possible to corrupt repository this way?

As per https://github.com/restic/restic/issues/1814, this should probably be treated as bug.
Are there any plans on fixing it?

Okay, so can we do what @FiloSottile suggested (reimplementing the SIGPIPE handling but only acting on it for file descriptors 1 and 2 (stdout and stderr), so everything > 2 is ignored)? Or won't that work for some reason I'm not seeing?

Judging from the go source code, the default behavior is currently to first ignore the SIGPIPE signal and then internally route it back to the signal handler if it is for fd 1 or 2 (look for epipecheck in the source code). The default signal handler behavior is then to terminate the process. Inside the signal handler there is no way to know which file descriptor is affected.
But what we could do is, to replace os.Stdin and os.Stderr with wrapped versions, which in the Write method check whether an error was returned that wraps EPIPE. This wrapper should then call the Exit function from cmd/restic.
I've also tried to come up with a solution that tries to route the error through restic, but that just ended up being quite horrible.


collapse Toolbar programmatically

Hi,
it would be great if you could provide a function to collapse the toolbar programmatically.
Or is a workaround with the existing functions possible?
Cheers.

I haven't tried it, but I imagine there is a function to hide or show AppBarLayout, which should be a direct parent of CollapsingToolbarLayout. Would you mind trying it? I'm sorry I couldn't help much I'm driving.

You are right. Thanks for the help^^


Confirmation when sending Tip/Support

Feedback from community member: Similar to the double confirmation we do on the wallet send page, something similar should happen for tips/supports (supports are less of an issue since they can be redeemed). This may have to be done inline on the existing modal since tips are already one.

I'll take a look


Update ujson to 1.2.2

Updates com.lihaoyi:ujson from 1.1.0 to 1.2.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.lihaoyi", artifactId = "ujson" } ]

labels: test-library-update, semver-minor

Superseded by #53.

Superseded by #53.


[Docs] Backfill all the releases on the releases page

Current Behavior

There missing release tags in the https://meshery.layer5.io/docs/project/releases
Desired Behavior

Add all the release tags of Meshery till v0.0.1 in the https://meshery.layer5.io/docs/project/releases

Contributor Resources

Meshery documentation site
Meshery documentation source
Instructions for contributing to documentation

Hi @kushthedude I'd like to give this a shot if still up for grabs 👍  . And the release tags should be "Annotated tags" yea?

Yes please go ahead @PluckyPrecious , You can find the releases in the releases section of the repo

Hi @kushthedude  the tag release doc is available for review. 😅


Escape SharedHelpers.run_shell_command

Escape the command passed to SharedHelpers.run_shell_command with shellwords.

Looks good, could we add a test to demonstrate how these will be escaped and to make sure we don't regress?

@jurre yeah great shout, pushed some tests.


Channels stuck on wainting_close_channels but final txs have been confirmed.

Background
I closed some channels a long time ago but they are stuck on waiting_close_channels
and the "unlocked" funds don't appear as unconfirmed or confirmed balance in the lnd wallet.
The corresponding final transactions have been confirmed a long time ago.
Your environment

version of lnd=  0.6.0-beta
operating system = Linux ip-10-2-11-182 4.15.0-1035-aws #37-Ubuntu SMP Mon Mar 18 16:15:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
bitcoind = v<IP_ADDRESS>-g4b4d7eb255

Steps to reproduce
Close some channels.
Expected behaviour
eventually i should see the local balance of each closed channel as wallet balance and
lnd should stop waiting for the final transactions.
Actual behaviour
Response of pendingchannels:
{
    "total_limbo_balance": "68930941",
    "pending_open_channels": [
    ],
    "pending_closing_channels": [
    ],
    "pending_force_closing_channels": [
    ],
    "waiting_close_channels": [
        {
            "channel": {
                "remote_node_pub": "021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d",
                "channel_point": "67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0",
                "capacity": "16777215",
                "local_balance": "16761438",
                "remote_balance": "0"
            },
            "limbo_balance": "16761438"
        },
        {
            "channel": {
                "remote_node_pub": "02bebaf15c038fa52a59eb5870cd3b6cb3af6b38b91c316243805df8a2dbd20d3c",
                "channel_point": "81ea221e0ddad70d5046946e89a0e5ba1b2c0b2cbd779afa676013d2181ec291:0",
                "capacity": "16777215",
                "local_balance": "16755285",
                "remote_balance": "0"
            },
            "limbo_balance": "16755285"
        },
        {
            "channel": {
                "remote_node_pub": "0330f0afe893e809d8790b26b40d9353f586ef0894d4ae704d06be24538c030457",
                "channel_point": "b852772aef9d648510978e3ad01a8ed0808dc27e34e426e90337a4f326827e31:1",
                "capacity": "16777215",
                "local_balance": "16764873",
                "remote_balance": "0"
            },
            "limbo_balance": "16764873"
        },
        {
            "channel": {
                "remote_node_pub": "0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0",
                "channel_point": "3c7cb2e054fb54a257503d1027c4d5a0ff2b42a25fa1132b1f62960838630b33:0",
                "capacity": "1900000",
                "local_balance": "1882271",
                "remote_balance": "0"
            },
            "limbo_balance": "1882271"
        },
        {
            "channel": {
                "remote_node_pub": "03df3f0a2fd6bea5429a596461ce784c922b2981ada1af89cfefcd9ccfb16c16a7",
                "channel_point": "c84288de1860aae9f18a68482e16e65a0eb1289d4c4151acea6d06101d54da3f:0",
                "capacity": "16777215",
                "local_balance": "16767074",
                "remote_balance": "0"
            },
            "limbo_balance": "16767074"
        }
    ]
}

this is one of the peding channels.
  {
            "channel": {
                "remote_node_pub": "021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d",
                "channel_point": "67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0",
                "capacity": "16777215",
                "local_balance": "16761438",
                "remote_balance": "0"
            },
            "limbo_balance": "16761438"
        },

the funding tx: https://www.blockchain.com/btc/tx/67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48
The closing tx:
https://www.blockchain.com/btc/tx/b02e9b0be768627bec12755daf649284d6dd153e83e71bc957cdadb311e3a9fd
the final tx description from listchaintxs:
{
            "tx_hash": "b02e9b0be768627bec12755daf649284d6dd153e83e71bc957cdadb311e3a9fd",
            "amount": "0",
            "num_confirmations": 1177,
            "block_hash": "00000000000000000013e444271bf52065cf4a87bc5b4fd09957e7a4d4282910",
            "block_height": 572773,
            "time_stamp": "1555948944",
            "total_fees": "0",
            "dest_addresses": [
                "bc1q4turnl6sv0qwk02mh30cldjuwx89k7h0ue3k7q",
                "bc1qvqzfqe4l4rff3pgs9s8h585ussl8h3zg4q5du68qqeq3adp4cagqyehggy"
            ]
        },

How long ago? What version were you running when you closed them? Is your bitcoind properly connected, on restart, do you see any relevant logs?

the channel 67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0 was closed on Monday, April 22, 2019 4:02:24 PM GTM
I was running lnd v0.6-beta
The bitcoind is fully synchronized and i don't see any relevant logs.
These are lnd logs for that particular channel

2019-05-01 14:43:09.231 [DBG] CNCT: Stopping ChannelArbitrator(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0)
2019-05-01 15:14:30.665 [DBG] CHBU: Crafting backup for ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0)
2019-05-01 15:14:32.801 [DBG] CNCT: New ChainEventSubscription(id=0) for ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0)
2019-05-01 15:14:32.802 [DBG] CNCT: Starting chain watcher for ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0)
2019-05-01 15:14:32.802 [DBG] NTFN: Using height hint 574097 retrieved from cache for outpoint=67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0 instead of 570077
2019-05-01 15:14:32.802 [INF] NTFN: New spend subscription: spend_id=7, outpoint=67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0, height_hint=574097
2019-05-01 15:14:32.802 [DBG] NTFN: Dispatching historical spend rescan for outpoint=67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0
2019-05-01 15:14:32.895 [INF] CNCT: Close observer for ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0) active
2019-05-01 15:14:33.514 [DBG] CNCT: Starting ChannelArbitrator(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0), htlc_set=(contractcourt.htlcSet) {
2019-05-01 15:14:33.514 [INF] CNCT: ChannelArbitrator(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0): starting state=StateCommitmentBroadcasted
2019-05-01 15:14:33.775 [INF] CNCT: ChannelArbitrator(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0): noop trigger chainTrigger
2019-05-01 15:14:38.073 [DBG] LNWL: ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0), starting local commitment: (*lnwallet.commitment)(0xc000f86240)({
    PreviousOutPoint: (wire.OutPoint) 67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0,
2019-05-01 15:14:38.078 [DBG] LNWL: ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0), starting remote commitment: (*lnwallet.commitment)(0xc0026e6cc0)({
    PreviousOutPoint: (wire.OutPoint) 67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0,
2019-05-01 15:14:38.079 [INF] PEER: NodeKey(021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d) loading ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0)
2019-05-01 15:14:38.079 [WRN] PEER: ChannelPoint(67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0) has status ChanStatusDefault|ChanStatusBorked|ChanStatusCommitBroadcasted, won't start.

2019-05-01 15:14:32.802 [DBG] NTFN: Using height hint 574097 retrieved from cache for outpoint=67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48:0 instead of 570077

Looks like the cache stored a value (574097) past the spending height (570077).

@sebareca to help narrow it down, I'd like to know if we missed the spend while we were online or offline. Do you see the log message New block: height=572773 within your logs? If you don't, what's the earliest height you see?

Our server erased all the logs :S. I will try to reproduce the problem once again.

It might not be so easy to reproduce considering this is the first report of its kind on something that's done quite often within lnd. If you're comfortable with compiling from source, you can use the following patch to use the right height in order to detect the spend and proceed to sweep the channel:
diff --git a/chainntnfs/txnotifier.go b/chainntnfs/txnotifier.go
index 919c08d8..8791c779 100644
--- a/chainntnfs/txnotifier.go
+++ b/chainntnfs/txnotifier.go
@@ -853,6 +853,15 @@ func (n *TxNotifier) RegisterSpend(ntfn *SpendNtfn) (*HistoricalSpendDispatch,
 			ntfn.SpendRequest, err)
 	}

+	hash, err := chainhash.NewHashFromStr("67db75d7700d2a2db8ffddd11441193cb9416b6ae8229e06ac8f5c97adc42a48")
+	if err != nil {
+		return nil, 0, err
+	}
+	op := wire.OutPoint{Hash: *hash, Index: 0}
+	if ntfn.OutPoint == op {
+		startHeight = 572773
+	}
+
 	n.Lock()
 	defer n.Unlock()

I think it would be great if we can add option of rescanning blockchain if wallet fails to confirm transaction status and give option of revealing seed phrase so that even if  wallet doesn't rescan or picks up the true status, user can delete all data and reinstall the wallet.


[CodeCompletion] Don't recommend functions with async alternatives in async contexts

When an function has an async alternative, that should be preferred when we are completing in an async context. Thus, the sync method should be marked as not recommended if the current context can handle async methods.
rdar://88354910

@swift-ci Please smoke test

@swift-ci Please smoke test


External data type 'user-defined-type' is currently not supported

I am trying to query a file in ADO.NET but am getting the following error:
"Unhandled Exception: Microsoft.Data.SqlClient.SqlException: External data type 'user-defined-type' is currently not supported. File: 'https://e....."
Which confuses me because all of the documentation that I have read seems like I should be able to query UDTs just fine.
Here is the relevant portion of my code:
      using (SqlConnection conn = new SqlConnection(ConnectionString1))
        {
            conn.Open();

            //query parameters
            string sqlScript =
                @"SELECT TOP 10 Id
                    FROM OPENROWSET(BULK 'filepath',
                    FORMAT = 'xxx')
                    AS Index
        ";

            using (var cmd = new SqlCommand(sqlScript, conn))
            {
                SqlDataReader reader = cmd.ExecuteReader();
                while (reader.Read())
                {
                    Console.WriteLine(String.Format("{0}", reader[0]));
                }
            }

        }
        Console.ReadKey();

Would that work on desktop net framework? I don't see how the reader is supposed to know what the data type of the columns from the external data set is.

@rtenten which documentation were you referring to?

@rtenten Could you provide your repro?

Closing due to inactivity and lack of repro.


Change cryptsetup encryption to aes cbc

The Raspberry Pi 5 includes AES acceleration (AES-256-CBC). This is much faster than xchacha20,aes-adiantum-plain64
#            Algorithm |       Key |      Encryption |      Decryption
xchacha20,aes-adiantum        256b       398.9 MiB/s       418.8 MiB/s
               aes-cbc        256b       886.1 MiB/s      1848.6 MiB/s

I have tested these changes on my raspberryi pi 5 and works like a charm. Thanks for sdm.
Sources:
https://www.hackster.io/news/raspberry-pi-5-review-hands-on-with-the-most-powerful-raspberry-pi-yet-57efaf61b10f
https://www.raspberrypi.com/news/introducing-raspberry-pi-5/
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-5

Thx for pointing this out. While aes works well on the Pi5, it sucks wind on the Pi4. So, will be incorporating your changes with aes as the default and a switch for using xchacha.


Solve race during creation of egg cache (fixes #1256)

Summary of changes
This patch solves a race condition in get_cache_path in pkg_resource init.py, which generally shows its head:

In high volume CICD systems with many cores
where the build job is configured to use all of said cores
where there is a lot of concurrent python-y stuff happening around the same time

Closes #1256
Details of change
Upstreaming a private fix that we have applied to python-setuptools 0.9.8 that solves a race during the creation of an egg cache. We use setuptools 0.9.8 with this fix internally on some of our projects. This fix has been in production for May 2017 and is working great.
The challenge we ran into is that setuptools, by itself, works great, both on development laptops/desktops, our fleet of development VMs, and so on. When put in a high volume CICD pipeline, even the latest version of python-setuptools falls on its face immediately (39.2.0, we haven't tried 40.x since it just came out a few hours ago). there was a recent-ish change (#1083) that (sounded) like it would address this, but did not
We suspect that given the build machines have 32 cores, and we're using make -j32, the concurrency is biting us here. We've added this small patch to work around it, and as mentioned, it has been great.
For sanity, I did include the most recent failure logging from this morning from the 32 core build system here: https://github.com/pypa/setuptools/issues/1256#issuecomment-403547646
In an effort to get off that ancient version of setuptools, we're submitting this upstream, with the hopes that we can get this mainlined, and can then stay on vanilla "fresh off the branch" versions going forward.
Pull Request Checklist

[x] Changes have tests
[x] News fragment added in changelog.d.

Given that this is a tricky to reproduce on a small scale race condition / edge case, can I get an exception on code coverage? or do you want coverage for this?

I think there are probably ways you can force the "race condition". My initial instinct is patching one of the files involved to create the directory at the right time.
I'm not entirely sure I understand why _bypass_ensure_directory exists, though. It seems like it's a deliberate choice, but I don't know what "sandbox" it's referring to that needs to be bypassed. Does os.makedirs have the same race condition?

hey @pganssle - Yes for sure there are ways you can force a race condition, but gut feeling is its a bit more a pain than it might be worth, as you'll get this to bomb out in the same way its bombing out today with the existing logic thats in place. Meaning, you wouldn't have uncaught errors.
Anyhow - Offhand, I dont know why the bypass exists; however, this is where it fails, this is it.
I know that the code (from git blame) hasn't been touched in 3-4 years; however, even before that (for example on our 0.9.8) its just about the same, just was in a different place before that refactoring 3-4 years ago.

@JonKohler I think my point is it's hard for me to evaluate if this actually works without tests. You mention it's hard to reproduce on a single machine so I haven't tried.
Can you check if switching the _bypass_ensure_directories over to ensure_directories causes problems in your system that can reproduce the issue? If the original SandboxViolation referred to in this commit doesn't apply anymore for whatever reason, we may be able to drop it.
As an aside, this is one very good reason to include tests for whatever behavior you care about. If the SandboxViolation change had associated tests, we'd be able to tell if removing _bypass_ensure_directories would cause a regression.

Thanks for the splunking @pganssle . Following that commit leads to this Distribute issue which links to this old Setuptools issue. Probably those issues still exist, although they're probably drastically reduced by the limited use of easy_install these days.
I'm hesitant to accept this change as (a) it is duplicating the behavior in py31compat, (b) it's added inline so difficult to tell if it's important, (c) it adds complication without any hope of ever breaking free, and (d) the sandboxing code isn't relevant except when using easy_install, which is deprecated.
My temptation is to remove the bypass function, rely on ensure_directory, and hope users no longer run into the issue... and if they do see if we can migrate them to pip instead of easy_install.

Alright, ill give it a whack. I've just upgraded our CICD to 39.2 with this fix, and for sure it works (horray!) but I'll try switching back to ensure_directories and see what happens.
If I'm lucky, that change combined with the previously mentioned #1083 might just fix this by default

Ok, I've updated the PR with what I've just committed in our side. I've moved from 39.2.0 to 40.0.0 and applied the same fixes on our side.
It takes a few hours for our toolchain to build (its big), then I'll retarget the CICD to use said toolchain. The problem appears immediately in the CICD builds, so I should (knock on wood) know yes/no today

It's a good sign that the tests are passing, but I'm still a bit anxious because we didn't have a test for the SandboxViolation problem in the first place, I'm not how to tell if removing the _ensure_directory_bypass is going to cause a regression or not. I'm thinking it is going to cause a regression, because after quite a bit of digging around I can't see any substantial changes in behavior in the sandbox between now and when the original bypass commit occurred.
I think the best options for now are:

Try to write a failing test for the original SandboxViolation error so that we can see if we can fix it without writing our own makedirs.
Write a test that exercises something like @JonKohler's original patch and accept that. I'll note that the upstream version of makedirs has a similar implementation.

I think the main problem here is that because makedirs is implemented in terms of mkdir, we need to re-implement makedirs in terms of the non-sandboxed mkdir in order to bypass the sandbox for makedirs. We may be able to change the implementation of the sandbox to make it easier to bypass the sandbox when using derived functions like makedir (for example, we could have the os wrapper add an os._bypass_sandbox submodule that exposes all the original functionality).

Thanks again @pganssle ! Adding in @jaraco and @dirk-thomas to this conversation - as they did the original work and commentary on #1083 as well as https://github.com/pypa/setuptools/commit/925dd35ec77d4cfd79c899f34255e3a753f33ca5
Hey guys - can you help out in this conversation, for some of the historical context on the ensure_directory vs bypass_ensure_directory? We see some good work being done to fight race conditions on https://github.com/pypa/setuptools/commit/925dd35ec77d4cfd79c899f34255e3a753f33ca5 / #1083, but the get_cache_path code wasn't touched at this time, so we're running into races there.
I had two proposed fixes:
1 - fix the race condition in bypass_ensure_directory, which we've had in production for a year
2 - nuke bypass_ensure_directory and unify all code paths to go through ensure_directory, which is what the active state of this PR is

I don't have enough context around WRITE_SUPPORT and if it is still needed to be handled separately. Besides that the patch looks fine to me. Certainly addressing the same race for this case. :+1:

@dirk-thomas I think the WRITE_SUPPORT thing is not so important - that seems to be a check that the platform actually supports the operations you're trying to do. The reason _bypass_ensure_directory exists is because the Sandbox modifies os with wrappers that prevent certain actions outside of the sandbox. Something related to the cache directory was causing SandboxViolation errors, which is why there's a bypass function.

@pganssle - our toolchain just finished building, and I kicked off the CICD job, and it built up the egg cache perfectly. We're using setuptools 40.0.0 from pypi with the modifications from this PR as of right now.
Once this build finishes and passes all of the smoke/testing/blah blah blah, we'll merge it. Once that's done, all of our CICD builds will run against this, and we'll be able to tell immediately if this is going to die in a fire or not.
net - it's looking really good thus far, and knock on wood, i think this might be a winner
Assuming that it is good, looking at the issue where the sandbox shenanigans originally occurred (back in 2008!) https://bugs.python.org/setuptools/issue23 ... at that time, they're saying the same things ... they can't reproduce it, but this race-generating fix happened to fix it at the time.
I suspect even though they probably tested it a bit, that they just didn't have the processing power 10 years ago to hit this with predictability.
that leaves us in an interesting spot. We might cause a bit of a regression, but the original fix wasn't bulletproof either.
Thoughts?

@JonKohler I think we're still in the same position with respect to the above. We should come up with a regression test for at least one of these problems and go from there.
If we really can't reproduce the SandboxViolation, I think I'd prefer to play around with the sandboxing logic to give us easier access to a sandbox-bypassing version of os.makedirs rather than just removing the sandbox bypass entirely. That seems like the most surgical approach, and we can open a new issue for "write a test that induces the SandboxViolation issue" to track whether the sandbox bypass is even necessary.

Thanks again @pganssle - I do appreciate the commentary and guidance. I've been discussing this internally with the developer who first fixed this (with the original bypass race fix).
For the race condition: The only test we can think of that might even get close to semi-reliably reproducing this on demand is spawning a ton of processes that import a python library from the same egg file.
For us, since we can hit this 100% of the time with our particular CICD setup, we're happy with the fix as is; however, I dont want to leave you guys high and dry.
From an "outsider looking in" perspective, the original commit (and others via googling around) have a really hard time reproducing this with certainty when it has come up.
If we do write a unit test, I have a feeling that to get it to do what we want it to do, it would be convoluted and may end up driving inconsistency. That means false negatives and false positives, which is a nightmare.
Truly, I’m against writing unit tests, it's just tricky hard to deterministically test against this it seems, which means we'd be doing more harm than good.
As for the sandboxing logic, in reading the previous commits and chatter, my gut feeling is the following:
@jaraco mentioned:

the sandboxing code isn't relevant except when using easy_install, which is deprecated.

So, we've had this half-racy code in the code base for the better part of 10 years, and the masses arent out with pitchforks. Given the moves away from easy_install and the moves from python2 (going out to pasture soon enough) to python3; honestly, it might be better to rip the bandaid off here and intentionally open up to a regression / breaking change.
I say that because, if we do that, we might run into a situation where a user actually has a 100% reproducible use case we could debug and fix properly.
Otherwise, as @jaraco said, we could end up in a situation where we've got complexity with no light at the end of the tunnel.
All that said, there is a really good chance, since this has been kicking around for 10 years, that fixes in the surrounding code (setuptools, python, or linux/etc) have actually made this a non-issue, so all this discussion could be 100% academic.
Thoughts?

ninja edited above comment to reflect that I'm NOT against writing the tests (original text didn't have the NOT) :)

I think the fact that we can (eventually) ditch the sandbox stuff entirely is an argument in favor of just improving it in this somewhat minor way now, because we know that long term there will be minimal maintenance burden (since that code is going away). I don't think we should be introducing regressions just because it's hard to test fixes.
With regards to the testing, I think the best option to do it deterministically is some sort of mock that deliberately introduces the race condition, though I will note that this relies on implementation details of our solution itself. If we end up using a different solution (like the unpatched os.makedirs, or even the patched os.makedirs), I think we would need to use a different test. I have created a proposal in #1418.

Thanks @pganssle - I appreciate it! I looked at #1418  ... LGTM, I appreciate it.
Assuming #1418 get accepted, are we good here? or do you need more of us? Happy to continue the work/conversation here, just want to make sure I know what action items are left :)

Is this replaced by PR #1418?


Unmarshalling exception when uploading from Jenkins -> Dependency Track (version git: 4b4b0975bd7a9)

Hi Steve,

I built the latest commit from git (4b4b0975bd7a9) and uploaded it to the server
Jenkins: dependency check plugin 3.2.1
I get an Exception in ScanUploadProcessingTask:

2018-06-07 17:40:54,221 [] ERROR [org.owasp.dependencytrack.tasks.ScanUploadProcessingTask] Error while processing scan result
2018-06-07 17:40:54,221 [] ERROR [org.owasp.dependencytrack.tasks.ScanUploadProcessingTask] javax.xml.bind.UnmarshalException
 - with linked exception:
[javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: Premature end of file.]

To check if the XML report itself is OK, I uploaded it via curl manually, it worked.

I can provide the report XML tomorrow if you need it - would need to clean up confidential information first. Let me know if you are interested.

If you're testing with Dependency-Track 3.1 snapshot, there's improvement in error handling #162 which should help diagnose the issue. If you're still not able to figure it out or need me to make changes in order to reproduce, send me the file, attached to this ticket or via email (steve.springett@owasp.org).

Thanks for the help Steve, I figured it out, although the hint to the cause was already in the original message. In contrast to the DependencyCheckPublisher, the DependencyTrackPublisher doesn't have a default value for artifact and returns success in this case.
I'll close this issue and open an issue with jenkinsci/dependency-check-plugin

https://github.com/jenkinsci/dependency-check-plugin/pull/25

Glad you figured it out and thanks for the PR


move circuit testing logic in Makefile

I also tried to make it work on Mac but shelving efforts for now.

I tried manually modifiying the generated makefile, here's my best attempt:
JSON_INCLUDE=$(shell brew --prefix nlohmann-json)/include
GMP_INCLUDE=$(shell brew --prefix gmp)/include
export LIBRARY_PATH += :$(shell brew --prefix gmp)/lib
export CPLUS_INCLUDE_PATH += :$(JSON_INCLUDE):$(GMP_INCLUDE)

CC=g++
CFLAGS=-std=c++11 -O3 -I.
DEPS_HPP = circom.hpp calcwit.hpp fr.hpp
DEPS_O = main.o calcwit.o fr.o fr_asm.o

ifeq ($(shell uname),Darwin)
	NASM=nasm -fmacho64 --prefix _
endif
ifeq ($(shell uname),Linux)
	NASM=nasm -felf64
endif

all: play.test

%.o: %.cpp $(DEPS_HPP)
	$(CC) -c $< $(CFLAGS) -include ../../uint.hpp

fr_asm.o: fr.asm
	$(NASM) fr.asm -o fr_asm.o

play.test: $(DEPS_O) play.test.o
	$(CC) -o play.test *.o -lgmp

This adds the first block, as well as the -include flag (included file only contains typedef unsigned int unit;
This takes me as far as I'll get: after that we run into the issue that circom-helper uses fr.asm which is assembly not compatible with Apple Silicon's ARM architecture.


Is there a roadmap for gitless?

I don't like git. It's confusing and messy. In fact, right now we're having chaos in another project just because of how git handles line endings...
That's why I like gitless. It's... easier to think about my repos with it. It's just better in most ways.
Hence, I want to know:

Is its design still evolving? Do you have a mailing list for that?
Are you still doing studies on the ergonomics of git and gitless, like this one?

And... lemme know if there's parts where I can give effective feedback. VCS doesn't have to be as hard as it is today :)

I don't like git. It's confusing and messy. In fact, right now we're having chaos in another project just because of how git handles line endings...

That's interesting, if you'd like to share what happened and what potential solutions (if any) you have in mind we can see if it is something that we can fix in Gitless

That's why I like gitless. It's... easier to think about my repos with it. It's just better in most ways.
Hence, I want to know:
Is its design still evolving? Do you have a mailing list for that?
Are you still doing studies on the ergonomics of git and gitless, like this one?

There's no mailing list. I still have a few ideas I'd like to pursue but no specific roadmap yet. My top priority right now is to fix the bugs people have reported, but I am a swamped with other projects at the moment so it's hard for me to find the time to work on Gitless.

And... lemme know if there's parts where I can give effective feedback. VCS doesn't have to be as hard as it is today :)

I agree! and feedback is always welcome. If you have some ideas you'd like to discuss feel free to open a new issue.

I think that's a worthy goal for the starters - https://github.com/sdg-mit/gitless/issues/176


Reducing cyclomatic complexity of search and addressing offset awareness issue

Includes 2 contributions:

Since the search functionality is complex, the first change addresses cyclomatic complexity and deep indentation in the search code. This should make the code easier to read and maintain.
Addresses #679 by handling timezone offset awareness.

Oooo, ok. I'll add an additional test here.

hey @noviluni So seems like the CC is complaining because I haven't hit this line.
Totally understand. Here's the problem... after code tracing, it doesn't seem that dateobj will ever have tzinfo as the code is currently written, so in practice this line of code is dead. My concern is that if the code changes to now start adding at tzinfo, this bug will be reintroduced. While I can easily remove this path, I do not feel that for the longer term this is the right thing to do.
Thoughts?

What about adding an assert for dateobj’s tzinfo being None, with a comment that explains that if it ever becomes possible for that to be something other than None, the code needs to change, and describes exactly how it needs to change?

What about adding an assert for dateobj’s tzinfo being None, with a comment that explains that if it ever becomes possible for that to be something other than None, the code needs to change, and describes exactly how it needs to change?

Great idea! Totally forgot about using an assert here. Changing it now.

Thank you!


auto completion missed in vscode 1.29.1

What is the problem?
auto completion missed in vscode 1.29.1
How can I reproduce it?
test
$\int$
$\a$

Is there any error message in the console?
no
just auto completion doesn't work. it cannot give any hint when I type \a

Works well on my laptop. It is strange if there is also no error message.
Could you disable all other extensions and try again?

What will happen if you manually execute Trigger Suggest in the command palette (ctrl/cmd+shift+p)

I don't know what happened, it can work now. I just renamed .vscode to .vscode_bak, then started a new environment, exited vscode, and changed .vscode_bak back to .vscode. It is now automatically prompted.

thanks @neilsustc

😂

@neilsustc I struggled with this too. I think this happens somehow for files which are not in the current workspace.
To reproduce:

Open a workspace/project.
Open its README.md or any other .md -> autocomplete works.
Move file out of the project folder -> autocomplete stops working.

Alternatively:

It also does not work on if you just open a single markdown file (by double click) or create a new buffer with ctrl+n and change the language with ctrl+k m to Markdown.

Maybe this is the problem in #330 too?

Another case where autocomplete does not work perfectly (possibly confusing people with "editor.suggestOnTriggerCharacters": false) is when the completion process is invoked after a non-\ character, i.e.:

Type \ -> autocomplete panel shows automatically.
esc -> abort/hide panel
ctrl-space -> autocomplete works
Type a -> autocomplete shows \And, ...
esc -> abort/hide panel
ctrl-space (cursor after \a) -> only basic text completes

Maybe it should only check this when completing an image path and not in a math context?

Makes sense! Thank you

ctrl-space (cursor after \a) -> only basic text completes

Will have a look later


copyright year to 2015 => 2016

Jenkins: test this please.

Jenkins: test this please

Jenkins: test this please


adding go application having ent support

this PR closes:https://github.com/keploy/keploy/issues/417
this is TASKMANAGER application having ent support .
in this application Ent is used as an ORM  library to manage database operations.

Hey . @Sekhar-Kumar-Dash we have to check if we have support for ent in keploy go-sdk yet . Since ent is an ORM we should be able to generate mocks for it ,We prefer to add samples apps with keploy integrated to it .

this issue specifically asked for the ent support https://github.com/keploy/keploy/issues/417


SAK-31434 Enable PA system by default.

@buckett Could you add these properties to the default.sakai.properties? I didn't even see them there with the old defaults.

@jonespm Added.

Great thanks!


adding "height: auto" to ".entry .content img" rule

This prevents images from getting distorted, due to the max-width: 100% rule, when the image's markup includes width and height attributes. So, height: auto; will respect the img's aspect ratio and resize it properly.

thanks!


Updated VirtualBox to latest version 5.2.12-122591

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

5.2.12-122591  is the current version in the Cask.
https://github.com/caskroom/homebrew-cask/blob/f582cff18fbdffa27397a3ff255f3921a72df889/Casks/virtualbox.rb#L1-L3


Unable to edit workload scheduling rule in UI

Rancher version
master 8/22
Steps to reproduce (least amount of steps as possible):

Go to the Default project, click Deploy
input ngx as the name, nginx as the image. Click Launch.
Edit the ngx workload, click Node Scheduling,
Add a a=b rule to the require-all session. Click Save.

Result:
The rule is not saved.
See JS errors in the console.

Rancher version: master-head (v2.3) (08/28/2019)
I was able to use all the operators individually and save the rules without errors in a workload.
Also tested combination of operators, all were saved without JS errors.
In both cases the rules were applied to the workload pods.


Adding page on rho statistics

Related to issue #34 .
Note : it seems that jupyter book doesn't really like the align environment for some reason, so take a look at the notebook.

I think we should be overall ready to merge unless there are more comments ; we can make another PR if there are additional changes to make.

@thuiop @aboucaud Have you tested that the Binder badge is working correctly?

I have not tested yet. It seems the Justine is reading the PR currently so we should wait until she is done.

OK, everything looks good to me. I can tag @aboucaud to merge once you guys are finished checking things on your side.

@Justinezgh is currently reviewing it. Once done I'll merge.

@aguinot I pushed the changes I made, the plot is a bit messy though because I reduced the base g1... also, the book is probably not building the page correctly because generating the image is too long. Maybe we should save the image in the repo and reuse the same ?

Right, if an image is too long to build you can probably write the code for it but also store it as a static image in the _static repo.

Right, if an image is too long to build you can probably write the code for it but also store it as a static image in the _static repo.

Do you want to make this change now? Or should we merge and update this page later?

Just wondering if it will break the CI or not

I don't think it will break the CI but the page won't run correctly. I will make this change during the weekend.

Some conflicts have emerged with the merging of the updated env : please check that @thuiop

I fixed the merge conflicts.
I made some more changes to the notebook, it now runs quicker than before so we do not need to save the image beforehand. The results are still not perfect and will need to be reworked later, but I think that for now we can merge this PR.


PMID:17936710

1 abolished double-strand break repair via nonhomologous end joining
2 abolished protein localization to chromatin at MCB promoters

abolished double-strand break repair via nonhomologous end joining FYPO:0005459
abolished protein localization to chromatin at MCB promoters FYPO:0005460
edit file: d8503b19b33d8680617723a57cf17c4a9ff14d58
release: ebe6a940a23af8e421a8673f8a946f77e8b967f5


Not able to decline the call

I am not able to decline the call on Galaxy s10 on Android 10. This was not an issue for galaxy s10 on android 9 and has not been an issue on any other test phones.

+1, same here in note 9 with android 10

+1


GCP instancegroupmanagers don't appear to be created

When I try applying the following state to a GCP cluster, following the docs it fails when waiting for the master IP.
x1c in /home/nrb/go/src/github.com/kris-nova/kubicorn (git) master
% kubicorn create myk8s --cloudid nolan-heptio --profile google
2017-11-06T09:38:03-05:00 [✔]  Selected [fs] state store
2017-11-06T09:38:03-05:00 [✿]  The state [./_state/myk8s/cluster.yaml] has been created. You can edit the file, then run `kubicorn apply myk8s`

x1c in /home/nrb/go/src/github.com/kris-nova/kubicorn (git) master
% cat _state/myk8s/cluster.yaml
SSH:
  metadata:
    creationTimestamp: null
  publicKeyPath: ~/.ssh/id_rsa.pub
  user: ubuntu
cloud: google
cloudId: nolan-heptio
kubernetesAPI:
  metadata:
    creationTimestamp: null
  port: "443"
location: us-central1-a
metadata:
  creationTimestamp: null
name: myk8s
serverPools:
- bootstrapScripts:
  - bootstrap/google_compute_k8s_ubuntu_16.04_master.sh
  image: ubuntu-1604-xenial-v20170811
  maxCount: 1
  metadata:
    creationTimestamp: null
  name: myk8s-master
  size: n1-standard-1
  type: master
- bootstrapScripts:
  - bootstrap/google_compute_k8s_ubuntu_16.04_node.sh
  image: ubuntu-1604-xenial-v20170811
  maxCount: 2
  metadata:
    creationTimestamp: null
  name: myk8s-node
  size: n1-standard-1
  type: node
values:
  itemMap:
    INJECTEDTOKEN: 2dfb52.a111929bb3699922
  metadata:
    creationTimestamp: null

The apply call:
x1c in /home/nrb/go/src/github.com/kris-nova/kubicorn (git) master U
% GOOGLE_APPLICATION_CREDENTIALS=~/Downloads/nolan-heptio.json kubicorn -v 5 apply myk8s
2017-11-06T09:39:38-05:00 [✔]  Selected [fs] state store
2017-11-06T09:39:38-05:00 [✔]  Loaded cluster: myk8s
2017-11-06T09:39:38-05:00 [✔]  Init Cluster
2017-11-06T09:39:38-05:00 [▶]  Running preprocessors
2017-11-06T09:39:38-05:00 [▶]  Running validations
2017-11-06T09:39:38-05:00 [✔]  Query existing resources
2017-11-06T09:39:38-05:00 [▶]  instanceGroup.Actual
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Actual
2017-11-06T09:39:39-05:00 [✔]  Resolving expected resources
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Expected
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Expected
2017-11-06T09:39:39-05:00 [✔]  Reconciling
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Actual
2017-11-06T09:39:39-05:00 [▶]  Using cached instance [actual]
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Expected
2017-11-06T09:39:39-05:00 [▶]  Using instance subnet [expected]
2017-11-06T09:39:39-05:00 [▶]  instanceGroup.Apply
2017-11-06T09:39:39-05:00 [▶]  Actual   : 8da063605f3dad6334d9b2fcca0509cb
2017-11-06T09:39:39-05:00 [▶]  Expected : 6360fcab378f8b189b6306db5bc62ae7
2017-11-06T09:39:39-05:00 [✔]  Parsing bootstrap script from GitHub [https://raw.githubusercontent.com/kris-nova/kubicorn/master/bootstrap/google_compute_k8s_ubuntu_16.04_master.sh]
2017-11-06T09:39:41-05:00 [▶]  Creating instance group manager
2017-11-06T09:39:41-05:00 [▶]  Waiting for instance template to be ready.
2017-11-06T09:39:44-05:00 [▶]  Creating instance group manager
2017-11-06T09:39:45-05:00 [✔]  Created instance group manager [myk8s-master]
2017-11-06T09:39:45-05:00 [▶]  instanceGroup.Render
2017-11-06T09:39:45-05:00 [▶]  instanceGroup.Actual
2017-11-06T09:39:45-05:00 [▶]  Using cached instance [actual]
2017-11-06T09:39:45-05:00 [▶]  instanceGroup.Expected
2017-11-06T09:39:45-05:00 [▶]  Using instance subnet [expected]
2017-11-06T09:39:45-05:00 [▶]  instanceGroup.Apply
2017-11-06T09:39:45-05:00 [▶]  Actual   : 4c0fb45bb8f449132847c6f78b74f4ad
2017-11-06T09:39:45-05:00 [▶]  Expected : 6b16297f6398c8b75de6d8442f1de8e4
2017-11-06T09:39:45-05:00 [▶]  Hanging for master IP.. (<nil>)
2017-11-06T09:39:48-05:00 [▶]  Hanging for master IP.. (<nil>)
2017-11-06T09:39:52-05:00 [✖]  Error during apply of atomic reconciler, attempting clawback: googleapi: Error 404: The resource 'projects/nolan-heptio/zones/us-central1-a/instanceGroupManagers/myk8s-master' was not found, notFound
2017-11-06T09:39:52-05:00 [!]
2017-11-06T09:39:52-05:00 [!]

NAME        LOCATION       SCOPE  BASE_INSTANCE_NAME  SIZE  TARGET_SIZE  INSTANCE_TEMPLATE  AUTOSCALED
myk8s-node  us-central1-a  zone   myk8s-node          0     1            myk8s-node         no

x1c in /home/nrb/go/src/github.com/kris-nova/kubicorn (git) master U
% GOOGLE_APPLICATION_CREDENTIALS=~/Downloads/nolan-heptio.json gcloud compute instance-groups managed list
NAME          LOCATION       SCOPE  BASE_INSTANCE_NAME  SIZE  TARGET_SIZE  INSTANCE_TEMPLATE  AUTOSCALED
myk8s-master  us-central1-a  zone   myk8s-master        1     1            myk8s-master       no
myk8s-node    us-central1-a  zone   myk8s-node          1     1            myk8s-node         no

I have a project in GCP, and I have tcp:443 forwarded through the  firewall:
.
My IAM user has pretty wide permissions:

Compute Admin
Organization Administrator
Project IAM Admin
Service Account Admin

During debugging, I tried making the MasterIPSleepSecondsPerAttempt in cloud/google/compute/resources/instancegroup.go, 60s after seeing #468 but this did not seem to help.
Setting the returned Operation at https://github.com/kris-nova/kubicorn/blob/master/cloud/google/compute/resources/instancegroup.go#L297 to a variable and logging it with %v, I saw the status always came back as PENDING. However, I wasn't sure how to use that object to long-poll, per some google docs.

Also, deleting the cluster that I manually spun up appears to work just fine. It reports things are fine on the CLI, and the resources are gone on my console.
x1c in /home/nrb/go/src/github.com/kris-nova/kubicorn (git) master U
% GOOGLE_APPLICATION_CREDENTIALS=~/Downloads/nolan-heptio.json kubicorn delete myk8s
2017-11-06T14:21:40-05:00 [✔]  Selected [fs] state store

Destroying resources for cluster [myk8s]:
2017-11-06T14:21:41-05:00 [✔]  Deleting InstanceGroup manager [myk8s-node]
2017-11-06T14:22:30-05:00 [✔]  Deleting InstanceGroup manager [myk8s-master]

After finding the StackDriver logs on my GCP console, I noticed I was getting these errors when Kubicorn was running:
   error: [
   0: {
    code: "SERVICE_ACCOUNT_ACCESS_DENIED"
    detail_message: ""
    location: ""
   }
  ]

After some experimentation, I found I needed to add the Service Account User role to my account; the Service Account Admin mentioned in the original comment apparently means that the account can manage other service accounts, but cannot act as one.
So in the end, it wasn't a Kubicorn bug, but perhaps I can explore the minimal set of permissions necessary to run Kubicorn and put those in the docs?

Thank you so much for checking this for us!! We really appreciate it.
If you find some time and willing to help, it would be great idea to document what are required permissions in order to create cluster on GCP. We would highly appreciate it.

thanks for this
i'm new to gcp and got stuck with the same issue

In my case, I was only able to make it work when using the Compute Engine default service account . Whenever I create a new service account, in theory replicating the same permissions as the default one, it fails. But I'm a newbie in GCE so probably missing something.
Could someone shed some light?


README.md:10: Explain how this package is intended to be...

The puzzle 1-f29a2224 from #1 has to be resolved:
https://github.com/dartoos-dev/json_cache/blob/138f45fe51cb15851f9240e8ea6e8cf18a03c037/README.md#L10-L10
The puzzle was created by @rafamizes on 23-May-21.
role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 1-f29a2224 has disappeared from the source code, that's why I closed this issue.


support createInstance

Hi there!
Thanks a lot for this package - its really nifty. In fact I am using it as a dependency in a cache wrapper im working on :). I haven't tested this in live code, but writing jest tests for my package, I noticed something peculiar-
const AsyncStorageDriver = driverWithDefaultSerialization()
await localforage.defineDriver(AsyncStorageDriver)
await localforage.setDriver(AsyncStorageDriver._driver)
//@ts-ignore
console.log(localforage._driver) // "rnAsyncStorageWrapper-withDefaultSerializer"

const instance = localforage.createInstance()

//@ts-ignore
console.log(localforage._config._driver) // "localStorageWrapper"

Does this package support instances?

 Closing this issue...

Okay, no problem. If you still perceive some issues, let me know.

well, i will suggest adding a paragraph in the docs for making sure to also do this:
const instance.createInstance({ driver: AsyncStorageDriver._driver })

Otherwise the driver is not passed from localForage. I'd assume this is a very "hidden feature" or simply broken localForage functionality 😉

Ah I see. I always did somehow the following as in the LF-docs:
const instance = localforage.createInstance({ name: 'mySecretInstanceName }); // because I required multiple instances with different names ...
instance.defineDriver(AsyncStorageDriver._driver);

:smile:
I will somehow add it and suggest both solutions...

Added to the docs, see: 74e05164ae4efc52275c10bae43886459df345d0

The documentation misses saying this step which is essential.
instance.defineDriver(AsyncStorageDriver._driver);

instance.defineDriver(AsyncStorageDriver._driver);

it's worth noting this returns a promise, so you will likely need to do await instance.defineDriver(AsyncStorageDriver._driver);, depending how your code is arranged


Use setuptools

Hello,
I refactored the folder structure to use setuptools.
The code and the Dockerfile were updated and a section in the READMD.md was added to explain how to setup dev env

Fantastic, thanks Thibaut.


Existing software to compute sensitivities

This thread is to add software that compute sensitivities though ODE solver at least with one of the methods explained in the review paper.

CVODES in Sundials
FATODE in Fortran
ODESSA in Fortran
SciMLSensitivity.jl in Julia

The NeuralODE paper has a couple of references that I am not sure fall into this, but may be worth exploring

DENSERKS in Fortran introduced in Forward and adjoint sensitivity analysis with continuous explicit Runge–Kutta schemes


pain.csv database and MKDAscript.m

This PR contains the pain.csv database used for the MKDA analysis as well as a MKDAscript.m for running the analysis.

Hi @AlexBowring: thanks for this! Could you comment this script to mention any value you have to manually type in when running the script (e.g. selection of the contrast)?

Hi @cmaumet, I have updated this PR with the results output from matlab file and commented on the script as you requested above.

Thank you @AlexBowring! To help replicate the analysis you did, could you also explicitely state in the comments which option you used?
For example with "During this stage the [missing user] specifies which variables (regressors) will be used during the analysis". Could you add which regressor you actually used? How is this entered into the program: using the regressor name, a numerical index...? If you can make a copy in the comment of what you typed in at each stage that would be very helpful for a user trying to replicate this exact analysis.

Okay @cmaumet I have updated the script again, let me know if it is clear now

That looks good!


githubWorkflowCheck failing when adjusting githubWorkflowScalaVersions

For some odd reason, if you remove a scala version to be tested by CI using githubWorkflowScalaVersions, specifically in my case
// Scala 2.10.7 seems to be causing issues with CI
ThisBuild / githubWorkflowScalaVersions -= "2.10.7"

and I commit this to a PR, githubWorkflowCheck ends up failing (specifically in the ci.yml spot where you have strategy.matrix.scala
You can find an example of this happening here https://github.com/iheartradio/ficus/pull/155, you can check the Continuous Integration / Build and Test (ubuntu-latest, 2.13.6<EMAIL_ADDRESS>(pull_request) build failure in that PR.

My guess is that something isn't using this setting when it really should have been! Will add a test and fix.

I wasn't able to reproduce this. However I was able to identify the issue in the PR you linked. I believe if you apply the fix I suggested, your build should work again. Tldr sbt changes scalaVersion all the time, and so you should be careful about what you derive from it. crossScalaVersions is particularly bad because it creates a cycle, which has weird consequences.


PHPCSFixer unaligns code

For configuration or updating questions please read the README and UPGRADE documentation,
or visit: https://gitter.im/PHP-CS-Fixer
When reporting an issue (bug) please provide the following information:
The PHP version you are using ($ php -v):
=> 7.4.1 (cli)
PHP CS Fixer version you are using ($ php-cs-fixer -V):
=> PHP CS Fixer 2.16.1 Yellow Bird
The command you use to run PHP CS Fixer:
=> :php-cs-fixer fix --config=$HOME/.config/.php_cs %
The configuration file you are using, if any:
<?php
// vim: ft=php

$finder = PhpCsFixer\Finder::create()
	->exclude('vendor')
	->ignoreUnreadableDirs()
	->notPath('src/Symfony/Component/Translation/Tests/fixtures/resources.php')
	->in(__DIR__)
;

return PhpCsFixer\Config::create()
	->setRules([
		'@PSR2'           => true,
		'@PHP70Migration' => true,
		// '@PhpCsFixer'       => true,
		// 'strict_param'      => true,
		'align_multiline_comment' => ['comment_type' => 'phpdocs_like'],
		'array_syntax'            => ['syntax' => 'short'],
		'array_indentation'       => true,
		'binary_operator_spaces'  => [
			// 'align_double_arrow' => true,
			// 'align_equals'       => true,
			'default' => 'align_single_space',
		],
		'blank_line_before_statement' => [
			'statements' => [
				'declare',
				'do',
				'while',
				'for',
				'foreach',
				'goto',
				'return',
				'switch',
				'case',
				'default',
				'throw',
				'try',
			],
		],
		'braces' => [
			'allow_single_line_closure' => true,
		],
		'combine_consecutive_issets' => true,
		'combine_consecutive_unsets' => true,
		// 'combine_nested_dirname' => true, // "risky"
		'concat_space'      => ['spacing' => 'one'],
		'constant_case'     => ['case'    => 'lower'],
		// 'ereg_to_preg'      => true,
		'final_class'                                 => false,
		'full_opening_tag'							                     => true,
		'heredoc_to_nowdoc'                           => true,
		'is_null'                                     => false,
		'linebreak_after_opening_tag'                 => false,
		'method_argument_space'                       => [
			'after_heredoc'                    => true,
			'keep_multiple_spaces_after_comma' => true,
		],
		'multiline_whitespace_before_semicolons'      => ['strategy' => 'new_line_for_chained_calls'],
		'native_function_casing'                      => true,
		'new_with_braces'                             => true,
		'no_break_comment'                            => true,
		'no_empty_comment'                            => true,
		'no_multiline_whitespace_around_double_arrow' => false,
		'no_short_bool_cast'                          => true,
		'no_singleline_whitespace_before_semicolons'  => true,
		'no_spaces_around_offset'                     => true,
		'no_trailing_whitespace'                      => true,
		'no_trailing_whitespace_in_comment'           => true,
		'no_unneeded_control_parentheses'             => true,
		'no_unneeded_curly_braces'                    => true,
		'no_unused_imports'                           => true,
		'no_useless_else'                             => true,
		'no_useless_return'                           => true,
		'no_whitespace_in_blank_line'                 => true,
		'normalize_index_brace'                       => true,
		'ordered_imports'                             => [
			'sort_algorithm' => 'length',
		],
		'phpdoc_align'                       => true,
		'phpdoc_indent'                      => true,
		'phpdoc_order'                       => true,
		'phpdoc_scalar'                      => true,
		'short_scalar_cast'                  => true,
		'single_blank_line_at_eof'           => true,
		'single_class_element_per_statement' => false,
		'single_import_per_statement'        => false,
		'single_quote'                       => true,
		'ternary_operator_spaces'            => true,
		'ternary_to_null_coalescing'         => true,
		'unary_operator_spaces'              => true,
		'whitespace_after_comma_in_array'    => true,
		'yoda_style'                         => null,   // NULL: do not change
	])
	->setIndent("\t")
	->setFinder($finder)
;

If applicable, please provide minimum samples of PHP code (as plain text, not screenshots):

before running PHP CS Fixer (no changes):

define('CONST_1',   1);
define('CONST_TWO', 2);

$varOne    = ($cond === 'one')    ? 1  : null;
$varFive   = ($cond === 'five')   ? 5  : null;
$varEleven = ($cond === 'eleven') ? 11 : null;

with unexpected changes applied when running PHP CS Fixer:

define('CONST_1', 1);
define('CONST_TWO', 2);

$varOne    = ($cond === 'one') ? 1 : null;
$varFive   = ($cond === 'five') ? 5 : null;
$varEleven = ($cond === 'eleven') ? 11 : null;

with the changes you expected instead:

// leave the alignments as is:
define('CONST_1',   1);
define('CONST_TWO', 2);

$varOne    = ($cond === 'one')    ? 1  : null;
$varFive   = ($cond === 'five')   ? 5  : null;
$varEleven = ($cond === 'eleven') ? 11 : null;

I know many people don't care about this kind of readability tips, but it is kind of frustrating. :-)
Is there any way to avoid this behaviour?
Thanks for the project, BTW.

Hi @mlopezgva ,
This is done by the rule ternary_operator_spaces;
$ php php-cs-fixer describe ternary_operator_spaces
Description of ternary_operator_spaces rule.
Standardize spaces around ternary operator.

Fixing examples:
 * Example #1.
   ---------- begin diff ----------
   --- Original
   +++ New
   @@ -1,1 +1,1 @@
   -<?php $a = $a   ?1 :0;
   +<?php $a = $a ? 1 : 0;

   ----------- end diff -----------

if you disable this rule though your configuration the un-aligning should no longer be done

closing as answered, but feel free to keep talking here :)

OK, does it interfere also with the comma alignment (the defines)?

Im not sure what you referring to, but the ternary_operator_spaces rule only touches spacing around the ternary operator, not define statements. Maybe you can give an example of what you want to know?

The first "paragraph" of the example.
define('CONST_1',   1);
define('CONST_TWO', 2);

ah I see now! That is done by the method_argument_space rule. Since we no option to align arguments within define call, you can either disable that rule as well or ignore it.

Thank you! I'll try; however, I thought this was the way to avoid the problem:
//...
		'method_argument_space'                       => [
			'after_heredoc'                    => true,
			'keep_multiple_spaces_after_comma' => true,
		],
//...

using 'keep_multiple_spaces_after_comma' => true, here works fine for me, does it remove the spacing after the comma for you?

Yes, it keeps removing the extra spaces.
However, I've got the trick:
		'method_argument_space'                       => [
			'after_heredoc'                    => true,
			'ensure_fully_multiline'           => true,
			'keep_multiple_spaces_after_comma' => true,
		],

I need to add the ensure_fully_multiline to true, and it works. Seems to me like a little bug, don't you think?

Great you found a solution!
Agreed it sounds odd to me as the multiline option shouldn't effect the results.
You are running it on;
<?php
define('CONST_1',   1);
define('CONST_TWO', 2);

?

Well, this is just an example. Another one would be:
$a = [
	"test",   "testing",  "alignment",
	"prueba", "probando", "alineación"
];

But it is working, now. Thank you for your help.


Using Sentinel Log Analytics Workspace

Please provide some guidance about what we should do if we send this data to the Log analytics workspace that is being used by Microsoft Sentinel.  Will we need to create/edit analytic rules, workbooks, playbooks or other resources?
THanks

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

ID: 025acd7e-54e5-5de7-d41f-8af02a835f40
Version Independent ID: 3352d1ac-9e15-c7eb-6cdc-ba0f8ca80475
Content: How to use enriched Microsoft 365 logs
Content Source: articles/global-secure-access/how-to-view-enriched-logs.md
Service: network-access
GitHub Login: @shlipsey3
Microsoft Alias: sarahlipsey

@DeanGross
I've delegated this to @shlipsey3 , a content author, to review and share their valuable insights.


Fix PR template typo

What does this PR (Pull Request) do?
Fixes PR Template "If this is a bug fix, what versions of Traffic Ops are affected?" to "Traffic Control"

[x] This PR is not related to any other Issue

No tests, no code.
No documentation, no code interface change.
No changelog, no code change.
Which Traffic Control components are affected by this PR?

Documentation

What is the best way to verify this PR?
Verify text looks correct.
If this is a bug fix, what versions of Traffic Ops are affected?
Not a code bug fix.
The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4026/
Test PASSed.


ListView inside TabView does not always update on iOS

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 5.3.3
Cross-platform modules: 5.3.2
Android Runtime: 5.3.1
iOS Runtime: 5.3.1
NativeScript-Angular: 7.2.4
Angular: 7.2.15

Describe the bug
Intermittently a ListView will not update when the backing array is changed/updated.

Only appears to occur on iOS
Seems to only happen when in a TabView with multiple tabs
Occurs intermittently.
Occurs infrequently in my emulator tests, but occurs quite often on my device test (iPhone 6 ios 12.2).

To Reproduce
I've setup the list to load after a 1s delay

tns run ios
if list appears (after 1s) tap any item
tap the button labelled "back"
repeat from 2 until the list doesn't display

Expected behavior
List should always display
Sample project
https://github.com/daveware-nv/test-ns-ios-listview

Hi @daveware-nv,
Thank you for the provided sample project, I was able to recreate the problem and will mark it as a bug. For now, I would suggest keeping track of the issue for further info.

It appears this is more serious than I thought. It is not just list-view's that are broken in the tab-views, some other components also seem to stop working at the same time.
I've added a branch linkBroken that demonstrates this, it adds a button labelled "go" that always links to item 1. It also stops working at the same time as the list fails to update.


Docs: add kafka connect configuration

Could you also add en doc for kafka-connetor in this file:
https://github.com/juicedata/juicefs/blob/main/docs/en/deployment/hadoop_java_sdk.md

@DeanThompson never mind, we will add English docs later.

@tangyoupeng @davies Thanks for the merging. I was a little busy these days and missed the comments.


wingetcreate update / wingetcreate update -i Installer version problem

Brief description of your issue
wingetcreate fails to identify installer new version and replaces only hash in old version manifests.
Steps to reproduce
wingetcreate update WHONET.2023
New version number is 23.13.8 but wingetcreate updated installer hash in old version 23.12.14 manifest.

Expected behavior
It should detect new version number from installer and detect that package is using vanity url.
So it should replace old version with new version manifest.
Actual behavior
PS C:\Users\drsht> wingetcreate update WHONET.2023
Retrieving latest manifest for WHONET.2023
Downloading and parsing: https://whonet.org/WHONET2023-Setup-x86.exe...
Downloading and parsing: https://whonet.org/WHONET2023-Setup-x64.exe...

The architecture detected from the binary might be different than what is specified in the installer URL for the following installer(s):
Using architecture detected from URL (X64), overriding architecture detected from binary (X86)
https://whonet.org/WHONET2023-Setup-x64.exe

Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
DefaultLocale: en-US
ManifestType: version
ManifestVersion: 1.5.0

Installer manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
InstallerType: burn
Installers:
- Architecture: x86
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x86.exe
  InstallerSha256: AA35364ABEE7B1229533E781173733AEE628D1293557C8688F4225F56958BCBA
- Architecture: x64
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x64.exe
  InstallerSha256: 0B8C70A5B148C476A83A505C74D18EA9A7C7F34F3BAE108CBB9FC1725248A9F6
ManifestType: installer
ManifestVersion: 1.5.0

Default locale manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
PackageLocale: en-US
Publisher: Brigham and Women's Hospital
PublisherUrl: https://whonet.org
PublisherSupportUrl: https://whonet.org/contact.html
Author: Brigham and Women's Hospital
PackageName: WHONET 2023
PackageUrl: https://whonet.org/software.html
License: Freeware
Copyright: Copyright (c) Brigham and Women's Hospital. All rights reserved.
ShortDescription: WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance.
Description: |-
  WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance developed and supported by the WHO Collaborating Centre for Surveillance of Antimicrobial Resistance at the Brigham and Women's Hospital in Boston, Massachusetts.
  WHONET, available in 44 languages, supports local, national, regional, and global surveillance efforts in over 2,300 hospital, public health, animal health, and food laboratories in over 130 countries worldwide.
  WHONET 2023 is a modernized and expanded version of WHONET 5.6. This version supports 44 languages and includes new features for exporting to the WHO GLASS data structure.
  It includes support for CLSI 2023 M100, M45, M60, M61, as well as EUCAST 2023 bacterial breakpoints. Also included are the most recent CLSI VET01, VET03/04, and VET06 breakpoints.
Moniker: WHONET
Tags:
- Microbiology
- Laboratory
- Bacteriology
- BacLink
- AMR
- Antibiotics
- Resistance
- CLSI
- EUCAST
- WHO
- GLASS
ManifestType: defaultLocale
ManifestVersion: 1.5.0

Manifest saved to %USERPROFILE%\manifests\w\WHONET\2023\23.12.14

Manifest validation succeeded: True

wingetcreate update WHONET.2023 -i
Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
DefaultLocale: en-US
ManifestType: version
ManifestVersion: 1.5.0

Installer manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
InstallerType: burn
Installers:
- Architecture: x86
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x86.exe
  InstallerSha256: AA35364ABEE7B1229533E781173733AEE628D1293557C8688F4225F56958BCBA
- Architecture: x64
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x64.exe
  InstallerSha256: 0B8C70A5B148C476A83A505C74D18EA9A7C7F34F3BAE108CBB9FC1725248A9F6
ManifestType: installer
ManifestVersion: 1.5.0

Default locale manifest preview:
# Created using wingetcreate <IP_ADDRESS>
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
PackageLocale: en-US
Publisher: Brigham and Women's Hospital
PublisherUrl: https://whonet.org
PublisherSupportUrl: https://whonet.org/contact.html
Author: Brigham and Women's Hospital
PackageName: WHONET 2023
PackageUrl: https://whonet.org/software.html
License: Freeware
Copyright: Copyright (c) Brigham and Women's Hospital. All rights reserved.
ShortDescription: WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance.
Description: |-
  WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance developed and supported by the WHO Collaborating Centre for Surveillance of Antimicrobial Resistance at the Brigham and Women's Hospital in Boston, Massachusetts.
  WHONET, available in 44 languages, supports local, national, regional, and global surveillance efforts in over 2,300 hospital, public health, animal health, and food laboratories in over 130 countries worldwide.
  WHONET 2023 is a modernized and expanded version of WHONET 5.6. This version supports 44 languages and includes new features for exporting to the WHO GLASS data structure.
  It includes support for CLSI 2023 M100, M45, M60, M61, as well as EUCAST 2023 bacterial breakpoints. Also included are the most recent CLSI VET01, VET03/04, and VET06 breakpoints.
Moniker: WHONET
Tags:
- Microbiology
- Laboratory
- Bacteriology
- BacLink
- AMR
- Antibiotics
- Resistance
- CLSI
- EUCAST
- WHO
- GLASS
ReleaseNotesUrl: https://whonet.org/WHONET-ReleaseNotes.html
ManifestType: defaultLocale
ManifestVersion: 1.5.0

Manifest saved to %USERPROFILE%\manifests\w\WHONET\2023\23.12.14

Manifest validation succeeded: True

Environment
PS C:\Users\drsht> wingetcreate --help
Windows Package Manager Manifest Creator v<IP_ADDRESS>

PS C:\Users\drsht> winget --info
Windows Package Manager v1.6.3482
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.2861
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3482.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Enabled
LocalArchiveMalwareScanOverride           Disabled

I think we can detect the "correct" version from the installer file with high confidence only if it's an MSI or an MSIX. The example you showed is an .exe, which can have all sorts of different behaviors depending on how the installer is made. One way for .exe is to look at the FileVersion / ProductVersion file property (that @wingetbot uses in its automation). The problem with that approach is that not all publishers set this value and even if they do, it does not match the actual version written to Registry / Apps&Features, resulting in a lot of false matches.
If wingetcreate auto-fills a version for a user, I think it should be the one that's the actual DisplayVersion written to Registry, and for that I think the implementation should first target MSIX and MSIs, and then optionally see if something can be done for .exe's.
The wingetcreate new command already fetches the version for MSIX's, so as a first step, we can look to replicate that behavior for the update command

wingetcreate update already downloads and parses the installer, so why can't it check for the same like wingetcreate new.
Using -i with command should show a similar flow with version number suggested which is detected from installer.
In my example, the package has correct display version in registry/app&features with each new version.

I think we can detect the "correct" version from the installer file with high confidence only if it's an MSI or an MSIX. The example you showed is an .exe, which can have all sorts of different behaviors depending on how the installer is made. One way for .exe is to look at the FileVersion / ProductVersion file property (that @wingetbot uses in its automation). The problem with that approach is that not all publishers set this value and even if they do, it does not match the actual version written to Registry / Apps&Features, resulting in a lot of false matches.
If wingetcreate auto-fills a version for a user, I think it should be the one that's the actual DisplayVersion written to Registry, and for that I think the implementation should first target MSIX and MSIs, and then optionally see if something can be done for .exe's.
The wingetcreate new command already fetches the version for MSIX's, so as a first step, we can look to replicate that behavior for the update command

As you can see here in screenshot, product version property is correctly set for .exe


CI: clone ROMs repo with deploy key

Coverage remained the same at 69.406% when pulling 4de56c69699d50110ff3bed351a52edfc1da2151 on ci-deploy-key into d87fecb96e94217d5046d2282118274c291544ea on master.


'Cannot read property 'id' of undefined' error when trying to debug a web part using MSGraphClient in the hosted workbench

Category

[ ] Question
[ ] Typo
[x] Bug
[ ] Additional article idea

Expected or Desired Behavior
Be able to debug web part using MSGraphClient in the hosted workbench while serving from the local web server.
Observed Behavior
After adding the web part to the page, you get the following error in the console:
sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283 Uncaught (in promise) TypeError: Cannot read property 'id' of undefined
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at sp-client-preview.js:94
    at e._processPendingCallbacks (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at PersonalCalendarWebPart.render (PersonalCalendarWebPart.ts:33)
    at t (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569)
    at PersonalCalendarWebPart.t._renderWithAccessibleTitle (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569)
    at sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569

Tenant is running on the 2018-04-20.015 release of SPFx.
Steps to Reproduce

scaffold new project using generator v1.4.1 with a React web part
to the render method add:

const graphClient = this.context.serviceScope.consume(MSGraphClient.serviceKey);
graphClient.api('me').version('v1.0').get();

run gulp serve --nobrowser
in the hosted workbench, add the web part to the canvas
in the console you get the aforementioned error

I'am experiencing the same behavior, when running gulp serve --nobrowser the graphclient does not get initialized.
When deploying the app, the MSGraphClient works as expected.

Same here

@waldekmastykarz Any news on this? My team experiencing the same behavior. Will it fixed?
Can we create a MSGraphClient in another way as a workaround?

Same here. Tenants I tried on:

DEV tenant with Targeted Release
'Normal' tenant with Targeted Release

@Maksim-Ilyenia have you tried the following?

run gulp bundle and gulp package-solution but don't use the --ship flag so that the generated package will point to your local files
deploy the generated package to the app catalog
run gulp serve --nobrowser to start the local web server
add the web part to the workbench

@mmsharepoint When you still encounter an error using the steps above add the webpart to a new modern-page (ignoring the remote workbench). This worked for me.

Thanks for your answer @RobinBreman
But I already knew the steps and they are working for me as well but the original issue and question was who else faces the error when working with the workbench.aspx without deploying the app
One of the main disadvantages of the mentioned workaround is:
Your colleagues cannot work with an already deployed Version of your Webpart as long as you need to debug it

Thanks @waldekmastykarz your solution works fine.

A short update on this with version 1.5.0:
I updated an existing solution from 1.4.1 to 1.5.0 by follwoing the standard approach
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/update-latest-packages
and additionally had to use Chris O' Breins nuclear approach:
http://www.sharepointnutsandbolts.com/2018/05/Update-SPFx-version.html
Now the debugging seems to work with the workbench on server-side ("/_layouts/15/workbench.aspx) although I received some timeout issues at first on renewing the token ...("Token renewal operation failed due to timeout")

Based on the message from @mmsharepoint, we should be fine with this starting from 1.5. If that's not the case, let's re-open.

I upgraded to 1.5.0 and followed the examples from below:
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aad-tutorial
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/call-microsoft-graph-using-graphhttpclient
I receive an error on importing AadHttpClient:
import { GraphHttpClient, HttpClientResponse, IGraphHttpClientOptions } from '';
Giving error: "c:/_/hellograph-webpart/node_modules//dist/index-internal"' has no exported member 'GraphHttpClient'.


Add qiskit-research

What is the expected enhancement?
Add https://github.com/qiskit-research/qiskit-research to ecosystem

This "submodule" kind of testing might have some overlap with the pytket-extensions model.

Closed in #220


Outputting currently resolved artifact to console

This is a simple aesthetic change. It would be nice if generate_workspace could output what artifact it is currently resolving. For example:
INFO: Running command line: //generate_workspace '--maven_project=/helloworld' '--artifact=org.powermock:powermock-module-junit4:1.5.1' '--artifact=org.powermock:powermock-api-mockito:1.5.1'
    ...
    Resolving model org.powermock powermock-module-junit4 1.5.1
    Resolving model org.powermock powermock-modules 1.5.1
    Resolving model org.powermock powermock 1.5.1
    Resolving model org.sonatype.oss oss-parent 5
    Resolving model junit junit 4.11
    Resolving model org.hamcrest hamcrest-core 1.3
    Resolving model org.hamcrest hamcrest-parent 1.3
    Resolving model org.powermock powermock-module-junit4-common 1.5.1
    Resolving model org.powermock powermock-modules 1.5.1
    Resolving model org.powermock powermock 1.5.1
    Resolving model org.sonatype.oss oss-parent 5

@kchodorow, how would you like it to output the currently resolved artifact? In addition, when there are duplicates, do you want it to skip over those duplicates?

@kchodorow, how would you like it to output the currently resolved artifact?

I think it only needs to print the artifact identifier it's currently downloading.  Downloading is the only thing that should take any time.

In addition, when there are duplicates, do you want it to skip over those duplicates?

If you only print when downloads happen, duplicates shouldn't be an issue.
Also, as a personal preference: I'd rather see the artifact in Maven coordinate form (group:artifact:version) and it would be nice to include who requested it, if it's not too gnarly.

That should not be problem. Thanks for the clarification.


Models dropdown shows azure:openaieven if no models have been configured

I have pulled the latest commit and re-deployed the chatbot on an existing installation.
Now I am getting

at the top of my models list.

Fixed


chore(deps): update aws-sdk dependency to 2.1358.0

Thanks 👌 I updated the commit message to trigger a release. I'll merge it in after CI has finished 🏁


comparison with phil nash's hamts?

Hi,
They published Phil Nash's HAMT talk from cppcon yesterday on youtube. His talk notes page has a link to immer, so I'm guessing you talked :) My question is how immer's HAMTs compare to phil's, broadly. I saw from the talk there are a few optimisations he's missing (some of which he even mentions), but is there anywhere his HAMT has the edge over immer's? if so, let's steal ideas!

They published Phil Nash's HAMT talk from cppcon yesterday on
youtube. His talk notes page has a link to immer, so I'm guessing you
talked :) My question is how immer's HAMTs compare to phil's,
broadly. I saw from the talk there are a few optimisations he's
missing (some of which he even mentions), but is there anywhere his
HAMT has the edge over immer's? if so, let's steal ideas!

Nice!  Phil does a great job in his presentations---I did attend his HAMT
session at CppNow which was very eloquent and clear.  We had also a chat
about the topic at CppCon.
As he mentioned, I do implement an optimization (the CHAMP variation of
the HAMT structure) which stores the values at one level of the tree in
a contiguous block, enabling less indirection, more cache locallity, and
also has less branching during iteration---at the cost of one extra bitmap
lookup step during search, but the other advantages compensate.  With
CHAMP also inequeal trees can always be found in log time, even if the
do not share structure.  CHAMP stores one extra bitmap, but on 64 bit
architectures it does not add extra memory usage (it is packed in the
same word with the other bitmap).
I keep following Phil's work.  Neither of us has implemented transients
yet... [1] if he gets to it before me I am sure his implementation will be
again a good source of insight and inspiration.
There were links to benchmarks and papers in the CHAMP pull request
here: https://github.com/arximboldi/immer/pull/19
[1] I am busy with work and... preparing a mini-Redux-for-C++ library to
show at MeetingCpp... I know, the clock is freacking ticking!
--
∿∿∿  https://sinusoid.al
∿∿∿  https://sinusoid.es

Brilliant, thanks for the summary. And I'd love a link to your redux lib when you're done :)

@jjl I just realized when reviewing the issues: here is the Redux lib https://github.com/arximboldi/lager and here is a talk about it: https://www.youtube.com/watch?v=NMol_5-2owo


fix: require  to puppeteer-core as fallback

Summary
This is because sometimes we prefer puppeteer-core as a dependency instead of puppeteer.

Thanks!

Awesome, I was about to propose something similar to avoid aliasing puppeteer as follows:
"puppeteer"<EMAIL_ADDRESS>

The 4.4.0 is without this change. When it will be published?

The 4.4.0 is without this change. When it will be published?


To remove the italic effect from a text on Playground page

Current Behavior
The text "Meshery Playground" is written in italics just before the accordion of information. It breaks the consistency of the design of the text which was followed since start of the page and looks off the wall

Desired Behavior
The desired behavior should consist of the text to be as consistent as all the piece of texts which is to be non-italic which will look more formal and give the boost of consistency to the page.

Implementation
To approach this issue I will search for the part  of code where the text is formatted to be italic and will rectify the code.

Contributor Guides and Handbook

🛠 Meshery Build & Release Strategy
📚 Instructions for contributing to documentation

Meshery documentation site and source

🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@Aviral0702 Can I take this issue if you're not available.

Sorry for the inconvenience . Just added sign to the commits in the second PR.

@Sulochan-khadka Could everyone please avoid creating pull requests until officially assigned to an issue? Your cooperation is greatly appreciated!

Hey @ayushrakesh can you assign this to me! I can fix this.

Folks, the italic text is intentional and aid in offsetting one section from the next.


runtimeArtifact warning

Perhaps this will be covered by #1043 but currently defining a <runtimeArtifact> gives the following warning for me:
Invalid plugin configuration: runtimeArtifact

Should this be the case?

@Joseph-Cass this is in Eclipse I assume?   Not sure the liberty-maven-plugin can do anything about this but maybe just for the record, what version of Eclipse and m2e (I assume that's what you're using)  are you running with?
I did stumble on this issue..wonder if it's related:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=563035

@Joseph-Cass In the 3.0 release runtimeArtifact replaced assemblyArtifact. Either you are hitting the bug that Scott mentioned above, or Eclipse does not recognize the new name for that configuration parameter.

Yes, this is in Eclipse. My Eclipse version is:
Eclipse IDE for Java Developers (includes Incubating components)
Version: 2020-12 (4.18.0)

My Apache Maven version is:
Josephs-MBP:api josephcass$ mvn --version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T20:00:29+01:00)
Maven home: /usr/local/Cellar/maven/3.6.1/libexec
Java version: 13.0.2, vendor: AdoptOpenJDK, runtime: /Library/Java/JavaVirtualMachines/adoptopenjdk-13-openj9.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

I did notice that the attached "doc" that Eclipse generates for <assemblyArtifact> is the same as it is for <runtimeArtifact>:
required: false
type: org.codehaus.mojo.pluginsupport.util.ArtifactItem
expression: ${runtimeArtifact}

Maven coordinates of a server assembly. This is best listed as
 a dependency, in which case the version can be omitted.

Yet the warning doesn't show for <assemblyArtifact>. Not sure if that's useful info?
Thanks!

Not sure if this is still an issue, but if it is we don't plan on fixing it.


Add TypeScript definition file

Hello @jossmac,
Great job on the library.  The toast notifications are the most beautiful looking ones I've seen.
Are there any plans to add a TypeScript definition file?

Hi @rscotten,
Thanks for the kind words! I don't use TypeScript but would be happy to check out a PR 🙂
Cheers

@rscotten closing due to inactivity. Please comment if you'd like it reopened.

This would be highly recommended if you want users using Typescript to use the library. Thanks in advance for any effort on this topic

I just ran into this error. I would also love to be able to use this in our project.

I threw together a poor man's ts def just to move ahead.
declare module 'react-toast-notifications' {
  export const ReactToast: any
  export const DefaultToastContainer: any
  export const DefaultToast: any
  export const ToastConsumer: any
  export const ToastProvider: any
  export function withToastManager(...args: any): any;
  export function useToasts(...args: any): any
}

Maybe it helps someone:
declare module 'react-toast-notifications' {
  import { ReactNode, ComponentType } from 'react';

  export type AppearanceTypes = 'error' | 'info' | 'success' | 'warning';

  export type Placement =
    | 'bottom-left'
    | 'bottom-center'
    | 'bottom-right'
    | 'top-left'
    | 'top-center'
    | 'top-right';

  export type TransitionState = 'entering' | 'entered' | 'exiting' | 'exited';

  export type ToastProps = {
    appearance: AppearanceTypes;
    autoDismiss: boolean | number;
    autoDismissTimeout: number; // inherited from ToastProvider
    children: ReactNode;
    isRunning: boolean;
    onDismiss: (id?: string) => void;
    onMouseEnter: () => void;
    onMouseLeave: () => void;
    placement: Placement;
    transitionDuration: number; // inherited from ToastProvider
    transitionState: TransitionState; // inherited from ToastProvider
  };

  export type ToastContainerProps = {
    children: ReactNode;
    hasToasts: boolean;
    placement: Placement;
  };

  export type ToastProviderProps = {
    autoDismissTimeout?: number;
    children: ReactNode;
    components?: {
      ToastContainer?: ComponentType<ToastContainerProps>;
      Toast?: ComponentType<ToastProps>;
    };
    placement?: Placement;
    transitionDuration?: number;
  };

  export type Options = {
    appearance: AppearanceTypes;
    autoDismiss?: boolean;
    onDismiss?: (id: string) => void;
    pauseOnHover?: boolean;
  };

  export type AddToast = (
    content: ReactNode,
    options?: Options,
    callback?: (id: string) => void
  ) => void;

  export type RemoveToast = (id: string, callback: () => void) => void;

  export const DefaultToastContainer: ComponentType<ToastContainerProps>;
  export const DefaultToast: ComponentType<ToastProps>;
  export const ToastConsumer: any;
  export const ToastProvider: ComponentType<ToastProviderProps>;
  export function withToastManager(...args: any): any;
  export function useToasts(): {
    addToast: AddToast;
    removeToast: RemoveToast;
    toastStack: Array<{
      content: ReactNode;
      id: string;
      appearance: AppearanceTypes;
    }>;
  };
}

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/40194

I would like to suggest following type declarations for HOC: withToastManager()
export interface ToastManagerProp {
  toastManager: ToastConsumerContext;
};

export function withToastManager<OwnProps extends ToastManagerProp>(
  Component: ComponentType<OwnProps>
): ComponentType<Omit<OwnProps, 'toastManager'>>;


distinguish portSecurity with security group

Pull Request

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Bug fixes

same as https://github.com/kubeovn/kube-ovn/pull/3862

Which issue(s) this PR fixes
Fixes #(issue-number)

SetPortSecurity

目前认为这个命令即是为空

@zhangzujian hi, please help review, thanks!