az monitor log-analytics is not supported in az cli 2.0.48

when running az monitor log-analytics --help I have the following error:  "az monitor: 'log-analytics' is not in the 'az monitor' command group. See 'az monitor --help'."

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

ID: f0fd6a58-ac1a-fa45-8d96-579b4af36499
Version Independent ID: 4098ca97-1b85-eb29-18e9-e6f0495fd030
Content: az monitor log-analytics
Content Source: latest/docs-ref-autogen/ext/log-analytics/monitor/log-analytics.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

Closing, I did not have the extension installed.


feat: ae supports canceling

Summary
Make ae plugin supports canceling, both collector and converter.
Key Points

[ ] This is a breaking change
[ ] New or existing documentation is updated

Description
The idea is simple:

make ae api client supports cancel (maybe we could move this feature to api client once for all ), so before /after each request, task can be canceled right away
add cancel checking in the begining of each loop, so conversion task can be canceled.

From @klesh
Hi, @Jonathan ODonnell  @Kevin Kline , I won't have much time to coding on  canceling feature recently, would you guys help me on it, I have put up a sample PR https://github.com/merico-dev/lake/pull/956
The idea is simple:
the work_scheduler already support canceling, but not every task utilizing work_scheduler
make ae api client supports canceling (maybe we could move this feature to api client once for all), so before/after each request, task can be canceled right away, even for collectors that didn't utilize the work_scheduer but just api client.
add cancel checking in the begining of each loop for converter, so conversion task can be canceled.
What needs to be done:
make sure all plugins implement the idea above
make sure all returned canceling error is the exact instance of core.TaskCanceled, this is for TASK_CANCELED status in database on next step, using same instance is the most reliable way for error checking.
channel and context.Conext is very important for our system in the long term, make sure you understand how they work.
@Julien Chinapen maybe we could add a canceling button for  Triggers page before pipeline run is ready.

@klesh we can work on this for sure but we are in the middle of the DB schema changes and migrations. @Startrekzky Please assign this ticket a priority label

you can work on db schema migration first.


Adoption of JSpecify annotations in Guava

(We'd spoken a while back about filing issues in the JSpecify tracker for some tasks that other projects would take but that have interdependencies worth tracking here. Here's one such issue.)
Currently, Guava is annotated with a combination of jsr305 annotations (both jsr305's built-in nullness annotations and Guava's custom "nicknames" built on jsr305) and Checker Framework annotations. For the most part, tools don't care too much which nullness annotations a project uses, but there's at least one big exception, which is Kotlin.
The annotations we've chosen have the advantage of mostly producing errors in Kotlin by default: Both the built-in jsr305 nullness annotations and the CF annotations do. The caveats are:

Our CF annotations appear only in "type-use-only" locations and thus currently have no effect until users set -Xtype-enhancement-improvements-strict-mode.
Our custom "nicknames" currently produce only warnings until users set -Xjsr305=strict.

With JSpecify annotations currently producing only warnings for Kotlin users, the ideal first step (as soon as the JSpecify annotations are "stable enough" that we're comfortable) would be to add @NullMarked to our annotated classes while leaving the existing annotations in place. This would let users who opt in to -Xjspecify-annotations=strict (and additionally opt in to -Xtype-enhancement-improvements-strict-mode) see Guava as almost completely annotated. Aside from that, it may be a no-op for Kotlin users (I'd have to think more to confirm that), though it may help users of other tools by then.
Later, once JSpecify annotations produce errors by default in a Kotlin release (and that release is out for long enough that we're comfortable relying on it), we could remove the other annotations. In particular, we could remove one kind of jsr305 nickname that forces Kotlin users to still see platform types, even if they've set all the applicable flags.

(We think we can do this without needing a GWT module: We already strip @Nullable annotations from our GWT sources, and we should strip @NullMarked annotations (per this comment that refers to its predecessor @ElementTypesAreNonnullByDefault) for as long as we strip @Nullable (thereby sidestepping any problem that might exist for the @Target({MODULE, ...}) line in NullMarked).)

I should note that Guava's transitional @ParametricNullness annotations (which we'd hope to be able to avoid someday, since they'd be technically redundant after we're fully on JSpecify annotations) have been getting used by various tools, so we may want to keep them around longer. See this discussion with the NullAway folks and this comment in the annotation's source, for starters.
I know I've done at least one other experiment that relied on @ParametricNullness. That resulted in https://github.com/google/error-prone/commit/941974e5c658ef0164e90367cacee137112b787b. Now, Error Prone doesn't rely on the annotation on an ongoing basis. But it's worth noting that @ParametricNullness remains at least periodically handy, especially until we can deal with JDK-8225377.

A user inside Google just noticed that IntelliJ's support for JSpecify annotations turned on by default recently. The user reports some resulting false positives in some generics-heavy code. That's expected, and the question is just how widespread such false positives will be. We'll keep an eye out for more reports, and we can use those reports as input for the decision about which annotations to use in Guava when.

In https://github.com/jspecify/jspecify/issues/24#issuecomment-1509090335, I mention another reason to stick with declaration annotations for now: Type-use annotations on arrays don't trigger errors, only warnings. (That is the case even for people who set the flags to otherwise promote nullness warnings to errors.)
That may well be fixed before we'd even be considering migrating fully from declaration to type-use annotations, anyway.

Good: The following works fine with -Xjspecify-annotations=strict, regardless of whether I also pass -Xtype-enhancement-improvements-strict-mode:
val f: Function<Any?, String> = constant("")

Interestingly, if I change Any? to Any (and continue to pass -Xjspecify-annotations=strict, I get a failure not only with -Xtype-enhancement-improvements-strict-mode (good) but also without (probably also good, just not sure if I would have expected it).

Note also that Guava recently started using @NonNull in a few places. We'd want to wait for Kotlin support for the JSpecify @NonNull before switching to JSpecify.

ascopes reports problems when building Javadoc against JSpecify, at least under certain settings: https://github.com/maxcellent/javadoc.io/issues/182
I'd need to read more to understand whether there is anything we can fix on the JSpecify side. At first glance, I get the impression that Guava (and other motivated consumers) could work around it with -linkoffline, which Guava already uses.

It's looking like IntelliJ always treats JSpecify annotations as producing warnings only, even if we add -Xjspecify-annotations=strict to the Kotlin compiler flags in its settings. We should see if that changes immediately when -Xjspecify-annotations=strict becomes the default (probably?) or if it requires a subsequent IntelliJ release.

https://stackoverflow.com/q/77915170/28465 suggests that Guava's current nullness annotations (perhaps specifically its usages of @CheckForNull) are not recognized by Eclipse, at least by default.
My suspicion, though, is that most nullness annotations are not by Eclipse by default. The thing I'd have to look into is whether Eclipse nowadays lets you specify multiple annotations to treat like @Nullable. Apparently, many years ago, you could pick only one: 1, 2. I must have seen what the UI was when I experimented a few years back, but I don't remember offhand. It's possible that the answer exists somewhere in https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm.
If Eclipse still supports only one annotation, then the main takeaway is that switching to JSpecify may improve things for Eclipse users: At least then, we'll consistently use the same annotation for the same thing (instead of mixing @Nullable and @CheckForNull). And of course the goal is that ultimately more tools recognize JSpecify annotations by default.

Oops, I should have waited until I clicked that final link on the Eclipse site... :)

The compiler supports exactly one primary set of annotation types for null specification. Additionally, an arbitrary number of secondary annotation types can be configured to carry the same semantics. Secondary annotation types are supported for the sole purpose of interfacing with 3rd party code that is already specified using other null annotations than the primary annotations types of the current project.

So multiple annotations are supported nowadays.

My impression from the recent activity on KT-59138 (and some quick testing) is that Kotlin 2.0 is going to start treating types like SettableFuture<String?> mostly the same as it currently treats SettableFuture<String>, at least until we're able to use the JSpecify annotations on them and rely on Kotlin to recognize those.
For example, today, code like this produces an error:
fun go(f: ListenableFuture<String?>): String = f.get()

Ditto for this slightly more complex code:
fun go(m: Multimap<String, String?>, s: String): String = m.get(s).iterator().next()

But with K2, neither of those will be an error anymore.
Granted, K2 still produces an error for this similar code, perhaps from magic in its handling of Collection?
fun go(m: Multiset<String?>): String = m.iterator().next()

