feat: Add git-only mode

Resolves #1144. Based off of @ozgunozerk's work in #1497.
Adds the ability for release-plz to use the git tags created during the release process to determine already published versions of packages, rather than relying on the registry. This is required for release-plz to work with packages that are never published to any registry, such as standalone closed-source applications.
Caveats

The git_tag_template must remain the same forever when using this feature. As noted in https://github.com/release-plz/release-plz/pull/1872#issuecomment-2519131781, other parts of the code also seem to be relying on this assumption, so we should consider making this assumption explicit until we find a workaround.
This feature is incompatible with setting git_tag_enable to false, since it relies on the existence of git tags to determine published versions.

Tasks

[x] Use git tag template (git_tag_name) to identify tags for each package

[x] Figure out what to do in the situation where old releases had a different tag name template (would require checking out the release-plz config file at each potential release tag and using the tag name template from the checked out config file) - see https://github.com/release-plz/release-plz/pull/1872#issuecomment-2519495429

[x] Checkout tree at the time of the tag/release to use as "downloaded" package
[x] Ensure the "downloaded" packages work well with the diff algorithm
[x] Write tests

[x] release
[x] update
[x] release-pr

[ ] Warn user when git_only is true and git_tag_enable is false
[ ] Rename git_only config option to something else. Options:

git_tags_as_published_versions
git_tags_provide_published_versions

