Add support for SLF4J binding via SPI in SLF4J 1.8 onwards

Description
Linked issue: #119
Definition of Done

[x] There are no TODOs left in the code
[x] Code style follows the tinylog standard
[x] All classes and methods have Javadoc
[ ] Changes are covered by JUnit tests including corner cases, errors, and exception handling
[x] Maven build works including compiling, tests, and checks (mvn verify)
[x] Changes are committed by a verified email address that is assigned to the GitHub account (https://github.com/settings/emails)

Documentation
Additions or amendments for the public documentation:
This patch allows to use Tinylog with SLF4J 1.8 and onwards, which requires locating SLF4J bindings via the service loader mechanism.

Additionally, users can retrieve bleeding edge Tinylog versions by using [JitPack](https://jitpack.io/#tinylog-org/tinylog) by specifying commit IDs as version numbers.

Agreements

[x] I agree that my changes will be published under the terms of the Apache License 2.0
[x] I agree that my GitHub user name will be published in the release notes

Notes

If you don't think JitPack is warranted, I'd also drop it. I just needed it to immediately test the change in my current project. I might keep the file to my fork only, or just might use the next release of Tinylog. But I see some value in being able to run with individual commits just by adding the repository definition and using dependency coordinates such as com.github.f4lco.tinylog:slf4j-tinylog:f93accf1c581682298246662fe5e31485d5b1c4a.
I didn't really see a good use-case for a unit test. It's really plain, devoid of any particular logic. Please feel free to give examples of testable properties if you think that's not the case.
Also suspected in #119, using the SPI is not possible from SLF4J 1.7. Only SLF4J 1.8 and onwards contains the required interface.
I'm not sure about the deprecation of the former method. At some point, we could likely remove the static binder classes org.slf4j.impl.{StaticLoggerBinder,StaticMarkerBinder,StaticMDCBinder} from Tinylog.
It's me.... it's just been a while since #70 😄

If you don't think JitPack is warranted, I'd also drop it. I just needed it to immediately test the change in my current project. I might keep the file to my fork only, or just might use the next release of Tinylog. But I see some value in being able to run with individual commits just by adding the repository definition and using dependency coordinates such as com.github.f4lco.tinylog:slf4j-tinylog:f93accf1c581682298246662fe5e31485d5b1c4a.

I didn't know JitPack before, but I actually like the idea. However, I would prefer the integration by a separate pull request.

I didn't really see a good use-case for a unit test. It's really plain, devoid of any particular logic. Please feel free to give examples of testable properties if you think that's not the case.

A full integration test case would be great to ensure that SLF4J's LoggerFactory provides loggers, which are an instance of TinylogLogger when using SLF4J 2.0.

Also suspected in #119, using the SPI is not possible from SLF4J 1.7. Only SLF4J 1.8 and onwards contains the required interface.

Older SLF4J should just ignore the new class. I don't expect any problems when using SLF4J 1.7. However, correct me if I'm wrong.

I'm not sure about the deprecation of the former method. At some point, we could likely remove the static binder classes org.slf4j.impl.{StaticLoggerBinder,StaticMarkerBinder,StaticMDCBinder} from Tinylog.

SLF4J 1.7 is still very popular and there is sill no stable release of SLF4J 1.8 nor 2.0. I assume we will have to live with the static binder classes quite long.

It's me.... it's just been a while since #70 😄

Welcome back :) I'm glad to receive a pull request again from you!

I didn't know JitPack before, but I actually like the idea. However, I would prefer the integration by a separate pull request.

I will arrange for that.

A full integration test case would be great to ensure that SLF4J's LoggerFactory provides loggers, which are an instance of TinylogLogger when using SLF4J 2.0.

I was a bit surprised something like that did not exist before for the static logger binder. No worries, I'll add one.

Older SLF4J versions should just ignore the new class. I don't expect any problems when using SLF4J 1.7. However, please correct me if I'm wrong.

That's also my belief.

SLF4J 1.7 is still very popular and there is sill no stable release of SLF4J 1.8 nor 2.0. I assume we will have to live quite long with the static binder classes.

OK, then maybe that's in for Tinylog 3 😉

Welcome back :) I'm glad to receive a pull request again from you!

Thanks 😄  Please enjoy my reworked PR, your feedback was very valuable.

The integration tests looks very good but SLF4J seems not using the new TinylogSlf4jServiceProvider for resolving the logger factory nor the MDC adapter. According to the code coverage report, none of the tests triggers any call of the TinylogSlf4jServiceProvider.
@f4lco Do you understand the reason?

No. I do not understand why @codecov did not provide us with an updated report within this PR. During test development I set breakpoints in the respective methods of TinylogSlf4jServiceProvider and the test definitely hit them. After a bit of digging, the report under https://codecov.io/gh/tinylog-org/tinylog/commit/4ce0fb5991d05642809f9257c37ac87197474734/ reflects that 🤷♂

No. I do not understand why @codecov did not provide us with an updated report within this PR. During test development I set breakpoints in the respective methods of TinylogSlf4jServiceProvider and the test definitely hit them. After a bit of digging, the report under https://codecov.io/gh/tinylog-org/tinylog/commit/4ce0fb5991d05642809f9257c37ac87197474734/ reflects that 🤷♂

I'm relived that the provider does work as expected :) @codecov did even update the report post after your commits but hasn't shown the correct code coverage for any reason.
Just a last wish before merging the pull request: Could you add a test for MarkerFactory.getIMarkerFactory()? tinylog converts markers into tags what requires an actual marker factory.

Just a last wish before merging the pull request: Could you add a test for MarkerFactory.getIMarkerFactory()? tinylog converts markers into tags what requires an actual marker factory.

Done 👍

Thank you, I'm happy to merge your pull request :)


Added Nth Fibonacci Number in C

Fixes #628
By submitting this pull request I confirm I've read and complied with the below declarations.

[x] I have read the Contribution guidelines and I am confident that my PR reflects them.
[x] I have followed the coding guidelines for this project.
[x] My code follows the skeleton code structure.
[x] This pull request has a descriptive title. For example, Added {Algorithm/DS name} [{Language}], not Update README.md or Added new code.
[x] This pull request will be closed if I fail to update it even once in a continuous time span of 7 days.
[x] This pull request shall only be reviewed and merged once the Travis build passes. No maintainer or supporter shall be obliged to review it before this condition is met.
[x] I have mentioned the issue number correctly (with hyperlink) in this pull request description.

@heisenberg-2505 please update your branch and fix the build errors.

You mean rebasing it with upstream master?

Sir upon changing the indent style to spaces (as you mentioned before) travis CI is giving the following error ❌ invalid indent style: space, expected: tab

@heisenberg-2505 that was my mistake, please roll back to tabs.


Sent items folder

Hello,
Is there a way to keep a copy of a sent mail in the sent items folder?
I was looking for something like this: https://angelborroy.wordpress.com/2009/01/21/javamail-send-message-copying-it-to-sent-items-folder/
thank you

That is not supported by the mail plugin, as it's sole purpose it to communicate via SMTP. The example shown does both that, and writes to the users inbox via IMAP. You should however be able to use that example fairly simply to build your own InboxService that writes after a message is sent.


PerpindicularPaths - Game Timer

The game timer is inaccurate when a level is completed.

http://stackoverflow.com/questions/17498199/why-are-there-differences-in-python-time-time-and-time-clock-on-mac-os-x

19cb4d8e1320aa7f5d9e4dd1865fba346e4472a9


Announce on Julia Discourse

Hi and thank you for this package!
Have you considered announcing it on Julia Discourse?
https://discourse.julialang.org/
It can give the package useful publicity

Thanks! I think I'm just about ready. I've struggled to get the "time-to-first-inference" down to a reasonable amount, and just now got it to 12 seconds, which I think is almost tolerable.

Done! https://discourse.julialang.org/t/new-wildboottests-for-wild-bootstrap-based-inference-on-linear-models/73567


Refactor helm chart, splitting operator deps into separate chart

ToDo:

[ ] Should we version the two charts separately or together?
[ ] Should we bundle in the NFS chart with galaxy-deps for convenience? or disable the alien cache by default?

I feel separate versioning is better suited for us. The Galaxy chart is likely to advance much more frequently than the deps one as we tend to not seek latest features in most of our deps.
Bundling the NFS chart seems like a reasonable thing to do so all the deps are captured.

Versioning separately is ok, but we would have to make the bundling logic much more sophisticated. We would probably have to detect which subfolder changed, and then bump versions accordingly. There's also the complication of which chart a  "minor/major" label applies to. Alternatively, we would need to maintain a separate chart. Maybe this is a separate thing that @ksuderman can help with, since he's done a lot of the packaging work.

Hmm, now I'm not so sure separate versioning is not worth it because the packaging seems like a bit of magic as is placing things a various places, which leads to playing pacman to find it all... But if we version it together, how will the upgrade process on a deployed instance look? Will all the deps get rotated every time?

Would it be better to separate the galaxy-deps chart into its own repository and package/deploy it separately?  That would clean up versioning and packaging issues.

Ok, I'll split it out into a new repository

I'd just suggest naming the repo (and the chart) galaxy-helm-deps so it is more clear that it applies to the Helm chart.

Removed versioning labels because we want to get all breaking changes into v6 in one go.

Deps moved to: https://github.com/galaxyproject/galaxy-helm-deps


Decouple errors for TagHelpers from type name

From https://github.com/aspnet/Razor/pull/1054#discussion_r104775920
Since TagHelperDescriptors are no longer tied to type name, we need to use DisplayName instead of type name in all our error messages for TagHelperDescriptors.
@NTaylorMullen

This could move out to 2.1.0 so it will.

Pulling this in, I ended up needing to do it while decoupling the builders from types and property names

This was fixed by 853b458893b01458ef3df1f2045c7c4dec35f5fc