So I don't know how widespread the impact of the change would be for Guava types.
I'm also not sure how much we can do about it until we're ready to use exclusively JSpecify annotations: Even though it's possible that we're at the point that we could use @NullMarked as a supplement to our existing nullness annotations, my fear is that its "warnings-mode" behavior would override (rather than supplement/enhance) the behavior of our JSR-305 defaulting annotations—which, admittedly, is also warnings-mode but which perhaps more users have upgraded to error-mode? Additionally, I think our @ParametricNullness annotations would undo much of the effect at the moment (though perhaps not all, like maybe helping in my Multimap example??). (In fact, I suspect that they're already preventing users from getting errors like the ones above in some cases.)

This is a minor thing (and not specific to Guava), but:
I get the impression that type-use annotations show up in the Summary section of rendered Javadoc but that declaration annotations do not. See, e.g., Equivalence, which shows onResultOf(Function<? super F,? extends @Nullable T> function) but doEquivalent(T a, T b) (rather than doEquivalent(@CheckForNull T a, @CheckForNull T b) or eventually doEquivalent(@Nullable T a, @Nullable T b)).
The theory would be that seeing the nullness annotations in the summary is superior to having to look for them in the details, but in fairness, they can be noisy (worsened by https://github.com/google/guava/issues/6790). Admittedly the mix of sometimes showing them and sometimes not showing them may be the worst of both worlds.

A few things (about Kotlin unless otherwise noted) that I researched/tested today (most of which I was aware of but some of which might have been new):

@CheckForNull and the Checker Framework @Nullable produce errors by default when used on return types; the JSpecify @Nullable, only warnings for now.
There seems to be only one default "in effect" at a time: If we have @ParametersAreNonnullByDefault on the package and @NullMarked on the class, then Kotlin produces only warnings for null arguments passes for non-null parameters, even with -Xjsr305=strict, unless of course we set -Xjsr305=strict.
@ParametersAreNonnullByDefault has an effect only with -Xjsr305=strict, as of course do our custom @ElementTypesAreNonnullByDefault annotations.
J2ObjC still doesn't recognize @NullMarked by default, but that likely matters only internally and perhaps doesn't matter a ton to begin with. (I think that J2ObjC will still recognize a package-level @ParametersAreNonnullByDefault even if there's a class-level @NullMarked, at least if J2ObjC isn't configured to recognize @NullMarked, but I didn't confirm this.)
The Checker Framework checker-qual release does include a module-info at this point.
I released a version of Truth with JSpecify annotations last week. We've been using it internally for a while, but this is another chance to shake out any problems in the outside world.

I'll try to synthesize that into a proposed plan, maybe as soon as later today.

Here's my 4-phase proposal for comment by @netdpb and others. I've written it mostly from the perspective of users of Kotlin, since Kotlin has the most complete JSpecify/nullness support of tools in common use.
We could implement Phase 1 and Phase 2 today, or we could wait until JSpecify 1.0.0 or some other time of our choosing.
Phase 1: Replace @*AreNonnullByDefault with @NullMarked
This lets Kotlin produce warnings for code like ImmutableList<String?>. Those warnings may identify runtime problems, and they're a helpful transitional state on the way to when Kotlin upgrades the findings to errors. (Users can upgrade to errors today with -Xjspecify-annotations=strict.)
Risks:

Users see warnings (or even errors in rare cases) that they might not want to deal with right now. (To spread that change across time, we could in theory adopt @NullMarked package-by-package or even class-by-class. But my guess is that it's better to start slowing the bleeding for all of Guava now.)
Users "need" a new dependency. (In practice, they can often get by without it—but not always. See also #294.)
Users who already set -Xjsr305=strict no longer see errors in some of the cases they were used to, only warnings. (The solution to that is for anyone who already sets -Xjsr305=strict to also set -Xjspecify-annotations=strict, which is unlikely to affect many existing libraries other than Guava.)

Phase 2: Remove JSR-305 magic from @ParametricNullness
This lets Kotlin produce warnings for code like Futures.immediateFuture<String>(null). That's good and bad in the same ways as in Phase 1.
This can't happen before Phase 1 because @ParametricNullness undoes the unwanted part of the effects of @*NonnullByDefault. It could happen as part of the same release as Phase 1, but I'd probably instead publish 2 separate releases on the same day so that users can choose between picking up the changes incrementally and picking them both up at once.
Phase 3: Replace JSR-305 @CheckForNull with Checker Framework @Nullable
This is the final step to removing our JSR-305 dependency (which, among other things, is one of the blockers to making Guava a module).
This can't happen until after a bug fix in Kotlin 2.0.20 is adopted widely enough. (Realistically, we probably could do it sooner, since I don't think we have many APIs that return nullable arrays.)
Phase 4: Replace Checker Framework @Nullable with JSpecify @Nullable
This is the final step to using a single set of nullness annotations that provides all the information needed by Kotlin without need for compiler plugins.
This can't happen until enough Kotlin users adopt a future Kotlin release (2.1.0?) in which JSpecify annotations produce errors by default, as Checker Framework annotations do already.

https://github.com/google/truth/issues/1320 points out that a usage of @NullMarked can lead to the warnings about MODULE that we've discussed in https://github.com/jspecify/jspecify/issues/302, https://github.com/jspecify/jspecify/issues/537, and elsewhere. That's one downside to adopting @NullMarked in Guava. It won't ultimately stop us, but it at least means that I want to pause to think (and maybe decide to wait longer).

As discussed in https://github.com/google/truth/issues/1320#issuecomment-2224038542, we may want to put Guava's @NullMarked annotations to be at the package level instead of the class level: That should be enough to avoid the warnings I mentioned above for users who set --release 8 and use a version of Error Prone that is at least 2.22.0 but less than 2.29.0.
We'd then want to opt out (with @NullUnmarked) any classes that we haven't annotated, but I think that's only package-private classes at the moment. (There are exceptions to that for Google-internal classes, though, so we may need to annotate them or else wait until we're on a new enough version of Kotlin to recognize @NullUnmarked.) Hmm, it would also include many of our tests, but that's mostly academic except in IntelliJ and maybe some future Error Prone checks or something. Oh, and it would affect any Java users of Kotlin code in the package (though I'm not sure we have any Kotlin APIs that are meant from use from Java currently), and of course Kotlin code doesn't include @Nullable everywhere that we'd want. We could still put @NullUnmarked anywhere that we turn out to need it (again, at least once Kotlin recognizes it... and probably our Error Prone checks, too...).
I'm on the fence about this.

Kotlin 2.1.0 was released this past Wednesday, including the expected change to JSpecify diagnostic severity. We'll likely still make our Guava changes in a series of releases to ease the migration path, and we'll likely still hold the final change until users have time to adopt Kotlin 2.1.0. But now it should all be just a matter of time :)


Buffered output on timeout is not sent back

There is an inconsistent behavior with output from piston, there is two way a program can be killed:

it prints too much stuff
its takes too much time

In the first case (OK), the output is truncated to some limit around 65k bytes.
In the second case (KO) we have too flush stdout for it to show up in the output.
example for the first case:
print('Some message')
while True:
    print('I will be truncated')

response from piston (I replaced a big chunk in the middle of output and stdout with [...] because it the limit is high):
{
  "ran": true,
  "language": "python3",
  "version": "3.8.2",
  "output": "Some message\nI will be truncated\nI will be truncated\n[...]I will be truncated\nI will be truncated\nI ",
  "stdout": "Some message\nI will be truncated\nI will be truncated\n[...]I will be truncated\nI will be truncated\nI ",
  "stderr": "Killed"
}

A second example that doesn't also timeout
print("a"*2**17) # the limit is at 2**16 chars

{
  "ran": true,
  "language": "python3",
  "version": "3.8.2",
  "output": "aaaaaaaaaaaaaaaaaaaaaaaa[...]aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "stdout": "aaaaaaaaaaaaaaaaaaaaaaaa[...]aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "stderr": ""
}

example for the second case:
import time
print('Some message', flush=True)
print('An other message')
time.sleep(10)

response from piston:
{
  "ran": true,
  "language": "python3",
  "version": "3.8.2",
  "output": "Some message\nKilled",
  "stdout": "Some message",
  "stderr": "Killed"
}

It's fixed ?

v3 should have fixed it, please reopen if it isn't


replace glob with rglob #283

PR for fix #283.
Replace Path(some_path).glob('**/*') with Path(some_path).rglob('*/*').
Act same as original code, and it can also find files from symlink.

Thanks for sending this PR. Shouldn't the update be

Thanks for sending this PR. The doc mentions

This is like calling Path.glob() with “**/” added in front of the given relative pattern

So shouldn't the update be
- paths += list(Path(root).glob('**/'+g))
+ paths += list(Path(root).rglob(g))

instead of
- paths += list(Path(root).glob('**/'+g))
+ paths += list(Path(root).rglob('*/'+g))

?

Thanks for reviewing!
I've tested with several scenarios, and I think current update is more suitable for handling various scenarios involving symlinks.

Case 1: When dataset path is a symlink, and mapping path and query path are regular directories.
Case 2: When dataset path is a regular directory, and mapping path and query path are symlinks.
Case 3: When dataset path, mapping path, and query path are all symlinks.

In these cases, paths += list(Path(root).rglob('*/'+g)) worked well for all three cases, but paths += list(Path(root).rglob(g)) only worked for case 1 and failed for Cases 2 and 3. I think it's because when rglob traversal, if a child directory is a symlink, it does not explore within that symlink directory.
So, I believe current approach is more appropriate.

Path(root).rglob('*/'+g) only handles symlinks at the top level, unlike glob.glob which handles arbitrary levels. This is exactly what the cpython issue says. Let's instead use glob, as:
paths += glob.glob((Path(root) / '**' / g).as_posix()), recursive=True)

Can you please confirms that it works and make the changes? Thanks!

You're right, glob.glob looks better. I changed it to glob, but it returns list with str, not pathlib.PosixPath. So I convert it to PosixPath like this:
paths += list(map(Path, glob.glob((Path(root) / '**' / g).as_posix(), recursive=True)))

And it works all good. Thanks!


fix: revert to using service.targetPort with fallbacks

Fixes #358
The logic here is to bring back a null-able service.targetPort that is an override (if not nil) to the listenPort defined in console.config.server.listenPort which will default to 8080 if not in turn is not found.

test is needed.


Error on sending message to Facebook status Forbidden

I have been managing a bot for a couple months now, and I recently ran into an issue where Facebook is having intermittent issues connecting with the Bot Connector.  While in dialog with Facebook, we're seeing that at random, some messages get through to the Facebook chat client while others return as 500s.  This ranges from sending a generic typing message to responses generated from a FormFlow dialog.
The exception raised:
System.UnauthorizedAccessException: Authorization for Microsoft App ID 4b6154c8-3228-4403-8999-dc7ae63c7d5c failed with status code Forbidden
   at Microsoft.Bot.Connector.JwtTokenRefresher.<SendAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.Bot.Connector.Conversations.<ReplyToActivityWithHttpMessagesAsync>d__7.MoveNext()

Our slack channel is still functioning as expected.
I did a run through of #1105 which included:

Checking my App Credentials
Checking the BotAuthentication annotation
Checking the trusted service url
Use Bot Framework portal to test connection

My current project setup is:

C#
Bot Builder SDK 3.2.1
Channels: Slack and Facebook

One of our calls that generate this error:
			Activity reply = activity.CreateReply();
			reply.Type = ActivityTypes.Typing;
			reply.Text = null;
			await connector.Conversations.ReplyToActivityAsync(reply);

Confirm problem with Facebook.

it's the same for me as well

i can reproduce the same issues with EchoBot from the sample project of BotBuilder, some messages get through but some messages return 500 with UnauthorizedAccessException. Is there any workaround for now? as it's just stop the bot working.

Having the same issue as wiltodelta

I'm seeing this on Node.js as well, some messages go through and some are 403. After testing it on Facebook and Skype, only the Facebook channel has the problem.

@wiltodelta there's an open issue #1254
Please comment something there to show Microsoft's team that's a general problem.

Hi folks, we're looking into it. Thanks

Verifying on my side that I think this issue has been resolved along with #1254 and #1257.
Thank you for the quick response!


Update project to use Gradle 8.7

Updates Gradle from 8.1 to 8.7 so jdk 21 can be used to develop
I've left the buildship version as is so some tests will fail unless JDK 17 or lower is used to run them.  Can this also be changed or is it set to 7.4.2 for a reason...
https://github.com/microsoft/build-server-for-gradle/blob/ec53a53b8b2b66cad5303e09474010b39d9303ff/server/src/main/java/com/microsoft/java/bs/core/internal/gradle/Utils.java#L45

They are some stale(invalid) checks. I'll raise a PR to remove them.

Removed in https://github.com/microsoft/build-server-for-gradle/pull/137

I've left the buildship version as is so some tests will fail unless JDK 17 or lower is used to run them.

Which tests?