[ ] write docs (added by Marco, I can do it if you don't want to).

💪 let me know when you want me to take a look 👍

Hey, I know this in draft mode, but maybe my feedback is still useful to you.
I tried out your changes, but ran into issues because the repo I use mixes different tagging schemes

rust crates are tagged as {{ package }}-v{{ version }}
there are some other tags for non-rust related things as well (both of the form {{ package }}-v{{ version }}, and {{ version }}).

With your current implementation, some of these unrelated tags get picked up instead, which might not contain any of the rust packages when checked out. If I understood your approach correctly, you try to find the latest git tag (in general), check out the repository at that tag, and then use the checked out repository as the manifest path, correct? I'm pretty sure this can easily desync, since you check out any latest version, instead of the latest version of a specific package.
I tried out an alternative approach (inspired by yours) in my fork: for each package marked as git_only release-plz searches for tags that match that package's tagging scheme (instead of any matching tag), and then adds a git worktree for that specific version. In my testing this worked quite well (though the code is proof of concept only, and needs cleaning up). In case this is useful to you @eviltak , feel free to copy (and/or ignore) as much of my version as you want.
P.S.: I'm not sure what the etiquette is for jumping onto a draft PR like this is, so if I overstepped I apologize in advance 😅

Thanks for the references @PigeonF! The contents of this PR are currently simply what were included in #1497 - the issues you have outlined are known (https://github.com/release-plz/release-plz/pull/1497#issuecomment-2185000159), and I have code locally that addresses the issue. I wasn't using git worktrees to check out the different package manifests at the time of release as I am not familiar with them, but they may end up working than the approach I had planned.

@MarcoIeni While writing tests for this feature I noticed that the release command does not work without a specified git client, even if we disable the creation of git releases. Besides the git release creation process, I noticed that the git client is only being used to retrieve PR contributor information, and to check if a release PR was merged. It looks to be pretty straightforward to skip these two things in the absence of a configured git client - do you think it would make sense to allow this behavior? It shouldn't impact normal operation - it would just let you release packages (i.e. create git tags and run cargo publish) in the absence of remote git repositories (which, for example, is what my test relies on).

You can have a look at the integration tests of release_plz crate to see how to have a remote repository.
We use gitea for that.
Sorry for the brief response. Let me know if it's helpful or you still need more help

I managed to figure out a way by using a local repo as the upstream, and a GitHubMockServer to mock the GitBackend. I have a few more tests I want to add, but otherwise this PR should be ready for you to start taking a look at!
While you review, I'd love to hear your thoughts on what to do in the situation where old releases had a different tag name template (the second task in the PR description). The current implementation would simply ignore the old release tags generated using the old template(s). My hunch is such a change would lead to update not being able to find the latest release after such a change, which would in turn lead to it not incrementing the version (potentially causing a subsequent release to re-release the same version), but I haven't actually tested what would happen. I shall write a test to see what happens in this scenario and check for expected behavior (regardless of whether we choose to handle this case or not).
If we were to handle this situation correctly, it would require checking out each version of the release-plz config file at each potential release tag and using the tag name template from the checked out config file. This can be a bit tricky because the config file parsing code is entirely in the CLI release-plz crate, and not the core release-plz library crate. There are other ways to do this, but they all would require the core library being able to parse config files.
While investigating this, I also noticed that other code (for example here and here) seems to implicitly rely on the assumption that the git tag template  never changes: they also always use the current tag template to reference older tags, and do not consider the possibility of an old release having a different tag template. If this is the case, then it might be worth making that assumption (along with any potential side effects of violating it) explicit in the documentation.

Thanks, I'll have a look asap!
I think for this pr we can assume the tag template never changes for simplicity, yes.
Fyi, Another reason why the tag template might change is when the project moves from single package to workspace.
We can merge this and open a new issue when we try to address the tag name problem. Not sure what the solution might be there.

I just tested this PR in a private repo, and it works 🎉 (though I do not publish any packages to a registry, so I did not test the interaction between git_only and non-git_only packages).
The only thing that is counter-intuitive when running release-plz release is that git_only is a bit of a misnomer:
In order for the package to be considered, the Cargo.toml has to set package.publish = true (or to some registry). However, setting workspace.package.git_only in release-plz.toml still tries to publish to crates.io. This means that in order to only publish git tags, and not to any registry, one has to

Set package.publish=true in Cargo.toml
Set workspace.package.git_only=true in release-plz.toml
Set workspace.package.publish=false in release-plz.toml

I think this should be noted in docs somewhere, because (as a non-native english speaker) the name git_only made me think that release-plz would not try to publish to a registry. Alternatively, git_only could override publish in this case (but this might also be surprising), or release-plz could pick up packages that have package.publish=false set in Cargo.toml, but workspace.package.git_only set in release-plz.toml.

I think we still want to have package.publish = false. That's a safety measure to avoid publishing the package to a registry.
Probably if git_only = true we should also consider packages with publish = false.
Release-plz shouldn't attempt to publish to a registry if git_only = true imo.

release-plz could pick up packages that have package.publish=false set in Cargo.toml, but workspace.package.git_only set in release-plz.toml.

exactly 👍

You bring up a great point @PigeonF. I shall modify the code so that both release and update consider git_only packages as publishable, and add tests to verify that crates with publish = false in their Cargo.toml work in git_only mode.
To that end, I do believe that we should use a more descriptive config option name than git_only. Something along the lines of treat_git_tags_as_published_versions, while more verbose, makes the implication of setting that option a lot clearer. Open to any suggestions!

I agree that git_only is a bad name.
publish_git_tag_only? Open to suggestions as well 😂

I think publish_git_tag_only is a bit of a misnomer, since it implies that the option limits release publishing to git tags only, which is not the case. The option makes release-plz use git tags to determine published package versions versus retrieving them from the registry, so IMO it doesn't make sense for it to imply that it affects publishing (since the current implementation does not affect publishing).
I am rewording my previous suggestion to git_tags_provide_published_versions. If no one has any objections or better suggestions by the time I finish the other pending tasks in this PR, I shall proceed with renaming the option to it.

I will chime in as I'm interested in the PR, if naming is one of the last remaining tasks 😅.
I like your suggestion, I'd change only 1 thing:
git_tags_as_published_versions
But again, I'd rather see the feature implemented than argue about the naming so if @MarcoIeni likes your suggestions I'm also up for it.

I will chime in as I'm interested in the PR, if naming is one of the last remaining tasks 😅.
I like your suggestion, I'd change only 1 thing:
git_tags_as_published_versions
But again, I'd rather see the feature implemented than argue about the naming so if @MarcoIeni likes your suggestions I'm also up for it.
Edit: another option is to just use what cargo is using.
publish= false
or
cargo_publish = false

it implies that the option limits release publishing to git tags only, which is not the case.

So with this option set, you still publish to crates.io?
Maybe it can be confusing.
What's the use case where somebody wants to use git tags to determine the next published version, but still publish to crates.io?
The only one I can think of is if someone has a private registry and doesn't want release-plz to access it.
Another design choice we could do is forcing people to set publish = false in the Cargo.toml, so that people don't publish by mistake to crates.io.
Another option is force people to set the publish field (not sure if possible to verify if the publish field is set to true from cargo metadata).
I'm interested in hearing the opinion of everyone involved in this PR 👍
Btw, I might have some time to review this pr this weekend 👍

Edit: another option is to just use what cargo is using.
publish= false
or
cargo_publish = false

We already have something like this in our config.
It disables cargo publish.

Yes, if publishing is enabled for that crate/workspace.

What's the use case where somebody wants to use git tags to determine the next published version, but still publish to crates.io?
The only one I can think of is if someone has a private registry and doesn't want release-plz to access it.

One other scenario where this would be useful is if someone wants to publish only some released versions of a package to a registry. Selectively publishing versions with release-plz without modifying the config file may not even be possible today, but it is possible that a command-line argument is added to the release command in the future to skip publishing versions for selected packages (overriding the config file).
I agree that in almost all cases (like my intended use case for this feature), if you want to use git tags to determine the next published version you will only be publishing to git tags and not the registry. However, since the feature does not rely on this implication at all to function correctly (and works irrespective of whether you publish to a registry or not), I am in favor of keeping the separate option (with a better name) without tying it into the publish option.

Another thing I just noticed: for obvious reasons, git_tag_enable = false is incompatible with git_only = true. What is the recommended way to show such an incompatibility to the user?
I think this is severe enough to be considered an error; I can check this condition and return an error when the release command checks the git tag enabled condition, but is there a better place to do this, such as in the config schema or in a config validation routine?

Another thing I just noticed: for obvious reasons, git_tag_enable = false is incompatible with git_only = true. What is the recommended way to show such an incompatibility to the user?
I think this is severe enough to be considered an error; I can check this condition and return an error when the release command checks the git tag enabled condition, but is there a better place to do this, such as in the config schema or in a config validation routine?

As far as I know, in such a scenario it would be better to use an enum instead of 2 Boolean fields. Maybe that will solve the whole question of naming the config?
I'm not sure how release-plz currently handles such compatibility where configuration value is changed from boolean to a different type, however, I though I would share this idea.

Answers

One other scenario where this would be useful is if someone wants to publish only some released versions of a package to a registry.

true, but very rare, I think I've never seen an example of this. I can see release-plz not supporting this use case since it's very rare. For this case, people could just run cargo publish when needed (also because workspace support for cargo publish is progressing).

Selectively publishing versions with release-plz without modifying the config file may not even be possible today, but it is possible that a command-line argument is added to the release command in the future to skip publishing versions for selected packages (overriding the config file).

It's not possible, yes, but as I said above I don't see a strong case for it 🤔
Proposal

I am in favor of keeping the separate option

Ok, what about "forcing" users to take the decision? I.e. forcing people to set the publish field of the Cargo.toml.
Pro:

If they want to keep this package away from crates.io, they set publish = false, which is a best practice
If they want to publish the package when using git_only it's a weird decision, so we want them to explicitly say so by setting publish = true.

Of course the con is that people need to update their Cargo.toml, but at least they do this to follow a best practice (setting publish = false).
Implementation detail of proposal
Unfortunately, cargo_metada doesn't distinguish between publish = true and the publish field being absent (publish is None in both cases), so we would need to read the Cargo.toml file.
git_tag_enable
The enum elpiel proposed is an option we can think about in the future. For now, let's keep things as they are to keep the size of this pr reasonable 👍
We can validate that the two fields are compatible here, so that we fail very early.
eviltak, if you prefer to have the enum in this pr, we can have it of course 👍

I'm not sure how release-plz currently handles such compatibility where configuration value is changed from boolean to a different type, however, I though I would share this idea.

We would need to release release-plz version 0.4 because it's a breaking change, but it's not an issue, since I haven't shipped a breaking change in years 😂

In my opinion it doesn't make sense to combine git_only and git_tag_enable into one enum option. Though the former option is dependent on the latter, the latter is completely independent of the former. I also am not sure what we would call the amalgam of these two options.
However, if we decide to enforce not publishing to a registry when using this feature (which I am completely fine with), we can take another approach (inspired by @elpiel's suggestion) that will solve our naming woes:

Eliminate the git_only option
Make publish an enum, with three variants (open to suggestions on naming): Registry, GitTagsOnly, Disabled
Enable this feature for all packages that have publish == Publish::GitTagsOnly
Override the value of git_tag_enable and always push tags  if publish is set to GitTagsOnly (this could also be a config validation error, as discussed eariler)

If we choose to go with this approach, it might be worth taking it a step further, which in my opinion will both improve naming and prevent a breaking change to the release-plz config schema:

Create a new config field, publish_to, which describes the target (registry, git tags or nothing) to publish packages to and is set to the enum as described above
Mark the publish field as deprecated and map publish = false to publish_to = Disabled (might rename Disabled to None or similar) and publish = true to publish_to = Registry if no value for publish_to is specified

What a great idea, I like it but I would like to give it some thoughts!

(this could also be a config validation error, as discussed eariler)

I would prefer this 👍
A good reason to deprecate publish is because it's easy to confuse release-plz publish and Cargo.toml publish.
Let me think about publish_to a bit more. I have doubts because Registry also implies "git tags", while GitTagsOnly doesn't imply "registry". What if tomorrow we introduce a new publish strategy, e.g. a POST to an endpoint (I just made this up)? Maybe individual booleans make more sense 🤔🤔🤔🤔

I got to thinking about this problem a bit more, and I believe I  have found a good approach inspired by my previous suggestion that should simplify things a lot. I am going to post below a (perhaps long-winded) description of my understanding of the problem, which will hopefully convey the reasoning behind my suggestion.
Background
Conceptually, release-plz supports a set $T$ of $N$ publish "targets". Based on the configuration, we publish each package $p$ to a subset $T_p \subseteq T$ of these targets (if $T_p$ is empty, we do not publish the package in any form).
In order to determine the next version of a package $p$, we must look up the latest version of that package published to any target in the set $T_p$ (i.e. the latest version of this package retrievable from any source) . In most cases, the published version would be the same in all targets, but in some cases (e.g. if a new target was added to the set $T_p$ recently) there may be a discrepancy. We thus pick the latest version published to any target to avoid re-publishing already published versions to a target.
What release-plz does today
Today, the set of supported targets $T$ consists of 3 targets: publishing to a registry, git tags, and git repository releases, and the set $T_p$ of targets we publish package $p$ to is determined by the config options publish (for the registry), git_tag_enable (for git tags) and git_release_enable (for git releases). In the future, $T$ could have an additional target, like sending a custom POST request to a server.
However, release-plz currently only supports looking up the latest version of a package published to the "registry" target; which means that we cannot retrieve the latest published version of packages that aren't published to a registry (but may be published to git tags and/or git releases and/or any other form of publishing that is added in the future).
This PR
This PR aims to address part of that problem - support for retrieving the latest versions of packages that aren't published to a registry, but are published to git tags. However, it does so by introducing a binary (exclusive OR) alternative to fetching latest published versions from a registry (enabled by the git_only option). This means that a package has to choose whether to retrieve its latest version from the registry or git tags; as we discuss below, this need not be the case.
What release-plz (and this PR) should be doing
As discussed in the Background section above, for a package $p$, rather than fetching latest published versions from a specific target (e.g. registry vs. git tags), release-plz should retrieve the latest version from all targets in the set $T_p$, and use the latest of all those versions.
In the context of this PR, this would mean getting rid of the git_only option altogether. Furthermore, when fetching the latest version of a package $p$, we would do the following:

If the package has publish = true (i.e. is published to a registry):

Fetch the latest version registry_version (if any) from the registry

If the package has git_tag_enable = true (i.e. is published to git tags):

Fetch the latest version tag_version (if any) from git tags

Return the latest (greater) version between registry_version and tag_version

This allows release-plz to automatically support packages that are not published to a registry (but are published to git tags) without having the user manually set an option.
In the case where a package has an older version published to the registry and a newer one published to a git tag (or vice versa), we pick the latest tag version because if we chose the older registry version, we would end up overwriting the git tag (or attempting to overwrite a version already published to the registry) after the version increment.
In the future
Note that even with this PR, retrieving published versions from the third currently supported publish target (git releases) is unsupported. In other words, release-plz will not be able to determine the latest published version of a package that is only published to git releases. This might be worth adding in the future
It might also be worthwhile considering a refactor to add a PublishTarget abstraction with an enum and/or a trait that looks like the following:
trait Target {
    async fn publish(&self, package: &Package) -> Result<()>;
    async fn fetch_latest_package(&self, package: &Package) -> Result<Option<Package>>;
}

struct Registry {
    // All publish_* config options
}

struct GitTag {
    // All git_tag_* config options
}

struct GitRelease {
    // All git_release_* config options
}

// Could use #[enum_dispatch]
enum PublishTarget {
    Registry(Registry),
    GitTag(GitTag),
    GitRelease(GitRelease),
}

This allows publish_to to be an array of the targets you wish to publish a package to (in code, a Vec<PublishTarget>).
fn release(package: &Package) {
    // ...
    for target in &package.config.publish_to {
        target.publish(package).await?;
    }
}

fn next_version(package: &Package) {
    let mut latest_package: Option<Package> = None;
    for target in &package.config.publish_to {
        let target_latest_package = target.fetch_latest_package(package).await?;
        if latest_package.map(|p| p.version) < target_latest_package.map(|p| p.version) {
            latest_package = target_latest_package;
        }
    }
}

I like this approach a lot because we don't need to edit our configuration to introduce this new feature. Thanks for taking the time to think about it!
I just have a few thoughts.

In the case where a package has an older version published to the registry and a newer one published to a git tag (or vice versa), we pick the latest tag version because if we chose the older registry version, we would end up overwriting the git tag (or attempting to overwrite a version already published to the registry) after the version increment.

To make this change less disruptive for existing release-plz users, if publish = true I will keep the existing behavior (where the registry takes precedence over the git tags in picking the next version), and maybe log a warning that says that there's a git tag with a newer version. We could always tweak this later if needed 👍
If publish = false we should pick the latest between git tags and registry. One might think that if publish = false we can completely ignore the registry version. However, release-plz users who have publish = false, run cargo publish manually or in other ways today. So we should expect that they publish the version to the registry.
After this PR, there will be people who use publish = false to achieve the git only functionality.
In the future
For git releases, I'm not sure if it's worth adding, because I would expect the same info to be available in git tags. Let's see if somebody requests this and why.

This allows publish_to to be an array

Let's keep the booleans for now I would say. We can discuss switching to publish_to in another issue 👍
Regarding the refactoring, feel free to do whatever you want 👍
Just be aware of the size of the PR. Nothing stops you from sending other PRs after we merge this one to do additional improvements.
Again, thanks a lot for pushing this forward, I really like that you bias towards providing solutions rather than asking questions 🙌


configure SSO-Clients by an config file (or environmrnt variable)

if i see it correct, everything is managed with the admin ui ...

I don't get it why someone would want to do that.
That doesn't make any sense to me.
We would you want something like that?
A little bit more input would be nice...


Access response in custom Link

I appreciate this may be better as a question on StackOverflow, but figured it might have more visibility here. I am trying to access the response headers in a custom link, but the FetchResult always has a null context. Am I trying to do something unsupported here? Thanks.

Nevermind, user error!

@leesus was this because you were accessing the context before waiting for a response? If you don't mind posting your solution it would be helpful for others as an example


Relaunching ElectronPlayer Netflix Multiple Tabs Bug

Some of the options require restarting ElectronPlayer to apply due to how Electron works. If you start playing a show on Netflix and then enable an option that requires the restart eg. frameless window or Mac Picture in Picture, It will restart and put you back on the same page as you previously had open but Netflix will show an error saying "Multiple Netflix Tabs". A simple reload of the page removes the error and allows you to continue watching your show.
@Scrumplex I thought I see if you have any ideas on what to do to fix this.

If I had to guess, it's because it is restarting too fast and Netflix hasn't figured out by then, that the old stream has been closed. We should either try to gracefully close Netflix somehow or just have a restart delay

This has been fixed now. Instead of restarting the entire application I now just destroy and recreate the browser window which doesn't cause the bugs and is also much faster due to it just resetting the browser window state and not exiting the entire application.


Packaging DBLPParser

What do you think about making this a package?
If you need help with that, let me know :-)

See https://github.com/WolfgangFahl/dblpconf

See https://github.com/WolfgangFahl/dblpconf


CoreCLR support

CoreCLR support PR for more visibility / build status / merge status.
This is work in progress, mostly by @phenixdotnet (thanks!!)
See for discussion: https://github.com/NLog/NLog/issues/641
todo:

[ ] fix net45 test
[ ] fix coreCLR tests
[ ] Fix compilationOptions of CoreCLR (dotnet5.4) -> remove UWP10 + NET4_5
[x] include net40 build
[ ] include xamarin builds
[ ] To netplatform (when CoreCLR RC2 has been released)
[ ] fix assembly FILE version.
[ ] fix UWP build (nuget dependencies packages weren't working yet)
[ ] fix .cake for Travis (build.sh)
[x] all tests are failing for dotnet5.4?
[x] add SL4 + SL5
[x] add wp8

build
Helper
build.cmd -Configuration Debug

With DNU
build from dnu:
dnu restore --quiet
dnu build src/NLog --quiet

Nuget packages:
dnu pack src/NLog --quiet

Current coverage is 73.14%

Merging #1160 into master will decrease coverage by -0.23% as of 6d195b3

@@            master   #1160   diff @@
======================================
  Files          265     265
  Stmts        14958   14979    +21
  Branches      1639    1624    -15
  Methods          0       0
======================================
- Hit          10976   10956    -20
- Partial        418     419     +1
- Missed        3564    3604    +40

Review entire Coverage Diff as of 6d195b3

Uncovered Suggestions

+0.08% via ...nternal/AspHelper.cs#206...218
+0.08% via ...nternal/AspHelper.cs#188...200
+0.08% via ...nternal/AspHelper.cs#170...182
See 7 more...

Powered by Codecov. Updated on successful CI builds.

build from dnu:
dnu restore --quiet
dnu build src/NLog --quiet

and nuget
dnu pack src/NLog --quiet

@phenixdotnet I fixed the .cake and DNU version. There was a mistake with the version and target for the unit tests in the .Cake file.
TODO

[ ] fix .cake for Travis (build.sh)

An error occured when executing task 'sl5'.
========================================
pack

@phenixdotnet any idea what this error is about?
Is this related? (maybe we can disabled nlog.unittests.web)

Running unit tests in project .\tests\NLog.UnitTests.Web
Error: Unable to load application or execute command 'test'.
An error occured when executing task 'net35'.

Any error logs ?
No I don't thinks it's related.
I don't know if the tests\NLog.UnitTests.Web is really under dev in the coreclr ;)

Do you know if It the Travis problem is a cake or unit test problem?   NLog.Extensions.Logging does run on Travis

The Travis build fail because travis use an unsupported version of linux. We can try to force travis to build on mac os x ?

I update the .travis file to use osx.
The project build but unit tests failed (as expected ^^)

Thanks!
I did not expected errors. Unit tests should succeed in dotnet5.4 and net451

fix net45 test

What is the failure here? I can help with this.

Wel try to run on appveyor. See branch coreCLR+test.  Help would be appreciated! Please test in a separate branch

fix Travis (build.sh)

@304NotModified, should it be considered fixed by 086ff66?

fix assembly FILE version.

Can you elaborate on this one? If this is about AssemblyInfo and still an issue, I can give it a try.. :)

Since #1592 was merged as "Squash and merge", this PR is still showing conflicts with master (as the original merge commit and yet commits from master are squashed); coreCLR branch would require another merge with master.

@304NotModified, should it be considered fixed by 086ff66?

I think it does :)