Rules Engine param Feature

Rules Engine has a param (like ‘var’ in c#) feature support now, it makes authoring and troubleshooting of issues very easy. Now you can breakdown your bigger statements into smaller logical expressions as parameters within a rule definition.

I don't completely understand what this should do. Do you have an example?


Make dataSourceId parameter optional for agent config_exist API

Description
The dataSourceId parameter in the agent config_exist API should be optional, for case dataSourceId is null for local cluster.
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test.

[ ] New functionality has user manual doc added.
[x] Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

FYI: I have the same fix in https://github.com/opensearch-project/dashboards-assistant/pull/310


Cannot use session() helper to store data in custom WebHooks handler

In the custom WebHooks handler, I try to store some data via the Laravel "session()" global helper function but it didn't work as expected. There's no session was created. For example,
    public function connect()     {         try {             session(['data' => '123']);         } catch (Exception $e) {             Log::channel('telegram')->error($e->getMessage());             $this->chat->html(ChatService::error())->send();         }     }

Already answered in discussions


Correct Batch Normalization Implementation

Overview
_The elephas calculates the deltas of the weights by simple subtraction. This strategy is efficient for the conv2d layers and dense layers. However, modern neural networks always contain batch normalization layers in which the subtraction strategy fails. Thus, elephas could not be used for distributed training some popular networks such as google inceptions and YOLO.
Can this be solved?_
(Copied from https://github.com/maxpumperla/elephas/issues/57)
Possible Approaches
We need to investigate what the "correct" implementation of batch normalization would be in a distributed setting.
Alternative Options
The current approach may already be correct? Or work "well enough".
Additional context
Add any other context or screenshots about the feature request here.

After thinking about this for a bit, I actually believe Elephas is handling distributed batch normalization correctly. I don't know if there is an alternative implementation that would make more sense based on the distributed paradigm we're using. For that reason, I am closing this issue out. I invite anyone to reopen the issue (or even a PR) if I am wrong about this or if there's a proposal.


p5.Vector explanation of setMag

Actual Behaviour
in https://p5js.org/reference/#/p5.Vector

Set the magnitude of this vector to the value used for the len parameter.

Expected Behaviour
if I understand correctly

Set the magnitude of this vector to the value used for the mag parameter.

That is set to match the parameter name in https://p5js.org/reference/#/p5.Vector/setMag. Changing it to be mag in both places is fine but I wonder if it would cause confusion with thee mag() method in some way (maybe that's why it is named len in the first place).

Thanks, now I see... I thought it's about mag() but in fact in the url you pointed it has len as a parameter of setMag(len). I feel it's a bit confusing in the p5.Vector page because len does not appear there. I don't know what would be a better description though :(

It seems the two descriptions have to match because of how the p5.Vector class is rendered, they are fetched from the same string.

that's what I thought after your first comment. The more I read the sentence I feel it sounds strange. What about

Set the magnitude of this vector to len (the first parameter)

is that still too wordy? do we need feedback from other people to change it?

It still feels a bit off to me.
For a bit of context, the existing description is taken from Processing word for word while the setMag() in Processing's PVector class has a different description. I'm not sure about how difficult it is to seperate the two on p5.js and I'm a bit reluctant to do it now as I'm exploring refinements to the whole render proceess.
Some additional feedback would definitely be helpful.

I think this could be simplified to just say "Set the magnitude of the vector." Maybe this is less confusing? My assumption would be that if someone is using setMag() they have wrapped their head around parameters a bit already, and would be able to follow the format of the documentation to use the method. But I think your proposed update to the language makes sense as well.


Parallax effect on main page image and adjust code so that it is reponsive

As discussed with Jessica, we can check on the parallax effect on the main image.
The responsiveness of that block needs also to be checked, the image doesn't shrink when the viewer size decrease.
On the actual site it doesn't decrease either and for small screens you need to scroll from left to right to see all of the text on the original site. On the Franklin site the text works well but the image doesn't shrink either
issue-image.pdf

I did fix the responsiveness of the image and now is shrinking. I am checking now on the parallax effect and see if I can do something about it


Added fields in appData and sensorData

added optional waterLevel, GPS and flush.

@johanstokking, @Nicolasdejean addressed your requests for changes

@johanstokking, @Nicolasdejean addressed your requests for changes.

We can wait to merge this one, I'm going to add fields for downlink and uplink for waternet.


snackbar: Handle connectivity changes and show appropriate SnackBar

This commit introduces a SnackBarPage widget that handles changes in connectivity status and displays a SnackBar accordingly. The SnackBarPage widget listens to connectivity changes using the Connectivity package and updates the UI to show a "Connecting" SnackBar  and a "No Internet Connection" SnackBar when there is no internet connection.
The showSnackBar method is responsible for displaying the appropriate SnackBar based on the current connectivity status. It uses ScaffoldMessenger to show and hide the SnackBar.
Additionally, the initState method initializes the connectivity status when the widget is first created, and the didChangeDependencies method subscribes to connectivity changes to update the UI accordingly. The dispose method cancels the subscription to avoid memory leaks.

When a PR is meant to fix an issue, please refer to the issue in both the commit and the PR description. This is mentioned in the Zulip Git style guide, and in more detail here:
https://github.com/zulip/zulip-mobile/blob/main/docs/style.md#mention-fixed-issue
Similarly, when there are previous closely related PRs, mention those too. For example (and I'm mentioning these now in order to get the cross-references): previous iterations of this PR were #586, #584, #583.

New Approach :-
1)The function registers an event queue with the Zulip server.
2)It sets a flag to indicate registration is in progress.
3)Sends a POST request to the server.
4)If successful (status code 200), it extracts the queueId and lastEventId, hides the "Connecting…" banner, and shows a success message.
5)If not successful, it prints an error message and shows a  connecting message.

`   Future registerEventQueue() async {
setState(() {
_isRegisteringEventQueue = true;
});
final String apiUrl = 'https://yourZulipDomain.zulipchat.com/api/v1/events';
try {
  final response = await http.post(
    Uri.parse(apiUrl),
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
      //  required authentication headers
    },
  );

  if (response.statusCode == 200) {
    final responseData = json.decode(response.body);
    final queueId = responseData['queue_id'];
    final lastEventId = responseData['last_event_id'];

    //  queueId and lastEventId to start listening for events
    // Hide the "Connecting…" banner and update the UI with refreshed data
    setState(() {
      _isRegisteringEventQueue = false;
    });

    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(
        content: Text(
          'Event queue registered successfully',
          style: TextStyle(color: Colors.white),
        ),
        duration: Duration(seconds: 3),
      ),
    );
  } else {
    print('Failed to register event queue: ${response.statusCode}');
    showSnackBar(ConnectivityResult.none); //  "No Internet Connection" message
  }
} catch (e) {
  print('Error registering event queue: $e');
  showSnackBar(ConnectivityResult.none); // "No Internet Connection" message
}

}`
we can use "https://yourZulipDomain.zulipchat.com/api/v1/events" this endpoint to get the data about the the event queue. which i read about this url in zulip docs.
@gnprice whar are your views on the new approach .

Please disable your autoformatter and undo the unrelated formatting changes, so that we can do a deeper code review without distractions. The project's approach to formatting is covered in the README: https://github.com/zulip/zulip-flutter?tab=readme-ov-file#code-formatting

Also, please organize your commits: https://github.com/zulip/zulip-flutter?tab=readme-ov-file#submitting-a-pull-request


Support unquoted attributes

if you have svgs with unquoted attributes such as:
xmlns="http://www.w3.org/2000/svg" width=20px height=20px
The error: Error in parsing SVG: Unquoted attribute value is emitted.
i created a plugin to temporary fix this:
https://www.npmjs.com/package/xml-fix-loader
{
  test: /\.svg$/,
  use: [
    { loader: 'file-loader' },
    { loader: 'xml-fix-loader' }
  ]
}

bug was also opened on svgo:
https://github.com/svg/svgo/issues/678

spam

https://github.com/imagemin/imagemin/issues/233
https://github.com/rpominov/svgo-loader/issues/9
https://github.com/Klathmon/imagemin-webpack-plugin/issues/25

not a spam, i just got deeper and deeper to dependencies of dependencies to solve it :P


Difference in  path serverside vs clientside

Description
Hi!
First off, let me say thanks for this library. My current projects now needs localized pathnames which this lib offers, so thanks!
Unfortunately I'm encountering an issue with the next-intl <Link/> component rendering the localePrefix serverside although as-needed is set as LocalePrefix. Clientside renders the correct path.
E.g. serverside renders /nl/over vs serverside /over.
This seems to be fully reproducible. Running the example-app-router with localePrefix  as-needed will result in the same problem.
Any ideas?
Although kind of  works for the end-user because it gets fixed by hydration and browsers with JS disabled will ultimately be redirected, it's not that nice to have in production and probably has some effect on SEO.
Mandatory reproduction URL (CodeSandbox or GitHub repository)
https://ndrx9l-3000.csb.app/
Reproduction description
Steps to reproduce:

Open reproduction
Use 'show source' or disable JS to view the rendered HTML.
Compare the link serverside vs clientside. It's "/nl/over" serverside, it's "/over" clientside.

Expected behaviour
Serverside should render the correct path when localePrefix = 'as-needed'.

Thanks for the kind words! This is a duplicate of #444 and mentioned in the docs, I'll close this in favour of #444.

Yeah, sorry about that.
Here's some more context for people coming here.  https://next-intl-docs.vercel.app/blog/next-intl-3-0#switching-the-middleware-default-of-localeprefix-to-always and https://next-intl-docs.vercel.app/docs/routing/middleware#locale-prefix-as-needed.
This is intended behaviour.