Which tests?

testJavaCompilerArgsToolchain failed for me but I think that's because I was switching between jdk-17 and jdk-21.  All work now.

Thank you @Arthurm1 for your contribution!


Dataset information not shown when cloning a model

When creating a new model and selecting a dataset:

When cloning a model:

If you only have one dataset, I don't see a way of having the information displayed.
If you have multiple datasets in the list, click on any other dataset, then back on the one you want.

While we're at this, maybe tackle some of the other minor cloning issues, of which a few have been fixed last week.
Problem: different label upon cloning
Steps:
(1) Make a model job, name it "test"
(2) Change the label name, name it "test renamed"
(3) Click clone
(4) The actual cloned name will be "test", not "test renamed".

You mean #710? :)

Thanks for the bug report @flx42
This should be fixed in #713


add: added supabase folder

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Can't merge as https://github.com/supabase-community/supabase-kubernetes has apache 2.0 licence


Storefront hangs loading after upload attempt

Hello,
Issue Impact: Minor
Device Manufacturer: Samsung
Device Model: S10
Device OS: Android
Device OS Version: 11
Application Version: apk: v0.98.24
Storefront version 1.0.3
What Happened?: I used the + to see what happens when trying to import something to the storefront. I selected a minidapp I previously downloaded (I didn't really expect it to import as I don't think this is what the + function is for).
It appeared to be loading but nothing imported, then I clicked on the + again but Return to the storefront without selecting anything and the storefront hangs on the loading page. I have to close the storefront and reopen for it to work again.
What Did You Expect To Happen?: Storefront would return to normal functionality
Steps to recreate:
1.Click the + from storefront
2. Select a file (appears to load but doesn't import - ok)
3. Click the + again
4. Click back without selecting anything
5. Storefront hangs on loading screen
https://user-images.githubusercontent.com/60537663/122181909-afc5a200-ce81-11eb-9ee6-22017fd95837.mp4
Question: what type of files can be uploaded with this + function? Is this specified somewhere?
Thanks,
Jazmin

To answer the question - the + sign is for loading new (decentralised) stores.
Meanwhile - thanks for the detailed description - I'll drop in a fix in due course...


Removed unsupported or undesirable credentials

Fixes #1805 by removing unused flows (we'll use the remaining flows internally) and fixes #1806 by removing support for azureauth.

As a seperate work item, I'd prefer we get rid of the SpecificAzureCredential and instead use the ChainedTokenCredential.

We have a meeting about that today. I could write up SpecificAzureCredential as an example - even use it in examples - but I still think showing DefaultAzureCredential in examples is counterproductive when we don't want people to use it. We know people copy and paste our samples, which is why many of us spent so much time making sure they are compiled and executed as tests - especially in toolchains like dotnet that didn't natively support such a thing.
While we may not want people to actually use a SpecificAzureCredential - since it seems we shouldn't even define one - it seems pretty clear that we want people to effectively write that themselves in code e.g.,
let credential = if is_dev_environment() {
  DefaultAzureCredential
} else {
  ManagedIdentityCredential
}

/cc @christothes @scottaddie

I still think showing DefaultAzureCredential in examples is counterproductive when we don't want people to use it.

I don't think this is necessarily true. It's still the best for getting started and samples can't really be nuanced enough to provide more specific guidance outside the context of the Identity readme and API docs.

I don't think this is necessarily true. It's still the best for getting started and samples can't really be nuanced enough to provide more specific guidance outside the context of the Identity readme and API docs.

Agreeing with @christothes here. Cross SDK languages we are working to replace samples that don't use DefaultAzureCred with ones that do. This has been the guidance from the Identity SDK V team for helping customers get started in an easy and secure way.


build cra-go: cannot load cra-go/webfiles: cannot find module providing package cra-go/webfiles

From following "getting started":
$ git clone https://github.com/ImVexed/muon.git
$ cd muon/examples/create-react-app/
$ cd public/
$ yarn
$ yarn build
$ cd ..
$ go generate
go: finding github.com/ImVexed/muon v0.0.0-20191009145610-caeea31ca3eb
go: finding golang.org/x/net v0.0.0-20190930134127-c5a3c61f89f3
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/text v0.3.0
go: downloading github.com/ImVexed/muon v0.0.0-20191009145610-caeea31ca3eb
go: extracting github.com/ImVexed/muon v0.0.0-20191009145610-caeea31ca3eb
main.go:1: running "fileb0x": exec: "fileb0x": executable file not found in $PATH
$ go build
build cra-go: cannot load cra-go/webfiles: cannot find module providing package cra-go/webfiles

You have to install fileb0x to use it.
Try go get github.com/UnnoTed/fileb0x and ensure it's in your $PATH

@ImVexed You should update getting-started.md then.

"or" makes fileb0x optional.

Under the hood go generate just executes: https://github.com/ImVexed/muon/blob/master/examples/create-react-app/main.go#L1
But I do agree it's non obvious until you hit the error, I'll modify the instructions.

@ImVexed
now:
$ go generate
go: finding github.com/ImVexed/muon/examples latest
can't load package: package github.com/ImVexed/muon/examples: unknown import path "github.com/ImVexed/muon/examples": cannot find module providing package github.com/ImVexed/muon/examples

I'm trying to run the same program in some other location, I almost everything same as we have to do in the muon/examples/create-react-app/. But still it's giving me this error when I run "go build" :
main.go:5:2: package cra-go/webfiles is not in GOROOT (C:\Program Files\Go\src\cra-go\webfiles)

I got error too.
M:\work\code\go\src\github.com\ImVexed\muon\examples\create-react-app>fileb0x M:/work/code/go/src/github.com/ImVexed/muon/examples/create-react-app/b0x.yml
%v map[]
panic: No files found
goroutine 1 [running]:
main.main()
M:/work/code/go/src/github.com/UnnoTed/fileb0x/main.go:102 +0x2653


Example to gradle project

My old project is using Dagger "1".
We need to understand existing usage in order to migration to Dagger "2".
This change will help us understand Dagger.
Thanks.

This project is not accepting contributions anymore. Your build system usage should not affect your usage of the library, however.


Confusion regarding the indexing of data labels!!!!!

for any train data item, in your 'data_loader.py' ,the code is :
        s_begin = index
        s_end = s_begin + self.seq_len
        r_begin = s_end - self.label_len
        r_end = r_begin + self.label_len + self.pred_len

        seq_x = self.data_x[s_begin:s_end]
        seq_y = self.data_y[r_begin:r_begin + self.label_len]
        seq_x_mark = self.data_stamp[s_begin:s_end]
        seq_y_mark = self.data_stamp[r_begin:r_end]

why the 'seq_y' is end with 'r_begin + self.label_len'? rather than ' s_begin + self.seq_len+self.pred_len '

the data begin from 'r_begin ' and end with 'r_begin + self.label_len' are all located in the history sequence.
I fell puzzled for this.
the same code in Autoformer is 'seq_y = self.data_y[r_begin:r_end]'
Is this an error or is it supposed to be like this?
I am looking forward to your response.
best wishes

This code is from class Dataset_Pred(Dataset):, where no ground truth value is available. Therefore the seq_y is not used, and the value of it has no meaning.  The other class Dataset_ is 'seq_y = self.data_y[r_begin:r_end]', same as Autoformer.


Alignment of lines

There are problems in alignment of lines, see the follow demo file.
Demo
alignment of lines.zip
Screenshot

Thanks Hao for this. Yes I had thought there were still some minor bugs in the layout code. This is something that will be shortly fixed with the new cubicalisation code for layout.

@calintat @doctorn We already have cubicalisation for 2d diagrams right? So we could already replace the 2d layout code to use this.

Good idea! I've had some ideas about how to merge the 2, 3 & 4D pipelines so hopefully we can replace all of the old SVG code soon.

OK that sounds interesting. However in the short term all I was proposing is to change the layout code; i.e. the code that decides at what coordinates to display particular entities. That is, I'm not proposing in the short term we remove the SVG code.

This is fixed by the new layout algorithm.


DB Migration not possible when selecting BlazeGraph

Issue description
DB migration fails on fresh node when selecting BlazeGraph
Expected behavior
OT-Node software to be installed with BlazeGraph
Actual behavior
Running DB migrations: FAILED
There was an error running the db migrations.
npm ERR! could not determine executable to run npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2022-04-08T17_43_50_472Z-debug-0.log

Steps to reproduce the problem

Fresh node
Edit installer to install latest NPM. Run installer
Select BlazeGraph

Specifications

Node version: latest
Platform: Ubuntu 20.04 LTS
Node wallet: 0x09D88eAbD226f94c14d89DFAad63221E3438d9Df

0 verbose cli /usr/bin/node /usr/lib/node_modules/npm/bin/npm-cli.js
1 info using<EMAIL_ADDRESS>2 info using<EMAIL_ADDRESS>3 timing npm:load:whichnode Completed in 1ms
4 timing config:load:defaults Completed in 2ms
5 timing config:load:file:/usr/lib/node_modules/npm/npmrc Completed in 0ms
6 timing config:load:builtin Completed in 0ms
7 timing config:load:cli Completed in 1ms
8 timing config:load:env Completed in 1ms
9 timing config:load:file:/root/ot-node/.npmrc Completed in 0ms
10 timing config:load:project Completed in 1ms
11 timing config:load:file:/root/.npmrc Completed in 0ms
12 timing config:load:user Completed in 0ms
13 timing config:load:file:/usr/etc/npmrc Completed in 1ms
14 timing config:load:global Completed in 1ms
15 timing config:load:validate Completed in 0ms
16 timing config:load:credentials Completed in 1ms
17 timing config:load:setEnvs Completed in 1ms
18 timing config:load Completed in 9ms
19 timing npm:load:configload Completed in 9ms
20 timing npm:load:mkdirpcache Completed in 10ms
21 timing npm:load:mkdirplogs Completed in 0ms
22 verbose title npm exec sequelize --config=./config/sequelizeConfig.js db:migrate
23 verbose argv "exec" "--" "sequelize" "--config=./config/sequelizeConfig.js" "db:migrate"
24 timing npm:load:setTitle Completed in 1ms
25 timing config:load:flatten Completed in 3ms
26 timing npm:load:display Completed in 4ms
27 verbose logfile logs-max:10 dir:/root/.npm/_logs
28 verbose logfile /root/.npm/_logs/2022-04-08T17_23_30_195Z-debug-0.log
29 timing npm:load:logFile Completed in 4ms
30 timing npm:load:timers Completed in 0ms
31 timing npm:load:configScope Completed in 0ms
32 timing npm:load Completed in 32ms
33 silly logfile start cleaning logs, removing 1 files
34 silly logfile done cleaning log files
35 http fetch GET 200 https://registry.npmjs.org/sequelize 94ms (cache revalidated)
36 timing command:exec Completed in 116ms
37 verbose stack Error: could not determine executable to run
37 verbose stack     at getBinFromManifest (/usr/lib/node_modules/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js:17:23)
37 verbose stack     at exec (/usr/lib/node_modules/npm/node_modules/libnpmexec/lib/index.js:114:15)
37 verbose stack     at async module.exports (/usr/lib/node_modules/npm/lib/cli.js:78:5)
38 verbose pkgid<EMAIL_ADDRESS>39 verbose cwd /root/ot-node
40 verbose Linux 5.4.0-105-generic
41 verbose node v16.14.2
42 verbose npm  v8.6.0
43 error could not determine executable to run
44 verbose exit 1
45 timing npm Completed in 196ms
46 verbose code 1
47 error A complete log of this run can be found in:
47 error     /root/.npm/_logs/2022-04-08T17_23_30_195Z-debug-0.log

note: this happens when installing latest npm version in the installer. without latest version installer will crash.

this can be fixed by removing ganache from package.json before running installer

This was fixed with #1920


Update test case TestDropWritesDuringBench to stop bbolt before resuming the failpoint

After applying the patch in this PR, then no reproduction anymore on the data corruption issue as mentioned in https://github.com/etcd-io/bbolt/issues/568#issuecomment-1817468463
The key problem is that the system call syscall.Fdatasync's semantics is not respected. If the data sync is successful, then it returns no error; otherwise it should return an error. It looks like the data sync actually fails (because data are dropped by the filesystem), but the system call is still returning no error. It leads to a situation that some data are actually lost but the meta page of the last TXNs are persisted successfully.  But will this happen in a real filesystem?
successful, ..., successful, failed, ..., failed, successfully, ..., successful

In this patch, I intentionally kills the bbolt before resuming/removing the failpoint, to ensure that there is no any successful data syncing anymore after the failures.
successful, ..., successful, failed,......, failed

Note that if you remove the second commit, then you can't reproduce the issue anymore.
The second commit is just to show you that the failure should be caused by the test case (filesystem) instead of bbolt.


lose RAMS dataset file?

Hi.
I tried to follow the code on dataset RAMS.And I changed the argument called 'test-file' in convert_gen_to_output.py to 'data/RAMS_1.0/data/test.jsonlines' when evaluating head score but only received low performance as follow:
Precision: 33.5640 Recall: 36.2133 F1: 34.8384.
I did't find the file called 'test_head_coref.jsonlines' and 'test_head.jsonlines'. Are they include in RAMS or created by yourself?
It puzzled me. Did I downloaded wrong version? My version: RAMS_1.0c.tar.gz [current as of March 2023, 4.5MB].
Thanks for reply.

The two files are processed by us. See the end of the README.md for instructions on how to download these files. Note that only Span F1 (should be the original exact match score) and Head F1 (match of head words) are reported in our paper.
We reported these metrics to match a previous paper "A two-step approach for implicit event argument detection.", not the original RAMS paper because the evaluation setting was different.

Thank you very much for your answer！


Storage replication to a second provider

Measures

Has all existing content been replicated to a second provider?

Is new content replicated to a second provider during ingest?

Link to feature: https://wellcomecollection.productboard.com/feature-board/planning/features/4912368

🎉 🎉 🎉


About the SxTAM() and CxTAM() function

Thanks for your inspiring work.
I find that you construct the Cross-task Attention module in ours_xatt.py. It seems that this module is composed of SxTAM and CxTAM. In the SxTAM module, the cross-attention between x and y is computed. But there is no self-attn or sigmoid function in the SxTAM class (from the xTAM module of the paper) and I can not find the CxTAM function in your code base.
**{f'CxTAM_{s}': CxTAM() if self.use_CxTAM else nn.Identity() for s in others(t)},

Hi, thank you for your interest in our work.
The channel attention block was only used for ablations but we opted for the spatial attention block in our final version.
The self-attention and sigmoid functions (in Fig. 2 purple) are applied by the self-attention block, SABlock.
Hope this clarifies your concerns!


ValueError: Cannot set tensor: Got value of type INT64 but expected type FLOAT32 for input 0, name: images

I get ValueError If the model.dtype is different from any of the inputs dtype. I think it happens because of this line, which assumes that the model.dtype is equal to the inputs dtype:
https://github.com/beasteers/tflit/blob/f766db6a38253b3967daba258f50b04519dc5f53/tflit/core.py#L58

Ah that's a good catch thank you! You're right, we should be doing something like:
    def predict_batch(self, X, multi_input=None, multi_output=None, add_batch=False):
        '''Predict a single batch.'''
        # set inputs
        X = self._check_inputs(X, multi_input)
        input_dtypes = self.input_dtypes
        for i, idx in self._input_idxs:
            x = np.asarray(X[i], dtype=input_dtypes[i])

that's actually a general bug with self.dtype because it's not a predictable order since it's using a set so that should be fixed too while we're at it.
I probably won't have a chance to get to this right away (like not in next few days), but if you're eager, and feel like doing a PR that's cool too!

So I pushed up that change plus some other things that had been sitting in the repo.
Another reason could be that your model is expecting floats (which is commonly the case) but you're providing ints, so in that case, you'd do x.astype(np.float32) to your numpy array before passing it to the model.

Thank you @beasteers. It worked!


Have Subsections not show the "in progress" banner

Ref https://github.com/StampyAI/stampy-ui/issues/560
See for instance this question that is a subsection in Coda
https://aisafety.info/questions/NLZV

This is relevant because in some cases we link to subsections directly, e.g.
https://aisafety.info/questions/NM1D/Careers
is linked from
https://aisafety.info/questions/8TJV/How-can-I-help

@Aprillion Nemo says he won't be able to take this in the near term, suggested you might want to take it.

If I won't find unexpected free time between work stuff, I can have a look on Sunday...


Show file progress as a diagnostic while it occurs.

Helps make sure someone using e.g. vim.diagnostic.goto_next
notices that the file isn't ready yet.
Closes: https://github.com/Julian/lean.nvim/issues/252

(The tests seem a bit flaky again locally, will investigate, but pinging the both of you in case you have an opinion on how well this works for you.)

LGTM as well, thank you! Yeah the tests in general need some work (I've been busy reading lately but will get back to #250 soon).


Loc Automation - json update on handback for Branch: jsonUpdater

Loc Automation - json update on handback for Branch: jsonUpdater

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

Line 111: [Error] W:\4k0s-s\jobs\100\Pages\Pricing\docfx.json for docset Pricing doesn't exist

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Build Xtensa kernels for Vision P6

This PR currently includes commits from #45619.
Confirmed that all tests pass for vision P6:
make -f tensorflow/lite/micro/tools/make/Makefile TARGET=xtensa OPTIMIZED_KERNEL_DIR=xtensa TARGET_ARCH=vision_p6 XTENSA_CORE=P6_200528 test

Once this PR is merged we can turn on continuous builds for P6.

tagging @pnikam-cad @nyadla-sys @kpraving

I'm going to wait until #45618 and this is rebased. Seems like that will provide a clearer picture of the delta here.

The quantize refactor PR is merged so this PR is ready for review now.

copybara import error occurred. retrying with "kokoro:force-run" and "ready to pull" labels.


Add par_rchunks* for slices

These additions work mostly like par_chunks* in reverse, but aligned against the end of the slice if the length is not a perfect multiple of the chunk size. The Exact variants also have remainder methods matching their forward counterparts.
pub trait ParallelSlice<T> {
    fn par_rchunks(&self, chunk_size: usize) -> RChunks<'_, T>;
    fn par_rchunks_exact(&self, chunk_size: usize) -> RChunksExact<'_, T>;
}

pub trait ParallelSliceMut<T> {
    fn par_rchunks_mut(&mut self, chunk_size: usize) -> RChunksMut<'_, T>;
    fn par_rchunks_exact_mut(&mut self, chunk_size: usize) -> RChunksExactMut<'_, T>;
}

Fixes #734.

I organized the submodules this way so they can easily be compared. I don't know how to get github to diff arbitrary files, but here's an external site diffing chunks.rs vs. rchunks.rs:
https://linediff.com/?id=60a6a8c4687f4bd2118b4567

bors r=nikomatsakis


Helm doesnt create a serviceaccount with a imagepullsecret

Hi,
I'm using the default helm template as basis. I have modified the following files:
values.xml
serviceAccount:
  create: true
  name:
  imagePullSecrets:
  - acr-auth

where acr-auth is a secret using the
 kubectl create secret docker-registry acr-auth --docker-server $ACR_NAME.azurecr.io --docker-username $ACR_NAME --docker-password $ACR_PWD --docker-email<EMAIL_ADDRESS>After that I modified the serviceaccount.yaml inside the /templates directory
{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ template "mychart.serviceAccountName" . }}
  labels:
{{ include "mychart.labels" . | indent 4 }}
  imagePullSecrets:
  {{- range .Values.serviceAccount.imagePullSecrets }}
  - name: {{- . | indent 1}}
  {{- end }}
{{- end -}}

When I --debug and/or --dry-run the install I get the following output
apiVersion: v1
kind: ServiceAccount
metadata:
  name: peddling-lightningbug-mychart
  labels:
    app.kubernetes.io/name: mychart
    helm.sh/chart: mychart-0.1.0
    app.kubernetes.io/instance: peddling-lightningbug
    app.kubernetes.io/version: "1.1"
    app.kubernetes.io/managed-by: Tiller
  imagePullSecrets:
  - name: acr-auth

from what I see the service account pickup the imagePullSecret just fine. However when I install the chart and do a describe serviceaccounts on the created serviceaccount I get the following.
Name:                peddling-lightningbug-mychart
Namespace:           default
Labels:              app.kubernetes.io/instance=peddling-lightningbug
                     app.kubernetes.io/managed-by=Tiller
                     app.kubernetes.io/name=peddling-lightningbug
                     app.kubernetes.io/version=1.1
                     helm.sh/chart=peddling-lightningbug-0.1.0
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   peddling-lightningbug-mychart-token-k9tkj
Tokens:              peddling-lightningbug-mychart-token-k9tkj
Events:              <none>

And because the service account doesn't have the imagepullsecret, it fails to download the image because it's not authorized.
I tested the private registry with a basic kubectl run --image= and a patched default serviceaccount with the acr-auth and the image is downloaded as expected.
Any ideas what I'm missing here?
I'm using
Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}