Can you elaborate on this one? If this is about AssemblyInfo and still an issue, I can give it a try.. :)

Sure, two things:

The assembly file version is now fixed (it should be from AppVeyor)

We are missing info in netstandard1.5 (but maybe it's a NPE bug)

netstandard1.3 is correct:

Since #1592 was merged as "Squash and merge", this PR is still showing conflicts with master (as the original merge commit and yet commits from master are squashed); coreCLR branch would require another merge with master.

Oops, sorry about that. If you have time for this, please, otherwise I will fix it probable this week

I cloned NuGetPackageExplorer and debug the netstandard1.5 issue and it doesn't seems like the bug in NPE, but with Assembly.GetCustomAttributesData throwing at CodeExecutor/AppDomainWorker.cs#L64:

 {"Could not load file or assembly 'System.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.":"System.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"}	System.Exception {System.IO.FileNotFoundException}

So far, steps to reproduce are:
mkdir \temp
cd \temp
git clone https://github.com/NLog/NLog --single-branch -b coreCLR --recursive
cd NLog
dotnet restore
dotnet build src/NLog -f netstandard1.3 -c Release
dotnet build src/NLog -f netstandard1.5 -c Release

Then create an additional application to test assembly loading:
mkdir \temp\test-asm
cd \temp\test-asm
dotnet new

Replace Program.cs with:
using System.Reflection;

public class Program
{
  public static void Main(string[] args)
  {
    Assembly.Load
    (
<EMAIL_ADDRESS>        // change 1.5 to 1.3 and won't have any exception thrown
    )
    .GetCustomAttributesData();
  }
}

and project.json with:
{
  "buildOptions": { "emitEntryPoint": true },
  "frameworks": { "net45": { } }
}

Would be nice if we could narrow the issue down and make a self-contained example for coreclr issue tracker. I can't reproduce, for example, with assembly produced by new lib project: dotnet new -t lib && notepad project.json && dotnet restore && dotnet run and having netstandard1.3 and netstandard1.5 simultaneously in the project.json.

cool! thanks, looks like something is wrong with the nuspec maybe

@304NotModified Maybe we should create a new branch from master (ex coreclr2), and then fix that to support NetStandard13 + NetStandard15 + NetStandard20.
But maybe wait until we have a NLog 4.5 BETA ready.

@304NotModified Maybe we should create a new branch from master (ex coreclr2), and then fix that to support NetStandard13 + NetStandard15 + NetStandard20.

Well I'm thinking of dropping NetStandard13+NetStandard15 support. Too much legacy.

But maybe wait until we have a NLog 4.5 BETA ready.

Yes, I prefer that at least.

4.5 will have .NET standard 2 support. These changes won't be merged to master


[Impeller] inline the second blur pass into the parent render pass.

Right now, the second pass of the blur is rendered into a texture and then that texture is composited onto the entity pass that consumes the blur. By adjusting the positioning UVs, we could actually perform the second pass of the blur in the entity pass without another intermediary texture. This will reduce memory usage, as well as reduce the overhead of texture fill operations: https://github.com/flutter/flutter/issues/142154 .We've done similar things for other filters, for example see: https://github.com/flutter/engine/pull/40973

FYI @gaaclarke

Here is a CPU profile of that benchmark.  CPU usage is >80% and 20% of that time is in creating render passes so eliminating render passes sounds promising.

As a hack I disabled the second render pass and that gets us to 60fps on my phone.  Since we aren't GPU bound I think that's a fair approximation of this change.

Its not clear to me if we're CPU or GPU bound on iOS. Its possible there are some odd backpressure mechanisms in the Metal API. But on Vulkan devices we are absolutely bound by GPU.

Its not clear to me if we're CPU or GPU bound on iOS. Its possible there are some odd backpressure mechanisms in the Metal API. But on Vulkan devices we are absolutely bound by GPU

I have local changes right now or I'd show you but if you choose that screen on Xcode that shows the dial it has a bar graph of cpu vs gpu.  In that breakdown it is attributing almost everything to the cpu, not the gpu.
here

I think that is mostly driver work also there are allocations and bzero/memset calls associated with creating a render pass.


Fix typos in api-opentelemetry.asciidoc

What does this PR do?

Checklist

[ ] This is an enhancement of existing features, or a new feature in existing plugins

[ ] I have updated CHANGELOG.asciidoc
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Added an API method or config option? Document in which version this will be introduced
[ ] I have made corresponding changes to the documentation

[ ] This is a bugfix

[ ] I have updated CHANGELOG.asciidoc
[ ] I have added tests that would fail without this fix

[ ] This is a new plugin

[ ] I have updated CHANGELOG.asciidoc
[ ] My code follows the style guidelines of this project
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I have updated supported-technologies.asciidoc
[ ] Added an API method or config option? Document in which version this will be introduced
[ ] Added an instrumentation plugin? Describe how you made sure that old, non-supported versions are not instrumented by accident.

[ ] This is something else

[ ] I have updated CHANGELOG.asciidoc

@fml2 Thanks a lot for your contribution, as this was already reviewed and approved, all you have left is to sign the CLA before we can merge this.

I can't get through the procedure. I seem to accomplish it but it does not work. Feel free to just make those changes yourself.

Thanks @fml2 it seems you have properly done it, so maybe there was a glitch and the CLA check is OK, which means we can merge.


[Idea] Combine and adapt DryIoc source directly into DI.MS.DI

Pros:

no dependency
ability to reference DI.Abstractions to support e.g. ISupportRequiredService on Container
add other MS.DI things in performant way (not sure about this)

To messy to keep 2 versions. What if something want to use MefAttributeModel which is relying on DryIoc - now we have 2 sets of DryIoc things and the ambiguous errors everywhere.


[Lab Notes] ToC anchor links not working

Where:

https://franklin.moleculardevices.com/lab-notes/cellular-imaging-systems/advanced-technology-for-automated-3d-biology-workflows-slas-europe-2022#compound_screening_and_high_content_imaging
https://franklin.moleculardevices.com/lab-notes/cellular-imaging-systems/advanced-technology-for-automated-3d-biology-workflows-slas-europe-2022#organ_on_a_chip_assay
https://franklin.moleculardevices.com/lab-notes/cellular-imaging-systems/7-tips-for-optimizing-your-3d-cell-imaging-and-analysis-workflow#Usemicroplates

Table of content anchor links don't go to the expected sections.

@duynguyen i think this is the same as #602 wdyt? We have a specific solution for the hero already but since that links can be everywhere we should have a generic solution.

Actually I checked the links again. This must be fixed in content. The hash value is wrong/old since Franklin has a different rule for I’d generation.

The importer must be able to find out where the hash link is linking to (that should be possible if it is on the same page), get the (heading) content, generate a new hash and rewrite the link.


Feature request: Lazy load plugin

Does this feature exist in Emacs orgmode?

[ ] Yes
[ ] No
[x] No idea

If answer to first question is "No", elaborate on how this feature is valuable and what problem does it solve.
This is probably a complicated ask, but is it possible to lazy load this plugin, for example with packer like this
use {"kristijanhusak/orgmode.nvim", ft = "org"}
The ft command I get is tricky as you set ftdetect from within the plugin. But perhaphs some otherway like a command like orgInit() that can be used to initialize/lazy-load?
...
Additional context
Add any other context or screenshots about the feature request here.

@austinbostonberlin I believe you can do this in packer by using keys or events, e.g.
use {"kristijanhusak/orgmode.nvim", event = {"BufReadPre", "BufEnter *.org"}, keys = {"<leader>oa"}

FWIW though I started out down this path but if you run PackerProfile you'll find that orgmode.nvim has a vanishingly small startup time (2ms) on my mac and <1ms on my linux machine, so I believe however the plugin is structured it is already very cheap to load so lazy loading is an unnecessary optimisation for now 🤷🏾♂

@akinsho summarized it pretty well. I was watching for the startup time to be as lowest as possible, and org files are loaded and parsed only after you initiate any of the actions (agenda, capture, BufEnter org).  Because I had a lazy-load similar to what @akinsho described (except without the keys argument) and it somehow messed up treesitter folding for other filetypes. Strange
But since it is so fast and semi-lazy loaded by itself I wont go that route either!

Ok. Closing then. Thanks for reporting anyway.


Missing JMX options to connect to the instance

I know JMX is discouraged, Jolokia is available, but this image is very handy to simulate a standalone installation.
However there is a missing part in the documentation about being able to connect to the Artemis via JMX. I am not sure if this should be a part of the image/runtime config:
 -e JAVA_OPTS="-Dcom.sun.management.jmxremote.local.only=false \
               -Djava.rmi.server.hostname=`ipconfig getifaddr en0`"

The hostname is resolved to the wireless adapter IP address via the ipconfig command on my Mac. Not sure about a more generic approach.
With this option among with forwarded ports we were finally be able to connect to the instance via JMX:
docker run -it --rm --name=artemis \
  -e ARTEMIS_USERNAME=devuser \
  -e ARTEMIS_PASSWORD=pass \
  -e ENABLE_JMX=true \
  -e BROKER_CONFIG_NAME=dev_artemis \
  -e JMX_PORT=2099 \
  -e JMX_RMI_PORT=2099 \
  -p 8161:8161 \
  -p 61616:61616 \
  -p 2099:2099 \
  -e JAVA_OPTS="-Dcom.sun.management.jmxremote.local.only=false \
                -Djava.rmi.server.hostname=`ipconfig getifaddr en0`" \
    vromero/activemq-artemis:1.5.6

I confirm the configuration above also works for me.
I am not knowledgeable enough about automatically adding the JAVA_OPTS. The current documentation mentions Kubernetes, and I cannot figure out how would Kubernetes access the container's JMX w/o the aforementioned options, maybe it can, but again, don't know much about Kubernetes either.
One thing I am almost sure is to include the BROKER_CONFIG_NAME parameter explicitly in the documentation. This is required to get external JMX access, because the default is random.

On second thought, maybe leaving the hostname=<IP_ADDRESS> in the documentation makes more sense: The user might install the docker on another machine (not the same host), and try to access externally. I am not sure localhost -> remote_docker_host -> artemis_container scenario would still work with <IP_ADDRESS>.

<IP_ADDRESS> should work, it means all addresses in all network interfaces, which works great for docker to avoid the need of predicting the ip address provided to the container.
I'm thinking on perhaps adding an `-e JMX_ALLOW_REMOTE=true' that would add those two parameters. Will think a bit more about it and then in a few days implement.

i happened to be looking at jmx today as well, just a couple other notes.

it probably also makes sense to expose 1099 & 1098 inside the dockerfile as well
<IP_ADDRESS> doesn't work for me if I want to connect via jmx using the dns entry of the external vip.  so in my case to get it to work i have to put the java.rmi.server.hostname=vip_dns_name.   With this in mind, it might make more sense to have a variable such as JMX_HOSTNAME which defaults to <IP_ADDRESS> but can be overriden when needed.   Although simply using JAVA_OPTS works well also.

Yeah so in my experience (and I might be wrong) <IP_ADDRESS> only works for localhost connections, I'm surprised it even works in docker but it does. The reason why it acts wacky is that there are two connections, the first one for jmx and then it reconnects using RMI to whichever is the ipaddress configured there, and <IP_ADDRESS> randomly (or at least non-deterministically) picks one. I have no solution for this, no-one seems to have and that is why I and pretty much everybody recommends jolokia over JMX in docker.
Passing the ip address with bash tricks and so on its not acceptable imho and very platform dependent.

jmx is still useful if you want to use jconsole/visualvm, passing the external dns name to java.rmi.server.hostname works fine in this case.

yes, hence my doubt. I guess I could add a JMX_HOSTNAME env defaulted to <IP_ADDRESS> and document very clearly the use case.
It is also arguably also that tanuki and the hawtio console are more than enough.

I have decided to ignore this for the time being, I don't want to support randomized ports within Docker at the moment. Might revisit later but not for now.


Uncaught Error: Already created an embed

I'm trying to embed Kleki into the next Js project but getting this error
Uncaught Error: Already created an embed

code:
`
if (typeof window !== "undefined" && typeof window.Klecks !== "undefined") {
const klecks = new Klecks({
onSubmit: (onSuccess, onError) => {
console.log(klecks.getPNG())
klecks.getPSD().then((blob) => {
console.log(blob)
});
            setTimeout(() => {
                onSuccess();
            }, 500);
        }
    });
    if (psdURL) {
        console.log("in psdUrl")
        fetch(new Request(psdURL)).then(response => {
            return response.arrayBuffer();
        }).then(buffer => {
            return klecks.readPSD(buffer); // resolves to Klecks project
        }).then(project => {
            klecks.openProject(project);
        }).catch(e => {
            klecks.initError('failed to read image');
        });

    } else {
        klecks.openProject({
            width: 500,
            height: 500,
            layers: [{
                name: 'Background',
                opacity: 1,
                mixModeStr: 'source-over',
                image: (() => {
                    const canvas = document.createElement('canvas');
                    canvas.width = 500;
                    canvas.height = 500;
                    const ctx = canvas.getContext('2d');
                    ctx.save();
                    ctx.fillStyle = '#fff';
                    ctx.fillRect(0, 0, canvas.width, canvas.height);
                    ctx.restore();
                    return canvas;
                })(),
            }]
        });
    }
}

`

So far I've made no effort to support React/Next.js. I'd be surprised if it works out of the box. You need to be careful to not execute Kleck's initialization logic twice. Also Klecks has no destructor yet.
At some point I will look into this.


Ping servers and get alerts when they are down.

Script Title - Pinging Websites
A new script will be added which will ping websites and/or servers as required automatically and alert a list of users via mail if the servers ever go down.
Instructions

[x] Adding New Code

Programming Language

[x] Python

Hi @codePerfectPlus
I have an automated script for this. Please add hacktoberfest-accepted label and assign this to me.

Hi @codePerfectPlus
I have added the script file along with instructions on how to use it in the README.md.
If you have any queries, do get back at me.


When will the new version of velero v1.10.0+ be supported

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
支持 velero v1.10.0 及以上。目前只支持v1.9.0版本
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:

Velero version: (use ark version):  v1.10.0
Kubernetes version: (use kubectl version): v1.19.3
Kubernetes installer & version: v1.22.15

Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):

@hanyan007 Is there any problem? I am currently trying to use version 1.11 of Velero for testing backups.

Same question as hanyan007, will the server image be updated? The latest velero version is 1.14 now.
And I got the same warning that is "Please update server"

I got error "Error: unknown flag: --uploader-type" with version v1.4.2, any advice?

We'll update soon, apologies for the delay update.


Debugger improvements, and Logger development.

Extract Logger from the debugger. We need the logger in release mode as well to log errors and such. Maybe put conditionals on the info and trace functions and remove the log message type variable. In addition, some kind of information gathering dump function would be needed to help with error debugging. This should be provided by the context.
Move the debugger and logger threads start functions to the module start rather than the context start so that Context.IsRunning can be used.

Extract Logger from the debugger.
Done
We need the logger in release mode as well to log errors and such.
Done.
Maybe put conditionals on the info and trace functions and remove the log message type variable.
Somewhat done.
Move the debugger and logger threads start functions to the module start rather than the context start so that Context.IsRunning can be used.
Done


fix(dataZoom): prevent movement when zooming

This pull request is in the type of:

[X] bug fixing
[ ] new feature
[ ] others

What does this PR do?

prevent moving when chart is scaled to  minSpan/maxSpan and moveOnMouseWheel = false
Fixed issues

#16144
Details
Before: What was the problem?

After: How does it behave after the fixing?

Document Info
One of the following should be checked.

[X] This PR doesn't relate to document changes
[ ] The document should be updated later
[ ] The document changes have been made in apache/echarts-doc#xxx

Misc
ZRender Changes

[ ] This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs
N.A.
Others
Merging options

[ ] Please squash the commits into a single one when merging.

Other information

@gooroodev review

1. Summary of Changes
The pull request modifies the behavior of the dataZoom feature to prevent movement when zooming. Specifically:

It changes the scale variable from const to let to allow for reassignment.
It adds a conditional check to determine if the scale should be set to 1 based on the minimum and maximum span constraints.
It ensures that the range values are adjusted only if the conditions for the minimum and maximum span are not violated.

2. Issues, Bugs, or Typos in Code

Issue: The scale calculation logic could be more readable and maintainable.
Improvement Proposal: The conditional check and scale reassignment could be refactored for clarity.

Improved Code (Refactoring for Readability):
let scale = Math.max(1 / e.scale, 0);

// Restrict range.
const minMaxSpan = this.dataZoomModel.findRepresentativeAxisProxy().getMinMaxSpan();

const isZoomingIn = scale < 1;
const isZoomingOut = scale > 1;
const isMinSpanReached = range[1] <= minMaxSpan.minSpan + range[0];
const isMaxSpanReached = range[1] >= minMaxSpan.maxSpan + range[0];

if ((isMinSpanReached && isZoomingIn) || (isMaxSpanReached && isZoomingOut)) {
    scale = 1;
}

range[0] = (range[0] - percentPoint) * scale + percentPoint;
range[1] = (range[1] - percentPoint) * scale + percentPoint;

sliderMove(0, range, [0, 100], 0, minMaxSpan.minSpan, minMaxSpan.maxSpan);

this.range = range;

3. General Review of Code Quality and Style

Variable Declaration: Changing scale from const to let is appropriate for reassignment.
Conditional Logic: The added conditional checks are necessary to ensure that the zooming behavior respects the minimum and maximum span constraints.
Code Readability: The refactored code improves readability by breaking down complex conditions into well-named boolean variables.
Code Style: The code follows a consistent style, but readability can be enhanced by using descriptive variable names for conditions.

Overall, the changes are well-targeted and improve the functionality as intended. The proposed refactoring further enhances the clarity and maintainability of the code.
Yours, Gooroo.dev. To receive reviews automatically, install Github App


Validate mapping files against required fields in json schema (all objects)

The transformation scripts should protest if a mapping does not provide either of the following

a mapped legacy field
a static value

for a property that is required according to the object schema.

@branchedelac  I believe I have done this. The only exception is the theoretical case of a nested object like this:
{
    "myObj": {
        "title": "Something",
        "myObjectProperty": {
            "property1": "something",
            "property2": ""
        }
    }
}

What about "myObjProperty" was not required, but "property2" is. Could that ever happen?

What about "myObjProperty" was not required, but "property2" is. Could that ever happen?
@fontanka16 Perhaps in a case where myObjProperty can be excluded, but if it is there it must contain property2.
So this would be ok
{
    "myObj": {
        "title": "Something",
    }
}

And this
{     "myObj": {         "title": "Something",         "myObjectProperty": {             "property1": "",             "property2": "something"         }     } }
but not
{     "myObj": {         "title": "Something",         "myObjectProperty": {             "property1": "something",             "property2": ""         }     } }
but perhaps (compare https://github.com/FOLIO-FSE/migration_acquisition_tool/issues/7)
{     "myObj": {         "title": "Something",         "myObjectProperty": {             "property1": "something"         }     } }

@fontanka16 I am having issues getting this to work in the acquisitions branch for this array of objects:
        "phoneNumbers": {
            "id": "phoneNumbers",
            "description": "The list of phone numbers for this organization",
            "type": "array",
            "items": {
                "type": "object",
                "$ref": "phone_number.json",
                "$schema": "http://json-schema.org/draft-04/schema#",
                "description": "A phone number record",
                "properties": {
                    "id": {
                        "description": "UUID",
                        "$ref": "../../common/schemas/uuid.json"
                    },
                    "phoneNumber": {
                        "description": "The entire sequence of digits for this phone number",
                        "type": "string"
                    },
                    "categories": {
                        "id": "categories",
                        "description": "The list of categories for this organization phone",
                        "type": "array",
                        "items": {
                            "type": "string"
                        }
                    },
                    "type": {
                        "description": "The type of this phone number",
                        "type": "string",
                        "enum": [
                            "Office",
                            "Mobile",
                            "Fax",
                            "Other"
                        ]
                    },
                    "isPrimary": {
                        "description": "Used to set this phone number as primary for the contact",
                        "type": "boolean"
                    },
                    "language": {
                        "description": "The language for this organization phone",
                        "type": "string"
                    },
                    "metadata": {
                        "type": "object",
                        "$ref": "../../../raml-util/schemas/metadata.schema",
                        "readonly": True
                    }
                },
                "additionalProperties": False,
                "required": [
                    "phoneNumber"
                ]
            }
        }

Could we write a test around that?

@branchedelac ping me tomorrow and let's write a test.

I was thinking that's what I should do. It turned out the culprit was a typo in the example organization mapping file! 🙀


v1 changes

zqwl -> yaml
tasks -> steps
type -> language

@max-radin what branch shall we use for the imports?

Other revisions:

Renaming steps using underscore convention + propagating changes in testing workflows
Updating branch of testing workflows to "dev"
Updating README to v1 (I left the final sentence on daemon, but might be worth removing it since it's not in v1 yet @max-radin ?)


Emoji in old commits

So we recently switched from gitbucket to gogs because gitbucket was using far too much resources.
After the "migration", (changed all origin urls to the new gogs system and pushing it). I noticed that emojis don't work for older commits. This commit is not the newest one (The newest is 3 commits newer)

Same emoji in an issue comment:

does it work on any commit? or just not on older ones?

What is your version of Gogs?

Newest self-compiled source ;).
We didn't tested it yet with newer commits. But the old ones are definitely not working.

OK, reproduced here: https://try.gogs.io/unknwon/issue-2390

I think it is caused by bug https://github.com/Ranks/emojify.js/issues/154

=).  But at least we know now where it comes from..

I'm thinking handle this directly in Go...

The emoji conversion? I thought you'd already do this. But after I looked I noticed you're not. It would certainly be better to convert it directly and just send the emoji url to the page.

convert it directly and just send the emoji url to the page.

Yes, agree.

So If a couple guys from us are implementing it, where do you think should we put it? As 3rd party library (I'm not a fan of this idea.), in the template.go file, or as a seperate module in the modules folder?

Actually, I'm going to implement as 3rd party library because somewhere else is using empjify.js and met the same problem...

I'd have a look at this: https://github.com/shurcooL/github_flavored_markdown/issues/1 :smile:

It's not just markdown, but everywhere... needs something more general. I've already got some idea.

Sooo. I tinkered with it and the result was.... The emojify.js is either old or broken. The current from the website works!
http://hassankhan.me/emojify.js/javascripts/emojify.min.js

Somehow, https://github.com/gogits/gogs/pull/2738 solved this.

Should be fixed by #2738 : https://try.gogs.io/unknwon/issue-2390

Close as fixed.


CERN Config

Locations: block creation and deletions
Circulation transitions: remove "In transit"

To be completed.

Superseded by https://github.com/CERNDocumentServer/cds-books/issues/80


Add a flag to allow generating custom tokens with no expiry

-1 Dangerous design wise. MITM attacks is the reason we have these expiry tokens in the first place. Additionally, even cryptographically strong sessions are needed to be expired for user/client side safety.

I agree with you about all of these points, of course, this can be dangerous when used with an access token, that's why I mentioned custom tokens.
Adding this option can be handy with custom tokens that are being used with no critical actions like allowing anonymous users to submit their feedback, so instead of creating a token with a long expiry time just to avoid expiry checking, it's better to have the ability to drop this on creating, I can override __init__() to do so but it will be just like copying the complete original implementation and just remove expiry lines, that's why I realized this option should be allowed if wanted.

There is a note from the previous implementation about the exp claim being omitted or "infinite" https://github.com/jazzband/django-rest-framework-simplejwt/blob/cb323efa4644ba74efaf106ad96c80d8449a7006/rest_framework_simplejwt/tokens.py#L84-L100
You've got two options:

You can omit the exp claim: https://github.com/jazzband/django-rest-framework-simplejwt/blob/cb323efa4644ba74efaf106ad96c80d8449a7006/rest_framework_simplejwt/tokens.py#L137-L153

Then write some code like:
def set_exp(self, claim='exp', from_time=None, lifetime=None):
        """
        Updates the expiration time of a token.
        """
# Add this if condition. Try to use "infinite" string literal
# instead of just None to maintain compatibility and avert
# any accidental omission of exp claim
        if lifetime == "infinite":
            return

        if from_time is None:
            from_time = self.current_time

        if lifetime is None:
            lifetime = self.lifetime

        self.payload[claim] = datetime_to_epoch(from_time + lifetime)

def check_exp(self, claim='exp', current_time=None):
    if claim in self.payload:
        super().check_exp(claim, current_time)

Easier but not as recommended: You can make a serializer that only does L96-L100 since the method is only a verification step.

I don't want to implement this in this library. Even though it's allowed by the RFC, in the context of DRF and what this package was designed for (and even though I'm striving to have more extensibility in the library), I don't want others to think like Microsoft (90 day tokens equals no good). Best practices in security is what matters, and that's what the original authors thought too in the comments.

I saw this original comment about zombie tokens when I was reading the source code and I agree with you about all of these points that's why I mentioned custom tokens, not a global variable where someone can use it by mistake.
I was thinking about something like this:
class Token:
    token_type = None
    lifetime = None
    set_expiry_claim = True # or whatever we will call it

then, this flag will be used to control whether or not we will deal with expiry at __init__() and other methods or not, by default it will be true which will be backwards compatible for everyone, but if you wish you will just override this flag and set it to false at your custom token class which inherits from Token.
So, everything will be the same but we are just making extendability more flexible.
I believe that there are many people who are using this package to use JWT with DRF with different needs that's why something like JWTTokenUserAuthentication was added later

I guess I'm mostly confused by what you mean by "custom tokens?" Are you saying we make an ABC abstract class? Or are you saying in the serializer, we pass a callback to allow the dev/server to edit the token however they wish before we send the client an access/refresh token?
Because the way I'm understanding this -- "custom token class which inherits from Token" -- you might consider just subclassing your token class and setting the AUTH_TOKEN_CLASSES settings.
So which of the three or none of the above are you talking about? (sorry)

Yup, I'm just talking about subclassing Token to create my custom token class with my desired token_type and lifetime and use that class later on.

I have written my custom authentication class to authenticate against this custom token class for a special endpoint where anyone with a valid token can access it

I think what you've done is correct. However, bad practices (even with good intentions) inside this package isn't exactly what we're after. Yea flexibility's pretty bad, and we shouldn't follow everything that was said in the past, but I think this is an instance of "eh" -- it could lead to poor decision making and frontend/client design.
BTW JWTTokenUserAuthentication was created so that we never hit the database, not for extensibility sake.

Okay, I respect your decision about this, keep the good work marinating this great package!


does this work with minetest

https://github.com/minetest/minetest

No,
it uses https://github.com/PrismarineJS/mineflayer to connect to the game.
mineflayer supports only regular minecraft protocol and minetest has its own protocol.
Maybe its not too hard to make mineflayer support minetest? I don't know.


fix-core clear block row_same_bit when block reuse

Signed-off-by: nextdreamblue<EMAIL_ADDRESS>Proposed changes
Issue Number: close #16155
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[x] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.27 seconds
load time: 522 seconds
storage size:<PHONE_NUMBER>9 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230128154457_clickbench_pr_85767.html

please add test case

please add test case

done


ActiveTasks when deleting node

Allow me for a vague request...
Assume we have one task (Task A) in the queue. After deleting the Task A, I would think that mean 0 in queue. But actually it still remains in the queue. So at this point even there is only one deleted task, $ActiveTasks shows 1. Only after there is a VM, the deletes are resolved.
Could you clarify this behavior on the document, if possible..?

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

ID: 6d888d2f-3a20-bb80-c600-074089e1d0f9
Version Independent ID: 2d365860-2876-50fe-e075-e89b92520833
Content: Autoscale compute nodes in an Azure Batch pool - Azure Batch
Content Source: articles/batch/batch-automatic-scaling.md
Service: batch
GitHub Login: @Padmalathas
Microsoft Alias: padmalathas

@himachida
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@Padmalathas
Can you please check and add your comments on this doc update request as applicable.

@himachida, thank you for your feedback, that's a good catch.
This is current design limit for Batch Service. The resolution of the pending tasks doesn't occur until there is a VM, at which point the scheduler will then read the queue and resolve the deletes.
The document will be updated with a note to list this current limitation for $PendingTasks.

#https://github.com/MicrosoftDocs/azure-docs-pr/pull/249192

#249192

#https://github.com/MicrosoftDocs/azure-docs-pr/pull/249192

Thank for your feedback, this has been fixed in the documentation and updates are published. Hope this clarifies confusion if any.
Appreciate your contribution to the doc-improvement.
#please-close


Rendering Content without RichTextReadOnly

Describe the bug
I created my editor using CodeSandbox Repo as a reference. Everything works very well. My problem occurs when rendering the HTML code I receive with getHTML().
If I had to give an example, here is the post in editor;

When I render it with the following code it looks like this:
<Box dangerouslySetInnerHTML={{ __html: details.items.content }}

When I render it with RichTextReadOnly it looks like this:

But I don't want to use RichTextReadOnly. I have several reasons for this:

With DevTools, when contenteditable="false" is set to true, the content becomes editable.
When you click on the images, a border is created around them.

Expected behavior
A component that allows the content received with getHTML() or getJSON() to be rendered as in the editor can solve this problem.
System (please complete the following information)

mui-tiptap version: 1.9.2
tiptap version: 2.4.0
Browser: Chrome
Node version: v21.1.0
OS: Windows
Copy-paste your extensions array used for the editor

export default function useExtensions({ placeholder } = {}) {
	return useMemo(() => {
		return [
			TableImproved.configure({
				resizable: true,
			}),
			TableRow,
			TableHeader,
			TableCell,
			BulletList,
			CodeBlock,
			Document,
			HardBreak,
			ListItem,
			OrderedList,
			Paragraph,
			CustomSubscript,
			CustomSuperscript,
			Text,
			Bold,
			Blockquote,
			Code,
			Italic,
			Underline,
			Strike,
			CustomLinkExtension.configure({
				autolink: true,
				linkOnPaste: true,
				openOnClick: false,
			}),
			LinkBubbleMenuHandler,
			Gapcursor,
			// HeadingWithAnchor,
			Heading,
			TextAlign.configure({
				types: ["heading", "paragraph", "image"],
			}),
			TextStyle,
			Color,
			FontFamily,
			FontSize,
			Highlight.configure({ multicolor: true }),
			HorizontalRule,
			ResizableImage,
			Dropcursor,
			TaskList,
			TaskItem.configure({
				nested: true,
			}),
			Placeholder.configure({
				placeholder,
			}),
			History,
		];
	}, [placeholder]);
}

Hi @Jasermon, as mentioned in https://github.com/sjdemartini/mui-tiptap/issues/136#issuecomment-2049890241, getHTML is a serialized representation of your content. While it can be used for display, there are Tiptap extensions where the Tiptap-based rendering of that content will visually differ from the serialized data due to JS-based logic used in rendering (where the serialized content is parsed but the visual representation is more involved).
For your particular extensions, which in general perhaps don't need any additional JS-based logic, you may be able to apply the mui-tiptap styles to your dangerouslySetInnerHTML element via using the getEditorStyles utility from mui-tiptap (e.g. similar to what the mui-tipap RichTextContent component does here).
In general though, if you want your editor and your serialized content to render/look the same, you should let Tiptap do the rendering, which is what RichTextReadOnly is for.

Hi @Jasermon, as mentioned in #136 (comment), getHTML is a serialized representation of your content. While it can be used for display, there are Tiptap extensions where the Tiptap-based rendering of that content will visually differ from the serialized data due to JS-based logic used in rendering (where the serialized content is parsed but the visual representation is more involved).
For your particular extensions, which in general perhaps don't need any additional JS-based logic, you may be able to apply the mui-tiptap styles to your dangerouslySetInnerHTML element via using the getEditorStyles utility from mui-tiptap (e.g. similar to what the mui-tipap RichTextContent component does here).
In general though, if you want your editor and your serialized content to render/look the same, you should let Tiptap do the rendering, which is what RichTextReadOnly is for.

Thanks for your answer. I have no problem using RichTextReadOnly, but I am bothered by the issue of setting the contenteditable prop to true with DevTools.

@Jasermon Your concern is a user changing contenteditable to true via dev tools, and thereby being able to edit stuff they otherwise shouldn't be able to edit? I don't believe there's a way to prevent someone from manipulating the DOM manually/externally to the application. Even if this were preventable via JS, couldn't they also then manipulate the JS? I don't know that there will be reasonable ways to prevent it, but you could try looking through Tiptap's issues and discussions (https://github.com/ueberdosis/tiptap) and/or Prosemirror's to see if anyone else discussed something similar. This sort of thing is outside of mui-tiptap in particular. Good luck!


Use of of older version of repr_offset

https://github.com/rodrimati1992/abi_stable_crates/blob/c52b07897ca27007213154fdd3fbd1e65a714543/abi_stable/Cargo.toml#L54
Should be 0.2.2.
This causes problems because repr_offset 0.2.1 had the silly bug on line 131 of having a semi colon in the code.  Can you push a fix please :-)

Closed by #103


seems vrcompositor hangs on a black screen when using steamVR-openHMD!

Hi there...
Here I am again on my fight to make steamVR work!! LOL
I finally got the vrcompositor to run successfully using the NULL driver from valve, so FINALLY steamVR is running as it should on my arch distro.
Now that it runnning 100% with the null driver, I known the problem is related to this openhmd driver. SteamVR is loading it successfully, showing the HMD icon exactly like yours in the video on YouTube.
BUT, the vrcompositor window is black, and I get a "(unresposive) SteamVR Home" message on the Status window.
After a few minutes, that message disappears and I get a beautiful green "Ready" message instead, but the vrcompositor is still black.
I also get this on the shell at the same time:
CAppInfoCacheReadFromDiskThread took 1 milliseconds to initialize
CApplicationManagerPopulateThread took 78 milliseconds to initialize (will have waited on CAppInfoCacheReadFromDiskThread)
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Steam_SetMinidumpSteamID:  Caching Steam ID:<PHONE_NUMBER>3337696 [API loaded yes]
Steam_SetMinidumpSteamID:  Setting Steam ID:<PHONE_NUMBER>3337696
assert_20180818232128_1.dmp[21812]: Uploading dump (out-of-process)
/tmp/dumps/assert_20180818232128_1.dmp
assert_20180818232128_1.dmp[21812]: Finished uploading minidump (out-of-process): success = yes
assert_20180818232128_1.dmp[21812]: response: CrashID=bp-d621494e-f1b0-48af-a78c-b4d282180818
assert_20180818232128_1.dmp[21812]: file ''/tmp/dumps/assert_20180818232128_1.dmp'', upload yes: ''CrashID=bp-d621494e-f1b0-48af-a78c-b4d282180818''
/ssd/dot_local_share_Steam/Steam/steamapps/common/SteamVR/tools/steamvr_environments/game/steamtours.sh: line 94: 20532 Segmentation fault      (core dumped) ${STEAM_RUNTIME_PREFIX} ${GAME_DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"

The "Frame Timing" window doesn't show anything running either... it's like something is "stuck" during starting up, and can't continue!
Again, with the NULL driver, this doesn't happen... so it must be something related to openHMD or maybe some missing configuration.
I couldn't find anything wrong in the log files, but I'll keep examining then...
My question is: Have you seem this problem before? any insights you can think off?

I was actually wondering if this behavior has anything to do with controller bindings... I've tried to

I have not seen this and don't know what could cause it. Sorry.

One more question... did you setup any special bindings on your setup? I notice there are no bindings and vrcompositor reverts to a default binding file that also has nothing in it.

Do you mean action bindings for the controller buttons? That's missing because I didn't get the button input to work yet. I've tried a bit in a branch called experiments, but I think it's missing something. I don't have nolo controllers currently so I don't have hardware for testing this. I thought I wait for the Vive controller support at least with rotation only before playing more with it, but I could also just simulate some buttons.


 overflows off screen in focus mode on mobile device

When using the UInput component with w-full class on a mobile device, the input focus causes the input element to overflow off the viewport. How can I fix it so it does not do that?
Note: For reference, when using an input component from daisyui.com , this issue does not happen on mobile viewports.
Version
@nuxthq/ui: v2.7.0
nuxt: v3.6.5
Reproduction Link
https://stackblitz.com/edit/nuxtlabs-ui-v7cplu?file=app.vue
Steps to reproduce
I am unsure if you are able to view the stackblitz repo on an iOS mobile device (didn't work for me), so I have copied the same code to my web host: https://modernmedlife.com/test
Works fine on desktop device, but if you view the input on a mobile device, and then touch it (it goes into focus mode), the input will span offscreen (overflow).
Overflowing issue when in focus on mobile device (iOS):
https://drive.google.com/file/d/14blyZjlvsSaZoJZtj_dxjEf2UAOz3fLD/view?usp=sharing
What is Expected?
Should look like this:
https://drive.google.com/file/d/1eE65ODquYvF4gubCczXJNYmY9TmIq5Tu/view?usp=sharing
What is actually happening?
Using the UInput component causes the above issue, but if I swap that out with a daisyUI input component, it works as intended. Is there a NuxtUI configuration for ui classes that need to be adjusted for the UInput component?

This seems to be fixed. May have been an issue with my own code. I'll close this.


OpenHue-CLI Discovery Never Resolves on Windows

At least, I assume it never will, because on Linux, this process finished in half a second, while on Windows, it's still running.
I'm building with go install directly instead of docker.
Everything else about the CLI works fine as far as I can tell, I just had to setup by manually checking and feeding in the Bridge IP address; openhue-cli setup -b <IP_ADDRESS>.
I enabled verbose logging by setting the dev environment variable, but the logs produced don't make it obvious to me what the issue is:
PS C:\Users\Xevion\projects\openhue-cli> openhue-cli discover
time="2024-05-19T00:53:33-05:00" level=info msg="Running in dev mode, logs will be output in the console"
time="2024-05-19T00:53:33-05:00" level=info msg="Running the 'discover' command"
time="2024-05-19T00:53:33-05:00" level=info msg="DNS-SD service '_hue._tcp.local.'"
time="2024-05-19T00:53:38-05:00" level=error msg="Unable to lookup bridge with service '_hue._tcp.local.'. Check error details below:"
time="2024-05-19T00:53:38-05:00" level=error msg="context deadline exceeded"

I waited a few minutes to see if anything else was outputted, but nothing did.

openhue-cli master (c42df59)
go1.22.0 windows/amd64
Windows 10

Hi @Xevion and thanks for reporting this issue.
My main problem in investigating this one is that I don´t have any Windows machine to test with.
Would you be able to run the following command on your side:
dns-sd -B _hue._tcp local.

[!NOTE]
Command found from the Philips Hue Developers documentation

PS C:\Users\Xevion> dns-sd -B _hue._tcp local.
Browsing for _hue._tcp.local.
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
 2:46:23.291  Add     2 20 local.                    _hue._tcp.                Hue Bridge - 98C048

I had to install the Bonjour SDK for Windows from Apple, which was much harder to find than it should be.
FYI for anyone exploring this in the future, you need an Apple ID (standard, no special developer setup/enrollment required).

https://developer.apple.com/bonjour/ (Bonjour for Windows, click Bonjour SDK for Windows, sign-in)
Final link: https://developer.apple.com/download/all/?q=Bonjour SDK for Windows
Install bonjoursdksetup.exe, dns-sd will then be available in PATH.

And actually, after looking into Bounjour, I found that Bonjour Print Services actually does install dns-sd into path (confirmed it).
I looked into Resolve-DnsName as a more readily available alternative, but it doesn't seem to be able to look up service instances (qualified by the -B argument). I also found a npm package, node-dns-sd, and it actually does work pretty well. It has a CLI wrapper, details here: @warren-bank/node-dns-sd-cli.

Hi @Xevion,
I've just released the 0.16, including a few improvements regarding the automatic bridge discovery.
Please let me know if the openhue discover command is now working better in Windows.
Thanks!

Apologies for the latency, but I tested and confirmed that discovery is working on Windows.
PS C:\Users\Xevion\Downloads\openhue-cli> go run . setup
[OK] Found Hue Bridge with IP '<IP_ADDRESS>'
[..] Please push the button on your Hue Bridge
.........
[OK] Successfully paired openhue with your Hue Bridge!
[OK] Configuration saved in file C:\Users\Xevion\.openhue\config.yaml


Notifications: Double notification about post in Timeline.

Circumstances:
User1's timeline will receive posts from himself (Common post - Action №1, Anonymous post - Action №2) and from User3 (Common post - Action №3, Anonymous post - Action №4).
User2 is a friend (follower) of User1.
Results:
Action №1: User2 received only one notification and it looks correctly. There is no retranslation event at all.

Action №2: User2 received only one notification and it looks correctly. Received retranslated event from Profile module.

Action №3: User2 receive 2 notifications and it's incorrect. Received both events: from Timeline and retranslated from Profile module.

Action №4: User2 receive 2 notifications and it's incorrect. Received both events: from Timeline and retranslated from Profile module.

Viewing images note:

CP - Common Post.
AP - Anonymous Post.

Questions:

What is the purpose of retranslated events in Profile modules?
Why do Action №1 have no retranslated event at all while the other actions have?
Why do Action №3 and Action №4 have 2 notifications.
Why do Action №3 and Action №4 have exactly the same notifications.

Related issue was fixed in Ticket #1807


Concurrent mode

Hi!
I couldn't find any information about future React Concurrent mode.
It is there any information/plan for it?

Hey @montogeek 👋 thanks for reaching out.
As of now we don't have any information or plan about concurrent mode.
But I'm keeping an eye on it and will update the docs (and code if needed) when needed!
Thanks!


Is it safe to deploy laravel-echo-server on a public facing server (internet)?

Or should I stick it behind a proxy (e.g. nginx)?

Safe is a relative term :)
I've been running one for months (dockerized). I've done through a proxy (apache) and now directly.
Go for it!
P.S. - as for everything you have on the internet, you'll need to be vigilant (security issues and stuff)

@jorgenb :
I use nginx in front as it makes easier with ssl and also your client don't have to connect to exotic ports.

@catalinux Do you use the same nginx server as your Laravel project or do you use a dedicated server?

Same. You can have your websock path as your app path also , so you don't have to handle any CORS issues

Something like that: https://stackoverflow.com/questions/39310308/how-to-use-laravel-echo-on-production-server-with-https/43047046#43047046

Thanks @catalinux  I was just writing some Nginx config before you posted that. The SO post probably saved me some time since I did not know about WebSocket proxying.
http://nginx.org/en/docs/http/websocket.html


Fixes #1114 - Changed <IP_ADDRESS> to localhost

resolves #1114

Pull Request Test Coverage Report for Build 1448

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 56.122%

Totals

Change from base Build 1439:
0.0%

Covered Lines:
4528

Relevant Lines:
7263

💛  - Coveralls


Error : Use process(css).then(cb) to work with async plugins

I am encountering an issue while using Nativewind. The error message I'm receiving is:
iOS Bundling failed 2061ms error: App.tsx: /Users/..../App.tsx: Use process(css).then(cb) to work with async plugins iOS Bundling failed 125ms error: App.tsx: /Users/...../App.tsx: Use process(css).then(cb) to work with async plugins

here is my package.json
{
  "name": "express-eats",
  "version": "1.0.0",
  "main": "node_modules/expo/AppEntry.js",
  "scripts": {
    "start": "expo start",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "web": "expo start --web"
  },
  "dependencies": {
    "@expo/webpack-config": "^19.0.0",
    "expo": "~49.0.15",
    "expo-status-bar": "~1.6.0",
    "nativewind": "^2.0.11",
    "react": "18.2.0",
    "react-dom": "^18.2.0",
    "react-native": "0.72.6",
    "react-native-web": "~0.19.6"
  },
  "devDependencies": {
    "@babel/core": "^7.20.0",
    "@types/react": "~18.2.14",
    "@types/react-native": "^0.72.8",
    "tailwindcss": "^3.3.6",
    "typescript": "^5.1.3"
  },
  "private": true
}

it looks like there are issues with tailwindcss newer versions from 3.3.3 and above.
I downgraded to 3.3.2 and it worked
yarn remove nativewind
yarn remove tailwindcss
yarn add<EMAIL_ADDRESS>yarn add --dev<EMAIL_ADDRESS>yarn add nativewind

#498


UX Update - Context create and Context use

What this PR does / why we need it
Enhance the context create and context use UX.
Which issue(s) this PR fixes

Fixes #
Describe testing done for PR

Release note

Additional information
Special notes for your reviewer

UX design has changed, hence closing this PR.


Bug: Error comes whenever we type something else then a number

Description:
I encountered an unhandled runtime error whenever i type something else then a number
The error message is as follows :
Unhandled Runtime Error: TypeError: A text for parsing must be a string.
Steps to Reproduce:
i) Click on phone number input box .
ii) Type something other than a number like any letter or even start with a backspace.
iii) You will face error moment you type.
Error Video:
https://github.com/SarthakSKumar/QuickSend/assets/88412712/8a6a4d76-2382-46ce-a119-eaad1f369e59
Possible Solutions:
I was not able to solve error on my own but i believe its due to some conditions in
react-phone-number-input , i  might be wrong . If you have any suggestions or ideas for a possible solution, feel free to share them here.

Please work on one issue at a time. This issue will be assigned on closing #6 @rizul11

Hey @SarthakSKumar
I faced the same issue
@rizul11 created this, But as he mentioned that, he was not solve that error
Assign It to me, I Can figure out the error

Hi @TheCodeVenturer
You can work on the issue.

@SarthakSKumar, why page.js has 100+ lines of code commented?
Do i remove it?

@SarthakSKumar, why page.js has 100+ lines of code commented? Do i remove it?

Sorry my bad coding habits


scikit_bring_your_own local test

When running through the scikit byom example, I hit an error when trying to run the local test..
$ ./serve_local.sh e7ea36fc1eda
Starting the inference server with 4 workers.
[2018-07-25 13:43:08 +0000] [10] [INFO] Starting gunicorn 19.9.0
[2018-07-25 13:43:08 +0000] [10] [INFO] Listening at: unix:/tmp/gunicorn.sock (10)
[2018-07-25 13:43:08 +0000] [10] [INFO] Using worker: gevent
[2018-07-25 13:43:08 +0000] [15] [INFO] Booting worker with pid: 15
[2018-07-25 13:43:08 +0000] [16] [INFO] Booting worker with pid: 16
[2018-07-25 13:43:08 +0000] [17] [INFO] Booting worker with pid: 17
[2018-07-25 13:43:08 +0000] [18] [INFO] Booting worker with pid: 18
/usr/local/lib/python2.7/dist-packages/gevent/builtins.py:96: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  result = _import(*args, **kwargs)

wondering if I could just ignore it I opened another terminal and tried to make a prediction
$ ./predict.sh payload.csv text/csv
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 8080 (#0)
> POST /invocations HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: text/csv
> Content-Length: 2900
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 500 INTERNAL SERVER ERROR
< Server: nginx/1.10.3 (Ubuntu)
< Date: Wed, 25 Jul 2018 13:48:05 GMT
< Content-Type: text/html
< Content-Length: 291
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>

Internal Server Error

The server encountered an internal error and was unable to complete your request.  Either the server is overloaded or there is an error in the application.

* Connection #0 to host localhost left intact

In the original terminal running the server I get the following error

ImportError: libopenblasp-r0-39a31c03.2.18.so: cannot open shared object file: No such file or directory

The full stack trace is
$ ./serve_local.sh e7ea36fc1eda
Starting the inference server with 4 workers.
[2018-07-25 13:43:08 +0000] [10] [INFO] Starting gunicorn 19.9.0
[2018-07-25 13:43:08 +0000] [10] [INFO] Listening at: unix:/tmp/gunicorn.sock (10)
[2018-07-25 13:43:08 +0000] [10] [INFO] Using worker: gevent
[2018-07-25 13:43:08 +0000] [15] [INFO] Booting worker with pid: 15
[2018-07-25 13:43:08 +0000] [16] [INFO] Booting worker with pid: 16
[2018-07-25 13:43:08 +0000] [17] [INFO] Booting worker with pid: 17
[2018-07-25 13:43:08 +0000] [18] [INFO] Booting worker with pid: 18
/usr/local/lib/python2.7/dist-packages/gevent/builtins.py:96: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  result = _import(*args, **kwargs)
/usr/local/lib/python2.7/dist-packages/gevent/builtins.py:96: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  result = _import(*args, **kwargs)
/usr/local/lib/python2.7/dist-packages/gevent/builtins.py:96: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  result = _import(*args, **kwargs)
/usr/local/lib/python2.7/dist-packages/gevent/builtins.py:96: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  result = _import(*args, **kwargs)
Invoked with 29 records
[2018-07-25 13:48:05,146] ERROR in app: Exception on /invocations [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1815, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1718, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/opt/program/predictor.py", line 76, in transformation
    predictions = ScoringService.predict(data)
  File "/opt/program/predictor.py", line 42, in predict
    clf = cls.get_model()
  File "/opt/program/predictor.py", line 32, in get_model
    cls.model = pickle.load(inp)
  File "/usr/lib/python2.7/pickle.py", line 1384, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.7/pickle.py", line 864, in load
    dispatch[key](self)
  File "/usr/lib/python2.7/pickle.py", line 1096, in load_global
    klass = self.find_class(module, name)
  File "/usr/lib/python2.7/pickle.py", line 1130, in find_class
    __import__(module)
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/sklearn/__init__.py", line 134, in <module>
    from .base import clone
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/sklearn/base.py", line 13, in <module>
    from .utils.fixes import signature
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/sklearn/utils/__init__.py", line 10, in <module>
    from .validation import (as_float_array,
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/sklearn/utils/validation.py", line 18, in <module>
    from ..utils.fixes import signature
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/sklearn/utils/fixes.py", line 144, in <module>
    from scipy.sparse.linalg import lsqr as sparse_lsqr  # noqa
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/scipy/sparse/linalg/__init__.py", line 114, in <module>
    from .isolve import *
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/scipy/sparse/linalg/isolve/__init__.py", line 6, in <module>
    from .iterative import *
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/scipy/sparse/linalg/isolve/iterative.py", line 10, in <module>
    from . import _iterative
  File "/usr/local/lib/python2.7/dist-packages/gevent/builtins.py", line 96, in __import__
    result = _import(*args, **kwargs)
ImportError: libopenblasp-r0-39a31c03.2.18.so: cannot open shared object file: No such file or directory
<IP_ADDRESS> - - [25/Jul/2018:13:48:05 +0000] "POST /invocations HTTP/1.1" 500 316 "-" "curl/7.47.0"

The only thing I think I changed was the algorithm name in this bash script..
%%sh

# The name of our algorithm
algorithm_name=decision-trees-sample

so I don't think I broke anything
any ideas?

I got this error as well.
This example does not freeze numpy version, the working version is 1.14.5. I tried OK last week.
You can modify the Dockerfile or migrate example code to 1.15.0.

@titanjer yep, that worked. :tada:  thanks :pray:

Thanks for jumping in an contributing the fix for this @samsammurphy and @titanjer !


@stealify/VSStudio

VSStudio
VSStudio - Visual Stealify Studio IDE

[ ] Stealify Installer working (fdo concepts)

[ ] VSStudio Installer based on the Advisory Concept.

[ ] Working minimal build vscode/vscodium electron

[ ] Working minimal build vscode/vscodium web + extension-host

[ ] Migrae Porting VSCodium / Theia / Code Server to @stealify/editor

[ ] @stealify/jint-bidirectional modules and component that can expose.NET Compatible apis.

[ ] Unreal Engine Integration

[ ] Unreal.JS Addon inside the Unreal Engine

[ ] Unity Support

[ ] @stealify/editor Monaco/Monarch reimplementation module and component that can expose a text area and all its events. as also some generic basic concepts and methods added to allow easyer reuse.

[ ] Merge Porting Process Components

[ ] @stealify/theia mpdules and components to implement theia interop with VSStudio
[ ] @stealify/vscode mpdules and components to implement vscode interop with VSStudio
[ ] @stealify/code-server modules and components to implement code-server interop

Fundamentals
They did mostly all lie to you!
Chapter 1 Create your first Cross Platform Arch Application
The following is a Complet Application it runs anywhere and is written in ECMAScript because that is the most Dynamic Highlevel Language that is still able to incremental adopt to readable code. and implements a well defined module system
export const helloWorld = () => "Hello World!";

This is all it takes to call that a Application! It returns Hello World! and is run able via a outer Component like a runtime for ECMAScript in this case maybe.
Chapter 2 Run your first Cross Platform Arch Application
This is the Hard part and the reason why terms like devops do exist. As you learned before it takes not much to create Cross Platform Arch Compatible code as it is simply text.
A Interpreter or Compiler of that text will make it run able on any Platform or Arch. So a Compiler and or Interpreter needs to exist as only register based code is run able on hardware.
Chapter 3 what is a operating system
It is a collection of drivers and implements the concept of run able components. That is often referenced by the term userland where a user can define what he wants to execute and how.
Chapter 4 what is a compiler
A Compiler gets implemented in a so called compiler Language that needs to be a low level language most best not directly register based but it needs to include rules to create register based code most people call such code ASM or Assembly Language.
to clean up the terms we call some projects that call them self compiler transpiler because they do not directly compile executeable results. a Compiler is always something that produces run able code on hardware and everything else we call transpiler. TypeScript for Example is a transpiled language while Stealify and ECMAScript are compiled or transpiled languages that destinguished if you use a transpiler or compiler with them. V8 for example is often referenced as a Engine but it is not that it is a Compiler with a Engine Implemented on top of it.
Chapter 5 What is a Engine
a Engine is a construct for Runable code it gets often referenced as Application a Engine is a generic Application that often has some functions to dynamical or static link external code.
In Stealify every Component is a own Engine so it is a self run able code unit that can execute and load other components if it gets a component passed to it that allows that.
Chapter 6 Environment
The Environment a Runtime or Engine aka Component from now on runs in is described in Chapter 3 when it is not a Context which comes in chapter 7
Chapter 7 what is a Context
a context is a abstraction unit for one or more components including the whole environment it runs in this allows you to define things that take no user mandatory user input. for example your browser implements many Contexts some are user accessible some are not.
Conclusion Solution
Code Generation is the key to succes in your overall development process while it is enjoyable and needed to write code you will most often need to use and maintain code to run your coden then you need to creat real production ready functional code.

Show Systrace Examples
strace hostname

reveals usage of uname -n
strace uname -n

VSStudio
This is a mixture of best practices that we saw in the Open Source World that we Combined together into a usefully starter Application that can build it self with other components.
It is a perfect example of what we create when we apply the build our self pattern with the stealify component system pattern. We Replace so many Applications and Feature Implementations with a single Software Product that is simple to Maintain even as a Single Developer it is able to get enrolled in Production. Something that was only possible with Extensive cloud provider or administration knowledge.

[ ] merge: vscodium build process
[ ] merge: electron-compat for Handle based PeerConnections
[ ] merge: code-server build process
[ ] merge: @stealify/editor
[ ] merge: baker browser feature set
[ ] merge: PeerConnection Recorder and Player
[ ] merge: Streaming Broadcaster interface for rtc-cluster/rtc-cluster
[ ] merge: @stealify/webplatform

Goals
Be the successor that is feature complet of the following products:

vscode
theia
code-server
baker-browser
obs
WPEWebKit
WebView2
Chromium Content
MOJO:IPC
Couchbase
Oracle Database
Oracle GraalVM


Add lexer for Portugol language

Portugol is a simplified programming language based on Pascal language. This language is used for teach programming for people that speak Portuguese but don't understand English.
https://www.apoioinformatica.inf.br/produtos/visualg/linguagem

And this is the list of the keywords from that language: https://www.apoioinformatica.inf.br/produtos/visualg/item/29-referencias-da-linguagem-de-programacao-do-visualg


maxPostSize?

Am I correct in line 1124's maxPostSize is overridden on line 1124?
https://github.com/franton/JSS-In-A-Box/blob/a67ed6ddafe76aef81631526737d741c352a47a7/jss-in-a-box.sh#L1122
https://github.com/franton/JSS-In-A-Box/blob/a67ed6ddafe76aef81631526737d741c352a47a7/jss-in-a-box.sh#L1124

Sorry about the delay, but you logged that just as I went on vacation.
Anyway v5.3 released that should deal with that.