@jbreemhaar I don't know if this solves your specific problem because I never experienced it, but perhaps it helps in some way, and it sounds similar to the direction you are taking :)
I've looked at the next-intl code and realized that there is almost nothing that really and intentionally differentiates server and client. We already have a function that next-intl exposes through navigation, used for path resolution and it gives us urls as strings.
I used this function getPathname to generate URLs and give them to next/link. This is able to do SSG and SSR URL resolution and requires no client.
P.S. The getPathname function is only exported with createLocalizedPathnamesNavigation. My project doesn't actually have localized paths, but in order to get that function export, I was forced to use it and manually enter all paths as shared.

@jbreemhaar I had the same issue and I am using this workaround for now:
import { type RedirectType, redirect as nextRedirect } from "next/navigation";
import { locales, pathnames, localePrefix, defaultLocale } from './config'
import NextLink from "next/link";

export const {
  redirect,
  getPathname: getPathname_
} = createLocalizedPathnamesNavigation({ locales, pathnames, localePrefix });

export const getPathname: typeof getPathname_ = ({ href, locale }) => {
  const pathname = getPathname_({ href, locale });
  let prefix = "";
  if (locale !== defaultLocale) {
    prefix = `/${locale}`;
  }
  return `${prefix}${pathname}`;
};

export const redirect: typeof redirect_ = (href, type) => {
  const locale = useLocale();
  const path = getPathname({ href, locale });

  nextRedirect(path, type);
};

export function Link<Pathname extends keyof typeof pathnames>(
  { href, ...rest }: ComponentProps<typeof I18nLink<Pathname>>,
  ref: ForwardedRef<ElementRef<typeof NextLink>>,
) {
  const locale = useLocale();
  // @ts-expect-error this is okay
  const localizedHref = getPathname({ href, locale });
  return <NextLink href={localizedHref} {...rest} ref={ref} />;
}


Setup docs out-of-date

Seems the CLI (including migrate) are now elsewhere:
https://github.com/sequelize/sequelize/blob/master/changelog.md#200-rc4
I'll submit a PR when I'm orientated

Indeed, same problem probably with the updates (migration steps).
Tell me whenever I can help out!

Not ready for merge yet, fyi

FYI

Chef Cookbook: https://github.com/mission-impossible-android/chef-cm-update-server
Demo VM: https://github.com/mission-impossible-android/cm-update-server-vagrant

Anyhow, I guess this is good to merge if it looks ok

I have commented d1db75e - but apart from that it looks fine


Better control of relationship between packagerevisons and versions.

Porch are currently very flexible when it comes to how users can create packagerevisions. Some examples are:

Packagerevisions can be created and published in any order, i.e. it is possible to create and publish v2 before creating and publishing v1.
Each packagerevision is completely independent. So it is possible to create version v1 by cloning from package A and then create version v2 directly from scratch (init) or cloning from a completely different package.
We don't enforce increasing versions for the packagerevisions, which means it is possible to create v1 and then having the next version be v100.
We allow multiple draft packagerevisions to exist at the same time. This isn't necessarily a problem, but we do need to consider how we want to handle that during updates of a package and if we will allow more than one of them to ever be published.

This does create some challenges around determining the latest packagerevision for a package and automatically assigning version to a new packagerevision.
We should consider whether it would be helpful to restrict how packagerevisions can be created and versioned. An example could be:

Only the first packagerevision for a package can be created with init or clone. All other must be created by copy/edit of an existing packagerevision.
Always auto-assign the version of a packagerevision. So the initial packagerevision will have v1 and the new version for every new packagerevision created with copy/edit will be the latest used version plus one. This effectively forces all users of porch to adopt a versioning scheme with simply an increasing number rather than something like semver.
Only a single draft packagerevision can exist at the same time. So a packagerevision must either be approved or deleted before a new one can be created.

I have a proposal to tackle some parts of this issue. There are some restrictions we can introduce to make it easier to reason about a package.
Package creation and editing
Background
This problem is outlined above:

Each packagerevision is completely independent. So it is possible to create version v1 by cloning from package A and then create version v2 directly from scratch (init) or cloning from a completely different package.

Proposal
I agree that we should make it so that the first package revision can only be created from init or clone. Subsequent package revisions should be created with edit or copy. This will force packages to have one distinct origin: either one upstream package in the case of clone, or the first package revision in the case of init.
Drafts and revision number assignment
Background
One thing that I've found odd when working with porch is that the revision number for a package revision needs to be assigned when you create the draft. This can lead to undesirable scenarios:

You can create draft v2 before you create draft v3. Then you can publish draft v3 before draft v2. The end result is that the order in which the package revisions are published is different from the semantic order of the revision numbers.
You have a published draft v1. You can create draft v2 before you create draft v3. You then realize you no longer need draft v2 and discard it. You then publish draft v3. Your published drafts are now v1 and v3 (v2 is skipped).

Comparison to git
In git, there is a concept of a named ref, which is usually one of two things:

an immutable, published tag that corresponds to a version
a branch, named descriptively, whose contents are mutable as features are added

The revision number in porch seems to be neither of these two things; instead, it is just an identifier for a particular package revision, but the version number itself doesn't necessarily correlate to the order of published revisions, nor does it give a description of what changes are included in the package revision.
Proposal
Instead of having the revision number assigned to a package revision when the draft is created, the revision number should be assigned upon approval. Draft package revisions' revision field should be empty until they are published.
This will ensure that the versioning correlates to the order in which the package revisions are published, and that version numbers don't need to be skipped when draft package revisions are discarded.  If we choose to allow semver, this will also allow users to choose whether this package revision should be considered a major, minor, or patch revision upon publishing rather than upon creation of the draft, which will be beneficial in the case that the user needs to make unforeseen changes to a draft.
However, draft package revisions will still need some sort of identifier. We can introduce an additional field to the package revision spec, description, to allow a very short, up to 50-character description of the changes included in this package revision. For example, the description can be something as simple as add new Starlark fn for validation.  Upon publishing of the package, we should clear the description field.
Alternatives

We could require that there can only be one draft of a package at all times. This would resolve the issues with the ordering of published package revision numbers, but would be extremely restrictive if users want to make changes to a package in parallel.

Instead of having an additional description field to identify package revisions when they are drafts, we allow the user to put their short description into the revision field. The description would be overwritten by the published revision number upon publishing. However, it could become confusing to use the same field for two different purposes.

Instead of clearing the description field upon publishing of the package, we could consider either keeping it or folding it into the commit history somehow, so that the user can use it to keep track of what changes have been made between published package revisions.

Versioning restrictions
Background
This problem is outlined above:

Packagerevisions can be created and published in any order, i.e. it is possible to create and publish v2 before creating and publishing v1.

We don't enforce increasing versions for the packagerevisions, which means it is possible to create  v1  and then having the next version be  v100.

There are no restrictions whatsoever on what revision numbers can be. The edit and copy task has a notion of a default next revision number, which is the next semver number, but this is not enforced. I could create a package revision with a revision "number" of foo, and create the next package revision with a revision "number" of bar.
Proposal
We have two primary options for restrictions on package revision numbers:

Very strict versioning with a single number, e.g. only allow v1, v2, in increasing chronological order
Allow semantic versioning, where the next version number for a package revision can only be a semver major, minor, or patch jump. For example, if you have v1.0.0 as the initial package revision number, the next package revision number  would be restricted to v1.0.1, v1.1.0, or v2.0.0.

Strict semantic version (the first option) seems a bit too restrictive. For example, there could be valid use cases where the package may need to branch off into parallel but different v3 and v4 versions that need to be independently maintained. The user could arguably instead maintain these two parallel package revision branches as two different packages, rather than two different versions of the same package, but this seems like an unusual restriction to have.
I think a better approach is to give the user some sort of control over how they want to structure and maintain their package versioning, so we should allow semantic versioning (the second option). We can do some sort of validation check upon publishing of the package that the revision number is actually a semver bump.
Alternatives

Another option we have here is to allow the user to define their own rules. By default, we could allow semantic versioning. If the user requires more strict versioning, they could define these rules in an additional KRM file in the package. We would need to define the syntax and GVK of this new KRM file containing these rules. One reason I am hesitant to introduce this early on is that this adds another configuration file for the user to understand and keep track of, increasing the complexity of the configuration they need to maintain.

Upon publishing a package, instead of the user inputting a version number and porch doing a validation check that it is a semver bump, we can give users the option to specify "patch", "minor", or "major", and let porch automatically assign the next revision number accordingly.

cc @yuwenma @droot @mortent @justinsb

I like this proposal:

Package creation and editing: Yes, this makes sense to me. I can't think of any reason why v2 of a package wouldn't be based on v1. I think this will also make the Package resource much more useful, as it will allow us to include the source (clone or init) in the Package resource and therefore allow direct creation of Package resources.
Drafts and revision number assignment: I like the idea of having a description field that can be used to provide information about drafts and then we just assign version numbers when a revision is published. I'm not sure I see any reason to clear the value when a packagerevision is published though, as it probably will still be useful information about how the new packagerevision is different from the previous one.
Versioning restrictions: I think enforcing strict versioning with a single number makes sense now, although we should be careful about making assumptions in the core logic that will prevent us from supporting other schemes in the future. I do kinda like the idea of allowing users to specify rules for versioning packagerevisions on the package resource itself. But probably not worth adding right now.

Natasha's proposal and Morten's follow up comments make sense to me. Should we also capture additional metadata about the draft - like who created it? I guess that's a separate topic and can be done later.
The rule-based versioning is interesting and perhaps can go in the backlog. Strict sequential numbering works for now.

Some questions may worth thinking of:

Which case best fit in the package update, init/clone or edit/copy?
For drafts and revision number assignment, I like the idea of creating at approval time. I'm a little bit doubt about using the spec.description  as the draft ID. Mainly because that the term "description" is normally used for human-readable info and mostly is mutable, while identifier should be unique and immutable. Also, is this draft UI required to be a user-aware field? Can porch assign an auto-generated id?
Incremental versioning makes sense to me. Can you explain what " branch off a package into two different versions" means? After branching, how does the new package version look like?