on microk8s and I have manually added the azurecr.io registry to the /var/snap/microk8s/current/args/containerd-template.toml file and restarted it.

perhaps https://github.com/helm/helm/pull/7355 may be relevant?

I don't know. I have created the secret manually beforehand. All I'm trying to do is connect this manual created secret to the new service account. I think the #7355 issue is when creating the secret during the helm install. Maybe they are connected somehow, indeed. It may make sense, that when first obtaining a token before the service account exists, the token will be invalidated.
Be aware that my kubernetes/helm is very limited at the moment.

From what I gather other projects are basically doing the same here. Like this one:
https://github.com/helm/charts/blob/master/stable/reloader/templates/serviceaccount.yaml

Hi, @morrowyn - Can you let us know if you can reproduce this issue with Helm 3? We are no longer providing support for Helm 2 as of today: https://helm.sh/blog/helm-2-becomes-unsupported/

closing as stale.

@bacongobbler @bridgetkromhout sorry for commenting on an issue y'all just closed, but:
coincidentally, my team is hitting this thanks to dockerhub experimenting with some new rate limiting for image pulls. It appears it is not possible to create a service account with an imagepullsecret in kubernetes. afaict, they can only be added afterwards, hence the workaround linked above.
Even with the workaround, i guess the chart would need to be released twice to patch the serviceaccount. It seems that if helm were to provide a clean solution for this, it would require doing up to two phases of service account release. Also, a template function would probably be required to abstract whatever intermediate representation would be needed for helm to do the right there here (i am assuming without evidence 😅).
is this sort of solution in scope for helm 3? fwiw, i can't think of any other tools that resolve this problem.


