add: print warning when using build.extractCSS.allChunks

Types of changes

[ ] Bug fix (a non-breaking change which fixes an issue)
[x] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Resolve: #4094
I have a question.
When build.extractCSS.allChunks is set, what should be the default value?
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

I wouldn't alter the value of extractCSS in this case as it could possibly contain other settings for mini-css-extract-plugin. Even if not, it'll evaluate to true and the CSS will be extracted as expected.

Thanks! Almost good to go from my perspective.
Could you adjust the "new property" (which is build.optimization.splitChunks)? :relaxed:

@manniL
Thanks.
I changed it just as you pointed out.

Thank you! ☺

Codecov Report

Merging #4097 into dev will decrease coverage by 0.07%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##              dev    #4097      +/-   ##
==========================================
- Coverage   97.24%   97.17%   -0.08%
==========================================
  Files          18       18
  Lines        1272     1274       +2
  Branches      351      352       +1
==========================================
+ Hits         1237     1238       +1
- Misses         33       34       +1
  Partials        2        2

Impacted Files
Coverage Δ

lib/common/options.js
96.22% <50%> (-0.89%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 521c377...84796cc. Read the comment docs.

@clarkdo @pi0 let's get this in?

Thanks, @tohutohu.


allow tensor alias for Loop's carried params

Currently the memory allocator of all graph's outputs will not reuse any previous slots, regardless whether tensor alias can be applied. This change allows graph's output to reuse the allocated buffer, if:

the 2 tensors are identified as identical (alias)
the 2 tensors are the matching carried parameters of a Loop operator
the 2 tensors are input and output of a sub-graph (parent_node is not null)

My understanding is that the shape of carried dependencies can change between iterations for Loop (but must remain the same for Scan). Does this change handle that?

class PlannerTest : public ::testing::Test {

You need unit tests here testing the new code and validating it's doing what is expected and ensuring future changes to the allocation planner don't accidentally break existing code.

Refers to: onnxruntime/test/framework/allocation_planner_test.cc:138 in 1d60776. [](commit_id = 1d6077686756a69968b538c4bea1823be7e9913f, deletion_comment = False)

My understanding is that the shape of carried dependencies can change between iterations for Loop (but must remain the same for Scan). Does this change handle that?

If there is a change between those tensors, they will not labeled as alias.

The high-level goal of optimizing the static allocation planning for loops/scan is a good one. There is definitely scope for improving reuse across loop iterations. But it is also somewhat complex. For example: the assumption that it is safe to reuse the memory of an (loop carried) input-state for the corresponding output-state may not always hold. Consider a Loop statement with an initial-value X for some loop-carried dependency P. The tensor X is "owned" by the caller of the Loop (eg., the main graph executor). If this tensor X is used by some node after the Loop, then it would be a problem if the Loop's internal execution overwrites X (by reusing it). We need to make sure that the "ownership protocol" is generalized correctly to enable this kind of optimization, keeping in mind here that we have multiple parties involved: the "main graph executor", which calls the "Loop implementation", which in turn calls the "subgraph executor". We have to be clear "who owns which tensor".

Please ignore my comment above. I spoke with Yulong. As I understand it, the goal of this PR is to target a specific scenario where a loop copies some state-in parameter to state-out, and goal is to avoid the copy (and not just reuse of memory). Another solution for this scenario would be to have a graph-rewrite-rule optimization that can transform such a loop to eliminate such a parameter (which can be directly referenced as an outer-scope variable inside the loop body). But writing this optimization is also a non-trivial amount of work.


fixed param naming in token request

The travis-ci error is a problem with npmjs
https://github.com/npm/npm/issues/13284

I've kicked off a new CI run....

@rckrdstrgrd thanks for the contribution. Can you point to some documentation or other reference to illustrate why this change is required?

@lance I created an issue, https://issues.jboss.org/browse/KEYCLOAK-3271 . When I run the current release which uses "application_session_state" as request param, the k_logout endpoint will not be invoked by the keycloak server. When using "client_session_state", remote logout works as excepted.
Maybe I missed some config or something. If so, please ignore this PR.


too complex

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Well did you even try?
Watch out this simple example :
import * as React from "react";
import { render } from "react-dom";
import { useDrag, DropTargetMonitor, useDrop, DndProvider } from "react-dnd";
import HTML5Backend from "react-dnd-html5-backend";

import "./styles.css";

const acceptType = "MYCONTEXT";

function Dragger() {
  const [, dragger] = useDrag({
    item: { type: acceptType }
  });
  return (
    <div
      ref={dragger}
      style={{
        borderColor: "blue",
        borderStyle: "dotted"
      }}
    >
      DRAG ME
    </div>
  );
}

function Dropper() {
  const [dropProps, dropper] = useDrop({
    accept: acceptType,
    canDrop: () => true,
    collect: (mon: DropTargetMonitor) => {
      return {
        isOver: mon.isOver(),
        canDrop: mon.canDrop()
      };
    }
  });
  return (
    <div
      ref={dropper}
      style={{
        height: "300px",
        borderColor: "red",
        borderStyle: "groove",
        backgroundColor: dropProps.isOver
          ? dropProps.isOver
            ? "green"
            : "lightgreen"
          : undefined
      }}
    >
      DROP THERE!
    </div>
  );
}

function App() {
  return (
    <div className="App">
      <DndProvider backend={HTML5Backend}>
        <Dragger />
        <Dropper />
      </DndProvider>
    </div>
  );
}

const rootElement = document.getElementById("root");
render(<App />, rootElement);

Demo
Does this still look too complex for you?
A big thanks to react-dnd devs :heart:

You're welcome, i'm happy to help.
Could you please close this issue So mine get solved faster :yum: ,
thx :)


Bump math library versions

Needed a newer version of glam in my own project. Bumped vek too since it had a newer version available.

Thank you very much! Ah I wish I didn't need to depend on these as much...

I see the two Clippy tasks are failing. I must admit I'm on thin ground when it comes to anything more than primitive use of Clippy, so I'm not sure how to resolve these. It looks like some kind of interaction with configurations / cfg?

yeah don't worry about it, i'll take care of it. I don't much enjoy having this run on PRs by other people!

thank you for the PR!


cursor disappears in MacOS Sequoia 15.0

Summary:
Cursor disappears when moved over virtual display with DeskPad launched. Cursor interactions are still functional as clicks and movement of cursor is observed when hovering over interactive assets on the UI.  However, cursor itself is not visible as it is moved when on the virtual display.
Expected behavior:
Cursor is visible during all movement on physical and virtual displays.

I am seeing similar behaviour.

Same behavior on Macbook Pro M1 running Sequoia

Same behavior for me as well. When I did a screen recording of the virtual display, I noticed that the recording showed the cursor, but I could not see it while creating the recording.

Same here! I'm on an 2019 Intel mac

Just updated to Sequoia 15.0.1 today and issue persists.

Fixed by #32


Error doing job: Task exception was never retrieved

Hi,
Same as #60.
I just want to let you know, it did not fix it. Your changes in the code it should be before line no 67, no?
 if current_value == 'unavailable':
                    _LOGGER.info(
                        f'{self.entity_id}: not available.')
                    return

I can't reproduce this issue so it is really difficult to test. But I have changed the code. Will be included in the upcoming release.


Background
The go command requires that the import path of a module (or package within a module) match its semantically-versioned API. In particular, starting with major version 2 — the first breaking change from the API stabilized in major version 1 — the module path must end with a /vN suffix indicating the major version of its API.
However, prior to the introduction of modules, many Go package maintainers had already reused existing import paths (such as github.com/google/go-github) across multiple major versions. To accommodate the migration to modules for users of those packages, the vgo prototype — and the initial module support released in the go command in Go 1.11 — allowed those existing major versions to be used directly, and even preferred them over compatible versions (#26238) under two conditions:

The module with the incompatible version must not contain an explicit go.mod file.

The version must be annotated in the user's go.mod and go.sum files with the suffix +incompatible, indicating that the selected version is not compatible with the original API for that path.

Unfortunately, those exceptions introduce a number of problems:

#34189: If a user adopts modules (by adding an explicit go.mod file) and then accidentally tags a pre-module commit with an inappropriate major version, the erroneous pre-module tag will always be semantically higher than the highest valid module-enabled release tag (1.99[…].99[…]).

#27009: If a user has already tagged a major version above 1 and adopts modules (by adding an explicit go.mod file), then they must either adopt the major-subdirectory layout for their project (disrupting developers on the project), or break upgrades for non-module users (who will be expecting the unversioned import path).

#31543: Since the damage of introducing breaking changes is already done, users often expect that their v2-or-higher repository can be migrated to modules without changing its import path, but for various reasons that does not work in the general case.

#33795, #32695: Since +metadata tags in general are not semantically meaningful, the fact that +incompatible is semantically meaningful requires numerous special cases that are difficult to test and maintain, and creates confusion about when incompatible versions are or are not allowed.

#29731: The possibility of using a +incompatible version led us to support major-version wildcard queries, which are only useful for legacy repos and interfere with more useful branch queries.

#34254: The constraints on +incompatible versions derive from the module path, but that introduces even more complexity (and makes things more difficult to debug) with replace directives, which involve two module paths that may or may not impose the same constraints on the corresponding versions.

In contrast, for another interesting case of legacy tagging — semantic versions with metadata (#31713) — we came up with what I believe is a simpler solution: instead of accepting the non-canonical version tags as-is, we instead rewrite them to canonical pseudo-versions with an appropriate major version.
In light of the problems we have encountered with incompatible major versions, I believe that we should have applied a similar strategy for incompatible versions: perhaps using them for “latest” version resolution, but rewriting them to canonical pseudo-versions.
Unfortunately, the decision was made, and cannot be unmade in light of our subsequent experience without breaking compatibility.

...or can it?
Observation
Since a +incompatible version cannot have an explicit go.mod file, it cannot impose any transitive requirements on module selection. Therefore, a +incompatible version selected as the minimal version of a module cannot impact the version selected for any other module.
This implies that if we ignore the +incompatible versions in the module graph entirely, we will not accidentally drop requirements that pertain to other modules.
This leads to the following proposal (see the comment below; updates will be linked from here).
CC @jayconrod @thepudds @hyangah @katiehockman @heschik

Proposal
I propose that, in Go 1.14:

If a module path passed to go get does not have a major-version suffix, its major version is incompatible with the path, and the corresponding version of the repository does not contain an explicit go.mod file, the version should be resolved to a pseudo-version with a compatible major version.

I note that<EMAIL_ADDRESS>currently resolves the non-canonical version to the corresponding +incompatible version. It should be updated to instead resolve to the compatible pseudo-version.

If an existing +incompatible version is found in the main module's go.mod file, it should be similarly rewritten to a canonical pseudo-version.

Proxies may continue to serve +incompatible versions, and should not redirect a version requested with an explicit +incompatible suffix to the corresponding pseudo-version.

If a +incompatible version is found in the requirements of some other module in the build list, that version constraint should be ignored entirely, as if the other module had not required it at all.

If the +incompatible module is needed to satisfy an import from some module during a build operation, go mod tidy, or go mod vendor, the version of that module should be re-resolved to latest and the dependency added to the main module's go.mod file.

When resolving the latest or upgrade version of a module, the go command should first check the latest version of that module tagged with a compatible version.

If that version includes a go.mod file, then that version should be used and no further search performed.

Otherwise, the highest release at each major version should be checked for a go.mod file. The last such release that lacks a go.mod file should be resolved to a pseudo-version, and that pseudo-version should be used as the latest or upgrade version of the module.

If a +incompatible version is found in the requirements of some other module in the build list, that version constraint should be ignored entirely, as if the other module had not required it at all.

If the +incompatible module is needed to satisfy an import from some module during a build operation, go mod tidy, or go mod vendor, the version of that module should be re-resolved to latest and the dependency added to the main module's go.mod file.

Is this saying that if you are building module foo, which requires module bar, and bar has a go.mod containing require baz v2.3.4+incompatible, then that would be interpreted as require baz/v2 latest?
If so, does that mean the version of baz selected for the build could change (that is, ending up with some later commit than the commit tagged v2.3.4 )?
And if so, what is the brief rationale for that?

Is this saying that if you are building module foo, which requires module bar, and bar has a go.mod containing require baz v2.3.4+incompatible, then that would be interpreted as require baz/v2 latest?

No. It would be treated as if module bar's go.mod file did not mention baz at all.
In that case, your module (foo) would resolve baz@latest and add that dependency to your (foo's) go.mod file, all as usual for a package not found in the existing module graph.

The rationale is that I don't want to make the MVS step use any notion of “version precedence” that isn't ordinary semantic versioning.
(I especially don't want to have to walk back from v1.5.0 looking for the discontinuity in order to figure out the relative ordering of v1.5.0 and v2.3.4+incompatible, and I don't want to have to re-resolve the pseudo-version corresponding to v2.3.4+incompatible every time I reload the build list.)

In that case, your module (foo) would resolve baz@latest (not baz/v2@latest), and add that dependency to your (foo's) go.mod file, all as usual for a package not found in the existing module graph.
That means that you could indeed end up with a version of baz more recent than v2.3.4, [...]

But would that then mean go.mod is not providing reproducible builds if the versions selected in the build change upon upgrading to Go 1.14?  If so, would that be reasonable to do given prior statements around future releases being able to properly consume go.mod files defined by older releases? There might be some shades of grey there, including for example Go 1.13 invalidated some go.mod files that built under Go 1.12, but there is at least an argument to be made that reporting a fatal error for a previously uncaught problem is different than shifting the versions used.
(Sorry for the multiple questions; mainly still trying to see if I understand the proposal).

But would that then mean go.mod is not providing reproducible builds if the versions selected in the build change upon upgrading to Go 1.14?

It would mean that the transition from Go 1.13 to Go 1.14 would not reproduce the same set of dependencies, but since the entire toolchain and standard library changes at each major release, that boundary is not exactly “reproducible” to begin with.
Once you run a go build or go mod tidy using 1.14, then each successive build using 1.14 would produce the same result, just not necessarily the same result as when using 1.13.
The more interesting problem occurs when going back from 1.14 to 1.13, since the version selected (and written to the go.mod file) by 1.14 may be “lower” (in the strict-semver sense) than the version selected by 1.13.

It would mean that the transition from Go 1.13 to Go 1.14 would not reproduce the same set of dependencies, but since the entire toolchain and standard library changes at each major release, that boundary is not exactly “reproducible” to begin with.

I haven't fully considered this yet, but it seems like a significant, breaking change in MVS. This would change builds in a more significant way than toolchain and standard library changes do (those tend to be in Hyram's law territory).
An obvious consequence: suppose you depend on module A (which has migrated to modules), which depends on module B (which has not) at v2.0.0+incompatible. With this change, the B requirement is ignored, and we get a pseudo-version based on v3.0.0, the newest major version of B without a go.mod file. The B API has been rewritten between major versions, and the upgrade breaks the build. The author of the main module now needs to either replace B or go get<EMAIL_ADDRESS>despite not being familiar with B or having any explanation of why the build broke.
(of course this can already happen if someone else requires B v3.0.0+incompatible)

@jayconrod, that's an interesting consideration (and somewhat ties in to #34165).
One alternative would be to only apply this proposal if the main module's go.mod file specifies go 1.14 or higher, so that the need to re-resolve versions would be opt-in at that point.
That has the advantage of retaining compatibility with as much of the +incompatible support as actually works today, but the disadvantage of not reducing the complexity (and bugs) induced by that support.
It also has the disadvantage of changing the meaning of a module's requirements depending on which other module is importing it, which makes fixes and patches more difficult to test, but perhaps not by too much.

Thinking about it some more, gating on go 1.14 in the main module's go.mod file seems like the clear way to go. Will edit the proposal.

This seems plausible but I haven't thought through it all carefully.
If you (@bcmills), @jayconrod, @thepudds, and @myitcv
all agree that this is the right thing to do, then I'm willing to try it.

Full disclosure: I'm not currently close enough to the details here to opine, so I'll leave it to others to decide.
FYI @mvdan @rogpeppe given previous conversations

CC @Helcaraxan

@bcmills Just to help people confirm their understanding, what do you think about giving a couple examples of final pseudo-versions? For example, for tags like v2.3.4 and 2.3.5-alpha.1, where neither corresponds to a commit with a go.mod, or something like that?
Is it correct that the final result would translate to a fourth form of pseudo-version being defined, rather than the current three forms:

vX.0.0-yyyymmddhhmmss-abcdefabcdef is used when there is no earlier versioned commit with an appropriate major version before the target commit. (This was originally the only form, so some older go.mod files use this form even for commits that do follow tags.)
vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefabcdef is used when the most recent versioned commit before the target commit is vX.Y.Z-pre.
vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the most recent versioned commit before the target commit is vX.Y.Z.

Or if not a forth form, then maybe it is just a tweak to the current three definitions, but a VCS tag like v2.3.4 getting translated to v2.3.4-yyyymmddhhmmss-abcdefabcdef I think is does not fit into one of those current patterns? (If that is indeed the proposed form?)
Separately, as I understand it, part of the overall intent for the proposal is to help simplify the cmd/go code (cutting down on corner cases and corresponding bugs) as well as making things simpler for users. But if cmd/go will need to forever understand old go.mod files, is there a large gain in simplicity of the cmd/go code? (I can imagine there could be simplicity gains if only reading old modules needs to be supported, but at least wanted to ask the question).

One problem with this: adding go 1.14 to go.mod does not prevent old versions of the Go command from adding +incompatible versions. So a module could be broken unintentionally in a mixed environment.

Somewhat related to prior comment, perhaps this could get rolled out across two releases -- first, in say Go 1.14, just rewrite +incompatible entries for the main module's go.mod. Second, in say Go 1.15, introduce the error conditions. Maybe that doesn't make sense, but maybe that would help in a mixed environment, and give more time for more modules to transition.  (I think the rules as outlined mean the common case might be smooth transition for an individual module, but there are a lot of gophers out there, and maybe being slightly more conservative on the roll out might cut down how many people complain about having hit a "rare" error).
Also, if these are new pseudo-versions, is there an opportunity to inject a suggestive word into the pseudo-version itself, so that people have a higher chance of (a) understanding when first encountering these (without ever having read the specific piece of doc that describes them), or at least (b) recognize them when the see them again later? Or maybe injecting a comment?
Finally, there is some subtlety in the discussion (including it is slightly tricky in some of the discussion to be 100% sure which "major version" is being mentioned), so sorry if some of these questions are off base.

@bcmills Also, I think I did not fully understand the last portion of this comment (including whether or not it means Jay's immediately prior suggestion does not work, or if it is only tangentially related to Jay's comment):

At the very least, I think we would need to give the main module the opportunity to to replace those versions with compatible pseudo-versions, but at that point we're back to having the main module specify the dependency anyway — so we may as well just ignore the versions that would need to be replaced.

Is it correct that the final result would translate to a fourth form of pseudo-version being defined […]?

It would be one of the usual forms. The resolution process is basically:

Resolve the incompatible version to a commit hash.
Fetch the requested commit and verify that it lacks a go.mod file.
Re-resolve the commit to a pseudo-version as if the incompatible-major tags did not exist.

That commit has v2.0.0-alpha.0 as its only valid-semver ancestor. v2 is not compatible with an unversioned import path, so that tag would also be excluded as a pseudo-version base.

That commit has numerous ancestors, but its last v1 ancestor seems to be v1.1.1.
Therefore, go list -m<EMAIL_ADDRESS>would resolve togithub.com/Azure/go-autorest v1.1.2-0.20190906230412-69b4126ece6b

But if cmd/go will need to forever understand old go.mod files, is there a large gain in simplicity for the cmd/go code?

No; the benefit is mainly for users — particularly for maintainers with existing v2+ tags, since this would give them a way to opt-in to modules going forward.
In particular, it would give maintainers a way to opt in without forcing their existing consumers to update import paths, assuming that either those consumers have already adapted to any breaking changes up to the last major version, or the maintainers are willing to go back to the API as it stood at the last v1 release.

In full disclosure, though, there are two possible simplicity gains in cmd/go:

We could perhaps avoid fixing some existing bugs on +incompatible paths, since users before Go 1.14 would have those same bugs and users at or after 1.14 could avoid the bugs by upgrading their go directive.

We could at some point declare that the main module itself must declare go 1.14 or higher, at which point we would only need to understand how to ignore +incompatible versions (rather than how to interpret them).

perhaps this could get rolled out across two releases

I don't think there would be a significant advantage in doing so. A go 1.13 binary working in a go 1.14 module would already untidy it in many cases (replacing v0 or v1 pseudo-versions with +incompatible versions from transitive dependencies), and at that point there doesn't seem to be a significant advantage to delaying the error-check for go 1.14 modules.

if these are new pseudo-versions, is there an opportunity to inject a suggestive word into the pseudo-version itself

Metadata in the pseudo-version itself would not be backward-compatible to Go 1.13 and earlier, and so would prevent Go 1.13 users from consuming a 1.14 module. That's not out of the question, but seems a high cost in exchange for the marginal value of the metadata.
We could probably inject a comment, at least.

I think I did not fully understand the last portion of this comment […]

If the main module specifies go 1.14 and we retain but disallow +incompatible versions found in transitive go 1.13-or-earlier dependencies, then the main module will need to replace those versions with compatible ones. But if the main module must replace those modules anyway, then we may as well filter them out in the first place — that way, the main module only needs to require the appropriate versions, and those version constraints will propagate appropriately as dependencies themselves upgrade to go 1.14.

Some more insights from a discussion with @jayconrod this morning.
Ideally, we would like to do our best to respect +incompatible versions by converting them to compatible pseudo-versions. Provided that the +incompatible versions all have some common v0 or v1 predecessor tag and the semantic tags are mostly applied to chronologically-ordered commits, that tends to produce the same result as running MVS on the original +incompatible versions.
The major problem with that approach is that it the version-to-pseudo-version mapping may be expensive to compute, so we don't want to recompute it every time we resolve dependencies.

However, we could do the version-to-pseudo-version resolution once and record the result in the go.mod file, and then only ignore a +incompatible version found in a transitive dependency if the main module's go.mod file specifies a version for the same module path.
That would at least preserve the selected version at the 1.13-to-1.14 transition point, but wouldn't pick up +incompatible requirements from newly-added dependencies. (But maybe we shouldn't be picking those up anyway, because they're incompatible?)

One other alternative might be to cache the +incompatible-to-pseudo-version mapping in the main module's go.mod file in some other way. For example, we could inject some directive that maps each of the resolved versions to the corresponding compatible version.
One option I'm considering for #26904 is to introduce a form of the replace directive that omits the version, meaning “alias the module path to the resolved version instead of replacing the source code”.
We could similarly overload the replace directive to omit the path, meaning “treat this version as actually referring to this other version, including during version selection”:
replace github.com/Azure/go-autorest v13.0.1 => v1.1.2-0.20190906230412-69b4126ece6b

On the other hand, I don't see much point in overloading the replace keyword at that point — we may as well just introduce a new one. I personally like remap:
remap github.com/Azure/go-autorest v13.0.1 => v1.1.2-0.20190906230412-69b4126ece6b

A remap directive (using either option for syntax) would have the advantage of also allowing module authors to more easily correct other kinds of invalid versions or semantic tagging errors.

It seems to me that from a practical perspective the need to respect the +incompatible versions of transitive dependencies is paramount. Not doing so would be a potential cause for many unexpected breakages. Both for new module adopters or for projects already using modules that add a new dependency with previously unseen +incompatible transitive dependencies.
In practice such breakages might not be too numerous, nor touch the majority of users, but it's yet another place where modules could potentially interfere with the "it just works" principle. The errors could also be very hard to decipher as they would arise in transitive and not direct dependencies of someone's project. Debugging this would then require a developer to learn in one swoop quite a bit about modules, dependency management subtleties, the actual implementation details of their dependencies and even the dependencies of their dependencies. This is not something that people would usually want to do. Hence if we can prevent it we should do so.
On the more practical side I do like the idea of the remap for both proposed syntaxes: version-less and path-less. It could indeed be used to correct a lot of breakages that have been introduced by early adopters without the necessary expertise or appropriate tooling (like described in #31543).
The downside though of remap is that, outside of the use-case discussed here, the burden of correction will fall on downstream users instead of on the offending projects themselves. This means that although it's a very useful tool, it's also a "patch" to fix things that have already gone wrong instead of a tool that adds new possibilities. I'd rather fix the root cause of those errors... but that ship has probably already sailed, at least for early adopters.
A potential middle ground could be to further make cmd/go capable of understanding the most common errors, referring to some of the proposals in #31543 and even extending them. It could pro-actively add more appropriate remap lines to a project's go.mod. One example would be to automatically add a "path" remap for a dependency at a vN version with a go.mod that misses the /vN suffix in the module's path.
All this said... I do very much like the idea of removing the +incompatible as it will help give a more "uniform" appearance, for lack of a better term, to (pseudo-)versions. I remember myself being relatively confused the first few times I encountered them and it took me a few weeks to wrap my head around the subject. In hindsight I would not have needed to worry as much as I had done. Another benefit would thus be to make things less confusing for developers with little dependency management experience who should not need to know about the subtleties of pre-module-version compatibility when using modules themselves.

I thought about this a bit more, and I have some questions and concerns listed below. In general, I'm worried this is a significant change with subtle implications. I don't expect we're going to be able to foresee all potential issues, and I'd like to see if we can solve the problems listed above by doing something narrower and possibly also #24031.

We should ensure that, given a complete go.mod file in the main module, all versions of the go command should pick the same build list or fail due to new, unrecognized syntax (remap).

Non-main go.mod files with newer go statements should be understandable by older versions of the go command. Only module, go, and require statements are read, and we should not change their interpretation.
Any differences in chosen versions may break the build. Replacing +incompatible versions with equivalent pseudo-versions is probably okay, but it will be visible in debug.BuildInfo.

What changes are needed by proxies? I think some buy-in may be needed by proxy maintainers.

/@v/list - should +incompatible versions still be advertised? Newer versions of the go command may be able to prune them out.
<EMAIL_ADDRESS>- should a +incompatible version be resolved to a pseudo-version here? Will that break anything in 1.13 or earlier?
<EMAIL_ADDRESS>.zip - I think we would still need to serve +incompatible versions to keep older versions of the go command working. Currently, 404 or 410 should be served for non-canonical versions.
/@latest - should probably be updated to match the new definition of @latest, but this shouldn't be strictly necessary unless /@v/list is empty.

When resolving versions in direct mode, do we need to fetch more than we did before?

In normal operation, I think we fetch commits for every tagged version, but not the full history. Replacing +incompatible with a pseudo-version would force unshallowing, but that's probably okay.

Are there situations where different versions of the go command will undo each other's changes? I don't think a pseudo-version would be replaced by the equivalent +incompatible version in 1.13, but please confirm.
Should the go command replace +incompatible versions without a go 1.14 statement in the main module?
I'm assuming remap would only apply in the main module, not downstream, but please confirm.
Will remap require go 1.14?
Would remap ever be added automatically? This would result in different build lists, but if the module has go 1.14, older versions won't work, so there's no inconsistency. Maybe that's okay.
Do you anticipate any other ways remap can be abused? What are its limitations with respect to semantic import versioning? Could it be used by authors to bypass semantic import versioning altogether?

I'd like to reiterate the previous commenters' support for keeping resolved versions the same.
For large projects, maintaining the exact versions of dependencies can be tricky. If dependencies change when moving to a new version of Go, that version of Go will be "tainted" by the associated breakage.
For any plan moving forward I think that, as a minimum requirement, modules should continue to build with exactly the same resolved dependencies on at least the last two versions of Go. People need to be able try out the latest version while still having the option to drop back to the previous version.
So anything landing in 1.14 should change the go.mod file in such a way that 1.13 arrives at the same resolved dependencies. I suspect that a phased plan, with the final phase landing in 1.15, might be the best way forward here.

Thanks @jayconrod for bring up the issues related to the module proxy.

What changes are needed by proxies? I think some buy-in may be needed by proxy maintainers.
/@v/list - should +incompatible versions still be advertised? Newer versions of the go command may be able to prune them out.
<EMAIL_ADDRESS>- should a +incompatible version be resolved to a pseudo-version here? Will that break anything in 1.13 or earlier?
<EMAIL_ADDRESS>.zip - I think we would still need to serve +incompatible versions to keep older versions of the go command working. Currently, 404 or 410 should be served for non-canonical versions.
/@latest - should probably be updated to match the new definition of @latest, but this shouldn't be strictly necessary unless /@v/list is empty.

Proxies that rely on the go command internally (e.g. Go Module Mirror) need to upgrade the newer version that behaves differently with the prior go versions following this proposal. Maybe some users of the proxies may upgraded their go before the proxies, or after the proxies. Then, I fear this behavioral change from the proxy side can add more confusion and complexities.
I feel adding this in 1.14 is too rushed to evaluate the impact and added complexity to the whole go ecosystem.

@jayconrod

should +incompatible versions still be advertised?

A proxy may continue to advertise them, but may choose to omit them. (In general the contents of a proxy's @v/list endpoint are at the discretion of its maintainers.)
I am not sure which direction we should recommend. As you note, newer versions of the go command should know what to do about them anyway, so I'm leaning toward keeping them, but still need to think through the implications of that.

<EMAIL_ADDRESS>- should a +incompatible version be resolved to a pseudo-version here?

No. However, the equivalent non-+incompatible version should be resolved to a pseudo-version (instead of the +incompatible version to which it resolves today).

Will that break anything in 1.13 or earlier?

It may cause users of earlier go versions to resolve a lower +incompatible version than what they did before. In many cases (such as #34189 and #34165), that will result in a better overall user experience, but in some cases it may cause MVS to bury the correct version (v1.0.0-something) in favor of a +incompatible dependency with a higher major version.

<EMAIL_ADDRESS>.zip - I think we would still need to serve +incompatible versions to keep older versions of the go command working. Currently, 404 or 410 should be served for non-canonical versions.

Agreed. And go mod download would presumably need to continue to support explicitly-requested +incompatible versions.

/@latest - should probably be updated to match the new definition of @latest, but this shouldn't be strictly necessary unless /@v/list is empty.

/@latest could matter if /@v/list contains only +incompatible versions. In that case, only new versions of the go command will care, so /@latest should presumably give the compatible pseudo-version rather than one derived from a +incompatible tag.

@bcmills

<EMAIL_ADDRESS>resolves to commit 69b4126ece6b.
That commit has numerous ancestors, but its last v1 ancestor seems to be v1.1.1.
Therefore, go list -m<EMAIL_ADDRESS>would resolve to
github.com/Azure/go-autorest v1.1.2-0.20190906230412-69b4126ece6b

I'll use that example as a starting point for a couple of questions, but let's also make up a v12.0.1 release that also does not have a go.mod. Let's pretend it was released a while ago (say, in 2018).
That would give us:

v12.0.1 (no go.mod) resolves as v1.1.2-0.20180101000000-aaaaaaaaaaaa (this is made up)
v13.0.1 (no go.mod) resolves as v1.1.2-0.20190906230412-69b4126ece6b (this is real portion)

Those sort properly as pseudo-versions.
However, let's suppose tomorrow there is a new v12.0.2 release (given part of the point of having major versions is to allow patch releases for prior major versions).
Let's say that gives us:

v12.0.2 (no go.mod) resolves as v1.1.2-0.20190922000000-bbbbbbbbbbbb (also made up)

At that point, that no longer sorts properly compared to the pseudo-version generated for v13.0.1. In other words, a lower major version release would be selected over a higher major version release (e.g., if there are multiple require statements in a larger build).
Let's take a second scenario. Let's pretend v12 is an import major release that they want to support for a long time, so they decide to adopt modules within the v12 train.
Let's say that then gives us:

v12.1.0 (with a go.mod) resolves as v12.1.0

That also no longer sorts properly compared to the pseudo-version generated for v13.0.1.
Is that the way this would work? Again, sorry if any of this is off base.

Sorry, my second scenario is not as relevant, given at that point it would be go-autorest/v12 once modules were adopted within the v12 major release.

Correct me if I'm wrong but:
One nice thing about this proposal is that converting +incompatible to <psuedo-semver> will work exactly like converting a master to <pseudo-semver>.
Which means even if the user is not using Go 1.14, but the proxy he/she is using is internally using Go 1.14, then their go.mod file will properly tell them to update their go.mod file to the correct version.
On the other hand, this can mean that if a proxy storage say one thousand +incompatible modules, then it will eventually have its own 1000 duplicates of the pseudo semver module.
If we can run some off-go command to know how eaxctly a +incompatible translates to the proposed pseudo semver, then go proxy maintainers can write a script to clean up the incompatible modules once they have all the corresponding duplicates

For the Go proxy we wrote at work the +incompatible situation has been a constant source of problems.
I understand that this +incompatible tag was introduced for easy backwards compatibility with libraries that had not yet upgraded to modules, but in hindsight, I feel it has more problems than benefits.
Now that almost everyone is upgrading to go modules, I think we should simply require a go.mod file for all module imports, an drop all support for the +incompatible tag. This might create some transition problems, which can be dealt with go1.14 in the go.mod file, but it will make go modules and go module proxies a lot easier to implement.

@beoran could you elaborate on

I think we should simply require a go.mod file for all module imports
Do you mean that we should no longer support non-module imports?

Yes. In hindsight, I think non module imports are more troublesome than they are useful. The convenience does not weigh up to the complexity. If we didn't have to support non module imports, or proxy would likely require 25% less code.

That would, in my opinion, be a much too aggressive move that risks causing an insurmountable amount of pain on the entire Go ecosystem. Especially given that it is still to be decided whether modules are going to be the default flow in 1.14, as this might be pushed again to 1.15. It would also be kind-of a breaking change (although not formally as it's not part of the Go language spec).
What such a change would mean is that projects will not be able to update their go directive in their go.mod to >=1.14 (and thus not use any new features of 1.14+) unless all their direct dependencies have adopted modules.
Given that many frequently-used projects have their oldest dependencies somewhere in the range of 2 to 7 years old that is not something that is a reasonable burden to put on these projects. Bear in mind that these dependencies are so old because they are no longer being developed and might simply have reached a stable and mature state 4+ years ago. This would mean that all such projects will need to be hard/soft forked (because the maintainer has likely moved on) or redeveloped from scratch.

Also please note: this proposal is not going to make it into 1.14 and will likely be reworked in the form of a new proposal by @bcmills, based on the golang-tools call earlier this week.

Yeah, I'm going to go ahead and withdraw this proposal — the consensus seems to be that it's too invasive. I'll file another one for something less invasive.


binary release of hugo-gallery

One of the great thing about hugo itself, is that it ships as a binary.
So I don't have to have any dependencies installed separately.
This is a request to provide hugo-gallery as a binary release.

I've added a binary here: https://github.com/icecreammatt/hugo-gallery/releases/tag/v1.0


vpn bridge start command generates " .dat " file in /tmp folder

HI
We are using VPN bridge for tunneling solution, when we start the bridge it creates a .unicode_cache_xxxxxx.dat file in the /tmp/ directory. I want to understand the purpose for this file, and is it safe to delete the file once the VPN bridge starts. Is there a way to configure it to stop generating this file or create in some other location other than /tmp. ?
I have asked this question in forum as well, but this seems like an issue, so reporting it here too.
Version 4.18 Build 9570   (English)
Compiled 2015/07/26 15:19:27 by yagi at pc30
Copyright (c) SoftEther VPN Project. All Rights Reserved.
cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.2 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.2 LTS"
VERSION_ID="14.04"

it is part of hamcore.se2
for more details, have a look: https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Mayaqua/Table.c#L1224


Improve lookup error handling

Return values from REopt were causing SAM to crash. Check for a null pointer earlier to avoid the crash.
To reproduce:

Check out develop on lk and wex, https://github.com/NREL/ssc/commit/d2f76f09d4e6f346fc8ceb16f8c53b30086f38c1 on ssc, and https://github.com/NREL/SAM/commit/d498705c6a2d112613211d64dd578009b743fb27 on SAM, build
Open a behind the meter PV-Battery case and run "Get size and dispatch from REopt"
Observe the crash
Check out improve_lookup_error_handling on lk, rebuild
Open a behind the meter PV-Battery case and run "Get size and dispatch from REopt"
Observe the improved error message and lack of crash

Note that the (!this) comparison does not generate a warning in XCode 14.1 but does generate a warning in the Github Actions Ubuntu build. So, either is fine. However, we must remove the -Werror from the CMakeList.txt that has been committed to this branch and pull request.

Thanks, I wasn't sure we wanted to remove -Werror. Were there further changes needed after a960030? This looks good to me.


Could the More Filters button have an option to show skipped tests?

If possible, could the More Filters button have an option to show skipped tests please?
That is, tests marked as so:
test.skip('this is a test', async....)

This sounds like a feature request to Visual Studio Code itself, please open a feature request there: https://github.com/microsoft/vscode


Feature/labs38 notebook final

Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
The model was tested in the performance notebook displaying various metrics.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings
https://www.loom.com/share/82645549702849ab84cc5de22d6c55ac

this was carried over to another PR


[1Password] Modify shortcuts and few new features!

Extension
https://www.raycast.com/khasbilegt/1password
Description
I would like to start using the 1Password extension, however, I would prefer to be able to modify keyboard shortcuts for the "Copy Username" and "Copy Password" actions. Additionally, I have some ideas for features that could be added to the extension:
The ability to paste the username and password in addition to copying them.
Copying and pasting 2FA codes.
Closing the Raycast window after copying the username or password so that the copied phrase can be immediately pasted.
Who will benefit from this feature?
Anyone who wants to customize shortcuts
Anything else?
No response

Why customizing keyboard shortcuts? We usually try to pick the best. Do you want to add the new actions yourself?

I create this issue because I prefer to use ⇧ it as a modifier as often as possible.
It's easier to click ⇧ + ⌘ + C or ⇧ + ⌥ + C rather than ⌘ + ⌥ + C. That's why I would love to change it in settings 🤔


Add Layout/IndentationConsistency to Rubocop config

As suggested in https://github.com/ruby/spec/pull/1174#discussion_r1660135696

I've added a few additional commits. This includes a Gemfile with the correct Rubocop version (the Gemfile.lock is ignored in git, so I left that one out) and updated Github Actions to use the gemfile. This means it's easier to run Rubocop on your home setup without having to worry about installing the correct version of Rubocop.

Mmh, one trouble with the Gemfile is if someone looks at this project they might think they should run bundle exec mspec or so to run specs, because there is a Gemfile at the root.
But on purpose ruby/spec avoids Bundler because subprocesses are a lot slower under Bunder and to keep things simple.
What I do locally is basically the same the CI does:
https://github.com/ruby/spec/blob/8aae62fbdc0e646ae775576d847beb60063ca253/.github/workflows/ci.yml#L75C12-L76
Except for the second command I use:
$ rubocop _1.28.2_ --parallel

(we could of course use that in CI too to be more explicit)
So I think either using that or adding a small script which just runs rubocop _1.28.2_ *args is better than the Gemfile.

Also since RuboCop 1.0 I think using a newer version of RuboCop has almost no observable behavior difference, so that should work fine too.

@herwinw Could you address https://github.com/ruby/spec/pull/1180#issuecomment-2408628698 ?
I think having a Gemfile at the root is not good because of those reasons so I would like to find another solution.

@herwinw Could you address #1180 (comment) ? I think having a Gemfile at the root is not good because of those reasons so I would like to find another solution.

My apologies, I completely overlooked that one. I will have a look at it tomorrow or the day after tomorrow.


deps: Update beam version to 2.24.0

Porting https://github.com/googleapis/java-bigtable-hbase/pull/2775 to bigtable-1.x

looks good, I think you also want to include the changes from #2789

Done.


⚠ Turnos 24x7 has degraded performance

In ac790eb, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 1206 ms

Resolved: Turnos 24x7 performance has improved in c00c123.


ObjectManager: implement InterfacesAdded and InterfacesRemoved

https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager
org.freedesktop.DBus.ObjectManager.InterfacesAdded (OBJPATH object_path,
    DICT<STRING,DICT<STRING,VARIANT>> interfaces_and_properties);
org.freedesktop.DBus.ObjectManager.InterfacesRemoved (OBJPATH object_path,
    ARRAY<STRING> interfaces);

The InterfacesAdded signal is emitted when either a new object is added or when an existing object gains one or more interfaces. The InterfacesRemoved signal is emitted whenever an object is removed or it loses one or more interfaces. The second parameter of the InterfacesAdded signal contains a dict with the interfaces and properties (if any) that have been added to the given object path. Similarly, the second parameter of the InterfacesRemoved signal contains an array of the interfaces that were removed. Note that changes on properties on existing interfaces are not reported using this interface - an application should also monitor the existing PropertiesChanged signal on each object.

@rafalgajda-silvair


Add slot for an icon/whatever on either side of GroupHeader

This will allow having things like collapsing sections

Closed by #720


Balena update to v17.12

Contributor checklist

[x] Changes have been tested
[x] Change-type present on at least one commit
[x] Signed-off-by is present
[x] The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

When submitting a review, please pick:

'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

@shaunmulligan tested it on rpi3.

@ZubairLK We do but as long as we still support boards on these versions we keep them.


[Feature] Fake source map

Generate random not working source map with dead code, so DevTools will hide the original obfuscated code and show weird code instead.

Not in the current plans


Potential risk:  	External Control of File Name or Path

Source code:
https://github.com/nodejs/node-gyp/blob/f0882b1264b2fa701adbc81a3be0b3cba80e333d/gyp/tools/pretty_gyp.py#L144Attack
Description: This call to open() contains a path manipulation flaw. The argument to the function is a filename constructed using user-supplied input. If an attacker is allowed to specify all or part of the filename, it may be possible to gain unauthorized access to files on the server, including those outside the webroot, that would be normally be inaccessible to end users. The level of exposure depends on the effectiveness of input validation routines, if any.
Remediation: Validate all user-supplied input to ensure that it conforms to the expected format, using centralized data validation routines when possible. When using blocklists, be sure that the sanitizing routine performs a sufficient number of iterations to remove all instances of disallowed characters.
References: CWE WASC

please take it up with https://github.com/nodejs/gyp-next (or get a more intelligent code scanning tool)


[test] div_euclid_overflow; not panic as expected

cargo +stable test --release
failures:

---- int::tests::div_euclid_overflow stdout ----
note: test did not panic as expected

failures:
    int::tests::div_euclid_overflow

test result: FAILED. 89 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Fixed in #403


[5.2] Array collapse() - Minor change

First of all validates if is accessible (using the new method). Also a new test was added.
This is not a breaking change.

In fact only regular arrays and Collection objects are supported, but not ArrayAccess.
Thus:

This method should be fixed (param in phpdoc, and reverting to previous code).
More important, data_get currently could try to call Arr::collapse with an ArrayAccess.

Refs #10709 and #12418.


image upload plugin

I am trying to create a custom plugin for image uploading so it will send to a server side script I wrote. What should the object look like for the upload plugin you provide? On line 89 in trumbowyg.upload.js I am seeing that you use data.message and data.file, I have tried passing the response I am sending back which contains the following
{
    'is_error': false,
    'message': 'uploadSuccess',
    'file': {
        'url': //the.com/url/of/the/image.jpg',
        'alt': 'something anything',
    },
}

should there be more or am I doing it wrong? When I wen through dist/trumbowyg.js from lines 863-867 it doesn't look like anything other than url and alt are being used.
But when I try to upload an image it always is inserts like this <img src="[object Object]">

the standard plugin "upload" expect "file" to be the url of the image, "message" is encoded in section lang of the same plugin (you need to add other ones if you want custom messages to show up, eg. "uploadNotAjax" from the examples).
so the standard object from your server - if the file is succesfully uploaded - should be:
{
    'message': 'uploadSuccess',
    'file': 'url/path/to/image.jpg'
}

i came up with se same problem...
seems that "file" have to be the plain text url to show up... is it a bug in plugin or in master js?
{
    'message': 'uploadSuccess',
    'file': '//the.com/url/of/the/image.jpg', //bug bug bug?
}

Since i really like the style of this plugin, I made some debug. the bug is in the plugin.
calling tbw.execCmd('insertImage', data.file) doesn't do what it's mean to be. So istead I use this code:
	tbw.execCmd('insertImage', data.file.url);
	$('img[src="'+data.file.url+'"]:not([alt])', tbw.$box)
		.attr('alt', data.file.alt)
		//section below is an enhancement - not pertinent with the question. you can skip it
		.css( typeof data.file.sizes === 'undefined' ? {} : {
			maxWidth : data.file.sizes.w+'px',
			maxHeight : data.file.sizes.h+'px'
		});

There is no alt support on upload plugin actually.
If you want to add it, you can submit a pull request :)

I've worked on upload plugin as you can see here : https://github.com/Alex-D/Trumbowyg/blob/master/plugins/upload/trumbowyg.upload.js
This version is avaible under 2.0.0-beta.6 version.
I've added a lot of options, see example of use here : https://github.com/Alex-D/Trumbowyg/blob/master/index.html#L173
I need to write documentation ASAP.

I struggled with implementing the upload stuff for some time so I wanna drop my insights here incase it may help someone else using nodejs
STEPS:

include the js file

then initialise trumbowyg like this
$("#test").trumbowyg({
btnsDef: {
// Customizables dropdowns
image: {
dropdown: ['insertImage', 'upload', 'base64', 'noEmbed'],
ico: 'insertImage'
}
},
btns: [
['viewHTML'],
['undo', 'redo'],
['formatting'],
'btnGrp-design',
['link'],
['image'],
'btnGrp-justify',
'btnGrp-lists',
['foreColor', 'backColor'],
['preformatted'],
['horizontalRule'],
['fullscreen']
],
plugins: {
upload: {
serverPath: '/upload',
fileFieldName: 'image',
}
}
});

NOTE: in the plugin segment the serverPath is the POST path that you have created to handle the file uploading process. A typical path will be like this in express. Please note the response format.
The response object should be in the format below to work with the default trumbowyg.upload.min.js file
router.post ("/uploader", function(req, res) {
//do other handling here for multipart middleware like multer
res.status(200).send({"file": "path/to/file/" + req.file.originalname, "success":true});
});
and just leave the fileFieldName option like that (I didn't bother to modify it);
before you can get the files in NodeJs environment you will need to install multer module and config it. The config info is on their github page
https://github.com/expressjs/multer

let editor = $('#editor-dropdown')
    .trumbowyg({
        btnsDef: {
            // Create a new dropdown
            image: {
                dropdown: ['insertImage', 'upload'],
                ico: 'insertImage'
            }
        },
        // Redefine the button pane
        btns: ['viewHTML',
          '|', 'formatting',
          '|', 'btnGrp-semantic',
          '|', 'link',
          '|', 'image',
          '|', 'btnGrp-justify',
          '|', 'btnGrp-lists',
          '|', 'horizontalRule',
          '|', 'fullscreen'],
        plugins: {
          upload: {
            serverPath: '123'
          }
        }
    })
    .on('tbwchange', (e) => {
      this.props.onChange(e)
    })

but I set the upload'serverPath as option , it's worked.


Move to yargs

Commander is cool and all, but there's some hacky things we have to do to get our CLI to do what we want. It'd be sweet to use yargs which is much more flexible.
All changes should happen in here. Should hopefully be able to just use it similar to how I've used it in split-guide here :+1:

That's a pretty solid starting point! 👍
Some things that should change here as well, from the looks of it, right?

Yes, probably so...

I actually found nomnom to be the best. Just in case you've never heard of it http://npm.im/nomnom

I've never used nomnom, but I have used yargs and liked it pretty well. It's also much more widely used. I think I'd like to stick with that one personally. What do you think @sxn?

Hm. Actually I hadn't played around with either of those, so I can't form an informed opinion. I'll briefly look into both before diving in and come back. Without looking into them I'd probably choose {{yargs}} just because there would be at least one person who knows this codebase and the library we'd be introducing. :D


fix zoom-container size

fix the overflow thumbnail image size issue

This looks like a fairly harmless fix, but could you tell me a little bit about what the issue it fixes is? Just want to understand what the change is trying to fix.

hi @wittlock,
Sorry, my bad. It turns out this is just duplication of is Issue#6 (which the PR has been created "Issue#6 fix - accurate zoom even for reduced size thumb image #24"). I will close this PR. Thanks!


fix: ignore empty event lines

Description
The Event Stream implementation was printing log in the console when an empty line was received.
I ignored the empty lines and also removed the log because it can flood log manager of production servers.
PS: super cool project guys, we love using it at Didask

Thank you @Aschen! I suppose it makes sense that there are empty lines in the event source response.

@all-contributors please add @Aschen for code


[monitor/monitor-opentelemetry-exporter] Update OpenTelemetry Instrumentation Packages

Packages impacted by this PR
@azure/monitor-opentelemetry-exporter
Issues associated with this PR
https://github.com/microsoft/ApplicationInsights-node.js/issues/1144
Describe the problem that is addressed by this PR
Update the @opentelemetry/instrumentation libraries in order to resolve a dependency conflict with @azure/functions-core
Are there test cases added in this PR? (If not, why?)
No. This is just an update of dependencies.
Checklists

[x] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[x] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


Attribute adyenMD missing in metadata

Describe the bug
Hi, it seems a new attribute adyenMD has been introduced in the last release code but is missing in the metadatas.
This custom attribute is used on paymentInstrument object, I see the attribute in develop branch but not on release 20.1.3.
To Reproduce
We were not able to reproduce the bug on development instance but only on production.
All card payments with 3DS finished with an error.
Here our logs from production :
Error while executing script 'int_adyen_SFRA/cartridge/controllers/CheckoutServices.js': ReferenceError: Unknown dynamic property 'adyenMD' for class 'class dw.object.ExtensibleObject$ExtensibleObjectAttributes'. (int_adyen_SFRA/cartridge/controllers/CheckoutServices.js#217) at int_adyen_SFRA/cartridge/controllers/CheckoutServices.js:217
We were able to solve this issue by adding the adyenMD attribute on OrderPaymentInstrument in metadata.
Regards,
Antoine

Hi @aquinzain,
Thank you for pointing this out.
The adyenMD attribute is indeed missing and adding it in the metadata like you did should solve the issue, so no further action is required from you.
For the record, Antoine's issue could be solved either directly from the business manager OR by adding the following attribute to the file system-objecttype-extensions.xml under an existing attribute (e.g. the attribute adyenAction)
  <attribute-definition attribute-id="adyenMD">
      <display-name xml:lang="x-default">adyenMD</display-name>
      <description xml:lang="x-default">Adyen MD for 3D Secure</description>
      <type>text</type>
      <mandatory-flag>false</mandatory-flag>
      <externally-managed-flag>false</externally-managed-flag>
      <min-length>0</min-length>
      <field-length>0</field-length>
  </attribute-definition>

And then re-importing the metadata as described here
Let me know if you have other questions and apologies for the inconvenience.
Regards,
Zaid

Hi @aquinzain,
Thank you for pointing this out.
The adyenMD attribute is indeed missing and adding it in the metadata like you did should solve the issue, so no further action is required from you.
For the record, Antoine's issue could be solved either directly from the business manager OR by adding the following attribute to the file system-objecttype-extensions.xml under an existing attribute (e.g. the attribute adyenAction)
  <attribute-definition attribute-id="adyenMD">
      <display-name xml:lang="x-default">adyenMD</display-name>
      <description xml:lang="x-default">Adyen MD for 3D Secure</description>
      <type>text</type>
      <mandatory-flag>false</mandatory-flag>
      <externally-managed-flag>false</externally-managed-flag>
      <min-length>0</min-length>
      <field-length>0</field-length>
  </attribute-definition>

And then re-importing the metadata as described here
Let me know if you have other questions and apologies for the inconvenience.
Regards,
Zaid


Installation docs

Just did a clean install of v1.0. And this step is in the wrong order.
First enable the filament panel. Then do the lunar:install. Otherwise an error occurs with the lunar:install, stating the panel is needed. But then it's unclear that you need to run the installer again to seed the database with needed permissions and users etc.

Since this PR was pending. I upgraded the whole install process. It now has correct return types in the sub-commands.
Also a check for a admin user was added, and if no admin is present, create one.

Thanks so much for this.
I notice when running this pull request that DB::transaction still fails because of missing attributes, specifically description:
SQLSTATE[HY000]: General error: 1364 Field 'description' doesn't have a default value (Connection: mysql, SQL: insert into `lunar_attributes` (`attribute_type`, `attribute_group_id`, `position`, `name`, `handle`, `section`, `type`, `required`, `default_value`, `configuration`, `system`, `updated_at`, `created_at`) values (Lunar\Models\Product, 1, 1, {"en":"Name"}, name, main, Lunar\FieldTypes\TranslatedText, 1, ?, {"richtext":false}, 1, 2024-02-11 06:24:53, 2024-02-11 06:24:53))

On my system the temporary fix for all attributes was to append a description field such as the example below:
 Attribute::create([
            'attribute_type' => Product::class,
            'attribute_group_id' => $group->id,
            'position' => 1,
            'name' => [
                'en' => 'Name',
            ],
            'handle' => 'name',
            'section' => 'main',
            'type' => TranslatedText::class,
            'required' => true,
            'default_value' => null,
            'configuration' => [
                'richtext' => false,
            ],
            'system' => true,
            'description' => '', // TODO had to add this to make the seeder work
        ]);

I had to do this for all four attributes seeded in the installer to make it work.
From what I can see in the 1.x documentation description is maybe only partially documented. In the MySQL it's a JSON field that cannot be null.
I would be grateful to know what we can use as initial values for this description.

Something else to consider to make a working install are tax defaults, apart from the TaxClass.
This is present in the Livewire starter kit:
https://github.com/lunarphp/livewire-starter-kit/blob/main/database/seeders/TaxSeeder.php

I will add the description. I didn't had that problem. But lots of merges last week, so maybe something changed upstream.

Thanks @webpatser for the help. We'll be working on this soon (this coming week) and this is a helpful start.

Added the new description field to the Lunar installer. That field was recently added in 2024_01_11_100000_add_description_to_attributes_table.php.
For now the description is blank, this should maybe contain some default description :-)

Feedback is processed..


term_windows: use golang.org/x/sys/windows

The parts of github.com/Azure/go-ansiterm/winterm that were used
is now provided by golang.org/x/sys/windows, so switch to that
package, as it's more actively maintained.

@cpuguy83 @dims @tklauser PTAL

LGTM !! thankfully it's mostly the same.

looks pretty good. Most are simple replacements, and any other code difference looks good as well.

Looks like this broke users at https://github.com/docker/for-win/issues/9770, because syscall.STD_INPUT_HANDLE = -10 while windows.STD_INPUT_HANDLE = -10 & (1 << 32 - 1)

Unfortunately I am unable to reproduce the issue linked to confirm what caused this.


Base.Meta.ParseError("invalid identifier name "?"")

Hello @vdayanand ,
Thanks for this package. I was trying it with the notebooks of mr. Kaminsky, and then the following error message appeared when converting lecture01.ipynb (i.e. jupyter2pluto("lecture01.ipynb") ):

ERROR: Base.Meta.ParseError("invalid identifier name \"?\"")
 I'm using Julia 1.9 under ubuntu, and my registry looks like this:
  [6e4b80f9] BenchmarkTools v1.3.2
  [2f5d96fc] Jupyter2Pluto v0.1.1 `http://github.com/vdayanand/Jupyter2Pluto.jl#master`
  [c3e4b0f8] Pluto v0.19.26
  [3fa0cd96] REPL

Thanks,

Thanks for reporting the bug, this should be fixed by https://github.com/vdayanand/Jupyter2Pluto.jl/pull/7. Could you try the latest version of the package (v0.2.0)


Issue 8 - Styleguide Integration with Webpack

resolves #8
Integrates Caxy's KSS Zaba Template with webpack and kss-node, and by default makes the styleguide available at /styleguide.
Note: Currently using issue-5/webpack as the base branch - but once issue-5/webpack is merged into master, I will update the base branch to be master.
TODOs
Documentation

[x] Document styleguide configuration options exposed in config/project.config.js (e.g. enabling/disabling styleguide, etc.)
[x] Add Styleguide subsection to main README.md with link to KSS docs and where to view the styleguide (localhost:3000/styleguide by default - can be configured though)
[x] Document config/styleguide.config.js
[x] Create and document src/styleguide/project-assets/README.md @beckkramer probably best for you
[x] Document the kss-caxy-zaba-template package (https://github.com/caxy/kss-caxy-zaba-template)
[ ] Document the caxy-styleguide-webpack-plugin package (https://github.com/caxy/styleguide-webpack-plugin)
[ ] Document how the two styleguide packages mentioned above are used in the starter kit
[ ] Add more code comments to why the render() function is not called when on styleguide pages in src/main.js
[ ] Document global variable added when on styleguide pages var __STYLEGUIDE__ = true;

Additional Clean-up

[x] Expose more of the commonly used config values from config/styleguide.config.js into config/project.config.js. For ex: source, sass.files
[x] Allow styleguide url to be configured in config/project.config.js - currently hard-coded to /styleguide in server/main.js
[x] Move src/styles/example-colors.scss into appropriate location based on what we have decided for our styles directory structure @beckkramer

@caxy/developers I added a whole bunch of tasks on this PR that I need help with if anyone has bandwidth. Otherwise I'll be working through these items the rest of the week slowly.

@jschroed91 I'm unclear on what the added value is of having essentially one file in a repo (caxy-styleguide-webpack-plugin)  vs. having that be an 'extra' part of the styleguide branch of the starter kit. Is that repo just incomplete at this point/am I missing a bit of context that would illustrate the benefits of this approach more clearly?

@beckkramer RE: the separate repo for caxy-styleguide-webpack-plugin - there are couple reasons I thought going that route would be beneficial to us and worth the added effort of maintaining the separate package/repo.

Open source - there appears to be a need for a more advanced webpack plugin for the kss-node library as was somewhat evident in this thread: https://github.com/kss-node/kss-node/issues/311. The kss-webpack-plugin works quite well for rebuilding the styleguide each time webpack bundles are recompiled, but it doesn't anything beyond that.
The caxy-styleguide-webpack-plugin goes further and injects the webpack assets into the kss-node configuration so that the styleguide is built with the application assets included - which is quite valuable.
It still needs quite a bit of work on documentation and some work in the code itself ... but the ultimate goal is to have a full-featured kss webpack plugin to share w/ the community

Since this is a starter kit, all of the projects that are cloned from this kit will likely not be getting regular updates from the upstream starter kit as it evolves - so most projects won't be getting the updates made to the starter kit as it evolves, and it might be a difficult process to merge the updates from upstream into the project if there were customizations made to the boilerplate code (which is likely).
So ... de-coupling some of the smaller things like this webpack plugin will actually allow those projects to get updates to these separate packages easily without having to go through a merge-conflict nightmare trying to merge upstream into the project - they can simply run yarn upgrade caxy-styleguide-webpack-plugin to get the latest version and take advantage of any new features

Makes perfect sense, thanks for breaking that down.

so as an outsider looking in here.....
I have been trying to use the kss-webpack-plugin, but i noticed that the styleguide doesn't actually render the styles when running a watch (only when running a build) because the css needed is an actual static file. Should i be using this new plugin instead?

@mephilip That's a great question - we actually discussed that same issue today for the webpack plugin we wrote for this: https://github.com/caxy/styleguide-webpack-plugin
You can try that plugin out for yourself to see if the remedies the issue - the plugin is very similar to the kss-webpack-plugin, but it takes it a little further and injects the assets that were compiled by webpack into the kss-node configuration. Not sure if that will solve your exact issue or not.
There's one limitation w/ the plugin that we plan to update in the coming days - right now it only rebuilds the styleguide when webpack recompiles any assets, but if you're passing any assets into kss-node that aren't actually compiled/watched by webpack, then it won't rebuild (pattern markup partials for example).

@mephilip Also - forgot to mention ... our webpack plugin isn't documented at all at this point - but if you wanted to try it out, you could have a look in this PR for an example of how to use it
https://github.com/caxy/front-end-starter-kit/pull/17/files#diff-a58d55bdb5770c78ad512f8e91f8d051R71

I am actually working on the documentation right now!


Please verify the IP addresses for the gateways listed here

Second request, please verify the IP addresses for the gateways listed here.

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

ID: e1a62365-4312-8aad-d2f1-bb5c4184adf1
Version Independent ID: 2ba5b809-8025-d7ee-c756-d6d1bab033fb
Content: Azure SQL Database and SQL Data Warehouse Connectivity Architecture
Content Source: articles/sql-database/sql-database-connectivity-architecture.md
Service: sql-database
Sub-service: development
GitHub Login: @rohitnayakmsft
Microsoft Alias: rohitna

@cobra30299 We are checking this. And we will get back to you.

Thank you this is steve thompson microsoft<EMAIL_ADDRESS>----- Original Message -----
From: NavtejSaini-MSFT<EMAIL_ADDRESS>To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: cobra30299<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Sent: Fri, 18 Oct 2019 17:54:22 -0400 (EDT)
Subject: Re: [MicrosoftDocs/azure-docs] Please verify the IP addresses for the gateways listed here (#41060)
@cobra30299 We are checking this. And we will get back to you.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/MicrosoftDocs/azure-docs/issues/41060#issuecomment-543969105
--
WOW! Homepage (http://www.wowway.com)

Thank you this is steve thompson with Microsoft ! STTHOMPS
Need this for a customer !
<EMAIL_ADDRESS>----- Original Message -----
From: "NavtejSaini-MSFT"<EMAIL_ADDRESS>To: "MicrosoftDocs/azure-docs"<EMAIL_ADDRESS>Cc: "cobra30299"<EMAIL_ADDRESS>"Mention"<EMAIL_ADDRESS>Sent: Friday, October 18, 2019 4:54:22 PM
Subject: Re: [MicrosoftDocs/azure-docs] Please verify the IP addresses for the gateways listed here (#41060)
@cobra30299 We are checking this. And we will get back to you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub , or unsubscribe .

@cobra30299 We will try to check this today and revert.

@cobra30299/Steve - We have confirmed with our Product Group team and the documents are up to date with Gateway information.
Hope this helps.

@cobra30299 We are going ahead and closing this thread for now. Please get back to us if any questions.


Java model _bits property should be transient

The _bits property in the java models should be declared as private transient int _bits so that the _bits property does not get included when a developer serializes a model to JSON.

@RicoYao - Will this prevent it from other serialization methods? For instance if you serialize to disk and read back the same model you'd lose the "is set" capabilities right?

@rahul-malik My thinking is that if you read back the model and deserialize it through the generated TypeAdapter, then _bits will be set to the expected value again (because the TypeAdapter uses the Builder which sets _bits).


[BUG] OpenAI Translator - Error 429

User report
I literally acquired ChatGPT yesterday (2024-02-15) and couldn’t use up all the tokens. Nevertheless, I’m getting a message saying I exceeded the monthly token quota, even though my dashboard shows everything is okay and I’ve used very few tokens. [What could be the issue, and how can I resolve it?
thanks for the attention.
I

Debugger data (do not alter)
plugin_version: "1.4.7"
platform: "Desktop"
framework_version: "1.5.3"
obsidian_version: "1.5.3"
selected_service: "openai_translator"

Hey, I'm sorry for getting back to you so late! I had forgotten to reply to you back then.
Is this still an issue you're encountering?
From my (limited) experience with the OpenAI API, if you get that message, the API connection should be set-up correctly (correct host found, api key is valid), but you might not have any credits available (under billing)
Let me know if it is an entirely different issue.


Possible to swap O/X for confirm/cancel?

I'm so used to the classic controls in Metal Gear games that having X as confirm and O as cancel actually trips me up a lot, is it possible to have an option to swap these just for their menu purposes without affecting their actual ingame function?
Not sure if this is beyond the scope of this project but I figured I'd suggest it!

You don't need MGSHDFix to do this actually, just swapping controller binds fully supports the old menu inputs without changing any other behavior.
MGS2: Look for my Swapped X/O bind

MGS3: Look for my Original X/O menu bind.

That seems like a great way of doing it using Steam Input @ShizCalev.
Closing this as dupe of #34. Please direct any further remapping issues/requests to that.


Add ShouldSerializeAttribute

At the moment, the bool ShouldSerialize{Name}() methods don't play well (at all) with refactoring. I'd propose the addition of a [ShouldSerialize(Field = "name")] method attribute, as this could be used with nameof():
public class Foo
{
    public IList<string> SomeList { get; set; }

    [ShouldSerialize(Field = nameof(SomeList))]
    private bool ReallyEmbedThatList()
    {
       return SomeList.Count > 0;
    }
}

You could do something like this with nameof already with a custom contract resolver. I don't think this would be used enough to be worth the complexity.


Don't log broken pipe exception when client disconnects

so this is what fixed the problem i was seeing on my local installs. Thanks James!


Content created through JS bypasses user defined CSS

Describe the bug
I like to tweak all my notebooks' CSS, trying to align their design with the guidelines of my University.
In principle, changing the font for the entire notebook should be easy with something like:
<link href='https://fonts.googleapis.com/css?family=Montserrat:300,300italic,800,800italic' rel='stylesheet'>

<style>
    .marimo, :root {
        --text-font: 'Montserrat';
        --heading-font: 'Montserrat';
    }
</style>

It works perfectly everywhere except in the content generated through JavaScript, like DataFrames' , callouts', or accordions' outputs.
It also does not work entirely in the Slides mode.
Environment
{
  "marimo": "0.8.0",
  "OS": "Linux",
  "OS Version": "6.9.3-76060903-generic",
  "Processor": "x86_64",
  "Python Version": "3.10.12",
  "Binaries": {
    "Browser": "--",
    "Node": "--"
  },
  "Requirements": {
    "click": "8.0.3",
    "importlib-resources": "missing",
    "jedi": "0.19.1",
    "markdown": "3.7",
    "pymdown-extensions": "10.9",
    "pygments": "2.18.0",
    "tomlkit": "0.13.2",
    "uvicorn": "0.30.6",
    "starlette": "0.38.2",
    "websockets": "12.0",
    "typing-extensions": "4.12.2",
    "ruff": "0.6.1"
  }
}

Code to reproduce
import marimo as mo

mo.Html("""
<link href='https://fonts.googleapis.com/css?family=Montserrat:300,300italic,800,800italic' rel='stylesheet'>

<style>
    .marimo, :root {
        --text-font: 'Montserrat';
        --heading-font: 'Montserrat';
    }
</style>
""")

mo.callout("This is a callout", kind="neutral")

mo.md(""""This is a sentence where we can see that the change in `:root` took effect in any other place other than JS generated content."")

The font doesn't change

This is currently by design - we render the UI elements (besides markdown) in a shadow-dom for css isolation. This helps rendering external widgets without affecting others.
We have some feature requests for theming. If you can help describe what sort of theming capabilities you'd hope (to the limit), we can look into creating an API for this.

Ok. Good to know!
I think having the ability to access and change the already built-in CSS variables in :root (fonts, colors, etc.) would be great!
I would also like to manage font size and some spacing for standard classes, like paragraph.

We can provide an api fonts, sizing, and the primary/secondary color.
Things like paragraph spacing likely will be out of scope as it becomes an "API" that we need to manage / not break. So we will likely won't support paragraph padding and that would be under "use at your own risk"

That would be excelent! Thanks!


WIP: making proxy resource override mutually exclusive

Please provide a description of this PR:
Fixes: #52693

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all

@shriramsharma: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
3b9f9a69dd45c52d6e07e47075c1f51825feb410
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@keithmattix @howardjohn , can I get some initial review on this?
Please let me know if I'm missing something. Thanks

The commit has 0 lines changed I think?

Looks like make gen reverted your original changes

@howardjohn @ilrudie , sorry I mistakenly reverted my changes. Can you please review? Thanks

@howardjohn @keithmattix , whenever you get a chance, please review. Thanks

Regardless of what is the most preferred behavior this seems like a breaking change. And it might make it impossible to unset a field?

@howardjohn I completely agree it is a breaking change but the current way of unsetting a field itself seems very unintuitive. If I need to unset memory then I'm forced to set CPU annotation.
Do you think adding a separate annotation for unsetting a specific field is an option?

hey @howardjohn what do you recommend should be the path forward?

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.


String implicit/explicit conversion issues/stance

Hi!
I'm loving the library. However there's one slight issue with the current auto-conversions between Id <-> string.
First, it seems that some conversions are implicit, while others are explicit, for example between Id<T> and Id, string -> Id is implicit, while it is explicit for string -> Id<T>. Seems the API isn't consistent. This caused some EF Core queries I was trying to make to fail, as the query was actually downcasting the ID column of my database to a string, and the string representation of ID in Sql Server is not the same as Ulid's Base32 representation, causing the query to fail.
Is there a reason certain casts are implicit vs explicit? If not, I think the best approach is to make all upcasts to Id and Id<T> implicit, and all downcasts explicit. This way you can't get into the scenario I was in where I thought a comparison was upcasting to Id and not downcasting Id. I feel like if you're ever using this library you're really wanting to operate only on the Id types, and if you want to do so then you can easily call ToString() to ToId().
Thoughts?

Hi!

I got an email about this earlier this week as well, with exactly the same concern. I initially made the casts implicit to make the library more interoperable and easier to adopt. However, looking back at it now, this was clearly a judgement error on my part - type information should never be lost implicitly. This also causes problems with comparison, since two different ID types can be compared to each other in, for example, a LINQ Where lambda, with only an IDE warning about an implicit cast but no compiler error. That clearly works against the purpose and goal of the library.
I will push a new version this week, removing all implicit casts which lose type information, just as you suggest. It's a far better approach.

Awesome! Thank you for the quick response.


Instaclustr partner information

Organization name
Instaclustr, now part of Spot by NetApp
Brief description of your business and what it does (50 words or less)
Instaclustr helps organizations deliver applications at scale by operating and supporting their data infrastructure through its SaaS platform for open source technologies, whether on-prem or in their cloud of choice.
In addition to managed platforms, Instaclustr also offers 24x7 support services, consulting and training for numerous open source technologies.
Name of your relevant product(s) or service for the OpenSearch audience
Instaclustr provides a fully managed and hosted service for OpenSearch on your cloud provider of choice under the Apache 2.0 License.
What OpenSearch technologies do you specialize in

Fully managed and hosted OpenSearch service
Configure through the Instaclustr SaaS platform, Instaclustr API or Terraform
24x7 Expert support
SOC 2, PCI Private Network and PrivateLink enabled
Built-in monitoring
99.999% SLA
Run in your cloud provider account or ours

Type of business
Managed Service Provider
Home/main office location or address
Canberra, Australia and San Jose, California, US
How can people contact you (email and phone)
<EMAIL_ADDRESS>Regions you serve
Worldwide
Industry specialization
All industries
Logo
Please see logo attached.
PNG:

Links
Add links to your last three blogs that are relevant for the OpenSearch Project audience.
https://www.instaclustr.com/blog/opensearch-feature-update/
https://www.instaclustr.com/blog/opensearch-2-now-in-preview-release/
https://www.instaclustr.com/blog/instaclustr-updates-nodes-types-for-opensearch-offering/

@abunday - Thank you for your submission.


Update base.html

d0ugal marked #324 closed because of something to do with with a previous discussion about local store. That said: this templates src URLs are still "broken" (a bug) for non-HTTP-served content.
It is just a reference error that only shows up when "http:" is not the default protocol to be handled -- i.e. when not being served. An alternative to this 'fix': store jquery and modernizr within the template directory structure itself and update this path reference to use {{base_url}}.

I didn't mean to suggest the bug is invalid. I closed it as the issue was described in another issue which was also open - however, yours probably highlighted it a bit more clearly.
I think we should go for having a local copy rather than upadating the CDN link, since that wont always work offline.

That is what I have done locally, and given what you have done w/ the
mkdocs theme, I agree. I was baffled by the change to these lines in the
file done in November and couldn't tell which way you wanted to take it.
Thanks.
On Sat, Jan 10, 2015 at 11:01 AM, Dougal Matthews<EMAIL_ADDRESS>wrote:

I didn't mean to suggest the bug is invalid. I closed it as the issue was
described in another issue which was also open - however, yours probably
highlighted it a bit more clearly.
I think we should go for having a local copy rather than upadating the CDN
link, since that wont always work offline.
--
Reply to this email directly or view it on GitHub
https://github.com/tomchristie/mkdocs/pull/325#issuecomment-69462744.

Yeah, the issue is probably my fault. I missed that bit in #168 I think, or I didn't fully appreciate what it was changing.
Do you want to update this to bundle a copy with mkdocs? or shall I close this and do that.

I'm not sure that I know how ... but I've give it a shot. Best way to
learn, right? If you have a few hours -- I've got to take care of something
first.
If I understand you correctly, you want these resources made locally
available in the directories of both the mkdocs and the readthedocs (this
one) themes?
On Sat, Jan 10, 2015 at 11:14 AM, Dougal Matthews<EMAIL_ADDRESS>wrote:

Yeah, the issue is probably my fault. I missed that bit in #168
https://github.com/tomchristie/mkdocs/pull/168 I think, or I didn't
fully appreciate what it was changing.
Do you want to update this to bundle a copy with mkdocs? or shall I close
this and do that.
--
Reply to this email directly or view it on GitHub
https://github.com/tomchristie/mkdocs/pull/325#issuecomment-69463253.

OK ... I think I have wrangled the delta/diffs (mostly) off of what I have
done to your x.11 release. Plus some things that were based on my
interpretation of what you were asking earlier (CST) today.
What do you want to do? These are (in total) some number of (mostly small)
unrelated changes. There are the local storage things, a couple of template
javascript (refactoring results?) things, and a couple of my "enhancements"
-- such as for sequence diagrams.
Is there a good way to get these to you discretely? That is -- in separate
bundles? I only ask because I would like to support you in the least
burdensome way to you. It's all the same to me to just throw it into a big
set of deltas -- but I'm assuming that this would be harder for you to
figure out.
Your guidance/help/mentoring is appreciated. And, if in fact, pushing any
of my deltas upstream is not needed, that is fine by me as well. Just let
me know.
If you decide to guide me a little, there is one type of question that will
come up. I am in love with the functionality of your mkdocs theme. It took
me a little while -- but that thing is super snazzy. I also have to do
silly/stupid stuff like (for example, as given above) ... attach notes to
sequence diagrams based on the parts of a complicated-ish system being
broken last night. The generated HTML from MD document is almost a roadmap
for the people in the morning.
That was ramble-ey. Sorry. The question is this: if someone finds a way to
integrate the (say) sequence-diagram-UML-markdown --> SVG into your system,
I believe that others would like this. What is the best way and the best
place to get that into your hands and or your process?
Best Regards,
W. Archibald
On Sat, Jan 10, 2015 at 11:14 AM, Dougal Matthews<EMAIL_ADDRESS>wrote:

Yeah, the issue is probably my fault. I missed that bit in #168
https://github.com/tomchristie/mkdocs/pull/168 I think, or I didn't
fully appreciate what it was changing.
Do you want to update this to bundle a copy with mkdocs? or shall I close
this and do that.
--
Reply to this email directly or view it on GitHub
https://github.com/tomchristie/mkdocs/pull/325#issuecomment-69463253.

Hmm, so, all I think we need to do is include the JavaScript files in the themes (much like they include other JavaScript files). So we shouldn't need to change anything other than the html (to make it a local link) and add the JS files.


Failure When Importing Third Party SVGs

import LogoutIcon from<EMAIL_ADDRESS>
12:36:55 AM [vite] Internal server error: ENOENT: no such file or directory, open<EMAIL_ADDRESS>
The plugin seems to always look in the ./src directory.

Same

same

Checked on 0.6.3 and it works correctly.


Can form elements be programmatically updated from user input?

Prerequisites

[x] I have read the documentation

Description
I've two dropdown lists and content of second dropdown list depends of user selection in the first dropdown list
Form definition
const form = {
  "schema": {
    "title": "",
    "type": "object",
    "properties": {
      "destination": {
        "type": "string",
        "title": "Where are you headed?",
        "enum": [
          "canada",
          "usa",
          "international"
        ],
        "enumNames": [
          "Canada",
          "USA"
        ]
      },
      "provinceOrState": {
        "type": "string",
        "title": "Which province or state",
        "enum": [],
        "enumNames": []
      }
    }
  },
  "formData": null,
  "uiSchema": {
    "ui:rootFieldId": "form",
    "provinceOrState": {
      "ui:widget": "ProvinceOrStateWidget"
    },
  },
  "widgets": {
    "ProvinceOrStateWidget": props => {
      const { destination } = props.formContext;
      const getNum = destination => {
        if (destination === 'canada') {
          return provinces.map(province => {
            props.schema.enum.push(province)
          })
        }
        return states.map(state => {
          props.schema.enum.push(state)
        })
      }
      if (destination) {
        return (

            {getNum(destination).map((element, index) => (

{element.value}

            ))}

        );
      }
      return null;
    }
  },
};

Calling form
<Form
          formContext={{...this.props.formData}}
          onChange={this.handleChange}
          onSubmit={this.handleSubmit}
          {...this.props}
          liveValidate
        />

Version
^0.46.0

did you try this https://jsfiddle.net/69z2wepo/68259/ ?

The provided fiddle breaks at least for me (Stock Chrome). When I tick the box it shows the form - but when unticking the box, the input box is still shown - this should remove surely?

The issue was formData is immutable, so I solved it with assigning formData to a new variable, updating new variable with change from user and displaying Form with new variable.

@urbanvikingr I'm afraid I might have a similar issue here, could you share your solution, so I can try to adapt?


Not working testsamples.py/imatches on Windows

I have tried to execute testsamples.py and realized that the imatches(case Insensitive RegEx) dosn't working at all(neither for correct nor incorrect casing)

Hi, thanks a lot for reporting this issue. Apologies for taking long time to get back to you. I have published a fix for this. Please use version 2.0.26.