Which case best fit in the package update, init/clone or edit/copy?

I think we eventually want to do a package update as a "reclone and replay", so walking through all the previous tasks and reapplying them. But @justinsb or @mortent can clarify the direction that we are heading here.

For drafts and revision number assignment, I like the idea of creating at approval time. I'm a little bit doubt about using the spec.description as the draft ID. Mainly because that the term "description" is normally used for human-readable info and mostly is mutable, while identifier should be unique and immutable. Also, is this draft UI required to be a user-aware field? Can porch assign an auto-generated id?

Yeah, I agree that the description shouldn't considered the "draft ID" necessarily. The revision metadata.name includes a unique, immutable hash identifying the package revision, and we should consider that the package revision ID. The "description" field is more for the user (a human) to identify their package revision without having to memorize the package revision hash.

Incremental versioning makes sense to me. Can you explain what " branch off a package into two different versions" means? After branching, how does the new package version look like?

For example, normally in semver we may maintain both v2 and v3 of some software. Instead of incrementally strictly going up, we may have patches to the old v2 and the new v3. So if we have both v2.0.0 and v3.0.0, we later release both v2.0.1 (for users who need the patch but cannot upgrade to v3) and also release v3.0.1. But we don't want to allow semver in porch (yet).
This proposal states that if a user needs similar functionality, i.e. they need to make some breaking change to their package but still maintain the old version of the package, they should create two separate packages.

Another minor point of discussion, when we create the first package revision, we could either start with v0 or v1. I'm leaning toward starting with v1, but am open to other opinions.

In regards to drafts, any thoughts towards making draft revisions immutable, so anytime a user updates a draft, a new draft revision is created?
An advantage of this is that this will allow us to show a timeline of draft package updates and showing the changes between draft revisions. This can help show what the user changed after cloning a package (whereas today, the clone rending and user changes are mixed together). This does increase complexity and the number package revisions we need to track though...

What is still unclear to me here  is what is the mechanism to determine a new revision is needed? Is this all handled on the server side or is the client involved and what mechanism is envisioned here?
So here is a flow I am using right now.

I determine the latest revision for the package
I determine the KRM resources I need.
I check the diff between the latest revision and the new KRM resources.
4a: if no diff don't update the package revision -> done
4b. if a diff is determined a new package revision would be created.

All of this is executed on the client side but with this enhancement I hope more if not all is done on the server side.

In Porch (server side), revisions will be created like this:

When creating a package from scratch, it starts at revision 1.
When cloning a package, say A  to a new repo, you get a new package A' with upstream pointed to A.  A' starts at r1 regardless of the revision number of A
When make changes to a package, it is done in a Draft branch when using Porch. Draft branches do NOT have revision numbers.
When you Approve a Draft, it moves to Publish and is assigned the next revision number at that time.

@henderiw this is all server side and automatic

@johnbelamaric On your bullet 3 -> When make changes to a package. To determine a change is required is still a client side job I believe or am I wrong?

I am not sure I understand the question completely. Yes, the client will decide what changes are needed to a package. But "client" here could be a controller - for example the controller we're working on in #3488.
The basic Porch commands won't automatically make any changes to a Draft package after cloning. There are certain changes that may happen automatically on clone. For example, when you rpkg clone to a new name, the package name in the package-context.yaml is updated, IIRC. For some packages (in particular, the namespace packages used for provisioning namespaces), that package name is used as input to functions like set-namespace. This could generate a bunch of changes. But since that's on clone it's still going to be rev 1 of the new package.

John, a client can indeed be a controller. The scenario I had in mind is this. You have some KRM resources the client owns in the package. The controller creates them and is the owner of them. Now a change is needed based on a reconciliation trigger, which results in a crud operation on these KRM resources.
So I was wondering how this scenario would be working with this enhancement. Will the client do its changes to the KRM resources it owns and the server will create a new revision automagically or is the client having to do the diff handling to determine a new package revision is needed and the server takes care of the revision handing.

Yeah, I see your point. As part of reconciliation, the controller needs to decide if the resulting package has changed after re-applying any inputs or transformations or whatever the controller does. And you want to know how to do that. It seems like we should be able to make that part of the API - that we should be able to tell if there are an material changes (as opposed to artifacts of the simple act of creating a Draft). @natasha41575 WDYT?

I want to make sure I understand the proposal correctly. Is the suggestion that, if the porch backend sees a diff between the in-cluster KRM resources and the latest package revision, that the porch server will then automatically create a new package revision with the changes?

Will the client do its changes to the KRM resources it owns and the server will create a new revision automagically or is the client having to do the diff handling to determine a new package revision is needed and the server takes care of the revision handing.

I think we could make it part of the API to allow the client to easily check for a diff and create a new package revision accordingly. I'm curious if that would support the use case here. We would have to think about what it means for there to be a diff (Do we check all package revisions? Just the latest published one? All drafts?) But I think it is theoretically doable.
I'm less certain about porch creating a new package revision automatically without the client specifically requesting it. Some scenarios that come to mind:

A user uses another tool to apply some sort of private data (like a Secret) to the cluster. IIUC, porch would see the diff and create a new package revision, meaning that it would end up writing that Secret out to git.
 Porch will either create a new package revision for each individually small change or have to figure out when to update a draft in-place vs when to create a new draft. The user will then have to manually clean up any automatically created package revisions if they didn't intend them to be created or published.

@mortent Do you have any thoughts on this?

@ChristopherFry It seems like what you are asking for is the state of the packagerevision for every mutation. We do capture this as individual commits in git (and individual layers in oci), but we don't currently expose this information through the API. Creating new draft packagerevisions for every change seems like it would create a lot of drafts that will never be published and that we would need additional tooling to manage. I think we could look into whether there is a way to allow quering for specific states of the packagerevision when doing a GET on the package.
An idea is that we could let users specify the tasks that they want to see applied in the packagerevisionresources, and the API would return the state of the packagerevision as it looks after only those tasks have run. I would need to look more into it to determine if it is feasible. Alternatively, we could introduce yet another resource type that provides a view into the data we have in git to allow for fetching packagerevision resources at specific states.

I'm not sure I follow the last question here. Is the question how/who should decide when packagerevision should be proposed/published and therefore deployed into clusters? It seems like that would be specific to each use-case, so I'm not sure porch itself can make that determination. It seems like it would be up to the client. But it is obviously possible that the client here is a controller.
If the client wants to make this decision based on what would change in the cluster, it would be possible to leverage the kpt alpha live plan command, that does a dry-run of the package against the cluster and then produces a Plan krm resource that has a structured description of the changes that will be performed when running apply.

If the client wants to make this decision based on what would change in the cluster, it would be possible to leverage the kpt alpha live plan command, that does a dry-run of the package against the cluster and then produces a Plan krm resource that has a structured description of the changes that will be performed when running apply.

Ooo, that's an interesting idea.

Is the suggestion that, if the porch sever sees a diff between the in-cluster KRM resources and the latest package revision, that the porch server will then automatically create a new package revision with the changes?

I don't think that is what Wim was suggesting. But it actually is an interesting feature. We have the concept of configuration drift. When there is drift, you can either resolve the drift by reconciling back to the intended state, or you can resolve it by updating the intended state. From an declarative management perspective, we always do the former (change the live state to reflect the intended state). In fact as a best practice we avoid allowing mutations to resources that Config Sync manages by using a policy web hook.
I have seen requests though for supporting the opposite workflow at times. For example, an urgent real-time fix on a cluster could be backported to the package so that it is applied across all other instances of the package. In general there would need to be some sort of process / human level controls on that kind of backport. But being able to calculate the deltas and import them could be useful, particularly in package authoring phases, where experimentation can be done on a live cluster and then reincorporated into the package.

I was trying to clarify, who triggers the creation of a new package revision. Is it the role of the client or the server?
My take from all the feedbacks is that:

it would be better that the client is in charge. The client can be assisted by the server to perform this task.

cc @natasha41575 @mortent @droot @justinsb
When choosing to limit ourselves (for now anyway) to a single, sequential numerical version, we discussed the distinction between the version of the configuration package and the underlying software, and I believe I suggested we just use the name of the package for the software version. We didn't lay that out specifically, but what I had in mind was that we would have packages with maybe the major.minor version in the package name, and the patch version being just somewhere in the tags associated with specific PackageRevision versions. So, off-the-shelf vendors would generally align PackageRevision tags and patch releases, but, say, platform teams may have multiple PackageRevisions to represent their config preferences shifting over time for a given patch release
Vendor
my-software-v1.0, v22, release v1.0.4
my-software-v1.0, v23, release v1.0.5
Org
my-software-v1.0, v1, upstream v22, release v1.0.4
my-software-v1.0, v2, upstream v22, release v1.0.4
my-software-v1.0, v3, upstream v23, release v1.0.5
my-software-v1.0, v4, upstream v23, release v1.0.5
etc.
I think that can work.
However, where I still am uncertain is how we upgrade from v1.0 to v1.1, if that's a different package altoghether. What support do we have for rebasing onto a new upstream package? And @natasha41575, how does that affect our UpstreamPolicy work?

@johnbelamaric don't you see a case where a configuration package can consists of multiple source packages? How do you see that working in the above scheme?

if we delete a configuration package I believe we have to delete all the package revision history and if we recreate we start from scratch meaning v1.0 or so.

However, where I still am uncertain is how we upgrade from v1.0 to v1.1, if that's a different package altoghether. What support do we have for rebasing onto a new upstream package?