Feature/routing

Added a routing source configuration to the appender in order to customize elasticsearch routing

Hi, that looks awesome 👍
Actually I am planning to add an option to add dynamic fields in the indexing process (say next time we will have request for another "routing" field to add, I want it to be manageable through the config).
In addition, I want to convert DocumentId (and the routing) to use SmartFormatter so it won't take it's value from one log field but you could combine two fields by doing {field1}_{field2} and so on.
I am merging this change since my vision may be too far away.
Thanks a lot @erangil2


Setup a react application

Set up linter config
Used the correct gitflow
Create a react app

Hi @fatmahussein
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project, that does not have a descriptive branch name and you currently have linter errors on this pr 👍🏿
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification @prolajumokeoni.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.

Hi @prolajumokeoni
Thank you

Thanks @skyv26


Lint: add eslint rule for linting outputStrings

Sorry, I wrote the wrong glob in eslint configuration file, now it shoild be working.

Is there a way to only highlight the particular output property rather than the entire function?

I understand that this is an error on the "whole trigger", but this is a bit jarring to have a huge error, especially when writing new triggers.  Is there some way to make this less loud? (Maybe only highlight the alertText?) Or maybe "missing output strings entirely" something better left for tests than syntax highlighting?

Is there a way to only highlight the particular output property rather than the entire function?

There is. It is just a bit complecated so I only check the source of whole function at the first time. I can change like that if you prefer.

I understand that this is an error on the "whole trigger", but this is a bit jarring to have a huge error, especially when writing new triggers.  Is there some way to make this less loud? (Maybe only highlight the alertText?) Or maybe "missing output strings entirely" something better left for tests than syntax highlighting?

Sounds good to only highlight the xxxText property.

Is there a way to only highlight the particular output property rather than the entire function?

There is. It is just a bit complecated so I only check the source of whole function at the first time. I can change like that if you prefer.

If it's not too unreasonable, I think that'd be better?  If it's extremely complicated, then even just the alertText vs the entire text of the function would be better.

Is there a way to only highlight the particular output property rather than the entire function?

There is. It is just a bit complecated so I only check the source of whole function at the first time. I can change like that if you prefer.

If it's not too unreasonable, I think that'd be better?  If it's extremely complicated, then even just the alertText vs the entire text of the function would be better.

AFAIK there are 2 ways to implement this, one is to calculate the relative position of the output.prop part, and generate loc for eslint dynamically. Another is complecated but robust, to search for CallExpression or MemberExpression in the current function.

Is there a way to only highlight the particular output property rather than the entire function?

There is. It is just a bit complecated so I only check the source of whole function at the first time. I can change like that if you prefer.

If it's not too unreasonable, I think that'd be better?  If it's extremely complicated, then even just the alertText vs the entire text of the function would be better.

AFAIK there are 2 ways to implement this, one is to calculate the relative position of the output.prop part, and generate loc for eslint dynamically. Another is complecated but robust, to search for CallExpression or MemberExpression in the current function.

I think given that you're already searching for it via a regular expression, searching again to find its position doesn't seem too awkward.  I think if you were going to do the robust search, then I'd probably say finding the errors in the first place should be done that way.  I think either is fine.

I found that ESLint has a getScope() function which helps fetching variables declared in code, I think at least I can change the current code to use this function rather than mentain variables by the rule itself, and increase a little bit of robustness.
Also the "report output properties positions" issue can be done with it, too. I will work on it this evening when I have time.

Now the highlight scope is minified.
Use ESLint's selector syntax, which I am not very familiar with it.
Hope it would apply to all kinds of outputs (except computed indexing)

Thanks! This is great!


ZR300 on Nvidia Jetson TX2 not reporting IMU data

Required Info

Camera Model
ZR300

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 16.04 LTS

Kernel Version (Linux Only)
4.4.15 aarch64

Following these instructions on Jetsonhacks I am able to get the ZR300 to stream all camera images on the Jetson TX2. However, on running cpp-motion-module I don't see the motion callback ever being triggered. Any insights on why this might be?

Hi @cvilas
Just wanted to update that we reproduce this problem and trying to look into it. Please take into account that the ZR300 does not officially support Jetson TX2. We will do our best to understand the problem and offer a work-around.

Thanks very much @dorodnic. I appreciate your time. Of course, I understand that the TX2 is not one of the supported platforms, but it is an important one in my opinion. Especially as Intel's own Joule boards are not supported anymore.

Hello everyone,
I tried ZR300 + Jetson TX1 with the same result - no motion data coming out. I didn't post anything here, since I didn't have enough time to get into more debugging. I see this issue being close, however, unresolved. Is there a chance for a solution in the future?
Thanks,
Seath

i get the same problem,does anybody can give me a suggestion?

hi~so is there anybody already solved this problem !?
i also have this problem and stop right here around a week....
hope someone can share your solution...

Hi, it's been a long time, not sure if I recollect this correctly ...
the issue was with the carrier board of TX2, not supporting usb3.
The manufacturer confessed at the end.
I'll try to reach out to my colleague who suffered this just recently.

@seath49  thamk you!!
i really appreciated that your reply, and also bothering you to reach out your colleague, if there has any new information please let me know !
Thanks again, Expect your update


Added favicon for mobile (Androi, iOS, Windows Phone) and desktop

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://guh.guru:8080/job/guh-webinterface-pull-request/39/
Test PASSed.


Tier Config Request image size correction

HTML, JSON  and image file size fixes for tier config requests

This PR has conflicts and can not be merged. Please fix the merge issues.


Show/Follow Logs Commands Throw JSONPath Parse Error