I don't think we have support for rebasing onto a new upstream package in the porch server. As @mortent describes in https://github.com/GoogleContainerTools/kpt/pull/3603#discussion_r993954378, we plan to enforce the invariant that all package revisions will have the same origin package.
I think it would be possible for UpstreamPolicy or some controller to do some sort of version of a rebase, where it creates a new package revision and does a reclone-and-replay using the new upstream package... but it would have to do so in a different, new downstream package because it would have a different origin. As a result, the client would end up creating a new package for every rebase, which seems like an awkward workflow.
@mortent @justinsb Have we ever considered adding support for rebase onto a different package?

@johnbelamaric don't you see a case where a configuration package can consists of multiple source packages? How do you see that working in the above scheme?

Are you saying sub-packages / an umbrella package? There are two approaches we have discussed for that. One is "static" sub-packages - copying the packages into the umbrella package, simply as sub-directories. The other is the "app of apps" pattern, which is a "by-reference" pattern. Basically, one package contains pointers to other packages (probably via R*Sync objects).
We haven't really sorted out which to use in what situation or what the best practices around these would be. In the static sub-package case, with respect to versioning, the umbrella package revision number has to change whenever any change happens in any sub-package. In the by-reference case, you should still get the same behavior - that is, stability in the contents of the entire umbrella package - because sub-packages cannot be changed without generating a new revision number (and the reference includes the revision number).

@mortent @justinsb Have we ever considered adding support for rebase onto a different package?

So I think we should distinguish between allowing rebase onto a different package, and whether the two resulting PackageRevisions would be part of the same package.
With the way we capture the changes performed on a PackageRevision (for PackageRevisions created and updated through Porch), we do have the information needed to replay the changes. I think it should be possible to replay those on another package, but since we rely on patches it seems like it would be fragile. The rebase-and-replay functionality on different versions of the same package would have the same challenge though.
But that aside, there doesn't seem to be any reason why this couldn't be implemented. I'm thinking this is something an external tool/controller could add, rather than us supporting it directly in Porch.

As for the discussion yesterday around how we should handle deletion of packagerevisions to prevent a deletion from essentially resulting in a rollback, I think it depends on how we consider deployment repositories (non-deployment repos seems irrelevant for this discussion).
If we consider the deployment repos as containing exactly the desired state of the clusters at any point in time (this is the Nephio approach), then deleting the whole package it should be removed from the cluster seems like the right thing to do. Similarly, if a packagerevision is deleted, then you would expect that a different revision will be deployed to the cluster. There are some challenges around this today since we don't have any way to delete a full package and all packagerevisions in one operation, so we should look at how we can handle that.
We have also ideas around a separate rollout controller that would be responsible for updating the desired version for specific packages. In this case, it seems like removing a package from a cluster should be handled by the rollout controller, so deletion from the deployment repo would not be strictly necessary. If a packagerevision in the deployment repo is deleted from underneath the rollout controller, that seems like it should be considered an error situation. Presumably the existing version in the cluster will remain there until the situation is resolved.

This has been implemented. Any follow-ups should be handled in separate issues.


[RDBMS] az mysql flexible-server restore/georestore/replica create: Add public-access parameter for restore, replication and georestore

Related command
az mysql flexible-server restore --public-access
az mysql flexible-server georestore --public-access
az mysql flexible-server replica create --public-access
Description
This PR uses latest Python SDK package which in turn uses the latest GA API version 2022-09-30. This PR will allow customers to enable/disabled public access when creating replica and restore.
Testing Guide
Covered by E2E

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

Thank you for your contribution! We will review the pull request and get back to you soon.

Please fix CLI issues first.

/azp run

/azp run


Bump poetry and pytest Python 3.11 compatibility

Poetry has changed its project configuration schema in recent versions which breaks running tests.
In addition, pytest needs a bump in Python 3.11 because the older release tickles importlib the wrong way yielding a Can't open orphan path error when pytest tries to import hypothesis.

This PR also updates wrapt to version 1.15.0 which is needed for Python 3.11. Any change to merge this any time soon?

Thanks @sjlongland ! Sorry for the delay.


fix title in category list

Closes #55

PR-Codex overview
This PR updates the text label in the CategoriesListHead component from "Поступление" to "Название".
Detailed summary:

Updated text label in CategoriesListHead component.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (d6d0d43) 68.24% compared to head (83f89c3) 68.24%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff            @@
##             master      #65   +/-   ##
=========================================
  Coverage     68.24%   68.24%
  Complexity      149      149
=========================================
  Files            76       76
  Lines          1118     1118
  Branches         89       89
=========================================
  Hits            763      763
  Misses          273      273
  Partials         82       82

Impacted Files
Coverage Δ

...t/src/components/categories/CategoriesListHead.tsx
80.00% <100.00%> (ø)

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


Css medium

solved issue #355

add css in style.css as asked in issue
Additional Context

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


[QA][Sharing NG] ApiTest: list shareByMe and update invite

share invite-related tests covered in https://github.com/owncloud/ocis/issues/7947
shareWithMe covered in https://github.com/owncloud/ocis/issues/7826

[x] shareByMe @SagarGi

[x] listShareByMe (Personal Space ) https://github.com/owncloud/ocis/pull/8285
[x] listShareByMe (Project Space Item ) https://github.com/owncloud/ocis/pull/8306
[x] listSharesByMe (sharing to a group) https://github.com/owncloud/ocis/pull/8345
[x] sharee deleted https://github.com/owncloud/ocis/pull/8450
[x] sharee disabled (forbidden) (not required since shared is list be shareer)
~[ ] listShareByMe (ResharedItem) https://github.com/owncloud/ocis/issues/7939~ We removed the test coverage for resharing (https://github.com/owncloud/ocis/issues/8335)

[x] updatePermission @nirajacharya2

[x] updateExpiration https://github.com/owncloud/ocis/pull/8311
[x] updateRole https://github.com/owncloud/ocis/issues/8131 role are depended on the resource type https://github.com/owncloud/ocis/pull/8329

All of the tests seems to be covered for sharedByMe endpoint. So closing this issue:


DNR: wip: catsrc reconciler tests

cc: @ankitathomas I've added a few more unit test scenarios, and the e2e tests for catsrc controller. Will test it out, cleanup and create a PR.


Can't set workspace-specific default terminal

In one of my workspaces, I need to initialize the terminal with a custom script. VSCode lets me do this, but I can't set this terminal up as the default, because terminal.integrated.defaultProfile.windows can only be set in the application settings.
I consider this behaviour a regression since the previous solution (terminal.integrated.shell & shellArgs) worked perfectly but is now ignored (#123069).

Duplicate of #123031


Clean up nested namespaces

Massive diff is mostly whitespace as I'm condensing namespaces.
This is to be ported forward to main.

diff without whitespace: https://github.com/gazebosim/gz-math/pull/603/files?w=1


feat: note fields in TS artifact

Exposes note fields info in typescript artifact.

Merge activity

Oct 4, 3:09 AM EDT: @benesjan started a stack merge that includes this pull request via Graphite.


fix: Analytics events improvements & Add missing ones

Description
I have removed the extra space after the colon in Payment Events, ensuring consistency with the other analytics.

Add missing events after the parity with the iOS Platform app.
Code improvements to restrict the event triggered against the user action.
Fix test cases.

@dixidroid, please resolve conflicts


[📚] Re-using the Bundle ID to register a new App ID doesn't seem to work

In the Registering an App Identifier section of the docs on setting up FCM via APNs it states that you should copy the existing bundle identifier from your app and use that when registering a new App ID for the push notifications. However, when I do that I get an error about the app id not being available:

This makes sense since I've already published my app using this identifier (com.directangular.sonletretailer, in my case). I'm adding push notifications to an existing app that has already been published to the app store.
Is this a bug in the documentation or am I missing something?

Hi @mgalgs, I found a link to some useful advice on what might be happening here. Closing as this isn't an issue with FlutterFire, but configuration on the iOS platform.


Add Indonesian Brand Name

I have been added Indonesian Brand Name to Commerce Provider. Please review the change

Thank you very much for your contribution, but unfortunately I cannot merge it into the master branch of this repository, as it contradicts the idea of this library as a whole. The main idea of this library is to help in generating fake names for things, while your contribution contains the names of real brands and manufacturers.

Thank you very much for your contribution, but unfortunately I cannot merge it into the master branch of this repository, as it contradicts the idea of this library as a whole. The main idea of this library is to help in generating fake names for things, while your contribution contains the names of real brands and manufacturers.

Thanks for your reply mate...


Git Specify Dir

Hey Chris/team,
I was about to write my own app to do just this but you saved me a ton of time! I want to know (and I couldn’t see any clear answer) if there is a way to specify a directory in git that the files get backed-up to.
In our Git Repo for example we have a folder for Search Heads and another for Heavy Forwarder. If I want to backup just the Heavy Forwarder config’s, I want them to be placed in the HF dir?
Any help would be amazing :)
Thanks

I am not sure I totally understand what you mean regarding having directories that files get backed-up to. This app is a simple automation over normal git.
If you want to track changes in two separate directories, then you can either setup two separate repositories (and two "inputs" in the git_for_splunk app) or you can just have one repo, (at a high parent directory level) then setup .gitignore correctly to only track the directories you are interested in.

I am not sure I totally understand what you mean regarding having directories that files get backed-up to. This app is a simple automation over normal git.
If you want to track changes in two separate directories, then you can either setup two separate repositories (and two "inputs" in the git_for_splunk app) or you can just have one repo, (at a high parent directory level) then setup .gitignore correctly to only track the directories you are interested in.

Hey Chris,
Thanks for getting back to me so quickly. I think I am using git in a kind of un-common way. Let me elaborate.
In our Git Repo currently we have the following folders:
Master Repo:
Splunk
SH
HF
IDX
Other
What I would like to do is on my heavy forwarder, install your app and have it backup to the HF folder in my master repo. So basically, I want to specify the folder it gets backed up to instead of having an entire repo dedicated for the Heavy Forwarder.
I hope that makes a bit more sense.

Hey Chris,
Thanks for getting back to me so quickly. I think I am using git in a kind of un-common way. Let me elaborate.
In our Git Repo currently we have the following folders:
Master Repo:
Splunk
SH
HF
IDX
Other
What I would like to do is on my heavy forwarder, install your app and have it backup to the HF folder in my master repo. So basically, I want to specify the folder it gets backed up to instead of having an entire repo dedicated for the Heavy Forwarder.
I hope that makes a bit more sense.

OK I think I understand. I don't think this is possible though. You would need to use separate repos.

OK I think I understand. I don't think this is possible though. You would need to use separate repos.

Thanks. That’s what I thought but I was hoping away around that.
Thanks for this great Addon!
On Mon, Jan 18, 2021 at 6:43 PM Chris Younger<EMAIL_ADDRESS>wrote:

OK I think I understand. I don't think this is possible though. You would
need to use separate repos.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ChrisYounger/git_for_splunk/issues/8#issuecomment-762516184,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7N7XUWCM5MRXXVADBA7QLS2TBSTANCNFSM4WH2GKKQ
.

Thanks. That’s what I thought but I was hoping away around that.
Thanks for this great Addon!
On Mon, Jan 18, 2021 at 6:43 PM Chris Younger<EMAIL_ADDRESS>wrote:

OK I think I understand. I don't think this is possible though. You would
need to use separate repos.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ChrisYounger/git_for_splunk/issues/8#issuecomment-762516184,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7N7XUWCM5MRXXVADBA7QLS2TBSTANCNFSM4WH2GKKQ
.


Fix app urls

The app URL scheme on the app page is close, but not quite right; it should point to /app/$publicUrl:

Loading apps is also dependent on https://github.com/dxos/dashboard/issues/51.

I know this came up in the status, but I'm slightly confused, because that link looks exactly like how it was described that it should look in the call the other day.
What is the "correct" link and how does one know it?
@AFDudley

The "working" way is linking to /app/$publicUrl as described by @elmasse in this issue: https://github.com/dxos/xbox/issues/72
This may be distinct from the "correct" way. My goal is a working stable build of xbox instead of blocking this deliverable on a new wire app serve.

@ccamrobertson actually not /app/$publicUrl, the publicUrl already contain /app for now till we figure out how to properly set publicUrls bound to the app version urls.

@elmasse Ok, so $publicUrl is currently /app/$name? So really dashboard should just show "$publicUrl" without anything else.


EDU-96 Prefill filters on search results

Resolves: https://educandu.atlassian.net/browse/EDU-96

Test comment

Question, how do we want to handle this case?

Question, how do we want to handle this case?

Not sure what to do in this case, the Musik vs musik is treated by the search algorithm as the same tag, but what to display up there is a bit more tricky, unless we agree on something like "display to lower case all the time".

Question, how do we want to handle this case?

Not sure what to do in this case, the Musik vs musik is treated by the search algorithm as the same tag, but what to display up there is a bit more tricky, unless we agree on something like "display to lower case all the time".

Maybe we can leave it for now and see if it's ever an issue. From my point of view, if we filter by "tags" then we should actually show the tags as they are, otherwise it's confusing that we show the same component, tag-like, but not the same text.


[FLINK-14498][runtime]Introduce NetworkBufferPool#isAvailable() for interacting with LocalBufferPool.

What is the purpose of the change
If the LocalBufferPool can not request available buffer from NetworkBufferPool, it would wait for 2 seconds before trying to request again in a loop way. Therefore it would bring some delays in practice.
To improve this interaction, we introduce NetworkBufferPool#isAvailable to return a future which would be monitored by LocalBufferPool. Then once there are available buffers in NetworkBufferPool, it would complete this future to notify LocalBufferPool immediately.
At the same time, the blocking exclusive buffer requests to NetworkBufferPool will be also notified immediately when there are buffers recycled.
Brief change log

A new interface isAvailable which returns a CompletableFuture is added to the NetworkBufferPool. The future is completed when there are free segments in the pool.
LocalBufferPool will monitor the future returned by isAvailable and will be notified to retry to request MemorySegment from NetworkBufferPool when the future is complete.
Network buffer pool will maintain the state of buffer availability. The future will be transited to uncompleted state when there are no available segments and will be completed once there are available segments.
Two ut cases are added to verify the change.

Verifying this change
Two new ut cases are added to verify the change. One is for the new added isAvailable interface of NetworkBufferPool to verify that the buffer availability is correctly maintained and the future callback is correctly processed. And the other is for the interaction between LocalBufferPool and NetworkBufferPool to verify that blocking requests of multi local buffer pools can be fulfilled by recycled segments to the global network buffer pool.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

I finished reviewing the whole codes and left some comments.
In addition, we also need to cover the test for LocalBufferPool#isAvailable() because we changed the logic there.

Thanks @zhijiangW. I have updated the PR and all the concerns are addressed.

Thanks for the updates @wsry, and the codes are becoming better now. I only left some tiny comments before merging.

Many thanks to @zhijiangW and @pnowojski for the review. I have updated the PR.

Thanks for the updates @wsry and the supplement reviews @pnowojski .
I reviewed the updates and left several tiny comment.

@zhijiangW Thanks for the review. I have updated the PR.

Many thanks to @pnowojski and @zhijiangW for the review. I adopted @pnowojski 's implementation and have updated the PR.

Thanks for the suggestions from @pnowojski and the updates @wsry .
I like the current way in LocalBufferPool and the codes become better now.  I only left several minor comments for the new updates.

I found the new implementation breaks the current BackPressureTracker, because the blocking method stack is changed. Here is the new stack:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
org.apache.flink.runtime.io.network.buffer.LocalBufferPool.requestMemorySegmentBlocking(LocalBufferPool.java:231)
org.apache.flink.runtime.io.network.buffer.LocalBufferPool.requestBufferBuilderBlocking(LocalBufferPool.java:209)

If we keep the max stack trace depth unchanged, then we can change the expected class name to java.util.concurrent.CompletableFuture$Signaller and the expected method name to block.
What do you think @pnowojski @zhijiangW ?

I would just increase the stack depth, CompletableFuture$Signaller is to generic and can mean wainting for something else (for example input availability?). We are going to rewrite the back pressure monitor anyway in the follow up PR.

I have no obvious preference for the options, as long as it would not make worse than the previous backpressure monitor.
A bit concern for the stack depth way, does it bring more memory overhead or this overhead could be ignored? Nevertheless, we would  completely discard the previous monitor way in the following PR.

I adopted @pnowojski 's suggestion and increased the stack depth. Now the PR has been updated and all other concerns are also resolved. @zhijiangW @pnowojski


Usage of InlineValidator is not consistent with other validators, and not documented properly.

Took me some time to figure this out, as the docs at http://www.yiiframework.com/doc-2.0/guide-input-validation.html#inline-validators do not mention this in any way.
The link above specifies an inline method signature as:
/**
 * @param string $attribute the attribute currently being validated
 * @param array $params the additional name-value pairs given in the rule
 */
function ($attribute, $params)

Obviously, we can pass parameters to our inline validator. That's great, except the implementation of that is the same as other validators, and its use is not documented.
With most validators, you put all the parameters in the same array:
['name', 'string', 'length' => [5, 20]],
['version', 'integer', 'min' => 0, 'max' => 1000],
// etc.

With Inline Validators, that will get you nowhere. You instead have to specify a params parameter and nest all your parameters in another array.
['status', 'myStatusValidator', 'params' => ['custom' => 'parameters', 'go' => 'here']],

Suggestions:
Either make this distinct functionality CLEAR in the docs (at present it is completely unmentioned), or modify the behaviour so it is consistent across all validators. The latter could be accomplished in Validator::createValidator by not using $params to hold the object parameters.
    public static function createValidator($type, $model, $attributes, $params = [])
    {
        $objectParams['attributes'] = $attributes;

        if ($type instanceof \Closure || $model->hasMethod($type)) {
            // method-based validator
            $objectParams['class'] = __NAMESPACE__ . '\InlineValidator';
            $objectParams['method'] = $type;
            $objectParams['params'] = $params;
        } else {
            $objectParams = array_merge($params, $objectParams);
            if (isset(static::$builtInValidators[$type])) {
                $type = static::$builtInValidators[$type];
            }
            if (is_array($type)) {
                $objectParams = array_merge($type, $objectParams);
            } else {
                $objectParams['class'] = $type;
            }
        }

        return Yii::createObject($objectParams);
    }

Usage example with the modified code:
public function rules() {
    return [
        /* ... */
        ['map', 'validateClassName', 'class' => 'StarsNT\Ruleset\MapRules'],
 //was: ['map', 'validateClassName', 'params' => ['class' => 'StarsNT\Ruleset\MapRules']],
        /* ... */
    ];
}

public function validateClassName($attribute, $params) {
    if (get_class($this->$attribute) !== $params['class']) {
        $this->addError($attribute, 'Object is of wrong class.');
    }
}

The proposed fix has the issue that $objectParams doesn't contain all possible properties supported by InlineValidator. It also breaks BC.
Considering the fact that you seldom need to pass extra parameters and also for BC consideration, I checked in the doc fix instead.


Show the project avatar if it a valid image is available

What
Some adapters have a project image available, e.g. GitLab.
If this image is set and can be loaded, it will now be displayed on the monitor.

Works like an absolute charm!


Tie break policy in LabelModel.predict()