Attempting to follow or show a pods logs either from the Command Menu or from the Sidebar menu is throwing an exception related to JSON parsing:
Failed to get containers in pod: error: error parsing jsonpath {'NAME\tIMAGE\n'}{range .spec.containers[*]}{.name}{'\t'}{.image}{'\n'}{end}, unrecognized character in action: U+0027 '''

This prevents all attempts to view logs using this extensions tools. Other commands seem to function properly.
I am encountering this when working with namespaced pods as well as in minikube. I am working with a Kubernetes server on version 1.6 in both instances. Is this to old for this tool? In prior releases of this tool showing logs was functioning as expected and I was able to see my pods logs.

I'm running the latest release from the VS Code Extension hub/library/thing. :)

Removing the quotes throws an: error: error parsing jsonpath {NAME\tIMAGE\n}{range, unclosed action
That command running on my console throws the same error as my original post.
I have encountered this error on pods with multiple containers and ones with single containers per pod.
I am able to follow logs from the terminal using kubectl logs -f my-pod-name -c my-pods-container successfully and able to use the kubernetes api to watch using the python, c# and javascript libraries that are available.
This is running on a mac with kubectl client version 1.7

Let me know if you need any other information.

Thanks for the info.  I'll have another crack at a repro.
To be clear, the error isn't in the log retrieval - it's occurring when we try to get the list of containers in the pod, so that we can prompt you if there is more than one.  (And that's why it happens even if there's only one pod, because we don't know that until we've listed out the containers.)

Looks like its an issue with the quotes used. If I switch the use of ' and " to make this:
kubectl get po [MY-POD-NAME] -o jsonpath='{"NAME\tIMAGE\n"}{range .spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'

I get an output of:
NAME        IMAGE
container1       some-image-for-container1:some.version
container2       some-image-for-container2:some.version

I assume that is the expected output from this? ¯\_(ツ)_/¯
I'm using Bash on a Mac (3.2.57(1)-release).

Okay, it looks like the existing quoting is the only form that works on Windows, and the switched quoting is the only form that works on Mac, and both work on Linux!  So we'll keep the existing quoting on Windows, but used the switched quoting elsewhere.  #smdh
Thanks for flagging this.  I don't know why it suddenly changed in the most recent version, but appreciate you taking the time to report it and to track down the problem.  A fix is on the way!


Caveat about Truma update?

@mc0110
I opened the Truma app the first time after a longer while not using it and received a message about an available update. It reads (in German):

INET BOX UPDATE VERFÜGBAR
Bitte laden Sie das Update innerhalb der nächsten 30 Tage auf alle Endgeräte sowie Ihre Truma iNet Box, um die Funktionen Ihres Systems auch weiterhin sicherzustellen.
OK

It reminds of other IoT gadgets that receive vendors' updates that are not always to the best of the customers. Regarding the inetbox2mqtt project, I wonder if the vendor could change the workings of the Truma communication protocol (incl. encryption, maybe?) that could render this nice project useless.
Do you or anybody else knowledgeable of the protocol etc. have a clue if this could happen?
I assume that as long as no iNet box is connected and used, no undesired update can happen. Maybe people who do use the iNet box, might face problems with remote control (sending/receiving SMS), if not updating the software/firmware.
Thanks for sharing your thoughts!

There is no relationship between inetbox-app-updates and the inetbox-simulation


Create FLOGS() macro

Hi!
I created this macro because LOGS() was still storing my strings in SRAM. I originally added it in my own GlobalFunctions.h file (and it works) but not in log4arduino.h itself, so I didn't really test the code there
Goodbye!

Hi @MatiasMFM2001, do I understand right that this is a workaround? Wouldn't it be better to investigate the root cause why the strings are still stored in RAM? Could you please open a bug report and post some details so I can reproduce the problem?
thanks
Jan

@MatiasMFM2001 , thanks for the contribution. Could you also please add a short documentation in the README.md?

@MatiasMFM2001 , thanks for the contribution. Could you also please add a short documentation in the README.md?
Yup! I'll do that in a minute

PS: I received this message days ago

Hi @MatiasMFM2001, do I understand right that this is a workaround? Wouldn't it be better to investigate the root cause why the strings are still stored in RAM? Could you please open a bug report and post some details so I can reproduce the problem?
thanks
Jan

Was it deleted? I can answer your questions later, no problem!

Oof renaming patch-1 closed the PR, sorry!

Yes, the comment was deleted. As I did not change log4arduino for years, it seemed that I just forgot some of the details in the meanwhile ;) nevermind - thanks for the MR

@MatiasMFM2001, reviewing the code, I think just using LOG("hello") has the same effect lik FLOGS("hello") since the printf format string is stored in flash memory.

Yes, the comment was deleted. As I did not change log4arduino for years, it seemed that I just forgot some of the details in the meanwhile ;) nevermind - thanks for the MR

Ohh, I understand.

@MatiasMFM2001, reviewing the code, I think just using LOG("hello") has the same effect lik FLOGS("hello") since the printf format string is stored in flash memory.

That's true, but if you have LOG("Hello %d"), printf() will use that %d and access garbage from Stack
So, you should need to backscape all % characters


LoadReleaseIntegration called too late

Platform:

[ ]  Dart
[x]  Flutter Android or iOS
[ ]  Flutter Web

IDE:

[ ]  VSCode
[x]  IntelliJ/AS
[ ]  XCode
[ ]  Other, which one?

split-debug-info and obfuscate (Flutter Android or iOS) or CanvasKit (Flutter Web):

[ ]  Enabled
[x]  Disabled

Platform installed with:

[x] pub.dev
[ ] GitHub

The version of the SDK (See pubspec.lock):
6.4.0-beta.1

I have the following issue:
When configuring the packageLoader parameter, the LoadReleaseIntegration is executed too late, after the native SDK integration. This results in different versions/release/dist being used on native and Flutter side. Ideally version/release/dist need to be send to the native SDK when it is being initialized.
Steps to reproduce:

Configure SentryFlutter.init(packageLoader: ...) with a custom release

Actual result:

Have two different releases appear in Sentry (one from native and one from Flutter)

Expected result:

They should be the same version

Workaround:

    /// Workaround for https://github.com/getsentry/sentry-dart/issues/776
  options
	..removeIntegration(options.integrations.firstWhere((i) => i is LoadReleaseIntegration))
    ..addIntegrationByIndex(
      3,
      LoadReleaseIntegration(() async {
        final info = await PackageInfo.fromPlatform();
        return PackageInfo(
          appName: info.appName,
          packageName: _package,
          version: info.version,
          buildNumber: info.buildNumber,
          buildSignature: info.buildSignature,
        );
      }),
    )

Thanks for reporting @kuhnroyal , we'll look into it.

@kuhnroyal I'm trying to understand your setup, mind sharing your SDK init code?
packageLoader is internal, it's only to make it testable, you should not change that.
If you want a custom release, use options.release, options.dist.

packageLoader is internal, it's only to make it testable, you should not change that.
If you want a custom release, use options.release, options.dist.

If I want to set a custom release via options.release, options.dist then I would have to run the PackageInfo plugin outside of the Sentry error handling first to get those.
Thee background is that I have multiple app flavors with different package names/ids but I need them to be reported as the same release (package).

@kuhnroyal ok, sounds like a fair use case.
The problem is that, right now, LoadReleaseIntegration calls the MethodChannel and reads the data from PackageInfo, or your own custom packageLoader.
Reading it before initing the Native SDKs -> NativeSdkIntegration means that you're calling the MethodChannel before the Native SDKs are initialized, which means if the MethodChannel throws for some reason, the Native SDKs won't detect it.
I'm not sure that initing it afterward would help.
Sounds like the best deal here is, using a custom runZonedGuarded to init. the Flutter SDK, and read your release from the MethodChannel yourself, set them to options.release and options.dist, at least if it throws, you are able to take care of it.
What do you think? it's a trade-off, but your workaround would cause another problem, as stated, if the packageLoader throws, the Native SDKs won't detect it.

Yea both approaches have the same problem.
Is it possible to update the native SDK (release, dist) after it has been initialized?

Currently not, Maybe after https://github.com/getsentry/sentry-dart/issues/265
So you can initialize the Native SDKs with your own custom release/dist.
I'm not sure if I should close this issue or not, since the root of the problem comes by using the packageLoader which is "internal", also because you have a special setup, I believe most apps wouldn't need it, will keep it open, so people can learn from the discussion.

Just an FYI: The parameter is not marked as internal and for testing purposes you could use the PackageInfo.setMockInitialValues instead

Just an FYI: The parameter is not marked as internal and for testing purposes you could use the PackageInfo.setMockInitialValues instead

You're totally right, I've marked them as internal https://github.com/getsentry/sentry-dart/pull/779
PackageInfo.setMockInitialValues TIL, We'll remove it then in the next major bump most probably.

There is a workaround by initializing the native SDK first and setting the release yourself, see https://github.com/getsentry/sentry-docs/pull/5029. We can close this after releasing 6.6.0.


[search-documents] Nest user-defined fields into a document property

To prevent accidentally shadowing user-defined fields with server metadata, we should modify the following interfaces:
// existing interfaces
export type SearchResult<T> = {
    readonly score: number;
    readonly highlights?: {
        [propertyName: string]: string[];
    };
} & T;

export type SuggestResult<T> = {
    readonly text: string;
} & T;

to instead nest the user defined fields:
// desired interfaces
export type SearchResult<T> = {
    readonly score: number;
    readonly highlights?: {
        [propertyName: string]: string[];
    };
    document: T;
}

export type SuggestResult<T> = {
    readonly text: string;
    document: T;
};

In order to accomplish this in code, we will likely have to create a swagger transform to rewrite the server-metadata to map to names that can't conflict (e.g. underscore prefix, so @search.score becomes _score instead of score) and then writing a conversion function to massage the generated interface into the above public shape.

https://github.com/Azure/azure-sdk-for-js/pull/9655

Code complete


correction, punctuation in reading/livebook > evaluation section

when Evaluated becomes italicized to indicate that a cell has changed since last evaluated, it is also followed by an asterisk
unnecessary comma

Thank you! Great catch!


Foreman ignores $PORT variable, always uses 5000

Has anyone else seen this?  No matter what I put in the .env file for PORT, it always uses port 5000.  When I added a debugging line to my Procfile
blah: echo `env`

It shows that Foreman is setting PORT=5000.  Looks like Foreman has issues for this: https://github.com/ddollar/foreman/issues/167 and https://github.com/ddollar/foreman/issues/583
This can be overridden with foreman start -p 3000.
@dsander, do you think we should standardize on port 5000 in Docker and remove the ineffective defaulting in the Procfile, or have Docker use the -p option, or something?

I noticed it too, but did not investigate yet. Defaulting to port 5000 is not really an option, it would require every docker user to change the docker run command to adapt the new exposed port.
The easiest solution would probably be to change our documentation to include the -p flag.

So Docker is assuming port 5000, I gather?

No, docker is assuming port 3000. If we change that every docker user has to change how they launch the container.

Hmm, then I don't fully understand how it's working inside Docker.  Wouldn't foreman be setting it to 5000 unless we're using the -p option?

This only applied to the huginn image, the single process one does not use foreman at all. We still try to change the Procfile, but that does not work anymore because the regex is outdated. It does not cause issues because the next line exports PORT which will be used by foreman (this works because PORT is a real env variable and not loaded by dotenv-rails after foreman booted).

Jumping in because this could be related to pull request #1082 I initiated. The change in that request pulls from an env variable $PORT, and if that's missing, fills in port 3000, which seems like the desired behavior. The regex in docker init shouldn't be needed anymore if I understand everything correctly since that regex looks to be trying to add support for specifying the port via env variable.
I wouldn't expect changes made to .env to make a difference because as @dsander says, the .env file gets loaded by rails which happens after the call to start the server. If you wanted to use you .env file, then the foreman issue suggests you might be able to use the foreman argument -e .env, but would mean another change to the Procfile.

Foreman should be loading the .env file automatically, that's the origin of .env, I think?  But it ignores the PORT variable in the file.

TIL that I've been needlessly dropping in the dot env gem. Gracias!
On Mon, Feb 15, 2016, 00:08 Andrew Cantino<EMAIL_ADDRESS>wrote:

Foreman should be loading the .env file automatically, that's the origin
of .env, I think? But it ignores the PORT variable in the file.
—
Reply to this email directly or view it on GitHub
https://github.com/cantino/huginn/issues/1291#issuecomment-184045314.

@cantino Aha! I also totally ignored that foreman loads the .env file. So the problem is we do not specify PORT in our .env file? When I add it it seems to work as expected.

Whoops, I guess it is that simple.  Do you see any downsides to #1298?  Will it affect Docker or your deployment guide?


Section Headings Not Always Matched

Currently the syntax only recognizes as valid section headers which don't contain attributes in their contents.
There might also be problems with handling title styles and some other inline constructs (need to provide tests coverage for the details).
Being able to properly detect and scope sub-elements within a section title shouldn't be a problem, we only need to create a dedicated context for headings that includes the required in-line elements contexts.
The problem we might facing (based on similar work with other markup syntaxes) is that Sublime Text can't handle proper indexing of TOC symbols which contain sub-elements. E.g.
== Heading Containing {some-attribute} Within

Chances are that the attribute won't be indexed. The only way to allow its indexing would be to not scope the attribute as entity.name.section.asciidoc, but this will leave a hole in the indexed heading — which, is worth remembering, we wish to index because we want to be able to navigate quickly through the various sections headings via "Goto Symbol".
It would also be nice to execute some transformation on the indexed headings, e.g. convert AsciiDoc straight quotes and backticks to typographic quotes, etc. If there was a way to expand attributes to their values (e.g. via the API) it would be great, but I doubt it.
The most important thing right now would be to ensure that no valid section headings are unmatched due to inline markup in their contents.
Also need to check how the syntax handles heading spanning multiple lines.

More Precisely...
The problem only affects section titles which start with an attribute reference, e.g.:
== {Lorem} Ipsum Dolor

whereas if the attribute appear within the title contents it's simply treated as normal text, and the title is correctly indexed:
== Lorem {Ipsum} Dolor

Attributes Are Now Supported!
Now, thanks to @polyglot-jones's contribution (see 8c99451b48d71376b44ece522c112b0c6653e2e4), the syntax does support attributes references.
From Asciidoctor.sublime-syntax (L412):
  attribute_reference:
    - match: ({)([A-Za-z0-9_][A-Za-z0-9_-]*)(})
      captures:
        1: constant.character.attributes.reference.begin.asciidoc
        2: support.variable.attribute.asciidoc
        3: constant.character.attributes.reference.end.asciidoc

Right now, the headings definition (section_titles) doesn't include attribute_reference in its own context — and probably doing so would break proper indexing of section titles, as mentioned in the original post.
I need to test how inclusion of @polyglot-jones's section_titles works, i.e. if it doesn't break correct title indexing.
Nested Symbols Dilemma
I have stumbled upon the same problem with PML, another lightweight markup syntax similar to AsciiDoc and Markdown (in many respects).
PML also supports "constants" definitions and references, which are very similar to AsciiDoc attributes. The problem here is trying to index both symbols: i.e. having ST track occurrences of constants/attributes references, and also indexing section titles (for quick navigation via Ctrl+R).
While working on the Sublime Text syntax for PML I couldn't find a way to preserve "constants" (very similar to ADoc attributes) and proper title indexing: if I wanted to preserved the attribute as a symbol (i.e. being indexed and listed by ST) I had to accept breaking-up the title indexing, and the only way to preserve the correct section title in the symbols index was to give-up tracking the occurrence of the attribute among the symbols list.
Right now, I don't recall all the details, but I do remember that I did stumble upon some limitations on how ST fails to handle nested indexed-Symbols.
For more details, see tajmone/Sublime-PML#13, which should contain some useful reminders and tips on the problem (although the PML syntax might have changed in the meantime, and no longer be as mentioned in the Issue).
In any case ... it would be a mistake to think that by simply including attribute_reference in section_titles should work flawlessly — we need to check if the presence of the attribute interferes with proper indexing of the section title, and also bear in mind that tracking attributes definitions might be a desirable feature in future.
The idea is that by properly scoping attributes definitions and references, end users can then select an attribute and exploit ST functionality like "Goto Symbol" and "Goto Definition" to quickly navigate through attributes occurrences and their definitions — a feature which is obviously useful, especially in big projects.


[HOPS-1100] BRTrackingService.assignWork in one transaction.

Make sure there is no duplicate PR for this issue

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added and passed (for bug fixes / features)
[x] HOPS JIRA issue has been opened for this PR
[x] All commits have been squashed down to a single commit
[x] The commit message has the following format: [HOPS-XXX] message

Post a link to the associated JIRA issue

https://hopshadoop.atlassian.net/browse/HOPS-1100

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:
Depends on  hopshadoop/hops-metadata-dal#151 and hopshadoop/hops-metadata-dal-impl-ndb#184

tests: https://bbc1.sics.se/jenkins/view/pull-manual/job/hops-pull-manual/56/


Just noting that this added the jill.py rather than the original jill:

@mkitti, we can discuss here

Just noting that this added the original jill rather jill.py:
https://github.com/abelsiqueira/jill
https://github.com/johnnychen94/jill.py

I can add the jillpy option through an output. Are they sufficiently different?
Originally posted by @ngam in https://github.com/conda-forge/staged-recipes/issues/18240#issuecomment-1063107200

We can use the trick of using the same feedstock for two different outputs here like I did here: https://github.com/conda-forge/coreutils-feedstock/pull/23

Jill is written in shell ([ba]sh). Jill.py is written in Python.

Ah, we have the "improved" one. I think we can make do with jillpy then? Maybe I should rename it?

Both are actively maintained. I suspect jill.py has greater utility to someone running Windows though. As far as I can understand, there is not a dependency between the two. jill.py is a complete rewrite.

Just to be clear, we have jill.py here, not jill

Thing is, I have no idea what to make of a shell script here in conda-forge. We could simply just copy it and chmod it in $PREFIX/bin --- I guess that would be good enough, right?
But then, we would have two jill commands in bin/; so we need to set a conflict between the two so that the user must choose one or the other (pretty easy to do like this)
Overall, it seems like shell script is not necessarily designed to be a full-fledged program, and instead it is light-weight enough, one could just copy/wget it and run it...

I definitely want to correct my oversight of not noticing jill.sh and just running with jill.py as the jill

Ah, I see I got it swapped now. jill.sh is quite light weight in terms of dependencies and thus much easier to install.

But then, we would have two jill commands in bin/; so we need to set a conflict between the two so that the user must choose one or the other (pretty easy to do like this)

Even if they were in the same bin directory, I think one would need to need explicitly execute jill.sh or jill.py, right? Does either of them run as just jill ?

https://github.com/conda-forge/jill-feedstock/blob/5a265bb23693355a91a38a4f46ce8465e26b73a6/recipe/meta.yaml#L12-L17

I think for now having jillpy only is the way to go. This is after all a primarily python ecosystem ... Closing for now, but we will revisit at some point later.

This is after all a primarily python ecosystem

Is it? It is a de facto python primarily ecosystem, but I get the impression it intends to be more. Anyways, this is fine with me.
Do you intend to bring the activation script here as well?

Do you intend to bring the activation script here as well?

Ah, that's a good point! Let me think...

but I get the impression it intends to be more

I don't think there's any inherent intention honestly. It is just a super flexible system run by volunteers, so you can build anything you wish. But there is not like a set of instructions to expand into each corner of software... at least, not that I am aware of.
I am reopening this to think about the scripts, thanks for bringing that up!

Btw, how do you feel about me adding you as a maintainer here and in the other feedstocks? No pressure, but since you're the one with vastly more julia experience, you may want to experiment and push things however you want — I generally prefer to defer to you :)
I would love to have you as a maintainer, but of course, you have to consent to be added first!

Sure. Why not?

Let's refocus this convo on the scripts vis-a-vis windows: xref https://github.com/conda-forge/julia-feedstock/issues/194
would you want to make a ghost package for windows in julia-feedstock that can just use jill to download julia or do you prefer to just do that here? I am going to try to see if we could have an opt in type of thing and we need to condition on the scripts on certain versions (e.g. the stacking)

You would know better than I what would match conda user expectations. If the label for the ghost package were clear, I think that would make sense. I feel like we need to write down documentation on this somewhere. Perhaps writing this up on https://discourse.julialang.org/ would make sense?

I think I would like to experiment with the following solution for Windows:

create a split here
one output is the same as now
second output (name it jill-conda-julia or something like that) contains the scripts we have + instructions to automatically install julia from upstream (i.e. user will get the binaries from julia upstream automatically, but we won't ship them)

How does that sound to you?
We will want to ensure a few things for completion:

direct jill to install binaries in CONDA_REFIX
carefully test the scripts
before actually releasing this to main, we will want to consult with core/isuruf (at first we can release it in a separate dev channel)

sounds good to me


Not detecting certificates

Describe the bug
I used gitleaks to review a small repo which had a private key and a certificate.
gitleaks detected the key (yay!) but not the certificate.
The string containing the certificate started with -> -----BEGIN CERTIFICATE-----
and ended with -> -----END CERTIFICATE-----\n
Between those lines, you can find the usual "random" characters.
To Reproduce

Run gitleaks and try to detect a string with a certificate such as the one said above.

Expected behavior
I believe the certificate should've been detected as a leak.
Screenshots
Can't give any.
Basic Info (please complete the following information):

OS: MacOS Catalina 10.15.7
Gitleaks Version: 7.5.0 (installed from brew)

Additional context
I ran gitleaks with --verbose, but only showed the key leaked, not the certificate.
cc @zricethezav

Hey @w0rmr1d3r this would be easy enough to add. We would just need an additional rule similar to https://github.com/zricethezav/gitleaks/blob/master/config/default.go#L76-L79.
Something like
        [[rules]]
            description = "Asymmetric Private Key"
            regex = '''-----BEGIN CERTIFICATE-----'''

Care to test that out and see if it works? If it does, feel free to open a PR 😄

Alright! Will do in the following days!

Hello @zricethezav !
I can't build a custom docker image in order to test it, it's giving me errors.
What I've tried is to use a custom config file and put that rule there, but it's not detecting anything.
I've put this:
[[rules]]
  description = "Certificate"
  regex = '''-----BEGIN CERTIFICATE-----'''

in the custom config file, and trying to scan a "bad file" with that in in, and nothing is found.
Any help here?

Hello @w0rmr1d3r,
gitleaks did not detected the certificate as a certificate is not a secret.  This means merging #656 would cause a lot of false positives.
In case there is a specific reason why a certificate should be detected, then a using a locally adapted configuration would be the better way, but not updating the default config for everyone.

Hi @lutzwillek-tomtom !
Agree, since @zricethezav suggested how to create the rule, I went for it.
Will close both the issue + PR.
Thanks


Breaking Change in Casbin when updated from v2.54.0 to v2.68.0

Getting error when updated the casbin version to latest
# github.com/pckhoi/casbin-pgx-adapter ../../../../go/pkg/mod/github.com/pckhoi/casbin-pgx-adapter@v1.0.1/adapter.go:347:50: cannot use persist.LoadPolicyLine (value of type func(line string, m model.Model) error) as func(string, model.Model) value in argument to a.loadFilteredPolicy
Although it was already discussed in #6 and by downgrading to the v2.54.0 it is working.
I am looking for fixed with latest version of casbin.
Thanks

@MrAwanishKumar what version of Casbin and casbin-pgx-adapter are you using?
casbin-pgx-adapter v2.2.0 and later versions should already support latest versions of Casbin, see: https://github.com/pckhoi/casbin-pgx-adapter/releases/tag/v2.2.0

Maybe you can try github.com/pckhoi/casbin-pgx-adapter/v3. The tests seem to pass at least.

@hsluoyz earlier I was using the older version of casbin v2.54.0 and casbin-pgx-adapter v1.0.1, was working fine but when I do update, the casbin updates to v2.68.0 and casbin-pgx-adapter remain on the same version v1.0.1. This causes the issue.
Now updated the both casbin to v2.68.0 and using casbin-pgx-adapter/v3 working fine.
Thank you @pckhoi  and @hsluoyz

Problem is solved. Closing this issue.
Thanks


fix markdown in a table

to show words after |

@yoichinak : Thanks for your contribution! The author, @v-miclar, has been notified to review your proposed change.

#sign-off


nmap still does not work on WSL

As of two years since this was last reported and ignored as a problem this still does not work.
Windows 10 1909, 18.363.778, Ubuntu WSL:
Starting Nmap 7.60 ( https://nmap.org ) at 2020-04-30 10:23 EDT
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
NSOCK ERROR [0.0530s] mksock_bind_device(): Setting of SO_BINDTODEVICE failed (IOD #1): Protocol not available (92)
NSOCK ERROR [0.0530s] mksock_bind_device(): Setting of SO_BINDTODEVICE failed (IOD #2): Protocol not available (92)
NSOCK ERROR [0.0530s] mksock_bind_device(): Setting of SO_BINDTODEVICE failed (IOD #3): Protocol not available (92)
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92
socket_bindtodevice: Protocol not available
Problem binding to interface , errno: 92

+1 some people's job rely heavily on the use of network scanners, particularly nmap, therefore if you want to win them over and have them ditch their VM to fully commit to WSL this issue should be treated as a high priority issue.

some people's job rely heavily on the use of network scanners

Them they should use the Windows version of nmap or use a real GNU/Linux distribution with its nmap package. Without relaying on any type of VM or compatibility layer.

This is a duplicate of at least #5083, #1349, #3859, #3521, #3440, #2039, #2548, #1349.
By knowingly opening a duplicate bug report you take time from developers working on new features. It does not help the developers ship it faster.
This is fixed in WSL 2 which is available on all Insiders channels. If you want to try it in a VM without upgrading your system, you can follow this guide. If you are interested in using WSL 2 for security, you should watch How we use WSL at Kali.

@sirredbeard

This is fixed in WSL 2 which is available on all Insiders channels.

incorrect. The problem is still present with WSL2 Ubuntu.

@sirredbeard your guide link has been taken down and only returns a 404 page.
for those coming from google, make sure you have gone though the steps to enable wsl then to upgrade from wsl 1 to wsl 2:
wsl --version 2
wsl --set-version default 2

@denzuko your second command is false, right is
wsl --set-version-default 2


record-collections and oai-sets

Description
Both ogcapi-records as well as oai-pmh have a similar concept for subsets of records.

In the case of OAI the sets are currently semi-hardcoded datasets and Interactive Resources in oai
ogcapi uses a mechanism with virtual collections based on parentidentifier

I wonder if it makes sense to align both cases?

There will be a third case soon: In STAC API we will enable empty collections to align with the STAC tooling


feat(FN-1432): handle formulas and new lines in excel cells

Introduction
The current parsing could not handle formulas in excel files and would return [Object object]. It also couldn't handle new lines in cells
Resolution
Replace new lines with spaces so that we can correctly convert to a csv format for parsing without worrying about extra new line characters in the middle of a row.
Check if the cell value comes from a formula looking for cell.value?.result before defaulting to cell.value if that is not the case to handle excel formulas. This also works for lookups to other sheets as they count as formulas in the same way by the excel parsing library

Codecov Report

:exclamation: No coverage uploaded for pull request base (main-stbr@6554470). Click here to learn what that means.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main-stbr   #2270   +/-   ##
===========================================
  Coverage             ?   7.15%
===========================================
  Files                ?     102
  Lines                ?    2110
  Branches             ?     358
===========================================
  Hits                 ?     151
  Misses               ?    1671
  Partials             ?     288

Flag
Coverage Δ

unit-test
7.15% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


Add function and classes docstrings

Pull Request
Title
Add function and classes docstrings

Description
Add function and classes docstrings

Issue link: #96

Type of Change

📝 Documentation update

Testing
tests passed

Codecov Report
Attention: Patch coverage is 72.72727% with 3 lines in your changes missing coverage. Please review.

Project coverage is 77.84%. Comparing base (3a157ee) to head (0d635aa).

Files with missing lines
Patch %
Lines

...ate_provider/PredictiveFileClusterStateProvider.py
70.00%
3 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #127      +/-   ##
==========================================
+ Coverage   77.63%   77.84%   +0.21%
==========================================
  Files          23       23
  Lines        1082     1079       -3
  Branches      137      136       -1
==========================================
  Hits          840      840
+ Misses        190      187       -3
  Partials       52       52

Flag
Coverage Δ

unittests
77.84% <72.72%> (+0.21%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Error: Building package boost:x86-windows failed with: BUILD_FAILED

Fresh clone and build of vcpkg, followed the directions in the README.md
Ran from a command prompt, this commant:
.\vcpkg install beast

Failed with this error:
Error: Building package boost:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: boost:x86-windows
  Vcpkg version: 0.0.81-05e682a19d40036c9a34c2c7a94e6325fb7e9f1c

This was the output:
C:\Users\vinnie\src\vcpkg>.\vcpkg install beast
The following packages will be built and installed:
    beast:x86-windows
  * boost:x86-windows
Additional packages (*) will be installed to complete this operation.
Building package boost:x86-windows...
-- CURRENT_INSTALLED_DIR=C:/Users/vinnie/src/vcpkg/installed/x86-windows
-- DOWNLOADS=C:/Users/vinnie/src/vcpkg/downloads
-- CURRENT_PACKAGES_DIR=C:/Users/vinnie/src/vcpkg/packages/boost_x86-windows
-- CURRENT_BUILDTREES_DIR=C:/Users/vinnie/src/vcpkg/buildtrees/boost
-- CURRENT_PORT_DIR=C:/Users/vinnie/src/vcpkg/ports/boost/.
-- Using cached C:/Users/vinnie/src/vcpkg/downloads/boost_1_64_0.tar.bz2
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Extracting done
-- Using cached C:/Users/vinnie/src/vcpkg/downloads/boost-range-has_range_iterator-hotfix_e7ebe14707130cda7b72e0ae5e93b17157fdb6a2.diff
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Applying patch C:/Users/vinnie/src/vcpkg/buildtrees/boost/src/boost-range-has_range_iterator-hotfix_e7ebe14707130cda7b72e0ae5e93b17157fdb6a2.diff.fixed
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/Users/vinnie/src/vcpkg/buildtrees/boost/src/boost-range-has_range_iterator-hotfix_e7ebe14707130cda7b72e0ae5e93b17157fdb6a2.diff.fixed done
-- Bootstrapping done
-- Building x86-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process_repeat.cmake:21 (message):
    Command failed: C:/Users/vinnie/src/vcpkg/buildtrees/boost/src/boost_1_64_0/b2.exe;--stagedir=C:/Users/vinnie/src/vcpkg/buildtrees/boost/x86-windows-rel/stage;--build-dir=C:/Users/vinnie/src/vcpkg/buildtrees/boost/x86-windows-rel;-sZLIB_INCLUDE="C:/Users/vinnie/src/vcpkg/installed/x86-windows\include";-sBZIP2_INCLUDE="C:/Users/vinnie/src/vcpkg/installed/x86-windows\include";-j20;--debug-configuration;--hash;-q;--without-python;threading=multi;runtime-link=shared;link=shared;toolset=msvc-14.1;-sZLIB_BINARY=zlib;-sZLIB_LIBPATH="C:/Users/vinnie/src/vcpkg/installed/x86-windows\lib";-sBZIP2_BINARY=bz2;-sBZIP2_LIBPATH="C:/Users/vinnie/src/vcpkg/installed/x86-windows\lib";variant=release;debug-symbols=on
    Working Directory: C:/Users/vinnie/src/vcpkg/buildtrees/boost/src/boost_1_64_0
    See logs for more information:
      C:\Users\vinnie\src\vcpkg\buildtrees\boost\build-x86-windows-rel-out.log
      C:\Users\vinnie\src\vcpkg\buildtrees\boost\build-x86-windows-rel-err.log

Call Stack (most recent call first):
  ports/boost/portfile.cmake:188 (vcpkg_execute_required_process_repeat)
  scripts/ports.cmake:73 (include)

Hey vinnie, thanks for trying out vcpkg 😊.
Sorry about the failure! I suspect based on previous experience that it is due to a site-config or user config file somewhere on your disk that bjam is picking up.
Could you post or send us the two log files listed in the message?

C:\Users\vinnie\src\vcpkg\buildtrees\boost\build-x86-windows-rel-out.log
C:\Users\vinnie\src\vcpkg\buildtrees\boost\build-x86-windows-rel-err.log

I renamed the site-config.jam in my user directory and it got farther along. This is the contents of my site-config.jam:
import os ;

using msvc ;

using boostbook
    : "C:/Users/vinnie/lib/docbook-xsl"
    : "C:/Users/vinnie/lib/docbook-dtd"
    ;

using xsltproc ;

using doxygen ;

using fop
    : "C:/Users/vinnie/boost_1_64_0/tools/boostbook/fop-0.94\fop
    :
    : "C:/ProgramData/Oracle/Java/javapath/java
    ;

local OPENSSL_ROOT = [ os.environ OPENSSL_ROOT ] ;
local OPENSSL_LIBRARIES = [ os.environ OPENSSL_LIBRARIES ] ;
local OPENSSL_INCLUDE_DIR = [ os.environ OPENSSL_INCLUDE_DIR ] ;

project
  : requirements
    <include>$(OPENSSL_ROOT)/include
    <library-path>$(OPENSSL_ROOT)/lib
  ;

It is still building, probably it will work, thanks.

Here are the log files. Not sure what the numbers at the end of the filenames mean.
build-x86-windows-rel-err-2.txt
build-x86-windows-rel-out-0.txt
build-x86-windows-rel-out-1.txt
build-x86-windows-rel-out-2.txt
build-x86-windows-rel-err-0.txt
build-x86-windows-rel-err-1.txt

The beast install was successful but I need that site-config.jam where it is for my other projects to work. What do I do?

Just wondering if anyone knows the answer to this:

I would love advice on how to stop Visual Studio 2017 from echoing the command lines it is using during a build, but that's not a vcpkg specific problem.

Described in more detail in #1084 (which I have since closed)

Unfortunately, the best current answer is that you will need to temporarily rename your site-config if you want to build boost through vcpkg -- you can rename it back once you are done since we cache the build.
I would love to have a better answer here, but I haven't been able to find any way to suppress bjam from picking it up (site-config). In the worst case, we may need to patch boost during our build to fix this.

Oh, you're saying that my site-config.jam only gets in the way when building Boost through vcpkg. That's not completely terrible. I could rename it to user-config.jam, maybe that would help.

That would work for us, because we supply our own user-config in order to customize the exact compiler used.
I don't know your full environment so I'm not sure how it would impact the rest of your boost usages.

I did a fresh install using vcpkg install beast with my config file renamed to user-config.jam, and it all worked! I was able to build my previous projects which use the bjam toolchain (mostly documentation) which relied on my user-wide jam file and it worked as well, so I think this is resolved.

Hi everybody!

remove "\protobuf" from "C:\src\vcpkg\buildtrees"
.\vcpkg.exe install protobuf
It helped me!