As per documentation https://snorkel.readthedocs.io/en/v0.9.3/packages/_autosummary/labeling/snorkel.labeling.LabelModel.html#snorkel.labeling.LabelModel.predict while using 'abstain' it should return  [-1] as vote in case of conflict.
In our example, we had explicitly mentioned tie-break-policy as 'abstain'. But I got the following predicted labels using LabelModel.predict(tie-break-policy='abstain).
Label-Matrix                                          Predicted-Label
[-1, -1, -1, -1, -1,  5, -1, -1,  9]	                   9

It is not returning -1 but predicting class as '9'. So we are wondering what is the meaning of tie-break policy argument that we provide in LabelModel.

Hi @durgeshiitj, the tie-break policy only applies if there is a tie between the probabilities of the most probable labels. In your example, the votes 5 and 9 were by two different LFs. If the LF that voted 9 has a higher accuracy than the other, then the probability of 9 will be higher than that of 5, and there won't be a tie to break.


Support of intel packages

I would like to package in a pex, the intel packages of the classic python numerical packages (numpy, scipy, etc.)
Pex seems not able to find the package that provides numpy because the name differs.
Here a simple reproducer:
System description
pex version: 1.6.11
python version: 3.6.3
OS: centos7
Using classic numpy, it works
pex numpy -o numpy.pex
./numpy.pex -c "import numpy; print(numpy.__file__)"
/home/jd.lesage/.pex/install/numpy-1.17.2-cp36-cp36m-manylinux1_x86_64.whl.0833169d405facf4fccb13d37dcbf723d0827c1e/numpy-1.17.2-cp36-cp36m-manylinux1_x86_64.whl/numpy/init.py
Using intel numpy, import fails
pex intel_numpy -o intel_numpy.pex
./intel_numpy.pex -c "import numpy; print(numpy.__file__)"
Traceback (most recent call last):
File ".bootstrap/pex/pex.py", line 397, in execute
File ".bootstrap/pex/pex.py", line 329, in _wrap_coverage
File ".bootstrap/pex/pex.py", line 360, in _wrap_profiling
File ".bootstrap/pex/pex.py", line 445, in _execute
File ".bootstrap/pex/pex.py", line 484, in execute_interpreter
File ".bootstrap/pex/pex.py", line 535, in execute_content
File ".bootstrap/pex/compatibility.py", line 81, in exec_function
File "-c ", line 1, in
ModuleNotFoundError: No module named 'numpy'

Alrighty - intel-numpy is an exceedingly odd package:
$ unzip -l intel_numpy-1.21.5-cp39-cp39-manylinux2014_x86_64.whl | grep numpy/__init__.py
    16819  2023-11-30 14:03   intel_numpy-1.21.5.data/data/lib/python3.9/site-packages/numpy/__init__.py
   133925  2023-11-30 14:03   intel_numpy-1.21.5.data/data/lib/python3.9/site-packages/numpy/__init__.pyi

It stuffs the code in data directories instead of at the top-level. This will never work with a traditional PEX, but things do work in --venv mode though:
$ pex intel-numpy --venv -o intel_numpy.pex && ./intel_numpy.pex -c "import numpy; print(numpy.__file__)"
/home/jsirois/.pex/venvs/440b59b00eab62a3ec204417f71948250dfe5db1/108a3ddc84230ab282ea6312e06cb68f51008ce5/lib/python3.9/site-packages/numpy/__init__.py:164: UserWarning: mkl-service package failed to import, therefore Intel(R) MKL initialization ensuring its correct out-of-the box operation under condition when Gnu OpenMP had already been loaded by Python process is not assured. Please install mkl-service package, see http://github.com/IntelPython/mkl-service
  from . import _distributor_init
/home/jsirois/.pex/venvs/440b59b00eab62a3ec204417f71948250dfe5db1/108a3ddc84230ab282ea6312e06cb68f51008ce5/lib/python3.9/site-packages/mkl_fft/_numpy_fft.py:206: SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif norm is "forward":
/home/jsirois/.pex/venvs/440b59b00eab62a3ec204417f71948250dfe5db1/108a3ddc84230ab282ea6312e06cb68f51008ce5/lib/python3.9/site-packages/numpy/__init__.py

In general, building a pex with --venv prepend --venv-site-packages-copies will net you a runtime environment most compatible with what even atypical distributions expect. The cost is a slightly slower cold boot, but then faster runs from then forward. You can use PEX_TOOLS=1 intel_numpy.pex venv --compile --site-packages-copies right/here to explicitly turn the PEX file into a venv as well if, for example, you're building a Docker image from it.

@jdlesage I'm going to close this as an answered question. The Pex --venv functionality did not exist in 2019, but it has now for several years and is generally what you want. You may also want to investigate --sh-boot.


SLAS Add Client: --tenant option ignored

A user reported an issue to support (see Slack thread) where they were getting the following error message when adding a SLAS client:

Failed to lookup secret SFCC_SCAPI_TENANTID

Although the --tenant option was provided, the tool seems to be expecting the tenant ID to come from an environment variable. If the environment variable is needed and it is not set, it should be set to the value of the --tenant option.
Also, the error message doesn't seem to accurately describe what's going on.

It would help to get a test of this with the latest version. I am not able to replicate


Use fastapprox for fast math calculations

http://fastapprox.googlecode.com/svn/trunk/fastapprox/src/fastonebigheader.h
We definitely want to use fast log in the rankers. We also probably want to use fast exp in some learning algorithms.

merged in PR #84


Stuck on installation in docker " Running setup.py bdist_wheel for opencv-python: still running..."

Hi
I am trying to install the Auto-editor in docker, but it seems stuck in installation
---> Running in 6fad3ef125b0
Obtaining file:///auto-editor
Requirement already satisfied: audiotsm2 in /usr/local/lib/python3.7/dist-packages (from auto-editor==20.53.1) (0.2.1)
Collecting numpy==1.19.3 (from auto-editor==20.53.1)
  Downloading https://files.pythonhosted.org/packages/ec/b7/59f5e75e4f2c9c07b7e651d2ef7502354b254d73bec8c68df30a2d243c9f/numpy-1.19.3-cp37-cp37m-manylinux1_x86_64.whl (13.4MB)
Collecting opencv-python (from auto-editor==20.53.1)
  Downloading https://files.pythonhosted.org/packages/30/46/821920986c7ce5bae5518c1d490e520a9ab4cef51e3e54e35094dadf0d68/opencv-python-<IP_ADDRESS>.tar.gz (88.9MB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
Requirement already satisfied: requests in /usr/local/lib/python3.7/dist-packages (from auto-editor==20.53.1) (2.25.1)
Requirement already satisfied: youtube-dl in /usr/local/lib/python3.7/dist-packages (from auto-editor==20.53.1) (2020.12.31)
Requirement already satisfied: chardet<5,>=3.0.2 in /usr/local/lib/python3.7/dist-packages (from requests->auto-editor==20.53.1) (4.0.0)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.7/dist-packages (from requests->auto-editor==20.53.1) (2020.12.5)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in /usr/local/lib/python3.7/dist-packages (from requests->auto-editor==20.53.1) (1.26.2)
Requirement already satisfied: idna<3,>=2.5 in /usr/local/lib/python3.7/dist-packages (from requests->auto-editor==20.53.1) (2.10)
Building wheels for collected packages: opencv-python
  Running setup.py bdist_wheel for opencv-python: started
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...
  Running setup.py bdist_wheel for opencv-python: still running...

can you help? I have been tried too many ways but opencv-python is not going to install

I should tell you the installation done after almost 1 hour! but it's done :)
Sorry for taking your time


Refactor Nerdlet use of Platform and Nerdlet StateContext

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


delay scene init until document active

fixes https://github.com/excalidraw/excalidraw/issues/1919
Not sure if this is 100% tight and won't cause issues elsewhere.
Someone please test on Safari using the steps outlined in the issue https://github.com/excalidraw/excalidraw/issues/1919 this can't actually be tested in the preview because share links aren't supported there.
@tomayac thoughts?

(Sorry for the delay, I was OoO.)
Maybe forcing the window focus manually via Window.focus() might help? Else, the delay workaround from the PR looks fine, too. Note that instead of removing the event listener after it has fired, you can also use the once option.

No problem. Good point about the once option. As for window.focus(), that won't work (I tested). If browser allowed to programmatically focus tabs, it would defeat the purpose.

I'm gonna merge this, and create a crbug when I get the chance because I think this can cause problems for many apps, and where the solutions wouldn't be as clear cut as this one.

No problem. Good point about the once option.

Cool.

As for window.focus(), that won't work (I tested). If browser allowed to programmatically focus tabs, it would defeat the purpose of the interventions that cause the OP issue ITFP.

Yeah, fair.


Improve documentation

The project README currently contains only the GitHub-generated content.  It needs to be finished to include:

[x] An introduction describing the goals of this project.
[x] A roadmap of where further documentation can be found.
[ ] A high-level system architecture diagram.
[x] A "further reading" section.
[ ] Define an ADR to capture security decisions.

Consider using Mermaid class diagrams as a substitute for deployment diagrams.


tests: Implement behavior tests

Fix https://github.com/datafuselabs/opendal/issues/8
Signed-off-by: Xuanwo<EMAIL_ADDRESS>

Maybe it's better to migrate to rspec instead. But I think this PR is a good start to make our test run.


Risk
We're now upserting data for folders and need to grab parents, this may have a performance impact
Deploy Plan
deploy connectors

but did you check all operations on GoogleDriveFiles / GoogleDriverFolders?

Yes, all upserts and deletes. I've just moved the upsert that was in folder to move in markFolderAsVisited to be more consistent (I first added in syncFiles, but was actually called mutiple times)

Thanks for the work and deep dive, much needed uniformization here 👍 Left a few questions, and we need to be extra cautious on the recursive cached getParents Relatedly, checking you did retest locally after your new changes with a few parents situations?

yes, did retest (full/incremental), parents are now in valid order

👍 🙏 (with note to backfill wrong order tables as mentioned)

Creating a dedicated task for that : https://github.com/dust-tt/dust/issues/9250


Every text centered after error

After this error:

if you go back via the back button in the browser every text is centered on every page and doesn't change (only after reload with Ctrl + F5):

As
user
I want to
see the page in all its beauty, even after something went wrong
In order to
get the full amazing workshop and event experience


Add /dashboard/lists and /dashboard/claims routing

Overview
To split work on #547 from work on #517 this PR sets up some routing for /dashboard/lists and /dashboard/claims routes, with the claims routes behind a feature flag. It also adds some placeholder components for each route.

add /dashboard/lists and /dashboard/claims routing
add placeholder DashboardLists and DashboardClaims components to
disentangle work on viewing contributor lists from work on viewing
facility claims
add routing & links on main Dashboard components to lists and claims,
placing the claims route behind a feature flag

Connects #517
Demo
feature switch:

with feature switched off:

with feature switched on:

/dashboard/lists:

/dashboard/claims:

Testing Instructions

serve this branch, ./scripts/manage resetdb, ./scripts/manage createsuperuser, then sign in to the app as your superuser on 6543 and visit /dashboard
if you haven't turned the feature flag for claim a facility on, you should only see the lists link on the dashboard page. Clicking it should take you to the placeholder component and update the route to /dashboard/lists
with the feature flag still turned off, visit /dashboard/claims directly and verify that you just see the main dashboard page again
turn the CLAIM_A_FACILITY switch on in the django-admin, save the change, then refresh /dashboard/claims. You should now see the claims placeholder component
visit /dashboard again and verify that you now see two links, both of which work

Checklist

[ ] fixup! commits have been squashed
[ ] CI passes after rebase
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines

Oops, I just realized that the alternative prop for FeatureFlag doesn't exist in develop yet because it is still on #540. I'll bring that into this.

9accec5 pulls the alternative prop for FeatureFlag in.

With the feature flag turned off, going to /dashboard/claims shows the regular dashboard, but the URL is not updated:

Can we make it redirect to /dashboard?

Can we make it redirect to /dashboard

I'd prefer not to have it redirect -- the /dashboard/claims behavior with the feature flag off is how it'd work with any other random route, too, like /dashboard/hello since the last Route in the Switch statement catches all nonmatches by virtue of not having a path declared. It'd probably possible to have /claims redirect, but the other routes still won't.

how it'd work with any other random route, too, like /dashboard/hello since the last Route in the Switch statement catches all nonmatches by virtue of not having a path declared

Oh hmm. That's a little confusing. As a user I expect the URL routes to be meaningful, and if parts of it don't apply then to have they discarded. Changing this behavior from our routing system is outside the scope of this card, and I agree in its presence we shouldn't make a one-off redirect. But ideally the URL would faithfully represent the current state of the application. I'll make a card for it.

But ideally the URL would faithfully represent the current state of the application.

Makes sense. I think we can accomplish this by:

replacing the defaults for current Switches with declared, specific paths with an exact prop
generally adding the NoRouteMatch component as the new default, non-path/non-exact case

Cool -- thanks for testing this!


Unity.Abstractions Dependency (again)

Since the UseUnityContainer extension takes a IUnityContainer as an argument, I need to declare my UnityConatiner as that interface. But I'm getting the error, that version v3.3.1 of Unity.Abstractions needs to be referenced to use the IUnityContainer interface.

Nevermind, I just had weird references in my project.


not working

webui has updated gradio 3.23, the UI interface has changed and cannot be used normally

Yeah this update today broke a LOT of extensions, I'm working on a fix now

Hi, Am wondering if there is any update on the fix for this?


Learning page update - typo in 'making a stack configurable'

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Affected area/feature

On the learning page (https://www.pulumi.com/learn/building-with-pulumi/stack-outputs/
) in the section “Making a stack configurable” the pulumi config set is wrong. The variables are each indicated with “_”, but in the code - or the previous lesson - the variables are camelCase.
This causes the pulumi up to fail with reference to missing variable definitions.

@nimbinatus is this something you can take a look at?

Yep, this is something I can fix. We must have missed it in the PulumiUp updates


Q: Is there a shorthand to get the first invalid element?

Hi,
I'm trying to get the first invalid element in case "validateAll" returns false.
I've found a workaround which is basically get the first item of "errors" (id) and then find the element on fields and it kinda works. Except that the order is not the DOM order so it's tricky sometimes.
Is it possible right now to accomplish this in a more straightforward way?
Thanks!

Embarrassingly, there is no way to do that in the current API. But I believe this should be easy to implement.

Nice, thanks!
Also, not sure if it's easy, but right now I have a problem with my workaround: basically, sometimes the "first" is not the first element on the DOM... maybe because of the way fields are added to $validator? Not sure if it's related to vee-validate but it would be cool to have that as well.
Thanks once again 💪

have you tried this.fields.find(field => field.invalid)?


ciao-launcher: Skip already unmapped volumes and improve logging

The cfg.Volumes slice contains all the volumes used by the instance -
both those that have been attached after boot and those specified on the
qemu command line.
The volume specified on the command line will be unmapped by qemu when
it is terminated and so those do not need to be explicitly unmapped.
This patch queries the mapped images on the node and only tries to unmap
those that are mapped.
Signed-off-by: Rob Bradford<EMAIL_ADDRESS>

Debugging #1009 showed up this issue with unmapping already unmapped volumes.

Coverage decreased (-0.03%) to 66.781% when pulling 694f0db427330d051533bc53a5b99d5dc716d8bd on rbradford:launcher-unmap-mapped into db44985c53e304a381523c9b7d4d1e5bb64f4c79 on 01org:master.

@markdryan ready for review now with the alternative approach we discussed.

Coverage decreased (-0.02%) to 66.771% when pulling 287d4c248998d37745c6eb3e3d1b8e7d48d05895 on rbradford:launcher-unmap-mapped into fe47dd351a7dabb1497d610fc357d1718e5da1f5 on 01org:master.

Coverage decreased (-0.02%) to 66.771% when pulling 287d4c248998d37745c6eb3e3d1b8e7d48d05895 on rbradford:launcher-unmap-mapped into fe47dd351a7dabb1497d610fc357d1718e5da1f5 on 01org:master.

Coverage decreased (-0.01%) to 66.775% when pulling 287d4c248998d37745c6eb3e3d1b8e7d48d05895 on rbradford:launcher-unmap-mapped into fe47dd351a7dabb1497d610fc357d1718e5da1f5 on 01org:master.

currently trying to verify this but looking at the code this commit will break containers

I was able to verify this.  The volume is still mapped on the compute node after the container to which it is attached is deleted.


Silvers chat post - Changed Comments path, Update on Cloud function tests

Updates on Comments
Updated Cloud Function for forum functions.

Please also merge this on Silvers after approval:
https://github.com/thruthesky/silvers/pull/3


Some settings in shell_plus

I've made some changes to shell_plus to make it support autoload aliases and skipping modules autoloading.
This comes after being annoyed by all the models you never want to see in big projects. And some models having name collision with apps sharing the same names.. If this is not accepted, please give me some feedback of what is missing for going into the project.

I agree, and if somebody has a real need for it there always free to make there own patch right :)
Also thanks for updating the docs.


Pulsar allows creating duplicate topics with the same name

Describe the bug
Pulsar 2.5.0 allows creating two topics (one partitioned, and the other non-partitioned) with the same name through Admin API. This behaviour is consistent across both persistent and non-persistent topics.
To Reproduce
Steps to reproduce the behavior:

Create a partitioned topic in a tenant/namespace (e.g. persistent://public/test/duplicate-test)
Create a non-partitioned topic in tenant/namespace by the same name as above

Expected behavior
Aamin API should return HTTP 409 with the following response, like it does if the order of steps above is reveresed:
{
    "reason": "This topic already exists"
}

Additional context
It does not allow topics with duplicate names as expected when reversing the order of steps above (create non-partitioned topic first, and then try to create partitioned topic by the same name. Response with HTTP 409 as described above)
Additionally, both topics do exist and show up in their respective list API calls. When trying to publish messages to the topic, they always seem to be received by the partitioned topic. If partitioned topic is removed, the publish still succeeds, and the messages go to the non-partitioned topic by the same name.

@deltasquare4 thank you for reporting this. Are you interested in contributing a fix?

This issue is fixed by #5943 and I have double-checked on the master branch. So close this issue first, if the problem is still there, please reopen it.


lastest bpftrace need -lstdc++fs

Hi,
The lastest bpftrace master need -lstdc++fs, current env not supported.
I found libc++fs is available on Android R AOSP source code(external/libcxx).
also available in projects/llvm/sources/libcxx.
So, use libc++fs instead of libstdc++fs?
Do you have any suggestion?
Very thanks

So there are a few things we could try.
std::filesystem will be supported in ndk r22, at least according to this issue: https://github.com/android/ndk/issues/609. But we're on r17 here for a reason (r18 removed gcc and libelf does not build with clang). Plus it's not obvious whether std::filesystem will be available on all the platforms we support (API 28+). The best way forward would be to move to r22 (if that works), but it won't happen soon.
Another way is to do what you suggest. We can compile our own libc++ as you suggest and link against that. It seems that we should be able to set ANDROID_STL to none to prevent ndk from providing its own stl.
I wonder whether we can do something quick to unblock you sooner. How much of libstdc++fs do we actually need ? Maybe we can just define our own filesystem header and define absolute and canonical functions in terms of realpath ?

I just pushed 2b28f5ef9e87b6a9d17801b3f6c460e7b0cf95a1 which updates version of bpftrace to current master. @b-ripper: does it solve problems you run into ?

Yes, thanks very much!


HHH-16514  test demonstrating issue with DDL generation

results from PK columns getting sorted, but FK columns not

6468


Scala 2.12 support

...for core and reporter, no sbt 1.0 plugin

@dwijnand Are you up to review this since you'd probably the one to continue working on the sbt 1.0 support?

I'm afk until Scala Days. So if you're happy with waiting that long I'm happy to review this.